Mit dem SAP Cloud Application Programming Model entwickeln

Core Data Services (CDS) als zentrales Modellierungsinstrument

Die SAP Core Data Services (CDS) definieren die fachlichen Strukturen einer Anwendung. Entitäten, Beziehungen und Semantiken werden als kompakte Modelle formuliert und dienen als gemeinsamer Ursprung für Datenbanktabellen, OData-Services und Ableitungen im Backend. Die Modelle bieten Tools für Aggregationen, Filter und Auswertungen, ohne dass prozeduraler Code erforderlich ist. Die Vereinheitlichung von Domäne, Persistenz und Schnittstellen führt zu stabilen Grundlagen für spätere Erweiterungen und fördert eine saubere Trennung von fachlicher Logik und Infrastruktur.

Konzepte wie cuid und managed ergänzen Datenstrukturen um technische Felder für Identifikation und Änderungsdaten. Die Modelle werden in der Laufzeit automatisch erweitert und erlauben konsistente Abläufe bei der Erfassung und Aktualisierung von Datensätzen. Dies erspart zusätzliche Implementierungen und verhindert strukturelle Abweichungen zwischen Tabellen und Services.

Serviceebene und technische Ausführung

Die Serviceebene bildet den Kern der Laufzeit. Der Entwickler definiert fachliche Endpunkte, die direkt auf CDS-Modelle zugreifen. Das Framework stellt OData-V4-Schnittstellen bereit und erzeugt Operationen für Lesen, Schreiben, Aktualisieren und Löschen. Erweiterungen erfolgen durch Handler, die in JavaScript oder Java formuliert werden. Die Handler-Schicht verarbeitet Anfragen, validiert Eingaben, führt Berechnungen aus und steuert Interaktionen mit Persistenz oder Fremdsystemen.

Neben CRUD-Operationen stehen Funktionen und Aktionen zur Verfügung. Funktionen liefern berechnete Werte ohne Seiteneffekte. Aktionen steuern Abläufe, die Daten verändern. Die Ausführung orientiert sich an HTTP-Semantiken und strukturiert Zugriffe auf Entitäten, Parameter und Rückgaben. Durch diese Mechanik lässt sich ein kontrolliertes Verhalten erreichen, das die Auswertbarkeit und Nachverfolgbarkeit von Änderungen unterstützt.

Laufzeitmechanismen und Interaktion mit Ereignissen

Die CAP-Laufzeit verarbeitet eingehende Anfragen über klar definierte Prozessstufen. Vor- und Nachverarbeitungen lassen sich gezielt aktivieren, um Strukturprüfungen, Typanpassungen oder Zugriffskontrollen einzubauen. Ereignisse aus internen oder externen Quellen können Vorgänge auslösen, ohne dass dafür synchrone Abhängigkeiten entstehen. Die Laufzeit verwaltet Transaktionen, ordnet sie Services zu und stellt sicher, dass fachliche Abläufe unabhängig vom zugrunde liegenden Kommunikationsmodell stabil ausgeführt werden. Dadurch wird der Übergang von isolierten Funktionen hin zu belastbaren verteilten Systemen unterstützt, ohne dass zusätzliche Frameworks notwendig sind.

Das Cloud Application Programming Model unterstützt konfigurierbare Strukturen, die ohne Eingriffe in den Anwendungscode greifbare Auswirkungen auf Abläufe haben. Einstellungen zu Rollen, Berechtigungen, Serviceparametern oder Routing lassen sich in dedizierten Dateien formulieren und zur Laufzeit laden. Dadurch können Teams Anpassungen vornehmen, ohne Logikblöcke umzuschreiben. Die Trennung zwischen Code und Konfiguration erleichtert den Betrieb in Umgebungen mit voneinander abweichenden Vorgaben, da Varianten für Entwicklung, Test und Produktion gezielt bereitstehen. Die Steuerung durch deklarative Parameter erhöht die Stabilität, da fachliche Regeln unabhängig von Implementierungsdetails gepflegt werden.

