异常处理是一种编程语言构造，旨在处理某些更改常规执行流的情况（异常）。处理程序通常保存流和执行的当前状态，然后切换到一个预定义处理程序流。

　　Business Process Modeling Notation (BPMD)支持一些异常处理构造，它们可用于对业务流程中的异常流进行建模。流程作者负责创建设计时解决方案，处理所有异常类型，这需要完全理解所有流程服务、coaches、集成点、Business Process Definition (BPD)路由策略以及业务流程本身。

　　在架构良好的流程中，异常不应导致流程本身失败；相反，工作流应该遵循一条专门用于处理异常的途径（异常途径）。要建模理想的异常路径，重要的是要理解潜在异常可能在流程或服务中的什么位置出现。

　　可能出现两种异常类型：

• 　　流程异常：如果流程或服务使用的某个组件出现问题，就会出现流程异常。流程异常的原因通常是一些临时错误，比如连通性故障、超时、或设计时代码错误。
• 　　业务异常：业务异常的原因是流程中的某个决策的结果。实际流程在内部触发这种故障。业务异常是业务流程的一个组成部分，在业务流程由于以下原因无法继续执行时触发：
• 　　数据校验失败
• 　　权限不足
• 　　流程应该暂停的已知业务情况

　　业务异常允许创建更整洁的流程，将流程的异常情况定义为真实异常。

　　异常处理概述

　　异常处理解决方案途径基于以下几点设计考虑：

• 　　对于BPM应用程序，业务和流程异常可能需要不同的处理机制。因此，这种途径应该允许用户独立处理这两种异常类型。
• 　　有些流程和业务异常可能不严重，不应导致流程实例终止。异常处理途径可以处理这类非致命性异常，一旦这些异常得到处理，流程将继续或重试。
• 　　业务异常（有时还有流程异常）可能需要通过一个交互式工作流处理。异常处理途径允许开发人员使用一些交互式子流程来处理异常。
• 　　没有未经处理的流程异常。所有运行时异常都得到处理，要么在单独的活动中处理，要么在流程级别处理，具体取决于异常类型（无论流程是否需要重试）。

　　WebSphere Lombardi有一个用于处理异常的开箱即用特性。本文介绍的设计模式和最佳实践将帮助您创建更强健的解决方案。由于Business Process Definition和服务层都有可能出现异常，因此处理这两种异常类型的方法也不同。异常情况出现时，WebSphere Lombardi允许调用服务处理异常，例如：

• 　　额外的上下文日志信息。
• 　　将上述信息传递给用户。
• 　　执行替代执行路径。

　　最佳实践表明，异常处理应该包含重试逻辑（如果可能），或者将任务路由给管理员处理。WebSphere Lombardi有一种默认机制来建模业务异常，这种机制称为异常路径。还有一种默认机制用于处理流程异常（通常称为运行时异常），这种机制称为异常事件。

　　异常事件

　　异常事件监听运行时异常，或代表流程实例抛出异常。可以在流程需要触发业务异常时使用异常事件。

　　使用异常事件的一般规则如下：

• 　　异常事件可以是 “附加的” 或 “终止的”。
• 　　附加异常事件监听异常，终止异常事件抛出异常。
• 　　异常事件只能附加到某个活动。
• 　　当流程执行一个附加了异常事件的活动出现异常，流程将遵循附加到异常事件的序列线。
• 　　如果异常出现且发生异常的活动没有附加异常事件，则异常将沿着Business Process Definition调用栈向上广播，直到到达这样一个嵌套流程：该流程包含一个附加了异常事件的活动；或者直到到达调用栈顶端。

　　使用WebSphere Lombardi进行异常处理

　　异常处理是每个应用程序的基本要求，以便处理应用程序的任意意外行为。借助异常事件，异常处理也可以在WebSphere Lombardi中进行。

　　图 1 展示了WebSphere Lombardi中的一个典型异常处理场景。

图 1. 捕获传递到异常处理活动的错误消息和Step ID

　　有多种不同的异常类型，比如系统异常、流程级异常和业务异常：

• 　　如果异常的原因是系统级错误，那么让错误上浮到流程级别，以便在流程级别捕获错误。系统级错误包括语法错误、空指针异常、web 服务超时、数据库连接超时等。
• 　　如果出现流程级异常，则将其路由到支持通道（support lane）或活动。支持通道的用户就能看到错误并相应操作。
• 　　业务异常也被触发并显式路由到支持通道或活动实例。支持通道或活动的用户将纠正错误并将其发送回主流程流。

　　流程的每个活动都将被分配一个“Step ID”。一个“Intermediate Exception Event” 被附加到每个步骤，标识发生异常的活动。这很重要，因为一旦异常得到处理，流程需要在该活动处恢复。在Intermediate Exception Event的“Post Assignments”中，“Error Message”和“Step ID”将被检索并存储在流程级变量中。

　　如果某个特定步骤出现异常，中间异常事件（intermediate exception event）将捕获异常并将其传递到设计用于处理异常的活动。捕获的“Error Message” 和“Step ID”被传递到异常处理活动。

