Komponenten des Transaktionsdiensts
Komponenten des Transaktionsdiensts
Eine objektorientierte Transaktion wird durch ein Transaktionsobjekt repräsentiert, das durch einen Transaktionsmanager (ebenfalls ein Objekt) verwaltet wird. Der Transaktionsmanager repräsentiert den Transaktionsdienst gegenüber dem ABAP-Programm.
CL_OS_SYSTEM
Um einen Transaktionsmanager zu erzeugen benötigt man die statische Methode GET_TRANSACTION_MANAGER der allgemeinen Systemdienstklasse CL_OS_SYSTEM. Weiterhin wird der
Transaktionsmodus mit der Methode INIT_AND_SET_MODES dieser Klasse gesetzt.IF_OS_TRANSACTION_MANAGER und IF_OS_TRANSACTION
Das ABAP-Programm arbeitet nicht über Klassenreferenzvariablen mit dem Transaktionsmanager und der Transaktion, sondern greift über die Interfaces IF_OS_TRANSACTION_MANAGER und IF_OS_TRANSACTION auf sie zu (siehe auch
Beispiel).Die relevanten Methoden des Systemdiensts
Die meisten Komponenten der Systemdienstklasse CL_OS_SYSTEM werden von den Object Services intern genutzt. Zwei Methoden müssen in einem Anwendungsprogramm verwendet werden, um explizit mit objektorientierten Transaktionen arbeiten zu können.
INIT_AND_SET_MODES
Diese statische Methode initialisiert die gesamten Object Services und erzeugt die notwendigen Serviceobjekte. INIT_AND_SET_MODES wird höchstens einmal pro ABAP-Programm ausgeführt. Jeder weitere Aufruf führt zu einer Ausnahme.
Im Zusammenhang mit dem Transaktionsdienst wird INIT_AND_SET_MODES verwendet, um den
Transaktionsmodus der Top-Level-Transaktion zu setzen. Hierfür müssen dem Eingabeparameter I_EXTERNAL_COMMIT entweder die Konstanten OSCON_TRUE oder OSCON_FALSE aus der Typgruppe OSCON übergeben werden. OSCON_TRUE setzt den sogenannten Kompatibilitätsmodus, bei dem COMMIT WORK explizit im Programm angegeben werden muß, während OSCON_FALSE den objektorientierten Transaktionsmodus setzt, bei dem kein explizites COMMIT WORK erlaubt ist. Wenn der Kompatibilitätsmodus gesetzt wird, wird implizit eine TOP-Level-Transaktion angelegt und gestartet, in die alle übrigen Transaktionen des Programms geschachtelt sind.Mit dem weiteren Eingabeparameter I_UPDATE_MODE vom Typ OS_DMODE wird der Verbuchungsmodus gesteuert. Mögliche Eingabeparameter sind: OSCON_DMODE_DEFAULT bzw. OSCON_DMODE_UPDATE_TASK für asynchrone Verbuchung, OSCON_DMODE_DIRECT für direkte Verbuchung, OSCON_DMODE_LOCAL für lokale Verbuchung und OSCON_DMODE_UPDATE_TASK_SYNC für die synchrone Verbuchung. OSCON_DMODE_LOCAL und OSCON_DMODE_UPDATE_TASK_SYNC sind nur im objektorientierten
Transaktionsmodus erlaubt, da sie im Kompatibilitätsmodus durch ABAP-Anweisungen (COMMIT WORK AND WAIT und SET UPDATE TASK LOCAL) gesetzt werden können. Falls die lokale oder die direkte Verbuchung gewählt wird, wird beim Transaktionstart implizit die Anweisung SET UPDATE TASK LOCAL ausgeführt.INIT_AND_SET_MODES wird implizit beim ersten Zugriff auf eine Klasse der Object Services mit Standardwerten (Kompatibilitätsmodus mit asynchronder Verbuchung) ausgeführt. Wenn INIT_AND_SET_MODES explizit ausgeführt werden soll, muß dies vor einem impliziten Aufruf erfolgen, um Wirkung zu haben (der implizite Aufruf findet dann nicht statt).
GET_TRANSACTION_MANAGER
Diese statische Methode liefert im Rückgabeparameter RESULT vom Typ IF_OS_TRANSACTION_MANAGER eine Referenz auf den Transaktionsmanager. Der Transaktionsmanager wird bei der Initialisierung der Object Services erzeugt.
Die Methoden des Transaktionsmanagers
Der Transaktionsmanager verwaltet die objektorientierten Transaktionen des ABAP-Programms und wird über das Interface IF_OS_TRANSACTION_MANAGER bedient.
IF_OS_TRANSACTION_MANAGER~CREATE_TRANSACTION
Erzeugt eine Transaktion und liefert im Rückgabeparameter RESULT vom Typ IF_OS_TRANSACTION eine Referenz auf die Transaktion.
IF_OS_TRANSACTION_MANAGER~GET_CURRENT_TRANSACTION
Liefert im Rückgabeparameter RESULT vom Typ IF_OS_TRANSACTION eine Referenz auf die aktuelle Transaktion.
IF_OS_TRANSACTION_MANAGER~GET_TOP_TRANSACTION
Liefert im Rückgabeparameter RESULT vom Typ IF_OS_TRANSACTION eine Referenz auf die Top-Level-Transaktion.
Die Methoden einer Transaktion
Transaktionen werden über das Interface IF_OS_TRANSACTION bedient.
IF_OS_TRANSACTION~START
Startet die Transaktion. Wenn es noch keine implizite Top-Level-Transaktion gibt, wird sie die Top-Level-Transaktion, ansonsten eine Untertransaktion. Zum Starten muß eine Transaktion den Status OSCON_TSTATUS_NEW haben. Jede Transaktion kann also nur einmal pro Programm gestartet werden. Eine Transaktion, die mit END beendet wurde kann nicht wieder mit START gestartet werden, da das Transaktionsobjekt im Programm invalididiert wird. Es muß eine neue Transaktion erzeugt werden, wofür natürlich die gleiche Referenzvariable wiederverwendet werden kann.
Die Anweisung COMMIT WORK ist zwischen den Methoden START und END verboten.
IF_OS_TRANSACTION~END
Beendet die Transaktion. Die Änderungen an persistenten Objekten werden bis zum COMMIT WORK oder ROLLBACK WORK der Top-Level-Transaktion aufbewahrt. Falls die Transaktion eine Top-Level-Transaktion ist, wird bei END implizit COMMIT WORK ausgelöst, damit die Verbuchung gestartet und die persistenten Objekte werden invalididiert. Beim erneuten Zugriff auf ein persistentes Objekt wird dieses von der Datenbank geladen.
IF_OS_TRANSACTION~UNDO
Beendet die Transaktion. Die in der Transaktion vorgenommenen Änderungen an persistenten Objekten werden rückgängig gemacht, d.h. die Objekte in den Zustand vor dem Eintritt in die Transaktion zurückversetzt. Falls die Transaktion eine objektorientierte Top-Level-Transaktion ist, wird bei UNDO implizit ROLLBACK WORK ausgelöst.
IF_OS_TRANSACTION~END_AND_CHAIN
Beendet die Transaktion und startet sofort eine neue. Falls die Transaktion eine objektorientierte Top-Level-Transaktion ist, werden gänderte persistente Objekte auf die Datenbank geschrieben, aber nicht invalididiert. Der Rückgabeparameter RESULT vom Typ IF_OS_TRANSACTION liefert eine Referenz auf die aktuelle Transaktion.
IF_OS_TRANSACTION~UNDO_AND_CHAIN
Macht in der Transaktion vorgenommene Änderungen an persistenten Objekten rückgängig und startet eine neue Transaktion. Der Rückgabeparameter RESULT vom Typ IF_OS_TRANSACTION liefert eine Referenz auf die aktuelle Transaktion.
IF_OS_TRANSACTION~REGISTER_CHECK_AGENT
Registriert ein Objekt als
Check-Agenten, der von der Transaktion zu Prüfzwecken aufgerufen wird, bevor die Transktion beendet wird. Hierfür wird eine Interfacereferenz auf ein solches Objekt an den Eingabeparameter I_CHECK_AGENT vom Typ IF_OS_CHECK übergeben.IF_OS_TRANSACTION~GET_STATUS
Liefert im Rückgabewert RESULT vom Typ OS_STATUS den Status der Transaktion. Folgende Werte (Konstanten der Typgruppe OSCON) sind möglich:
Die Transaktion wurde noch nicht gestartet. Nur Transaktionen in diesem Status können mit START gestartet werden.
Die Transaktion wurde gestartet und ist aktiv.
Die Transaktion wurde mit IF_OS_TRANSACTION~END beendet und ruft gerade einen Check-Agenten oder wartet auf einen Ereignisbehandler.
Die Transaktion wurde erfolgreich mit IF_OS_TRANSACTION~END beendet.
Die Transaktion wurde mit IF_OS_TRANSACTION~UNDO beendet und die Wiederherstellung der persistenten Objekte in den Anfangszustand war erfolgreich.
Die Transaktion wurde mit IF_OS_TRANSACTION~UNDO beendet aber die Wiederherstellung der persistenten Objekte in den Anfangszustand war nicht erfolgreich.
IF_OS_TRANSACTION~SET_MODE_UNDO_RELEVANT
Kann benutzt werden, um vor dem Start einer Transaktion den UNDO-Mechanismus zu deaktivieren, z.B. aus aus Performancegründen. Dies geschieht durch Übergabe des Wertes OSCON_FALSE an den optionale Eingabeparameter I_UNDO_RELEVANT vom Typ OS_BOOLEAN. Der Standardwert ist OSCON_TRUE. Dadurch entfällt die Notwendigkeit, den Anfangsstatus persistenter Objekte vor einer Änderung aufzubewahren. Im Kompatibilätsmodus ist in der Top-Level-Transaktion der UNDO-Mechanismus deaktiviert. Ansonsten ist der UNDO-Mechanismus, falls er nicht explizit mit dieser Methode deaktiviert wurde, aktiv.
Wird IF_OS_TRANSACTION~UNDO auf einer Transaktion mit deaktiviertem UNDO-Mechanismus aufgerufen, ist der Status der Transaktion OSCON_TSTATUS_FIN_ABORT.
IF_OS_TRANSACTION~SET_MODE_UPDATE
Kann genau einmal für die Top-Level-Transaktion verwendet werden bevor auf persistente Objekte zugegriffen wird, um den Verbuchungsmodus zu setzen. Dies ist eigentlich nur im Kompatibilitätsmodus notwendig, wo der Verbuchungsmodus in der Regel implizit beim ersten Zugriff auf ein persistentes Objekt auf asynchrone Verbuchung gesetzt wird (siehe
Persistente Objekte und COMMIT WORK). Bei objektorientierten Transaktionen ist die Methode nicht notwendig, da der Verbuchungsmodus der Top-Level-Transaktion dann ohnehin explizit mit CL_OS_SYSTEM=>INIT_AND_SET_MODES oder beim Anlegen einer OO-Transaktion in der ABAP Workbench gesetzt wird.Dem Eingabeparameter I_UPDATE_MODE vom Typ OS_DMODE können folgende Werte übergeben werden: OSCON_DMODE_DEFAULT bzw. OSCON_DMODE_UPDATE_TASK für asynchrone Verbuchung, OSCON_DMODE_DIRECT für direkte Verbuchung, OSCON_DMODE_LOCAL für lokale Verbuchung und OSCON_DMODE_UPDATE_TASK_SYNC für die synchrone Verbuchung. OSCON_DMODE_LOCAL und OSCON_DMODE_UPDATE_TASK_SYNC sind nur im objektorientierten
Transaktionsmodus erlaubt, da sie im Kompatibilitätsmodus durch ABAP-Anweisungen (COMMIT WORK AND WAIT und SET UPDATE TASK LOCAL) gesetzt werden können.Falls die lokale oder die direkte Verbuchung gewählt wird, wird beim Transaktionstart implizit die Anweisung SET UPDATE TASK LOCAL ausgeführt.
IF_OS_TRANSACTION~GET_MODES
Liefert die Eigenschaften der aktuellen Transaktion in den Ausgabeparametern: E_UNDO_RELEVANT vom Typ OS_BOOLEAN, E_CHAINED vom Typ OS_BOOLEAN, E_UPDATE_MODE_TYPE vom Typ OS_DMODE und E_EXTERNAL_COMMIT vom Typ OS_BOOLEAN.
Die Ereignisse einer Transaktion
IF_OS_TRANSACTION~SAVE_REQUESTED
Das Ereignis wird beim Beenden einer Top-Level-Transaktion mit END ausgelöst bevor die Klassenagenten der geänderten persistenten Objekte die Änderungen festschreiben. Für Klassenagenten, die implizit Verbuchungsbausteine verwenden, wird das Ereignis ausgelöst, bevor die Verbuchungsbausteine mit CALL FUNCTION IN UPDATE TASK registriert werden. Für Klassenagenten mit selbstprogrammierten Änderungsmethoden gibt das Ereignis den Zeitpunkt an, an dem die Änderungen an persistenten Objekten durchzuführen sind.
IF_OS_TRANSACTION~SAVE_PREPARED
Das Ereignis wird beim Beenden einer Top-Level-Transaktion mit END ausgelöst nachdem die Klassenagenten der geänderten persistenten Objekte die Änderungen festgeschrieben haben. Für Klassenagenten, die implizit Verbuchungsbausteine verwenden, wird das Ereignis ausgelöst, nachdem die Verbuchungsbausteine mit CALL FUNCTION IN UPDATE TASK registriert wurden. Für Klassenagenten mit selbstprogrammierten Änderungsmethoden gibt das Ereignis den Zeitpunkt an, an dem die Änderungen an den Datenbanktabellen in den Objekten durchzuführen sind.
IF_OS_TRANSACTION~FINISHED
Das Ereignis wird am tatsächlichen Ende einer Transaktion ausgelöst, egal ob sie mit END oder UNDO beendet wurde. Ein Ausgabeparameter vom Typ OS_STATUS liefert die Information, wie die Transaktion beendet wurde (siehe obige Methode GET_STATUS).