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 -
Now add a second two-way subscriber to the mix…
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.
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.