Yesterday we had some problems with a connection to an endpoint and it became clear the endpoint was less reliable as promised.
When using a static sendport you would set RetryCount and RetryInterval for that port. But in this case it was a Dynamic send port.
Fortunately we had a PipelineComponent that could add context properties in the send port on the fly.
So I added the properties BTS.RetryCount and BTS.RetryInterval. I messed with some adapter properties so every send would fail. Then I dropped in a Test message and for sure the retry was happening.
But to my horror, the retry never ended !. It just kept retrying. Then I removed the properties in the send pipeline and put the properties on the message in the orchestration. And now the behavior was completely as expected.
After some thinking I drew the following conclusion.
If those properties are set in the pipeline the following will happen:
- The orchestration will send the message
- Message hits the Messagebox without retry propeties
- BizTalk Hands the message over to the send port / adapter (without the properties)
- Send port gets the message and will add the properties.
- Adapter gets the message and sees the retrycount
- Adapter will send and fail
- Adapter will honor the retry and not fail the message instead it will give a transmission failure
- Transmission failure will not elevate to a failed send because the retrycount is not exhausted
- Original message stays in the messagebox (without the retry properties)
- BizTalk will start again from step 3
This is different from the scenario when the properties are set in the orchestration
- The orchestration will send the message with the properties
- Message hits the Messagebox with retry propeties
- BizTalk Hands the message over to the send port / adapter
- Send port gets the message and pushes it to the adapter
- Adapter gets the message and sees the retrycount
- Adapter will send and fail
- Adapter will honor the retry and not fail the message instead it will give a transmission failure
- BizTalk will now recognize the Transmission failure and will increase the retrycount on the message in the mesagebox
- BizTalk will start again from step 3 now honoring the retrycount.
- If retrycount is exhausted it wil eventually fail.
This is observed behavior in BizTalk 2013.
Key takeaway:
You cannot add the bts.RetryCount and bts.RetryInterval properties for a dynamic send in the send port itself they must be set in the orchestration.