ABAP lebt: Embedded Steampunk in S/4HANA Public Cloud richtig einsetzen

Kaum eine Sprache wurde so oft beerdigt wie ABAP. Und kaum eine lebt so zuverlässig weiter. In SAP S/4HANA Public Cloud ist sie zurück, allerdings nicht als das ABAP der User-Exits und Z-Reports, das man aus zwanzig Jahren ECC kennt. ABAP Cloud heisst das Regelwerk, Embedded Steampunk der Spitzname, und richtig eingesetzt ist es das präziseste Erweiterungswerkzeug, das die Public Cloud zu bieten hat. In unseren Projekten scheitert der Einstieg selten an der Technik. Er scheitert an den Begriffen.

Erst die Begriffe sortieren

Rund um S/4HANA Public Cloud existieren drei Erweiterungsebenen, und sie werden in Workshops verlässlich durcheinandergebracht:

Key-User-Extensibility ist die unterste Stufe: eigene Felder, kleine Logik-Snippets, angepasste Oberflächen, alles direkt in der Fiori-Oberfläche und ohne Entwicklungsumgebung. Ein befähigter Fachbereichs-Power-User kommt hier weit, ganz ohne Entwickler.

Developer-Extensibility, alias Embedded Steampunk, ist echtes ABAP im Entwicklungs-Tenant des S/4HANA-Public-Cloud-Systems selbst. Gleicher Stack, gleiche Datenbank, voller Editor. Aber unter dem Regelwerk von ABAP Cloud, dazu gleich mehr.

Side-by-Side-Steampunk ist das BTP ABAP Environment: eine eigenständige ABAP-Plattform auf der SAP BTP, mit eigener HANA-Datenbank, getrennt vom ERP. Die Kommunikation läuft ausschliesslich über APIs.

Wer side-by-side lieber ohne ABAP baut, dem steht auf der BTP auch Cloud Foundry offen; wie das aussieht, haben wir in einem eigenen Beitrag beschrieben.

Was ABAP Cloud konkret bedeutet

ABAP Cloud ist kein neues ABAP, sondern eine Teilmenge mit hartem Zaun. Vier Dinge sollte man verinnerlicht haben, bevor die erste Zeile Code entsteht:

• Nur freigegebene Objekte und APIs sind erreichbar. Kein direktes SELECT auf unfreigegebene Tabellen, keine User-Exits, keine Modifikation von SAP-Code. Was SAP nicht als released markiert hat, existiert für Ihren Code schlicht nicht.
• RAP ist das Programmiermodell. Das ABAP RESTful Application Programming Model strukturiert alles: CDS-Views als Datenmodell, Behavior Definitions für die Logik, Service Bindings für die Aussenwelt. Wer RAP beherrscht, beherrscht Embedded Steampunk.
• Entwickelt wird in Eclipse. Die ABAP Development Tools (ADT) sind die einzige IDE. Eine SE80 gibt es in der Public Cloud nicht, und niemand vermisst sie lange.
• Transportiert wird über Software Components auf gCTS-Basis, durch die drei Systeme DEV → TEST → PROD. Git-basierte Versionierung inklusive, ein echter Fortschritt gegenüber jedem klassischen Transportwesen.

Die Entscheidungsleiter aus unseren Projekten

Bei der Frage, welche Ebene ein Requirement bekommt, hat sich eine einfache Leiter bewährt. Man steigt unten ein und klettert nur weiter, wenn es nicht anders geht:

1. Key-User zuerst. Erstaunlich viel passt hier hinein: Zusatzfelder auf Belegen, Feldkontrollen, kleine Validierungen, angepasste Layouts. Wer diese Stufe überspringt, baut Entwicklerlösungen für Konfigurationsprobleme und zahlt sie doppelt.
2. Embedded Steampunk, wenn Logik im Stack laufen muss. Determinierungen und Validierungen auf freigegebenen Business-Objekten, eigene Fiori-Apps auf eigenen RAP-Objekten, Logik, die synchron im Belegfluss sitzt. Genau dafür ist es gebaut.
3. BTP side-by-side, wenn es ein eigenes Produkt ist. Anwendungen mit eigenem Lebenszyklus, eigenem Release-Rhythmus, oder Szenarien, die Daten aus mehreren Systemen aggregieren. Das gehört neben das ERP, nicht hinein.

