Ansicht
Dokumentation

ABENCOMMIT_ENTITIES_BEGINEND_ABEXA - COMMIT ENTITIES BEGINEND ABEXA

CL_GUI_FRONTEND_SERVICES - Frontend Services   CPI1466 during Backup  
Diese Dokumentation steht unter dem Copyright der SAP AG.

- COMMIT ENTITIES BEGIN, END mit CONVERT KEY OF

In diesem Beispiel wird die COMMIT ENTITIES-Variante COMMIT ENTITIES ... END einschließlich CONVERT KEY OF mit einem einfachen nicht verwalteten RAP-BO demonstriert.

Datenmodell

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

Wurzelentität:

Verhaltensdefinition

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

Verhaltensimplementierung

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

• lcl_buffer bildet den transaktionalen Puffer. Sie beinhaltet eine interne Tabelle zum Behandeln der Daten.

• lhc_demo_unmanaged_root_late_nu ist die Behandlerklasse des Verhaltens-Pools. Die einzigen relevanten Methoden in diesem Beispiel sind create und update.

• lsc_demo_unmanaged_root_late_nu ist die Saver-Klasse des Verhaltens-Pools. Die Methoden dieser Klasse implementieren die eigentliche Modifikation der persistenten Daten.

Details zu ABP

• lcl_buffer

In dieser lokalen Klasse wird eine interne Tabelle aufgebaut, die als transaktionaler Puffer dient. root_late_num_buffer ist der transaktionale Puffer der Wurzelentität. Der zugrundeliegende strukturierte Datentyp wird auf eine Weise gebaut, die die Behandlung des Puffers vereinfacht. gty_late_num_buffer enthält als strukturierter Datentyp für root_buffer alle Schlüssel- und Datenfelder der CDS-View, die der Wurzelentität mit demselben Typ zugrundeliegt. Darüber hinaus enthält die Struktur die Komponenten cid und pid zum Halten des Inhalts und der Vorab-ID. Diese Vorab-ID ist für die späte Nummernvergabe notwendig. Darüber hinaus enthält sie zur komfortablerer Verarbeitung des Sicherns und Löschens von Instanzen zwei Felder (changed und deleted), die die Rolle von Kennzeichen spielen (das Löschen ist in diesem Beispiel nicht relevant). Diese Kennzeichen werden während modifizierender Operationen gesetzt, beispielsweise erhält das changed-Feld beim Anlegen oder Ändern einer Instanz ein X.

• Methode create

Diese Methodenimplementierung wird absichtlich einfach gehalten. Zum Beispiel wird das Füllen des REPORTED-Parameters oder die Existenzprüfung einer Instanz zur Entlastung des Quelltextes weggelassen. Die Methode umfasst nur das Anlegen von %pid und das Füllen des transaktionalen Puffers, plus den MAPPED-Antwortparameter. Eine LOOP-Anweisung verarbeitet den transaktionalen Puffer mit den als Eingabeparameter eingehenden einzelnen Instanzen (entities). In diesem Fall werden folgende Schritte implementiert: Zuerst wird eine Vorab-ID (%pid) für die zu verarbeitende Instanz angelegt. Dort ist sie eine UUID. Dann wird der transaktionale Puffer mit allen bereitgestellten Eingaben, einschließlich %cid, der neuen %pid, der Datenfelder und eines Kennzeichens im changed-Feld, damit die Instanz angelegt werden kann. Die Schlüssel spielen dort keine Rolle, da die endgültigen Schlüssel erst in der Sicherungsphase gezogen werden. Am Ende wird die MAPPED-Antwortstruktur mit %cid und der neuen %pid gefüllt. In dieser Phase hat die MAPPED-Antwortstruktur den Typ MAPPED EARLY.

• Methode update

