Clean Core in SAP S/4HANA – Konzept und Umsetzung
6 Beiträge
•
Seite 1 von 1
6 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 / 2041 / 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 / 2041 / 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?
Interessante Fragestellung.
D&P bevorzugt das direkte Lesen des Materialstamms. Mit Releasewechsel 6.4D (oder war es 4.6C?) hat SAP die Historientabellen für Betände/Bewertung eingeführt. Seid dem stehen die alten Daten in der MARDH/MBEWH. Ist nur blöd wenn man das im Releasewechsel nicht bemerkt und man weiterhin nur MARD/MBEW ließt um die Werte aus den Vorperioden zu ermitteln. Nachder ersten Erkenntnis waren viele ZProgramme schnell angepasst, doch oh Wunder die Ergebnisse stimmten immer noch nicht. Man muss halt Wissen, dass SAP nur neue Periodensätze anlegt, wenn es auch Buchungen gab. Sonst gilt der letzte Satz auch für die nächsten Perioden. Also wieder alle ZProgramme auf die neue Logik anpassen.
Hätte es eine API geben, die die benötigten Daten zum Material liefert, wäre die Änderung im Datenmodell nicht schlimm gewesen, solange SAP die API ebenfalls auf das neue Datenmodell anpasst.
Und genau das ist der Gedanke hinter CleanCore: Die freigebene API ändert sich nicht mehr. Evtl. kommen "nur" weitere optionale Daten/Funktionen hinzu. Dann kann SAP am Datenmodell schrauben, die API inter anpassen und die ZProgramme laufen unberührt weiter.
Bei den APIs zeigt aber auch das Problem: CleanCore kann ich nicht implementieren, solange SAP nicht alle benötigten APIs anbietet. Im Rahmen der Lieferverarbeitung wird das deutlich: Es gibt kaum freigebene APIs um Lieferung anzulegen/zu ändern. Wenn es APIs gibt, sind die immer in der Funktion limitiert. Also nimmt man was SAP anbietet, egal ob offiziell freigeben. Anlage über die Sammelgang-FuBas, Änderungen über WS_UPDATE_DELIVERY_2 (der wird eh von allen SAP APIs aufgerufen).
Aber so kann ich keinen CleanCore anbieten, der 100% Releaseupdate fähig ist.
Selbst SAP "leidet" unter den fehlenden APIs. Für BusinessPartner muss aufwändig das CVI eingerichtet werden, damit die neuen BPs ihren Weg in die alten Strukturen der Debitoren/Kreditoren Tabellen finden. Wieso macht SAP das? BPs bringen doch die benötigten APIs für die Datenbeschaffung mit. Weil SAP selber an zu vielen Stellen in ihrem Code direkt auf die alten Datenbanktabellen zugreift. Der Aufwand diese Zugriffe alle auf APIs umzustellen ist selbst für SAP eine zu große Nummer. Also führt man das neue Modell ein, integriert aber alles zurück ins alte Model, damit der alte Code sicher weiter läuft....
D&P bevorzugt das direkte Lesen des Materialstamms. Mit Releasewechsel 6.4D (oder war es 4.6C?) hat SAP die Historientabellen für Betände/Bewertung eingeführt. Seid dem stehen die alten Daten in der MARDH/MBEWH. Ist nur blöd wenn man das im Releasewechsel nicht bemerkt und man weiterhin nur MARD/MBEW ließt um die Werte aus den Vorperioden zu ermitteln. Nachder ersten Erkenntnis waren viele ZProgramme schnell angepasst, doch oh Wunder die Ergebnisse stimmten immer noch nicht. Man muss halt Wissen, dass SAP nur neue Periodensätze anlegt, wenn es auch Buchungen gab. Sonst gilt der letzte Satz auch für die nächsten Perioden. Also wieder alle ZProgramme auf die neue Logik anpassen.
Hätte es eine API geben, die die benötigten Daten zum Material liefert, wäre die Änderung im Datenmodell nicht schlimm gewesen, solange SAP die API ebenfalls auf das neue Datenmodell anpasst.
Und genau das ist der Gedanke hinter CleanCore: Die freigebene API ändert sich nicht mehr. Evtl. kommen "nur" weitere optionale Daten/Funktionen hinzu. Dann kann SAP am Datenmodell schrauben, die API inter anpassen und die ZProgramme laufen unberührt weiter.
Bei den APIs zeigt aber auch das Problem: CleanCore kann ich nicht implementieren, solange SAP nicht alle benötigten APIs anbietet. Im Rahmen der Lieferverarbeitung wird das deutlich: Es gibt kaum freigebene APIs um Lieferung anzulegen/zu ändern. Wenn es APIs gibt, sind die immer in der Funktion limitiert. Also nimmt man was SAP anbietet, egal ob offiziell freigeben. Anlage über die Sammelgang-FuBas, Änderungen über WS_UPDATE_DELIVERY_2 (der wird eh von allen SAP APIs aufgerufen).
Aber so kann ich keinen CleanCore anbieten, der 100% Releaseupdate fähig ist.
Selbst SAP "leidet" unter den fehlenden APIs. Für BusinessPartner muss aufwändig das CVI eingerichtet werden, damit die neuen BPs ihren Weg in die alten Strukturen der Debitoren/Kreditoren Tabellen finden. Wieso macht SAP das? BPs bringen doch die benötigten APIs für die Datenbeschaffung mit. Weil SAP selber an zu vielen Stellen in ihrem Code direkt auf die alten Datenbanktabellen zugreift. Der Aufwand diese Zugriffe alle auf APIs umzustellen ist selbst für SAP eine zu große Nummer. Also führt man das neue Modell ein, integriert aber alles zurück ins alte Model, damit der alte Code sicher weiter läuft....
Folgende Benutzer bedankten sich beim Autor JHM für den Beitrag:
black_adept
Gruß Hendrik
Beitrag
von DeathAndPain (Top Expert / 2041 / 276 /
428
)
»
Das Lesen der MARA war nur ein Beispiel, weil ich den Eindruck habe, dass viel mehr Leute diese Tabelle kennen als, sagen wir, die PA0001. Meine SD/MM-Zeit ist 2010 zu Ende gegangen, noch bevor meine damalige Firma die von Dir genannten Releases eingeführt hat. Insofern überrascht es nicht, dass ich die von Dir genannten Entwicklungen in MM nicht mehr mitbekommen habe (da ich seitdem HCM mache).
Allerdings sehe ich das so, dass man schauen und testen muss, wenn man Standardtabellen liest. Hätte ich damals mit MM weitergemacht, bin ich überzeugt, dass ich den von Dir genannten Schwenk mitbekommen hätte. Hätte ich später mit MM angefangen, hätte ich probiert und gemacht und bald gemerkt, dass die von mir gelesenen Daten nur unter bestimmten Umständen stimmen. Das hätte ich dann schnell geklärt.
Klar kann man so ziemlich alles über irgendwelche FBs oder Methoden machen, die die SAP bereitstellt (und sich dabei die verschiedensten Namen für dasselbe einfallen lässt. Eine Klasse, die BAPI heißt, ist trotzdem eine Klasse, und als Verwender interessiert es mich nicht die Bohne, ob SAP sie "freigegebene Klasse" oder "BAPI" nennt).
Aber das ist häufig wenig performant, gerade wenn man mit einem direkten SELECT alle Daten auf einmal in eine Puffertabelle einlesen könnte, die Schnittstelle des BAPI aber nur eine einzelne Materialnummer (um bei dem Beispiel zu bleiben) akzeptiert, so dass man sie für jedes Material einzeln aufrufen muss. In vielen Fällen halte ich das noch nicht einmal für übersichtlicher, weil solche Methoden in aller Regel deutlich mehr Daten liefern, als man tatsächlich im jeweiligen Anwendungsfall braucht, wohingegen der Leser meines SELECT genau die Spalten sieht, die ich selektiere, weil sie relevant sind (klappt natürlich nur, wenn man kein fauler SELECT *-Programmierer ist, aber das ist seit S4 zum Glück ohnehin nicht mehr so in Mode).
Es sei denn, die API macht nicht genau das, was ich als Aufrufer erwarte. Bei meinem ABAP-Code sehe ich ganz präzise, was er macht. Bei einer API kann ich nur hoffen, genau verstanden zu haben, was sie tut. Ich erinnere an Daten- vs Personenauswahlzeiträume bei logischen Datenbanken. Da haben auch die wenigsten den Überblick behalten (wobei es in dem Fall auch Anwender betroffen hat, aber auf logische Datenbanken kann man ja auch aus ABAP zugreifen).Hätte es eine API geben, die die benötigten Daten zum Material liefert, wäre die Änderung im Datenmodell nicht schlimm gewesen, solange SAP die API ebenfalls auf das neue Datenmodell anpasst.
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
letzen Monat von codemaster1 2 / 314780
letzen Monat von codemaster1 2 / 314780
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
letzen Monat von codemaster1 2 / 314780
letzen Monat von codemaster1 2 / 314780