Resume from the Point of Failure - BizTalk 2004

Of late, we were working on providing adequate Error Handling capabilities to our BizTalk 2004 orchestrations. One of the main requirements, we wanted, was to have an orchestration handle its own exceptions with the opportunity of resuming from the actual point of failure.

This needed some interesting logic which is explained below. In case of most orchestrations which involve Rules (say) or any external assemblies - called in functoids in maps or directly in the Orchestration; this kind of an approach is most applicable.

We would need to use a Retry Pattern implementation into the orchestration, especially at the place where we have the Call Rules shape.

Now the Call Rules shape is in an Atomic Scope (Rules_Scope). Create a New loop (OnError_Loop). This loop will enclose a new Long-Running Scope - (ProcessOnError_Scope). Add a new Exception Handler (Catch_RulesException) to the ProcessOnError_Scope.

Inside the ProcessOnError_Scope, place your actual Atomic Scope which has the Call Rules shape.

Now the next step is to initialise the variables for the Retry Logic. You need to have two variables - vRetryCount (Integer) and vDone(Boolean).

vRetryCount = 5;

vDone = false;

In the loop OnError_Loop settings, add this:

vRetryCount > 0 && !vDone

After the (Rules_Scope), add a Expression Shape which has the vDone variable set to true.

In the Catch_RulesException handler, add a Suspend Shape and provide an adequate error message. Below the Suspend Shape, add an Expression Shape, where you are decrementing the vRetryCount. Now you need to set the exception handler to catch exceptions of the type:

Microsoft.RuleEngine.RuleEngineException as the ExceptionObjectType.

You are all set to implement your error handling now.

Business Scenario:

If a message is being processed by an orchestration instance, then when it hits the Call Rules shape, and the rules is not deployed or the rules engine update service is stopped, a system exception of type Microsoft.RuleEngine.RuleEngineException is generated. This exception is handled by the Catch_RulesException handler, and is suspended. On manual intervention, the orchestration instance is resumed and it hits the OnError_Loop and resumes again from the start of the CallRules shape, calls the Rule successfully, ( as it has been deployed correctly by the support individual) and then exits the loop as the vDone variable is set to true and proceeds with the next step in the orchestration.

As business rules are bound to be changed quite frequently, such an error handling practice would help in ensuring that the orchestration is smart enough to handle any system exceptions which take place.

====

Also I have done some work on Orchestrations to provide a check on how many rules got triggered. So if you have a business check of "I want all rules to be fired" - it can be done quite effectively.

Lots of stuff to share.

====

Satish Viswanathan.