　　根据异常的严重程度，异常处理活动可能会采取以下一个或多个动作：

• 　　记录消息并将控制权返回发生异常的活动。
• 　　发送一封电子邮件并将控制权返回发生异常的活动。
• 　　传递详细信息，以便支持用户能采取行动，然后从门户启动实例。

　　“Step ID”表明发生异常的步骤。“Error Message”拥有一个详细异常消息，向Error Handling Activity中的Exception Coach处的用户显示。

　　WebSphere Lombardi日志框架

　　本文介绍的日志解决方案基于Apache Log4j API，采用基于文件的日志途径。

　　但是，完整的日志解决方案途径基于以下因素：

• 　　日志需要考虑已经在企业级别标准化或结构化得要求。
• 　　考虑日志信息（事件、事件和用户信息）或其他信息（比如负载、自定义消息等）中需要的数据量。
• 　　根据紧急程度和流程需求，不同流程的日志级别可能不同。
• 　　根据需求，日志数据存储可以基于文件，也可以基于数据库。
• 　　可能还需要提示进行了日志记录，如果必要，可以向支持小组发送电子邮件，以便他们研究日志。
• 　　如果达到某个阈值，考虑备份日志文件。

　　解决方案使用WebSphere Lombardi的标准特性来实现日志解决方案：

• 　　定义日志对象。
• 　　调用常规日志服务。

　　WebSphere Lombardi中的日志记录

　　日志记录通过以下活动完成：

• 　　调用日志：一个业务流程活动（通常是异常处理活动）激活一个日志 API。如果某个事件或服务需要被记录，可以在每个服务需要记录的起始和结束处创建一个日志任务。
• 　　填充包装器对象：记录器对象使用相关负载信息填充。该对象能生成进程实例特定数据，比如进程名称、当前活动、当前登录用户以及当前实例ID。
• 　　调用定制日志服务：此信息与日志消息一起传递到WebSphere Lombardi常规记录器服务，该服务需要被映射。此服务还可以添加一些特性，将通知或提示发送给日志用户。
• 　　调用WebSphere Lombardi常规日志服务，将信息记录到文件：这是WebSphere Lombardi的一个内置服务，专门用于记录日志。根据需求，甚至这个服务也可能被定制。可以使用这个日志服务设置优先性，最终如图 2 所示在指定的日志文件中记录相应条目。

图 2. WebSphere Lombardi常规日志服务

　　异常处理原则

　　以下原则将帮助您在一个Business Process Definition中集成高效的异常处理功能：

　　如果可能，不要将业务关键型Business Process Definition与错误处理功能混在一起。要牢记，异常和错误通常是技术问题，而不是业务问题。只有业务部门告知您或关心的异常和错误才应该在顶级Business Process Definition上可见。这条原则可能适用于子流程，具体取决于流程中涉及业务的深度。同样，在某个阶段，异常和错误都必须被适当处理。

　　考虑 “重建” 业务流程实例的难度有多大。如果从起始数据创建Business Process Definition很容易，那么 错误的严重性就较低，因为可以通过使用相同的输入新建一个Business Process Definition实例来处理错误。反之，如果从起始数据（或者甚至是当前状态数据）重建Business Process Definition很困难，那么Business Process Definition失败的影响就更大，因此，应该格外注意。在上述情况下，可以将流程最容易出错的部分封装到适当的错误处理功能中。这支持在必要时使用 “重试” 逻辑。

　　注意，Business Process Definition 中的错误处理与 COBOL 大型机应用程序中的错误处理不同。在 Business Process Definition 中，错误可以被路由到人，而人毕竟是流程的关键元素。考虑一下，如何利用人来解决错误，而不是让 Business Process Definition 失败，或写入一个日志文件，等待管理员查看。例如，一位客户在数据失败时将一个任务路由到管理员，请求管理员检查固定宽度的数据提要，以便找到错误的字符，修复或删除它们。另一位客户在使用 Optical Character Recognition (OCR) 技术不能正确识别修复后的字符时（这需要人工干预）将一个任务路由给一个人。当错误出现时，流程应该通知谁？通知域（notification domain）取决于错误的类型还是严重性？如果可能，应利用人来保护业务流程。

　　考虑一下，错误或异常何时导致Business Process Definition失败或终止是可接受的。有时，一个错误或异常路径意味着Business Process Definition 应该终止。考虑一下Business Process Definition是否存在这类情况，然后相应实现它们。

　　尽量简化错误处理机制。不要针对错误处理过度构建某个常用实用工具。尽可能靠近错误出现的位置记录错误。如果可能，将流程路由到能够处理错误的人。业务部门可能已经、也可能没有考虑和设计这种路由。系统管理员甚至也可能收到路由给他的任务。在解决错误的同时，尽可能保持流程简单。如果必要，将一个活动及其附加错误处理机制收集到一个子流程中，以保持父流程 “整洁”。

　　结束语

　　本文从BPM角度讨论了异常处理和日志记录机制，描述了 BPM 场景中可能遇到的异常类型，介绍了如何使用WebSphere Lombardi的开箱即用特性处理异常。本文还讨论了WebSphere Lombardi中的默认登录机制。