Ansicht
Dokumentation

ABENRAP_ADDITIONAL_SAVE_ABEXA - RAP ADDITIONAL SAVE ABEXA

General Data in Customer Master   Vendor Master (General Section)  
Diese Dokumentation steht unter dem Copyright der SAP AG.

- TYPE REQUEST FOR in einem verwalteten RAP-BO mit zusätzlichem Sichern

Dieses Beispiel zeigt die Verwendung der abgeleiteten BDEF-Typen TYPE REQUEST FOR CHANGE und TYPE REQUEST FOR DELETE im Kontext eines managed RAP-BO, dessen BDEF mit with additional save angegeben ist.

In diesem vereinfachten Beispiel werden alle Änderungen an der Wurzelinstanz des Demo-BO in der Protokolltabelle DEMO_TAB_LOG aufgezeichnet (bzw. werden sie zusätzlich gesichert). Diese Protokolltabelle enthält die folgenden Felder:

Protokolltabellenfelder	Details
change_id	Kennzeichen für eine individuelle Änderung. In diesem Fall ist es ein UUID.
key_field	Schlüsselfeld der RAP-BO-Instanz.
changing_operation	Standardoperation, die ausgeführt wurde (CREATE, UPDATE oder DELETE).
changed_field_name	Name des Feldes einer RAP-BO-Instanz, das angelegt oder geändert wurde.
changed_value	Wert eines angelegten oder geänderten Felds der RAP-BO-Instanz
created_at	Zeitpunkt (Datum und Uhrzeit), an dem die Instanzdaten angelegt, aktualisiert oder gelöscht wurden.

Datenmodell

Das CDS-Datenmodell besteht aus der Wurzelentität DEMO_MANAGED_ADDITIONAL_SAVE.

Wurzelentität:

Verhaltensdefinition

Die CDS-Verhaltensdefinition DEMO_MANAGED_ADDITIONAL_SAVE 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_ADDITIONAL_SAVE. Die eigentliche Verhaltensimplementierung findet in lokalen Klassens statt, die im BP_DEMO_MANAGED_ADDITIONAL_SAVECCIMP des Behavior-Pools definiert und implementiert werden.

Die folgende Methode ist in diesem Beispiel relevant:

• save_modified

Zuerst sind mehrere Typ- und Variablendeklarationen nur für Demonstrationszwecke verfügbar. Darunter finden sich die abgeleiteten BDEF-Typen TYPE REQUEST FOR CHANGE, TYPE REQUEST FOR DELETE, TYPE TABLE FOR CHANGE und TYPE STRUCTURE FOR CHANGE. Diese abgeleiteten BDEF-Typen sind nur im Kontext eines managed RAP-BO mit additional save und unmanaged save relevant. Im Prinzip sind die Strukturen create und update (vom Typ TYPE REQUEST FOR CHANGE) sowie delete (vom Typ TYPE REQUEST FOR DELETE) - sie enthalten diese Instanzen, die angelegt, geändert oder gelöscht werden sollen - hier standardmäßig verfügbar und können direkt referenziert werden. Zusätzliche Typ- und Variablendeklarationen wie in diesem Beispiel sind nicht notwendig. Auf die Deklarationen folgen weitere Deklarationen von internen Tabellen, die sich um das Speichern der Eingaben für die Protokolltabellen in der Datenbank kümmern.

Anschließend prüfen IF-Anweisungen, ob Instanzen von einem RAP-BO-Consumer angelegt, aktualisiert oder gelöscht wurden. Dabei wird die %control-Struktur zum Abrufen von Informationen zu den Feldern, die beim Anlegen, Aktualisieren oder Löschen der Instanz gesetzt wurden, verwendet. Die IF-Anweisung, die diese angelegten Instanzen verarbeitet, wird wie folgt implementiert: Die interne Tabelle lt_log wird mit den durch Operation CREATE erzeugten Instanzdaten befüllt. Eine LOOP-Anweisung verarbeitet die individuellen Instanzen: Die changing_operation empfängt den Wert CREATE. Die Anlegezeit wird protokolliert (Feld created_at). Dann werden die Instanzdaten in eine interne Tabelle eingelesen, um die %control-Informationen für bestimmte Felder zu behandeln. In diesem Fall wird geprüft, ob field1 als aktiviert markiert ist. Wenn das der Fall ist, wird ein UUID angelegt und dem Feld change_id zugeordnet. Da field1 betroffen ist, erhält das Feld changed_field_name den Wert field1. Das Feld changed_value erhält den Wert, der vom RAP-BO-Consumer bereitgestellt wird. Schließlich werden die Einträge zu der internen Tabelle lt_log_c hinzugefügt. Dieselbe Prozedur wird für field2 durchgeführt. Am Ende der IF-Anweisung werden alle Einträge in der internen Tabelle in die Protokolltabelle auf der Datenbank (demo_tab_log) eingefügt.

Die IF-Anweisung, die diese aktualisierten Instanzen verarbeitet, wird ähnlich wie oben beschrieben implementiert (hier werden field3 und field4 der Entität verwendet).

Die IF-Anweisung, die sich um die gelöschten Instanzen kümmert, berücksichtigt nicht die Felder changed_field_name und changed_value. Sie sind nicht relevant.

Quelltext

Ausführen

Beschreibung

Zugriff mit ABAP über EML

Der obige Quellcode verwendet EML, um auf das RAP Business-Objekt aus einem ABAP-Programm zuzugreifen:

• Eine CREATE-Operation wird ausgeführt. Zwei Instanzen werden angelegt. Die Sicherungssequenz wird durch die Anweisung COMMIT ENTITIES ausgelöst. Der zugrundeliegende BDEF umfasst die Syntax with unmanaged save. Daher wird in diesem Beispiel die ABAP-Methode save_modified aufgerufen, die, wie oben beschrieben, bestimmte Einträge in einer Protokolltabelle in der Datenbank sichert.

• Auf die CREATE-Operation folgt eine UPDATE-Operation, welche die zwei zuvor erzeugten Instanzen modifiziert. Die Änderungen werden ebenfalls festgeschrieben.

• Schließlich wird eine der vorhandenen Instanzen über die DELETE-Operation gelöscht. Ein anderer Commit kümmert sich im das Löschen der Instanz.

• Das Ausgabefenster zeigt das Ergebnis der drei Operationen. Für jede Operation wird eine interne Tabelle angezeigt, welche die Einträge der Datenbanktabelle zeigen. Eine andere interne Tabelle zeigt die Einträge der Protokolltabelle als ein Ergebnis der Implementierungen in der Methode save_modified.

CPI1466 during Backup   General Material Data  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 8719 Date: 20240523 Time: 101219     sap01-206 ( 133 ms )