Ein Praxisleitfaden zu ABAP RAP: Teil 4

Hallo Technikbegeisterte!!

Willkommen zum vierten Teil unserer Blogserie über ABAP RAP. In den ersten drei Teilen haben wir verschiedene Programmiermodelle von ABAP besprochen, ABAP RAP kennengelernt, das Szenario in acht Schritte unterteilt und die ersten vier Schritte unserer Lösung umgesetzt. Falls Sie unseren vorherigen Blog noch nicht gelesen haben, empfehlen wir Ihnen, das zuerst nachzuholen, das Szenario zu verstehen und die hier genannten Schritte umzusetzen.

In diesem Beitrag besprechen wir den fünften Schritt:

1. Anlegen eines Pakets zur Ablage der Projektressourcen.
2. Anlegen von drei Tabellen samt einem Datenelement, das tabellenübergreifend verwendet wird.
   1. Mitarbeiterinformationen: zur Ablage der Basisinformationen über einen Mitarbeiter.
   2. Beschäftigungsinformationen: zur Ablage von Beschäftigungsbestandteilen wie Eintrittsdatum und Gehalt.
   3. Positionsinformationen: zur Ablage positionsbezogener Informationen (wird als Wertehilfe- bzw. Prüftabelle verwendet).
3. Anlegen eines CDS Interface View, um eine Basissicht ohne umfangreiche Informationen zu erzeugen, die von verschiedenen Services genutzt werden kann.
4. Anlegen eines CDS Projection View, der eine Teilmenge der Elemente des CDS Interface View bereitstellt. Er ist serviceagnostisch.
5. Anlegen einer Metadata Extension für UI-Elemente sowie Anlegen von Behavior Definition und Projection zur Definition der auf dem Service möglichen Aktionen. Beispiel: Create, Update, Delete, Determination usw.
6. Anlegen der Behavior Implementation, um die Geschäftslogik zu Aktionen wie Validation, Action und Determination zu schreiben.
7. Anlegen des Binding Service zur Definition des vom Service genutzten Protokolls. Beispiel: OData V2 - UI, OData V2 - WebAPI usw.
8. Bereitstellen des Service.

Metadata Extension

Die meisten von Ihnen wissen vermutlich schon, was Metadaten sind, aber für alle anderen hier ein kurzer Überblick:

Metadaten helfen dabei, Daten zu organisieren und zu finden, indem sie eine Beschreibung dieser Daten enthalten. Kurz gesagt: Metadaten sind Daten über Daten.

Wenn Sie zum Beispiel ein Dokument speichern, enthält es Titel, Ersteller, Erstellungszeit, letzte Änderung usw. Das verrät uns alle Details des erstellten Dokuments und behält im Blick, wann Änderungen vorgenommen wurden, von wem und wann.

Im Kern ist eine Metadata Extension also eine Möglichkeit, eine CDS-Entität um CDS-Annotationen zu erweitern, die nicht im CDS-Quellcode definiert sind.

Im Kontext von ABAP RAP hilft die Metadata Extension dabei, die UI-bezogenen CDS-Annotationen in einem separaten CDS-Quellcode zu definieren, der unabhängig von der CDS-Entität, für die er definiert wird, transportiert und aktiviert werden kann. Diese Unterstützung des Separation-of-Concerns-Prinzips (SoC) sorgt für bessere Lesbarkeit des CDS-Quellcodes.

Was passiert, wenn ich keine Metadata Extension hinzufüge?

Wenn Sie keine Metadata Extension hinzufügen, müssen Sie beim Erscheinen der UI die anzuzeigenden Spalten manuell auswählen. Dieser zusätzliche Schritt entfällt, wenn die Metadaten vorhanden sind. Die UI übernimmt die Daten und die anzuzeigenden Felder dann automatisch.

Behavior Definition

Sehen wir uns zunächst an, was ‚behavior‘ laut Google bedeutet:

noun: behavior

the way in which one acts or conducts oneself, especially towards others.

Nehmen wir an, Sie sind auf einer Party und die Gastgeber wirken sehr glücklich und erfreut darüber, dass Sie dabei sind. Wie würden Sie ihr Verhalten Ihnen gegenüber beschreiben? Sie würden vielleicht sagen, sie zeigen ein sehr angenehmes und höfliches Verhalten. Als Menschen zeigen wir ständig Verhalten. Bei ABAP RAP ist das nicht anders. Auch RAP zeigt Verhalten, und um das zu tun, benötigt es eine Behavior Definition.

Eine Behavior Definition ist ein ABAP-Repository-Objekt, das das Verhalten von Business Objects im Kontext von ABAP RAP abbildet. Sie bezieht sich immer auf ein CDS-Datenmodell und stützt sich direkt auf die CDS-Root-Entität. Behavior Definitions für ein gegebenes Composition-Modell werden für den Root-CDS-View angelegt und enthalten die Definition aller Entitäten.

---

Da wir nun wissen, was Metadata Extension und Behavior Definition sind, können wir bedenkenlos mit dem Anlegen beider fortfahren.

Schritt 5: Anlegen einer Metadata Extension für UI-Elemente sowie Anlegen von Behavior Definition und Projection zur Definition der auf dem Service möglichen Aktionen. Beispiel: Create, Update, Delete, Determination usw.

5.1 Metadata Extension für ZC_RAP_E2E_AEMP

