Clean Core in SAP S/4HANA – Konzept und Umsetzung
4 Beiträge
•
Seite 1 von 1
4 Beiträge
Seite 1 von 1
Hallo Leute,
Ich arbeite mich gerade ins Thema "Clean Core" ein – mein Ausbilder hat mich gebeten, einmal völlig unvoreingenommen zu prüfen, was sich hinter dem Begriff wirklich verbirgt. Da ich aus der Python-/Data-Welt komme, ist vieles für mich neu, und ich hoffe auf euer Feedback, ob ich alles richtig verstanden habe.
Soweit ich es sehe, ist Clean Core ein Entwicklungs-Konzept für SAP S/4HANA: Der Standard-Kern soll möglichst unangetastet bleiben. Statt Standardcode zu ändern oder direkt auf Tabellen wie MARA zuzugreifen, läuft die Erweiterung über Extension Points, freigegebene (released) APIs oder ergänzende Anwendungen in der Cloud Platform (BTP).
Das erinnert mich von der Idee her an "Separation of Concerns" aus der sauberen Software-Architektur. Nur klingt der Sprung vom klassischen ABAP (Dynpro, ALV, direkte SQL-Reads) hin zu CDS-Views und dem RAP-Framework deutlich radikaler – gerade wenn man über Jahre gewachsenen Code betrachtet.
Was mich konkret interessiert:
Grüße Nico
Ich arbeite mich gerade ins Thema "Clean Core" ein – mein Ausbilder hat mich gebeten, einmal völlig unvoreingenommen zu prüfen, was sich hinter dem Begriff wirklich verbirgt. Da ich aus der Python-/Data-Welt komme, ist vieles für mich neu, und ich hoffe auf euer Feedback, ob ich alles richtig verstanden habe.
Soweit ich es sehe, ist Clean Core ein Entwicklungs-Konzept für SAP S/4HANA: Der Standard-Kern soll möglichst unangetastet bleiben. Statt Standardcode zu ändern oder direkt auf Tabellen wie MARA zuzugreifen, läuft die Erweiterung über Extension Points, freigegebene (released) APIs oder ergänzende Anwendungen in der Cloud Platform (BTP).
Das erinnert mich von der Idee her an "Separation of Concerns" aus der sauberen Software-Architektur. Nur klingt der Sprung vom klassischen ABAP (Dynpro, ALV, direkte SQL-Reads) hin zu CDS-Views und dem RAP-Framework deutlich radikaler – gerade wenn man über Jahre gewachsenen Code betrachtet.
Was mich konkret interessiert:
- Wie strikt ist das Verbot des direkten Tabellenzugriffs wirklich? Gibt es legitime Ausnahmen?
- Lohnt sich der Aufwand vor allem bei Greenfield-Projekten oder auch beim Umbau bestehender Systeme?
- Wie prüft ihr, ob der vorhandene Code sauber wird – z.B. über die ATC-Checks?
Grüße Nico
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von DeathAndPain (Top Expert / 2040 / 276 /
428
)
»
Also für mich klingt Deine Definition von "Clean Core" im wesentlichen wie "professionell arbeiten". 😃
Standardcode ändert man nicht, denn solche Änderungen sind beim nächsten Release-Upgrade häufig weg (bzw. jede einzelne muss mit dem Modifikationsassistenten manuell nachgezogen werden) und womöglich noch nicht mal kompatibel zur neuen Version. Maximal kann man implizite Enhancements machen - und auch das sollte nur eine Lösung für den Notfall sein.
Bei Zugriffen auf Standardtabellen muss man unterscheiden. Lesezugriffe sind in aller Regel harmlos. Klar muss man wissen, was die gelesenen Daten bedeuten (und dabei auch mögliche Pufferungsproblematiken im Auge haben (geänderte Daten könnten noch nicht in die Datenbank zurückgeschrieben sein)), aber im Großen und Ganzen liest eigentlich jeder ABAP-Programmierer aus den Standardtabellen, und meist ist auch offensichtlich, was wo gespeichert ist.
Anders sieht es beim Schreiben aus. Zum einen wegen jener Pufferungsproblematiken, zum anderen, weil außerhalb der SAP niemand sicher sagen kann, was für Querabhängigkeiten (Konsistenzkriterien) es gibt. Z.B. könnte Schreiben in Tabelle A erfordern, dass immer auch ein ergänzender Datensatz in Tabelle B geschrieben werden muss, sonst wird die Datenbank inkonsistent. Häufig kann man spekulieren, dass da wohl nichts sein wird, aber genau wissen tut es nur, wer Zugang zur internen Doku von SAP hat - und das ist nur die SAP selbst.
Es ist auch unnötig, in Standardtabellen zu schreiben. Fast immer gibt es dafür passende Fubas oder Klassen, und wenn alle Stricke reißen, kann man sich mit einem programmierten Batch Input (per SHDB aufzeichnen, in Programmcode wandeln, anpassen und dann per CALL TRANSACTION aufrufen) retten.
Standardcode ändert man nicht, denn solche Änderungen sind beim nächsten Release-Upgrade häufig weg (bzw. jede einzelne muss mit dem Modifikationsassistenten manuell nachgezogen werden) und womöglich noch nicht mal kompatibel zur neuen Version. Maximal kann man implizite Enhancements machen - und auch das sollte nur eine Lösung für den Notfall sein.
Bei Zugriffen auf Standardtabellen muss man unterscheiden. Lesezugriffe sind in aller Regel harmlos. Klar muss man wissen, was die gelesenen Daten bedeuten (und dabei auch mögliche Pufferungsproblematiken im Auge haben (geänderte Daten könnten noch nicht in die Datenbank zurückgeschrieben sein)), aber im Großen und Ganzen liest eigentlich jeder ABAP-Programmierer aus den Standardtabellen, und meist ist auch offensichtlich, was wo gespeichert ist.
Anders sieht es beim Schreiben aus. Zum einen wegen jener Pufferungsproblematiken, zum anderen, weil außerhalb der SAP niemand sicher sagen kann, was für Querabhängigkeiten (Konsistenzkriterien) es gibt. Z.B. könnte Schreiben in Tabelle A erfordern, dass immer auch ein ergänzender Datensatz in Tabelle B geschrieben werden muss, sonst wird die Datenbank inkonsistent. Häufig kann man spekulieren, dass da wohl nichts sein wird, aber genau wissen tut es nur, wer Zugang zur internen Doku von SAP hat - und das ist nur die SAP selbst.
Es ist auch unnötig, in Standardtabellen zu schreiben. Fast immer gibt es dafür passende Fubas oder Klassen, und wenn alle Stricke reißen, kann man sich mit einem programmierten Batch Input (per SHDB aufzeichnen, in Programmcode wandeln, anpassen und dann per CALL TRANSACTION aufrufen) retten.
Wenn wir einer Partei die Regierungsbeteiligung verweigern, die von einer Mehrheit gewählt worden ist, weil wir diese Partei für schlecht halten, da wir einer anderen Partei angehören, wie ist dann unsere eigene demokratische Gesinnung zu bewerten?
Was DAP schreibt ist alles richtig, trifft aber nicht den "Kern" von der Clean-Core-Philosophie von SAP. Dass man den Standard nicht modifiziert und nicht direkt in SAP-Tabellen schreibt, war aber schon lange vor S/4HANA gute Praxis und ist vor allem eine Frage von Wartbarkeit und Upgradefähigkeit. Der eigentliche Kern von Clean Core ist die Entkopplung von den internen Implementierungsdetails des SAP-Standards. Deshalb stehen heute Released APIs, Released CDS Views, RAP Business Objects und das ABAP-Cloud-Modell so stark im Fokus.
Die entscheidende Frage ist nicht: „Darf ich auf MARA zugreifen?“ sondern: „Greife ich auf einen von SAP freigegebenen Vertrag zu oder auf eine interne Implementierung?“
Ein direkter Lesezugriff auf MARA funktioniert heute möglicherweise problemlos. Die Eigenentwicklung ist damit aber weiterhin an ein konkretes Datenmodell gekoppelt. Erfolgt der Zugriff dagegen über eine freigegebene CDS-View oder API, spielt die technische Persistenz dahinter keine Rolle mehr. SAP kann die Implementierung ändern, ohne dass die Eigenentwicklung angepasst werden muss.
Genau daraus ergibt sich der strategische Nutzen von Clean Core: Nicht nur das nächste Upgrade wird einfacher, sondern auch größere Architekturwechsel. Je konsequenter eine Lösung ausschließlich auf freigegebenen Objekten basiert, desto robuster wird sie gegenüber Änderungen im SAP-Standard und desto leichter lassen sich Szenarien wie der Wechsel von S/4HANA On-Premise in die Cloud unterstützen. Somit gehört der Clean-Core-Ansatz aus meiner Sicht direkt zur Cloud-Strategie von SAP - und daraus ergibt sich auch die persönliche bzw. unternehmensgebundene Priorisierung: Wenn es völlig utopisch ist, dass man in die Public Cloud wechselt, dann sind die "klassischen" ABAP-Richtlinien für professionelle Entwicklung wichtiger als eine Clean-Core-Architektur.
Die entscheidende Frage ist nicht: „Darf ich auf MARA zugreifen?“ sondern: „Greife ich auf einen von SAP freigegebenen Vertrag zu oder auf eine interne Implementierung?“
Ein direkter Lesezugriff auf MARA funktioniert heute möglicherweise problemlos. Die Eigenentwicklung ist damit aber weiterhin an ein konkretes Datenmodell gekoppelt. Erfolgt der Zugriff dagegen über eine freigegebene CDS-View oder API, spielt die technische Persistenz dahinter keine Rolle mehr. SAP kann die Implementierung ändern, ohne dass die Eigenentwicklung angepasst werden muss.
Genau daraus ergibt sich der strategische Nutzen von Clean Core: Nicht nur das nächste Upgrade wird einfacher, sondern auch größere Architekturwechsel. Je konsequenter eine Lösung ausschließlich auf freigegebenen Objekten basiert, desto robuster wird sie gegenüber Änderungen im SAP-Standard und desto leichter lassen sich Szenarien wie der Wechsel von S/4HANA On-Premise in die Cloud unterstützen. Somit gehört der Clean-Core-Ansatz aus meiner Sicht direkt zur Cloud-Strategie von SAP - und daraus ergibt sich auch die persönliche bzw. unternehmensgebundene Priorisierung: Wenn es völlig utopisch ist, dass man in die Public Cloud wechselt, dann sind die "klassischen" ABAP-Richtlinien für professionelle Entwicklung wichtiger als eine Clean-Core-Architektur.
Beitrag
von DeathAndPain (Top Expert / 2040 / 276 /
428
)
»
Zumal die ganzen Abstraktionslayer natürlich zum einen auch Performance kosten und zum anderen jedes Layer die Chance SAP-seitiger Bugs oder vom Nutzer unerwarteter Verhaltensweisen birgt. Wenn ich mit den Selektionsbedingungen meines eigenen SELECTs aus der MARA eine Materialnummer lese, dann weiß ich genau, was ich habe. Lasse ich mir von irgendeiner Funktionalität ein "Material" übergeben, dann hoffe ich verstanden zu haben, was ich bekomme - könnte mich in irgendeiner Randbedingung aber auch täuschen. Genau das war (neben der miesen Performance) auch eine Schwachstelle der ollen logischen Datenbanken.
Der Performanceaspekt ist ein Stück weit subjektiver Natur. Es ist deutlich wahrzunehmen, dass heutige Systeme schlampige Programmierung viel mehr verzeihen als früher, weil die Leistungsfähigkeit heutiger Hardware es häufig kaum noch wahrnehmbar macht, wie effizient ein Code läuft.
Auf der anderen Seite bin zumindest ich persönlich ziemlich genervt, dass trotz aller Hardwarefortschritte heutige Systeme sich oft deutlich träger anfühlen als früher. Ein 486er hat viel schneller in sein MS-DOS gebootet als manch heutiger Windows-Rechner, und auch die Anwendungen in MS-DOS haben vielfach bei jedem Klick sofort reagiert, wohingegen man heute bei MS Word oder LibreOffice Writer oft schon sekundenlang wartet, bis sich nur das Fenster "Absatz" öffnet, in dem man die Abstände usw. einstellen kann. Meine Erwartung ist einfach, dass ein Rechner ein Werkzeug ist, mit dem man flüssig arbeiten kann. Bei einer Schere warte ich auch nicht eine Sekunde darauf, bis sie sich öffnet, damit ich damit losschneiden kann. Die arbeitet so schnell, wie ich es tue, ohne mich wahrnehmbar aufzuhalten.
Und wenn ich mir überlege, wie schnell ein C64 gebootet hat...
Der Performanceaspekt ist ein Stück weit subjektiver Natur. Es ist deutlich wahrzunehmen, dass heutige Systeme schlampige Programmierung viel mehr verzeihen als früher, weil die Leistungsfähigkeit heutiger Hardware es häufig kaum noch wahrnehmbar macht, wie effizient ein Code läuft.
Auf der anderen Seite bin zumindest ich persönlich ziemlich genervt, dass trotz aller Hardwarefortschritte heutige Systeme sich oft deutlich träger anfühlen als früher. Ein 486er hat viel schneller in sein MS-DOS gebootet als manch heutiger Windows-Rechner, und auch die Anwendungen in MS-DOS haben vielfach bei jedem Klick sofort reagiert, wohingegen man heute bei MS Word oder LibreOffice Writer oft schon sekundenlang wartet, bis sich nur das Fenster "Absatz" öffnet, in dem man die Abstände usw. einstellen kann. Meine Erwartung ist einfach, dass ein Rechner ein Werkzeug ist, mit dem man flüssig arbeiten kann. Bei einer Schere warte ich auch nicht eine Sekunde darauf, bis sie sich öffnet, damit ich damit losschneiden kann. Die arbeitet so schnell, wie ich es tue, ohne mich wahrnehmbar aufzuhalten.
Und wenn ich mir überlege, wie schnell ein C64 gebootet hat...
Wenn wir einer Partei die Regierungsbeteiligung verweigern, die von einer Mehrheit gewählt worden ist, weil wir diese Partei für schlecht halten, da wir einer anderen Partei angehören, wie ist dann unsere eigene demokratische Gesinnung zu bewerten?
Seite 1 von 1
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
GLD Preis Verrechnung mit inkl. Fracht- / Zollkosten für eine Analyse wieder zerlegen
vor 5 Wochen von codemaster1 2 / 163210
vor 5 Wochen von codemaster1 2 / 163210
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Vergleichbare Themen
Aktuelle Forenbeiträge
GLD Preis Verrechnung mit inkl. Fracht- / Zollkosten für eine Analyse wieder zerlegen
vor 5 Wochen von codemaster1 2 / 163210
vor 5 Wochen von codemaster1 2 / 163210
Unbeantwortete Forenbeiträge
Custom logic - Feld wieder initialisieren (BADI CRMS4_SERV_CUST_H_MODIFY)
July 2026 von JanR 1 / 471696
July 2026 von JanR 1 / 471696