Transport Retry Options in a BRE Rule

Question

Hi,

does anyone know how you specify the transport retry and retry interval options within a BRE rule for a dynamic send or send/receive port?

Answer 1

Hi,

I have already asked that question myself here: http://social.msdn.microsoft.com/Forums/en-US/biztalkesb/thread/e4b3bf7d-62c7-4085-bda0-1fb936f7ceb6

You can not configure retries with the BRE resolver that comes out of the box with the toolkit. You have to implement your own BRE resolver.

Answer 2

Well,

that is **** and makes the ESB toolkit rather unfit for purpose. One of the reasons people use BizTalk is for its automated retry & secondary transport capabilties. The ESB toolkit effectively forces you to use dynamic rather than static ports (the itinerary designer certainly ignores them), so it should provide this rather basic capability. Like a lot of Microsoft stuff, it is designed in a theorhetical workshop and never tried out in real world scenarios.

Did you write your own resolver to get around this issue? Or do you just assume target systems are always up & running and sends never fail?

I see that some other people have asked a similar question:

http://social.msdn.microsoft.com/Forums/en-US/biztalkesb/thread/23c6b59e-9231-4a6e-ae31-26c90d7eb557 &
http://social.msdn.microsoft.com/Forums/en-US/biztalkesb/thread/b5147bab-a5eb-497a-b9a9-9d5401acd2e9

and got the stock reply: simply build your own resolver!

However I have done some research & I don't think it is as easy as that. See this blog for instance:
http://geekswithblogs.net/BVeldhoen/archive/2009/08/28/my-beef-with-the-esb-toolkit-2.0-resolution-framework.aspx

This implies that there is a fixed set of facts and that "AdapterConfig" is not one of them! I had a look at the CTP2 source code and came to the same conclusion. I think the people who gave the reply that all you need to do is add your own resolver and add a Resolver.AdapterConfig property have never actually tried it out. I don't want to waste my time trying to do this only to find that this property will never get used due to contraints elsewhere!

So, I challenge any of the moderators to prove it can be done.

Answer 3

As a different solution,

does anyone know if I can achieve the same result by building a custom pipeline based on the ESB pipelines, that sets additional context properties such as BTS.Retry and BTS.RetryInterval?

Answer 4

Hi,

I posted here an implementation of a custom BRE resolver that support retries.

Sorry for the two following inconveniences:
    1) the blog is in French;
    2) the code is embedded in the blog entry (I was not able to provide it in an attached ZIP file).

Answer 5

Hi,

many thanks for posting your solution, its a great help - I see how you managed to overcome the hardwired list of resolver facts. Let's hope that the CTP2 version of the code is not too different from the final version.

Answer 6

For reference,

I solved this short coming in the ESB toolkit by writing a custom pipeline component that set BTS.RetryCount & BTS.RetryInterval context options. Then I built custom pipelines (ItinerarySendPassthroughRetry, etc) with this extra component. Now I can specify RetryCount & RetryInterval on the port by configuring the pipeline.

I thought that was easier & safer to do than write a custom resolver.

Answer 7

Indeed, coding a custom retrying BRE resolver is complex when you consider that it is for the benefit of the so basic and important BizTalk automated retry capability.

 

In the next version of the toolkit, let hope that the other resolvers (than UDDI) will allow to specify retries.

 

Until then, in someone care about it, one advantage of custom retrying resolvers is that they allow specifying particular retry count/interval per endpoint whereas using a pipeline component requires different ports when requiring different retry count/interval per endpoint.