Chapter 3. ESB Exception Handling
Being prepared for situations when something goes wrong is always a key concept for the design and implementation of any IT solution. Depending on the scenario, we will need to decide whether to implement proactive or reactive error handling and how to handle system exceptions in opposition to a functional exception scenario.
Note
It's always advisable to re-use existing and proven frameworks or components instead of reinventing the wheel.
In this chapter, we will explore the benefits provided by the ESB Exception Handling framework:
The artifacts and patterns for exception handling included in the ESB Toolkit
How to capture and publish exceptions
How to monitor exceptions in the ESB Management Portal
How to repair and resubmit messages into the ESB
Error handling in BizTalk and the ESB Toolkit
The ESB Toolkit Exception Handling framework is meant to complement and standardize the usage of the existing error handling features included in BizTalk. The out of the box error handling features included in BizTalk are good, but a support model based solely on these becomes too manual and laborious for the teams supporting the solution. The following are some issues:
Inconsistent pattern for messaging and orchestration: The messages that fail during the processing of the messaging engine (during the execution of a pipeline for example) get suspended or, if
Failed Messages Routing is enabled in the corresponding port, routed to failed messages subscribers. In our orchestrations we don't have the same feature. We could create our own exception handling blocks to promote the same context properties Failed Messages Routing does, so the behavior was somehow similar, but we would still need to create those exception handling libraries so those were...
The Exception Handling API
As we mentioned before, in order to provide a more convenient approach to handle our exceptions in BizTalk, we would need to write some custom code and define the patterns our development team should follow to use them. Over time this has been done by many teams around the world, but now there's no need to reinvent the wheel as this is provided by the ESB Toolkit.
The fault message concept
The whole exception handling feature in the ESB Toolkit is built around the fault message concept.
A fault message is a special type of message that contains all the information about the failure that happened while processing at some point in our ESB. It's the canonical representation of a failure in the ESB, and contains all the relevant information about the fault and its schema is Microsoft.Practices.ESB.ExceptionHandling.Schemas.Reporting.FaultMessage.
Failed messages can come from three different sources, and so they need to be normalized so any downstream components know how...
The ESB Management Portal
The ESB Management Portal consumes data from the ESBExceptionDb database where the faults information is published. This data feeds several features in the portal.
Note
The ESB Management Portal is one of the samples provided with the toolkit and might not fit all organizations' needs, so it's open for any customizations required.
This module within the portal shows different reports about the faults that happened in our ESB. All the reports are accessible through the Reports link on the portal navigation bar, and can be filtered by application and by time range. The following reports listed are shown in the picture from left to right and from top to bottom:
Fault Count By Application: This report displays an aggregate view of all the faults generated for a specified set of applications over a specified time. This report is also shown in the portal's home page.
Fault Count By Error Type: This report displays an aggregate view of all faults by specified error...
In some organizations, the errors that happen in some systems might be relevant to other systems (for example, our production support case management system in the Exception Handler sample that we showed earlier in the chapter). Thanks to the ESB Exceptions service, we can standardize our operations processes in a company-wide fashion by having a unified process to notify and react to issues that happen in our systems.
External systems can use this web service to submit their own errors to the ESB. They just need to invoke the web service providing the relevant information of the fault that happened in the system, and so the fault message will be published into the ESB, allowing any subscribers to receive it and process it as required.
The service is deployed in two flavors when the ESB Toolkit is installed, providing both SOAP and WCF endpoints. The following figure shows the two types of services:
In this chapter, we learned how the ESB Toolkit helps us to design and implement a consistent error handling model within our ESB.
In the next chapter, we will go through the additional web services provided by the ESB Toolkit that support some other use cases for our ESB.
