Normally in a day today life the Business Rules in BizTalk might fail because of the Exception raised by SQL Connection Unavailable or a Permissioning Issue or Rules might have not deployed properly. In these scenarios the messages are terminated generally. Instead of terminating the messages, the messages can be resumed after handling the exception raised by the Business Rules Engine (BRE). This article will deal with this in detail.
The Rules can be retried with the help of the default mechanism provided by BizTalk instead of working with a custom logic. In order to work with such a mechanism, the rules need to be called from an Atomic shape with the property ‘Retry = True’.
We are all aware that an Atomic Scope cannot have an exception handling, in order to capture the exception, we need to have a Scope with the ‘Transaction Property =None’. The Outer Scope will be an Atomic Scope and there will be a inner Scope (Transaction type - None) from where the rules will be called. We can add an Exception Handling block to the existing ‘None Scope’, where the exception object of type ‘Microsoft.RuleEngine.RuleEngineException’ should be used to capture the Exception.
After once we track the exception, we can work with the default retry logic, by throwing the exception with the help of the “Throw Exception Shape”. While Throwing the Exception we need to throw it as a “RetryTransactionException'” which can be inherited from the XLANG base class of type ‘Microsoft.XLANGs.BaseTypes.RetryTransactionException'.
Limitation: -
When the ‘Retry Exception’ is raised then BizTalk continuously retries for 21 times, and after retrying for 21 times then it suspends the message. The count 21 cannot be reduced but where as the retry interval can be programmatically controlled.
Programmatically Controlling the Retry interval: -
Just before the ‘Throw Exception’ Shape in the Catch Block, the retry interval can be specified with the help of the Expression Editor.
E.g: -
//Create a retry exception, and set the Delayfor to 1 sec.
retryException = new Microsoft.XLANGs.BaseTypes.RetryTransactionException();
retryException.DelayFor = new System.TimeSpan(0,0,1);
Note
Here in this sample we are specifically working with the Rule Engine Exception (we can even work with the “General Exception” as well), and then rethrows a RetryTransactionException whose DelayFor property is one second.
An atomic transaction retries when the user deliberately throws a RetryTransactionException at the time that the atomic transaction tries to commit. If this happens for an atomic scope that has Retry=True, then it will retry up to 21 times. The delay between each retry is two seconds by default. The sample orchestration overrides the default value and specifies a one-second delay by using the DelayFor property. After 21 retries, if the transaction is still unable to commit, the whole orchestration instance is suspended. It can be manually resumed, in which case it starts over again, with a fresh counter, from the beginning of the offending atomic scope.
The Same logic can be used to retry Rules with both BizTalk 2004 and 2006
