Key User, ABAP Cloud oder Side-by-Side: S/4HANA Public Cloud auf SAP BAIP erweitern

SAP S/4HANA Cloud Public Edition lässt sich auf drei Arten erweitern: mit Key User Extensibility im System, mit Developer Extensibility in ABAP Cloud im selben Stack und mit Side-by-Side-Erweiterungen auf der SAP Business AI Platform (BAIP), zu der seit Mai 2026 auch das frühere SAP BTP gehört. Side-by-Side ist die richtige Wahl, wenn die Erweiterung lose an das ERP gekoppelt ist: eigene Oberfläche, eigene Benutzer, eigener Release-Rhythmus oder Daten aus mehr als einem System.

TL;DR: Beginnen Sie mit den Key-User-Werkzeugen, wechseln Sie zu ABAP Cloud, wenn Logik in die ERP-Transaktion gehört, und gehen Sie Side-by-Side auf BAIP, wenn die Erweiterung ein kleines eigenes Produkt ist. Eine saubere Side-by-Side-App nutzt nur freigegebene APIs und Events, verbindet sich über ein Communication Arrangement und den Destination Service und meldet Benutzer über SAP Cloud Identity Services an. So bleibt sie auf Clean-Core-Stufe A, und S/4HANA-Upgrades laufen an ihr vorbei.

Mein Kollege Michael Suter hat das Side-by-Side-Muster mit einer kleinen Cloud-Foundry-App beschrieben, Sofiene Karaja den Weg im Stack mit Embedded Steampunk. Dieser Beitrag ist die Entscheidungshilfe dazwischen: welche Option, warum, und wie die Side-by-Side-Architektur darunter aussieht.

Die drei Erweiterungsoptionen in S/4HANA Public Cloud

Die SAP-Dokumentation zur Extensibility in S/4HANA Cloud Public Edition nennt drei Optionen und vergleicht sie in einer Tabelle. In den Worten von SAP ist Key User Extensibility für «smaller low/no-code extensions» gedacht, Developer Extensibility für «tightly coupled more complex extensions and apps» und Side-by-Side für «loosely coupled extensions and apps».

	Key User	Developer (ABAP Cloud)	Side-by-Side auf BAIP
Wo es läuft	In S/4HANA	In S/4HANA (ABAP Environment)	Auf SAP BAIP
Typischer Inhalt	Felder, Logik, CDS Views, Business Objects	RAP Business Objects, Validierungen, Fiori-Apps	Eigene Apps, Oberflächen, Workflows, Integrationen
Sprachen	Low Code, No Code	ABAP Cloud	Java, Node.js, ABAP
Kopplung	Eng	Eng	Lose
Voraussetzung	Key-User-Rollen	Drei-System-Landschaft	BAIP-Subaccount, Communication Arrangement

Key User Extensibility deckt mehr ab, als viele Teams erwarten. Zu den Key-User-Werkzeugen gehören Custom Fields, Datenquellen-Erweiterungen, Custom CDS Views, Custom Business Objects mit eigener Oberfläche, Custom Logic und Custom Analytical Queries, transportiert mit den Apps Export Software Collection und Import Collection.

Developer Extensibility bringt ABAP Cloud, das RESTful Application Programming Model und die ABAP Development Tools ins System. Eine Einschränkung entscheidet früh, ob sie überhaupt verfügbar ist: SAP schreibt, dass Developer Extensibility nur in einer Drei-System-Landschaft verfügbar ist, und sie nutzt eine für die Cloud optimierte Teilmenge von ABAP mit ausschliesslich freigegebenen SAP-Objekten.

Side-by-Side Extensibility läuft auf der Plattform neben dem ERP. Die SAP-Dokumentation zu Side-by-Side nennt sie lose gekoppelt, aber nahtlos integriert, und fügt eine Regel hinzu, die man vor der ersten Skizze kennen sollte: Eine Side-by-Side-App nutzt eigene UI-Services, nicht die UI-Services, die SAP für die eigenen Fiori-Apps ausliefert.

Alle drei Optionen lesen und schreiben über dasselbe Fundament, das virtuelle Datenmodell mit seinen CDS Views und freigegebenen APIs. Deshalb blockiert keine von ihnen ein Upgrade, solange Sie bei freigegebenen Objekten bleiben.

Clean Core: was «freigegeben» bringt

SAP hat das frühere Drei-Stufen-Modell im August 2025 zu vier Clean-Core-Stufen weiterentwickelt. Stufe A umfasst voll konforme Erweiterungen, die nur öffentlich freigegebene und stabile SAP-Schnittstellen nutzen; die Stufen B bis D erlauben schrittweise mehr internen Zugriff, und D gilt als nicht sauber. Das White Paper zu Clean Core Extensibility ordnet eine Side-by-Side-Erweiterung auf SAP BTP (heute Teil der SAP Business AI Platform) mit freigegebenen Schnittstellen der Stufe A zu, neben ABAP Cloud im Stack.

