Von der Skizze zur Cloud-Applikation: Wie CAP und Joule die SAP-Entwicklung neu definieren

SAP S/4HANA lässt sich heute auf zwei grundlegend verschiedene Weisen erweitern: eng gekoppelt über das ABAP RESTful Application Programming Model (ABAP RAP) – oder eigenständig über das SAP Cloud Application Programming Model (CAP) auf der SAP BTP. Beide Modelle adressieren unterschiedliche Architekturschichten. Eduard Kumbeiz (COMLINE SE) zeigt in seinem Gastbeitrag, wo CAP seine strukturellen Stärken ausspielt und wie KI-Unterstützung durch Joule beide Entwicklungswege messbar beschleunigen kann.

ABAP RAP oder CAP? Eine falsch gestellte Frage

In unserem letzten Beitrag haben wir gezeigt, wie ABAP-Teams ihre Expertise in die Cloud überführen – mit Cloud ABAP und dem ABAP RESTful Application Programming Model auf der SAP BTP. Die Kernbotschaft: ABAP stirbt nicht, es transformiert sich. RAP ist das moderne Entwicklungsparadigma für S/4HANA-Erweiterungen – on-stack im S/4HANA-System selbst oder side-by-side auf der SAP BTP, jeweils mit tiefer nativer Kopplung an SAP S/4HANA.

Wer diesen Beitrag gelesen hat, könnte schlussfolgern: ABAP RAP deckt alles ab. Für S/4HANA-erfahrene Teams stimmt das in vielen Szenarien. Aber es gibt eine Kategorie von Anforderungen, die RAP strukturell nicht adressiert – und genau dort setzt das SAP Cloud Application Programming Model (CAP) an.

Wo RAP aufhört – und warum das kein Defizit ist

ABAP RAP – ob on-stack oder side-by-side auf SAP BTP – ist eng und bewusst an SAP S/4HANA gekoppelt. Genau das macht es stark: natives Typsystem, direkter Zugang zu Geschäftsobjekten, semantisches Verständnis des S/4HANA-Datenmodells ohne API-Umwege. Wer einen Beschaffungsprozess um eine eigene Eskalationsregel erweitern will, ist mit RAP genau richtig.

Diese enge Kopplung ist aber gleichzeitig eine strukturelle Grenze. RAP-Anwendungen sind S/4HANA-Erweiterungen – sie denken in S/4HANA-Entitäten, sie leben im oder direkt neben dem S/4HANA-System. Für Szenarien, die ein eigenes Domänenmodell brauchen, mehrere Quellsysteme integrieren oder eine vollständig eigenständige Anwendungslogik aufbauen, ist RAP schlicht nicht das richtige Werkzeug. Nicht weil es schwach wäre – sondern weil es für einen anderen Zweck gebaut wurde.

CAP: Cloud-Anwendungen unabhängig von S/4HANA

Das SAP Cloud Application Programming Model hingegen verfolgt einen grundlegend anderen Architekturansatz. CAP ist ausschließlich als Sidecar konzipiert: Die Anwendung läuft auf SAP BTP, kommuniziert über standardisierte OData- oder REST-APIs mit SAP S/4HANA – und bleibt architektonisch bewusst außerhalb des S/4HANA-Systems. Es gibt keinen direkten On-Stack-Zugang, keine native S/4HANA-Laufzeitintegration. Stattdessen beschreibt CAP eine eigene Domäne, in der SAP S/4HANA eine von potenziell mehreren Datenquellen ist.

Was auf den ersten Blick nach einer Einschränkung klingt, ist in der Praxis häufig genau der richtige Ansatz – besonders in drei typischen Szenarien:

