Comments
SAP OS TRANSACTION COMPS documentation, setup help and example usage
ARTICLE
Components of the Transaction Service
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 .
Relevant Methods of the System Service
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.
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 and
OSCON_DMODE_UPDATE_TASK_SYNC cannot be specified in compatibility mode. If local or direct updates are chosen, the statement
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).
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 .
Creates a transaction and returns a reference to the transaction in return value RESULT of type IF_OS_TRANSACTION .
Returns a reference to the current transaction in return value
RESULT of type IF_OS_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 .
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
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.
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,
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.
Ends the transaction and immediately starts a new one. If the transaction is an object-oriented top level transaction, changed persi
stent 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 .
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 .
Registers an object as a checking agent, which is called by the transaction for checking purposes before the transaction ends. An in
terface reference to this type of object is passed to the input parameter I_CHECK_AGENT of type IF_OS_CHECK .
Returns the transaction status in the RESULT return value of type
OS_STATUS . The following values (constants of type group
OSCON ) are possible:
The transaction has not been started. Transactions in this status can only be started using START .
The transaction has been started and is active.
The transaction ended with IF_OS_TRANSACTION~END and is just starting a checking agent or is waiting for an event handler.
The transaction was success. It ended with IF_OS_TRANSACTION~END .
The transaction ended with IF_OS_TRANSACTION~UNDO and the persistent objects were returned to their initial state.
The transaction was ended with IF_OS_TRANSACTION~UNDO but the persistent objects were not returned to their initial state.
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 .
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
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
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.
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.
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.
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved
