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

Jedes Projekt mit S/4HANA Public Cloud erreicht den Moment, in dem die Key-User-Extensibility an ihre Decke stösst. Ein zusätzliches Feld, eine Validierung, ein angepasstes App-Layout: kein Problem, dafür ist sie gebaut. Aber dann will der Vertrieb ein Dashboard, das Umsätze über Jahre und Zehntausende Belege aggregiert. Oder eine Fachabteilung braucht einen kleinen Prozess, den der Standard nicht kennt. Und die Frage steht im Raum: Müssen wir doch an den Kern?

Nein. Die Antwort heisst Side-by-Side: eine kleine Anwendung auf SAP BTP Cloud Foundry, die neben dem System lebt und ausschliesslich über freigegebene APIs mit ihm spricht. Das ERP bleibt unangetastet, die Erweiterung läuft daneben, und klein ist wörtlich gemeint.

Kurzfassung: Reicht die Key-User-Extensibility nicht, bauen Sie eine kleine CAP-Anwendung auf SAP BTP Cloud Foundry, die S/4HANA Public Cloud nur über freigegebene APIs liest und schreibt, angebunden über den Destination-Service und eine eigene Kommunikationsvereinbarung. Bauen Sie langweilig: leselastige Dashboards und kleine, klar abgegrenzte Schreibszenarien. Upgrades laufen dann durch, ohne dass es jemand merkt, und die Betriebskosten bleiben klein.

Das Muster: eine kleine App neben dem System

Die Blaupause ist immer dieselbe, und genau das ist ihre Stärke. Im Backend ein Service mit dem SAP Cloud Application Programming Model (CAP), in Node.js oder Java, der Daten aus S/4HANA holt, aggregiert oder anreichert. Davor ein Frontend: SAPUI5/Fiori, wenn sich die App wie SAP anfühlen soll, ein schlichtes Web-Frontend, wenn nicht. Die Verbindung ins ERP läuft über den Destination-Service und eine Kommunikationsvereinbarung in S/4HANA, und genutzt werden nur freigegebene APIs aus dem SAP Business Accelerator Hub. SAP dokumentiert den Ansatz als Side-by-Side-Erweiterbarkeit mit SAP BTP.

Das ist alles. Kein Framework-Zoo, keine eigene Plattform, keine Modifikation. Wer schon ein Node.js-Projekt aufgesetzt hat, findet sich in CAP innert Tagen zurecht. Und weil die Cloud-Foundry-Umgebung Speicher pro Instanz abrechnet, kostet eine App mit einigen hundert MB im Betrieb wenig.

Ein Beispiel aus einem unserer Projekte

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

Also haben wir eine kleine Side-by-Side-App gebaut: einen CAP-Service, der die Aufträge über die freigegebene Sales-Order-API liest, sie pro Kunde aggregiert und ein schlankes Dashboard ausliefert. Es ist als Mashup direkt in SAP Sales Cloud V2 eingebettet, mit Single Sign-on, damit sich niemand zweimal anmeldet. Der Verkäufer öffnet den Kunden im CRM und sieht das Dashboard, als wäre es Teil des Produkts.

Das Ergebnis: Das ERP wurde nie angefasst. Die App läuft in einigen hundert MB Cloud-Foundry-Speicher, die monatlichen Infrastrukturkosten liegen im zweistelligen Frankenbereich. Der Vertrieb hat eine Sicht auf den Kunden bekommen, die es vorher nicht gab. Dasselbe Muster auf der CRM-Seite beschreibt unser Beitrag zum Erweitern von Sales Cloud V2 mit eigenen Cloud-Foundry-Apps.

Die Architektur-Checkliste

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

1. Nur freigegebene APIs. Was im SAP Business Accelerator Hub nicht als freigegeben dokumentiert ist, wird nicht genutzt. Diese eine Regel entscheidet, ob die App Upgrades überlebt.
2. Eine Kommunikationsvereinbarung pro Szenario. Nicht eine Sammelvereinbarung mit allen Scopes, sondern eine eigene Vereinbarung pro Geschäftsfall. Das hält Berechtigungen nachvollziehbar und den Rückbau schmerzlos.
3. Principal Propagation oder technischer Benutzer: bewusst entscheiden. Muss das ERP wissen, welche Person fragt, brauchen Sie Principal Propagation. Ein technischer Benutzer ist einfacher, dann prüft aber die App selbst, wer was sehen darf. Beides ist legitim, unentschieden ist keines von beiden.
4. Destination-Service statt URLs im Code. Endpunkte, Zugangsdaten und Authentifizierungsart leben in der Destination, nie im Repository.
5. Ein BTP-Subaccount pro Stufe. Test und Produktion getrennt, jede Stufe mit Destinations auf das passende S/4HANA-System. Klingt selbstverständlich und wird erstaunlich oft ausgelassen.

