BizTalk Server Video Tutorials for Beginners

Understand the Basic concepts in BizTalk, here is the video playlist to my channel.

Atomic and Long-running Transaction | BizTalk | Exception Handling

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:

• 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.

Here is simple LRT process which receives a message and does a parallel process on a copy of received message inside a LRT scopes as shown. Both Left and Right scope have compensation block and these are wrapped inside as Main LRT scope that logs the error and invokes compensate block for Left and Right. 

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.

Exception Handling with None Transaction Scope | BizTalk

Exception Handling/Transaction Scope
When creating BizTalk orchestrations, we also have some building blocks available to do exception handling. Here I'll try to give a very brief explanation of the available building blocks for your orchestration. Handling exceptions inside orchestration is the equivalent of doing a “catch { }” block in C#, of course there are some little differences, but the idea is the same.

General Exception Type
When we create New Exception Handler, in property “Exception Object Type combo, the only item in the list is ‘General Exception’:
Think of catching a “Generic Exception” as the equivalent of doing a “catch { }” block in C# with no exception declared. “General Exception” allows BizTalk to deal with any exception it may catch and re-throw, there’s no wayto get the exception message at that point.

Here is simple process which receives a message and performs some operation and calls a rule to enrich the message.

Add a scope and place the business logic inside the scope and set the transaction type as None. Now, Select the Scope then right click and exception block as shown

Inside the Catch Block, place a decide shape and in configure rule invoke a simple method which investigates the exception object and returns a Boolean flag to indicate whether resumable or non resumable exceptions.If resumable, then process would throw the exception again and this can be resumed from Admin Console. In case of non-resumable error, our process would archive and terminate the instance.

Deploy and test the solution.

Here is the helper method which parse and verify the exception object for resumable/ Non-resumable exceptions.

Scenario 1
Let us say, we forgot to deployed BRE which is used by the process this would cause an exception and would
be caught in catch block, if we had implement a normal exception handling, process would be terminated and
actually we may require to re-process the message. But with the customization of exception handling, we suspend the process by throwing the exception and once the rule is deployed you can resume the suspended instances from Admin Console.

How this work, this design is developed based on the persistent point caused by BizTalk. Hence by rethrowing the exception we save the last persistent point caused in BizTalk, thus we can resume these instances.
Scenario 2
Let us say, some runtime exception happens and this would be caught by the exception block. The exception object would be parsed to verify if this can be resumed and in case if this isn’t configured as part of resumable exception, our process would archive and terminate the process.

Conclusion
In this article, I covered how to handle exceptions with Scope with Transaction Type as None, now you can apply this solution to your own business scenario. This resumable feature would work only when the orchestration transaction is set as None. Transaction Type Long Running and Atomic doesn't support resumble instances of a process.

The video demonstration is available on the Youtube, here is the embedded video.