Validierungsregeln und fachliche Konsistenz

CAP bietet Mechanismen zur Definition fachlicher Prüfregeln, die direkt an Entitäten oder Services gebunden werden. Regeln greifen vor der Verarbeitung und verhindern unzulässige Zustände, indem sie Eingaben analysieren und Ablehnungen zurückgeben, sobald Anforderungen nicht erfüllt sind. Dadurch bleibt die Datenqualität hoch, selbst wenn mehrere Dienste parallel auf dieselben Strukturen zugreifen. Die Prüfmechanik lässt sich erweitern, indem Services Kontextinformationen aus Anfragen auswerten oder abhängige Entitäten einbeziehen. Dieser Ansatz verhindert inkonsistente Datensätze und sorgt dafür, dass fachliche Vorgaben systemweit einheitlich umgesetzt sind.

Das Cloud Application Programming Model nutzt SQLite für den lokalen Betrieb. Tabellen werden beim Start automatisch erzeugt und Daten aus CSV-Dateien eingelesen. Dieser Mechanismus erlaubt schnelle Entwicklungszyklen und verkürzt die Dauer für Testläufe. Der Befehl cds watch startet einen lokalen Server, überwacht Dateien und lädt Prozesse neu. Änderungen an Modellen, Services oder Logik sind somit unmittelbar sichtbar.

Die gleiche Struktur lässt sich mit SAP HANA Cloud verbinden. Dabei werden Tabellen, Indizes und Strukturen aus den CDS-Modellen abgeleitet. CAP übernimmt die Übersetzung in HANA-optimierte Artefakte. Durch diese Abstraktion bleibt der Code stabil, selbst wenn sich das Datenbanksystem unterscheidet.

Modulare Architektur und Erweiterbarkeit

Ein CAP-Projekt folgt einer klaren Gliederung. Das Datenmodell befindet sich im Verzeichnis db, die Services im Verzeichnis srv und optionale Oberflächen im Verzeichnis app. Diese Trennung verbessert die Wartbarkeit und ermöglicht parallele Arbeiten an verschiedenen Ebenen. Projektteile lassen sich schrittweise erweitern oder austauschen, ohne die Gesamtstruktur zu beeinträchtigen.

Das Cloud Application Programming Model unterstützt ereignisbasierte Abläufe. Anwendungen können interne oder externe Ereignisse senden und empfangen. Dadurch lassen sich Workflows auf mehrere Komponenten verteilen, ohne starre Aufrufe oder Kopplungen einzuführen. Die Integration externer APIs erfolgt über deklarative Definitionen. Das Framework erzeugt Proxys, die Anfragen an entfernte Systeme weiterleiten und Antworten für interne Abläufe bereitstellen.

Vergleich zu ABAP RESTful Application Programming Model (RAP)

ABAP RAP und CAP adressieren unterschiedliche Bereiche der SAP-Landschaft. RAP integriert sich tief in SAP S/4HANA und baut auf ABAP, CDS View Entities, ADT und Business Objects auf. Es ist die Grundlage für In-App-Erweiterungen und Cloud-ABAP-Entwicklung. RAP bietet einen formalisierten Weg zur Modellierung und Steuerung transaktionaler Abläufe im Kernsystem.

CAP richtet sich an Szenarien, in denen Anwendungen außerhalb des S/4HANA-Kerns programmiert werden sollen. Dazu gehören eigenständige Dienste, Integrationsschichten, Erweiterungen im BTP-Kontext und Multi-Tenant-Anwendungen. Die Offenheit für JavaScript oder Java erleichtert die Einbindung gemischter Teams und unterstützt Cloud-Architekturen mit klar abgegrenzten Services.

