Kontakt & Service
Jetzt Beratung vereinbaren

In wenigen Schritten einen Beratungs­termin mit unseren Experten buchen.

ABAP RESTful Application Programming Model (RAP)

News & Wissen Einführung in das ABAP RESTful Application Programming Model (RAP)

Das ABAP RESTful Application Programming Model (RAP) ist das neueste Modell der SAP, um Web APIs in ABAP mit JSON/XML als Datenaustausch zu schreiben. Genauer gesagt: Mit dem RAP können Sie SAP HANA-optimierte OData Services erstellen. Es handelt sich um den Nachfolger des ABAP Programming Model for SAP Fiori. Das Modell ist verfügbar in der SAP Cloud Platform ABAP-Umgebung ab Release 1808 und in SAP S/4HANA ab Version 7.54, Release 1909.

Es gibt zwei Arten von Implementierungen: „managed“ für das Erstellen von komplett neuen OData-Services und „unmanaged“ für das Schreiben von OData-Services mit bereits bestehendem Code. Das ABAP RESTful Application Programming Model nutzt mehrere Technologien, darunter REST, CDS, OData und ABAP. Diese werden im Folgenden kurz erklärt:

REST

Mit REST ist eine Programmierschnittstelle gemeint, die sich an den Paradigmen des World Wide Web (WWW) orientiert und einen Ansatz für die Kommunikation zwischen Client und Server in Netzwerken beschreibt. Die Abkürzung REST steht für Representation State Transfer.

CDS

CDS steht für Core Data Services. Diese werden für die Datenmodellierung in neueren SAP-Systemen benutzt. Mit CDS lassen sich Entitäten und deren Beziehungen beschreiben. Eine CDS-Entität entspricht praktisch einer Entität der realen Welt. Außerdem wird das Verhalten - sprich, was mit dem Datenmodell gemacht werden kann - definiert: Können die Daten aktualisiert, gelesen, gesperrt etc. werden? Das Framework BOPF aus dem ABAP Programming Model for SAP Fiori wird dadurch abgelöst.

OData

OData ist ein Protokoll, das auf dem HTTP-Protokoll basiert.  Es ermöglicht einen Datenzugriff zwischen kompatiblen Softwaresystemen und SQL-ähnlichen Abfragen über die URL.

RAP-Beispielprojekt

