Ansicht
Dokumentation

ABENEML_MODIFY_OP_U_ABEXA - EML MODIFY OP U ABEXA

SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up   General Data in Customer Master  
Diese Dokumentation steht unter dem Copyright der SAP AG.

- MODIFY, Standardoperationen (nicht verwaltet)

Dieses Beispiel zeigt alle Standardoperationen zum Modifizieren und Lesen in einem einfachen nicht verwalteten RAP-BO. Folgende Operationen sind abgedeckt:

• CREATE

• CREATE BY (Create-by-Association-Operation)

• UPDATE

• DELETE

• READ

• READ BY (Read-by-Association-Operation)
  
  

Im Gegensatz zu einem nicht verwalteten RAP-Szenario muss sich der Entwickler in einem verwalteten RAP-Szenario um die Implementierung der Standardoperationen kümmern. Dieses vereinfachte Beispiel ist kein alltägliches Szenario und konzentriert sich auf die technische Seite, indem gezeigt wird, wie die Methoden eines ABAP-Behavior-Pools (ABP) selbst implementiert sein könnten und dadurch die Behandlung des Transaktionspuffers in einem verwalteten Szenario in einer vereinfachten Weise als Rollenmodell dient. Die Implementierung kann z.B. über ABAP EML außerhalb des Behavior-Pools aufgerufen werden.

Der Transaktionspuffer des nicht verwalteten RAP Business-Objekts im Beispiel wird durch interne Tabellen gebildet, damit ein geschlossenes Beispiel zur Verringerung der Komplexität enthalten ist. Die Tabellen dienen als Speicherbereich, in den Daten aus den persistenten Datenbanktabellen eingelesen werden und aus dem Daten nach dem Auslösen der Sicherung von modifizierten Instanzen (mit einer COMMIT ENTITIES -Anweisung) in die Datenbanktabellen zurückgesichert werden.

Hinweis

Der Code soll einen Eindruck von den Grundsätzen eines nicht verwalteten RAP-Szenarios vermitteln sowie die Tatsache, dass alles selbst implementiert werden muss, und die Bedeutung des Transaktionspuffers, auf den über ABAP EML zugegriffen werden kann. Deshalb sollte der Code nicht in einem produktiven Szenario wiederverwendet werden.

Datenmodell

Das CDS-Datenmodell besteht aus der Wurzelentität DEMO_UNMANAGED_ROOT_2 und ihrer untergeordneten Entität DEMO_UNMANAGED_CHILD_2.

Wurzelentität:

Kindentität:

Verhaltensdefinition

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

Die Verhaltensdefinition ist die Basis der Implementierung. Sie legt fest, was im Behavior-Pool implementiert werden kann.

Verhaltensimplementierung

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

• lcl_buffer bildet den Transaktionspuffer. Sie beinhaltet interne Tabellen zum Behandeln von Daten.

• lhc_demo_unmanaged_root_2 ist die Handler-Klasse des Behavior-Pools. Die Methode dieser Klasse implemetiert alle Standardoperationen einschließlich einer Fehlerbehebung.

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

Details zu ABP

• lcl_buffer

In dieser lokalen Klasse werden zwei interne Tabellen konstruiert, die als Transaktionspuffer dienen: root_buffer als Transaktionspuffer für die Wurzelentität, und child_buffer für die untergeordnete Entität, um auch die Create- und Read-by-Association-Operationen abzudecken. Die zugrundeliegenden strukturierten Datentypen werden auf eine Weise gebaut, die die Behandlung des Puffers vereinfacht. gty_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. Zusätzlich beinhaltet die Struktur die Komponenten cid zum Halten der Inhalts-ID, die ggf. durch eine Instanz bereitgestellt wird, sowie die zwei Felder (changed und deleted) für eine bequemere Verarbeitung beim Sichern und Löschen von Instanzen als Kennzeichen. Diese Kennzeichen werden während Modify-Operationen gesetzt. Wenn z.B. eine Instanz angelegt oder geändert wird, erhält changed ein X. Wenn eine Instanz gelöscht wird, erhält deleted das Kennzeichen X. Wenn für eine Entität keine Operation stattfindet, bleiben beide Felder initial. Genauso ist der strukturierte Datentyp für die untergeordnete Entität (gty_buffer_child) konstruiert. Er enthält alle Schlüssel- und Datenfelder der CDS-View, die der untergeordneten Entität mit demselben Typ zugrundeliegt (was in diesem Beispiel der Wurzelentität sehr ähnlich ist). Diese Struktur beinhaltet die Komponenten cid_ref für By-Association-Operationen undcid_target für die Inhalts-ID der untergeordneten Instanzen in der %target-Struktur. Letzteres wird in diesem Beispiel nicht verwendet. Des Weiteren ist die Komponente created beinhaltet. Ihr Zweck entspricht dem von changed, jedoch ist sie in diesem Fall nur zum Abdecken von Create-by-Association-Operation relevant. Nur die Instanzen, deren created -Feld mit einem X gekennzeichnet ist, sollten in der Datenbanktabelle der untergeordneten Entität gesichert werden.

