Clean Core mit SAP CAP: SAP CX erweitern ohne Upgrade-Schmerzen

Sie passen SAP an. Ein Jahr später macht ein Upgrade Ihre Änderungen kaputt, und Ihr Team ist wochenlang mit der Reparatur beschäftigt. Diese Geschichte hören wir oft von Unternehmen, die mit einer bestehenden SAP-Landschaft zu uns kommen.

Das sind die Kosten von eigenem Code im SAP-Kern. Sie wachsen leise: Nach ein paar Runden wird jedes Release zu einem kleinen Projekt, und das Team fürchtet die Release Notes, statt sie zu lesen.

Clean Core durchbricht diesen Kreislauf. Der SAP-Kern bleibt Standard, und die individuelle Logik entsteht daneben, nicht darin, mit dem Erweiterungsrahmen, den SAP dafür vorsieht.

Kurzfassung: Clean Core heisst: keine Modifikationen im SAP-Kern. Wir bauen Erweiterungen Side-by-Side mit dem SAP Cloud Application Programming Model (CAP) auf SAP BTP. Sie sprechen über freigegebene APIs und Ereignisse mit SAP Sales Cloud V2, Service Cloud V2 oder S/4HANA Public Cloud. Bringt SAP ein Release, testen Sie den API-Vertrag Ihrer Erweiterungen erneut, statt modifizierten Kerncode zu reparieren.

Was bedeutet Clean Core konkret?

Das Prinzip: kein eigener Code im SAP-Kern. Ihre Geschäftslogik lebt in separaten Erweiterungen, die über stabile, freigegebene APIs mit SAP kommunizieren. SAP hat das für Cloud-ERP zur ausdrücklichen Empfehlung gemacht; der SAP-Beitrag How to Extend SAP S/4HANA Cloud the Right Way erklärt das Modell. In SAP S/4HANA Public Cloud ist es nicht einmal optional: Die Plattform lässt nur freigegebene Erweiterungspunkte zu.

SAP Sales Cloud V2 und SAP Service Cloud V2 folgen demselben Aufbau. Sie bieten REST-APIs, dokumentiert im SAP Business Accelerator Hub, und ein Ereignissystem für Side-by-Side-Erweiterungen. SAP aktualisiert den Kern nach eigenem Takt, und Ihre Erweiterungen funktionieren weiter, solange der API-Vertrag hält.

Das ist kein Umweg. Die V2-Produkte wurden gebaut, um Kern und Kundenlogik zu trennen.

Wie bauen wir Erweiterungen mit SAP CAP?

Wir nutzen das SAP Cloud Application Programming Model (CAP), das Framework von SAP für Services auf SAP BTP, und betreiben die Services in der Cloud-Foundry-Umgebung von SAP BTP. Für Side-by-Side-Erweiterungen auf Sales Cloud V2, Service Cloud V2 und S/4HANA Public Cloud ist das unser Standard, aus drei Gründen:

• Wenig Infrastrukturarbeit. Cloud Foundry übernimmt Skalierung, Routing und Deployment. Das Team schreibt Geschäftslogik, keine Betriebsskripte.
• SAP-Anbindung eingebaut. CAP arbeitet mit XSUAA für die Authentifizierung, dem Destination Service und dem SAP-Eventing zusammen und nutzt die APIs von Sales und Service Cloud V2 ohne eigenen Verbindungscode.
• Ein Standard-Stack. Node.js oder Java, OData und REST, CDS für die Datenmodellierung. Die Entwicklerinnen und Entwickler kennen die Werkzeuge, exotische Abhängigkeiten gibt es keine.

Das Ergebnis: Erweiterungen, die Sie unabhängig vom SAP-Releasekalender deployen, testen und aktualisieren. Den ganzen Aufbau vom Subaccount bis zum Deployment beschreiben wir in SAP Sales Cloud V2 mit eigenen Cloud-Foundry-Apps erweitern und für die ERP-Seite in S/4HANA Public Cloud auf BTP Cloud Foundry erweitern. Wo Logik nahe an den ERP-Daten liegen muss, bietet S/4HANA auch ABAP Cloud im Kern-Stack, beschrieben in unserem Beitrag zu Embedded Steampunk.

Wie sieht das in der Praxis aus?

Beispiel Sales Cloud V2: Ein Kunde braucht eine eigene Validierung auf der Opportunity und einige zusätzliche Felder für seinen Prozess. Wir deployen einen CAP-Service auf Cloud Foundry, der die Validierungslogik und die zusätzlichen Daten hält. Er reagiert auf Opportunity-Ereignisse, statt abzufragen oder geplante Jobs laufen zu lassen. Eine eigene Oberfläche ist als Mashup in Sales Cloud V2 eingebettet, sodass der Vertrieb in einer einzigen Oberfläche arbeitet.

