Das ABAP RESTful Application Programming Model (RAP) ist das neue Programmiermodel der SAP, um APIs für Fiori-Anwendungen aber auch Web-APIs bereitzustellen.
Im Kontext mit Fiori-Apps handelt es sich hierbei um den Backend-Teil der Anwendung, der die Daten über einen OData-Service bereitstellt und verändert.
Das bestehende ABAP Programming Model for SAP Fiori wird durch das neue Programmiermodell vollständig ersetzt und sollte für Neuentwicklungen nicht mehr verwendet werden.
Ersatz bestehender Frameworks
Das ABAP RESTful Application Programming Model ersetzt, bzw. versteckt einige der bisher verwendeten Frameworks. So verschwindet z.B. das Business Object Processing Framework (BOPF) vollständig von der Bildfläche.
Der OData-Service wird nicht mehr manuell verwaltet, sondern automatisch generiert. Über die Transaktion SEGW sind die entsprechenden Services dann nicht mehr zu verwalten und zu bearbeiten.
Managed / Unmanaged Szenario
Völlig neue Geschäftsobjekte (Greenfield) können mit dem sogenannten Managed Szenario entwickelt werden. Das Framework übernimmt hierbei die Beschaffung und Verwaltung der Daten des Geschäftsobjektes aus den Datenbanktabellen (CRUD-Operationen). Damit entfällt auch der dafür notwendige Implementierungsaufwand. Auch das Sperren der zu verändernden Objekte wird durch das Framework übernommen.
Im Gegensatz dazu steht das Unmanaged Szenario (Brownfield), das verwendet werden kann, um bestehende Geschäftsobjekte anzubinden. In diesem Fall muss das Daten-Handling zum Geschäftsobjekt durch eigenes Coding sichergestellt werden. Dieses Vorgehen ermöglicht es dann allerdings auch, bestehendes Legacy-Coding (z.B. SAP-BAPIs) für den Zugriff auf die Geschäftsobjekte zu verwenden.
Draft-Handling
Das Draft-Handling kann für ein Managed Szenario aktiviert werden und ermöglicht das Zwischenspeichern von angelegten, bzw. geänderten Objekten. Im Zusammenhang mit einer Fiori-App erfolgt das Zwischenspeichern des Objektes automatisch mit jeder Feldänderung.
Dieses Verfahren hat den Vorteil, dass Objektänderungen beim Abbruch der App nicht verloren gehen und auch ein Wechsel des Gerätes während der Bearbeitung möglich ist.
Die Daten der Draft-Objekte werden in eigenen Datenbanktabellen gespeichert, die explizit vom Entwickler angelegt werden müssen. und im Wesentlichen den Tabelle des eigentlichen Geschäftsobjektes entsprechen.
Im Kontext mit dem Draft-Handling wird auch ein abweichendes Sperrkonzept verwendet. Während in einer zustandslosen (stateless) App ausschließlich eine optimistische Sperre verwendet wird, kommen hier wieder ausschließliche Sperren über den Sperr-Server zum Einsatz. Diese sind allerdings nicht an die Dialog-Session gebunden, sondern haben ihren eigenen Timeout.
Erweiterungen ABAP-Umgebung
Der Umfang der ABAP-Umgebung wurde wieder einmal erweitert. Im Bereich der Core Data Services (CDS) wurden neue Schlüsselworte und Annotationen bereitgestellt.
Für jedes Geschäftsobjekt kann ein Verhalten (Prüfungen, Initialisierungen, Aktionen) implementiert werden. Im Bereich der Core Data Services wird dafür eine Behavior Definition erstellt. Diese definiert, welches Verhalten für das Geschäftsobjekt zur Verfügung steht und referenziert auf eine ABAP-Klasse, in der die Behavior Implementation erfolgt.
Für den Zugriff auf die Daten der Geschäftsobjekte wurde eine sogenannte Entity Manipulation Language (EML) als Erweiterung des ABAP-Sprachumfanges neu erschaffen.
Über eine Service-Definition wird jetzt definiert, welche Bestandteile und Aktionen eines Geschäftsobjektes im Rahmen dieses Service bereitgestellt werden. Über das Service-Binding werden die Services bereitgestellt, und die Art des Service (SAPUI5 oder Web-API) wird hierbei definiert. Aus dem Service-Binding für einen UI-Service heraus, kann direkt eine automatisch generierte Fiori-Elements-Test-App gestartet werden.
Die Bearbeitung all dieser Objekte ist nur noch über die ABAP Development Tools (ADT) in Eclipse möglich. Über die Development-Workbench der SE80 können nur noch einzelne Teilobjekte (z.B. Klassen, DB-Tabelle) geändert werden.
Struktur im CDS
Für jede Entität des Geschäftsobjektes wird ein Basis-View definiert, der alle Felder und Assoziationen enthält. Darauf aufbauend wird dann noch ein Projektions-View (Consumption View) erstellt, der weitere Annotationen (z.B. Suche, Währungsschlüssel, usw.) enthält. Das Geschäftsobjekt wird dann auf Basis des Projektions-Views aufgebaut.
UI-Annotationen, die zur Steuerung der Anwendungsoberfläche in der App verwendet werden, werden in sogenannte Metdata Extensions ausgelagert, um die vom eigentlichen Datenmodell zu trennen.
Die Objekte, die das Verhalten des Geschäftsobjektes bestimmen, sind ebenfalls in zweigeteilt. Die Verhaltensdefinition bestimmt, welche Prüfungen, Initialisierungen und Aktionen zum Geschäftsobjekt generell zur Verfügung stehen und nimmt hierbei Bezug auf den Basis-View. Die Verhaltens-Projektion bestimmt wiederum, welche Bestandteile (hier auch der CRUD-Operationen) im konkreten Fall bereitgestellt werden – hierbei wird auf den Projektions-View Bezug genommen.