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

If you are using dynamic ports inside an orchestration, you have to configure 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”.

Delivery Notification Send Logical Port
Delivery Notification Send Logical Port

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 database or somewhere that 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 to kick 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 sent 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

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community.

2 thoughts on “BizTalk Dynamic Send Port – How to implement retries, delivery notification and backup transport”

  1. 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. 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

Your email address will not be published. Required fields are marked *

BizTalk360
BizTalk Server

Over 500+ customers across
30+ countries depend on BizTalk360

Learn More
Serverless360
Azure

Manage and monitor serverless
components effortlessly

Learn More
Atomicscope
Business Users

Monitor your Business Activity in iPaaS
or Hybrid integration solutions

Learn More

Back to Top