Suspended message routing is arguably the greatest and most anticipated new feature in Biztalk 2006.
Suspended message routing gives you the ability to subscribe to messages that fail inside the messaging system. Matt Hall going into detail on how to generate Error Reports for Suspended Message Routing and what properties you have available to subscribe to. In addition, the documentation that ships with Beta 1 cover this is great detail.
The ability to react to errors in the messaging system goes much deeper then just “No Matching Subscription” errors. You now have the ability to easily handle all messaging errors that occur inside a pipeline, an adapter, and even maps. That’s right, no more looking into the great abyss for Send and Receive Port mapping errors.
In a post about a year ago, I point out that Delivery Notification in Biztalk 2004 did not work when the map fails on the Send Port. Not any more! Now, Delivery Notification supports Send Port mapping exceptions as well as adapter exceptions.
That brings up another point. You now have Error Reporting, native support for First-in First-out on EVERY Send Adapter, and the traditional Delivery Notification to accomplish FIFO in Biztalk 2006. With all these options available it could be very easy to go overboard and needlessly bog down a process with too many bells and whistles. Off hand, I can not see a need in using both Delivery Notification and FIFO on a Send Adapter together in a single process.
I have put together a small sample that works with Error Reporting and Suspended Message Routing. It includes two Orchestrations, one intended to fail on the Receive Port and one on the Send Port. In addition, I have included a map that throws an Exception. In the suspended message routing Orchestration, I subscribe to the ErrorReport.FailureCode exists property.
Download: Biztalk 2006 Suspended Message Routing Sample
The download includes a binding file with source code as well as a packaged MSI. This should only be run on Biztalk 2006.