Beide Modelle nutzen CDS als Grundlage, verfolgen jedoch unterschiedliche strategische Ziele. RAP erweitert ABAP intern und führt Business-Objekte als direkte Bestandteile des Sprachumfangs. CAP setzt CDS als universelles Metamodell ein und erzeugt daraus APIs, Persistenzdefinitionen und Laufzeitstrukturen im Cloud-Umfeld.

Praxisorientierte Entwicklungsabläufe

Die Entwicklung mit CAP beginnt mit der Definition eines einfach strukturierten Datenmodells. Anschließend erfolgt die Exposition über einen Service, der die Entitäten projiziert und freigibt. Lokale Ausführungen zeigen sofortige Ergebnisse über OData-Aufrufe. Handler ergänzen fachliche Logik, validieren Daten, berechnen Werte oder orchestrieren Abläufe. Die Verbindung zu HANA Cloud oder weiteren Diensten wird durch Konfigurationen durchgeführt, nicht durch imperative Codeblöcke.

In komplexeren Szenarien lassen sich mehrere Services zu einer vollständigen Anwendung verbinden. Die Modelle bleiben weiterhin die einzige Quelle für Strukturinformationen. Diese Einheitlichkeit führt zu belastbaren Systemen, da Wechselwirkungen zwischen Backend, Persistenz und Schnittstellen transparent bleiben.

Einsatzgebiete und typische Motivationen

Das Cloud Application Programming Model eignet sich für Integrationsschichten zwischen SAP und nicht SAP-Systemen. Es steuert Datenflüsse, stellt APIs bereit und verarbeitet Ereignisse aus heterogenen Umgebungen. Multi-Tenant-Szenarien profitieren vom integrierten Lifecycle-Management. Mandanten erhalten isolierte Datenbereiche, und Erweiterungen lassen sich gezielt pro Mandant aktivieren.

Für eigenständige Cloud-Anwendungen bietet CAP eine stabile Grundlage. Die Entwicklungszeit reduziert sich, da das Framework technische Aufgaben übernimmt. Sicherheit, Authentifizierung, Validierungen und Berechtigungen sind eng eingebunden und müssen nicht wiederholt implementiert werden.

Die Nutzung der CAP Console ist auf die Zusammenarbeit im Team ausgelegt. Projekte lassen sich verwalten und bereitstellen. Entitlements, Serviceinstanzen und Log-Auswertungen erfolgen ohne manuelle Interaktion mit der BTP-Oberfläche. Die automatische Analyse der mta.yaml erleichtert den Abgleich zwischen Projektanforderungen und Subaccount-Konfigurationen. Die Möglichkeit, Logpegel dynamisch umzuschalten, beschleunigt Fehleranalysen.

Durch die Git-freundliche Struktur lassen sich Umgebungen versionieren. Teams greifen auf identische Projektzustände zu und können lokale und Cloud-Umgebungen ohne technische Reibungsverluste wechseln. Die Kombination aus Laufzeit, Werkzeugen und Containerisierung fördert zuverlässige Abläufe in verteilten Entwicklungsgruppen.

Positionierung im SAP-Portfolio

CAP bildet die bevorzugte Grundlage für Cloud-Erweiterungen und eigenständige Dienste auf der SAP BTP. ABAP RAP bildet die bevorzugte Grundlage für S/4HANA-nahe Erweiterungen und ABAP-basierte Cloud-Lösungen. Beide Modelle koexistieren ohne Konkurrenzdruck. Die Entscheidung orientiert sich an der Umgebung, der Sprache, der Integrationsdichte und dem Umfang der Erweiterung.

In S/4HANA dominiert RAP. In BTP-Umgebungen ohne Bezug zu ABAP dominiert CAP. In hybriden Szenarien ergänzen sich beide Modelle. Die Bewertung ergibt sich aus Compliance-Vorgaben, Architekturentscheidungen und dem Ziel, Anwendungen mit stabilen Schnittstellen über mehrere Produktgenerationen zu betreiben.