• Methoden prep_root_buffer und prep_child_buffer

Diese zwei Methoden sollen die Transaktionspuffer für die Wurzelentität und die untergeordnete Entität vorbereiten und diese mit Daten aus der zugrundeliegenden Datenbanktabelle befüllen, insbesondere, wenn die Puffertabellen bereinigt werden, sobald die Sicherungssequenz durch eine COMMIT ENTITIES-Anweisung im ABAP-Programm ausgelöst wird.

Der Grundsatz von internen Tabellen als Transaktionspuffer ist Folgender: Sobald ein EML-Aufruf Daten (zum Lesen oder Modifizieren) mit einem bestimmten Schlüssel erfordert, wird geprüft, ob der Transaktionspuffer bereits die erforderlichen Daten enthält. Ansonsten wird geprüft, ob die Daten in der persistenten Datenbanktabelle verfügbar sind. Wenn sie dort verfügbar sind, wird die Zeile über die SELECT-Anweisung mit dem angegebenen Schlüssel aus der Datenbanktabelle in den Transaktionspuffer eingelesen. Um doppelte Einträge zu vermeiden, wird in den individuellen Methoden für die Operationen Folgendes gemacht: Wenn die Daten gar nicht existieren (z.B., wenn sie gelöscht wurden), sollten die Strukturen FAILED und REPORTED mit Informationen zu den Datenmengen, die nicht gelesen oder modifiziert werden konnten, befüllt werden. Die Methode prep_child_buffer ist relevant für die By-Association-Operationen. Die Verfügbarkeit der Zeile mit dem angegebenen Schlüssel muss nicht nur im Wurzel-Puffer sondern auch im untergeordneten Puffer geprüft werden. Wenn die Zeile in der zugrundeliegenden Datenbanktabelle der untergeordneten Entität existiert, werden die Daten über die SELECT-Anweisung ebenfalls in den untergeordneten Puffer eingelesen.

• Methode create

Nachdem der Wurzel-Puffer mit den bereitgestellten Eingabeparametern (entities) vorbereitet wurde, kümmert sich eine LOOP AT-Anweisung um die Weiterverarbeitung des Transaktionspuffers mit den individuellen Instanzen, die als Eingabeparameter kommen. Bestimmte Bedingungen müssen erfüllt sein, bevor eine Instanz angelegt werden kann. Wenn die Bedingungen für eine bestimmte Instanz nicht erfüllt werden, kommt es in den Strukturen FAILED and REPORTED zu einem Eintrag für die fehlgeschlagene Instanz. Wenn diese Instanzen im Transaktionspuffer enthalten sind und die Bedingungen erfüllen, erhalten sie ein Kennzeichen im Feld changed und können schließlich angelegt werden. Die Instanzen werden daraufhin über die Anweisung COMMIT ENTITIES im ABAP-Programm in der Datenbanktabelle gesichert und lösen eine Sicherungssequenz aus. Die Prüfungen berücksichtigen auch die Bedeutung der Kennzeichnen in der %control-Struktur, d.h., wenn ein Datenfeld mithilfe der Konstante mk-off der Schnittstelle ABP_BEHV_FLAG entmarkiert wird, sollte dieses Feld nicht mit den bereitgestellten Werten angelegt werden.

