In the example provided, when using a Local_Transaction connection in Integration Server (IS) without using built-in services, if adapter3 fails, the flow will exit the try block and the error will be caught in the catch block. At this point, Integration Server will initiate a rollback process to undo all the previous insert operations.
To clarify the sentence you asked to correct, here is a revised version:
“How does Integration Server (IS) become aware of the need to perform a rollback in this scenario?”
Looks like this one is using explicit transaction handling.
Even if there were updates to the DB or not, when there is an error detected while updating the DB (indicated by the db adapter service failing, the try block exits (“on Failure”) to avoid further updates and goes to the catch block (exit “on Done”) to proivde the error message for further processing and rolling back the transaction holding the previous updates to avoid data discrepancy due to incomplete processing.
Please find the Example of Service . All are InsertAdapter are using local transaction if Adapter3 got Fail… then flow will come to Catch Block. No Insert Operation will do commit
My Question is
How does Integration Server (IS) become aware of the need to perform a rollback in this scenario?
as there is no explicit TransactionHandling implemented here, this is handled internally by the ART and the database itself.
This will only work when all adapters are using the same ConnectionPool from the Adapter as only one local transaction is allowed in one service instance running.
IS itself does not need to know that a rollback is needed.
The Transaction knows what Adapter1 and Adapter2 wanted to update and when Adapter3 fails, the transaction will be marked as faulty and will be rolled back by the database driver autmatically.
If you want more control over this you can use Built-In-Services from the ART:
Please the startTransaction command before the first sequence, commitTransaction at the end of the second sequence (behind the last adapter service participating in this transaction) and the rollbackTransition at the end of the third sequence (behind getLastError).
Map the transaction identifier from output of startTransaction to the corresponding input field of commitTransaction and rollbackTransaction.
See IS Built-In-Services Reference for further informations on the public services of the WmART package.
Whenever a transaction management is being performed, it shares a common transaction name for all operations that are being performed in a single management using start, commit & rollback.
Yes, in this scenario a temporary transaction name is being used to perform the management operation. that’s why IS rollback all the started transactions with same transaction name.
To trigger an automatic rollback, you must throw an error within the catch block. This will notify the IS about the failure, prompting the automatic rollback process.
