Transactional Behavior of an Integration Process  

Use

You can now influence transactional behavior in the definition of an integration process in the process editor.  This enables you to improve performance.

Transaction

A transaction is a sequence of processing steps that are either fully executed, or not executed at all. If the system cannot fully execute a transaction, it rolls back all processing steps within the transaction. This means that the system can return to the state before the transaction was begun.

The transaction control mechanism for integration processes is not a central transaction manager for an entire system landscape. The transaction control mechanism cannot roll back any processing steps outside the Integration Server.

Transaction Boundaries

You have the option of defining the start or end of a block as the boundary of a transaction.

●      In the case of the start of a block, you can define that the system is to start a new transaction.

●      In the case of the end of a block, you can define that the system is to end the transaction being started (COMMIT WORK). The system ends the transaction that is currently open, regardless of whether it has been started or not. For example, if no new transaction was started at the start of the block, the last transaction started is continued instead.

By making appropriate settings for the start and end of a block you can expand transactions. This means that the database needs to be accessed less often, and enables you to improve system performance.

Transactional Behavior for Specific Step Types

At runtime, the system normally creates a separate transaction for each step. The transaction then covers this step only. However, you can influence the transactional behavior of particular step types. In the step properties, you can define that the system is not to start a new transaction when the step is executed. The system then executes the step in the transaction that was started at the time of execution. Consequently, no background work item is created for the step and the database does not need to be accessed. In this way you can improve system performance.

You can influence the transactional behavior of the following step types:

●      Send step

You can influence the transactional behavior when sending messages both synchronously and asynchronously, and when sending acknowledgments.

More information:

Sending Messages from Integration Processes Asynchronously

Sending Messages from Integration Processes Synchronously

Sending Acknowledgements from Integration Processes

●      Transformation Step

More information: Bundling, Splitting, and Transforming Messages

●      Receiver Determination Step

More information: Receiver Determination Step

Optimizing Transactional Behavior

Note the following points when defining the transactional behavior:

●      Memory requirements

Expanding transactions and executing specific steps without creating a new transaction may increase the burden on the main memory. If the burden on the main memory is too great, you must redefine transactions, or define that a new transaction is to be created for the step concerned.

●      Troubleshooting in the workflow log

The technical view of the workflow log does not show any detailed information for steps for which no work item was created. If an error occurs, the workflow log displays the error information for the last executed step. The following example illustrates this:

A process contains a transformation step that is executed within an expanded transaction. When the transformation step is executed, an error occurs in mapping and the system rolls back the transaction. Since no work item was created for the transformation step, the workflow log does not have an entry for the transformation step. The error information is entered in the last executed step in the workflow log.