ABAP Side-by-Side auf BTP (Steampunk)
ABAP Cloud / Steampunk als Side-by-Side-Spielwiese – Erweiterungen die NICHT im S/4-Mandanten leben sollen, weil sie eigene Releases brauchen, Drittsysteme orchestrieren oder AI-Services wrappen. Wir bauen die Service-Schicht mit ABAP-Standards (RESTful, OData V4, mandantenfähig via IAS), versionieren über abapGit, und integrieren sauber via SAP Destinations zum S/4.
Die Frage hinter ABAP Side-by-Side
Manche Erweiterungen gehören nicht in den S/4-Mandanten. Sie haben andere Release-Zyklen, integrieren mehrere Systeme, wrappen externe AI-Services oder bedienen sehr spezifische Workflows. Wer solche Erweiterungen trotzdem im Standard-Mandanten implementiert, deformiert den Clean Core und schmerzt bei jedem S/4-Upgrade.
ABAP Cloud (umgangssprachlich "Steampunk") ist die Antwort: Sie schreiben weiter ABAP, in der vertrauten Sprache mit dem vertrauten Tooling – aber in einer eigenständigen Cloud-Umgebung auf BTP. Das hat eine Disziplin-Komponente: nur Whitelisted-APIs sind erlaubt, Standard-Modifikationen sind ausgeschlossen, jede Erweiterung muss sauber über Destinations zum S/4 sprechen.
Wann Side-by-Side richtig ist
Wir treffen die Entscheidung bewusst pro Erweiterung. Side-by-Side passt für:
- AI-Service-Wrapper: Joule-Skill, GenAI-Klassifikator, ML- Anomalieerkennung – die Service-Schicht zwischen S/4 und AI-Modell.
- Cross-System-Orchestrierung: Workflows die SAP, ein Lieferanten- portal und ein Lagersystem orchestrieren. Kein Standard-System ist der natürliche Ort, also Side-by-Side.
- Microservices mit eigenem Lifecycle: ein API-Gateway, ein Auswertungs-Service mit eigener Cache-Schicht, ein zeitgesteuerter Daten-Job. Eigenes Release-Tempo, eigener Code-Repo.
- Customer-Apps für externe Nutzer: Lieferanten-Portal, Kunden- Anfrage-Portal – was nicht in den SAP-Mandanten gehört.
Side-by-Side ist NICHT richtig für: - Erweiterungen die direkt am Standard-Datenmodell hängen (Custom-Felder, Custom-BO-Verlängerung) → das ist RAP - One-off-Reports und Auswertungen → das ist CDS - Workflows die ausschliesslich Standard-Daten lesen/schreiben → RAP
So bauen wir das
1. Architektur-Entscheidung
Wir starten mit einem Architektur-Review (30 Min) auf den konkreten Use-Case. Aus 6–8 Fragen (Lifecycle? Datenmodell-Nähe? User-Type? Performance-Anforderung? Drittsystem-Integration?) entsteht die Entscheidung RAP vs. CAP vs. ABAP-Steampunk. Ohne diese Entscheidung baut man falsch.
2. Service-Skelett
Wir setzen die ABAP-Cloud-Umgebung im BTP-Subaccount auf (Subaccount, Service Instance, IAS-Anbindung, Connectivity- Destinations zum S/4). Das Repository ist abapGit-versioniert, ATC-Pflicht-Checks sind aktiv, der Pipeline-Build prüft jedes Commit.
3. RESTful Service + OData V4
Auf den ABAP-Cloud-APIs (Released-APIs only) bauen wir die Service-Schicht. Drittsystem-Calls laufen über Destinations, S/4-Calls über die freigegebenen API-Schnittstellen (RAP-Services des S/4, BAPI-RFC nur mit Whitelist).
4. Mandant-Trennung via IAS/IPS
Wenn mehrere Mandanten oder mehrere Kunden den Service nutzen, richten wir die Mandant-Trennung über IAS-Tenant-Zuordnungen ein. Audit-Trail läuft direkt in die SAP-Audit-Schicht.
5. Integration zurück zum S/4
Vom S/4 aus wird der Service als externe Anwendung integriert – über Fiori Launchpad (URL-Link), über Custom-Code-Calls (Destinations), oder über RAP-Erweiterungen die den Service aufrufen. Diese Brücke planen wir bewusst – kein "wirkommt schon irgendwie zusammen".
Anschluss-Pattern: AI-Agent im SAP-Prozess
Eine der häufigsten Anwendungen ist ein AI-Agent-Wrapper: der Service nimmt eine SAP-Anfrage entgegen, ruft via AI Hub ein LLM auf (modell-agnostisch, wir wählen pro Use-Case), verarbeitet die Antwort, schreibt das Ergebnis via RAP zurück. Das ist der saubere Integrationspfad für die ERP-AI-Kombination – AI lebt Side-by-Side, S/4 bleibt Clean Core.
Wer mit uns arbeitet
Dieses Angebot richtet sich an ABAP-Leads und Tech-Architekten die ihre Erweiterungs-Architektur konsequent in RAP-Stack und Side-by-Side aufteilen wollen. Ein Architektur-Review (30 Min) auf einen konkreten Service-Vorschlag genügt meist, um die Anschluss-Entscheidung sauber zu treffen.
