BizTalk Dynamic Send Port – How to implement retries, delivery notification and backup transport

Posted: April 30, 2009 in BizTalk
Tags: ,

If you are using dynamic ports inside orchestration, you have to configuring BTS.RetryCount and BTS.RetryInterval properties on the message you want to send to implement retry mechanism:

myMessage(BTS.RetryCount) = 5;
myMessage(BTS.RetryInterval) = 5; //(in minutes)

You also have to ensure that the property Delivery Notification is not set to “Transmitted”.

You might also consider setting up a backup transport in case after the retry count the message has still not gone through. You could for instance then deliver the message to a file drop location, or a db or something so you have ultimate control.

Note: If you need backup transport you will have to implement it in your process, you have to enable Routing on the send port which will allow you tokick off another process if the send port was unable to deliver the message.

Delivery Notification = “Transmitted”

If this property is set to Transmitted it means that your orchestration will receive an exception if the message cannot be send to the destination.

The Delivery Notification flag on the Send Port indicates that the orchestration must be NOTIFIED back, in case the message has not been received by the destination. Delivery Notification works only when the Retry Count set to 0. When a message cannot be delivered, a DeliveryNotificationException is raised and the exception needs to be handled by the Orchestration.

Note: inside Exception handler (DeliveryNotificationException) you can implement your backup transport

Tags: BizTalk | Dynamic Send Port

Comments
  1. Anonymous says:

    Thanks this was really useful. I was wondering why I couldn’t Catch the exception in my orchestration. RetryCount set to 0 did it.

  2. Dag says:

    I suspect you are mistaken. It makes perfect sense that the delivery notification should work regardless of the number of retries, but that all retries should execute before the exception is raised in the orchestration. For example, if you are attempting to deliver to a remote web service and network connectivity isn’t 100% reliable, it makes a lot of sense to simply try again 5 minutes later and, if things go well, continue exactly as you would have if the first attempt had gone well. But it does not make sense to just keep trying indefinitely, and it is therefore meaningful to combine retry > 0 with delivery notification.

    My bet is that you simply never noticed the exception because you didn’t wait until all retries had been performed. If you’re waiting 5 minutes and have 3 retries, that is 4 attempts in total and I’d expect the exception to occur just over 20 minutes after the first attempt (provided each attempt fails fast).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s