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.