Nachdem nun ein paar Begrifflichkeiten erklärt worden sind, folgt nun ein Beispielprojekt. Um dieses zu erstellen, werden die ABAP Developer Tools (https://tools.hana.ondemand.com/#abap) und die Eclipse IDE (https://www.eclipse.org/downloads/packages/release/2020-09/r/eclipse-ide-java-developers) benötigt.

Außerdem ist ein Trial Account für die SAP Cloud Platform und das SAP-System „TRL“ erforderlich. Eine Anleitung ist unter diesem Link zu finden: https://developers.sap.com/tutorials/abap-environment-trial-onboarding.html.

Das folgende Beispielprojekt basiert auf einem größeren SAP-Beispielprojekt, das unter GitHub zu finden ist: https://github.com/SAP-samples/abap-exercises-codejam.

Es werden nur Reisedaten aus einer Demotabelle angezeigt bzw. erstellt. Dafür wird zunächst ein Paket im Testsystem mit beliebigem Namen und ein CDS View erstellt. Nach jedem Schritt sollte nun alles mit CTRL+SHIFT+S gespeichert und mit CTRL+SHIFT+F3 aktiviert werden.

Ein Paket kann mit Rechtsklick auf das SAP Trial System und dann auf New->ABAP Package anlegt werden. Danach einen Namen und eine Beschreibung für das Paket eingeben:

Danach auf „Next“ klicken und bei Software Component „ZLOCAL“ eingeben. Noch einmal auf „Next“ und dann auf „Finish“ klicken.

Anschließend Rechtsklick auf das erstellte Paket und unter Other ABAP Repository Object->Core Data Services->Data Definition einen CDS View anlegen:

Dann wieder auf „Next“ und anschließend auf „Finish“ klicken. Folgender Code wird nun für die Data Definition benötigt:

@AbapCatalog.sqlViewName: 'ZTRAVELTESTVIEW'

@AbapCatalog.compiler.compareFilter: true

@AbapCatalog.preserveKey: true

@AccessControl.authorizationCheck: #CHECK

@EndUserText.label: 'Travel'

@Metadata.allowExtensions: true

define root view ZTRAVELTEST

  as select from /dmo/travel as Travel

  association [0..1] to /DMO/I_Agency as _Agency on $projection.AgencyID = _Agency.AgencyID

{

  key Travel.travel_id     as TravelID,

      Travel.agency_id     as AgencyID,

      Travel.customer_id   as CustomerID,

      Travel.begin_date    as BeginDate,

      Travel.end_date      as EndDate,

      @Semantics.amount.currencyCode: 'CurrencyCode'

      Travel.booking_fee   as BookingFee,

      @Semantics.amount.currencyCode: 'CurrencyCode'

      Travel.total_price   as TotalPrice,

      @Semantics.currencyCode: true

      Travel.currency_code as CurrencyCode,

      Travel.description   as Memo,

      Travel.status        as Status,

      Travel.lastchangedat as LastChangedAt,




      /* public associations */

      _Agency

}

Mit diesem CDS View werden die Daten aus der Demotabelle „/dmo/travel“ selektiert. Außerdem wird die Auswahl der Spalten festgelegt und welche Assoziationen es gibt.

Zusätzlich zum CDS View werden sogenannte Metadatenerweiterungen angelegt. Dazu Rechtsklick auf das Paket und unter Other ABAP Repository Object->Core Data Services->Metadata Extension eine Metadatenerweiterung anlegen. Danach auf „Next“ und „Finish“ klicken.

Mit den Metadatenerweiterungen werden eingeblendete Spalten, Positionen, Labels etc. für das UI festgelegt. Folgender Code wird für die Generierung der Metadaten benötigt:

@Metadata.layer: #CORE




@UI: { headerInfo: { typeName: 'Travel',

typeNamePlural: 'Travels',

title: { type: #STANDARD,

value: 'TravelID' } } }




annotate view ZTRAVELTEST with




{

@UI.facet: [ { id:            'Travel',

purpose:       #STANDARD,

type:          #IDENTIFICATION_REFERENCE,

label:         'Travel',

position:      10 }]




@UI: { lineItem:       [ { position: 10,

importance: #HIGH } ],

identification: [ { position: 10 } ],

selectionField: [ { position: 10 } ] }

TravelID;




@UI: { lineItem:       [ { position: 20,

importance: #HIGH } ],

identification: [ { position: 20 } ],

selectionField: [ { position: 20 } ] }

AgencyID;




@UI: { lineItem:       [ { position: 30,

importance: #HIGH } ],

identification: [ { position: 30 } ],

selectionField: [ { position: 30 } ] }

CustomerID;




@UI: { lineItem:       [ { position: 40,

importance: #MEDIUM } ],

identification: [ { position: 40 } ] }

BeginDate;




@UI: { lineItem:       [ { position: 41,

importance: #MEDIUM } ],

identification: [ { position: 41 } ] }

EndDate;




@UI: { identification: [ { position: 42 } ] }

BookingFee;




@UI: { identification: [ { position: 43 } ] }

TotalPrice;




@UI: { identification:[ { position: 45,

label: 'Comment' } ] }

Memo;




@UI: { lineItem: [ { position: 50,

importance: #HIGH },

{ type: #FOR_ACTION,

dataAction: 'set_status_booked',

label: 'Set to Booked' } ] }

Status;

}

Als nächstes wird das Verhalten des Services definiert, also welche CRUD-Methoden an welchen Entitäten durchgeführt werden können. Dazu Rechtsklick auf das Paket und unter Other ABAP Repository Object->Core Data Services eine Behavior-Definition anlegen.

Root Entitätsname ist der Name des vorhin erstellten CDS Views. Implementierungstyp ist in diesem Beispiel „unmanaged“:

Danach auf „Next“ und „Finish“ klicken.

Folgender Code definiert das Verhalten und die Klasse, wo die Implementierung stattfindet:

unmanaged implementation in class zbp_traveltest unique;

define behavior for ZTRAVELTEST

{

create;

}

Danach muss noch die Behavior-Implementierung erfolgen. Diese kann man mit Rechtsklick auf die Behavior-Definition im Project Explorer anlegen. Die Klasse muss so heißen, wie es in der Behavior-Definition oben angegeben ist.

In der folgenden Klasse wird nun eine beispielhafte Create-Methode unter dem Reiter „Local Types“ implementiert. Normalerweise werden dort BAPIs etc. aufgerufen. Folgender Code dient nun als kurzes Beispiel, um eine Create-Methode zu implementieren:

CLASS lhc_ZTRAVELTEST DEFINITION INHERITING FROM cl_abap_behavior_handler.

  PRIVATE SECTION.




    METHODS create_travel     FOR MODIFY

      IMPORTING it_travel_create FOR CREATE ztraveltest.




ENDCLASS.




CLASS lhc_ZTRAVELTEST IMPLEMENTATION.




  METHOD create_travel.

    DATA:

      lt_travel TYPE TABLE OF /dmo/travel,

      ls_travel LIKE LINE OF lt_travel.




    LOOP AT it_travel_create ASSIGNING FIELD-SYMBOL(<fs_travel_create>).

      ls_travel-agency_id = <fs_travel_create>-AgencyID.

      ls_travel-begin_date = <fs_travel_create>-BeginDate.

      ls_travel-customer_id = <fs_travel_create>-CustomerID.

      ls_travel-end_date =  <fs_travel_create>-EndDate.

      ls_travel-lastchangedat = <fs_travel_create>-LastChangedAt.

      ls_travel-description = <fs_travel_create>-Memo.

      ls_travel-status = <fs_travel_create>-Status.

      ls_travel-travel_id = <fs_travel_create>-TravelID.

      APPEND ls_travel TO lt_travel.

    ENDLOOP.




    INSERT /dmo/travel FROM TABLE @lt_travel.

  ENDMETHOD.




ENDCLASS.

Nun wurde das Datenmodel schon definiert, die Datenquelle ausgewählt, das Verhalten und auch die Create-Methode festgelegt. Jetzt fehlt nur noch die Service-Definition und das Service Binding. Diese kann man mit Rechtsklick auf das Paket unter Other ABAP Repository Object->Business Services anlegen.

Als erstes wird jetzt der Service definiert, also welche Entitäten von unseren CDS View(s) angelegt und sichtbar sein sollen:

Hier wieder auf „Next“ und „Finish“ klicken. Danach gehört folgender Code zur Service-Definition:

@EndUserText.label: 'Travel SD'

define service ZTRAVEL_SD {

expose ZTRAVELTEST;

expose /DMO/I_Agency;

}

Hier wird die selbst erstellte Entität „ZTRAVELTEST“ sichtbar gemacht und die bereits existierende Entität „/DMO/I_Agency“ veröffentlicht. Damit wird auch die Assoziation von Travel zu Agency sichtbar.

Jetzt fehlt nur noch das Service Binding für die soeben erstellte Service-Definition:

Danach wieder auf „Next“ und anschließend auf „Finish“ klicken.

Sobald das Service Binding erstellt worden ist, muss der Service Endpoint noch aktiviert werden. Zuletzt sollte alles andere mit CTRL+SHIFT+F3 aktiviert werden. Danach kann man neben den Entitäten auf Preview klicken und sich die Daten im Browser anzeigen lassen:

Vorher die Spaltenanzeige mit dem Zahnrad anpassen, dann ggf. auf „Go“ klicken, um sich die beispielhaften Reisedaten anzeigen zu lassen. Mit Klick auf „Create“ kann die Create-Methode getestet werden:

Fazit zum RAP

Mit dem ABAP RESTful Application Programming Model wird die Art und Weise, wie zuvor OData-Services geschrieben wurden, abgelöst. Von nun an wird eigentlich nur noch Eclipse genutzt; die SAP GUI fällt größtenteils weg. Dies sehen einige Entwickler vermutlich als Vorteil und andere als Nachteil an.

Alles in allem ist das ABAP RESTful Application Programming Model eine interessante Weiterentwicklung, vor allem durch die Optimierung von Datenabfragen mit dem RAP und SAP S/4HANA. Für Entwickler, die auf vielen neueren SAP-Systemen unterwegs sind, ist es auf jeden Fall sinnvoll, sich mit dem RAP und - vor allem - CDS zu beschäftigen.

Newsletter Setzen Sie auf fundiertes Wissen aus allen Bereichen unserer Branche. Regelmäßig und stets aktuell.
Beratende Person
Kontakt Haben Sie Fragen oder wünschen weitere Informationen? Unsere Experten beraten Sie gerne.