Ansicht
Dokumentation

ABENDERIVED_TYPES_FAIL_ABEXA - DERIVED TYPES FAIL ABEXA

CL_GUI_FRONTEND_SERVICES - Frontend Services   General Data in Customer Master  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Verwendung von %fail

Mit diesem Beispiel wird die Verwendung von %fail mit einem verwalteten RAP-BO demonstriert.

Datenmodell

Das CDS-Datenmodell besteht aus der Wurzelentität DEMO_MANAGED_ROOT_FAILED und ihrer untergeordneten Entität DEMO_MANAGED_CHILD_FAILED. Die untergeordnete Entität wird in diesem Beispiel nicht verwendet.

Wurzelentität:

Verhaltensdefinition

Die CDS-Verhaltensdefinition DEMO_MANAGED_ROOT_FAILED 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_FAILED. Die eigentliche Verhaltensimplementierung findet in lokalen Klassen statt, die im BP_DEMO_MANAGED_ROOT_FAILED===CCIMP des Behavior-Pools definiert und implementiert werden.

Die folgenden Methoden sind im Beispiel relevant:

• get_instance_authorizations: Falls eine Instanz einen spezifischen Wert in einem Feld besitzt, sollten die Aktualisierungs- und Löschoperationen abgelehnt werden, da die Operationen als unauthorized. %fail-cause wird entsprechend zugeordnet. %fail-cause und der Schlüssel der RAP-BO-Instanz werden in der failed-Antwortstruktur gespeichert.

• get_instance_features: Falls eine Instanz einen spezifischen Wert in einem Feld besitzt, sollten die Aktualisierungsoperationen abgelehnt werden, da die Operationen als readonly. %fail-cause wird entsprechend zugeordnet. %fail-cause und der Schlüssel der RAP-BO-Instanz werden in der failed-Antwortstruktur gespeichert.
  
  

Quelltext

Ausführen

Beschreibung

Zugriff mit ABAP über EML

Das Programm enthält mehrere -Anforderungen:

1. Modifizierende -Anforderung: Es werden RAP-BO-Instanzen angelegt. Mit einer COMMIT ENTITIES-Anweisung wird das Sichern der Instanzen auf der Datenbank ausgelöst. Für alle Anforderungen wird der Inhalt der failed-Antwort in der Ausgabe gezeigt. In diesem Fall weisen keine der Instanzen Fehler auf. Weiterhin wird eine interne Tabelle mit den Datenbankeinträgen gefüllt. In der Ausgabe werden alle neuen RAP-BO-Instanzen auf der Datenbank gesichert und in der internen Tabelle gezeigt.
2. Aktualisierende und anlegende -Anforderungen: Es werden spezifische RAP-BO-Instanzen aktualisiert und gelöscht. Beim Aufruf von get_instance_authorizations und get_instance_features können aufgrund der in den Methoden implementierten Bedingungen mehrere Instanzen nicht aktualisiert und gelöscht werden. Da diese Methoden die failed-Antworten füllen, zeigt eine interne Tabelle mit den Einträgen der failed-Antwort die diversen Fehlerursachen für die RAP-BO-Instanzen, die nicht auf der Datenbanktabelle gesichert werden konnten oder von ihr gelöscht werden konnten. In diesem Fall ist %fail-cause READONLY und UNAUTHORIZED. Wie oben sichert eine COMMIT ENTITIES-Anweisung die Instanzen, die keine Fehler aufwiesen. Das Ergebnis von diesen -Anforderungen wird auch in einer internen Tabelle gezeigt.
3. Lesende -Anforderung: Es werden mehrere RAP-BO-Instanzen aus der Datenbanktabelle gelesen. Das gelesene Ergebnis wird in einer in der Ausgabe gezeigten internen Tabelle gespeichert. Da nicht alle angeforderten Instanzen auf der Datenbanktabelle existieren, werden die Einträge in einer internen Tabelle mit der failed-Antwort gezeigt. In diesem Fall ist %fail-cause NOT_FOUND.

SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up   Vendor Master (General Section)  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 5474 Date: 20240523 Time: 162159     sap01-206 ( 85 ms )