Clean Core 2.0 aus Code-Sicht
Clean Core ist kein Marketing-Begriff sondern eine technische Disziplin – sie regelt, an welchen Stellen Sie den SAP-Standard verändern dürfen und an welchen nicht. Aus Code-Sicht heisst das: kein Modify am Standard, keine Z-Tabellen mit Standard-Daten, Erweiterungen ausschliesslich über Released-APIs (RAP, BAdI, Enhancement-Point). Wer diese Disziplin durchhält, übersteht S/4-Upgrades ohne SPAU-Spätschmerz.
Clean Core in einem Satz
Clean Core 2.0 ist die Disziplin, am SAP-Standard nichts zu ändern, was die Standard-Lifecycle gefährdet – und gleichzeitig Erweiterungen so zu bauen, dass sie zukünftige Standard-Änderungen aushalten. Es ist kein Verbot von Eigenentwicklung. Es ist eine Regel für die Erweiterungs-Architektur.
Die drei Anti-Patterns
Wer Clean Core verletzt, tut typischerweise eines von drei Dingen:
1. Modify am Standard
Sie greifen in eine SAP-Standard-Klasse, ein Standard-FBA, ein Standard-Programm ein und verändern Quellcode. Das Ergebnis: jeder Upgrade hat einen SPAU-Konflikt, jede Standard-Hotfix muss manuell nachvollzogen werden, jede neue API-Variante kann das Verhalten kippen. Die Wartung verdoppelt sich.
Stattdessen: Erweitern Sie via BAdI, Enhancement-Point, Implicit Enhancement Section oder RAP-Behaviour-Override – Stellen, die SAP explizit für Erweiterungen anbietet.
2. Z-Tabellen die Standard-Daten reduplizieren
Sie kopieren Standard-Belegdaten in eine Z-Tabelle und arbeiten dort weiter. Das Ergebnis: doppelte Wahrheit, Synchronisations- Probleme, fehlende Audit-Trail-Konsistenz. Bei einem Standard- Datenmodell-Wechsel (z.B. Universal Journal) müssen Sie Ihre Z-Tabellen migrieren.
Stattdessen: Erweitern Sie das Standard-Datenmodell via Custom Fields auf dem Standard-Beleg, oder bauen Sie ein Custom-CDS auf Standard-Tabellen das die zusätzliche Logik deklarativ ausdrückt.
3. Direkter Aufruf von nicht-released APIs
Sie nutzen ein FBA, eine Klasse oder eine Tabelle direkt, ohne zu wissen ob die Schnittstelle für Erweiterungen freigegeben ist. Das Ergebnis: SAP ändert das Innere, Ihre Erweiterung bricht ohne Hinweis.
Stattdessen: Verwenden Sie nur Released APIs (in der ABAP-Cloud-Umgebung erzwungen, im klassischen ABAP per ATC- Regelsatz prüfbar). Wenn eine benötigte API nicht released ist, Anfrage an SAP – oder Side-by-Side mit Standard-Schnittstellen.
Die drei Erweiterungs-Pfade die erlaubt sind
On-Stack via Enhancement-Frameworks
BAdIs, Enhancement-Spots, Implicit Enhancements. Klassische Pfad für Custom-Logik die im Standard-Lauf eingehängt wird. Lebt im S/4-Mandanten, ist ATC-prüfbar.
On-Stack via RAP
Neue Apps, Custom-Business-Objects, Custom-CDS-basierte Auswertungen. Lebt im S/4-Mandanten, Behaviour Definition kapselt Logik, OData V4 + Fiori Elements liefern die UI. Siehe RAP-Applikation im S/4-Stack.
Side-by-Side via ABAP Cloud / BTP
Eigenständige Services mit eigenem Lifecycle. Lebt im BTP-Subaccount, kommuniziert via Destinations zum S/4, ATC-Pflicht-Regelsatz erzwingt die Released-API-Disziplin. Siehe ABAP Side-by-Side auf BTP.
ATC als Erzwinger statt Predigt
Die Clean-Core-Regeln sind nur dann robust, wenn sie technisch erzwungen werden. Wir richten den ATC mit drei Regelsätzen ein:
- Released-API-Check – jeder Custom-Code wird auf direkte Aufrufe nicht-released APIs gescannt
- Modify-Detection – Standard-Objekte mit Modifikation werden als Pflicht-Finding markiert
- Z-Tabellen-Patterns – Z-Tabellen die Standard-Felder mit ähnlichen Namen tragen werden als Verdacht-Finding aufgeführt
Diese Regeln laufen in der Pipeline, nicht erst im Code-Review. Damit ist Clean Core nicht eine Frage der Disziplin sondern eine Frage des Workflows.
Praxis-Übergang
Bei Bestandscustomer (Brownfield-Kandidaten) gibt es immer Verstoss-Stellen. Wir behandeln sie wie Tier-2 im Custom-Code-Cleanup: priorisiert ja, aber nicht alle gleichzeitig. Die ATC-Regeln werden für Neuentwicklungen sofort aktiv, für Bestand schrittweise zurückgezogen mit klarer Sanierungs-Reihenfolge.
