Design of the Exception Management Framework

Consistent re-usable patterns for exception management are a core part of any development project. They help to maximize maintainability and make it easier to support the application post deployment. ESB and BizTalk-based applications introduce new challenges because of the distributed nature of the BizTalk infrastructure.

For example, a typical BizTalk application might use the BizTalk messaging features, optionally start processing an orchestration, call the Business Rule Engine, interact with several line-of-business (LOB) or enterprise resource planning (ERP) systems, and return a response to separate third-party system. In addition, the run-time location of these components, including the BizTalk subsystems, may reside on one or more servers distributed within the current environment.

This is a typical scenario and requires that the system support catching and reporting exceptions that may occur within any of the ESB or BizTalk decoupled subsystems or in the various third-party LOB systems; each of which has its own exception-handling constraints. For example, the mainframe may reject an order sent from a Web site during a normal processing cycle. The Web site must compensate for this error and notify the user.

Because of the complexity of ESB applications and their environment, development of a consistent solution for application exception management should embody the following common design goals:

• Provide a standardized approach for detecting and handling exceptions that occur within the BizTalk Server environment; for example, in the messaging and orchestration subsystems.
• Provide common patterns that allow automated processes to react to and manage application exceptions.
• Provide a loosely coupled exception management pattern that facilitates reuse.
• Provide a common reporting mechanism for application exceptions and their available message states that can apply to any BizTalk subsystem.

To understand why the Microsoft ESB Guidance provides a custom error mechanism, namely the Exception Management Framework, and how it works, it is necessary to understand the exception management features available in BizTalk Server and why these features are not fully capable of meeting the preceding design goals.

BizTalk Server Exception Reporting

BizTalk Server supports the following exception handling and reporting mechanisms:

• Failed Message Routing (BizTalk 2006 only)
• BizTalk Server Administration Console
• Health Activity and Tracking (HAT)
• Microsoft Event Log
• Custom development options

In BizTalk Server 2004, the capabilities for handling exceptions rely a great deal on operator intervention. For example, consider the situation where a user submits a message to BizTalk Server that causes an exception during the validation stage. In BizTalk Server 2004, the message moves to a suspended queue. This means that an operator must do the following:

• Independently detect that an exception occurred.
• Manually save the failed message to disk using the HAT user interface.
• Manually edit and correct the message and re-submit it to the system.

To resolve these issues, BizTalk Server 2006 introduces the Failed Message Routing capability. Essentially, developers and administrators can use this to create orchestration processes or messaging send ports configured to subscribe to any exceptions that occur within the messaging subsystem. This provides an automated error-detection and routing mechanism that preserves the original message state and solves the problem of detecting exceptions.

This means that there are now two very different ways in which exceptions are processed and managed in a BizTalk Server system. Therefore, the developer must customize the exception handling mechanism to suit their own requirements if they want to implement a system that matches the requirements described earlier in this section.

BizTalk Server 2006 Administration Console

BizTalk Server 2006 includes a new Administration Console that provides a set of Group Overview pages. By using these pages, administrators can query for suspended messages and exceptions grouped by application, service name, error code, or URI, as shown in Figure 1.

Figure 1
The BizTalk Server 2006 Administration Console Group Overview pages

Although the Group Overview feature provides a common user interface to view exceptions, the views are limited to “live” service instances. Examining the state can be a cumbersome task because administrators must drill down through the tree to each item. In addition, several other factors limit the BizTalk Server Administration Console capabilities as an application exception-reporting tool:

• There is no capability for mining the data for business intelligence. For example, you cannot query for the worst offending applications on a monthly basis or examine quarterly trends for application exceptions.
• The business may require alerts to be raised when certain application exceptions occur or when reaching specific thresholds, but there is no facility to subscribe to these types of exception events.
• The Microsoft Management Console (MMC) that the Administration Console uses as its user interface (UI) mechanism is not an ideal interface, and it is not always convenient to access in production environments. At minimum, it requires users to be members of the BizTalk Operators role; and, in production environments, access to the MMC is usually only possible through Terminal Server.
• The console displays only unhandled exceptions (suspended service instances). If the developer handles the exception within the orchestration, allowing the orchestration to complete normally, the exception information will never appear in the Administration Console.

The Microsoft ESB Guidance addresses these limitations through the ESB Failed Orchestration Exception Routing mechanism. This closely resembles the Failed Message Routing mechanism introduced with BizTalk Server 2006. In addition, the ESB Guidance includes a pipeline component in a send port that subscribes to messages generated from both the ESB Failed Orchestration Exception Routing and the Failed Message Routing and normalizes them.

The ESB Exception Management Framework takes advantage of other features in BizTalk Server, such as the subscription model, and event-based Business Activity Monitoring (BAM). This means that the ESB Exception Management Framework can track the exception data points with BAM, and then publish them to the BizTalk BAM Portal for monitoring.