内容


WebSphere Lombardi 异常处理和日志

Comments

简介

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

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
捕获传递到异常处理活动的错误消息和 Step ID
捕获传递到异常处理活动的错误消息和 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 常规日志服务
WebSphere Lombardi 常规日志服务
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 中的默认登录机制。

致谢

本文作者对 Srinivas Bannigol 对本文的审阅表示感谢!


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=764455
ArticleTitle=WebSphere Lombardi 异常处理和日志
publish-date=10102011