SAP CAP Java: Why I still Code (and why Low-Code is holding you back)

Sarmad Ahmed Khalil — Thu, 12 Mar 2026 23:26:53 +0000

I’ve been seeing a lot of hype lately about "Citizen Developers" and how low-code is going to replace the need for actual programming in the SAP ecosystem.

Look, if you’re building a simple form for a one-off task, fine. Use Build Apps. But if you’re trying to build a real enterprise-grade extension on SAP BTP—something that actually scales—low-code is a trap.

The "Visual Logic" Headache

The biggest lie in low-code is that it's "faster."

Maybe it’s faster for the first 10 minutes. But the moment you hit a real-world requirement—like handling complex document streams or a non-standard OData expansion—you hit a wall.

In CAP Java, if I need to map a massive, messy external payload to my clean CDS entities, I’m not dragging boxes. I just pull in MapStruct. It’s type-safe, fast, and handles the "dirty work" so I can focus on the business logic. Look at how much cleaner this is than trying to find a "workaround" in a visual tool:

@Mapper(componentModel = "spring")
public interface InvoiceMapper {
    // Mapping messy external JSON to my CDS-based Entity
    @Mapping(source = "ext_ref", target = "referenceNumber")
    @Mapping(source = "vendor_id", target = "supplier")
    Invoice toEntity(ExternalInvoiceDto dto);
}

In a low-code tool, you’d spend an hour clicking through menus just to map those fields. In Java, it’s a single interface, and more importantly, it’s testable.

Visual flowcharts aren't architecture. Architecture is about maintainability. How do you do a proper peer review on a visual block? How do you run a git diff to see what changed in a production hotfix? You can't. With CDS and Java, my logic is transparent, version-controlled, and solid.

Why CAP Java is the actual "Clean Core"

For the backend extensions I'm building, I’m sticking with the Java stack for a few blunt reasons:

Type-safety isn't a luxury: I want my compiler to scream at me if my data model is broken. I don't want to find out during a production demo that a field was missing because a drag-and-drop connection was loose.

The JVM handles the heavy lifting: When you’re orchestrating high-volume data between BTP and S/4HANA, you need the performance of the JVM. Scripts and "flows" just don't have the same level of memory management.

Integration Suite is for middleware, not business logic: I use the Integration Suite (iFlows) for what it’s good at: being the "handshake" between systems. But the moment you start burying business rules inside an iFlow, you’re creating technical debt. Keep your logic in the CAP layer where it belongs.

Final thought

Programming is still relevant because it’s the only way to build software that lasts longer than a sales demo.

I’m not saying I have all the answers. I’m still in the thick of it, navigating the BTP landscape every day. But what I do know is that shortcuts like "drag-and-drop" logic usually end up costing more time than they save.

I’m sticking with the code because it’s the only way I can guarantee my architecture won't fall apart in six months. Whether I'm building a vendor portal or a complex integration flow, I want to know exactly what’s happening under the hood.

The goal isn't just to make it "work" for a demo—it's to build something I'm actually proud to sign my name to.

DEV Community: Sarmad Ahmed Khalil

SAP CAP Java: Why I still Code (and why Low-Code is holding you back)

The "Visual Logic" Headache

Why CAP Java is the actual "Clean Core"

Final thought