Kontakt

Ansicht
Dokumentation

ABENDERIVED_TYPES_REPORTED_ABEXA - DERIVED TYPES REPORTED ABEXA

ABENDERIVED_TYPES_REPORTED_ABEXA - DERIVED TYPES REPORTED ABEXA

Fill RESBD Structure from EBP Component Structure   BAL Application Log Documentation  
Diese Dokumentation steht unter dem Copyright der SAP AG.
SAP E-Book

Beispiel für nachrichtenbezogene abgeleitete BDEF-Typkomponenten

Mit diesem Beispiel wird die Verwendung von abgeleiteten BDEF-Typkomponenten mit einem verwalteten RAP BO demonstriert:

Weitere Informationen über Nachrichtenbehandlung finden Sie im Entwicklungsleitfaden für das ABAP-RESTful-Anwendungsprogrammierungsmodell, Abschnitt Messages.

Datenmodell

Das CDS-Datenmodell besteht aus der Wurzelentität DEMO_MANAGED_ROOT_REPORTED und ihrer untergeordneten Entität DEMO_MANAGED_CHILD_REPORTED.

Wurzelentität:

Untergeordnete Einheit:

Verhaltensdefinition

Die CDS-Verhaltensdefinition DEMO_MANAGED_ROOT_REPORTED wird in CDS BDL wie folgt definiert:

Verhaltensimplementierung

Für die oben genannte CDS-Verhaltensdefinition wird ein ABP angelegt. Die globale Klasse des Behavior-Pools ist BP_DEMO_MANAGED_ROOT_REPORTED. Die eigentliche Verhaltensimplementierung findet in lokalen Klassen statt, die im BP_DEMO_MANAGED_ROOT_REPORTED=CCIMP des Behavior-Pools definiert und implementiert werden.

Die folgenden Methoden sind im Beispiel relevant:

  • get_global_authorizations
Die Methode ist so implementiert, dass anlegende, aktualisierende und löschende RAP-Operationen nur für Benutzer mit entsprechenden Berechtigungen aktiviert sind. Um die Demonstration einfach zu halten, kommt das Beispiel ohne ein Berechtigungsobjekt aus, z.B. eine Art und Weise der Behandlung einer Berechtigungsgewährung in produktiven Anwendungen. Die Variable auth_flag stellt die Berechtigung dar, die gewährt wird oder nicht. In diesem Fall wird die Berechtigung für die Operationen gewährt und der Antwortparameter reported wird über das Hinzufügen einer Nachricht zur Komponente %msg gefüllt. Weiterhin werden die Komponenten %create, %update und %delete gefüllt, wenn die entsprechenden requested_authorizations-Parameter als aktiviert markiert sind. Die Komponente %global wird auch als aktiviert markiert, da die Nachricht eine RAP-Übergangsnachricht ist und daher im Zusammenhang mit einer spezifischen Entität des Business-Objekts steht.
Für Demonstrationszwecke wird eine nicht gebundene RAP-Nachricht der Komponente %other im Kontext dieser Methode hinzugefügt.
  • validatenum:
Enthält die Methodenimplementierung für eine Validierung. Mit der Validierung wird geprüft, ob der Wert einer Zahl in einem RAP-BO-Instanzenfeld in der untergeordneten Entität zwischen den Werten zweier Zahlen in zwei Feldern der Wurzelentität fällt. Wenn nicht, schlägt die Validierung fehl und die Antwortparameter failed und reported werden gefüllt. Da reported vom Typ TYPE RESPONSE FOR REPORTED LATE ist, steht die Komponente %own zur Verfügung und wird (obwohl optional) im Beispiel verwendet, um die untergeordnete Entität zu referenzieren. Die Komponenten %path, %element und %state_area werden auch gefüllt. Vor einer Schleife über die RAP-BO-Instanzen wird der Zustandsbereich invalidiert.
Für Demonstrationszwecke wird eine nicht gebundene RAP-Nachricht der Komponente %other im Kontext dieser Methode hinzugefügt.

