Quantcast
Channel: Patrick Wellink
Viewing all articles
Browse latest Browse all 11

BizTalk just keeps retrying and never stops doing so

$
0
0

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:

  1. The orchestration will send the message
  2. Message hits the Messagebox  without retry propeties
  3. BizTalk Hands the message over to the send port / adapter (without the properties)
  4. Send port gets the message and will add the properties.
  5. Adapter gets the message and sees the retrycount
  6. Adapter will send and fail
  7. Adapter will honor the retry and not fail the message instead it will give a transmission failure
  8. Transmission failure will not elevate to a failed send because the retrycount is not exhausted
  9.  Original message stays in the messagebox (without the retry properties)
  10. BizTalk will start again from step 3

This is different from the scenario when the properties are set in the orchestration

  1. The orchestration will send the message with the properties
  2. Message hits the Messagebox  with retry propeties
  3. BizTalk Hands the message over to the send port / adapter
  4. Send port gets the message and pushes it to the adapter
  5. Adapter gets the message and sees the retrycount
  6. Adapter will send and fail
  7. Adapter will honor the retry and not fail the message instead it will give a transmission failure
  8. BizTalk will now recognize the Transmission failure and will increase the retrycount on the message in the mesagebox
  9. BizTalk will start again from step 3 now honoring the retrycount.
  10. 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.

 


Viewing all articles
Browse latest Browse all 11




Latest Images