SAP Activate für BTP-Extensions

Side-by-Side-Erweiterungen Clean-Core-konform liefern – sechs Activate-Phasen für CAP- und RAP-Apps, mit BTP-Subaccount auf Cloud Foundry oder Kyma, IAS/IPS als Identity-Layer, CI/CD über SAP Continuous Integration and Delivery und Cloud ALM für Monitoring. Der Core bleibt clean, die Plattform wächst horizontal.

BTP-Extensions in sechs Activate-Phasen

BTP-Erweiterungen folgen dem Clean-Core-Prinzip: keine Modifikation des SAP-Standards, sondern Side-by-Side-Apps und -Services auf der Business Technology Platform. Wir arbeiten auch hier nach dem SAP- Activate-Ansatz, übersetzen die sechs Phasen aber in die Welt von CAP, RAP, AI Hub und HANA Cloud.

mermaid flowchart TD D[1 · Discover Extension-Kandidaten] P[2 · Prepare BTP-Subaccount + IAS] E[3 · Explore CAP/RAP-Prototyp] R[4 · Realize CI/CD + Cloud ALM] Dp[5 · Deploy Cloud Foundry / Kyma] Rn[6 · Run DevOps-Loop] D --> P --> E --> R --> Dp --> Rn Rn -.->|nächste Extension| D click D call mmdInfo() "Wir identifizieren Erweiterungsszenarien, die nicht in den S4HANA-Kern gehören – Felder, Prozesse, Apps, Integrationen. Drei bis fünf Kandidaten werden mit Aufwand, Nutzen und Daten-Abhängigkeit priorisiert. Die Clean-Core-Disziplin entscheidet, was wirklich Side-by-Side gehört und was nicht." click P call mmdInfo() "Ein BTP-Subaccount wird im Cloud Foundry oder Kyma Runtime aufgesetzt. Identity über IAS und IPS, Konnektivität zu S4HANA über den Cloud Connector, AI Hub und HANA Cloud Vector Engine bei Bedarf. Service-Bindings, Destinations und Berechtigungen werden dokumentiert. Resultat ist eine vollständige Dev-Umgebung mit allen Service-Verbindungen." click E call mmdInfo() "Pro Kandidat entsteht ein CAP- oder RAP-Prototyp – je nach Technologie-Stack des Teams. Integration via OData, REST oder Event Mesh wird real getestet. Fachanwender geben Feedback auf reale Daten. Iterationen sind kurz, der Backlog wird sauber geführt. Am Ende steht ein technisch und fachlich freigegebenes Konzept." click R call mmdInfo() "Die finale Implementierung läuft mit CI/CD über SAP Continuous Integration and Delivery. Unit- und Integrationstests laufen automatisch, die Architektur wird mit der HANA Cloud und dem AI Hub geerdet. SAP Cloud ALM überwacht den Service. Authorization-Scopes, Audit-Trails und Security-Hardening sind Pflicht, kein nice-to-have." click Dp call mmdInfo() "Deployment via Cloud Foundry oder Kyma. Berechtigungs-Scopes werden im Subaccount aktiviert, Routes und Destinations finalisiert. Eine Performance-Baseline wird gemessen und das Monitoring scharfgeschaltet. Smoke-Tests durch Fachbereiche und ein definierter Eskalations-Pfad sichern die Live-Schaltung." click Rn call mmdInfo() "Kontinuierliches DevOps mit Auto-Scaling, regelmässigen Updates und SLA-Monitoring via Cloud ALM. Neue Extensions können unabhängig hinzugefügt werden, ohne den Core zu berühren. Clean Core bleibt clean, die Plattform wächst horizontal. Der Loop schliesst sich, sobald die nächste Extension diskutiert wird."

1. Discover – Extension-Kandidaten priorisieren

Wir identifizieren Erweiterungsszenarien, die nicht in den S/4HANA- Kern gehören – kundenspezifische Felder, Prozess-Schritte, Apps, Integrationen mit Drittsystemen. Drei bis fünf Kandidaten werden mit Aufwand, Nutzen und Daten-Abhängigkeit priorisiert. Die Clean-Core- Disziplin entscheidet, was wirklich Side-by-Side gehört und was nicht – das Vermeiden von Modifikationen ist genauso wichtig wie das Bauen neuer Funktionen.

2. Prepare – BTP-Subaccount und Identity-Layer

Ein BTP-Subaccount wird im Cloud Foundry oder Kyma Runtime aufgesetzt. Identity läuft über IAS und IPS, Konnektivität zu S/4HANA über den Cloud Connector. AI Hub und HANA Cloud Vector Engine werden bei Bedarf provisioniert. Service-Bindings, Destinations und Berechtigungen werden dokumentiert. Am Ende steht eine vollständige Dev-Umgebung mit allen Service-Verbindungen.

3. Explore – CAP- oder RAP-Prototypen

Pro Kandidat entsteht ein CAP- oder RAP-Prototyp – je nach Technologie-Stack und Team-Erfahrung. Integration via OData, REST oder Event Mesh wird real getestet. Fachanwender geben Feedback auf reale Daten. Iterationen sind kurz, der Backlog wird sauber geführt. Am Ende steht ein technisch und fachlich freigegebenes Konzept.

4. Realize – CI/CD und Cloud ALM

Die finale Implementierung läuft mit CI/CD über SAP Continuous Integration and Delivery. Unit- und Integrationstests laufen automatisch, die Architektur wird mit HANA Cloud und AI Hub geerdet. Cloud ALM überwacht den Service ab Tag 1. Authorization- Scopes, Audit-Trails und Security-Hardening sind Pflicht, kein nice-to-have.

5. Deploy – Cloud Foundry / Kyma Rollout

Deployment via Cloud Foundry oder Kyma. Berechtigungs-Scopes werden im Subaccount aktiviert, Routes und Destinations finalisiert. Eine Performance-Baseline wird gemessen und das Monitoring scharfgeschaltet. Smoke-Tests durch die Fachbereiche und ein definierter Eskalations-Pfad sichern die Live-Schaltung.

6. Run – DevOps-Loop und Skalierung

Kontinuierliches DevOps mit Auto-Scaling, regelmässigen Updates und SLA-Monitoring via Cloud ALM. Neue Extensions können unabhängig hinzugefügt werden, ohne den Core zu berühren. Clean Core bleibt clean, die Plattform wächst horizontal – und nicht in den Kern hinein.

Stand: 2026-05-10

SFOUR Consulting — Übersicht · Kontakt