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”.
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
Thanks this was really useful. I was wondering why I couldn’t Catch the exception in my orchestration. RetryCount set to 0 did it.
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).
Hi,
I’am using Biztalk Server 2016 version. I tried DeliveryNotificatin is ‘Transmitted’ and message RetryCount = 3 on Dynamic Send Port. It works well. When process gets an error, retry itself. Error return to my Orchestration when the retry count limit is over. You said that this process cannot be done because Delivery Notification works only when the Retry Count set to 0. What problems does my operation produce?