Ansicht
Dokumentation

ABENRAP_HANDLER_METHODS_ABEXA - RAP HANDLER METHODS ABEXA

RFUMSV00 - Advance Return for Tax on Sales/Purchases RFUMSV00 - Advance Return for Tax on Sales/Purchases
Diese Dokumentation steht unter dem Copyright der SAP AG.

Beispiel für RAP-Behandlermethoden

Dieses Beispiel zeigt verschiedene RAP-Behandlermethoden mit einem nicht verwalteten und draftfähigen RAP BO.

Beachten Sie, dass das vereinfachte Beispiel kein reales Geschäftsszenario repräsentiert. Der Fokus liegt auf den technischen Aspekten, indem ein Überblick über die Selbstimplementierung der Behandlermethoden eines ABAP-Behavior-Pools (ABP) und den Umgang mit den Methodenparametern gegeben wird. Der Quelltext sollte nicht in einem produktiven Szenario wiederverwendet werden.

Datenmodell

Das CDS-Datenmodell besteht aus der Wurzelentität DEMO_MANAGED_ROOT_DRAFT und ihrer untergeordneten Entität DEMO_MANAGED_CHILD_DRAFT.

Wurzelentität:

Untergeordnete Entität:

Verhaltensdefinition

Die CDS-Verhaltensdefinition DEMO_UNMANAGED_ROOT_DRAFT 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_DRAFT. Die eigentliche Verhaltensimplementierung findet in lokalen Klassens statt, die im BP_DEMO_UNMANAGED_ROOT_DRAFT==CCIMP des Behavior-Pools definiert und implementiert werden.

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

lhc_demo_unmanaged_root_draft ist die Behandlerklasse des Behavior-Pools.

lsc_demo_unmanaged_root_draft ist die Saver-Klasse des Behavior-Pools.

Behandler- und Saver-Klasse für die untergeordnete Entität sind in diesem Beispiel nicht relevant.

Details zu ABP

Transaktionspuffer

Klasse / Methode	Details
Lokale Klasse 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. \lbr \lbr 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 und cid_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. \lbr 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.

Behandlermethoden

In jeder Methode wird der Name der Methode zu einer interne Tabelle in der globalen Klasse hinzugefügt. Diese interne Tabelle wird in der Ausgabe mehrmals angezeigt, um die Sequenz der RAP-Behandlermethodenaufrufe zu protokollieren und zu visualisieren.

Die Methodendefinitionen beinhalten in den meisten Fällen die explizite Spezifikation der Änderungsparameter.

In den meisten Methodenimplementierungen sind die Parameter failed und reported befüll.

