Side-by-Side: S/4HANA Public Cloud mit kleinen Cloud-Foundry-Apps erweitern, ohne den Clean Core zu opfern

In jedem S/4HANA-Public-Cloud-Projekt kommt der Moment, in dem die Key-User-Extensibility an ihre Grenze stösst. Ein Zusatzfeld, eine Validierung, ein angepasstes App-Layout: alles kein Thema, dafür ist sie gebaut. Aber dann wünscht sich der Vertrieb ein Dashboard, das Umsätze über Jahre und Zehntausende Belege aggregiert. Oder ein Fachbereich braucht einen kleinen Prozess, den der Standard schlicht nicht kennt. Und plötzlich steht die Frage im Raum: Müssen wir jetzt doch in den Kern eingreifen?

Müssen Sie nicht. Die Antwort heisst Side-by-Side: eine kleine Applikation auf SAP BTP Cloud Foundry, die neben dem System lebt und mit ihm ausschliesslich über freigegebene APIs spricht. Das ERP bleibt unberührt, die Erweiterung läuft daneben. Klein ist dabei wörtlich gemeint.

Das Muster: eine kleine App neben dem System

Der Bauplan ist immer derselbe, und genau das ist seine Stärke. Im Backend ein CAP-Service (Cloud Application Programming Model, Node.js oder Java), der die Daten aus S/4HANA holt, aggregiert oder anreichert. Davor ein Frontend: Fiori/UI5, wenn die App sich wie SAP anfühlen soll, oder ein schlankes Web-Frontend, wenn nicht. Die Verbindung ins ERP läuft über den Destination Service und Kommunikationsvereinbarungen im S/4HANA, konsumiert werden nur freigegebene APIs aus dem SAP Business Accelerator Hub.

Das war’s. Kein Framework-Zoo, keine eigene Plattform, keine Modifikation. Wer schon einmal ein Node.js-Projekt aufgesetzt hat, findet sich in CAP innert Tagen zurecht. Und weil Cloud Foundry Speicher pro Instanz abrechnet, kostet eine App, die in wenigen hundert MB läuft, im Betrieb fast nichts.

Ein Beispiel aus einem unserer Projekte

Bei einem Schweizer Handelsunternehmen wollte der Vertrieb im CRM sehen, was ein Kunde über die Jahre tatsächlich gekauft hat: Umsatz pro Jahr, pro Produktgruppe, Trend. Die Rohdaten dafür liegen im ERP, verteilt auf rund 75’000 Kundenaufträge. Kein CRM-Standardreport bildet das ab, und niemand wollte dafür am ERP schrauben.

Also haben wir eine kleine Side-by-Side-App gebaut: ein CAP-Service, der die Aufträge über die freigegebene Sales-Order-API liest, pro Kunde aggregiert und als schlankes Dashboard ausliefert. Eingebettet ist das Ganze als Mashup direkt in SAP Sales Cloud V2, mit iframe-SSO, damit sich niemand ein zweites Mal anmeldet. Der Vertriebler öffnet den Kunden im CRM und sieht das Dashboard, als wäre es Teil des Produkts.

Die Bilanz: Das ERP wurde nicht angefasst. Die App läuft in ein paar hundert MB Cloud-Foundry-Speicher. Die monatlichen Infrastrukturkosten liegen im zweistelligen Frankenbereich. Und der Vertrieb hat eine Sicht auf den Kunden, die vorher schlicht nicht existierte.

Die Architektur-Checkliste

Damit das Muster sauber bleibt, halten wir uns in jedem Projekt an fünf Punkte:

1. Nur freigegebene APIs. Was nicht im SAP Business Accelerator Hub als released dokumentiert ist, wird nicht konsumiert. Punkt. Diese eine Regel entscheidet darüber, ob die App Upgrades übersteht.
2. Eine Kommunikationsvereinbarung pro Szenario. Nicht ein Sammel-Arrangement mit allen Scopes, sondern pro fachlichem Anwendungsfall eine eigene Vereinbarung. Das hält Berechtigungen nachvollziehbar und Abschaltungen schmerzfrei.
3. Principal Propagation oder technischer User: bewusst entscheiden. Soll das ERP wissen, welcher Mensch anfragt, braucht es Principal Propagation. Reicht ein technischer User, ist er einfacher, aber dann prüft die App selbst, wer was sehen darf. Beides ist legitim; unentschieden ist keines von beidem.
4. Destination Service statt URLs im Code. Endpunkte, Credentials und Auth-Methode leben in der Destination, nie im Repository.
5. Ein BTP-Subaccount pro Stage. Test und Produktion getrennt, jede Stage mit eigenen Destinations gegen den passenden S/4HANA-Tenant. Klingt selbstverständlich, wird de facto erstaunlich oft übersprungen.