Die Leiter klingt banal. Sie erspart trotzdem in jedem Projekt Wochen, weil sie die Diskussion von «was wäre cool» auf «was ist nötig» dreht.

Drei Dinge, die wir jedem Projekt mitgeben

Der Clean-Core-Entscheidungsbaum, eine Seite, Woche eins. Gemeinsam mit der IT des Kunden zeichnen wir in der ersten Projektwoche einen Entscheidungsbaum: Welche Anforderung landet auf welcher Ebene, und nach welchen Kriterien? Eine A4-Seite, laminierbar. Diese eine Seite beantwortet jede künftige Architekturdebatte, bevor sie entsteht. Der Aufwand liegt bei einem halben Tag; der Ertrag ist jede Eskalationsrunde, die nie stattfindet.

Die Released-API-Liste früh prüfen. Nicht die Wünsche entscheiden die Architektur, sondern die Lücken. Ob das Objekt, das Sie erweitern wollen, freigegebene APIs, BAdIs und CDS-Views mitbringt, klärt man an Tag zwei, nicht in Sprint fünf. Wir haben Vorhaben gesehen, die drei Wochen lang als Embedded-Steampunk-Lösung geplant wurden, bis jemand nachschaute und feststellte: Das Zielobjekt ist nicht freigegeben. Zurück auf Feld eins.

Die Quartals-Upgrades laufen einfach durch. S/4HANA Public Cloud spielt Release-Upgrades automatisch ein. ABAP-Cloud-Code auf freigegebenen APIs übersteht sie, ohne dass jemand ihn anfasst; freigegebene APIs sind Verträge, und SAP hält sie stabil. Das ist der ganze Sinn der Übung. Wer das einmal erlebt hat, nach Jahren von Upgrade-Projekten mit SPAU-Listen, versteht den Zaun um ABAP Cloud plötzlich als Feature.

Die ehrlichen Grenzen

Modifikationen an SAP-Objekten gibt es nicht. Punkt, keine Ausnahme, kein Trick. Und nicht alles, was man aus ECC kennt, ist freigegeben: Manche klassischen BAPIs und Funktionsbausteine fehlen in der Released-Liste bis heute.

Trifft man auf eine harte Lücke, gibt es einen erprobten Weg: einen Influence Request bei SAP einstellen (die Release-Zyklen sind kurz, die Chancen real, wir haben Freigaben innert zweier Releases erlebt) und in der Zwischenzeit eine Side-by-Side-Brücke auf der BTP bauen, die später zurückgebaut wird. Kein schöner Moment, aber ein planbarer. Schlimm wird es nur, wenn man die Lücke erst im Integrationstest entdeckt, siehe oben.

Häufige Fragen

Ist ABAP in der Public Cloud tot?

Nein, das Gegenteil ist der Fall. ABAP ist in S/4HANA Public Cloud als ABAP Cloud zurück: modern, mit RAP als Programmiermodell und einem klaren Regelwerk. Was verschwunden ist, sind Modifikationen und wilde Z-Programme. Man kann das Verlust nennen. Wir nennen es Disziplin, und die Upgrade-Bilanz gibt dieser Sicht recht.

Müssen langjährige ABAP-Entwickler komplett umlernen?

Umlernen ja, komplett nein. Die Sprache bleibt ABAP, die Denkweise ändert sich: RAP statt Report, freigegebene APIs statt Direktzugriff, Eclipse statt SE80. Nach unserer Erfahrung ist das ein fokussierter Ramp-up von Wochen, nicht Monaten, vorausgesetzt jemand mit RAP-Praxis begleitet die ersten Objekte.

Wo lebt der Code eigentlich?

Im Entwicklungs-Tenant der eigenen S/4HANA-Public-Cloud-Instanz, organisiert in Software Components. Von dort wandert er gCTS-basiert und versioniert durch DEV → TEST → PROD. Kein separates System, keine eigene Infrastruktur, aber sauber getrennt vom SAP-Standard.

Sie planen Erweiterungen in S/4HANA Public Cloud und wollen die Architekturfrage beantworten, bevor sie teuer wird? Wir bringen den Entscheidungsbaum mit. Sprechen Sie mit uns.