Yossi Dahan [BizTalk]

Google
 

Friday, December 18, 2009

This should not be a routing failure!

Important update: it looks like it’s not after all! and I’ve posted the details here; I suggest you check it out after reading this post.

Some routing failures are straight forward – you have a message, it has context, and no one subscribes to it. Routing Failure Report notifications are very useful on helping troubleshooting these – and most likely someone has mistyped a property’s value, a subscription value or forgot to ensure that the relevant properties are promoted and that relevant services are enlisted.

Some routing failures are a little bit more tricky to map out -

Consider a simple scenario where you have a two way receive port publishing a request, which is being picked up by a two way send port -

image

Now add a second two-way subscriber to the mix…

image

In this case BizTalk cannot know which of the two potential responses it may get (from the two different two way send ports) it should deliver to the [send side of the] receive port, and so it opts to not even publish the request and instead deliver a routing failure.

This is fair enough - race conditions are not a good thing and it’s pretty clever that BizTalk identifies this up front and prevents this.

However - the same routing failure will happen, it appears, even if the publisher is NOT a two way port, and that – I did not expect.

If the publisher of the original message (the receive port) was not a two way port, but one-way, it would not expect any response from anybody, which removes the race-condition situation, and therefore should have been supported in my view, but it does not appear that it does.

Imagine a scenario like this -

1st Process publishes message A, through a one way port
1st Send port (2-way) picks up message A and calls a service, publishing the service’s response - Message B.
2nd Send port (also 2-way) picks up message A as well and calls a different service, publishing this service’s response - Message C.

image

As far as I can tell, this is a valid scenario – call it message enrichment via external services.

Subscribers should be able to subscribe to message A, B or C as they wish, and all is nice and loosely coupled, if you only ignore the fact that this does not seem to work!

Building such a scenario I'm getting a routing failure for message A, which - unless I'm not seeing correctly - I can only explain according to the rule mentioned above, which I find really frustrating.

Labels:

4 Comments:

  • Hi Yossi,

    I have a similar CBR setup working. In my case i didn't care for the response from Solict-Reponse send ports, so I initally created a new send port subscribed to the reponse message type using the NULLAdapter (Winterdom). This way, it was effectively deleted without having any overhead.

    I then realised that I could call my services using a standard one-way send port (even though the service is not 1 way), which would completely ignore the useless response message, meaning one less artefact arriving to the message box. Importantly - if for any reason my service threw a fault or was unavailable, the error would still propogate via a routing failure report - and so I get the best of both worlds. I can call the service as if its asyncronous, yet get error reports in the case of failure.

    Tarun

    By Blogger Tarun, at 19/12/2009, 17:54  

  • Yossi,

    This is indeed a puzzling problem, You're correct (IMHO) this should work. I played around with it a little and true as ... I get routing failures immediately on receipt of a message. My understanding is that as long as there is a consumer for each response msg from a send port then all should be ok. but it doesn't appear to be so.

    I can get this scenario working, but only with an orchestration consuming the first message, then using a parallel shape to invoke the two way send ports correlating the responses back to the orchestration and having it write the response back to the messagebox.

    Odd. I'm going to play around a little more and see if i dig up anything more on this.

    By Blogger Ryan CrawCour, at 21/12/2009, 04:05  

  • Hi,
    I had a problem like the you describes where a 2-way receive port publish a message and we have multiple 2-way send ports subscribing to the message. We were getting a routing problem but we could fix it. There was a hot fix published in Nov 2007 that seems did not make it to the upgrades. Have a look at http://support.microsoft.com/kb/923632. We are using BTS 2009 and the mentioned registry entry was missing. Once we created it, the above scenario worked fine.

    By Anonymous Enrique Albert, at 30/04/2010, 14:27  

  • Thanks Enrique,

    I did not know that hotfix existed, and that's very good news.

    I still believe that in the case of a one-way publisher the product could be intelligent enough to understand there's no race condition, but this certainly works around the issue, if you're willing to live with the per-host setting

    By Blogger Yossi Dahan, at 01/05/2010, 07:12  

Post a Comment

<< Home