Methode	Details
create	Nachdem der Wurzel-Puffer mit den bereitgestellten Eingabeparametern (entities) vorbereitet wurde, kümmert sich eine LOOP AT-Anweisung um die Verarbeitung 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.
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.
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.
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.
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.
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.
action1	Aktualisiert die Zeichenkette in Feld field2 für alle angeforderten Instanzen. \lbr CDS-BDL-Information: action.
action2	Eine mit result angegebende Aktion in der BDEF Aktualisiert die Zeichenkette in Feld field1 für alle angeforderten Instanzen. Zusätzlich wird der Ergebnisparameter der Aktion befüllt. \lbr CDS-BDL-Information: action.
action3	Eine mit parameter und result selective angegebene Aktion in der BDEF. In diesem Beispiel stellt der Eingabeparameter einen Prozentrabatt dar und die Aktion zieht den Rabatt vom Wert der Felder field3 und field4 einer Entitätsinstanz ab. Zusätzlich wird der Ergebnisparameter der Aktion mit den Werten der angeforderten Felder befüllt. \lbr CDS-BDL-Information: action.
action4	Legt Instanzen auf Basis von Schlüsseln an, die vom RAP-Consumer angegeben werden. Da action4 in der BDEF mit precheck angegeben wird, wird die Methode precheck_action4 vorab aufgerufen, um die Eindeutigkeit der Schlüssel zu prüfen. \lbr CDS-BDL-Information: action, precheck.
precheck_action4	Überprüft, dass die Primärschlüssel für neu angelegte Entitätsinstanzen mit action4 eindeutig sind. Da action4 in der BDEF mit precheck angegben wird, wird die Methode precheck_action4 vor action4 aufgerufen. In diesem Beispiel wird die Eindeutigkeitsprüfung in der Methode create implementiert. Hier ist sie zu Demonstrationszwecken verfügbar, sodass sich die Vorprüfung und anderen Operationen nicht beeinträchtigen, z.B. wenn die Notation create in der BDEF mit precheck angegeben wurde. \lbr CDS-BDL-Information: precheck.
function1	Statische Funktion, die für das gesamte BO und nicht nur für eine bestimmte Entitätsinstanz gilt. Die Funktion filtert zuerst alle Entitätsinstanzen. Der Wert von field3 sollte höher als 100 sein. Anschließend summiert sie die Werte von Feld field3. Der Wert der Summe wird an den Ergebnisparameter zurückgegeben. \lbr CDS-BDL-Information: function.
function2	Eine in der BDEF mit parameter angegebene Instanzfunktion. Voraussetzung für die Ausführung der Funktion ist die Angabe einer Entitätsinstanz und eines Wertes für den Eingabeparameter. In diesem Beispiel stellt der Eingabeparameter einen Prozentrabatt dar und die Funktion zieht den Rabatt vom Wert des Feldes field3 einer Entitätsinstanz ab. Der reduzierte Wert wird an den Ergebnisparameter zurückgegeben. \lbr CDS-BDL-Information: function.
function3	Eine in der BDEF mit result selective angegebene Instanzfunktion. Der Importparameter requested_fields wird berücksichtigt. Es werden nur die Felder befüllt, die vom RAP-Consumer angefordert werden. \lbr CDS-BDL-Information: function.
get_instance_authorizations	Gleicht Berechtigungen mit dem persistenten Zustand der Instanz ab. Die Methode gibt Informationen darüber zurück, ob Update- und Delete-Operationen sowie die Ausführung von Aktionen auf Instanzen erlaubt ist. In diesem Beispiel sind sie nicht erlaubt, wenn field2 einen bestimmten Wert hat. \lbr CDS-BDL-Information: authorization.
lock	Ein Sperrobjekt(ELOCKRAP) ist für die Datenbanktabelle verfügbar. Die Methode sperrt die aktiven Instanzen auf Basis der Schlüssel (key_field). Zur Visualisierung der Sperre kann die globale Sperrtabelle (Transaktion SM12) während des Debuggings des Programms geprüft werden. Die Sperren werden entfernt, nachdem die Anweisung COMMIT ENTITIES ausgeführt wurde. Im Hinblick auf die Bearbeitung von Draft-Instanzen werdem die Sperren entfernt, nachdem die Draft-Aktion activate fertiggestellt wurde. \lbr CDS-BDL-Information: locking.
get_instance_features	Diese Methode gibt Informationen darüber zurück, ob ein bestimmtes Feld (field3) schreibgeschützt ist oder auf Basis einer bestimmten Bedingung modifiziert werden kann. \lbr CDS-BDL-Information: feature control.
get_global_features	Diese Methode gibt Informationen darüber zurück, ob Update- und Delete-Operationen auf Instanzen auf Basis einer bestimmten Bedingung erlaubt sind oder nicht. \lbr CDS-BDL-Information: feature control.
get_global_authorizations	Die Methode ist so implementiert, dass Modify-Operationen nur für Benutzer mit entsprechenden Berechtigungen aktiviert sind. Um die Demonstration einfach zu halten, kommt das Beispiel ohne ein Berechtigungsobjekt aus, z.B. eine Art und Weise der Behandlung einer Berechtigungsgewährung in produktiven Anwendungen. Die Variable auth_flag stellt die Berechtigung dar, die gewährt wird oder nicht. In diesem Beispiel wird die Erlaubnis immer gewährt. \lbr CDS-BDL-Information: authorization.
det_on_modify	Fügt eine Zeichenkette zum vorhandenen Zeichenkettenwert in Feld field1 hinzu. \lbr CDS-BDL-Information: determination.
det_on_save	Führt eine einfache Berechnung auf dem Wert in Feld field4 aus. \lbr CDS-BDL-Information: determination.
validation	Püft, ob der Wert von field3 höher als 1000 ist. \lbr CDS-BDL-Information: validation.
activate	Führt eine einfache Berechnung auf dem Wert in Feld field3 aus. \lbr CDS-BDL-Information: draft action.
discard	Entfernt Unterstriche aus der Zeichenkette in Feld field1. \lbr CDS-BDL-Information: draft action.
edit	Konvertiert die Zeichenkette in Feld field1 in Großbuchstaben. \lbr CDS-BDL-Information: draft action.
resume	Enthält keine Implementierungen auf Draft-Instanzen. Es ist aktuell nicht möglich, diese Methode im Demonstrationsprogramm aufzurufen und zu debuggen. \lbr CDS-BDL-Information: draft action.
earlynumbering_create	Frühe Nummernvergabe gilt für Primärschlüssel. In diesem Beispiel sollte der Schlüssel eine Zufallszahl zwischen 50 und 100 sein. Die Schlüssel sind auf %cid gemappt. \lbr CDS-BDL-Information: early numbering.

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 Haupfokus des Programms liegt darin, RAP-Behandlermethoden mit mehreren EML-Anforderungen zu demonstrieren.