Diese Methodenimplementierung wird absichtlich einfach gehalten. Zum Beispiel wird das Füllen der FAILED- und REPORTED-Parameter oder die Existenzprüfung einer Instanz zur Entlastung des Quelltextes weggelassen. Die Methode umfasst das Aktualisieren von Feldern nur wenn sie tatsächlich bereitgestellt werden. Dies findet innerhalb einer LOOP-Anweisung statt, die den transaktionalen Puffer mit den als Eingabeparameter eingehenden einzelnen Instanzen (entities) verarbeitet. Die Implementierung wird so durchgeführt, dass die zu aktualisierenden Instanzen durch die Vorab-ID %pid identifiziert wird. Nur Datenfelder sind relevant, und keine Schlüssel. Damit die Instanz aktualisiert werden kann, wird ein Kennzeichen für das changed-Feld gesetzt.

• Klasse lsc_demo_unmanaged_root

Die Methode finalize kümmert sich um das Löschen aller Inhalts-IDs aus dem Transaktionspuffer, da sie während der Sicherungsphase nicht verwendet werden dürfen.

Mit der adjust_numbers-Methode wird der echte und endgültige Schlüsselwert der Instanz zugeordnet. Die Zeilen der Tabelle des transaktionalen Puffers werden über eine LOOP-Anweisung verarbeitet. In diesem vereinfachten Beispiel erhält das Schlüsselfeld einen Attrappenwert und die MAPPED-Antwortstruktur wird gefüllt. Dort wird die Struktur mit MAPPED LATE typisiert.

Die Methode save enthält Anweisungen, die für das Sichern der Instanzen aus der transaktionalen Puffer zuständig sind, d.h. aus der internen Tabelle root_late_num_buffer zur Datenbanktabelle (demo_tab_root_3). Hier wird eine interne Hilfstabelle zum Speichern der Instanzen angelegt, die ein Kennzeichen für das Feld changed haben. Diese Hilfstabelle wird für eine -MODIFY-Anweisung verwendet, die dann nur die Datenbanktabelle mit den Instanzen, für die eine Änderung vorgesehen ist, ändert.

Die Methode cleanup bereinigt die Puffertabelle.

Quelltext

Ausführen

Beschreibung

Zugriff mit ABAP über EML

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

Auf eine -MODIFY-Anweisung, die eine CREATE-Operation zum Anlegen neuer RAP-BO-Instanzen enthält, folgt eine UPDATE-Operation, die diese neu angelegten Instanzen aktualisiert. Die MODIFY-Anweisung mit CREATE umfasst auch das Füllen des MAPPED-Antwortparameters (mapped_early). Beim Aufruf der create-Methode erhält dieser Parameter die bereitgestellte %cid und auch die durch die Methode angelegte %pid. Mit dieser Information werden die Instanzen für die UPDATE-Operation identifiziert.

Die Sicherungssequenz wird durch COMMIT ENTITIES BEGIN eingeleitet und mit COMMIT ENTITIES END beendet. Die CONVERT KEY OF-Anweisung steht auch zur Verfügung, ist aber in diesem nicht geschäftsbezogenen Beispiel prinzipiell nicht notwendig. Angenommen aber, das Besorgen der Schlüssel sei zu Demonstrationszwecken doch interessant. Daher werden die in der adjust_numbers-Methode gezogenen endgültigen Schlüssel geholt. Da die Vorab-IDs (%pid) bis zum Abbruch der RAP-LUW bestehen bleiben, können die Schlüssel auf einer dieser %pid-Komponenten konvertiert werden. In diesem Beispiel verarbeitet eine LOOP-Anweisung die Zeilen der MAPPED-Tabelle für die RAP-BO-Entität. Die CONVERT KEY-Anweisung erhält die endgültigen Schlüssel der einzelnen Instanzen. Grundlage ist die Vorab-ID, mit der diese Instanzen identifiziert werden. Der einzelne Schlüssel wird in eine lokale Variable geschrieben. Zu Demonstrationszwecken werden dann %pid und die Schlüsselwerte in einer internen Tabelle gespeichert.

Das Ausgabefenster zeigt das Ergebnis der CONVERT KEY OF-Anweisung, nämlich eine Tabelle mit %pid und den entsprechenden Schlüsselwerten und die durch die -MODIFY-Operationen erfolgreich auf der Datenbank gesicherten Instanzen.

BAL Application Log Documentation   SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 10031 Date: 20240523 Time: 175722     sap01-206 ( 183 ms )