In the previous post we saw the main bill upload process. What I left out was the process that handles failed message routing.

Download Solution

http://1drv.ms/1P5X4b8

The Famous Failed Routing Error

In the previous post, I showed you how correlation is vital for the correct operation of a business process. However, this correlation – being based on matching field values – is subject to failure.

For example, in our process, say that the bank sent the Bill Confirmation Rq, with a wrong AsyncRqUID. Using correlation BizTalk will try to route the message to running Ox instance but it won’t be able to do so.

In order to see this, drop a bill request message into the folder. Now while the process is waiting for the confirmation rq message, edit the asyncrqid. Now drop the message in the confirmation request folder. If you examine now the event log you will see the famous error: “The published message could not be routed because no subscribers were found”. This happened because BizTalk was not able to match the correlation and no other subscribers were found for the message.

So how to solve this? Well simply do not submit the wrong id.

However, a technique called Failed Message Routing comes into play.

Handling all mis-targeted Messages: Failed Message Routing

A requirement I had from the Bank is that any message they send, must not be lost. It doesn’t matter if they send a message with the wrong asyncid and thus correlation is not matched; or if they just send a completely mistargetted message which is not even for a running Ox instance. Regardless of the case, the gateway must get the message. Now what will the gateway do with this message, is a non-relevant business complication.

A technique called Failed Message Routing is designed just for this purpose.

To enable failed message routing, first from the admin console on the receive port that receives the confirmation message, select option “Enable routing for failed messages”. This means, that when this port receives a failed message, this message will be sent to the MessageBox with additional properties promoted that provide information about the error. As we’ll see in a moment, I can then create a send port or an orchestration that subscribe for these properties, and thus will get the message.

In VS solution I have an Ox which I called FailedMessageRouting, this Ox, uses a MessageBox direct binding port:

This means that the Ox will be getting messages published internally and not from an external entity..

In the receive shape I set the following filter expressions:

First thing to notice is that, as I said moments before, I am building my subscription around the ErrorReport context properties that were generated as a result of enabling failed message routing on the receive port. Together, these filter conditions, indicate that my Ox wants to subscribe on any message whose error report says that it was received on the receive port where I enabled failed message routing and where the error type is failed message.

To see this in action drop a billconfirmation request message in the file location. There are no running instances to pick this message so I know that this is a case of failed routing. To see this go the admin console, from the group hub I will select completed instances. You will see an instance of the FailedMessageRouting Ox completed:

If you check the debugger you see that the Ox has indeed processed the failed message:

One final thing which is good to see, if you right click the instance and select the tracked message events you will see the failed message that the  orchestration got. Double click the message, first check the body and this is for sure the message that you submitted. However, the interesting part is the context:

Ss you can see there are error report promoted properties. These are the result of enabling failed message routing, and these are the properties that my Ox used to subscribe to the message.