Ansicht
Dokumentation

ABENABP_SAVER_LN_ABEXA - ABP SAVER LN ABEXA

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

Beispiel für RAP-Saver-Methode (Szenario der späten Nummernvergabe)

Mit diesem Beispiel werden RAP-Saver-Methoden innerhalb einer RAP-Saver-Klasse mit einem einfachen nicht verwalteten RAP-BO und später Nummernvergabe demonstriert und dabei auch die Saver-Methode adjust_numbers abgedeckt.

Datenmodell

Das CDS-Datenmodell besteht aus der Wurzelentität DEMO_UMANAGED_ROOT_LATE_NUM2 und ihrer untergeordneten Entität DEMO_UMANAGED_CHILD_LATE_NUM2.

Wurzelentität:

Kindentität:

Verhaltensdefinition

Die CDS-Verhaltensdefinition DEMO_UMANAGED_ROOT_LATE_NUM2 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_UMANAGED_ROOT_LATE_NU2. Die eigentliche Verhaltensimplementierung findet in lokalen Klassen statt, die im BP_DEMO_UMANAGED_ROOT_LATE_NU2CCIMP des Verhaltens-Pools definiert und implementiert werden. Der ABP enthält absichtlich wenige Behandlermethodenimplementierungen, da die Betonung bei den Saver-Methoden liegt.

Die Klasse lsc_demo_umanaged_root_late_nu ist die RAP-Saver-Klasse, die folgende RAP-Saver-Methoden enthält:

Methode	Details
finalize	Hiermit werden endgültige Berechnungen mit den BOs in der aktuellen LUW vor der Sicherung auf der Datenbank ausgelöst. In diesem Beispiel wird die Methode für eine Berechnung auf einem Datenfeld implementiert. field3 wird durch 2 geteilt. Da das Feld vom Typ i ist, führt eine Teilung durch zwei bei ungeraden Zahlen zu einem Fehler. Bei einem Fehler werden die Parameter FAILED und reported gefüllt. Bei einer erfolgreichen Teilung erhält field3 das Ergebnis und eine Erfolgsmeldung wird in den Parameter reported für die jeweilige Instanz aufgenommen. Eine Protokolltabelle (DEMO_TAB_LOG_LN) wird dann mit dem Inhalt der Strukturen failed (wenn verfügbar) und reported. Das Ziel dieser Protokolltabelle ist es, die zurückgegebenen Meldungen der Methoden finalize, check_before_save und save in der Ausgabe zu zeigen.
check_before_save	Enthält eine Konsistenzprüfung. Eine Instanz sollte nur gesichert werden, wenn der Wert des Datenfelds field4 100 nicht überschreitet. Weiterhin werden die Parameter failed und reported und die Protokolltabelle DEMO_TAB_LOG_LN gefüllt.
adjust_numbers	Ordnet die endgültigen Primärschlüssel der RAP-BO-Instanzen zu. In diesem Beispiel wird ein Zufalls-Integer zugeordnet. Nach Aufruf der Methode ist keine Rückkehr mehr möglich. Die Methode muss gewährleisten, dass die Schlüsselzuordnung keine Fehler enthält. Daher wird eine Prüfung dahingehend implementiert, dass keine Zufallszahl für Instanzen existiert, weder im transaktionalen Puffer noch in der Datenbanktabelle. Weiterhin werden die Parameter failed und reported und die Protokolltabelle DEMO_TAB_LOG_LN gefüllt.
save	Speichert die Daten aus dem transaktionalen Puffer in die Datenbank. Die Methode wird nur bei erfolgreichen Verarbeitung der Methoden finalize, check_before_save und adjust_numbers aufgerufen. Nachdem die Daten gesichert werden, wird eine Erfolgsmeldung in den Parameter reported und die Protokolltabelle DEMO_TAB_LOG_LN aufgenommen.
cleanup	Hiermit wird der Transaktionspuffer geleert. Diese Methode wird bei Verarbeitung der Methode save gerufen.
cleanup_finalize	Hiermit wird der Transaktionspuffer geleert. Diese Methode wird bei Problemen in den Methoden finalize und check_before_save gerufen.

Quelltext

Ausführen

Beschreibung

Zugriff mit ABAP über EML

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

Mit diesem Beispiel werden drei unterschiedliche -MODIFY-Anforderungen demonstriert. Jede MODIFY-Anforderung enthält CREATE-Operationen, um drei Instanzen anzulegen. COMMIT ENTITIES-Anweisungen stoßen die Sicherungssequenz an.

1. Erste MODIFY-Anforderung: Die Methode finalize wird nicht erfolgreich verarbeitet und die Daten werden nicht gesichert.
2. Zweite MODIFY-Anforderung: Die Methode finalize wird erfolgreich verarbeitet und die Methode check_before_save nicht. Die Daten werden nicht gespeichert.
3. Dritte MODIFY-Anforderung: Die Methoden finalize und check_before_save werden erfolgreich verarbeitet. Folglich werden die Methoden adjust_numbers und save gerufen und die Daten auf der Datenbanktabelle gesichert.

Die Ausgabe zeigt drei Abschnitte für jede MODIFY-Anforderung:

• Eine Protokolltabelle mit den gerufenen Saver-Methoden.

• Eine Protokolltabelle mit zurückgegebener Information für FAILED und REPORTED. In allen Fällen wird die Vorab-ID %pid für die Instanzen aufgenommen. Bei der letzten Anforderung werden die neu zugeordneten Schlüssel auch aufgenommen.

• Eine Tabelle mit den Datenbanktabelleneinträge nach den CREATE-Operationen. Die ersten beiden MODIFY-Anweisungen zeigen die Tabelle nicht, da die CREATE-Operationen absichtlich nicht erfolgreich verarbeitet werden können.

Vendor Master (General Section)   TXBHW - Original Tax Base Amount in Local Currency  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 7718 Date: 20240523 Time: 162008     sap01-206 ( 69 ms )