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.
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
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 re-usable across orchestrations. Now we don't need to worry about that as the ESB Toolkit provides that API and standardized and proven patterns to follow.
- Limited alerting features: The best we could get when something goes wrong would be an event being logged in the Windows Event Viewer or some suspended instances showing up in the BizTalk Administration Console, but we would need to rely on further customization to get the correct people notified. We could do this either with custom code or some other monitoring products such as System Center Operations Manager (SCOM), but yet again the Toolkit comes to the rescue with some prebuilt features for this.
- Access to the error information: Some individuals within the organization might need to review and even report on the errors on our solution, but that would require granting them access to our production environment or relying on other solutions to provide the appropriate information.
- Issues resolution: The process of saving failed messages, manually fixing them, and resubmitting them is not always very neat, so a bit of extra help in here is more than welcome as well.
In the following figure we can see, highlighted in dashed square boxes, that the different areas of the ESB Toolkit architecture bring some cool news features around exception handing to tackle the issues mentioned earlier:
Those main items will be described in detail later in this chapter:
- The Exception Handling API: The ESB Toolkit provides an API that establishes defined patterns to deal with errors that might happen within the ESB and generate a fault message for them, either on the messaging or the orchestration runtime.
- The Exception Management Pipeline Components: These pipeline components preprocess any fault message published into the ESB, that later will be published into the ESB Management portal through the ESB Exception database.
- The ESB Management Portal: One of the main features of the portal is to provide reporting features over the errors that might happen in our portal, as well as creating alerts to be triggered when certain errors happen and even resubmitting failed messages.
- The Exception Web Service: Allows external systems to publish their own exceptions into the ESB.
By using all these features, we can envision and implement our error handling model in our ESB solution, even being able to establish an organization-wide standardized model to handle and report business errors.