Moderne ABAP Architektur
Moderne Frameworks und Anwendungen in ABAP bauen? Welche Bausteine sind eigentlich dafür nötig und was solltest du in den verschiedenen Bereichen beachten? Mehr dazu im Artikel.
Inhaltsverzeichnis
Wie könnte heute eigentlich eine sinnvolle ABAP Architektur aussehen, wenn es um moderne ABAP Anwendungen geht? Schauen wir uns dazu eine Referenz in diesem Artikel an.
Einleitung
Wie sieht eigentlich eine neue ABAP-Architektur aus, wenn wir auf die moderne ABAP-Entwicklung schauen? Dabei werden wir in diesem Artikel auf die vier Säulen eingehen und uns im Detail die ABAP OO Säule einmal genauer anschauen. Zu den anderen Parts hatten wir bereits in der Vergangenheit Artikel gemacht, die das Vorgehen und die Nutzung noch einmal im Detail beschreiben. Diese Artikel sind in den jeweiligen Abschnitten verlinkt, wobei wir die eigentlichen Abschnitte dann eher kurz halten.
Architektur
Schauen wir auf eine mögliche moderne Architektur, gibt es insgesamt vier Grundsäulen, die wir dabei berücksichtigen wollen. ABAP OO ist die Grundsäule für die komplette ABAP-Entwicklung, den Bau von Anwendungen und Frameworks aus technischer Sicht ohne Frontend und zur Verknüpfung sowie dem Aufbau von Schnittstellen. Die zweite Säule ist die RAP-Entwicklung, wenn wir Business-Objekte bauen wollen und Frontend-Anwendungen zur Verfügung stellen wollen. Die dritte Säule ist ABAP Cloud, wenn es um die Standardisierung und die Clean-Core-Entwicklung geht, aber vor allem auch um die Nutzung von freigegebenen APIs für unsere Entwicklung. Die vierte Säule ist Fiori Elements zur schnellen Entwicklung von UIs und zur Bereitstellung von neuen Anwendungen für uns selbst und für unsere Fachbereiche.
Säulen
Schauen wir uns deshalb in diesem Abschnitt noch einmal die 4 Säulen im Detail an und beschreiben, für was wir diese benötigen und auf welche Punkte in der modernen Entwicklung zu achten ist.
ABAP OO
ABAP spielt die wichtigste Rolle bei einer soliden Grundarchitektur, um Fehler aus der Vergangenheit zu korrigieren und Anwendungen zu bauen, die bereit für die Zukunft sind. Dabei stellen wir uns die folgende Architektur vor, wie sie in dem Bild dargestellt wird.
Die eigentliche Basis unseres gesamten Codes bilden dabei die verschiedenen Klassen, die wir implementieren. Jede Klasse sollte dabei ein Interface implementieren, um die Testbarkeit über die verschiedenen Test-Double-Frameworks sicherzustellen. Dabei sollte vermieden werden, statische Klassen oder statische Methoden anzulegen, da diese als nicht wirklich gut testbar gelten (höchstens per TEST SEAM). Ausnahmen sind hier beispielsweise Injector- oder Factory-Klassen, die statische Methoden nutzen, um Instanzen zu erzeugen. Wenn unser kompletter Code in Klassen verfügbar ist, können wir darüber auch Unit-Tests auf alle Objekte setzen, um das Thema Testbarkeit sicherzustellen und ein Sicherheitsnetz für den Entwickler zur Verfügung zu haben, damit wir in Zukunft einfach und flexibel unseren Code testen und erweitern können.
Schauen wir dabei in den unteren Bereich der Grafik, sehen wir die verschiedenen anderen Objekte, die es noch gibt. Diese dienen lediglich als Hüllen zum Aufruf der Klassen. Hier gibt es zum Beispiel den klassischen SEGW Service, der Coding aufruft. Diesen könnten wir in unsere Klassen verschalen, um ihn dort testbar zu machen. Das Gleiche gilt für klassische Programme, wenn wir solche noch einsetzen: Diese rufen am Ende nur unsere Klasse mit der Logik auf, wo auch die Tests liegen.
Der dritte Fall ist der Funktionsbaustein. Funktionsbausteine sind grundsätzlich noch relevant. Wenn wir zum Beispiel auf die verschiedenen Fachmodule schauen, gibt es User-Exits, die auf Funktionsbausteinen basieren. Ebenso benötigen wir noch RFC-Funktionsbausteine für die Kommunikation mit anderen SAP-Systemen oder nach außen. Was du aber nicht mehr machen solltest, ist, den kompletten Code in den Funktionsbaustein zu schreiben, da dieser irgendwann sehr unübersichtlich wird und eine Strukturierung nur schwer umsetzbar ist. Ebenso solltest du an deine neuen und jungen Kollegen denken, die zum Beispiel das Konzept des globalen Datenbereichs in Funktionsgruppen nicht beherrschen oder auch nicht unbedingt lernen wollen. Deshalb sollten Funktionsbausteine lediglich als Hüllen dienen, die die eigentliche Implementierung aufrufen. Pufferlogiken können durchaus auch in Klassen und Singletons dargestellt werden. Grundsätzlich kann man auch sagen, dass Funktionsgruppen mit den ganzen Funktionsbausteinen immer komplett von einem ATC-Check geprüft werden. Deshalb ist es auch vorteilhaft, diese Objekte so klein wie möglich zu halten, um mögliche Findings später ebenfalls im Umfang der eigentlichen Implementierung zu halten.
Der letzte Punkt ist die Datenbank: In der Vergangenheit wurden hier Data Access Objects (kurz DAOs) verwendet, um auch den Zugriff auf die Datenbank mocken zu können. Bist du auf einem neueren System, solltest du hier keine DAOs verwenden, sondern direkt das Test-Double-Framework für Core Data Services und Tabellen nutzen. Dies ist einfacher und überschaubarer zu implementieren.
RAP
Wollen wir ein neues Business-Objekt innerhalb des Systems anlegen, verwenden wir dafür das ABAP RESTful Application Programming Model. Dieses Modell ist mittlerweile der Standard in der ABAP-Cloud-Entwicklung, da es verschiedene Use Cases wie APIs, Frontend-Szenarien und Business-Objekte innerhalb des Systems abbilden kann. Das Modell ist relativ kompliziert in der Erlernung, da es hier viele neue Statements und auch das komplette Framework zu lernen gibt. Über die verschiedenen UI-Annotationen ist es aber leicht möglich, Fiori-Elements-Anwendungen auf diesen Services zu generieren und im System bereitzustellen, was die Flexibilität des Modells erhöht. Deshalb ist neben der eigentlichen ABAP-Architektur das Thema Core Data Services, Annotationen und das RAP-Framework ein wichtiger Punkt, der in eine moderne Architektur gehört.
ABAP Cloud
Die Entwicklung im Clean-Core-Umfeld mit ABAP Cloud ist ein wichtiger, zentraler Bestandteil, um in Zukunft Anwendungen zu bauen, die Clean-Core-ready sind, und uns damit weitere Aufwände im eigentlichen Kern zu ersparen. Deshalb ist dies eine Grundsäule für jegliche Eigenentwicklung und soll uns helfen, standardisierte Anwendungen zu bauen und Standardschnittstellen zu verwenden. Dass wir nebenbei Clean Core werden, ist ein positiver Aspekt. Der wichtigste Aspekt ist aber, dass wir die Anzahl der zu nutzenden Schnittstellen reduzieren und uns Gedanken machen, was wir vom Standard bei uns in der Anwendung verwenden wollen. Gleichzeitig erhalten wir von den ATC-Checks Informationen zu den verwendeten Objekten und ob wir auch die richtigen und freigegebenen Artefakte nutzen. Insgesamt sollte dies eine Standardarchitektur sein. Zwangsläufig kommt das aber auf das verwendete Modul an und die freigegebenen APIs innerhalb dieses Moduls.
Fiori Elements
Fiori Elements ist ein wichtiger Bestandteil der Frontend-Strategie, da es die Generierung der UIs im späteren Verlauf übernimmt. Hier setzen wir ganz klar nicht auf Fiori-Freestyle-Entwicklung, da dies Zeit kostet, die UIs aufzubauen, und den Testaufwand für Individualentwicklungen erhöht. Hier liegt ganz klar der Fokus auf der automatischen Generierung und der Nutzung des Flexible Programming Models, um UIs später erweitern zu können. Dies hält die eigentliche Lernkurve für den ABAP-Entwickler flach und erspart uns wiederum den Test von automatisch generierten UIs, wenn keine Anpassungen des Kunden vorgenommen wurden. Hier setzen wir ganz klar darauf, dass UI-Technologien und Fiori Elements automatisiert bei SAP getestet werden. Solange wir keine eigenen Anpassungen vornehmen, müssen wir die eigentlichen UI-Komponenten überhaupt nicht testen. Mehr Informationen zur Frontend-Strategie entnimmst du diesem Artikel auf unserer Seite.
KI als Hilfsmittel
Als Mittel heutzutage kann man vor allem auf gute Tutorials und das Thema KI schauen. Eine gut definierte KI (Grounding, MCP) kann dir dabei helfen, die richtigen Informationen zu finden, egal, ob es Nachfolger, Core Data Services, die richtige Architektur oder bereits Anwendungen aus dem Standard sind. Ebenso ist KI viel schneller, wenn es darum geht, größere Mengen an Daten zu verarbeiten und einen Extrakt herauszuziehen. Gezielt kannst du sie auch nutzen, um verschiedene Bestandteile deiner Anwendung zu generieren und dir erste gute Vorschläge zu machen, vor allem dann, wenn du noch nicht allzu tief in das Thema eingearbeitet bist. Grundsätzlich solltest du am Ende das Ergebnis noch einmal prüfen, ob es genau deinen Vorstellungen entspricht und den Anforderungen im Unternehmen auch taugt.
Neben den Standardanwendungen am Markt wie GitHub Copilot, Claude Code oder OpenAI Codex gibt es auch Anbieter, die sich auf SAP spezialisieren, wie Nova Intelligence und Conduct AI. Je nach Anforderungen solltest du die Augen am Markt offenhalten und die für dich passende Lösung suchen. Hier kann die Auswahl im Moment etwas überfordernd sein. Viele Unternehmen setzen deshalb auch oft auf Eigenentwicklungen in diesem Bereich.
Fazit
Die vier Säulen der modernen ABAP-Architektur sind ein gutes Gerüst bei der Umsetzung von kompletten Anwendungen im ABAP Cloud Umfeld. Dies bedeutet: Wir bauen Anwendungen in der Public Cloud, Private Cloud und On-Prem und nutzen dafür die gleiche Architektur und Technologie, wobei der Großteil des Codings und der Logik weiterhin im ABAP liegen wird. Weshalb auch das Thema Testbarkeit und Wiederverwendbarkeit ein wichtiger Bestandteil von zukünftigem Coding bleiben wird.
