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

Kaum eine Programmiersprache wurde so oft totgesagt 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 Sie aus zwanzig Jahren ECC kennen. Das Regelwerk heisst ABAP Cloud, der Spitzname Embedded Steampunk, und richtig eingesetzt ist es das präziseste Erweiterungswerkzeug, das die Public Cloud bietet. In unseren Projekten scheitert der Einstieg selten an der Technik. Er scheitert an den Begriffen.

Kurzfassung: S/4HANA Public Cloud hat drei Erweiterungsebenen: Key-User-Extensibility im Fiori-UI, Developer Extensibility mit ABAP Cloud im System selbst (Embedded Steampunk) und Side-by-Side-Erweiterungen auf SAP BTP. ABAP Cloud heisst: nur freigegebene APIs, RAP als Programmiermodell und die ABAP Development Tools in Eclipse. Beginnen Sie auf der tiefsten Ebene, die die Anforderung löst, und prüfen Sie früh, ob das Objekt, das Sie erweitern wollen, freigegeben ist.

Zuerst die Begriffe sortieren

Es gibt drei Erweiterungsebenen in und um S/4HANA Public Cloud, und sie werden in Workshops mit bemerkenswerter Zuverlässigkeit verwechselt:

Key-User-Extensibility ist die unterste Sprosse: eigene Felder, kleine Logikbausteine und angepasste Bildschirme, direkt im Fiori-UI und ohne Entwicklungsumgebung. Ein versierter Power-User aus dem Fachbereich kommt hier erstaunlich weit.

Developer Extensibility, auch Embedded Steampunk genannt, ist echtes ABAP in S/4HANA Public Cloud selbst, im Entwicklungssystem der Drei-System-Landschaft. Gleicher Stack, gleiche Datenbank, voller Editor, aber unter dem Regelwerk von ABAP Cloud. SAP beschreibt das in der Hilfe zur Developer Extensibility in S/4HANA Cloud Public Edition.

Side-by-Side-Steampunk ist die SAP BTP ABAP Environment: eine eigene ABAP-Plattform auf SAP BTP mit eigener Datenbank, entkoppelt vom ERP. Die Kommunikation läuft ausschliesslich über APIs.

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

Was ABAP Cloud in der Praxis bedeutet

ABAP Cloud ist kein neues ABAP, sondern eine geregelte Teilmenge mit hartem Zaun. Vier Dinge sollten Sie vor der ersten Codezeile verinnerlichen:

• Nur freigegebene Objekte und APIs sind erreichbar. Kein direktes SELECT auf nicht freigegebene Tabellen, keine User-Exits, keine Modifikation von SAP-Code. Was SAP nicht als freigegeben markiert hat, existiert für Ihren Code 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 kennt, kennt Embedded Steampunk.
• Entwickelt wird in Eclipse. Die ABAP Development Tools (ADT) sind die Entwicklungsumgebung. Eine SE80 gibt es in der Public Cloud nicht, und niemand vermisst sie lange.
• Transporte laufen über Softwarekomponenten durch die Drei-System-Landschaft: Entwickler geben sie aus den ADT frei, und sie werden mit der App Import Collection ins Test- und Produktivsystem importiert.

Die Entscheidungsleiter aus unseren Projekten

Für die Frage, auf welcher Ebene eine Anforderung landet, hat sich eine einfache Leiter bewährt. Man beginnt unten und steigt nur höher, wenn es nicht anders geht:

1. Zuerst Key-User. Erstaunlich viel passt hierher: zusätzliche Felder auf Belegen, Feldsteuerungen, kleine Validierungen, angepasste Layouts. Wer diese Sprosse überspringt, baut Entwicklerlösungen für Konfigurationsprobleme und bezahlt sie doppelt.
2. Embedded Steampunk, wenn Logik im Stack laufen muss. Ermittlungen 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 und eigenem Releaserhythmus oder Szenarien, die Daten aus mehreren Systemen aggregieren. Das gehört neben das ERP, nicht hinein; siehe SAP BTP bei Spadoom.

Die Leiter klingt trivial. Sie spart trotzdem in jedem Projekt Wochen, weil sie die Diskussion von «was wäre schön» zu «was ist nötig» verschiebt.

Drei Dinge, die wir in jedes Projekt mitbringen

