RAP - Einführung
Das ABAP RESTful Programming Model wird das Programmiermodell der Zukunft im ABAP Bereich, in diesem Artikel schauen wir uns den Sinn, Nutzen und Aufbau an.
Inhaltsverzeichnis
Einige werden sich fragen: Wieso wurde schon wieder ein neues Programmiermodell entwickelt? Andere werden sich fragen: Programmiermodell? Doch die Antwort ist sehr leicht, die Technologie fürs Frontend hat sich verändert und Entwickler müssen, im Gegensatz zu Früher, im Backend vor allem Daten modellieren und per Service dem Frontend zur Verfügung stellen. Die klassische ABAP Entwicklung hat sich stark verändert und die Anforderungen an einen Backend Entwickler ebenfalls.
RAP
Das ABAP RESTful Programming Model oder auch kurz RAP, ist eines der zwei Programmiermodelle, welches mit der Business Technology Platform (BTP) entstanden ist. Das andere ist das Cloud Application Programming Modell, kurz CAP und basiert auf NodeJS oder Java. In dieser Serie werden wir uns allerdings auf RAP fokussieren und damit dem ABAP treu bleiben.
RAP ist das mittlerweile dritte Programmiermodell, wenn man auf die ABAP Entwicklung schaut. Dazu die folgende Grafik, die die drei Modelle einmal nebeneinanderstellt und gut die Entwicklung zeigt:
Das erste Modell (1) basierte auf der Freestyle Entwicklung mit Dynpros und klassisch über PBO/PAI. Hier war so weit alles möglich, was der GUI Baukasten anbot und dem ABAP Entwickler zur Verfügung stellte. Das zweite Modell war das ABAP Programming Modell for SAP Fiori (2) mit den ersten Fiori Anwendungen, die per OData Service versorgt wurden. Dabei spielt die Transaktion SEGW eine zentrale Rolle zur Bereitstellung des Service und der Großteil der Entwicklung findet in den klassischen Entwicklungstools statt. RAP (3) ist das neuste Programmiermodell, basiert vor allem auf Core Data Services.
Voraussetzungen
Es handelt sich bei RAP zwar um ein Cloud Programmiermodell, ist aber mittlerweile auch im S/4 HANA für On-Premise angekommen, da sich die Versionen den gleichen Core teilen. Dazu die folgende Übersicht der Releases:
- Release 1808 - Erster Release in der Cloud (ABAP Environment)
- Release 1909 - On-Premise Release ohne Validierungen, Ermittlungen und nur als Unmanaged
- Release 2009 - Managed und Unmanged On-Premise verfügbar, Nutzung nun vollständig möglich
- Release 2109 - Empfehlung auf On-Premise nur noch RAP als Programmiermodell zu verwenden
Ab dem 2009 Release kann nun vollständig genutzt werden und auch damit gelernt werden. Auch ab diesem Release kannst du bereits mit der Umsetzung von Anwendungen beginnen, es fehlen kleinere Funktionen wie Draft oder Late Numbering noch.
Aufbau
Wie ist RAP strukturiert und wie baut sich so ein neues Business Objekt zusammen? Dazu erst einmal das folgende Übersichtsbild mit den einzelnen Schichten. Dabei solltest du beachten, dass das Modell immer auf Datenbank-Tabellen aufbaut.
Auf der untersten Schicht befindet sich das Datenmodell und die Modellierung der Beziehungen untereinander. Hier werden Core Data Services angelegt, die das Objekt modellieren und eine Verhaltensdefinition um zusätzliche Funktionen zu implementieren.
Die mittlere Schicht modelliert das Objekt für die Nutzung nach Außen, die sogenannte Projektion. Damit wird der Funktionsumfang für die Anwendung oder API definiert, damit kann die Funktionalität eingeschränkt werden, aber keine neue Funktionalität hinzugefügt werden. Auf dieser Schicht wird auch das Protokoll in der Service Binding definiert.
Die letzte Schicht beschreibt den Umfang zur Nutzung der Services.
Managed vs Unmanaged
Wir hatten oben bereits die Ansätze Managed und Unmanaged erwähnt, was hat es damit eigentlich auf sich? Dabei geht es um vor allem um Migrationsszenarien die du als Brownfield abbilden möchtest. Hast du noch bestehende gekapselte Objekte die sich um die Verwaltung der Daten kümmern, dann kannst du diese in einem unmanaged Objekt wiederverwenden und musst nicht alles neu entwickeln. Setzt du auf Greenfield und musst sowieso alles neu machen, dann auf jeden Fall den managed Ansatz verwenden.
Bei den meisten Neuentwicklungen wirst du immer auf den managed Ansatz setzen, da dir hier die gesamte Verwaltung des Objekts übernommen wird.
Umfang
Was steckt alles in einem Business Objekt und wie kannst du es nutzen? Hier einmal eine Liste an Funktionen die du innerhalb eines Objekts zur Verfügung hast:
- Validierung - Prüfung von Feldern und Zuständen der Daten. Fehlermeldungen können das Speichern verhindern, damit kein inkonsistenter Stand gesichert wird.
- Ermittlung - Anreicherung der Daten und Felder über Regeln, externe APIs oder vorhandene Informationen.
- Aktion - Auslösung einer Aktion im Kontext des Business Objekts, um Daten konsistent zu verarbeiten oder Status umzusetzen.
- Draft - Zwischenspeichern der Daten, ohne die produktiven Daten zu verändern. Sind die Daten am Ende konsistent, dann werden die produktiven Daten aktualisiert.
Was kannst du alles mit einem RAP Objekt machen und wofür nutzen?
- OData für eine Anwendung (mit Annotationen)
- OData als API
- Data Integration
- Ersatz für BAPI
Die einzelnen Kategorien, Funktionen und Themen werden wir dir in den folgenden Artikeln etwas näherbringen, damit du eine genaue Vorstellung davon bekommst, was du alles tun kannst.
BOPF
Wenn du dir den Umfang und die Inhalte von RAP angeschaut hast und BOPF bereits kannst, dann werden dir viele Parallelen dazu auffallen. BOPF bildete bereits ein Business Object ab und verbindet Tabellen zu einer logischen Einheit. Auch bei BOPF gibt es Validierungen, Ermittlungen und Aktionen auf dem Objekt, dieses Konzept wurde für RAP übernommen, aber um den Boilerplate Code und das Framework reduziert.
Fazit
RAP wird in Zukunft einen sehr wichtigen Teil in der ABAP Entwicklung einnehmen und sollte bereits heute ein Have-To-Learn für jeden ABAP Entwickler darstellen, der noch einige Jahre vor sich hat. Wenn du aktuell kein System hast, um es zu lernen, empfehlen wir dir die kostenlose Variante über die BTP, ein Sandbox System mit Foundation Stack (außer Hardware keine Kosten) oder die Developer Edition für den privaten Rechner.
