Ansicht
Dokumentation

ABENRPM_SAVER_CLASS - RPM SAVER CLASS

Vendor Master (General Section)   CL_GUI_FRONTEND_SERVICES - Frontend Services  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Saver-Klasse

Syntax

CLASS lcl_saver_name DEFINITION
      INHERITING FROM cl_abap_behavior_saver
        $[ABSTRACT$] $[FINAL$].
  PROTECTED SECTION.
    METHODS finalize          REDEFINITION.
    METHODS check_before_save REDEFINITION.
    METHODS adjust_numbers    REDEFINITION.
    METHODS save              REDEFINITION.
    METHODS cleanup           REDEFINITION.
ENDCLASS.

CLASS lcl_saver_name IMPLEMENTATION.
  METHOD finalize.
    ...
  ENDMETHOD.
  METHOD check_before_save.
    ...
  ENDMETHOD.
  METHOD adjust_numbers.
    ...
  ENDMETHOD.
  METHOD save.
    ...
  ENDMETHOD.
  METHOD cleanup.
    ...
  ENDMETHOD.
ENDCLASS.

Wirkung

Innerhalb des Behavior-Pools wird eine lokale Saver-Klasse zur Implementierung der Sicherungsphase des Business-Objekt-Verhaltens definiert. Die Sicherungsphase besteht aus einer Folge von Aufrufen zur Synchronisation der beteiligten Business-Objekten. Erst der letzte Aufruf in dieser Folge ist die eigentliche save-Methode, in der die Änderungen auf die Datenbank geschrieben werden dürfen und müssen.

Die Saver-Klasse lcl_saver ist implizit als ABSTRACT und FINAL definiert und von der Klasse CL_ABAP_BEHAVIOR_SAVER abgeleitet. Es gibt keine speziellen Regeln für den Namen der Saver-Klasse.

Die transaktionalen Methoden finalize, check_before_save, adjust_numbers, save und cleanup sind in einer Saver-Klasse implementierbar:

• finalize
  Schließt Änderungen an Daten ab, bevor sie in der Datenbank gespeichert werden können.

• check_before_save
  Überprüft den Anwendungspuffer auf Konsistenz.

• adjust_numbers
  Implementiert die späte Nummernvergabe .

• save
  Speichert die Daten aus dem transaktionalen Puffer in die Datenbank.

• cleanup
  Verwirft alle Datenänderungen und bereinigt den transaktionalen Puffer.

Die dem Saver-Protokoll entsprechenden Methoden finalize, check_before_save, adjust_numbers, save und cleanup haben keine individuelle Signatur, sondern sind alle bereits in der Basisklasse CL_ABAP_BEHAVIOR_SAVER definiert. Die abgeleitete konkrete Saver-Klasse muss diese Methoden per REDEFINITION implementieren. Bei der Redefinition werden die Typen der in der Basisklasse definierten Parameter failed, mapped und reported durch konkrete abgeleitete Typen ersetzt. Diese Parameter sind in der Basisklasse generisch als CHANGING-Parameter deklariert.

Die Implementierung der Methoden finalize, check_before_save und cleanup ist nicht obligatorisch. Die einzige zwingende Redefinition ist die Methode save. Wenn die Verhaltensdefinition die späte Nummernvergabe spezifiziert, muss auch die Methode adjust_numbers implementiert werden. Darin wird die Struktur mapped gefüllt.

Anders als in der Interaktionsphase werden in der Sicherungsphase keine Instanz-Daten übergeben. Der Saver selbst muss wissen (durch die Kooperation mit der Handler bzw. der dahinterliegenden Legacy-Funktionalität), wo die Daten liegen, für die er zum Beispiel die Methode finalize durchführen soll, nämlich in dem transaktionalen Puffer, den die Anwendung verwalten muss.

Die Saver-Sequenz finalize, check_before_save, adjust_numbers, save, cleanup wird in dieser Reihenfolge für jedes Business-Objekt aufgerufen, nachdem mindestens eine erfolgreiche Änderung mithilfe des Business-Objekt-Providers in der aktuellen LUW durchgeführt wurde. Eine erfolgreiche Saver-Sequenz:

• Die Saver-Sequenz beginnt mit der Methode finalize, die abschließende Berechnungen und Datenänderungen ausführt, bevor Daten in die Datenbank gespeichert werden können.

• Wenn keine Fehler von der Methode finalize gemeldet werden, wird die nachfolgende Methode check_before_save aufgerufen.

• Wenn die Methode check_before_save keine Fehler zurückgibt, ist der Punkt erreicht ab welchem ein erfolgreiches Speichern für alle beteiligten Business-Objekte garantiert ist. Nach diesem Punkt wird die Methode adjust_numbers aufgerufen, um die späte Nummernvergabe zu berücksichtigen.

• Schließlich wird die Methode save aufgerufen, um alle Daten der Business-Objekt-Instanz aus dem transaktionalen Puffer in die Datenbank zu speichern.

• Am Ende wird die Methode cleanup aufgerufen, um den transaktionalen Puffer zu löschen.

Wenn die Methoden finalize oder check_before_save einen Fehler zurück geben, wird die Methode cleanup aufgerufen, um alle Änderungen an den in der aktuellen LUW vorgenommenen Daten zu verwerfen und den transaktionalen Puffer zu bereinigen.

Während die Methoden finalize und check_before_save noch fehlschlagen können, ist dies bei den darauf folgenden Methoden nicht mehr möglich. Darum gibt es ab der Methode adjust_numbers die Parameter failed und reported nicht mehr.

Im folgenden Beispiel werden die Daten aus dem ABAP-Flugdaten-Referenzszenario (Kurz: Flugdaten-Szenario) verwendet. Es stellt eine Legacy-Business-Logik dar, mit der Flugbuchungen erstellt und bearbeitet werden können. Die Wurzel-Entität Travel repräsentiert das Business-Objekt zur Verwaltung von Flugreisen. Das zugrundeliegende Datenmodell und das Verhalten der Wurzel-Entität Travel sind im Abschnitt ABAP BDL - Beispiel beschrieben.

CLASS lcl_travel_saver DEFINITION
      INHERITING FROM cl_abap_behavior_saver.
  PROTECTED SECTION.
    METHODS finalize          REDEFINITION.
    METHODS check_before_save REDEFINITION.
    METHODS save              REDEFINITION.
    METHODS cleanup           REDEFINITION.
ENDCLASS.

CLASS lcl_saver IMPLEMENTATION.

  METHOD finalize.
    ...
  ENDMETHOD.

  METHOD check_before_save.
    ...
  ENDMETHOD.

  METHOD adjust_numbers.
    ...
  ENDMETHOD.

  METHOD save.
    ...
  ENDMETHOD.

  METHOD cleanup.
    ...
  ENDMETHOD.

ENDCLASS.

TXBHW - Original Tax Base Amount in Local Currency   BAL_S_LOG - Application Log: Log header data  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 12510 Date: 20240523 Time: 093144     sap01-206 ( 153 ms )