Quelltext

Ausführen

Beschreibung

Zugriff mit ABAP über EML

Das Programm enthält mehrere -Anforderungen:

  1. Anlegende -Anforderung:
Es werden mehrere RAP-BO-Instanzen für die Wurzelentität angelegt. Mit einer COMMIT ENTITIES-Anweisung wird das Sichern der Instanzen auf der Datenbank ausgelöst. Neben einer internen Tabelle, die die Datenbanktabelleneinträge zeigt, wird die Antwort REPORTED EARLY in der Ausgabe gezeigt. Unter anderem umfasst diese Antwort die als aktiviert markierte Komponente %global und den Inhalt der Komponente %other.
  1. Erste -Create-by-Association-Anforderung:
Es werden mehrere RAP-BO-Instanzen für die untergeordnete Entität angelegt. Sie werden absichtlich so angegeben, damit die Validierung nicht fehlschlägt. Daher werden alle Einträge nach einer COMMIT ENTITIES-Anweisung in der Datenbanktabelle gesichert. In der Ausgabe werden die Einträge in einer internen Tabelle gezeigt. Außerdem werden REPORTED LATE-Antworten gezeigt. Da die Validierung erfolgreich ist, gibt es keine Einträge im reported-Parameter für die RAP-BO-Entitäten. Für Demonstrationszwecke wird eine andere beim Aufruf der Methode validatenum %other hinzugefügte nicht gebundene RAP-Nachricht angezeigt.
  1. Zweite -Create-by-Association-Anforderung:
Es werden zwei RAP-BO-Instanzen für die untergeordnete Entität angelegt. Sie werden absichtlich so angegeben, damit die Validierung fehlschlägt. Daher werden die Einträge nach einer COMMIT ENTITIES-Anweisung nicht in der Datenbanktabelle gesichert. Die Einträge der Datenbanktabelle werden in der Ausgabe in der internen Tabelle gezeigt und weisen keine Änderungen auf. REPORTED LATE-Antworten werden auch hier in einer Tabelle angezeigt. Da die Validierung fehlschlägt, enthält der reported-Parameter Einträge. Unter diesen Einträgen sind welche, die den Inhalt der Komponenten %path und %element visualisieren. Die Komponente %state_area ist in diesem Kontext initial. Es muss hinter dieser Create-by-Association-Operation eine lesende Operation geben, damit ein Eintrag visualisiert werden kann. Die nicht gebundene RAP-Nachricht in %other wird auch angezeigt.
  1. -Read-by-Association-Anforderung:
Es wird eine Read-by-Assoziation-Operation auf bisher fehlgeschlagenen Instanzen ausgeführt. Die Einträge der REPORTED EARLY-Antwort wird in einer internen Tabelle angezeigt. Einziger Zweck dieser Operation ist die Visualisierung der Komponente %state_area, die einen Eintrag zeigt.
  1. Dritte -Create-by-Association-Anforderung:
Eine ROLLBACK ENTITIES-Anweisung vor der Create-by-Association-Anforderung nimmt alle Änderungen der aktuellen RAP-LUW zurück. Danach werden mit den gleichen Schlüsseln wie bisher zwei RAP-BO-Instanzen für die untergeordnete Entität angelegt. Sie werden absichtlich so angegeben, damit die Validierung nicht fehlschlägt. Daher werden die Einträge nach einer COMMIT ENTITIES-Anweisung in der Datenbanktabelle gesichert. Die Einträge der Datenbanktabelle werden in einer internen Tabelle gezeigt. Sowohl REPORTED EARLY- als auch REPORTED LATE-Antworten werden auch in einer internen Tabelle angezeigt, es werden aber keine Einträge für die untergeordnete Entität gezeigt. Es werden die nicht gebundene RAP-Nachrichten in %other angezeigt die in REPORTED EARLY und REPORTED LATE enthalten sind.





PERFORM Short Reference   BAL Application Log Documentation  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 10555 Date: 20240606 Time: 092829     sap01-206 ( 184 ms )