In this article, I should explain how to handle exception in Long Running Process and Atomic Process. BizTalk Server supports two distinct types of transactions: Atomic and Long-running.
You can set an orchestration with the transaction type at the orchestration level or, if you need a finer level of granularity for configuring transaction behavior, you can define a scope to wrap a unit of work within a transaction boundary.
Atomic transactions:
This enables a transaction to automatically role back to a previous state in case the transaction does not successfully complete.
Supports ACID, in BizTalk, you can design orchestrations to support ACID transactions by configuring the scope (or the entire orchestration itself) as atomic. Any variables, messages, etc., within an atomic scope are isolated within the transaction and changes to their state are not visible until after the transaction commits. Atomic transactions are married with the appropriate isolation level. Choices include serializable (object-level locking), read committed (only committed data is readable) and repeatable read (row-level locking occurs to prevent “dirty” reads).
Long-running Transactions:
Can span days, weeks, and longer time durations, contain nested transactions, and use custom exception handling to recover from error scenarios. Supports Consistency and Durability
Nesting of Transactions:
Log expression writes an entry to event logs.
I have a simple helper method to generate random errors, which is invoked in expression shape on Left and Right scopes; here is the snap shot of helper class. Deploy and test the solution.
Event Logs of the process,
Conclusion
In this article, I covered exception handling for Atomic and LRT transaction with the help of compensation block. Now you can apply this solution to your own business scenario.
The video demonstration is available on the Youtube, here is the embedded video.
You can set an orchestration with the transaction type at the orchestration level or, if you need a finer level of granularity for configuring transaction behavior, you can define a scope to wrap a unit of work within a transaction boundary.
Atomic transactions:
This enables a transaction to automatically role back to a previous state in case the transaction does not successfully complete.
Supports ACID, in BizTalk, you can design orchestrations to support ACID transactions by configuring the scope (or the entire orchestration itself) as atomic. Any variables, messages, etc., within an atomic scope are isolated within the transaction and changes to their state are not visible until after the transaction commits. Atomic transactions are married with the appropriate isolation level. Choices include serializable (object-level locking), read committed (only committed data is readable) and repeatable read (row-level locking occurs to prevent “dirty” reads).
Long-running Transactions:
Can span days, weeks, and longer time durations, contain nested transactions, and use custom exception handling to recover from error scenarios. Supports Consistency and Durability
Nesting of Transactions:
- Long Running Transaction (LRT) supports nesting of transactions (Atomic or LRT), whereas Atomic doesn’t support nesting.
- Atomic scope support compensate block only but LRT supports both exception and compensate blocks.
Log expression writes an entry to event logs.
I have a simple helper method to generate random errors, which is invoked in expression shape on Left and Right scopes; here is the snap shot of helper class. Deploy and test the solution.
Event Logs of the process,
Conclusion
In this article, I covered exception handling for Atomic and LRT transaction with the help of compensation block. Now you can apply this solution to your own business scenario.
The video demonstration is available on the Youtube, here is the embedded video.
No comments:
Post a Comment
Note: only a member of this blog may post a comment.