Share via

Understanding Resume Pattern In BizTalk

  • Article

So what if you are placed against a scenario to design a process which does multiple service calls and if one of the service return a fault with message " ______field is not available at the moment but it will be after 2 hours” (May be because it is trying to look up some value from the database which is not yet created but soon will be created) you should be able to retry.

Note: This implementation is useful when you are making multiple synchronous service call, for example in an orchestration.If that is not the case you are better off having the retry done from the send port.

We achieve this by wrapping our send receive port within a scope which will suspend in event of exception. I am trying to demo this here.

  • Create an orchestration which will look something like this. I will breakdown each component's explanation further. 

http://psrathoud.files.wordpress.com/2014/01/orchestrationwhole_1.png?w=288

We have used two nested scopes having the "Long Running" transaction type, this is important since the atomic transaction is designed to just complete and cannot be resumed.

  • Use a loop shape and put your inner transaction scope within. Also define a variable which will govern if the loop should be executed or not. 

http://psrathoud.files.wordpress.com/2014/01/orchscopes_2.png?w=300

  • Within the scope_suspend (That what I have named it, you can discard if you don't like it ;-)) add an exception block. Also add the message construct shape to create your service request and have your send receive shape to service within as shown in the picture. In the exception block add the suspend shape. The variable which is governing execution of the loop has to set appropriately within exception block and outside exception block just after your service response receive shape.  your solution is ready. 

http://psrathoud.files.wordpress.com/2014/01/orchscopesinner_3.png?w=300

How It Works: When the orchestration makes the service call and there is a valid response returned from it goes to the 1st expression shape where we reset the flag for looping to insure it exits  the loop. When the orchestration makes the service call and bumps into fault instead of a valid response it hits the "scope_suspend" catch exception block. There it sets the looping flag to true and goes to suspended resumable mode courtesy our next suspend shape. At this point the state of your orchestration is persisted. So when you resume it the next time it basically restart the inner scope and check the loop flag which directs it to make the service call again. That completes the demo. Please note that Biztalk send port retires 3 times by default in case of failure. You may want to change this setting to 0 retries in case your service method is doing any add update or delete. Also you will see two suspended instances in admin console, one the orchestration which is resumable and other is the send port which upon resume will cause no effect to the orchestration. The suspended send port thou doesn't brings any harm to your BT server but it may pile up in time and may cause performance issues. So you may want to enable failed message routing to take care of this. I will cover this topic later in a separate blog. Please leave a comment if you need the source code or need any help implementing this.