ABAP RESTful Application Programming - Architektur und Kernkonzepte

Im ersten Teil dieser Beitragsreihe wurde das ABAP RESTful Application Programming Model (RAP) vorgestellt. Dieser Artikel behandelt die Architektur und Kernkonzepte von ABAP RAP.

Das Modell ist in 3 Schichten unterteilt:

1. Date Modeling & Behavior
2. Business Service Provisioning
3. Service Consumption

1.   Data Modeling & Behavior

In der untersten Schicht liegt das Datenmodell bestehend aus CDS Views. Je nach Verwendungszweck können CDS Views als Business Objects oder Queries angelegt werden.

Queries dienen dem lesenden Zugriff auf Daten aus eigenständigen, lose assoziierten Views und Tabellen. Sie verfügen über erweiterte Funktionen zur Aufbereitung und Anzeige von Daten wie Sortierung, Filter, Suche, Wertehilfen und Textzuweisungen.

Die CDS Entität Connection liefert beispielsweise die IDs von Fluggesellschaften und Flughäfen. Die Assoziationen zu den Entitäten Carrier und Airport sind notwendig, um die Namen zu den IDs zu anzuzeigen, auch wenn sonst keine weiteren Informationen von den beiden Entitäten benötigt werden.

Business Objects repräsentieren komplexe Geschäftsentitäten wie Produkte oder Be-stellungen durch ein Datenmodell bestehend aus Kompositionen von CDS-Entitäten in einer hierarchischen Baumstruktur mit einer Root Entity und der optionalen Definition ihres transaktionellen Verhaltens. Die Implementierung ihres Verhaltens ist in ABAP-Klassen ausgelagert.

So besteht beispielsweise die Bestellung aus einer weit verzweigten Struktur vieler CDS Views, wird aber als einzelnes Objekt dargestellt. Das Business Object vereinfacht somit die CRUD Operationen auf eine Bestellung mit all ihren zugehörigen Daten aus vielen verschiedenen Datenbanktabellen.

Das Verhalten eines Business Objects umfasst die üblichen CRUD Operationen und anwendungsspezifische Aktionen wie die Freigabe einer Bestellung und wird in einer speziellen ABAP Klasse implementiert.

2.   Business Service Provisioning

Die zweite Schicht stellt OData Services für Web und Mobile Apps bereit. Dabei wird zwischen UI Services und Web APIs unterschieden. Ein UI Service gewährt Zugriff auf eine CDS Projection View, die auf die Root View eines Business Objects aufbaut. Projection Views beschreiben die anzuzeigenden Felder von Business Objects durch Annotationen, sodass ein Frontend basierend auf den Informationen aus dem UI Service generiert werden kann. Dadurch wird der Aufwand bei der Frontendentwicklung stark reduziert und viele Änderungen müssen lediglich an der Projection View vorgenommen werden. Die UI passt sich dann entsprechend der vom Service gelieferten Metadaten an.

Als Alternative zum UI Service kann der OData Service auch über eine clientunabhängige Web API exponiert werden.

3.   Service Consumption

Die letzte Schicht einer ABAP RAP Anwendung ist der Client, der den angebotenen OData Service nutzt.

UI Services werden von Fiori Apps genutzt. Diese können mit Fiori Elements generiert oder mit SAP UI5 Freestyle entwickelt werden. Über Web APIs können verschiedene Clients sowie andere Systeme ohne UI oder mit eigener UI auf den Service zugreifen.

Fazit

ABAP RAP ermöglicht eine effiziente Entwicklung von Unternehmensanwendungen durch die klare Trennung von Datenmodellierung, Geschäftslogik und Servicebereitstellung. Es vereinfacht die Anwendungsentwicklung und -wartung, indem es standardisierte und flexible Architekturen für moderne, skalierbare Lösungen bereitstellt.

Im nächsten Beitrag dieser Blogreihe zeigen wir, wie Geschäftsobjekte mit dem RAP-Framework entwickelt werden.

Sollten Sie noch Fragen haben, dann melden Sie sich – wir helfen gerne weiter!