Blog

RAP – ABAP RESTful Application Programming Model – ist das aktuellste Entwicklungsmodell der SAP. Damit eröffnet sich eine weitere Option Serviceprovider für das OData-Protokoll zu implementieren.  Auch die Architektur für die Implementierung einer Lösung, basierend auf SAP HANA und dem Application Server ABAP, bis hin zur OData Web API bzw. zu OData UI Services gibt RAP vor.

Die Schnittstelle ist die Lösung

Schnittstellen sind für uns kein weißer Punkt auf einer Landkarte. Wir haben uns über Jahre ein breites Know-how angeeignet. Sowohl beim Konsumieren von Services als auch beim Implementieren von Serviceprovidern haben wir uns in mehreren Projekten verschiedenste Lösungswege erarbeitet. Eifrige Leser*innen unserer Website erinnern sich an unsere Cats-Lösung (basierend auf dem SAP Netweaver Gateway), denn dabei wurde eine Schnittstelle für die Zeiterfassung implementiert sowie eine iOS App und ein Outlook Add-In als Clients entwickelt.

RAP: eine sinnvolle Weiterentwicklung

Mittels ABAP RESTful Application Programming Model (kurz RAP) wird eine weitere und effiziente Möglichkeit einen Serviceprovider für das OData-Protokoll zu implementieren, relevant. ABAP RAP gibt dabei die Architektur für die Implementierung einer Lösung, basierend auf SAP HANA und dem Application Server ABAP, bis hin zur Odata Web API bzw. zu OData UI Services vor.

Mit Hilfe von Core Data Services (CDS) werden einzelne Entitäten (z.B. ein Service-Ticket oder ein Kunde), die über die Schnittstelle zur Verfügung gestellt werden, deklariert. Ebenso können die Zusammenhänge zwischen den einzelnen Entitäten festgelegt werden. Im Gegensatz zu früheren Lösungen, wo das Modell mit Hilfe einer model provider class programmiert wurde, kann dies nun deklarativ umgesetzt werden. Dies erlaubt auch, dass Prüfungen von der Entwicklungsumgebung bereits in der Modellierungsphase durchgeführt werden können, und nicht erst zur Laufzeit.

Zusätzlich werden Optimistic Concurrency Control mittels ETag unterstützt sowie deklarative Berechtigungsprüfungen für lesende Operationen. Selbstverständlich gibt es die Möglichkeit eigene (auch bestehende) Programmlogiken einzubinden, um auch komplexere Vorgänge bzw. Prozesse abzubilden.

Die entwickelten Services können als UI Service veröffentlicht werden. Denn durch die Verwendung von UI Annotations werden die OData Metadaten mit zusätzlichen Informationen angereichert, so dass aus diesen die Fiori Oberfläche generiert werden kann (siehe auch Fiori Elements).

RAP löst Standardtransaktionen ab

Unter Verwendung des ABAP RESTful Application Programming Models haben wir mittlerweile viele browserbasierende Anwendungen entwickelt, um Standardtransaktionen abzulösen. Dabei immer im Fokus: die User Experience. Durch die Reduktion auf wesentliche Bestandteile und interaktive Nutzerführung, haben wir für unsere Kunden einen Mehrwert geschaffen: es wurden Arbeitsabläufe wesentlich vereinfacht.

Zusätzlich haben wir, als Alternative zum SAP Fiori Launchpad, das SRB Workspaces entwickelt, das zum Beispiel die Abbildung von Hierarchien unterstützt. Basierend auf der UI5 Technologie werden verschiedene, interaktive Kacheltypen und Kachelgrößen unterstützt.

Weitere Details über das SRB Workspaces werden wir bald preisgeben.

Fazit

RAP ist eine logische Weiterentwicklung des ABAP Programming Model for SAP Fiori rund um die Optimierung von Datenbankoperationen. Damit haben wir nun die Möglichkeit noch zügiger neue OData Schnittstellen und zugehörige Webanwendungen für unsere Kunden zu entwickeln.