Der Kern von Sales Cloud V2 bleibt unberührt. Kommt das nächste SAP-Release, testen wir die API-Aufrufe und Ereignisse, auf die sich die Erweiterung stützt; modifizierten Kerncode, der repariert werden müsste, gibt es nicht.

Beispiel Service Cloud V2: eigene Eskalationsregeln, angereicherte Falldaten, Anbindungen an externe Ticketsysteme. Alles CAP-Erweiterungen auf Cloud Foundry, alles ausserhalb des Kerns.

Beispiel S/4HANA Public Cloud: Dasselbe Muster gilt, wenn ein CX-Prozess ERP-Daten braucht, etwa eine Bonitätsprüfung, bevor ein Angebot freigegeben wird. Die Erweiterung ruft freigegebene S/4HANA-APIs auf und berührt den ERP-Kern nie. So kann ein Team den ERP-Kern und den CX-Stack gleichzeitig im Standard halten.

Warum zählt Clean Core für Ihr Budget?

Eigener Code, der bei Upgrades bricht, gehört zu den häufigsten Gründen, warum SAP-Projekte Zeit und Budget überschreiten. Viele IT-Verantwortliche haben ein Upgrade erlebt, das schiefging, weil eine vor Jahren eingebaute Modifikation nie dokumentiert wurde.

Ohne Clean Core kostet Sie jedes SAP-Release: Das Team testet den Eigencode, passt ihn an und repariert, was gebrochen ist, jedes Mal. Mit Clean Core heisst ein Release vor allem, Ihre Erweiterungen gegen einen API-Vertrag erneut zu testen, den SAP versioniert und stabil hält. Wie viel schneller Upgrades werden, hängt davon ab, wie viel Logik Sie aus dem Kern herausholen; der Aufwand verschiebt sich aber von Reparatur zu Regressionstest.

Über drei bis fünf Jahre summiert sich dieser Unterschied. Weniger Zeit für Wartung heisst mehr Zeit für Funktionen, die das Geschäft voranbringen.

Wenn Sie einen Wechsel auf S/4HANA planen und wissen wollen, wie viel Eigencode neu gebaut werden muss, beantwortet unser S/4HANA Readiness Assessment das vor Projektbeginn. Für die Wahl eines Partners, der Erweiterungen so baut, lesen Sie unsere Übersicht der besten SAP-BTP-Entwicklungspartner in der Schweiz.

Häufig gestellte Fragen

Was, wenn meine Erweiterung Daten aus dem SAP-Kern braucht?

Eine CAP-Erweiterung liest und schreibt Daten über die freigegebenen APIs von SAP Sales Cloud V2, Service Cloud V2 oder S/4HANA Public Cloud. Über Änderungen wie eine neue Opportunity informieren Ereignisbenachrichtigungen, etwa über SAP Event Mesh. Auf die Datenbank des Kerns greift sie nie direkt zu.

Lassen sich bestehende Anpassungen auf Clean Core umstellen?

Ja, aber das ist ein Refactoring und kein einfaches Umziehen. Eigenes ABAP oder Modifikationen im Kern werden als Side-by-Side-Services oder als freigegebene On-Stack-Erweiterungen neu gebaut. Die Geschäftslogik bleibt gleich, die Architektur ändert sich.

Funktioniert Clean Core auch für SAP Commerce Cloud?

Das Prinzip ist dasselbe, der Mechanismus ein anderer. Commerce Cloud arbeitet mit Extensions im Typsystem und definierten Erweiterungspunkten statt mit Modifikationen des Kerns. Im Frontend trennt SAP Composable Storefront (früher Spartacus) Anpassungen über die Dependency Injection von Angular.

Ist CAP die einzige Option für Clean-Core-Erweiterungen?

Nein. Jede Technologie, die die freigegebenen SAP-APIs aufruft, funktioniert, etwa Java, Node.js, Python oder Low-Code mit SAP Build. Wir setzen auf CAP, weil es Authentifizierung, Datenmodellierung und SAP-Anbindung mitbringt und so der kürzeste Weg zu produktionsreifen Erweiterungen ist.

Wie wirkt sich Clean Core auf den SAP-Support aus?

SAP unterstützt sein Standardprodukt. Modifikationen im Kern können Supportfälle erschweren, weil SAP zuerst den eigenen Code ausschliessen muss. Side-by-Side-Erweiterungen lassen den Standard intakt, und Sie betreuen Ihre Erweiterungen separat.

Starten Sie ein Projekt mit Sales Cloud V2, Service Cloud V2 oder S/4HANA Public Cloud? Sprechen Sie mit unseren Architekten über einen Clean-Core-Ansatz ab dem ersten Tag.