Der Lohn: Upgrades, um die sich niemand kümmern muss

S/4HANA Public Cloud erhält seine Release-Upgrades nach dem Zeitplan von SAP, ob man will oder nicht. Hätten Sie den Kern modifiziert, würden Sie Ihre Modifikationen bei jedem Upgrade testen. Die Side-by-Side-App merkt vom Upgrade nichts, weil sie nur freigegebene, versionierte APIs nutzt, die SAP stabil hält. Unser Dashboard aus dem Beispiel hat mehrere Releases ohne jeden Aufwand auf unserer Seite überstanden.

Darum geht es bei Clean Core: nicht um Dogma, sondern um die Freiheit, Upgrades einfach geschehen zu lassen.

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 abgegrenzte Jobs. Genau dort glänzt das Muster.

Zwei Warnsignale aus Projekten, die wir übernommen haben. Erstens: Wenn Sie sich dabei ertappen, das halbe ERP in eine HANA-Cloud-Datenbank zu replizieren, halten Sie an und überdenken Sie das Zielbild. Ab diesem Punkt bauen Sie ein zweites System mit allen Synchronisationsproblemen, die dazugehören. Zweitens: Achten Sie auf API-Ratenlimits. Eine App, die bei jedem Seitenaufruf 75’000 Belege neu abfragt, lernt auf die harte Tour, dass freigegebene APIs gedrosselt sind. Aggregieren, cachen und nach Zeitplan nachladen.

Muss die Logik dagegen synchron im Belegfluss des ERP sitzen, ist ABAP Cloud das bessere Werkzeug; das beschreiben wir in Embedded Steampunk in S/4HANA Public Cloud. Sie suchen einen Partner für solche Arbeit? Unser Überblick über die SAP-BTP-Entwicklungspartner in der Schweiz zeigt, was Sie fragen sollten, und SAP BTP bei Spadoom zeigt, wie wir arbeiten. Side-by-Side-Apps sind auch ein typischer Baustein des integrierten Stacks aus S/4HANA Public Cloud und Sales Cloud V2, weshalb wir beide Hälften mit einem Team abdecken, wie in unserem Leitfaden zum besten SAP-Partner für Cloud ERP und CRM in der Schweiz beschrieben.

Häufige Fragen

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

Weniger, als die meisten erwarten. Sie bezahlen im Wesentlichen den Cloud-Foundry-Speicher plus kleine Posten für Dienste wie Destination und Berechtigungen. Unsere Beispiel-App mit einigen hundert MB Speicher kostet einen zweistelligen Frankenbetrag im Monat; der relevante Kostenblock ist der Bau, nicht der Betrieb, und selbst der bleibt bei einem fokussierten Szenario überschaubar.

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

Key-User-Extensibility für Felder, Validierungen und UI-Anpassungen innerhalb einer bestehenden App. BTP Cloud Foundry, sobald Sie eigene Datenaggregation, eine eigene Oberfläche oder die Einbettung in ein anderes System wie ein CRM brauchen. ABAP Cloud (Developer Extensibility, auch Embedded Steampunk genannt), wenn die Logik nah an den ERP-Transaktionen laufen muss und das Team ABAP-Kenntnisse mitbringt.

Lässt sich eine solche App in SAP Sales Cloud V2 einbetten?

Ja. Sales Cloud V2 bettet die App als Mashup in die Account- oder Opportunity-Sicht ein. Ist Single Sign-on sauber eingerichtet, merken die Benutzer nicht, dass sie in einer externen App arbeiten; so läuft das Umsatzdashboard aus unserem Beispiel.

Bricht die App, wenn SAP die API ändert?

Freigegebene APIs sind versioniert, und SAP hält freigegebene Versionen stabil; neue Versionen kommen additiv hinzu. Das Risiko liegt fast vollständig bei nicht freigegebenen Schnittstellen, darum lautet die erste Regel unserer Checkliste: nur freigegebene APIs nutzen.

---

Ihre Key-User-Extensibility ist ausgereizt, und auf dem Tisch liegt der Vorschlag einer Kernmodifikation? Wir zeigen Ihnen gern, wie das Side-by-Side-Muster in Ihrem Fall aussieht. Sprechen Sie mit unserem Team.