Strategische Einordnung: ABAP Cloud, RAP und CAP im Rahmen von BTP

Vom monolithischen System zur API-zentrierten Cloud-Architektur

Die SAP-Entwicklungswelt vollzieht einen Paradigmenwechsel: Weg von der engen Kopplung klassischer ABAP-Ansätze in ECC hin zu einer dezentralen, cloudfähigen Architektur. Dieser Wandel wird durch ABAP-Cloud, RAP und CAP als Alternative getragen. Dabei gilt:

Die bisherige Basis: SAP ECC und klassisches ABAP

In der traditionellen On-Premise-Welt dominiert das klassische ABAP-Modell. Es bietet maximale Freiheit, führt aber zu architektonischen Herausforderungen:

Direkte Tabellenzugriffe, Enhancements und Modifikationen im Core.
Konsequenz: Eine tiefe systemische Kopplung, die die Upgrade-Fähigkeit einschränkt und die Wartungskosten (TCO) erhöht.
In dieser Umgebung ist ABAP-Cloud nicht nativ verfügbar.

ABAP-Cloud: Der Standard für die „Clean Core“-Strategie

ABAP-Cloud weist im Vergleich zum klassischen ABAP einen reduzierten Funktionsumfang auf und ist das obligatorische Entwicklungsmodell für S/4HANA Public Cloud und das SAP BTP ABAP Environment:

Es erzwingt die Nutzung freigegebener SAP-APIs und hat eine Cloud-optimierte Syntax.
Zielsetzung: Sicherstellung der Cloud-Fähigkeit und Upgrade-Stabilität durch strikte Trennung von kundeneigener Logik und SAP-Core.

RAP (RESTful ABAP Programming Model): Das transaktionale Herzstück

RAP ist das Framework innerhalb von ABAP-Cloud zur Erstellung OData-basierter Services:

Architekturschichten:

- Datenmodell: Semantisch reiche Core Data Services (CDS).

- Verhaltensmodell: Definition von Logik (Create, Update, Delete) inkl. Draft-Handling für transaktionale Sicherheit.

- Service-Definition: Bereitstellung als OData V2/V4 für Fiori-UIs oder externe Konsumenten.

Eine modellgetriebene Entwicklung, die standardmäßig moderne UI-Paradigmen (Fiori Elements) unterstützt.

4. Die Brücke: RAP im Kontext von S/4HANA als On-Premise-System

Es gibt zwei Möglichkeiten:

Nutzung von RAP in vereinfachter Form (ohne BTP).
Nutzung über BTP über ein Side-by-Side Ansatz.

RAP vs. CAP: Architektonische Entscheidungshilfe

Für Cloud-native Erweiterungen stehen zwei Paradigmen zur Verfügung:

Merkmal	RAP	CAP
Technologie-Stack	ABAP-basiert (Kernel-nah)	Node.js oder Java (Open Source Fokus)
Primärer Fokus	Integrierte ERP-Erweiterungen	Flexible, leichtgewichtige Microservices
Governance	Vorgegeben	Hohe Flexibilität bei Bibliotheken/Tools
Compliance	Nutzt ABAP-Berechtigungskonzept	Eigenständiges Security-Modell (UAA/XSUAA)

Fazit: Der Weg zur zukunftssicheren Architektur

Die Transformation folgt einem klaren Pfad:

Entkopplung: Innovationen finden Side-by-Side auf der BTP statt, um den ERP-Kern sauber zu halten (Clean Core).
Standardisierung: RAP ist der Standard für alle ABAP-Entwickler, um zukunftssichere (Cloud-ready) Apps zu entwickeln.
Flexibilität: CAP ergänzt das Portfolio dort, wo Cloud-native Flexibilität und Open-Source-Expertise gefragt sind.

Der entscheidende Paradigmenwechsel: Weg von systeminternen Modifikationen – hin zu cloudfähigen Services über stabile, versionierte APIs.

Unsere Experten helfen Ihnen weiter!

Sie haben weitergehende Fragen rund um das Thema SAP ABAPStack oder zum Service- und Produktangebot der isacon AG? Kontaktieren Sie gerne unseren Experten.