Die Ausgabe zeigt mehrere Läufe von Operationen auf RAP BOs, um die Auswirkung von Implementierungen in den RAP-Behandlermethoden, wie zuvor beschrieben, zu visualisieren. Damit das Programm erfolgreiche Modify-Operationen anzeigt, muss es in einem bestimmten Zeitfenster ausgeführt werden (siehe Methode get_global_features). Andernfalls werden alle Modify-Operationen nicht erlaubt.

Erster Lauf von Standardoperationen auf aktiven Instanzen mithilfe von EML MODIFY

Zuerst legen die Operationen CREATE und CREATE BY Instanzen für die Wurzelentität und die untergeordnete Entität an. Dieselbe Modify-Anforderung beinhaltet die Operationen UPDATE und DELETE auf den neu angelegten Instanzen der Wurzelentität. Die Parameter mapped, failed und reported werden durch ihre Behandlermethoden befüllt. Die Information, die von diesen Parametern zurückgegeben wird, wird in internen Tabellen angezeigt. Darunter sind Instanzen, die absichtlich nicht angelegt, aktualisiert oder gelöscht werden können. Eine COMMIT ENTITIES-Anweisung stoßt die Sicherungssequenz an. Das Ergebnis der Sicherung bzw. die auf den Datenbanktabellen persistierten Einträge werden ebenfalls in internen Tabellen angezeigt. Vor den Datenbankeinträgen wird eine andere interne Tabelle angezeigt, angestoßen von der Methode get_handler_meth, die die Behandlermethodennamen zeigt. In diesem Lauf von EML-Modify-Operationen wird diese interne Tabelle als Protokollierung und Visualisierung der Sequenz der RAP-Behandlermethodenaufrufe gesehen.

Zweiter Lauf von Standardoperationen auf aktiven Instanzen mithilfe von EML MODIFY

Der Zweck des zweiten Laufs mit derselben Menge von Modify-Operationen ist es, die Auswirkung von weiteren Behandlermethoden zu visualisieren, z.B. get_instance_authorizations und get_instance_features. Das Beispiel demonstriert, dass bestimmte Modify-Operationen nicht erfolgreich sind, weil die Bedingungen, die in diesen Methodenimplementierungen festgelegt sind, nicht erfüllt werden.

Aktionen aus aktiven Instanzen ausführen

Mehrere Aktionen werden in diesem Beispiel abgedeckt. Alle Aktionen haben verschiedene Spezifikationen in der BDEF, um die Vielzahl von möglichen Parametern für Aktionen in ABP zu zeigen. Zum Beispiel beinhalten manche Aktionen Ergebnis- oder Anforderungsparameter. Das Muster für diese Aktionen in der Ausgabe ist immer dasselbe: die Antwortparameter werden in internen Tabellen angezeigt, genauso wie die Auswirkung der Aktionsausführung, indem die Datenbanktabelleneinträge in interne Tabellen gezeigt werden. Zusätzlich wird die Protokolltabelle der Behandlermethode für alle Aktionen angezeigt. Das Aktionsergebnis wird für die Aktionen angezeigt, die einen Ergebnisparameter beinhalten. Aktion action4 ist ein Sonderfall, da sie in der BDEF mit precheck angegeben wird. Daher muss die Auswirkung der Methode precheck_action4 berücksichtig werden.

