工作流系统异常处理实现方法

工作流系统异常处理实现方法①张志君②范玉顺（清华大学自动化系北京 100084）摘要随着业务过程的不断复杂和多变，工作流管理系统需要提供一套有效的异常处理机制应对由此而带来的各类异常情况。

在分析工作流系统异常的基础上，结合高级编程语言的异常处理方法、工作流任务的事务特征和组织层次的异常处理协调三个方面提出了一种工作流系统异常处理的实现方法。

关键词工作流系统，异常处理，事务，协调0 引言工作流技术通过信息技术的支持实现企业业务过程的自动化执行，是实现业务过程管理与控制的一项关键性技术。

目前，工作流技术已经成为了计算机应用的一个重要研究方向，并被逐步应用于服务业与制造业等领域。

随着业务过程的不断复杂和多变，工作流管理系统中的异常处理问题显得尤为突出[1-3]。

传统上将异常处理包含于正常流程中的方法不仅不能有效的处理各类异常，同时使得整个系统流程复杂化；而完全的人工参与也使得异常处理过程效率低下，形式极不规范。

所以，工作流管理系统的异常处理机制应该以统一的方式处理各种错误情况，采用人工与自动处理相结合的方式，实现异常处理与正常流程的分离。

高级编程语言中的结构化异常处理（Structured Exception Handling）方法已经发展的相当成熟，在C++、JAVA、C#等语言中得到了广泛应用与验证[4]。

结构化异常处理方法中的异常传播和处理机制为工作流系统的异常处理提供了一个很好的借鉴模式。

这种TRY-CATCH-FINALLY模式的异常处理过程如下：z在TRY模块中检测程序运行情况，如果发生错误，则抛出异常；z程序运行停止于异常发生处，然后开始沿调用栈向上搜索，直到找到处理该类型异常的CATCH模块；z程序按搜索顺序执行所有嵌套程度大于当前CATCH模块的FINALLY模块；z执行当前CATCH模块中的异常处理函数；z异常处理函数结束后，终止异常，并从异常被处理处继续执行，即继续执行当前CATCH模块后的FINALLY模块以及之后的程序语句。

需要注意的是，相当多情况下工作流系统的异常需要在人工参与的情况下进行传播，而非自动传播，并且在异常处理完成后，过程应该从异常发生处继续执行，这是与高级编程语言异常处理模式的很大不同。

事务概念来自于数据库研究领域，用于解决数据的并发访问与出错恢复问题。

工作流过程本身具有事务特性，而工作流过程的层次化和执行控制结构，与高级事务模型又非常相似[5]。

在工作流异常处理中加入工作流过程的事务特征是相当必要的，这主要包括基本活动的状态转换和子过程的事务特征。

为了方便于分析，本文不再区分子过程（Subprocess）与模块（Block）的不同，并且认为事务块（Transaction Block）仅在子过程层次上实现。

子过程（Subprocess）和活动（Activity）统称为任务（Task）。

另外，由于异常本身存在的多样性与复杂性，异常处理过程需要人工与自动处理相结合① 863计划（2002AA414710）资助项目。

②男，1978年生，硕士；研究方向：CIMS环境下面向企业的工作流技术；联系人。

（收稿日期：2003-05-08）的方式进行。

人工参与的异常处理过程就要涉及到系统的组织结构。

考虑到人员在工作流系统中的严格角色和权限定义，单靠部分参与者可能无法完成一个异常处理过程，所以除了异常的自动传播机制外，如何在系统的组织层次上实现异常处理过程的协调合作也是非常重要的。

而且这也为异常处理完成后，保证过程仍从异常发生处继续执行提供了一种实现方法。

文献[2,3,7]对工作流异常和异常处理的分类进行了深入研究。

文献[1]分析了工作流任务的原子性特征，提出了一种异常自动传播和处理机制，并重点论述包含异常处理过程的工作流模型的正确性准则。

文献[2]在工作流元模型方面进行研究，实现了保持执行状态、修改执行状态和动态演进三个层次的异常处理。

本文在简要分析工作流系统异常的基础上，结合高级编程语言的异常处理方法、工作流任务的事务特征和组织层次的异常处理协调三个方面提出了一种工作流系统异常处理的实现方法。

1 工作流异常分析企业业务过程的不断复杂和多变使得异常处理问题在工作流系统中无法避免。

工作流异常可以定义为一种对正常工作流流程状态的偏离，这种偏离主要指工作流实例运行状态与其原始定义的不一致，在某些特殊情况下（如工作流模型动态演进），也可能指与所期待状态的不一致。

对于工作流异常的分类多种多样，从实用的观点来看可以有以下两种分类方法[6,7]。

1) 按异常的激发源分类：z系统异常：系统异常指在工作流执行过程中，由工作流系统直接激发的异常。

这类异常又可以分为：时间异常，工作流实例对时间限制的违反，如任务运行时间超过给定期限；数据异常，工作流相关数据对其约束条件的违反；资源异常，无法为任务分配人员或资源；应用异常，无法激活所要调用的自动应用，如所定义自动应用的位置错误等。

一般的，对于工作流管理系统实现层次的错误情况，并不归类到工作流异常中，这类错误应该在程序实现时得到解决。

但某些情况下，这类异常可以由工作流管理系统映射为某种系统异常，如由于网络连接中断导致的自动应用激活错误可以映射为应用异常。

z任务异常：由任务的执行者或执行程序激发的异常。