In S/4HANA Public Cloud ist die Wahl ohnehin enger als in einer Private Edition, weil es keinen Modifikationszugriff gibt. Die praktische Frage lautet also nicht «sauber oder nicht», sondern welche freigegebene Schnittstelle Sie nutzen und wo der Code lebt.

Wann Side-by-Side die richtige Wahl ist

Der Extension Architecture Guide von SAP liefert einen Entscheidungsrahmen. Verdichtet auf die Fragen, die wir in Workshops stellen:

Frage	Spricht für
Muss die Logik in derselben Transaktion wie der ERP-Beleg laufen?	ABAP Cloud
Viele Roundtrips oder grosse Datenmengen pro Benutzeraktion?	ABAP Cloud
Löst ein Feld, eine Regel oder eine Key-User-CDS-View das Problem?	Key User
Arbeiten externe Benutzer damit (Kunden, Partner, Aussendienst ohne S/4-Lizenz)?	Side-by-Side
Verbindet sie S/4HANA-Daten mit einem CRM, einem Webshop oder einem Drittsystem?	Side-by-Side
Braucht sie einen eigenen Release-Rhythmus oder eigene Skalierung, unabhängig von S/4HANA-Upgrades?	Side-by-Side
Ist das Team in Java, Node.js oder TypeScript stärker als in ABAP?	Side-by-Side
Gibt es keine Drei-System-Landschaft?	Key User oder Side-by-Side

Die letzte Zeile wird oft übersehen. Wer eine Zwei-System-Landschaft hat, hat keine Developer Extensibility; alles, was über Key-User-Werkzeuge hinausgeht, landet automatisch Side-by-Side.

Wie eine Side-by-Side-Architektur aussieht

Eine typische Side-by-Side-Erweiterung für S/4HANA Public Cloud hat fünf Schichten. Keine davon ist exotisch.

1. Anwendung: CAP auf Cloud Foundry oder Kyma

Die Entwicklerempfehlungen von SAP setzen auf zwei Programmiermodelle, ABAP Cloud und das SAP Cloud Application Programming Model (CAP). Auf dem Side-by-Side-Weg ist CAP meist das Rückgrat: Java mit Spring Boot oder Node.js mit JavaScript oder TypeScript. CAP lässt sich auf Cloud Foundry oder auf die Kyma Runtime deployen. Cloud Foundry ist der einfachere Start; Kyma lohnt sich, wenn Sie bereits Container betreiben oder Kubernetes-Funktionen brauchen.

2. Oberfläche und Einstieg

SAPUI5 oder SAP Fiori Elements für Apps, die sich wie S/4HANA anfühlen sollen, SAP Build Work Zone als Launchpad. S/4HANA kann seine Launchpad-Inhalte an SAP Build Work Zone übergeben, sodass Benutzer ERP-Apps und Erweiterungen nebeneinander sehen.

3. Freigegebene APIs über Communication Arrangements

Jede API im SAP Business Accelerator Hub für S/4HANA Cloud gehört zu mindestens einem Kommunikationsszenario. Um sie zu nutzen, legen Sie in S/4HANA einen Kommunikationsbenutzer, ein Kommunikationssystem und ein Communication Arrangement für dieses Szenario an. Passt kein Standardszenario, stellt die App Custom Communication Scenarios Ihre eigenen Custom CDS Views bereit. Ein Arrangement pro fachlichem Zweck hält Berechtigungen lesbar und den Rückbau einfach.

4. Events statt Polling

S/4HANA Public Cloud veröffentlicht Business Events über Enterprise Event Enablement. Konfiguriert mit dem Kommunikationsszenario SAP_COM_0092 gehen die Events an SAP Event Mesh, im Format CloudEvents. Eine Side-by-Side-App abonniert sie und reagiert, etwa wenn ein Kundenauftrag angelegt wird oder sich ein Geschäftspartner ändert, statt die API alle paar Minuten abzufragen. Das hält sie innerhalb der API-Limits und näher an der Echtzeit.

5. Identität und Authentifizierung

S/4HANA Public Cloud nutzt den Identity Authentication Service von SAP Cloud Identity Services (IAS) als Standard-Identity-Provider, das Vertrauen wird bei der Bereitstellung eingerichtet. Richten Sie Ihren BAIP-Subaccount auf denselben IAS-Tenant aus, melden sich Benutzer einmal für beide an.

Für den Aufruf von der App nach S/4HANA unterstützt der SAP S/4HANA Cloud Extensibility Service auf BAIP Basic Authentication, OAuth 2.0 Client Credentials, OAuth 2.0 SAML Bearer Assertion, Client-Zertifikate und OAuth mit mTLS. Die Entscheidung hinter dieser Liste:

• Technischer Benutzer: Die App ruft S/4HANA als sie selbst auf. Einfach, aber die App muss selbst durchsetzen, wer was sehen darf.
• Principal Propagation: Der SAML-Bearer-Assertion-Flow reicht den angemeldeten Benutzer weiter, sodass S/4HANA dessen Berechtigungen anwendet. Das setzt Single Sign-on über IAS voraus.