Der Lohn: Upgrades, die niemanden interessieren

Hier zahlt sich die Disziplin aus. S/4HANA Public Cloud bekommt seine Release-Upgrades im Quartalstakt, ob man will oder nicht. Wer in den Kern eingegriffen hätte, testet jetzt jedes Quartal seine Modifikationen. Die Side-by-Side-App dagegen merkt vom Upgrade nichts, weil sie nur freigegebene, versionierte APIs nutzt, deren Kompatibilität SAP garantiert. Unser Dashboard aus dem Beispiel hat mehrere Release-Wechsel erlebt. Aufwand auf unserer Seite: null.

Das ist der eigentliche Sinn von Clean Core. Nicht Dogma, sondern die Freiheit, Upgrades einfach geschehen zu lassen.

Know-how aus der Praxis: langweilig bauen

Die wichtigste Regel für Side-by-Side-Apps ist unspektakulär: Bauen Sie sie langweilig. Leselastige Dashboards, kleine Schreibszenarien über freigegebene APIs, klar umrissene Aufgaben. Genau dort spielt das Muster seine Stärke aus.

Zwei Warnsignale aus Projekten, die wir übernommen haben. Erstens: Wer sich dabei ertappt, das halbe ERP in eine HANA Cloud zu replizieren, sollte innehalten und das Zielbild hinterfragen. Ab diesem Punkt baut man kein Extension-Szenario mehr, sondern ein zweites System mit allen Synchronisationsproblemen, die dazugehören. Zweitens: API-Rate-Limits beobachten. Die freigegebenen APIs sind gedrosselt, und eine App, die bei jedem Seitenaufruf 75’000 Belege frisch abfragt, lernt das schmerzhaft. Aggregieren, cachen, zeitgesteuert nachladen: unglamourös, aber genau richtig.

Häufige Fragen

Was kostet der Betrieb einer kleinen Cloud-Foundry-App?

Weniger, als die meisten erwarten. Abgerechnet wird im Wesentlichen der Cloud-Foundry-Speicher (GB-Stunden) plus kleine Posten für Destination- und Authorization-Services. Eine App mit wenigen hundert MB Speicherbedarf landet bei zweistelligen Franken pro Monat. Der relevante Kostenblock ist nicht der Betrieb, sondern der Bau, und auch der bleibt bei einem fokussierten Szenario überschaubar.

Wann Key-User-Extensibility, wann BTP Cloud Foundry, wann Steampunk?

Unsere Faustregel: Key-User-Extensibility für Felder, Validierungen und UI-Anpassungen innerhalb einer bestehenden App. BTP Cloud Foundry, sobald eigene Datenaggregation, ein eigenes UI oder die Einbettung in ein anderes System (etwa ein CRM) gefragt ist. Steampunk, also ABAP Cloud im Embedded oder BTP-Umfeld, wenn die Logik nahe an den ERP-Transaktionen leben muss und das Team ABAP-Kompetenz mitbringt. Zu ABAP Cloud folgt übrigens ein eigener Beitrag.

Kann eine solche App in SAP Sales Cloud V2 eingebettet werden?

Ja, und das ist einer der schönsten Anwendungsfälle. Sales Cloud V2 bindet die App als Mashup ein, per iframe direkt in der Kunden- oder Opportunity-Ansicht. Mit sauber aufgesetztem SSO merkt der Anwender nicht, dass er gerade eine externe App bedient. Genau so läuft unser Umsatz-Dashboard aus dem Beispiel.

Bricht die App, wenn SAP das API ändert?

Freigegebene APIs sind versioniert, und SAP hält bestehende Versionen stabil. Neue Versionen kommen additiv. Das Risiko liegt fast ausschliesslich bei nicht freigegebenen Schnittstellen, und genau deshalb steht Regel eins der Checkliste dort, wo sie steht.

Ihre Key-User-Extensibility ist am Limit und der nächste Vorschlag heisst Core-Eingriff? Wir zeigen Ihnen gern, wie das Side-by-Side-Muster in Ihrem Fall aussieht. Sprechen Sie mit uns.