Der folgende Beitrag soll den Beginn einer ganzen Reihe von technisch orientierten Blogs markieren, die sich mit dem „ABAP Restful Application Programming Model“ (RAP Model) als de-facto Nachfolger des „ABAP Programming Model for SAP Fiori“ befassen. Während das RAP Model ursprünglich nur für die SAP BTP ABAP (früher: SAP Cloud Platform ABAP) eingeführt wurde, kann es seit dem SAP S/4HANA Release 1909 auch in On-Premise Systemen- wenn auch nicht mit dem vollen Sprachumfang- verwendet werden. In einem S/4 2020 wurde der Sprachumfang nochmals deutlich erweitert und dies wird auch in den kommenden Releases so bleiben. Hierbei werden neue Features quartalsweise auf der SAP BTP ABAP ausgeliefert. Diese finden ihren Weg über die jährlichen SAP S/4HANA Releases in die On-Premise Systeme.
Im Fokus dieser Blogs sollen die in den On-Premise Releases (speziell SAP S/4HANA 2020) verfügbaren Features stehen. Denn der größte Teil der ABAP Entwickler hat immer noch mit diesen oder älteren Systemen im Alltag zu tun . In diesem ersten Blog möchte ich auf allgemeine Konzepte des RAP eingehen und seine Vorteile gegenüber dem „ABAP Programming Model for SAP Fiori“ erläutern.
ABAP Programming Model for SAP Fiori
Das „ABAP Programming Model for SAP Fiori“ ist auf On-Premise Systemen mit den Netweaver Basis Release 7.5 und höher verfügbar:
Im Vergleich zur klassischen ABAP Freestyle Programmierung reduziert es die Menge des notwendigen Codes zur Modellierung und Implementierung eines Geschäftsobjekts enorm. Es eignet sich aufgrund seiner Architektur allerdings eher für Greenfield Ansätze, bei denen ein neues Geschäftsobjekt definiert wird. Kernstück bilden hierbei entsprechende CDS Views, die mit entsprechenden Annotationen versehen werden, um daraus entsprechende Artefakte wie BOPF Objekte und SAP Gateway Services automatisch zu generieren.
Diese Architektur bringt allerdings einige Nachteile mit sich. Es werden sehr viele Artefakte in verschiedenen Schichten generiert, welche eine Fehleranalyse aufwendig und schwierig machen. Darüber hinaus wurde das BOPF vor CDS entwickelt. Die Anbindung dieser beiden Frameworks gestaltet sich im Detail oft schwieriger , als es auf den ersten Blick scheint, da beide parallel entwickelt und gewartet werden müssen. Außerdem werden z.B. auch viele redundante Annotationen über verschiedene Schichten des Virtual Data Models hinweg benötigt, um vergleichsweise einfache Features, wie einen Draft Modus für ein Geschäftsobjekt zu aktivieren.
ABAP RAP Model
Das ABAP RAP ist auf SAP S/4HANA On-Premise Systemen ab dem Release 1909 verfügbar. Da der Sprachumfang mit dem Release 2020 nochmals deutlich erweitert wurde, wird dieser im Folgenden im Fokus stehen. Wie im folgenden Bild zu erkennen ist, besteht das ABAP RAP im Wesentlichen aus 3 Schichten:
Data Modeling & Behavior
Hauptaufgabe dieser Schicht ist die Definition des Datenmodells durch CDS Entitäten basierend auf Datenbanktabellen und anderen CDS Entitäten. Die Felder eines CDS Views repräsentieren hierbei die Eigenschaften des Geschäftsobjekts und Kompositionen bzw. Assoziationen repräsentieren die Verbindungen zu Unterobjekten bzw. anderen Geschäftsobjekten. Ein einfaches Beispiel für eine Komposition wäre ein Kundenauftrag und seine Verbindung zu entsprechenden Auftragspositionen. Da Aufträge immer für einen Kunden angelegt werden, wäre die Verbindung zum Kundenobjekt (als eigenständiges Geschäftsobjekt) eine Assoziation.
Ein weiterer wichtiger Teil dieser Schicht sind die sogenannten „Behavior Definitions“. Während die CDS Entitäten vielmehr das Datenmodell einschließlich seiner Beziehungen beschreiben, definieren die „Behavior Definitions“ das transaktionale Verhalten des Geschäftsobjekts. Neben den üblichen transaktionalen CUD (create, update, delete) Methoden, steuert die Behavior Defintion unter anderem auch mögliche Aktionen des Geschäftsobjekts, das Sperrverhalten, das Draft-Handling sowie andere feldbezogenen Eigenschaften (Validierungen und Determinations).
Letztlich existiert noch die „Behavior Implementation“, die es ermöglicht, eigene Geschäftslogik für ein Geschäftsobjekt in ABAP zu implementieren. Dies können beispielsweise zuvor in der Behavior Defintion festgelegte Validierungen oder Determinations sein, oder auch Aktionen, welche z.B. einen Statuswechsel oder ähnliches anstoßen. In diesem Zusammenhang sollte auch erwähnt werden, dass es im ABAP RAP zwei grundlegend verschiedene Szenarien gibt:
- Managed Scenario
- Unmanaged Scenario
Das Managed Scenario eignet sich besonders gut für einen Greenfield Ansatz und überlässt große Teile des transaktionalen Verhaltens dem Framework. Es ist etwas weniger flexibel, benötigt dafür aber auch deutlich weniger Code. Das Unmanaged Scenario legt die komplette Implementierung des Geschäftsobjekts in die Hände des ABAP Entwicklers. Es hat einen höheren Implementierungsaufwand, bringt dafür aber auch mehr Flexibilität mit sich. Als Konsequenz eignet es sich daher auch für Brownfield Ansätze, wenn zum Beispiel Legacy Geschäftsobjekte in Form von BAPIs, oder andere Legacy APIs eingebunden werden sollen. Dies ist ein klarer Vorteil gegenüber dem ABAP Programming Model for SAP Fiori.
Business Service Provisioning
Diese Schicht besteht im Wesentlichen aus „Service Definitions“ und „Service Bindings“.
Bevor diese Artefakte angelegt werden, ist es allerdings auch möglich, die Sicht auf ein Geschäftsobjekt Anwender- oder Prozessabhängig über „CDS Projection Views“ oder „Projection Behaviors“ einzuschränken. Es könnte also zum Beispiel ein großes Geschäftsobjekt mit vielen Attributen und abhängigen Datensätzen für eine gewisse Anwendergruppe sehr schlank dargestellt werden.
Service Definition: Diese dienen dazu einen Service auf Basis einer Behavior Definition, oder einer Projektion nach außen verfügbar zu machen.
Service Binding: Basierend auf einer Service Definition macht ein Service Binding das Geschäftsobjekt über OData V2/V4, oder ein Web API von außen konsumierbar.
Aussicht
In den kommenden Blogbeiträgen werde ich ein konkretes Beispiel in einem Managed und einem Unmanaged Scenario vorstellen. Zudem sukzessive Objekte mit weiteren Features wie Draft Handling sowie Validierungen und Determinations erweitern.