ABAP Cloud oder klassisches ABAP: was in welcher Lage offensteht
Die Einschränkung ist nicht der Sprachumfang, sondern der Zugriff auf fremde Objekte. Wer das verstanden hat, schätzt den Umbau realistisch statt nach Bauchgefühl.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Zwei Lager, eine Frage, und beide Antworten sind zu grob
In den meisten Entwicklungsteams gibt es zu diesem Thema zwei Haltungen. Die eine sagt, ABAP Cloud sei die Zukunft und alles andere Altlast, und fordert den vollständigen Umbau. Die andere sagt, im eigenen System liefe alles weiter wie bisher, und wartet ab. Beide Haltungen ersparen die Arbeit, die eigentlich ansteht, nämlich für jedes Vorhaben einzeln zu entscheiden, welcher Weg der richtige ist, und diese Entscheidung begründen zu können.
Der Kern des Missverständnisses liegt darin, was ABAP Cloud überhaupt einschränkt. Es ist nicht in erster Linie der Sprachumfang, auch wenn ABAP for Cloud Development tatsächlich nur eine Teilmenge des ABAP-Sprachumfangs abdeckt. Der spürbare Unterschied ist der Zugriff: Ein fremdes Objekt ist nur dann nutzbar, wenn es als freigegebene API mit einem Release-Kontrakt klassifiziert ist, in der Regel dem Kontrakt C1. Genau das trifft Code, der über Jahre gewachsen ist und beiläufig auf Dutzende Objekte zugreift, deren Herkunft niemand mehr prüft.
Und dann gibt es das dritte Missverständnis, das am meisten Zeit kostet: die Annahme, in ABAP Cloud sei alles verboten, was nicht von SAP kommt. Das stimmt nicht. Objekte im selben Softwarepaket bleiben zugänglich, eure eigenen Bausteine also auch. Wer das nicht weiß, schätzt den Umbau um ein Vielfaches zu hoch und entscheidet sich deshalb gegen einen Weg, der in Wahrheit gangbar gewesen wäre.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die Kriterien, an denen die Wahl tatsächlich hängt
Verglichen werden hier keine Sprachumfänge aus einer Tabelle, sondern die Eigenschaften, die sich in eurem Projekt bemerkbar machen: Zugriff auf fremde Objekte, Verhalten beim Upgrade, Verfügbarkeit, Einarbeitung, Eignung für Oberflächen und Services und der Aufwand am Bestand.
ABAP Cloud
das Entwicklungsmodell für clean-core-konforme, cloudfähige Anwendungen auf SAP BTP, SAP S/4HANA Cloud und SAP S/4HANA, technisch getragen von ABAP for Cloud Development
Klassisches ABAP
die gewohnte Entwicklung im eigenen System mit vollem Sprachumfang und ohne Einschränkung des Zugriffs auf fremde Objekte
| Entscheidungsfrage | ABAP Cloud | Klassisches ABAP |
|---|---|---|
| Auf welche Objekte darf der Code zugreifen? | Schwäche Ein fremdes Objekt ist nur nutzbar, wenn es als freigegebene API mit einem Release-Kontrakt klassifiziert ist, in der Regel C1. Objekte im selben Softwarepaket bleiben zugänglich, alles andere nicht. Für gewachsenen Code ist das die Stelle, an der der Umbau entsteht. | Stärke Der Zugriff ist nicht eingeschränkt, alles im System steht zur Verfügung. Das ist der Grund, warum sich damit fast jede Anforderung schnell umsetzen lässt, und zugleich der Grund für den Zustand, den Clean Core adressiert. |
| Wie verhält sich der Code beim nächsten Upgrade? | Stärke Weil nur Objekte mit Release-Kontrakt benutzt werden, gibt es eine Aussage darüber, was sich ändern darf und was nicht. Genau dafür ist das Modell gebaut, und genau das macht die Aufwandsschätzung für ein Upgrade überhaupt möglich. | Kommt darauf an Es gibt keine Zusage, und ohne Zusage lässt sich der Aufwand eines Upgrades nicht schätzen. Wer sich an vorgesehene Wege hält, kommt weit. Wer auf interne Objekte zugreift, hat keine Zusage, und interne Objekte dürfen sich ändern, ohne dass das angekündigt werden müsste. |
| Wo steht der Weg überhaupt offen? | Stärke SAP nennt ausdrücklich SAP BTP, SAP S/4HANA Cloud und SAP S/4HANA. Damit ist es der einzige Weg, der in allen drei Umgebungen gleich funktioniert, und der einzige, den ihr nur einmal lernen müsst. | Kommt darauf an Im eigenen System und in der Private-Variante ist es die gewohnte Arbeitsweise. Wer damit eine Erweiterung baut, sollte aber wissen, dass er sie beim Wechsel der Betriebsform nicht einfach mitnimmt. |
| Wie schnell ist ein eingespieltes Team produktiv? | Kommt darauf an Die Sprache ist vertraut, das Vorgehen nicht. Core Data Services, Verhaltensdefinitionen und Geschäftsobjekte sind eine andere Denkweise als ein Modulpool mit Bildschirmbildern, und die Umstellung braucht echte Wochen an Projektarbeit. | Stärke Ein Team, das seit Jahren so arbeitet, liefert ab dem ersten Tag. Das ist der ehrliche Vorteil des gewohnten Wegs, und er ist der Grund, warum er unter Termindruck immer wieder gewinnt. |
| Wie gut passt es zu Fiori-Oberflächen und Services? | Stärke Das RESTful Application Programming Model ist ein wesentlicher Bestandteil von ABAP Cloud und dient genau dem Bau transaktionaler SAP-Fiori-Apps, OData-basierter Services und Erweiterungen. Für diese Aufgaben ist es der vorgesehene Weg. | Kommt darauf an Machbar, aber mit deutlich mehr Handarbeit, und das Ergebnis fügt sich weniger selbstverständlich in die Oberfläche ein. Für Berichte und Hintergrundverarbeitung dagegen bleibt es ein sehr direkter Weg. |
| Was kostet der Umbau des vorhandenen Bestands? | Schwäche Jeder Zugriff auf ein nicht freigegebenes Objekt muss ersetzt werden, und bei gewachsenem Code sind das viele. Der Aufwand ist real, er lässt sich aber vorher ermitteln, und das ist der Unterschied zu einer Schätzung nach Gefühl. | Stärke Es fällt kein Umbau an, der Bestand läuft weiter. Der Preis steht auf einer anderen Rechnung: Er taucht bei jedem Upgrade auf und wächst mit jedem Jahr, in dem weiter so gebaut wird. |
Auf welche Objekte darf der Code zugreifen?
Ein fremdes Objekt ist nur nutzbar, wenn es als freigegebene API mit einem Release-Kontrakt klassifiziert ist, in der Regel C1. Objekte im selben Softwarepaket bleiben zugänglich, alles andere nicht. Für gewachsenen Code ist das die Stelle, an der der Umbau entsteht.
Der Zugriff ist nicht eingeschränkt, alles im System steht zur Verfügung. Das ist der Grund, warum sich damit fast jede Anforderung schnell umsetzen lässt, und zugleich der Grund für den Zustand, den Clean Core adressiert.
Wie verhält sich der Code beim nächsten Upgrade?
Weil nur Objekte mit Release-Kontrakt benutzt werden, gibt es eine Aussage darüber, was sich ändern darf und was nicht. Genau dafür ist das Modell gebaut, und genau das macht die Aufwandsschätzung für ein Upgrade überhaupt möglich.
Es gibt keine Zusage, und ohne Zusage lässt sich der Aufwand eines Upgrades nicht schätzen. Wer sich an vorgesehene Wege hält, kommt weit. Wer auf interne Objekte zugreift, hat keine Zusage, und interne Objekte dürfen sich ändern, ohne dass das angekündigt werden müsste.
Wo steht der Weg überhaupt offen?
SAP nennt ausdrücklich SAP BTP, SAP S/4HANA Cloud und SAP S/4HANA. Damit ist es der einzige Weg, der in allen drei Umgebungen gleich funktioniert, und der einzige, den ihr nur einmal lernen müsst.
Im eigenen System und in der Private-Variante ist es die gewohnte Arbeitsweise. Wer damit eine Erweiterung baut, sollte aber wissen, dass er sie beim Wechsel der Betriebsform nicht einfach mitnimmt.
Wie schnell ist ein eingespieltes Team produktiv?
Die Sprache ist vertraut, das Vorgehen nicht. Core Data Services, Verhaltensdefinitionen und Geschäftsobjekte sind eine andere Denkweise als ein Modulpool mit Bildschirmbildern, und die Umstellung braucht echte Wochen an Projektarbeit.
Ein Team, das seit Jahren so arbeitet, liefert ab dem ersten Tag. Das ist der ehrliche Vorteil des gewohnten Wegs, und er ist der Grund, warum er unter Termindruck immer wieder gewinnt.
Wie gut passt es zu Fiori-Oberflächen und Services?
Das RESTful Application Programming Model ist ein wesentlicher Bestandteil von ABAP Cloud und dient genau dem Bau transaktionaler SAP-Fiori-Apps, OData-basierter Services und Erweiterungen. Für diese Aufgaben ist es der vorgesehene Weg.
Machbar, aber mit deutlich mehr Handarbeit, und das Ergebnis fügt sich weniger selbstverständlich in die Oberfläche ein. Für Berichte und Hintergrundverarbeitung dagegen bleibt es ein sehr direkter Weg.
Was kostet der Umbau des vorhandenen Bestands?
Jeder Zugriff auf ein nicht freigegebenes Objekt muss ersetzt werden, und bei gewachsenem Code sind das viele. Der Aufwand ist real, er lässt sich aber vorher ermitteln, und das ist der Unterschied zu einer Schätzung nach Gefühl.
Es fällt kein Umbau an, der Bestand läuft weiter. Der Preis steht auf einer anderen Rechnung: Er taucht bei jedem Upgrade auf und wächst mit jedem Jahr, in dem weiter so gebaut wird.
Was passt wann
- Wenn etwas Neues entsteht, das eine Oberfläche oder einen Service braucht
- nimm ABAP Cloud mit RAP, denn genau dafür ist das Modell gebaut, und ein Neubau trägt keine Altlasten.
- Wenn ein gewachsener Bestand gepflegt wird und die Anforderung klein ist
- bleib zunächst auf dem gewohnten Weg, sortier das Objekt aber nach seinem Clean-Core-Level ein, damit die Schätzung für das nächste Upgrade stimmt.
- Wenn ein Wechsel der Betriebsform absehbar ist
- baue ab sofort nichts Neues mehr auf nicht freigegebene Objekte, denn genau dieser Code verursacht den Aufwand, den ihr später als Projekt bezahlt.
Sechs Fragen, und der Weg steht fest
- 01 Auf welche fremden Objekte greift euer Code zu, und sind sie freigegeben?
- 02 Wie viel davon liegt im eigenen Paket und ist damit ohnehin unproblematisch?
- 03 Entsteht eine transaktionale App oder ein Service? Dann ist RAP der vorgesehene Weg.
- 04 Baut ihr neu oder baut ihr um? Die Antwort verschiebt den Aufwand um eine Größenordnung.
- 05 In welcher Betriebsform läuft das System, und was steht dort überhaupt offen?
- 06 Wie viel Einarbeitung braucht das Team, und steht sie sichtbar im Plan?
Danach kannst du den Umbau schätzen statt ihn zu fürchten
Die Entscheidung fällt nicht für das ganze Haus, sondern für ein Vorhaben. Sechs Punkte reichen, um sie in einer Sitzung zu treffen, und fünf davon lassen sich mit Informationen aus dem eigenen System beantworten.
Den Zugriff prüfen, nicht die Sprache
Die entscheidende Frage lautet nicht, welche Anweisungen fehlen, sondern auf welche fremden Objekte euer Code zugreift und wie viele davon als freigegebene API mit Release-Kontrakt klassifiziert sind. Danach steht der Umfang des Umbaus.
Eigene Objekte aus der Rechnung nehmen
Objekte im selben Softwarepaket bleiben nutzbar. Was ihr selbst gebaut habt und selbst pflegt, ist nicht das Problem. Wer diesen Punkt übersieht, schätzt den Aufwand systematisch zu hoch und trifft die Entscheidung auf falscher Grundlage.
RAP als das begreifen, wofür ABAP Cloud gebaut ist
Das ABAP RESTful Application Programming Model ist ein wesentlicher Bestandteil von ABAP Cloud und dient dem Bau transaktionaler SAP-Fiori-Apps, OData-basierter Services und Erweiterungen. Wer eine Liste im Batch schreiben will, arbeitet gegen das Modell an.
Zwischen Neubau und Bestand trennen
Für etwas Neues ist die Frage leicht, denn dort entstehen keine Altlasten. Beim Bestand geht es um eine Reihenfolge, und die richtet sich nach Wirkung: zuerst das, was bei jedem Upgrade Arbeit macht, danach das, was fachlich wichtig ist.
Die Betriebsform als Rahmen lesen
ABAP Cloud steht auf SAP BTP, in SAP S/4HANA Cloud und in SAP S/4HANA zur Verfügung. Wo ihr betreibt, entscheidet mit darüber, ob der klassische Weg überhaupt noch eine Option ist oder nur noch eine Gewohnheit.
Die Einarbeitung als eigenen Posten einplanen
Ein Team, das ABAP seit Jahren schreibt, ist mit RAP nicht nach einer Woche produktiv. Core Data Services, Verhaltensdefinitionen und Geschäftsobjekte sind eine andere Denkweise, und dieser Aufwand gehört sichtbar in den Plan statt in die Abendstunden.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Was ABAP Cloud technisch wirklich einschränkt
ABAP Cloud wirkt über eingeschränkte Sprachversionen. ABAP for Cloud Development deckt nur eine Teilmenge des ABAP-Sprachumfangs ab, daneben steht ABAP for Key Users für die Erweiterungen, die von Fachanwendern gepflegt werden. Die Einschränkung des Sprachumfangs klingt zunächst dramatisch, ist es in der Praxis aber selten, denn was wegfällt, sind überwiegend Konstrukte, die man in neuem Code ohnehin nicht mehr schreibt.
Die Einschränkung, die tatsächlich weh tut, ist eine andere: der Zugriff auf Objekte. Ein Objekt ist nur dann nutzbar, wenn es als freigegebene API mit einem Release-Kontrakt klassifiziert ist, in der Regel dem Kontrakt C1. Das betrifft Tabellen, Funktionsbausteine, Klassen und Views gleichermaßen. Für gewachsenen Code ist das der Punkt, an dem der Umbau entsteht, denn solcher Code greift beiläufig auf Objekte zu, deren Herkunft und Zusagen niemand mehr prüft.
Entscheidend für eine ehrliche Schätzung ist der zweite Teil der Regel: Objekte im selben Softwarepaket bleiben zusätzlich zugänglich. Eure eigenen Bausteine, eure eigenen Datenstrukturen, eure eigenen Klassen im eigenen Paket sind also nicht betroffen. Wer diese Hälfte übersieht, kommt zu der Einschätzung, ABAP Cloud verbiete praktisch alles, und diese Einschätzung ist der häufigste Grund, warum Teams die Frage gar nicht erst ernsthaft prüfen.
RAP ist das, wofür ABAP Cloud gebaut wurde
Das ABAP RESTful Application Programming Model, kurz RAP, ist ein wesentlicher Bestandteil von ABAP Cloud. SAP beschreibt es als das Herzstück für den Bau transaktionaler SAP-Fiori-Apps, OData-basierter Services und Erweiterungen. Grundlage sind Core Data Services für das Datenmodell, Verhaltensdefinitionen für das, was mit den Daten geschehen darf, und Geschäftsobjekte als die Einheit, um die herum alles gebaut wird.
Das ist eine andere Denkweise als die gewohnte. Im klassischen Weg schreibst du ein Programm, das Daten liest, verarbeitet und ausgibt, und die Reihenfolge steht in deinem Code. In RAP beschreibst du zuerst, was es gibt und was damit erlaubt ist, und die Ablaufsteuerung kommt aus dem Modell. Für ein Team, das seit Jahren Reports und Modulpools schreibt, ist diese Umstellung der eigentliche Aufwand, größer als jede fehlende Anweisung im Sprachumfang.
Umgekehrt heißt das auch: Wer eine Aufgabe hat, die nicht transaktional ist, arbeitet mit RAP gegen das Modell an. Eine nächtliche Verarbeitung großer Datenmengen, eine Auswertung, eine Schnittstelle in ein Fremdsystem sind Aufgaben, für die es andere Bausteine gibt. Die Wahl des Werkzeugs richtet sich nach der Aufgabe, und der Satz, in ABAP Cloud werde jetzt alles mit RAP gebaut, führt in die Irre.
Was in welcher Lage offensteht
SAP nennt für ABAP Cloud ausdrücklich drei Umgebungen: SAP BTP, SAP S/4HANA Cloud und SAP S/4HANA. Es ist damit der einzige Weg, der überall gleich funktioniert. Wenn ihr euren Leuten nur ein Modell beibringen wollt und nicht wisst, wo ihr in fünf Jahren betreibt, ist das ein starkes Argument, unabhängig von jeder Clean-Core-Diskussion.
Im eigenen System und in der Private-Variante bleibt die klassische Entwicklung daneben verfügbar. Das ist kein Schlupfloch, sondern der Grund, warum SAP im Clean-Core-Level-Konzept überhaupt Stufen für Erweiterungen beschreibt, die auf interne Objekte zugreifen oder mit nicht empfohlenen Techniken arbeiten: Es gibt sie, sie funktionieren, und sie sind vorhanden. Was sich ändert, ist der Preis, und der wird beim Upgrade fällig.
Praktisch führt das zu einer einfachen Aufteilung. Neues, das eine Oberfläche oder einen Service braucht, entsteht in ABAP Cloud mit RAP. Änderungen an vorhandenem Code bleiben zunächst dort, wo sie sind, bekommen aber eine Einordnung nach Clean-Core-Level. Und für alles, was neu entsteht, gilt eine einzige zusätzliche Regel: keine neuen Zugriffe auf nicht freigegebene Objekte. Diese Regel kostet heute wenig und erspart später sehr viel.
Den Bestand einschätzen, ohne ein Projekt daraus zu machen
Die Frage, wie teuer ein Umbau wird, lässt sich beantworten, und zwar ohne Beratungsvorhaben. Was gebraucht wird, ist eine Liste der eigenen Objekte und für jedes davon die Angabe, auf welche fremden Objekte es zugreift. Daraus ergibt sich, wie viele dieser Zugriffe auf freigegebene APIs gehen und wie viele nicht. Diese Zahl ist der Umfang des Umbaus, und sie ist deutlich kleiner als die Gesamtzahl der Objekte, weil die meisten Zugriffe sich auf wenige Stellen konzentrieren.
Die Reihenfolge der Bearbeitung sollte sich nicht nach Aufwand richten, sondern nach Wirkung. Ein Objekt, das bei jedem Upgrade angefasst werden muss, kostet euch bei jedem Release erneut. Ein Objekt, das seit vier Jahren unverändert läuft und nichts Kritisches anfasst, kostet euch gar nichts, auch wenn es formal auf einer niedrigen Stufe liegt. Wer nach der formalen Stufe sortiert statt nach der tatsächlichen Belastung, arbeitet die Liste in der teuersten aller Reihenfolgen ab.
Und dann gibt es die Objekte, deren beste Behandlung das Löschen ist. In jedem gewachsenen System liegt ein erheblicher Anteil Code, der seit Jahren nicht mehr aufgerufen wird. Bevor jemand ihn nach ABAP Cloud überträgt, lohnt die Frage, ob er noch gebraucht wird. Diese Prüfung ist die billigste Aufwandsreduzierung, die es in diesem Zusammenhang gibt, und sie wird fast immer übersprungen, weil sie sich nicht wie Fortschritt anfühlt.
Die Missverständnisse, die am meisten Zeit kosten
Das erste ist die Vorstellung, ABAP Cloud verbiete alles Eigene. Es verbietet den Zugriff auf fremde Objekte ohne Release-Kontrakt. Objekte im selben Softwarepaket bleiben zugänglich, und damit ist der eigene Bestand an Bausteinen und Klassen kein Hindernis. Wer das klarstellt, verändert die Diskussion im Team sofort, weil die geschätzte Größe der Aufgabe um ein Vielfaches sinkt.
Das zweite ist die Gleichsetzung von ABAP Cloud mit der Cloud als Betriebsform. Der Name legt das nahe, richtig ist es nicht: SAP nennt SAP S/4HANA ausdrücklich als eine der Umgebungen. Ihr könnt in eurem eigenen System nach diesem Modell entwickeln, ohne irgendetwas an eurem Betrieb zu ändern, und für viele Häuser ist genau das der sinnvolle erste Schritt.
Das dritte ist die Annahme, es handele sich um eine Entscheidung für das ganze Haus. Das ist sie nicht. Sie fällt für jedes Vorhaben einzeln, und sie fällt anders für einen Neubau als für eine Änderung am Bestand. Wer eine Grundsatzentscheidung sucht, wird sie nicht finden und verliert währenddessen die Zeit, in der er zwanzig einzelne Entscheidungen hätte treffen können.
Dazu passende Kurse
Weil sich der Weg über freigegebene Schnittstellen nur mit sauberer Objektorientierung gehen lässt, sind ABAP-Kurse von den Grundlagen bis zu ABAP Objects die Voraussetzung und nicht die Kür.
Und weil eine Erweiterung nur so gut ist wie das Verständnis des Prozesses darunter, gehören SAP-Kurse für den Systemzusammenhang um die Entwicklung in die Planung derselben Woche.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Häufige Fragen
Können wir in unserem eigenen System überhaupt ABAP Cloud nutzen?
Ist in ABAP Cloud alles verboten, was nicht von SAP kommt?
Müssen wir jetzt alles auf RAP umstellen?
Wie lange braucht ein erfahrenes ABAP-Team für die Umstellung?
Wie finden wir heraus, wie groß der Umbau bei uns wäre?
Quellen
- SAP: ABAP Cloud, das Entwicklungsmodell für clean-core-konforme Erweiterungen
- SAP: ABAP RESTful Application Programming Model (RAP)
- SAP: ABAP Versions and APIs (ABAP-Schlüsselwortdokumentation)
- SAP: Released APIs (ABAP-Schlüsselwortdokumentation)
- SAP News: Extend SAP S/4HANA Cloud the Right Way (Clean-Core-Level)
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem SAP-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Erst den Zugriff prüfen, dann über den Umbau reden
Wie objektorientiertes ABAP aussieht, das ohne Zugriff auf fremde Interna auskommt, arbeitest du bei cmt an eigenem Code durch und siehst dabei, wie klein der Umbau tatsächlich ist.