Kontakt

Ansicht
Dokumentation

ABENSAVE_MODIFIED_UNM_SAVE_ABEXA - SAVE MODIFIED UNM SAVE ABEXA

ABENSAVE_MODIFIED_UNM_SAVE_ABEXA - SAVE MODIFIED UNM SAVE ABEXA

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

Beispiel für save_modified in einem verwalteten RAP-BO mit nicht verwaltetem Sichern

Dieses Beispiel zeigt die RAP-Saver-Methode save_modified sowie die Verwendung der abgeleiteten BDEF-Typen TYPE REQUEST FOR CHANGE und TYPE REQUEST FOR DELETE im Kontext eines verwalteten RAP-BOs, dessen BDEF mit with unmanaged save angegeben ist. Das Sichern von angelegten, geänderten oder gelöschten RAP-BO-Instanzen wird in der Methode save_modified von ABP selbst implementiert.

Datenmodell

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

Wurzelentität:

Verhaltensdefinition

Die CDS-Verhaltensdefinition DEMO_MANAGED_UNMANAGED_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_UNMANAGED_SAVE. Die eigentliche Verhaltensimplementierung findet in lokalen Klassens statt, die im BP_DEMO_MANAGED_UNMANAGED_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 in den Kontexten eines managed RAP-BO with additional save und eines managed RAP-BO with 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 folgt eine weitere Deklaration einer internen Tabelle (lt_tab), die als eine Helfertabelle für das temporäre Speichern der Instanzen, die angelegt, geändert oder gelöscht werden sollen, dient.
Anschließend prüfen IF-Anweisungen, ob Instanzen von einem RAP-BO-Consumer angelegt, aktualisiert oder gelöscht wurden. Somit wird die Struktur %control zum Abrufen von Informationen über die Felder verwendet, die beim Anlegen, Aktualisieren oder Löschen der Instanz gesetzt wurden.
Die IF-Anweisung für die angelegten Instanzen wird wie folgt implementiert: Die interne Tabelle lt_tab wird mit den durch Operation CREATE erzeugten Instanzdaten befüllt. Eine LOOP-Anweisung verarbeitet die individuellen Instanzen. Die Datenfeldwerte werden nur in die interne Tabelle lt_tab geschrieben, wenn die Datenfelder für die Operation in der %control-Struktur nicht deaktiviert sind. Am Ende der IF-Anweisung werden alle Einträge in der Tabelle lt_tab in der Datenbanktabelledemo_tab_root_3 mithilfe einer MODIFY-Anweisung gesichert.
Die IF-Anweisung, die diese aktualisierten Instanzen verarbeitet, wird ähnlich wie oben beschrieben implementiert. Um jedoch sicherzustellen, dass die Update-Operation keine Leerzeichen in die interne Tabelle lt_tab schreibt, sorgt eine SELECT-Anweisung dafür, dass alle existierenden Einträge der Datenbanktabelle demo_tab_root_3 zuerst abgerufen werden. Wenn ein Wert für ein bestimmtes Datenfeld nicht bereitgestellt oder das Feld in der %control-Struktur als deaktiviert markiert ist, werden die bereits vorhandenen Feldwerte übernommen und nicht mit einem Initialwert überschreiben.
Die IF-Anweisung, die sich um gelöschte Instanzen kümmert, löscht die Einträge mit einer DELETE-Anweisung aus der Datenbanktabelle.

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 die Instanzen in der Datenbanktabelle demo_tab_root_3 sichert, wie im Abschnitt Verhaltensimplementierung beschrieben.
  • Auf die CREATE-Operation folgt eine UPDATE-Operation, welche die zwei zuvor erzeugten Instanzen modifiziert. Die Änderungen werden ebenfalls festgeschrieben. Einige Felder werden in der %control-Struktur deaktiviert (mit if_abap_behv=>mk-off). Daher werden vorhandene Feldwerte nicht geändert.
  • Schließlich wird eine der vorhandenen Instanzen über die DELETE-Operation gelöscht. Ein anderer Commit löst die Löschung der Instanz aus.
  • Das Ausgabefenster zeigt das Ergebnis der drei Operationen. Für jede Operation wird eine interne Tabelle angezeigt, welche die Einträge der Datenbanktabelle zeigen.





ROGBILLS - Synchronize billing plans   rdisp/max_wprun_time - Maximum work process run time  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 7457 Date: 20240523 Time: 094224     sap01-206 ( 131 ms )