Überblick zu RESTful ABAP Programming Model (RAP)

Das RESTful ABAP Programming Model (RAP) ist der evolutionäre Nachfolger des Fiori Programmiermodells. Das Modell ist sowohl in der SAP BTP ABAP als auch SAP S/4 HANA Cloud ABAP Environment verfügbar, wie auch in SAP S/4HANA 1909 On-Premise und höheren Versionen.

Zuerst wird das Evolutionsmodell der Programmiermodelle betrachtet:

ABAP Plattform ≤ 7.5

Die klassische ABAP Entwicklung, worunter Dynpro, WebDynpro, Business Server Pages, Floorplan Manager und WebClient UI Framework gehören, ist von On-Premise Umgebungen bekannt und stellt die erste Evolutionsstufe des Programmiermodells dar.

ABAP Plattform ≥ 7.5

Das ABAP Programming Model für SAP Fiori ist das aktuell meist präferierte und verwendete Programmiermodell. In diesem wird mit dem generischen Konzept für SAP Fiori mit dem Model View Controller (MVC) design pattern gearbeitet. Auch dort war es bereits möglich, Gateway Services mit der Hilfe von Core Data Services (CDS) und dem transaktionalen Speichermodell Business Object Process Framework (BOPF) zu entwickeln.

SAP S/4HANA ≥ 1909 / SAP BTP ABAP ≥ 1808

Als evolutionärer Nachfolger kommt das RESTful ABAP Programming Model des Fiori Programmiermodells. Dieses bietet eine standardisierte und effiziente Programmierung von webbasierten Applikationen und APIs. Das RAP ist für HANA-Datenbanken optimiert und bietet eine vollständige Integration.

Das neue Modell lässt sich in drei Hauptkomponenten aufteilen:

ABAP Developement Tools for Eclipse (ADT)

Die Entwicklung wird mithilfe der ADT-Tools für Eclipse durchgeführt. Dadurch wird die SAP GUI für die Programmierung überflüssig.

ABAP & CDS als Entwicklungssprachen

Die Erstellung von RAP-Services basiert auf ABAP und CDS-Views, welche im Ganzen als Business Objekte (BO) bezeichnet werden. In diesen wird die Datenmodellierung sowie die transaktionale Speicherung implementiert. Die Business Objekte bleiben, wie gewohnt aus der „alten“ Welt, die Hauptentitäten im RAP.

Powerful frameworks für die Laufzeitkonzepte

Es werden dedizierte Code-Exits für die spezifische Geschäftslogik zur Verfügung gestellt, um eine einfache Implementierung zu gewährleisten.

Um hier einen Überblick zu schaffen, was dies bedeutet, dient folgende Grafik zur Veranschaulichung:

Data Modeling & Behavior

Die unterste Ebene stellt die Daten-Modellierung und die transaktionale Verhaltensdefinition (BDEF) dar. In dieser Schicht werden die grundlegenden CDS-Entitäten modelliert. Dabei wird das sogenannte Business Object (BO) erstellt. Auf Basis dessen wird die Behavior Definition und Implementierung angelegt. Neben den transaktionalen Modellen gibt es auch die Möglichkeit analytische Modelle für RAP-basierte Embedded Analytics zu erstellen.

Business Service Provisioning

Auf der zweiten Ebene befinden sich die BO Projektionsviews mit ihrer eigenen Behavior Definition. Neben den Projektionsviews wird die Service Definition und das Service Binding angelegt. Die Service Definition gibt hierbei die zu veröffentlichenden Entitäten und das Service Binding die ODATA Protokollversion (V2 oder V4) an.

Consumption

Auf der obersten Ebene sind verschiedene Technologien verwendbar, welche den Service konsumieren können. Dabei ist der Hauptfokus auf SAP Fiori Elements gelegt, jedoch sind auch Web-APIs oder SAPUI5 Freestyle Apps möglich.