An object-oriented transaction is represented by a transaction object that is managed by a transaction
manger (which is also an object). The transaction manager represents the transaction service with respect to the ABAP program.
To create a transaction manager, the static method GET_TRANSACTION_MANAGER of the general system service class CL_OS_SYSTEM is required. The
transaction mode is set with the method INIT_AND_SET_MODES of this class.
An ABAP program does not work with the transaction manager and the transaction by using class reference
variables. Instead the program accesses the transaction manager and the transaction using the interfaces IF_OS_TRANSACTION_MANAGER and IF_OS_TRANSACTION.
Most of the components of the system service class CL_OS_SYSTEM are used
internally by the Object Services. Two methods must be used in an application program to be able to work explicitly with object-oriented transactions.
INIT_AND_SET_MODES
This static method initializes the entire Object Services and creates the necessary service objects. INIT_AND_SET_MODES is executed no more than once for each ABAP program. Every additional call causes an exception.
INIT_AND_SET_MODES is used together with the transaction service to set the
transaction mode of the top level transaction.
The constant OSCON_TRUE or OSCON_FALSE of type group OSCON must be passed to input parameter I_EXTERNAL_COMMIT.
OSCON_TRUE sets the compatibility mode for which COMMIT WORK must be defined
explicitly in the program, whereas OSCON_FALSE sets object-oriented transaction mode, for which an explicit
COMMIT WORK is not allowed. Once the compatibility mode has been set, a top
level transaction is implicitly created and started. All other transactions of the program are nested in this transaction.
Update mode is controlled with the other input parameter I_UPDATE_MODE of type OS_DMODE. Possible input
parameters are: OSCON_DMODE_DEFAULT or OSCON_DMODE_UPDATE_TASK for asynchronous updates, OSCON_DMODE_UPDATE_TASK_SYNC
for synchronous updates, OSCON_DMODE_LOCAL for local updates, and OSCON_DMODE_DIRECT for direct saves
when using COMMIT WORK. The constants OSCON_DMODE_LOCAL andOSCON_DMODE_UPDATE_TASK_SYNC
cannot be specified in compatibility mode. If local or direct updates are chosen, the statement SET UPDATE TASK LOCAL is executed implicitly when the transaction is started.
INIT_AND_SET_MODES is executed implicitly the first time an Object Services class is accessed with the
default compatibility mode and asynchronous updates. If INIT_AND_SET_MODES is to be executed explicitly, this must be done before an implicit call for it to take effect (the implicit call does not take place).
GET_TRANSACTION_MANAGER
This static method returns the return value RESULT (of type IF_OS_QUERY_MANAGER) that contains a reference to the transaction manager. The transaction manager is created when Object Services are initialized.
Methods of the Transaction Manager
The transaction manager manages the object-oriented transactions of the ABAP program and is executed using the interface IF_OS_TRANSACTION_MANAGER.
IF_OS_TRANSACTION_MANAGER~CREATE_TRANSACTION
Creates a transaction and returns a reference to the transaction in return value RESULT of type IF_OS_TRANSACTION.
IF_OS_TRANSACTION_MANAGER~GET_CURRENT_TRANSACTION
Returns a reference to the current transaction in return value RESULT of type IF_OS_TRANSACTION.
IF_OS_TRANSACTION_MANAGER~GET_TOP_TRANSACTION
Returns a reference to the top level transaction in return value RESULT of type IF_OS_TRANSACTION.
Methods of a Transaction
Transactions are controlled using interface IF_OS_TRANSACTION.
IF_OS_TRANSACTION~START
Starts the transaction. If a top level transaction does not yet exist, it becomes the top level transaction.
Otherwise it becomes a subtransaction. A transaction must have status OSCON_TSTATUS_NEW so that it can
be started. Each transaction thus can only be started once per program. A transaction cannot be started
again using START if it was ended with END, since this would invalidate the transaction object in the program. A new transaction must be created, but the same reference variable can be used again.
The COMMIT WORK statement is not allowed between the START and END methods.
IF_OS_TRANSACTION~END
Ends the transaction. Changes to persistent objects are stored until the COMMIT
WORK or ROLLBACK WORK of the top level transaction. If the transaction
is a top level transaction, COMMIT WORK is implicitly triggered upon encountering an END. This starts
the updater and invalidates the persistent objects. If a persistent object is accessed again, it is loaded from the database.
IF_OS_TRANSACTION~UNDO
Ends the transaction. The changes made to persistent objects in the transaction are canceled and the
objects are returned to the state they had prior to the transaction. If the transaction is an object-oriented
top level transaction, ROLLBACK WORK is triggered implicitly when an UNDO is performed.
IF_OS_TRANSACTION~END_AND_CHAIN
Ends the transaction and immediately starts a new one. If the transaction is an object-oriented top
level transaction, changed persistent objects are written to the database but are not invalidated. Returns a reference to the current transaction in return value RESULT of type IF_OS_TRANSACTION.
IF_OS_TRANSACTION~UNDO_AND_CHAIN
Cancels the changes made to persistent objects in the transaction and starts a new transaction. Returns a reference to the current transaction in return value RESULT of type IF_OS_TRANSACTION.
IF_OS_TRANSACTION~REGISTER_CHECK_AGENT
Registers an object as a checking agent, which is called by the transaction for checking purposes before
the transaction ends. An interface reference to this type of object is passed to the input parameter I_CHECK_AGENT of type IF_OS_CHECK.
IF_OS_TRANSACTION~GET_STATUS
Returns the transaction status in the RESULT return value of type OS_STATUS. The following values (constants of type group OSCON) are possible:
OSCON_TSTATUS_NEW The transaction has not been started. Transactions in this status can only be started using START.
OSCON_TSTATUS_RUNNING The transaction has been started and is active.
OSCON_TSTATUS_END_REQ The transaction ended with IF_OS_TRANSACTION~END and is just starting a checking agent or is waiting for an event handler.
OSCON_TSTATUS_FIN_SUCCESS The transaction was success. It ended with IF_OS_TRANSACTION~END.
OSCON_TSTATUS_FIN_UNDO The transaction ended with IF_OS_TRANSACTION~UNDO and the persistent objects were returned to their initial state.
OSCON_TSTATUS_FIN_ABORT The transaction was ended with IF_OS_TRANSACTION~UNDO but the persistent objects were not returned to their initial state.
IF_OS_TRANSACTION~SET_MODE_UNDO_RELEVANT
Can be used to deactivate the UNDO mechanism before a transaction is started, for example, to improve
performance. This is done by transferring the value OSCON_FALSE to the optional input parameter I_UNDO_RELEVANT
of the type OS_BOOLEAN. The default value is OSCON_TRUE. This removes the need to save the initial status
of persistent objects before a change. In compatibility mode, the UNDO mechanism is deactivated in the
top level transaction. Otherwise the UNDO mechanism is active, unless it was explicitly deactivated
using this method. If IF_OS_TRANSACTION~UNDO is called in a transaction with a deactivated UNDO mechanism, the status of the transaction is OSCON_TSTATUS_FIN_ABORT.
IF_OS_TRANSACTION~SET_MODE_UPDATE
Can be used exactly once for the top level transaction before persistent objects are accessed in order
to set the update mode. This is only necessary in compatibility mode, where the update mode is normally
set implicitly the first time a persistent object is accessed using asynchronous updates. This method
is not necessary for object-oriented transactions. This is because the update mode of the top level
transaction is set explicitly with CL_OS_SYSTEM=>INIT_AND_SET_MODES or when an OO transaction is created in the ABAP Workbench.
The following values can be passed to the input parameter I_UPDATE_MODE of type OS_DMODE: OSCON_DMODE_DEFAULT
or OSCON_DMODE_UPDATE_TASK for asynchronous updates, OSCON_DMODE_UPDATE_TASK_SYNC for synchronous updates,
OSCON_DMODE_LOCAL for local updates, and OSCON_DMODE_DIRECT for direct saves. OSCON_DMODE_LOCAL and OSCON_DMODE_UPDATE_TASK_SYNC are allowed only in the object-oriented transaction mode.
If local or direct updates are chosen, the statement SET UPDATE TASK LOCAL is executed implicitly when the transaction is started.
IF_OS_TRANSACTION~GET_MODES
Provides the attributes of the current transaction in the output parameters: E_UNDO_RELEVANT of type OS_BOOLEAN, E_CHAINED of type OS_BOOLEAN, E_UPDATE_MODE_TYPE of type OS_DMODE and E_EXTERNAL_COMMIT of type OS_BOOLEAN.
Events of a Transaction
IF_OS_TRANSACTION~SAVE_REQUESTED
The event is triggered when a top level transaction is ended with END before the class agents of the
changed persistent objects record the changes. For class agents that implicitly use update modules,
the event is triggered before the update modules are registered using CALL FUNCTION
IN UPDATE TASK. The event defines the time when the changes to persistent objects should be recorded for class agents with self-programmed change methods.
IF_OS_TRANSACTION~SAVE_PREPARED
The event is triggered when a top level transaction ends with END after the class agents of the changed
persistent objects have recorded the changes. For class agents that implicitly use update modules, the
event is triggered after the update modules are registered using CALL FUNCTION IN
UPDATE TASK. The event defines the time when the changes to database tables in the objects should be recorded for class agents with self-programmed change methods.
IF_OS_TRANSACTION~FINISHED
The event is triggered at the actual end of a transaction, regardless of whether it was ended with END or UNDO. An output parameter of type OS_STATUS indicates how the transaction was ended.
This translation does not reflect the current version of the documentation.