• Methode update

Wie bei der zuvor beschriebenen Methode kümmert sich eine LOOP AT-Anweisung um die Weiterverarbeitung des Transaktionspuffers mit den individuellen Instanzen, die als Eingabeparameter kommen, nachdem der Wurzel-Puffer mit den bereitgestellten Eingabeparametern (entities) vorbereitet wurde. Auch hier müssen bestimmte Bedingungen erfüllt sein, bevor eine Instanz angelegt werden kann. Wenn die Bedingungen für eine bestimmte Instanz nicht erfüllt werden, wird in den Strukturen FAILED and REPORTED ein Eintrag für die fehlgeschlagene Instanz angelegt. Die Prüfungen werden so implementiert, dass die vorhandenen Werte eines Datenfelds nicht überschrieben werden sollten, wenn es in der %control-Struktur explizit entmarkiert ist. Genauso wie oben erhält eine geänderte Instanz ein Kennzeichen. Darüber hinaus werden die IF-Anweisungen für zwei Szenarien implementiert. Es kann passieren, dass eine EML-Anforderung nur die Schlüssel oder nur %cid_ref enthält. Im letzeren Fall wird ein potentiell bereitgestellter Schlüssel ignoriert, da die Refernz auf eine bestimmte%cid die Hauptreferenz ist.

• Methode delete

Diese Methode wird ähnlich wie die Methode update implementiert. Beispielsweise berücksichtigt sie die zwei Szenarien, wenn nur der Schlüssel oder nur %cid_ref bereitgestellt werden. Wenn eine Instanz gelöscht werden soll, erhält sie ein Kennzeichen für das Feld deleted. Das Feld changed wird initialisiert. %control ist hier nicht relevant.

• Methode read

Nachdem der Wurzel-Puffer mit den bereitgestellten Eingabeparametern (keys) vorbereitet wurde, kümmert sich eine LOOP AT-Anweisung um die detaillierte Vorbereitung und Befüllung der gelesenen Tabelle result gemäß den Schlüsseln, die als Eingabeparameter kommen und unter Berücksichtigung der Kennzeichen für die Felder in der %control-Struktur. Wenn ein Datenfeld entmarkiert ist, sollte dieses Feld nicht gelesen und in das Leseergebnis eingeschlossen werden. Der Schlüssel muss immer gelesen und zurückgegeben werden.

• Methode rba_child

Als initialer Schritt in der Methode für Read-By-Association-Operationen müssen sowohl Wurzel-Puffer als auch untergeordnete Puffer vorbereitet werden. Wie auch bei der Methode read, kümmert sich eine LOOP AT-Anweisung um die detaillierte Vorbereitung und Befüllung der Tabelle read result gemäß den Schlüsseln, die als Eingabeparameter kommen und unter Berücksichtigung der Kennzeichen für die Felder in der %control-Struktur. Wenn ein Datenfeld entmarkiert ist, sollte dieses Feld nicht gelesen und in das Leseergebnis eingeschlossen werden. Der Schlüssel muss immer gelesen und zurückgegeben werden.

• Methode cba_child

Als initialer Schritt in der Methode für Create-By-Association-Operationen müssen sowohl Wurzel-Puffer als auch untergeordnete Puffer vorbereitet werden. Die Bedingungen für die Befüllung des untergeordneten Puffers innerhalb der LOOP AT-Anweisung beinhaltet Prüfungen für zwei Szenarien. Es kann passieren, dass eine EML-Anforderung nur die Schlüssel oder nur %cid_ref enthält. Im letzeren Fall wird ein potentiell bereitgestellter Schlüssel ignoriert, da die Refernz auf eine bestimmte%cid die Hauptreferenz ist. Die Kennzeichen in der %control-Struktur für die Datenfelder werden ebenfalls berücksichtigt. Wenn die Bedingungen für eine Instanz, die in der untergeordneten Entität angelegt werden soll, erfüllt sind, erhält die Instanz ein Kennzeichen für das Feld created.

• Klasse lsc_demo_unmanaged_root

