One of the most interesting new features for me within BizTalk 2006 is the ability to route failed messages. For BizTalk 2004 we wrote numerous utilities to minimise the operational headache of suspended messages. There were many possible methods for achieving this, subscribing to NACKs, reactively using some utilities written with WMI, etc.
However, none of them appeased my sense of injustice that this functionality really should have been included as part of the product. Let’s face it, your operations team do not wish to be spending a huge amount of time dealing with message instances in your Message Box. In fact, they would rather not be spending any time dealing with such matters, and I can’t say I blame them. So writing such utilities turned out to be a necessity, but brought various challenges to the table.
It seems that Microsoft have also subscribed to this philosophy of attempting to keep the Message Box free of such clutter and a step in the right direction is to provide this ability to route failed messages. You may now subscribe to and handle programmatically a new ErrorReport context property.
If you go to your Filter Expression property within a Receive Shape in an Orchestration you will notice the new ErrorReport context property from the list of available properties. You may filter on a number of properties from the ErrorReport such as those listed below:
- Description
- ErrorType
- FailureCategory
- FailureCode
- InboundTransportLocation
- MessageType
- OutboundTransportLocation
- ReceivePortName
- RoutingFailureReportID
- SendPortName
As you can see, there is quite a comprehensive selection of properties to choose from. In my simple example that is taken from the demonstration I have seen, we are simply going to filter on the ErrorType property with a value of “FailedMessage”, so that we receive all failed messages as shown below:
By setting up a direct port binding and using this filter expression we can receive all error messages into an Orchestration that can then go on to handle the error. Obviously, this can be as simple and complex as you wish, but in this example we simply send an email message with the attached message onto someone that needs to deal with the failure as shown below:
Now that we have an Orchestration to handle the errors, we need to tell the port where the errors occur to generate the error report that gets passed off into our generic error handling Orchestration. This is achieved by selecting the “Generate error report for failed message” tick box in your Receive Port properties box as shown below.
All that is left to do is send in some valid and invalid messages to test whether all is working as expected. In our example all the invalid messages get routed to an email address. On my development machine I have installed the Pop3 service with Windows 2003 to facilitate this and as expected an email is routed to the email address I specified.
The attachment to this email contains the original message. I have to say I ran through this example based partly on a demonstration I had and it worked pretty much first time and I was impressed. Not simply for the fact it was pretty painless to accomplish, but for the potential use of it in future applications.