ESB Toolkit 2.0: Exception Management (Messaging-Only Scenario)

In the previous  post I’ve shown a Hello World example utilizing the ESB Toolkit Exception management framework inside an Orchestration. Its very common a BizTalk solution can be purely based on messaging (aka content based routing) without any Orchestrations. In this post, I’ll show you how you can take advantage of the ESB Toolkit 2.0 exception management framework inside your messaging only solution. ESB Toolkit 2.0 Exception Management Framework relies on BizTalk servers “Failed Message Routing” capabilities in a messaging only scenario. You can enable failed message routing either at the Receive Port  or Send Port. Once its enabled, whenever there is an exception while publishing the message into MessageBox or transmitting the message to the end point BizTalk Server will create and publish routing failure message with all relevant promoted properties into the MessageBox database. Installation of ESB core components (or just Exception management components) installs a generic send port called “All.Exceptions” as part of the Microsoft.Practices.ESB BizTalk application. The send port basically contains 3 pipeline components, configured with SQL Adapter and the filter condition is set as shown below. The top property ErrorReport.FailureCode is promoted by BizTalk Server whenever it publishes a Routing failure message into the MessageBox, so the generic Send Port (All.Exceptions) subscribe to any failed messages that get published into the system. The core logic relies on the 3 pipeline components configured in the send port as shown below. The first component ESB Exception Encoder is the one responsible for normalizing the fault message generated by either BizTalk Servers Failed Message routing in messaging only scenario or the one we explicitly published from the exception handling block in the Orchestration into a canonical message that comply with the ESB Exception reporting Schema. The ESB BAM tracking component is responsible for logging the exception details into the BAM Primary import database, in our case its disabled (Enabled:False). The final component ESB Transform is responsible for transforming the canonical ESB Exception message into SQL Adapter expected format. The message then finally gets processed by SQL Adapter and get stored in the ESB Exception management database (EsbExceptionDb). Now, you can see the logged exception details via the ESB Exception management portal as shown below. In the Fault viewer page, you can click on the Message Id link to view the original message that failed to get published into the MessageBox database, you also got the option to resubmit the message back into the BizTalk server from the Message Viewer Page if required.