Die Methode finalize löscht alle Inhalts-IDs aus dem Transaktionspuffer, da sie während der Sicherungsphase nicht verwendet werden dürfen. Jedoch ist sie für das Beispiel nicht relevant.

Die Methode save enthält Anweisungen, die für das Sichern der Instanzen aus der Transaktionspuffer zuständig sein, d.h. aus den internen Tabellen root_buffer und child_buffer zu den Datenbanktabellen (demo_tab_root_3 und demo_tab_child_3). Unter den Anweisungen gibt es einen Quelltextblock, der sich mit Create- und Update-Operationen beschäftigt. 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. Es gibt einen anderen Block für die Löschung. Ähnlich umfasst eine interne Hilfstabelle die Instanzen, die ein Kennzeichen für deleted haben. Das Sichern von Instanzen über Create-by-Association-Operationen wird im Beispiel separat behandelt, da die Instanzen aus dem untergeordneten Puffer (die Instanzen mit einem Kennzeichen für created) und nicht die aus dem Wurzelpuffer berücksichtigt werden müssen, wie es in den zwei vorangehenden Quelltextblocks der Fall war.

Die Methode cleanup bereinigt die Puffertabellen.

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: Der Hauptfokus des Programms liegt darin, einfache EML-Aufrufe zu demonstrieren, die auf den Transaktionspuffer zugreifen und RAP-BO-Instanzen der Wurzelentität und der untergeordneten Entität modifizieren, oder lesen und entsprechend zurückgeben. Alle Standardoperation sind abgedeckt: CREATE, CREATE BY, UPDATE, DELETE, READ und READ BY. Über die Anweisungen COMMIT ENTITIES wird die Sicherung der geänderten Instanzen ausgelöst. Um die erfolgreiche Sicherung der Instanz zu demonstrieren, wird eine interne Tabelle angezeigt, die mit den aktuellen Datenmengen, die in der persistenten Datenbanktabelle enthalten sind, befüllt wird (über die Anweisung SELECT). Des Weiteren enthalten die Modify- und Read-Operationen die Strukturen FAILED und REPORTED. Das Beispiel berücksichtigt Fälle, in denen Instanzen absichtlich nicht geändert oder gelesen werden können. Um die Antworten der fehlgeschlagenen Instanzen im Ausgabefenster anzuzeigen, umfasst die Methode display_responses den Aufbau und das Befüllen von internen Tabellen, um die zurückgegebenen Informationen für fehlgeschlagene Instanzen zu halten. Die Informationen, die für die fehlgeschlagenen Instanzen angezeigt werden, basieren auf den individuellen ABP-Methodenaufrufen, die sich um das Befüllen der Antwortstrukturen kümmern. Die bereitsgestellten Informationen werden absichtlich einfach und begrenzt gehalten.

Die angezeigten FAILED-Tabellen umfassen die Fehleruhrsache (es ist keine bestimmte Logik zur Spezifizierung der Fehlerursache implementiert), die Inhalts-ID und den Schlüssel der betroffenen Instanzen sowie der betroffenen Operation oder Assoziation (bererits durch den Eintrag 01 vermerkt). Die angezeigten REPORTED-Tabellen umfassen Informationen zu der Dringlichkeit des Vorfalls, der Inhalts-ID und dem Schlüssel zur benutzerdefininierten Nachricht.

• Manche Felder werden absichtlich nicht befüllt, um die Bedeutung der %control-Struktur zu verdeutlichen. D.h., wenn ein Feld entmarkiert ist, wird es nicht für die Operation berücksichtigt. Aus diesem Grund wird im Beispiel das Schlüsselwort FROM nach dem Schlüsselwort für die Operation verwendet, da %control in diesem Fall explizit befüllt werden muss.

• Die Modify-Operationen, die sich auf UPDATE und DELETE konzentrieren, beinhalten zusätzliche CREATE-Operationen für Instanzen, dir eine Inhalts-ID halte. Dadurch können auch die UPDATE- und DELETE-Operationen die Verwendung von %cid und %cid_ref demonstrieren.

BAL_S_LOG - Application Log: Log header data   ABAP Short Reference  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 20345 Date: 20240523 Time: 172730     sap01-206 ( 406 ms )