通过

ESB 异常管理框架设计

  • 项目

管理异常的一致和可重用模式是任何开发项目的核心考虑因素：它们有助于最大程度地提高可维护性，并使部署后更容易地支持应用程序。

典型的 BizTalk 应用程序可能使用 BizTalk 消息传送功能，可以选择开始处理业务流程，调用业务规则引擎，与多个业务线 (LOB) 或企业资源规划 (ERP) 系统进行交互，并将响应返回到单独的第三方系统。 此外，这些组件的运行时位置（包括 BizTalk 子系统）可能驻留在整个当前环境中分布的一个或多个服务器上。 这是一个典型的方案，需要系统支持捕获和报告任何 ESB 或 BizTalk 分离子系统或各种第三方 LOB 系统中可能发生的异常，每个系统都有自己的异常处理约束。 例如，大型机可能会在正常处理周期内拒绝从网站发送的订单;网站必须补偿此错误并通知用户。

由于 ESB 应用程序及其环境的复杂性，开发一致的应用程序异常管理解决方案应体现以下常见设计目标：

  • 提供一种标准化方法来检测和处理BizTalk Server环境中发生的异常， (即消息传送和业务流程子系统) 。

  • 提供允许自动化进程响应和管理应用程序异常的常见模式。

  • 提供便于重用的松散耦合异常管理模式。

  • 为可应用于任何 BizTalk 子系统的应用程序异常及其可用消息状态提供通用报告机制。

    若要了解 Microsoft BizTalk ESB 工具包为何提供自定义错误机制（即异常管理框架）及其工作原理，必须了解 BizTalk Server 中提供的异常管理功能，以及这些功能为何不能完全满足上述设计目标。

BizTalk Server异常报告

BizTalk Server支持以下异常处理和报告机制：

  • 失败的消息路由

  • BizTalk Server 管理控制台

  • Microsoft 事件日志

  • 自定义开发选项

    默认情况下，BizTalk Server处理异常的功能在很大程度上依赖于操作员干预。 例如，假设用户向BizTalk Server提交消息，导致验证阶段出现异常。 默认情况下，消息将发布到 Message Box 数据库，在该数据库中将其路由到挂起的队列。 这意味着操作员必须执行以下操作：

  • 独立检测是否发生了异常。

  • 使用 BizTalk Server 管理控制台手动将失败消息保存到磁盘。

  • 手动编辑和更正消息，并将其重新提交到系统。 在某些情况下，此过程可能会丢失重要的上下文信息。

    若要解决这些问题，BizTalk Server提供了失败的消息路由机制。 开发人员和管理员可以使用它来创建业务流程进程或消息发送端口，这些端口配置为订阅消息传送子系统中发生的任何异常。 这提供了一种自动的错误检测和路由机制，可保留原始消息状态并解决检测异常的问题。

    由于未为业务流程进程提供自动失败消息路由，因此开发人员必须通过将异常处理程序块添加到业务流程范围形状来解释错误。 使用此解决方案，每个业务流程都可以有其自己的异常处理，但没有机制可以跨多个业务流程重用异常处理功能。

    这意味着现在有两种截然不同的方式在BizTalk Server系统中处理和管理消息传送异常，第三种方式是处理业务流程异常。 因此，如果开发人员想要实现与本节前面所述的要求匹配的系统，则必须自定义异常处理机制以满足自己的要求。

BizTalk Server 管理控制台

BizTalk Server管理控制台提供一组组“组概述”页，称为 BizTalk 组中心。 使用这些页面，管理员可以查询按应用程序、服务名称、错误代码或 URI 分组的挂起消息和异常，如图 1 所示。

管理员 控制台

图 1

BizTalk Server管理控制台组概述页

尽管“组概述”功能提供用于查看异常的通用用户界面，但视图仅限于“实时”服务实例。 检查状态可能是一项繁琐的任务，因为管理员必须向下钻取到每个项的树。 此外，其他几个因素限制了 BizTalk Server 管理控制台功能作为应用程序异常报告工具：

  • 无法挖掘商业智能数据。 例如，无法每月查询最恶劣的违规应用程序，也无法检查应用程序异常的季度趋势。

  • 业务可能需要在发生某些应用程序异常或达到特定阈值时引发警报，但无法订阅这些类型的异常事件。

  • Microsoft 管理控制台 (MMC) 管理控制台用作其用户界面 (UI) 机制不是理想的界面，在生产环境中访问并不总是方便。 它至少要求用户是 BizTalk 操作员角色的成员;在生产环境中，通常只能通过终端服务器访问 MMC。

  • 控制台仅显示) 挂起的服务实例 (未经处理的异常。 如果开发人员处理业务流程中的异常，允许业务流程正常完成，则异常信息永远不会显示在管理控制台中。

    Microsoft BizTalk ESB 工具包通过 ESB 失败的业务流程异常路由机制解决这些限制。 这与BizTalk Server的失败消息路由机制非常相似。 此外，Microsoft BizTalk ESB 工具包在发送端口中包含一个管道组件，该组件订阅从 ESB 失败的业务流程异常路由机制和失败的消息路由机制生成的消息，并将其规范化。

    ESB 异常管理框架利用BizTalk Server中的其他功能，例如订阅模型和基于事件的业务活动监视 (BAM) 。 这意味着 ESB 异常管理框架可以使用 BAM 跟踪异常数据点，然后将其发布到 BizTalk BAM 门户进行监视。