Database Transactions

If one of the below listed steps is contained in an integration flow, the processing of the message is executed in one transaction.

●Data Store Operations step

1. Select (in case delete=true)
2. Write
3. Get (in case delete=true)
4. Delete

●Usage of Write variables

●Aggregator step

●Content Enricher

In case of an error, the whole process is rolled back and the original state is being re-established. That means, data from failed processes remain and, in case message processing fails, customers normally cannot access data about the failed processing (due to the roll-back).

In case an error is propagated back to the calling component, all data that have been written in the course of the (failed) transaction are being removed (in other words: not persisted in the database). For the calling component, an error implies, therefore, to restart the integration flow.

Transactional processing is also to be considered in scenarios that contain asynchronous decoupling.

 Let’s assume integration flow A contains a Data Store Operation step. Integration flow B contains a Select operation on the Data Store and runs into an error. 

In that case, that data is preserved that has been written to the database by integration flow A. 

This behavior makes sense in particular when you consider the case that integration flow B changes or deletes the data that has been stored by integration flow A. In case integration flow B fails, the original data from integration flow A can be retrieved.