Clean-Core-Erweiterbarkeit erklärt: Stufen, freigegebene APIs und klassische Modifikationen
Ein praxisnaher Überblick, wie SAP Erweiterungen nach ihrer Upgrade-Stabilität einordnet — von ABAP Cloud auf freigegebenen APIs bis zu klassischen Modifikationen — und wie Sie bestehenden Eigenentwicklungscode bewerten.
- Zuletzt geprüft:
- Ziel-Releases:
- SAP S/4HANA, SAP S/4HANA Cloud Private Edition, SAP S/4HANA Cloud Public Edition
- Version:
- 1
- Herkunft der Inhalte:
- Redaktioneller Inhalt, fachlich geprüft
Die Idee hinter Clean Core
Clean Core bedeutet, dass der SAP-Standard nicht modifiziert wird und Erweiterungen nur stabile, dokumentierte Schnittstellen nutzen. Der Vorteil sind planbare Upgrades: Hängt eine Erweiterung nur von freigegebenen Objekten ab, ist die Wahrscheinlichkeit deutlich geringer, dass ein neues Release sie bricht.
Das Stufenmodell
SAP hat Erweiterungen in einem Stufenmodell beschrieben:
- Stufe 1 — cloudfähige Erweiterungen. Entwickelt mit ABAP Cloud (eingeschränkte Sprachversion) oder Side-by-Side, ausschließlich auf freigegebenen APIs und Erweiterungspunkten.
- Stufe 2 — Cloud-API-Enablement. Wrapper um klassische, noch nicht freigegebene Funktionalität, die diese kontrolliert für Code der Stufe 1 verfügbar machen.
- Stufe 3 — klassische ABAP-Erweiterungen. Klassische Entwicklung, die auf nicht freigegebene Objekte zugreifen oder Standardcode modifizieren kann. Hier konzentriert sich das Upgrade-Risiko.
SAP hat diese Leitlinien inzwischen zu feiner abgestuften Clean-Core-Levels weiterentwickelt. Prüfen Sie stets die aktuelle SAP-Dokumentation für die Einordnung, die für Ihr Release gilt.
Typische Befunde in bestehendem Code
- Direkte Datenbankschreibzugriffe auf SAP-Standardtabellen statt freigegebener APIs.
- Verwendung von Objekten ohne Freigabevertrag, die sich ohne Ankündigung ändern können.
- Modifikationen und implizite Erweiterungen im Standardcode.
- Abhängigkeiten von Objekten, die im Zielrelease veraltet sind.
So bewerten Sie Ihre Landschaft
- Erstellen Sie ein Inventar der Eigenentwicklungen und ihrer Abhängigkeiten zu SAP-Objekten.
- Ordnen Sie jede Abhängigkeit nach Freigabestatus ein (freigegeben, veraltet, nicht freigegeben).
- Priorisieren Sie Objekte mit direkten Tabellenänderungen und Modifikationen.
- Planen Sie Nachfolger: freigegebene CDS-Views, freigegebene APIs oder Erweiterungspunkte.
Der Clean Core Object Guard von ERP Preflight klassifiziert Eigenentwicklungen und ihre Abhängigkeiten deterministisch und belegt jeden Befund mit Datei, Zeile und Hash. Siehe Migration & Clean Core.
Dieser Artikel enthält allgemeine Informationen zu SAP-Konzepten und ersetzt nicht die SAP-Dokumentation für Ihr konkretes Release.
Quellen
Passende Lösungsbereiche
Zugehörige Engines: Clean Core Object Guard, Extension Impact Guard, ECC2Cloud Navigator
Weiterführend
SAP-Probleme zu diesem Artikel
- BlockerZyklische Erweiterungsabhängigkeit
- BlockerDirektes Schreiben in eine SAP-Standardtabelle
- BlockerIDoc-Typ im Cloud-Zielsystem nicht unterstützt
- KritischAnforderung impliziert einen Clean-Core-Verstoß (Stufe 11)
- KritischLöschen durch aktive Konsumenten blockiert
- KritischDirektes Lesen einer SAP-Standardtabelle