第五章 ABPM系统的设计与实现
5.1 系统结构
根据工作流管理联盟参考模型，一个完整的工作流管理系统一般应当具有过程定义工具、管理监控工具、工作流API和数据交换格式、其他工作流执行的服务、客户端应用程序、被调用的其他应用程序这六个部门的内容组成[17]。不同部分之间的交互主要通过五种不同的接口来进行，他们之间的关系如下图所示：
管理监 控工具 过程定义工具 接口一 工作流API和数据交换格式 其他工作流执行的服务 工作流执行服务 接口五 工作流引擎 接口二 工作流引擎 接口四 接口三
图5.1 ABPM系统结构图
（1）过程定义工具。过程定义工具主要包含以下的要素：（1）建立过程定义的能力；（2）用AND-split、AND-join、 OR-split、OR-join这样的图形组件、对顺序、并行、选择和迭代路由进行建模的能力；（3）版本管理的支持；（4）过程中使用的案例属性的定义；（5）任务定义；（6）过程定义的正确性检查，以及任何遗漏或不一致的追踪[19]。在过程中，需要为每个任务建立多个属性。这些属性决定了在什么条件下执行任务，和执行什么操作。
下面列出了应为每个任务建立的属性： ? 人物的名称和描述。
? 任务信息——换句话说，员工执行任务时所需的指令和支持信息。 ? 执行任务的资源需求。
19
客户端应用程序
被调用的应用程序
? 任务的路由特性。 ? 需要的触发的定义。 ? 对工作流引擎的指令。
? 需要启动的应用程序以及应用程序启动的条件和次序。 ? 被应用程序使用和调整的案例属性的定义。
当OR-split或混合的OR/AND-split存在时，依据案例属性来确定后续任务的决策原则[20]。资源分类工具：除了定义过程，还必须对执行工作流十所需的资源进行分类，这样任务才能用特定的雇员分离。为此，要明确如下要素：
? 一个资源分类列表，通常被划分为角色和组织单元。 ? 资源分类的特性。
? 各种资源分类之间的联系。
分析工具：通常情况下工作流管理系统仅提供了有限的分析能力。因此在大多数的系统中，再投入生产前，很有可能定义出一些会带来灾难性后果的过程。因此将来的工作流管理系统会提供越来越多的分析能力。
（2）管理和监控工具。管理和监控工具主要是管理员用来进行用户角色权限组织结构的维护、工作流系统环境的重新配置、以及工作流的运行状态管理。系统还提供了对工作流运行相关数据的统计分析工具，比如任务的平均完成时间、平均等待时间和处理时间、在一定时间内完成任务的百分比、资源利用率的评价水平，这对于我们分析和改进业务流程是非常重要的。
（3）工作流客户端应用程序。在ABPM系统当中，工作流客户端的主要作用是为用户提供一个工作列表管理功能，用户通过工作列表管理器可以查看到当前所有可以操作的工作项，工作项的相关属性信息，可以按照名称或者其他属性对工作项进行排序。用户可以选择一项工作，启动任务实例，客户端把启动消息发送给引擎完成任务实例的创建工作，创建结果会返回给客户端程序。
（4）被调用的其他应用程序。ABPM负责流程的逻辑运行，而具体的业务操作应当由相关的应用程序来完成，用户通过开发人员设计的应用程序来完成具体的业务。一般情况下，一个Form表单就可以完成业务数据的提交工作，在某些情况下，与用户交互的可能是专门设计的应用程序，比如某些办公工具或者报表工具。该模块的主要功能是对抽取的特征信息进行分词、去重、去停用词、同义词替换、关键词词频统计等处理。
（5）其他的工作流执行服务。如果业务系统的用户数比较多，可能需要多个ABPM系统工作流引擎实例来满足业务需求，若干个工作流系统之间可以并行运行，并进行相互连接，我们称这种情况为工作流互操作。
5.2 功能分析
20
一般说来工作流管理软件都包括工作流引擎、工作流定义工具、工作流执行服务、工作流监控工具、对外封装接口几部分组成[21]，下面对这几部分进行详细说明。
图5.2 ABPM模块示意图
（1）流程定义工具。现在几乎所有的工作流产品都提供可视化的流程设计工具，我们的ABPM系统也提供了基于浏览器的流程设计器和开发人员在Eclipse平台使用的流程设计插件。现在有些产品不仅提供流程设计功能，还能验证工作流定义的正确性，甚至可以在流程执行前进行模拟仿真，这也是我们以后的研究方向。流程定义包含流程执行过程中可能用到的所有信息，这些元素包括开始结束条件、节点、节点之间的关联关系以及节点需要调用的服务，流程的参与执行者和要用到的相关数据等等。流程的执行者可以是具体用户，也可以是组织或者角色。
（2）工作流执行服务。系统中可以存在一个或者多个工作流引擎来提供工作流执行服务，管理多个流程实例的执行，这些工作流引擎可以是集中式的也可能是分布式部署的。工作流执行服务通过机解析流程定义文件，根据流程的逻辑安排活动的执行顺序，把工作项添加到用户的工作表中，在适当的时候调用应用程序来完成工作。
流程定义是工作流执行服务的前提条件，流程定义中包含了流程实例执行所需要的数据，这些数据主要包括节点信息、节点之间的逻辑关系和引起流程状态改变的用户操作等等。流程执行服务根据这些信息来控制和完成流程的整个运行
21
消息系统 数据库 流程设计器 客户端 表单设计器 Eclipse插件 流程运行监控 用户角色管理 资源仓库 工作流引擎 域控制器 内容系统 目录服务周期。如果流程定义信息中包含相关联的用户组织角色，那么流程执行服务将会根据配置信息请求调用相关的组织角色模型的数据来完成业务操作。
在一般情况下，被调用的应用程序可能与工作流引擎在同一台计算机上的相同环境中，也有可能处于不同的系统平台上。在实际中，企业的应用系统结构往往千差万别，运行平台也不尽相同，所以怎样让工作流引擎屏蔽应用系统的差异性完成业务调用，是工作流管理系统的一大难题，按照统一标准设计的接口有助于解决这一问题。
（3）流程实例表管理器。流程实例表管理器是工作流执行服务和用户之间交互的载体，它负责流程实例的存储，并把流程的信息反馈给用户。在某些开源的工作流引擎中，允许用户自己来扩展流程实例表管理器的实现方式，当然在我们的系统当中，它是作为系统的一部分存在的。在实际运行中，用户可以通过流程实例表管理器来查看流程的运行状态并对其进行修改。流程实例表管理器在系统中一般只存在一个实例，而工作流引擎则可能有多个与它进行交互。
（4）工作流监控工具。对于用户来说，工作流管理系统除了要完成流程的定义、执行过程以外，对流程的监控和管理也是很重要的功能。工作流监控以用户权限模型为基础，实行严格的权限区分，不同权限的用户可以进行不同的操作。管理员用户可以对流程的定义所有元素进行修改，可以更改流程节点的执行角色或者用户，可以暂停或者挂起一个运行中的流程实例。我们还可以通过工作流监控工具得到很多企业管理方面的信息，比如企业流程的平均完成时间、节点执行花费的时间、某个员工的执行效率等信息，这对于我们发现企业流程中的不足改进流程是非常有帮助的。
（5）对外接口实现及封装。ABPM系统也是基于以上的结构来实现的，ABPM还提供了REST风格的API给开发人员来调用工作流引擎的相关接口。REST API采用了JASON数据交换格式，建立在Spring Webscprit之上。每个Rest API调用都有其各自的认证级别，认证使用的是基本的HTTP认证，拥有权限的用户才能进行相关的操作。
5.3 工作流引擎
工作流引擎是整个ABPM工作流管理系统的核心，或者说是系统的中央运行枢纽[22]。ABPM吸收和借鉴了Activiti的设计思路和实现方案，通过抽象和封装，把工作流引擎尽可能的独立成一个中间层来完成所有与流程运行相关的动作，比如流程的流转、流程补偿机制、出错处理等。
22
图5.3 ABPM工作流引擎工作示意图
基于Activiti的工作执行引擎具有以下的优点：
透明性：透明性是指工作流系统的用户（业务的执行者）不需要知道工作流引擎的具体部署信息，包括所使用的平台和框架、开发语言等，工作流引擎的运行和内部实现细节，工作流引擎和业务系统之间的信息交互的具体过程等等。业务的实际执行者甚至察觉不到工作流引擎的存在。
跨平台性：基于J2EE规范开发实现的工作流系统可以在Windows、Linux等各种不同的平台上部署。
兼容性：工作流引擎除了要和用户交互，还要和各种异构业务系统进行交互。Activiti工作流引擎从一开始就预见到了这种差异性，使用了Web Service等先进的理念和技术来解决异构系统之间的交互问题。
5.3.1 流程解析器
流程解析器主要负责将符号化的流程定义文件解析成XML文件，并最终转化成可执行对象供执行引擎使用[23]。系统使用工作流模版来描述和定义工作流对象，最终通过持久化层将工作流保存在数据库当中。
5.3.2 流程管理器
在BPMN中，每个流程都必须至少拥有一个启动活动，当某个起始活动被触发，一个新的流程实例将会被创建。起始活动的触发条件有两种：第一种是外界传递进来的消息，第二种是pick活动的警报。
23