READ, READ BY-Operationen und ausführende Aktionen auf aktiven Instanzen

Zuerst werden READ und READ BY-Operationen abgedeckt. Die Methode rba_child beinhaltet einen Zusatzparameter (association_links). Der Inhalt wird ebenfalls in einer internen Tabelle angezeigt, mit Ausnahme der Antwortinformation und des Leseergebnisses. Danach werden im Beispiel mehrere Funktionen abgedeckt. Alle Funktionen haben verschiedene Spezifikationen in der BDEF, um die Vielzahl von möglichen Parametern für Funktionen in ABP zu zeigen. Zum Beispiel beinhaltet eine Funktion Anforderungsparameter. Das Muster für diese Funktionen in der Ausgabe ist immer dasselbe: die Antwortparameter werden in internen Tabellen angezeigt, genauso wie die Auswirkung der Funktionen, indem die Leseergebnisse gezeigt werden. Zusätzlich wird die Protokolltabelle der Behandlermethode für alle Aktionen angezeigt. Das Aktionsergebnis wird für die Aktionen angezeigt, die einen Ergebnisparameter beinhalten.

Draft-Instanzen anlegen

Zuerst werden neue Draft-Instanzen angelegt, indem der Indikator %is_draft entsprechend gekennzeichnet wird. Die Instanzen beinhalten keinen Schlüssel. Stattdessen beinhalten sie eine Inhalts-ID (%cid). Die Schlüsselzuordnung erfolgt mit der Methode earlynumbering_create. Die Protokolltabelle der Behandlermethode zeigt, dass die Determinierung det_on_modify ebenfalls aufgerufen wurde. In der Ausgabe werden die Antwortinformationen gezeigt, bevor die angelegten Draft-Instanzen festgeschrieben werden. Mit der Anweisung COMMIT ENTITIES wird das Sichern von Draft-Instanzen in Draft-Tabellen angestoßen. Die Ausführung der Methode activate macht die Draft-Instanzen zu aktiven Instanzen, und die nachfolgende Anweisung COMMIT ENTITIES stößt schließlich das Sichern der originalen Draft-Instanzen in der Datenbanktabelle an. Bei der Ausführung der Draft-Aktion werden unter anderem die Methoden det_on_save und validation aufgerufen. Die Methode discard wird zuletzt aufgerufen. Die Ausgabe zeigt vier interne Tabellen, die den Zustand von Draft- und Datenbanktabellen protokollieren - vor und nach der Aktivierung.

Draft-Tabelle vor der Aktivierung: Alle angelegten Draft-Instanzen sind in der Draft-Tabelle verfügbar. Einfache Bearbeitungen, z.B. auf Feld field1, angestoßen von der Methode det_on_modify, sind sichtbar.
Datenbanktabelle vor der Aktivierung: Zeigt keine Änderungen an Einträgen.
Draft-Tabelle nach der Aktivierung: Da die Validierung für eine Instanz fehlgeschlagen ist, ist sie immer noch in der Draft-Tabelle vorhanden. Sie kann im Beispiel ignoriert werden. Jedoch ist zu sehen, dass zwei andere Instanzen nicht mehr vorhanden sind.
Datenbanktabelle nach der Aktivierung: Zwei der drei originalen Draft-Instanzen wurden in der Datenbanktabelle gesichert. Einfache Bearbeitungen, z.B. auf Feld field1, angestoßen von der Methode discard, sind sichtbar.

Draft-Instanzen aktualisieren

Durch die Ausführung der Draft-Aktion edit werden persistierte Instanzen in die Draft-Tabelle eingefügt und auf der Datenbanktabelle gesperrt. Die Auswirkung der Sperre kann beim Debugging in Transaktion SM12 geprüft werden. Wie zuvor, zeigen in der Ausgabe vier interne Tabellen den Zustand der Draft- und Datenbanktabelle. Die Datenbanktabelle nach der Aktivierung zeigt die erfolgreiche Sicherung von Instanzen mit der einfachen Bearbeitung, angestoßen von der Methode edit.

ROGBILLS - Synchronize billing plans ROGBILLS - Synchronize billing plans
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 32399 Date: 20240523 Time: 113557 sap01-206 ( 691 ms )

Ansicht Dokumentation