ABAP Cloud & RAP: Wie ABAP-Teams Clean Core umsetzen – side-by-side und on-stack

Mit dem Clean-Core-Prinzip und dem Wechsel in Richtung S/4HANA Cloud geraten viele ABAP-Teams unter Druck. Doch statt eines Abschieds von ABAP zeichnet sich nach Einschätzung von Eduard Kumbeiz (Head of SAP Innovation & Cloud Transformation, COMLINE) ein klarer Paradigmenwechsel ab: Mit ABAP Cloud und dem ABAP RESTful Application Programming Model (RAP) entstehe ein modernes Entwicklungsmodell, das Upgrade-Fähigkeit, API-Disziplin und Architekturqualität in den Mittelpunkt stellt. Wie dies konkret aussieht, schildert er in seinem Gastbeitrag für das IT-OnlineMagazin.

Die Frage, die ABAP-Teams umtreibt

„Ist ABAP tot?“ – Diese Frage taucht überall dort auf, wo Unternehmen den Wechsel auf S/4HANA Cloud planen oder ihre bestehende S/4HANA-Landschaft zukunftsfähig machen wollen. Der Auslöser ist meist das Prinzip Clean Core: Der Standard bleibt unangetastet, Erweiterungen sollen upgrade-stabil und supportbar bleiben – anstatt sich über Modifikationen, implizite Abhängigkeiten oder interne Zugriffe in den Kern zu „bohren“.

Die gute Nachricht: ABAP verschwindet nicht – es bekommt einen klareren, moderneren Rahmen. SAP fasst diesen Ansatz unter ABAP Cloud zusammen: eine cloud-optimierte Entwicklungsweise mit eingeschränkter Sprachversion und dem Prinzip „released APIs statt interner Objekte“. Das reduziert technische Schuld und verbessert die Upgrade-Fähigkeit spürbar. Für viele Teams bedeutet das auch: Die über Jahre aufgebaute ABAP-Kompetenz bleibt wertvoll – sie muss nur neu ausgerichtet werden.

 

RAP: Mehr als ein OData-Generator

 Der zentrale Baustein von ABAP Cloud ist das ABAP RESTful Application Programming Model (RAP). RAP ist kein OData-Generator, sondern ein durchgängiges Programmiermodell, das Datenmodellierung, Transaktionsverhalten und Service-Exposition in einer konsistenten Architektur zusammenführt – entwickelt in Eclipse ADT (ABAP Development Tools) statt in der klassischen SE80. Wer RAP nur als technisches Mittel zum Zweck betrachtet, unterschätzt seinen architektonischen Mehrwert: Business-Logik wird nicht mehr über viele technische Ebenen verteilt, sondern klar strukturiert und nachvollziehbar modelliert.

Die drei tragenden Säulen im Überblick:

• CDS (Core Data Services): Bildet das fachliche Datenmodell ab – inklusive Semantik, Beziehungen und Zugriffssteuerung.
• Behavior Definition & Implementation: Beschreibt das Transaktionsmodell – Create/Update/Delete, Validations, Actions, Determinations und bei Bedarf Draft-Handling.
• Service Definition & Binding: Stellt die Funktion als Service bereit – konsumierbar für Fiori-Apps, mobile Clients und API-Konsumenten gleichermaßen.

Das Ergebnis ist eine API-first-Architektur, die Logik über UI und Integrationen hinweg wiederverwendbar macht – ohne den Clean Core zu gefährden. Teams, die diesen Ansatz konsequent verfolgen, berichten von deutlich reduzierten Aufwänden bei Upgrades, besserer Testbarkeit durch ABAP Unit und CDS Test Doubles sowie einem spürbar klareren Überblick über die eigene Systemlandschaft.

 

 

Side-by-side auf BTP und on-stack in S/4HANA

ABAP Cloud wird in Diskussionen oft mit „ABAP auf BTP“ gleichgesetzt. In der Praxis sind jedoch zwei Zielbilder relevant – und genau diese Unterscheidung ist entscheidend für Unternehmen mit bestehenden S/4HANA On-Premise-Systemen.

1. Side-by-side auf SAP BTP (ABAP Environment)