Beides ist legitim. Unentschieden zu bleiben dagegen nicht, denn das zeigt sich später entweder als Sicherheitslücke oder als Neubau.

Typische Fehler, die wir sehen

• Nicht freigegebene Services aufrufen. Ist ein OData-Service im Business Accelerator Hub nicht als freigegeben gelistet, kann er sich mit dem nächsten Upgrade ändern.
• Das ERP in die Erweiterung replizieren. Caching für die Performance ist in Ordnung. Eine zweite Kopie der Aufträge oder Geschäftspartner macht die Erweiterung zu einem zweiten System mit eigenen Synchronisationsproblemen.
• Ein Arrangement für alles. Breite Berechtigungen machen Audits langsam und den Rückbau riskant.
• Keine Trennung der Stufen. Test- und Produktiv-Subaccount auf BAIP, jeweils mit Destinations auf das passende S/4HANA-System, sind das Minimum.
• Side-by-Side bauen, was ein Key User könnte. Ein Custom Field und eine Regel in Custom Logic kosten Stunden; eine separate App kostet Wochen und muss betrieben werden.

Was Spadoom Side-by-Side baut

Wir bauen auf dieser Plattform für Kunden und für uns selbst. Engage, unsere Erweiterungen für Sales und Service Cloud V2, läuft mandantenfähig auf SAP BAIP. Pulse, unsere Suite für S/4HANA Public Cloud mit Plantafel für die Produktion, Terminal für die Linie, Qualitätsprüfung und einem Stammdaten-Cockpit, folgt demselben Side-by-Side-Muster: Node.js-Services und UI5-Oberflächen auf BAIP Cloud Foundry, ein Approuter mit XSUAA für die Anmeldung und S/4HANA ausschliesslich über freigegebene APIs wie die Fertigungsauftrags-, Produkt- und Geschäftspartner-APIs. Die Integration zwischen S/4HANA Public Cloud und Sales und Service Cloud V2 läuft auf der Integration Suite auf derselben Plattform; wie, habe ich im Integration Suite Runbook beschrieben.

Dabei hilft der Blick aus einem Team. Ob eine Erweiterung ins ERP oder daneben gehört, entscheidet oft das CRM, der Webshop oder die Menschen, die damit arbeiten werden. Auf unserer Seite SAP Partner Schweiz steht, wie ERP und CX bei Spadoom in einem Team zusammenkommen. Mehr zu den Produkten: SAP S/4HANA Public Cloud, SAP BAIP (ehemals BTP) und SAP Sales Cloud V2.

Sie haben eine Anforderung, die Key-User-Werkzeuge nicht abdecken? Sprechen Sie mit uns, und wir sagen Ihnen, welche der drei Optionen passt, auch wenn die ehrliche Antwort ein Custom Field ist.

Häufige Fragen

Welche Erweiterungsoptionen hat SAP S/4HANA Cloud Public Edition?

SAP nennt drei: Key User Extensibility mit eingebauten Werkzeugen wie Custom Fields, Custom Logic und Custom Business Objects; Developer Extensibility mit ABAP Cloud in der S/4HANA Cloud ABAP Environment, nur in einer Drei-System-Landschaft verfügbar; und Side-by-Side Extensibility auf SAP BTP, das heute Teil der SAP Business AI Platform ist.

Wann baue ich eine Side-by-Side-Erweiterung statt ABAP Cloud?

Wenn die Erweiterung lose gekoppelt ist: eigene Oberfläche oder eigene Nutzergruppe (zum Beispiel externe Benutzer), eigener Release-Rhythmus, Daten aus mehreren Systemen oder ein Team, das in Java oder Node.js arbeitet. Muss die Logik in derselben Transaktion wie der ERP-Beleg laufen, mit vielen Roundtrips oder grossen Datenmengen, ist ABAP Cloud im Stack die bessere Wahl.

Wie authentifiziert sich eine Side-by-Side-App gegenüber S/4HANA Public Cloud?

Über ein Communication Arrangement in S/4HANA, angesprochen über den Destination Service oder den SAP S/4HANA Cloud Extensibility Service auf BAIP. Technischer Zugriff läuft über einen Kommunikationsbenutzer, Client Credentials oder ein Zertifikat. Muss S/4HANA den angemeldeten Benutzer kennen, nutzt Principal Propagation den OAuth-2.0-SAML-Bearer-Assertion-Flow; das setzt Single Sign-on über SAP Cloud Identity Services voraus.

Bleibt der Core mit einer Side-by-Side-Erweiterung sauber?

Ja, wenn sie nur freigegebene APIs und Events nutzt. In den Clean-Core-Stufen von SAP ist eine Side-by-Side-Erweiterung auf SAP BTP, heute Teil der SAP Business AI Platform, die nur freigegebene, stabile Schnittstellen verwendet, Stufe A, also voll konform.