这类异常主要是由于任务输入参数错误、资源不可用或其他外部原因而导致执行者或执行程序无法正确完成任务功能而产生。

2)按对异常的知晓程度分类：z可预测异常：可以预见的对工作流正常流程的偏离。

通常对出现的异常情况有充分的了解，并明确的定义了异常处理过程。

这类异常经常用来描述工作流过程模型中很少发生的情况，将这类情况定义为工作流异常，可以避免流程复杂化，增强模型的可读性，提高工作流过程的执行效率。

z不可预测异常：在模型定义阶段无法预知的异常情况，通常需要在异常发生时通过人工参与处理该类异常。

某些情况下，对于实例异常的处理可能导致对整个工作流模型的修改，这就涉及到工作流模型动态演进问题。

异常处理是指在异常发生后，由工作流系统提供一套机制，通过人工和自动处理相结合的方式，使工作流重新回复到正常流程或预期状态的方法。

通常，异常处理过程可能采用的操作包括：1) 忽略：出现的异常对工作流流程的正确执行没有影响或者影响可以忽略。

这种情况下系统可以由异常处理状态直接回到正常运行状态。

2) 重试：对于出错的任务重新执行，直到任务运行正确完成或者超过了设定的最大重试次数。

重试过程中用户可能采取了其他一些外部操作，如恢复网络连接等。

3) 修改实例：异常的发生是由于实例的某些属性或数据与正确值或预期值不符造成，此时可以通过直接修改这些属性或数据达到解决异常的目的。

4) 后向恢复：通过对已经执行任务的补偿，使工作流实例的状态恢复到一个可以重新执行的正常状态，然后通过人工导航（沿原路径或其他合理路径）重新启动实例的运行。

5) 修改模型：修改工作流实例所对应的模型。

修改模型可以仅针对当前实例，即为当前实例建立一个临时模型，也可以将所作修改保存到模型定义中，从而影响到其他实例和新实例。

替换原有活动、增加新路径、修改限制条件等都是这种方法的表现形式。

6) 复杂组合情况：上面各种处理方式的组合。

对于复杂的异常处理过程，需要联合使用各种异常处理操作以达到目的。

常见的描述异常处理实现的方法包括[7]：1) 失败补偿法：给每一个任务设置相应的补偿任务，以保证在异常发生时通过补偿任务的执行消除原任务所产生的影响。

使用该方法能够使过程实例的状态恢复到一个可以重新执行的正常状态。

这种方法的缺点是对于不同的异常不加区分，并且只提供一种后向恢复机制，实际的异常处理仍然完全依靠人工参与。

2) ECA（Event-Condition-Action）规则法：在异常事件发生时，根据预先定义的规则判断条件状态，然后决定所要采取的动作。

该规则可以配合异常处理知识库实现。

这种方法是基于ECA规则工作流建模方法的推广，对于不同的异常提供了不同的处理方法，但未考虑异常传播、任务事务特征和组织层次协调等问题。

2 异常处理方法2.1 任务属性定义工作流模型定义了其组成任务（包括活动与子过程）的各种执行属性。

为了满足异常处理的要求，我们在工作流模型中加入任务的事务特征和异常处理属性定义。

表1简要描述了这些属性，其中包括任务执行失败后的回退（Rollback）属性，由于并非所有的任务都是原子性的，所以在任务执行失败后需要取消任务失败所产生的影响；任务执行完成后的补偿（Compensate）属性，可以在后向恢复时将已经完成任务的影响消除，恢复到未执行状态；任务失败后的重试（Retry）属性；以及该任务所有可以引发的异常和提供的异常处理过程。

表1 任务的相关属性类别名称类型描述Rollbackable 布尔型是否定义回退过程失败回退Rollback Process 回退过程System Rollback 布尔型是否执行系统回退Retriable 布尔型是否可重试Retry Times 整数型最大可重试次数失败重试Need Rollback 布尔型重试前是否执行回退过程Compensatable 布尔型是否定义补偿过程完成补偿Compensate Process 补偿过程System Compensate 布尔型是否执行系统补偿Exceptions 数组型该任务所有的可引发异常异常引发 Raiseable异常处理Exception Handling Processes 该任务所有的异常处理过程工作流模型允许用户自定义任务的回退过程和补偿过程，同时也提供了自动的失败回退和完成补偿过程。

系统回退：对于普通活动，根据日志记录取消数据操作；对于子过程，回退所有正在运行的活动，然后逆向执行补偿所有已经完成的活动。

系统补偿：对于普通活动，根据日志记录取消数据操作；对于子过程，逆向执行补偿所有已经完成的活动。

在逆向执行补偿时，由于存在工作流运行到目前状态的确定历史记录，因此工作流模型中所有的未经历路径都可以消去，而由所有已执行活动和路径构成逆向工作流图。

以工作流管理联盟所提出的六种逻辑关系：顺序、与分支、与汇合、或分支、或汇合、循环为例，在逆向的工作流图中，只存在“顺序”映射为“顺序”、“与分支”映射为“与汇合”、“与汇合”映射为“与分支”、“循环”映射为“循环”四种逻辑关系。

2.2 任务状态图在工作流执行系统中，用户创建工作流模型的运行实例。

工作流实例的执行过程如下：首先实例化其模型顶层的开始节点，然后按照模型定义的控制流规则逐步实例化后续任务，即工作流实例的导航过程，任务执行通过与人员和外部应用的交互，完成任务所要求的功能，然后继续导航过程和任务执行，直至遇到模型顶层的结束节点为止，整个工作流实例运行结束。