
ABAP Cloud - Level Concept und nun?
Öfters gab es nun die Frage: Was nach mit dem neuen Level Concept machen und was bedeutet nun eigentlich die neue Definition von Clean Core? Lass uns einmal in die Details schauen.
Inhaltsverzeichnis
In diesem Artikel beschäftigen wir uns mit dem Clean Core Concept und schauen uns die Sicht aus mehreren Perspektiven an, wie es nun eigentlich damit weiter geht.
Einleitung
Das neue Clean Core Level Concept ist nun seit knapp zwei Monaten released und öfters erreichte uns die Frage, wie es bun eigentlich damit weiter geht? Zum einen gibt es nun Unternehmen, die bereits mit einer Transformation Richtung ABAP Cloud angefangen haben und nach dem 3-TIER Modell ihre verschiedenen Layer im System erstellt haben. Zum anderen gibt es die Gruppe der Unternehmen die das Konzept des Clean Core's nun adaptieren wollen und sich fragen, wo sie eigentlich anfangen sollten.
Strategien
In diesem Kapitel schauen wir uns einmal die Strategien und Herangehensweisen an, wie du dich nun dem neuen Clean Core Level Concept nähern kannst.
Migration 3-TIER
Fangen wir erst einmal mit dem leichtesten Schritt an. Wenn du bereits das 3-TIER Modell am Laufen hast, dann musst du eigentlich nicht viel ändern, außer vielleicht den Namen deiner Paketstrukturen und wie du damit umgehen möchtest. Grundsätzlich wird TIER-1 bzw. nun Level A weiterverwendet. Die Anlage von Software Komponenten für die Entwicklung von ABAP Cloud bleibt Best-Practice, da du als Entwickler damit automatisch Clean Core und Cloud Ready entwickelst. Damit musst du dir erst einmal keine Gedanken machen, ob deine verwendete API wirklich Clean Core ist, wenn du dich auf die freigegebenen APIs verlässt.
TIER-3 bzw. Classic ABAP (Level B-D) muss nicht mehr zwingend unter einem Paket zusammengefasst werden, du kannst allerdings das Oberpaket bestehen lassen, wenn du bereits eine Bündelung der Objekte vorgenommen hast. Damit kannst du außerhalb der Software Komponenten weiter deine normalen Paketstrukturen verwenden.
Neuanfang
Beschäftigst du dich noch ganz neu mit dem Thema, dann gibt es einige Dinge zu beachten, die du dir die nächste Zeit vor allem anschauen solltest. Zum einen solltest du nun dein System (>= S/4HANA 2022) erst einmal fit für ABAP Cloud machen. Dazu zählt die Einrichtung der neuen ABAP Cloud APIs, wie E-Mail, Software Komponenten, bgPF, Business Configuration und noch einige mehr. Weitere Infos dazu erhältst du in unserer Checkliste zur Einrichtung, diese wurde noch einmal auf das Level Concept angepasst.
Gemeinsamkeiten
Was haben beide Ansätze erst einmal gleich? Dazu schauen wir uns nun in verschiedenen Abschnitten die unterschiedlichen Punkte an. Dazu erst einmal eine Übersicht der neuen Struktur, die wir dann in den folgenden Abschnitten als Referenz verwenden.
Neue Entwicklungen
Neue Entwicklungen solltest du daher in ABAP Cloud und damit mit einer Software Komponente (SWC) beginnen. Handelt es sich um eine neue Erweiterung des Standards, dann solltest du prüfen, ob hier ABAP Cloud unterstützt wird oder ob es sich dabei um eine klassische Erweiterung handelt, mehr dazu im Abschnitt unten.
Dabei empfehlen wir weiterhin die Anlage von SWCs für jede Erweiterung. Damit kannst du verschiedene Punkte abdecken, die zu einer besseren Software Qualität im System beitragen:
- Monster-Pakete - Damit verhinderst du, dass zu große Pakete im System entstehen, wo am Ende keiner mehr die Übersicht hat. Auch vermischen sich damit verschiedene Projekte und Ressourcen nicht mehr.
- Strukturierung - Automatisch stellst du eine einfache und übersichtliche Strukturierung innerhalb der Pakete sicher. Wo liegen die Apps, wo gibt es Schnittstellen, welche Objekte werden freigegeben? Damit sollten sich auch neue Entwickler in einer Erweiterung zurechtfinden.
- APIs - Die Objekte sind erst einmal sauber von anderen SWC getrennt, möchtest du etwas woanders nutzen, dann musst du zuerst einen C1 Contract dafür setzen. Dadurch machst du dir Gedanken, wie die Objekte vom Design her beschaffen sein sollten, aber auch welche Objekte vielleicht durch andere Komponenten genutzt werden.
API Enablement
Wie oben auf der Übersicht dargestellt, verwenden wir für die APIs im System eigene Pakete (ZCA_RELEASED_APIS) und Strukturen. Damit sollen alle Entwickler einen schnellen Überblick über die freigegebenen Wrapper erhalten. Zum einen gehören vielleicht noch weitere Objekte zum Wrapper, die aber nicht freigegeben sind, zum anderen wollen wir vermeiden etwas doppelt zu entwickeln und damit höhere Wartungskosten zu verursachen. Eine eigene Software Komponente für dieses Paket ist nicht zwingend notwendig, es kann auch die klassische HOME Komponente verwendet werden.
Grundsätzlich hat sich an der Erstellung von Wrappern nichts geändert und wir folgen den Best-Practices, welche Objekte sich zum Wrapper eignen. Mit den neuen Level B (Classic APIs) Artefakten, bekommen wir noch einmal einen Hinweis, welche Objekte wir sehr gut für Wrapper verwenden können.
Classic Extensibility
Hier kommt dann auch der neue Teil der Erweiterungen. Bisher waren wir angehalten, so viel wie möglich in ABAP Cloud umzusetzen, auch wenn wir klassische Erweiterungen durchgeführt haben. Solltest du nun einen klassischen BADI ausprägen oder einen klassischen User-Exit, den du zwingend für deinen Prozess benötigst, dann solltest du die Implementierung in Classic ABAP machen. Damit sparst du dir Wrapper und andere Komponenten, die du auf die verschiedenen Layer auslagern musst. Grundsätzlich solltest du natürlich sicherstellen, dass du die aktuellsten APIs dabei verwendest. Also keinen SELECT auf die klassischen Tabellen, sondern die freigegebenen Core Data Services nutzen oder selbst Wrapper erstellen.
Hier sollen ebenfalls die neuen ABAP Test Cockpit (ATC) Prüfungen unterstützen, die dir sagen, ob es für eine API einen Nachfolger gibt und es auch die richtige API für diesen Fall ist. Daher auch die Empfehlung, ATC für die Governance zu nutzen, um dich als Entwickler zu unterstützen.
Technologien
Wichtig für weitere Bewertungen ist auch der Hinweis 3578329, hier bekommst du wichtige Informationen zu Technologien und wie sie innerhalb vom Level Concept eingeordnet werden. Schauen wir uns dazu ein paar Beispiele aus der Liste an:
- Classic Batch Job (SM37) - Als Level B klassifiziert, damit Clean Core, aber nicht Cloud Ready. Hier gibt es mittlerweile eine gute Alternative mit dem Application Job.
- Business Object Processing Framework (BOPF) - Level B und damit Clean Core. Neue Anwendungen solltest du allerdings lieber mit RAP erstellen. Mittlerweile gibt es für CDS-basiertes BOPF auch Migrationspfade und Tools, um es mehr Richtung RAP zu bringen.
- SAP Query - Wird als Level C eingestuft, da hier Zugriffe vor allem auf Standardtabellen modelliert werden und nicht auf Core Data Services.
- Workflow - Sowohl Classic, auch Flexible, Workflow werden als Level B eingestuft und können damit für Clean Core verwendet werden. Als Cloud Ready wird allerdings nur SAP Build Process Automation eingestuft.
- ABAP Report - Der klassische Report wird als Clean Core (Level B) eingestuft, du solltest neue Anwendungen allerdings mit SAP Fiori umsetzen. Grundsätzlich musste du damit erst einmal nicht mehr zwingend alle Reports auf einen Schlag ablösen. Vor allem bei komplexen Transaktionen und Frameworks noch fraglich.
Reise
Damit kann die Reise nach Clean Core starten. Grundsätzlich solltest du im Browfield Fall an Level D zuerst arbeiten und diesen auf das Nötigste reduzieren. Die zwingend benötigten Use-Cases kannst du dann dokumentieren und auf erledigt setzen. Grundsätzlich werden sehr wahrscheinlich noch einige Level D Findings bleiben, wo es einfach keine Alternative gibt. Bist du damit fertig, solltest du dir dann die Findings in Level C anschauen. Diese sind erst Conditional Clean Core, können sich als in Zukunft ändern, hier macht es durchaus Sinn, nach Alternativen zu schauen.
Als letzten Punkt solltest du dann die Modernisierung Richtung Frontend anschauen. Reports zu Fiori und Fiori Elements Anwendungen transformieren, kann Prozesse einfacher machen. Wenn komplexe GUI Anwendungen aufgebrochen werden und Fiori Anwendungen mit schnellerem und einfacherem Arbeitsflow entstehen, kann das zusätzlich die Produktivität der Kollegen erhöhen. Grundsätzlich wird dann auch die Einheitlichkeit bei der Benutzeroberfläche hergestellt, da Fiori Anwendungen das Ziel sind.
Hinweis: Die Grafik soll nur die Reise Richtung Clean Core symbolisieren. Bereits mit der Abarbeitung von Level D bist du zu einem sehr guten Teil Clean Core.
Business Technology Plattform
Die BTP ist ein wichtiger Faktor, wenn es um Innovationen und Cloud-Lösungen geht und sollte daher von Unternehmen auf jeden Fall in ihrer Architektur mitberücksichtigt werden. Allerdings sehen wir noch sehr oft bei Beratungshäusern auf den Folien und Hinweisen, dass nur mit Hilfe der BTP Clean Core erreicht werden kann. Diese Aussage ist aktuell falsch, da bereits mit dem Clean Core Level Concept und einer korrekten Anwendung Clean Core erreicht werden kann.
Keine Erweiterung auf dem System durchzuführen ist teilweise nicht möglich, da es bestimmte Szenarien gibt, die einfach eng gekoppelt sind und On-Stack umgesetzt werden sollten. Selbst in einer Public Cloud Lösung müssen Szenarien auf dem System umgesetzt werden, da sie Side-by-Side nicht möglich sind. Side-by-Side Entwicklung sollte da eingesetzt werden, wo es Sinn ergibt und nicht als Clean Core Lösung verkauft werden.
Fazit
Damit sollte nun hoffentlich der Weg vom 3-TIER Modell zum Level Concept etwas klarer sein und für Starter, sowie die ABAP Cloud Veteranen, einfacher vonstatten gehen. Grundsätzlich sollte nun aber auch klar sein, woran die nächste Zeit gearbeitet werden kann und das der Berg an Arbeit verwaltbar und erreichbar bleibt.

