Ein Überblick über die Integrationsstrategie der SAP BTP: Integration Suite, API Management und Event Mesh auf strategischer Flughöhe.
Einleitung
In Teil 1 haben wir das Clean-Core-Prinzip und die Extensibility-Level A bis D vorgestellt. In Teil 4 ging es um die BTP-Environments Cloud Foundry, Kyma und das ABAP Environment. Jetzt verbinden wir beides: Wie sehen Erweiterungen konkret aus? Welches Programmiermodell passt zu welchem Szenario?.
Dieser Teil gibt einen Überblick über die beiden zentralen Entwicklungsmodelle der SAP-Welt: das Cloud Application Programming Model (CAP) für Side-by-Side Extensions auf der BTP und das RESTful Application Programming Model (RAP) für On-Stack- & Side by Side-Erweiterungen in S/4HANA und dem BTP ABAP Environment.
Denn der eigentliche Mehrwert der SAP BTP entsteht nicht isoliert, sondern dann, wenn Systeme, Daten und Prozesse intelligent miteinander verbunden werden. Genau hier setzt die SAP Integration Suite an.
Dieser Teil gibt einen Überblick über die Integrationsfähigkeiten der SAP BTP mittels der SAP Integration Suite. Wir erklären die wichtigsten Bausteine, ordnen sie ein und zeigen, wann welcher Ansatz sinnvoll ist.
Warum sollten wir überhaupt den SAP-Standard erweitern?
Der SAP-Standard deckt viel ab, aber natürlich nie alles.
Unternehmen haben individuelle Prozesse, branchenspezifische Anforderungen oder Integrationsbedarfe, die über die Standardfunktionalität hinausgehen.
Und das ist auch gut so: Denn genau diese individuellen Prozesse machen Unternehmen erfolgreich. Sie sind oft die eigentliche USP, was das Unternehmen vom Wettbewerb unterscheidet. Wenn alle nur Standard machen, wo bleibt dann der Differenzierungsvorteil? Gleichzeitig gilt: Nicht jede historisch gewachsene Individualentwicklung ist heute noch sinnvoll. Unternehmen sollten ihre individuellen Prozesse regelmäßig hinterfragen im Sinne von „brauchen wir diesen Prozess noch in seiner jetzigen Form?“ oder „Hat sich der Geschäftskontext so verändert, dass der Standard inzwischen die bessere Lösung wäre?“.
Diese Balance zwischen wertschöpfender Individualisierung und sinnvoller Standardisierung ist eine der wichtigsten strategischen Entscheidungen. Früher wurde Individualisierung über Z-Entwicklungen, User-Exits und Modifikationen umgesetzt mit den bekannten Folgen:
- technische Schulden
- Upgrade-Blockaden
- wachsende Komplexität.
Das Clean-Core-Prinzip (siehe Teil 1) gibt eine klare Richtung vor: Erweitere über freigegebene Schnittstellen, halte den Kern sauber.
Nun das klingt erstmal logisch, Aber wie macht man das genau?
SAP bietet zwei strategische Wege:
Ansatz | Beschreibung | Programmiermodell |
On-Stack (In-App) | Erweiterungen direkt im S/4HANA-System oder im BTP ABAP Environment. Nutzt freigegebene APIs, BAdIs, Funktionsbausteine und CDS-Views. Der Code läuft im selben System wie der Standard. | RAP – RESTful Application Programming Model |
Side-by-Side | Eigenständige Anwendungen auf der BTP, die über APIs mit beispielsweise dem S/4HANA kommunizieren. Eine eigene Datenhaltung ist möglich. Das Deployment erfolgt auf die Cloud Foundry oder Kyma Umgebung der Business Technology Platform. | CAP – Cloud Application Programming Model (Node.js oder Java) |
Beide Ansätze ergänzen sich, es ist kein Entweder-oder. Die Wahl hängt vom Szenario, den Team-Skills und der gewünschten Architektur ab.
CAP – Das Cloud Application Programming Model
CAP ist SAPs strategisches Programmiermodell für Side-by-Side Extensions auf der BTP. Es wurde von SAP entwickelt, um die Erstellung von Cloud-nativen Geschäftsanwendungen so effizient wie möglich zu machen – mit einem klaren Fokus auf Domain-Driven Design und Konvention vor Konfiguration.
Was ist CAP?
- Open-Source-Framework: CAP ist frei verfügbar und wird von SAP aktiv weiterentwickelt.
- Sprachunterstützung: js (JavaScript/TypeScript) oder Java.
- CDS (Core Data Services): Eine deklarative Modellierungssprache für Datenmodelle, Services und Berechtigungen. CDS ist sozusagen das Herzstück von CAP.
- Datenbank-agnostisch: Unterstützt SAP HANA Cloud, PostgreSQL und SQLite (für lokale Entwicklung). Die CDS-Modelle sind unabhängig von der konkreten Datenbank.
- Built-in Best Practices: Authentifizierung (via Cloud Identity Servic), Multitenancy, Localization, Draft-Handling, Fiori-Kompatibilität sind vorkonfiguriert und müssen nicht selbst gebaut werden.
Architektur einer CAP-Anwendung
Eine typische CAP-Anwendung besteht ganz vereinfacht gesagt aus drei Schichten:
Schicht | Technologie | Aufgabe |
Datenmodell (db/) | CDS-Definitionen, die Entitäten, Assoziationen und Annotationen beschreiben. | Definiert das persistente Datenmodell. Wird in HANA-Cloud-Tabellen oder PostgreSQL-Tabellen auf der BTP deployed. |
Service-Schicht (srv/) | CDS-Service-Definitionen + Custom Handler (Node.js/Java) für Geschäftslogik. | Exponiert OData-V4- oder REST-APIs. Implementiert Validierungen, Berechnungen, Integrationsaufrufe. |
UI (app/) | SAP Fiori Elements (empfohlen) oder Freestyle SAPUI5/React. | Die Benutzeroberfläche. SAP Fiori Elements generiert komplette UI-Seiten (Listen, Objektdetails, Formulare) automatisch aus CDS-Annotationen – ohne manuellen UI-Code. Das spart erheblich Entwicklungsaufwand und sorgt für eine konsistente SAP-User-Experience. Freestyle-Ansätze bieten mehr gestalterische Freiheit, bedeuten aber auch deutlich mehr Aufwand. |
Das Ergebnis: Mit wenigen CDS-Dateien und Custom Handlern entsteht eine vollständige Geschäftsanwendung inkl. OData-API, Berechtigungen, Fiori-UI und Datenbankschema. Wer sich an die klassische ABAP-Welt erinnert, weiß, was das bedeutet. Früher musste man ICF-Knoten manuell anlegen, OData-Services Schritt für Schritt im SEGW ausprägen, Deep-Create-Logik selbst programmieren und jede CRUD-Operation einzeln implementieren.
In CAP reicht eine Composition (z. B. Bestellkopf → Positionen → Unterpositionen), und das Framework generiert automatisch Deep Create, Deep Update und Deep Delete über die gesamte Objekthierarchie.
Associations definieren Beziehungen zwischen Entitäten deklarativ. Keine manuellen JOINs, keine Navigations-Properties von Hand.
Annotations steuern nicht nur die UI (Fiori Elements), sondern auch Validierungen, Wertehelfen, Sortierungen und Suchfelder. Alles im CDS-Modell, nicht im Code verstreut. Die Entwicklung wird durch SAP CAP enorm beschleunigt.
Deployment-Optionen für CAP
Ziel | Details |
Cloud Foundry | Empfohlene Standardoption. Deployment als MTA (Multi-Target Application). Buildpacks für Node.js oder Java. |
Kyma / Kubernetes | Deployment als Container-Image (Docker). Ideal, wenn Kubernetes-Expertise vorhanden ist oder containerisierte Workloads bevorzugt werden. |
Vorteil: SAP CAP ermöglicht eine direkte lokale Entwicklung. Im Hybrid-Szenario lässt sich die Anwendung lokal ausführen und gleichzeitig gegen Cloud-Services (z. B. HANA-Cloud, Destination Service, etc.) testen. Dadurch können Entwickler produktionsnah arbeiten, ohne jedes Mal ein vollständiges Cloud-Deployment durchführen zu müssen.
RAP – Das RESTful Application Programming Model
RAP ist SAPs strategisches Programmiermodell für ABAP-basierte Entwicklung – sowohl in S/4HANA (On-Premise und Cloud) als auch im BTP ABAP Environment. Es löst die klassischen Programmiermodelle (Dynpro, Web Dynpro) ab und bringt ABAP ins Cloud-Zeitalter.
Was ist RAP?
- ABAP Cloud: RAP basiert auf ABAP Cloud.
- Business Objects (BO): Das zentrale Konzept. Ein BO definiert Entitäten, deren Verhalten (CRUD, Actions, Validations) und die Zugriffskontrolle.
- CDS Views: Datenmodellierung und -zugriff erfolgt über Core Data Services, ähnlich wie in CAP.
- Behavior Definitions & Implementations: Deklarative Definition des BO-Verhaltens (was darf der Service?) und imperative Implementierung der Geschäftslogik in ABAP.
- OData-Exposition: Jedes RAP-BO kann automatisch als OData-V2- oder V4-Service exponiert werden und steht somit bereit für Fiori-Frontends.
Architektur eines RAP Business Objects
Artefakt | Beschreibung |
CDS Data Model | Datenbank-Tabellen und CDS-Entity-Definitionen mit Assoziationen, Annotationen und berechneten Feldern. |
Behavior Definition | Deklariert das Verhalten: Create/Read/Update/Delete, Actions (z. B. „Freigeben“), Validations (z. B. „Pflichtfelder prüfen“), Determinations (z. B. „Nummer automatisch vergeben“), Draft-Handling. |
Behavior Implementation | ABAP-Klasse, die die in der Behavior Definition deklarierten Methoden implementiert (die eigentliche Geschäftslogik). |
Service Definition | Legt fest, welche Entitäten des BO als OData-Service exponiert werden. |
Service Binding | Bindet die Service Definition an ein konkretes Protokoll (OData V2/V4) und einen Endpunkt. Ab hier ist der Service aufrufbar. |
Metadata Extensions | UI-Annotationen für Fiori Elements |
Wann CAP, wann RAP? – Praxisszenarien
Statt abstrakt zu bleiben, hier konkrete Szenarien und unsere Empfehlung:
| Szenario | Empfehlung | Begründung |
| Custom Field an Bestellung anhängen | RAP | Erweiterung eines bestehenden Standard-BO‘s. |
| Kundenportal mit eigenem Datenmodell | CAP | Eigene Datenhaltung, Web-Frontend, API-Zugriff auf S/4HANA. Klassisches Side-by-Side. |
| Genehmigungsworkflow für Bestellanforderungen | CAP + SAP Build Process Automation | Workflow-Engine kombiniert mit CAP-Service für Custom-Logik. |
| Embedded Analytics / Custom Report | RAP (On-Stack) | CDS-basierte Queries mit direktem S/4-Datenzugriff und ggf. Fiori-Element-Visualisierung. |
| Legacy-Z-Report modernisieren | RAP | ABAP-Code bereinigen, in RAP-BO kapseln, Fiori-UI generieren. |
| SaaS-Anwendung für mehrere Mandanten | CAP | Built-in Multitenancy in CAP. Subscription-Management über SaaS Provisioning Service. |
(Quelle: SAP Business Application Studio; SAP Build Code; ABAP Development Tools)
Best Practices aus unserer Projektpraxis
Thema | Empfehlung |
Klein anfangen | Starten Sie mit einem überschaubaren Pilotprojekt (z. B. ein Custom BO mit 3–5 Feldern). Lernen Sie das Tooling und die Patterns, bevor Sie komplexe Szenarien angehen. |
CDS ernst nehmen | Sowohl CAP als auch RAP basieren auf CDS. Investieren Sie in CDS-Know-How. |
Fiori Elements first | Nutzen Sie Fiori Elements (generierte UI) statt Freestyle-UI5, wann immer möglich. Der Aufwand ist drastisch geringer und die UX bleibt SAP-konform. |
API-Katalog pflegen | Dokumentieren Sie alle genutzten S/4HANA-APIs (OData, RFC, Events). Das erleichtert Impact-Analysen bei S/4HANA-Upgrades. |
Extensibility-Level tracken | Nutzen Sie das Extensibility-Cockpit in S/4HANA, um den Clean-Core-Status Ihrer Erweiterungen transparent zu machen (Level A–D). |
Blog-Serie:
In den nächsten Teilen gehen wir tiefer auf spezielle Themen ein, welche uns bei unseren Kunden immer wieder begegnen.
Vereinbaren Sie jetzt Ihren Expert Call. Wir freuen uns über Ihre Nachricht.
Thomas Krafft
- thomas-krafft
- n.n.
- n.n.
