In einem vorherigen Beitrag haben wir die Verwendung des Business Object Processing Frameworks im Rahmen eines Low-Code-Ansatzes in der SAP-Entwicklung erläutert. Eine häufige Anwendung ist das Bereitstellen von CRUD-Operationen über einen OData-Service für externe Anwendungen wie z.B. Fiori Apps oder Umsysteme. Für diesen Fall bietet SAP eine umfassende Low-Code-Lösung, die einen OData-Service bereitstellt und dazu CDS-Views und das BOP-Framework nutzt. In diesem Beitrag wollen wir mit einem Beispiel die transaktionalen Anwendungen mit CDS-Views übersichtlich erklären.

 

Hierfür wird der Hauptteil der Entwicklung in CDS-Views geleistet und über Annotationen werden sowohl der OData-Service als auch die BOPF-Objekte generiert. Die eigentliche Entwicklung kann sich daher ganz auf das Datenmodell konzentrieren. Dabei bleibt immer die Möglichkeit, das generierte BOPF-Objekt durch eigene Ermittlungen, Prüfungen und Aktionen anzureichern. Diese werden wie gewohnt als ABAP-OO-Entwicklungen durchgeführt.

 

How To?

Die Durchführung verläuft ist hierbei wie folgt:

  1. Im Consumption-View des Datenmodells werden die Annotationen für den OData-Service ergänzt. Die Annotation „@Odata.publish: true“ ist dabei obligatorisch und sorgt für die Generierung der Odata-Objekte.
  2. Anschließend werden die Annotationen für das BOP-Framework ergänzt. Diese sorgen für die Generierung eines BOPF-Objektes, welches den gleichen Namen bekommt wie der CDS-View.
  3. Der Service muss nun lokal oder auf einem Hubsystem registriert werden.
  4. Falls benötigt, werden die Ermittlungen, Prüfungen und Aktionen implementiert. Falls es dazu keine Anforderungen gibt, entfällt dieser Schritt und der Service kann sofort genutzt werden.

 

Ein einfaches Beispiel

Um ein besseres Verständnis zu erhalten, hilft folgendes einfaches Beispiel:

 

Hier sehen wir die Annotationen, die das generierte BOPF-Objekt steuern. Dabei geben die ersten drei Annotationen die erlaubten (C)RUD-Operationen an. Dann wird die Tabelle für die aktive Persistenz und eine semantische Kategorie gesetzt (z.B. für Viewübersichten). Als letztes wird die transaktionale Verarbeitung aktiviert. Alle diese Annotationen werden auf Viewebene gesetzt, aber es gibt weitere Annotationen auf Feldebene, die beispielsweise Felder als schreibgeschützt oder als obligatorisch kennzeichnen. Diese beiden Eigenschaften können dann über eine Ermittlung auch dynamisch verwaltet werden.

 

Aus diesem CDS-View wird dann bei Aktivierung im gleichen Paket das BOPF-Objekt generiert:

 

Weitere Informationen

Leicht kombinieren lässt sich dieser Aufbau eines transaktionalen Service mit den SAP Fiori Floorplans in der UI5-Entwicklung. Eine List- oder Objectpage lässt sich direkt an einen so generierten Service anbinden und erfordert ihrerseits kaum eigene Entwicklung.

 

Darüber hinaus kann das erzeugte Objekt auch aus ABAP-Anwendungen genutzt werden und erspart auch hier einiges an Aufwand im Vergleich zur klassischen Entwicklung. Eine gute Testumgebung für die so erzeugten Services bietet z.B. Postman.

 

Wenn Sie jetzt noch Fragen haben oder bereits eine Idee für eine Anwendung haben, können Sie sich gerne an uns wenden!