ABAP läuft hier in einer eigenen Laufzeitumgebung auf der SAP Business Technology Platform. Die Integration in S/4HANA erfolgt ausschließlich über released APIs (OData/REST). Dieses Muster eignet sich besonders, wenn Entkopplung, eigenständige Release-Zyklen oder die Kombination mit externen Services und Cloud-Diensten im Vordergrund stehen. SAP positioniert die BTP ABAP Environment explizit für diesen side-by-side Erweiterungsansatz.

2. On-stack (Embedded ABAP Cloud) – für S/4HANA On-Premise und Private Cloud

Nicht jede Modernisierung lässt sich – oder soll – vollständig „neben dem System“ umgesetzt werden. Hier kommt das on-stack ABAP Cloud-Entwicklungsmodell ins Spiel, das in der Community auch als „Embedded Steampunk“ bekannt ist. Neue Entwicklungen folgen dabei denselben ABAP Cloud- und RAP-Standards wie auf der BTP: eingeschränkte Sprachversion, released APIs, keine internen Zugriffe. Der Altbestand wird parallel schrittweise entkoppelt, ersetzt oder neu aufgebaut – je nach Risiko und Wertbeitrag.

Dieser Pfad ist bewusst pragmatisch: Er setzt keine vollständige Systemablösung voraus, erlaubt inkrementelle Modernisierung und schützt gleichzeitig bestehende ABAP-Investitionen. Für viele Unternehmen ist er der realistischere Einstiegspunkt.

 

Praxisbeispiel: Freigabelogik ohne Clean-Core-Bruch

Ein konkretes Szenario aus der Praxis: Der Standard-Freigabeprozess für Bestellungen reicht nicht aus. Ab 50.000 € soll automatisch an den VP eskaliert werden, ab 100.000 € an den CFO. In klassischen Systemen wäre das oft als enger Eingriff in den Kern umgesetzt worden – mit allen bekannten Konsequenzen für Upgrades und Wartbarkeit.

Mit RAP lässt sich dieselbe Anforderung sauber als Erweiterung modellieren: Bestelldaten werden über eine freigegebene Schnittstelle konsumiert, eine Determination ermittelt die Freigabestufe anhand des Bestellwerts, eine Validation prüft die Vollständigkeit der Genehmigungskette, und über eine Action („Send for Approval“) wird der Workflow- oder API-Call ausgelöst. Die Fachlogik bleibt nachvollziehbar, testbar und upgrade-sicher – unabhängig davon, ob die Umsetzung side-by-side auf BTP oder on-stack im bestehenden S/4HANA erfolgt.

 

Worauf es beim Einstieg ankommt

Der Umstieg auf ABAP Cloud ist weniger eine Frage neuer Transaktionen als vielmehr von Architektur- und Engineering-Disziplin. Vier Stellschrauben sind dabei entscheidend:

• API-Disziplin: Released APIs statt interner Zugriffe – konsequent und von Beginn an. Die Custom Code Migration Worklist und der Compatibility Check in ADT helfen dabei, bestehenden Code systematisch auf API-Konformität zu prüfen.
• RAP-Patterns: Behavior Definitions, Validations, Actions, Determinations und Draft-Handling als Standard nutzen – nicht als Sonderfall. Managed Scenarios mit EML (Entity Manipulation Language) als Regelfall, Unmanaged nur bei begründeter Notwendigkeit.
• Qualitätssicherung: ABAP Unit Tests, ATC-Prüfungen (ABAP Test Cockpit) mit aktiviertem Cloud-Regelwerk, Code Reviews und automatisierte CI/CD-Checks als fester Bestandteil des Entwicklungsprozesses – idealerweise ergänzt durch das CDS Test Double Framework für isolierte Modultests.
• Enablement-Pfad: Umstieg auf Eclipse ADT als Entwicklungsumgebung → Training (RAP Generator als schneller Einstieg) → Pilot-Use-Case mit RAP → interne Templates, Coding Guidelines und Referenzarchitekturen → schrittweise Skalierung ins Team.

Wer früh mit einem klar umrissenen Pilot-Use-Case startet und verbindliche Leitplanken setzt, kann bestehende ABAP-Kompetenz sehr effektiv in moderne Clean-Core-Fähigkeit überführen – ohne das Team zu überfordern oder laufende Projekte zu gefährden.