Der Clean-Core-Entscheidungsbaum, eine Seite, erste Woche. Zusammen mit der IT des Kunden zeichnen wir in der ersten Projektwoche einen Entscheidungsbaum: Welche Anforderung landet auf welcher Ebene, nach welchen Kriterien? Eine A4-Seite erledigt die meisten späteren Architekturdebatten, bevor sie beginnen. Sie kostet einen halben Tag.

Die Liste der freigegebenen APIs früh prüfen. Die Lücken entscheiden die Architektur, nicht die Wünsche. Ob das Objekt, das Sie erweitern wollen, freigegebene APIs, BAdIs und CDS-Views mitbringt, klären Sie am zweiten Tag, nicht im fünften Sprint. Wir haben Vorhaben gesehen, die drei Wochen lang als Embedded-Steampunk-Lösung geplant wurden, bis jemand nachschlug und feststellte, dass das Zielobjekt nicht freigegeben war.

Release-Upgrades einfach durchlaufen lassen. S/4HANA Public Cloud spielt Release-Upgrades nach dem Zeitplan von SAP ein. ABAP-Cloud-Code auf freigegebenen APIs übersteht sie, ohne dass ihn jemand anfasst, weil freigegebene APIs Verträge sind, die SAP stabil hält. Nach Jahren von Upgrade-Projekten mit SPAU-Listen liest sich der Zaun um ABAP Cloud wie ein Feature.

Die Grenzen

Modifikationen an SAP-Objekten gibt es nicht, und nicht alles, was Sie aus ECC kennen, ist freigegeben: Einige klassische BAPIs und Funktionsbausteine fehlen noch auf der Freigabeliste.

Stossen Sie auf eine harte Lücke, gibt es einen bewährten Weg: bei SAP einen Influence Request einreichen und in der Zwischenzeit eine Side-by-Side-Brücke auf BTP bauen, die zurückgebaut wird, sobald SAP das Benötigte freigibt. Kein angenehmer Moment, aber ein planbarer. Unschön wird es nur, wenn Sie die Lücke erst im Integrationstest entdecken.

Diese Entscheidungen früh richtig zu treffen, ist Teil dessen, was das S/4HANA Readiness Assessment abdeckt. Erweiterungen bleiben selten im ERP: Dieselben Clean-Core-Regeln gelten für die CRM-Seite des integrierten Stacks aus S/4HANA Public Cloud und Sales Cloud V2, und unser Leitfaden zu Clean Core mit SAP CAP zeigt das Gegenstück auf BTP. Wenn Sie Implementierungspartner vergleichen, lesen Sie die besten SAP-S/4HANA-Public-Cloud-Partner in der Schweiz und unseren Leitfaden zum besten SAP-Partner für Cloud ERP und CRM in der Schweiz.

Häufige Fragen

Ist ABAP in S/4HANA Public Cloud tot?

Nein. ABAP ist Teil von S/4HANA Public Cloud, als ABAP Cloud mit dem ABAP RESTful Application Programming Model (RAP) und einem klaren Regelwerk: nur freigegebene APIs, keine Modifikationen. Weg sind Modifikationen und ungezügelte Z-Programme, und genau das hält die Upgrades ereignislos.

Müssen erfahrene ABAP-Entwickler komplett umlernen?

Umlernen ja, komplett nein. Die Sprache bleibt ABAP, die Denkweise ändert sich: RAP statt Reports, freigegebene APIs statt direkter Tabellenzugriffe, die Eclipse-basierten ABAP Development Tools statt SE80. Nach unserer Erfahrung ist das eine fokussierte Einarbeitung von Wochen, sofern jemand mit RAP-Praxis die ersten Objekte begleitet.

Wo lebt der Code?

Im Entwicklungssystem Ihrer Drei-System-Landschaft von S/4HANA Public Cloud, organisiert in Softwarekomponenten. Entwickler geben Transporte aus den ABAP Development Tools frei, und die Erweiterungen werden mit der App Import Collection ins Test- und danach ins Produktivsystem importiert. Eine eigene Infrastruktur ist nicht nötig.

---

Sie planen Erweiterungen in S/4HANA Public Cloud und wollen die Architekturfrage beantwortet haben, bevor es teuer wird? Wir bringen den Entscheidungsbaum mit. Sprechen Sie mit unserem Team.