💡 Voraussetzung für das Erweitern einer CDS-Entität mit Metadata Extensions ist, dass die Annotation Metadata.allowExtensions mit dem Standardwert true im DDL-Quellcode der CDS-Entität angegeben ist

Klicken Sie mit der rechten Maustaste auf das von Ihnen im ersten Schritt angelegte Paket und gehen Sie zu New → Other repository objects. Suchen und wählen Sie ‚Metadata Extension‘.

Vergeben Sie einen passenden Namen und eine Beschreibung, klicken Sie auf Next, wählen Sie den Transportauftrag und klicken Sie auf Finish.

💡 Wichtig: Die Namen von Metadata Extensions sind identisch mit denen der zugehörigen CDS-Entitäten.

Sobald Sie das Layout erhalten, fügen Sie den untenstehenden Code hinzu.

📢 Die Metadata Extension gibt Auskunft über Layout, Positionierung und weitere UI-bezogene Informationen zu den anzuzeigenden Feldern.

5.2 Metadata Extension für ZC_RAP_E2E_AEMPL

5.3 Metadata Extension für ZC_RAP_E2E_AEMP_M

5.4 Metadata Extension für ZC_RAP_E2E_AEMPL_M

---

---

5.5 Anlegen der Behavior Definition

💡 Die Behavior Definition wird für den Root-CDS-Interface-View angelegt, die Behavior Projection für den Root-CDS-Projection-View.

Wie immer besteht der erste Teil dieses Schritts darin, zu New → Other repository objects zu gehen. Suchen Sie danach nach ‚Behavior Definition‘ und vergeben Sie eine passende Beschreibung. Klicken Sie dann auf browse, um die ‚Root Entity‘ zu suchen.

💡 Nach der Auswahl des Root-CDS-Interface-View wird der Implementierungstyp automatisch auf Managed gesetzt.

Da der Implementierungstyp managed ist, müssen wir das in der ersten Zeile angeben. Dadurch übernimmt RAP die Operationen Create, Update und Delete. Die Klasse zbp_i_rap_e2e_aemp ist hier die Klasse, in der wir die Geschäftslogik für alle Verhaltensweisen definieren, die wir selbst implementieren, etwa Action, Determination und Validation.

🗒️ Diese Klasse ZBP_I_RAP_E2E_AEMP legen wir im nächsten Teil unserer Blogserie an.

Für den Employee Interface View definieren wir zwei Actions, eine Validation und eine Determination.

Action

1. hireEmployee: setzt den Status eines Mitarbeiters auf aktiv
2. retireEmployee: setzt den Status eines Mitarbeiters auf inaktiv

Validation

1. validateAge: prüft das Alter eines Mitarbeiters anhand des Feldes DateOfBirth während der Save-Sequenz der Create-Operation.

Determination

1. assignIDs: erzeugt die EmployeeID während der Create-Operation für einen Mitarbeiter.

💡 Determination on save: Die Determination wird während der Save-Sequenz am Ende einer Transaktion ausgeführt, wenn Änderungen aus dem Transaktionspuffer in der Datenbank persistiert werden.

Für den Employment Interface View definieren wir zwei Determinations.

Determination

1. checkPositonAssigned: prüft während der Create-Operation, ob dem Mitarbeiter bereits eine Position zugeordnet ist. Ist bereits eine Position zugeordnet, führt das Anlegen einer neuen Employment für denselben Mitarbeiter zu einem Fehler.

💡 Determination on modify

Die Determination wird unmittelbar nach Datenänderungen im Transaktionspuffer ausgeführt, sodass das Ergebnis während der Transaktion verfügbar ist.

2. assignAdditionalInfo: ordnet dem Mitarbeiter abhängig von der PositionID automatisch das Gehalt zu.

5.6 Anlegen der Behavior Projection

Sobald die Behavior Definition für den Root Interface View des Composition-Modells definiert ist, können wir mit dem Anlegen der Behavior Projection fortfahren.

💡 Die Behavior Projection wird mit dem Root-CDS-Projection-View des Composition-Modells angelegt. In unserem Fall haben wir zwei Root-CDS-Projection-Views, also legen wir zwei Behavior Projections an.

💡 Nach der Auswahl des Root-CDS-Projection-View wird der Implementierungstyp automatisch auf Projection gesetzt.

💡 Legen Sie die Behavior Projection für die Manager-Nutzung an, indem Sie dieselben oben genannten Schritte befolgen, oder schauen Sie in das GitHub-Repository, um die vollständigen End-to-End-Schritte zu sehen.

Damit kommen wir zum Ende dieses Blogteils. Wir haben den fünften Schritt unserer Lösung abgeschlossen. In diesem Blogbeitrag haben wir einen weiteren Schritt unseres praktischen Einstellungsszenarios umgesetzt. Außerdem haben wir Einsatz und Anwendung von Behavior Definition und Projection sowie Metadata Extension verstanden.

Im nächsten und letzten Teil unserer Blogserie lernen wir die Implementierung der Geschäftslogik für die Behavior Definition kennen, gefolgt von Service Binding und der Bereitstellung des Service. Bleiben Sie bis dahin dran, lernen Sie weiter mit uns und vergessen Sie nicht, in das GitHub-Repository zu schauen.

Das war es fürs Erste, wir setzen unsere Lernreise zu ABAP RAP bald fort. Auf Wiedersehen und viel Freude beim Lernen!!