• Eigenständige Anwendungsdomänen. Ein Lieferantenbewertungssystem, das S/4HANA-Lieferdaten mit externen Kreditrating-Informationen und einem eigenen Scoring-Modell kombiniert, gehört architektonisch nicht in eine S/4HANA-Erweiterung. CAP baut hier ein eigenes Domänenmodell auf – sauber entkoppelt, mit SAP S/4HANA als einer Datenquelle unter mehreren.
• B2B-Portale und externe Nutzeroberflächen. Wenn Distributoren, Lieferanten oder Kunden direkten Systemzugang brauchen, entsteht eine Anwendungsschicht, die primär für externe Nutzer gedacht ist – mit modernen UI-Anforderungen, mobiler Nutzung und einem eigenständigen Authentifizierungskonzept. CAP verbindet sich nahtlos mit React, Vue.js oder anderen modernen Frontend-Frameworks und ist für diesen Anwendungstyp architektonisch besser geeignet als eine RAP-basierte Erweiterung.
• Teams ohne ABAP-Hintergrund. Unternehmen, die BTP-Entwicklung mit Full-Stack-Entwicklern aus dem Java- oder JavaScript-Umfeld aufbauen, gewinnen mit CAP deutlich schneller Produktivität als mit einer ABAP-Einarbeitung. CAP nutzt Node.js oder Java als Laufzeitumgebung – Technologien, die Entwicklern außerhalb der SAP-Welt vertraut sind.

Die Architekturgrenze klar ziehen

In der Praxis sind RAP und CAP keine Alternativen, die gegeneinander abgewogen werden – sie adressieren unterschiedliche Schichten einer BTP-Architektur:

Viele Unternehmen betreiben beide Modelle parallel – und das ist kein Architekturwiderspruch, sondern eine saubere Trennung von Verantwortlichkeiten: Eine RAP-basierte Erweiterung des S/4HANA-Bestellprozesses on-stack, und ein CAP-basiertes Lieferantenportal, das denselben Prozess von außen zugänglich macht. Wir reden von unterschiedlichen Werkzeugen für unterschiedliche Aufgaben auf einer gemeinsamen Plattform.

Was das in der Praxis bedeutet

 Ein Maschinenbauer mit weitverzweigtem Distributorennetz benötigte ein Self-Service-Portal: Bestellungen aufgeben, Lieferstatus abrufen, Rechnungen herunterladen. Kommerzielle Portallösungen lagen bei über 300.000 Euro – bei gleichzeitig eingeschränkter Flexibilität für individuelle Prozessanforderungen. Die Entscheidung fiel auf CAP, mit S/4HANA SD-APIs als Datenquelle und einem modernen React-Frontend. Ergebnis nach zwölf Wochen: produktiver MVP für 80.000 Euro. Sechs Monate nach Go-Live: Bestellabwicklungszeit minus 50 Prozent, Support-Aufkommen minus 60 Prozent. Kein RAP-Szenario – ein eigenständiges Domänenmodell für externe Nutzer. Das ist CAP-Territorium.

KI als Beschleuniger: Joule in der CAP-Entwicklung

Mit dem SAP Fiori Tools Project Accelerator können Teams aus UI-Skizzen, Figma-Modellen oder detaillierten User Stories CDS-Datenmodelle, OData-Services und eine funktionierende Fiori-Grundstruktur erstellen. Die KI-Unterstützung beschränkt sich nicht auf das erste Gerüst: Auch bei späteren Aufgaben wie Verarbeitungs- und Validierungslogik, Event Handler und Annotationen liefert Joule passende Code-Vorschläge auf Basis von User Prompts. Dadurch werden Routineaufgaben minimiert, die Entwicklung beschleunigt und der Schwerpunkt kann auf die fachliche Logik gelegt werden. Prototyping, das früher Tage in Anspruch nahm, wird damit zur Aufgabe von Stunden.

CAP-Entwickler profitieren zusätzlich vom Open-Source MCP-Server für CAP, der KI-Agenten wie Claude Code oder GitHub Copilot mit projektspezifischem Kontextwissen versorgt – von CDS-Servicestrukturen bis zu Best Practices. Dass sich der Einsatz rechnet, belegen Zahlen aus der Praxis: Bosch Digital hat Joule for Developers auf 1.500 Entwickler ausgerollt und misst eine Produktivitätssteigerung von 20 Prozent sowie 15 bis 20 Prozent schnellere Erstellung von Unit-Tests.