如何基于工作流,实现OA-ERP集成

第一篇：如何基于工作流,实现OA-ERP集成

如何基于工作流，实现OA-ERP集成

2002-10-30 13:15

郭应中、吴科/(AMT)

引言

ERP系统是对企业能够提供业务数据支持的信息系统，OA系统是实现公文收发、流转、签发、归档等群组化办公作业自动化的信息系统。两者都是为实现单一目标而运行的信息系统。

在企业的业务活动中，经常有些业务是贯穿ERP和OA两个系统的。比如采购流程：采购申请生成、采购定单生成、验收单生成是在ERP系统进行；采购单申批、入库准备单流转在OA系统进行。企业中存在对OA和ERP两个系统集成的需求。另外，ERP系统和OA系统实施的难度差别造成一个时期内系统覆盖范围不同，将两个系统集成，ERP的实施效果可以事半功倍。

将两个系统集成，涉及到组织、角色、任务和过程的定义和管理。通过工作流系统进行集成，不但可以把两个系统中的多个模型统一，还可以使企业专注于应用业务，更方便地进行企业流程重组（BPR）。

对ERP和OA两个系统的集成，主要的工作有集成方案的确定、系统集成功能范围的确定、工作流系统的创建或改造、组织模型的统一等。

集成方案的确定

实现OA和ERP系统的集成，通常的实现方案有以下三种：

1、更换原有的ERP系统，选择能够同时提供OA和ERP解决方案的供应商。

同时提供OA和ERP解决方案的供应商，其产品在设计阶段就考虑到了两个系统的集成。但是目前这样的方案往往是供应商出于市场份额的考虑而提供的，由于开发规模、成本和周期的限制，所提供的ERP－OA一体化方案的功能往往比较简单，不能满足企业个性化的需求。而且，ERP系统在企业内运行一段时间后，更换新的系统，会面临新旧系统间数据移植的巨大工作量、用户不愿意舍弃熟悉的界面和高昂的费用等困难。所以这个方案只能被未实施ERP系统企业中的少部分企业使用；

2、使用ERP供应商的合作伙伴提供的集成方案。

例如Lotus Notes为SAP、Oracle、JDE等公司的ERP产品都提供了集成化的解决方案。其方法是：在OA Server和ERP Server之间通过数据库连接工具DECS连接。在ERP 系统的DB 建立大量视图供OA访问，在OA Server上建立关系型数据库，存储定期从ERP系统中按照字段映射过来的静态数据，作为OA系统组织和资源定义的依据。OA系统中的表单鉴审后可以通过ERP系统的Interface table写入ERP系统。

这种方案可以两个系统的高度集成，但是存在以下问题：

（1）不是所有的ERP系统都有相应的集成方案提供。Lotus Notes仅对大型而且著名的ERP产品提供了这样的集成方案；

（2）这个方案的实现和维护费用非常高。如果在新增流程，需要在ERP系统中新增视图，在OA系统中新增表单。对于大型的ERP系统，其数据库中的table有近万个，加上在OA中创建表单，都是企业IT人员无法独立完成的，仍需要方案提供者的服务。即使是方案的提供者，在使用这种工具完成两个应用系统结合 时，也必须同时对两个系统了如指掌。然而，不论在国内和国外，同时能够深层次了解两个系统的技术人员极为紧缺，加上高昂的购买费用，企业很难接受；

（3）ERP实施模块增加，特别是ERP系统的升级，都会造成集成化系统的瘫痪，限制了企业的业务发展。

因此，此方案的应用仍然比较少。

3、通过工作流系统，实现工作流程在两个平台上切换。

在工作流系统的管理下，用户通过远程登录工具和模拟键盘录入，实现OA平台和ERP平台之间的简单切换。系统架构图如下：

图1集成后的系统架构

对应上图的每个步骤说明如下：

1.用户登录OA系统后，Workflow Server根据OA系统中人员配置管理功能确认其身份，此用户同时得到了相应的权限；

2.身份确认后，Workflow Server再根据此用户在其权限内申请的工作流程提供工作流表单，并在表单上显示用户对应的组织结构的层次度；

3.用户在工作流表单上填写本流程执行需要的数据，这些数据可能是请假天数、请假原因等不涉及ERP系统的数据，也可能是访问ERP系统的参数。如果在流程执行时仅仅需要在ERP系统中执行查询，工作流表单的填写要在访问ERP系统后进行。

4.当工作流程执行到ERP系统上的作业时，工作流系统自动引导用户进入ERP系统。通过OA系统本身的Script语言结合Terminal simulator script语言编写的访问ERP系统的任务项，根据执行的流程类型、顺序、工作流表单参数，用户可以直接进入ERP系统相应的功能模块。

5.用户操作ERP系统。可以根据权限执行不同的操作。以采购申请为例，用户可以填写需要采购的物料编号、采购数量、价格范围、供应商等，存储后保存在ERP DB中；

6.ERP DB保存后，通过ERP系统界面向用户提示保存成功；

7.ERP系统将保存成功的单据编号和单据状态等信息传送到工作流系统。根据需要，用户可以把ERP系统生成的表单导出为Excel文件保存在本地；

8.当工作流系统收到ERP系统传来的信息后，进行格式检查，确认无误后继续执行；

9.用户在屏幕上审查工作流系统执行情况是否正确，确认无误后，将工作流表单传送到Workflow Server，保存在本地的Excel文件也可以作为附件提交；

10.Workflow Server收到用户传来的工作流表单，并据此将工作流表单和附件传送到下一个执行者。

同前面两种方案比较，这种方案的适应性非常强，开发量、开放难度和费用都比较低。因此为本文采用。

系统集成功能范围的确定

如果把企业内所有的流程都通过工作流系统在OA和ERP系统中实现，不仅没有必要，而且有些流程是不适合在信息系统中实现的。因此，需要对系统集成的功能范围进行确定。

企业内部流程是由一个个动作组成的，根据动作发生的频率和流程特点，可以分为以下三个类别：

A类：发生频率高而且执行简单。如各种申请的上呈、核签、否决、查询；

B类：发生频率一般，执行方法复杂而且经常发生变化。如会签，往往人数不定，层次不定，后续动作不定；

C；类：发生频率特别低，或者其所在流程不具备管理意义。如卫生值日流程中的所有动作；

为使集成工作简单而有效，系统集成的功能应集中在由A类动作组成流程的范围内。在集成工作前阶段，工作流系统中计划实现的流程中，需要OA和ERP两个系统共同完成的流程有：

1．物料信息维护。当物料新增或停用时，经过层层签字，在ERP系统中做相应处理；

2．采购流程。采购申请、审核、采购申请汇总、分单验收、入库流程；

3．付款流程。付款申请、发票校验、审核、通知付款、付款登记；

4．报销流程。单据填写、网上审核、票据检查、登记入帐；

工作流系统的改造或重构

按照工作流管理联盟的定义，工作流是一类能够完全或部分自动执行的经营过程，将文档、信息和任务在不同的执行者之间传递、执行。

传统的工作流系统中，每一个业务流程都要根据企业内的业务流程完整构建出来的。这样每一个业务流程都有大量的代码来实现，流程的创建和维护工作量很大。

仔细分析企业内的众多业务流程中，相当部分的流程是有共同部分的，每个流程中都有功能重复的代码。动态工作流把完整的工作流分解为若干个活动（Task）（对象），使工作流建模工作得以简化，可以实现更复杂的工作流系统。

活动是动态工作流的一个重要概念：工作流是一组有关联关系的活动的集合。一个活动与其它活动之间有顺序，分支，循环，调用的关系，还有并行、有同步的关系。

按照动态工作流的概念，一个完整的工作流程被分解为若干个活动（Task）和活动间的逻辑控制器。每个活动不和其它活动作任何直接交互，交互完全在逻辑控制器间进行。如图2所示：

图2动态工作流系统结构

每个活动都有进入条件，工作条件，中断条件，完成条件，暂停条件及继续条件。执行时，判断每个工作项是否可以进入，可以则进行进入处理，然后，判断需要是否中断或暂停。活动的结构图如图3：

图3活动的内部结构

图3中，一个活动有不同的状态集、输入集、输出集。状态集包括等待、执行和完成。输入集和输出集分别由若干个输入和输出组成。输入来源可以是本活动的输出，也可以是其它活动的输入或输出或状态。当输入集中某项输入状态发生改变时，将触发工作项的状态发生改变。达到完成状态时，将产生输出集。输入不同，触发的执行过程和产生的输出集不同。当多个输入集同时被激活时，按优先级执行。

工作流系统的动作和逻辑控制器采用Java Bean和关系型数据库实现，可以设计为可视的图形元件，也可以设计为不可视的逻辑处理元件。这样做的好处是把工作流系统的各个活动做成代码行数小、功能明确的黑盒子，实现动态的工作流系统，并在多环境下运行。

OA系统和ERP系统都可能自带工作流功能。但ERP系统的工作流功能缺乏开放性和适应性，并且ERP系统开发商不允许对其进行修改，因此其工作流功能的存在在集成中实际上是一个障碍。完成系统集成后，ERP的部分功能会由系统管理员设定为只能通过远程登录的方式访问，这是要对ERP系统原有的工作流系统做重新的设置，以免系统运行出错。

OA的工作流功能，如果不能实现动态工作流机制，是无法满足集成的需要的。这时要对其工作流功能进行重构。如果已经实现了动态工作流机制，也要增加一些访问ERP系统的功能动作。

如果选择其它的工作流系统支持集成工作，虽然理论上可行，但是开发量未必减少，系统复杂度、维护量和费用必然上升，所以本文建议采用对原有的OA系统的工作流功能进行改造，实现企业的工作流系统。

组织模型的统一

OA系统和ERP系统都有各自的组织模型。OA的组织模型是服务于企业行政组织层面的，ERP的组织模型则是服务于企业业务层面的。在用工作流系统对两个系统集成时，要对两个系统的组织模型进行统一。在本方案中，就是要对OA系统的组织模型重新定义。

ERP系统的组织模型比OA系统要复杂，不同的ERP系统有不同的组织模型。以Oracle Application为例，其组织模型为：账簿集－法律实体－操作单元－库存组织，再往下是更细致的划分，可以做到用户－角色－所属组织－权限的一一对应，权限的设置可以明确到字段。

对OA系统的组织模型的重定义，主要是增加OA系统组织结构的层次数量，建立新组织结构数据库，把ERP用户和OA用户都在新的组织结构中反映出来。注意OA系统中的用户名要和ERP系统中的用户名统一，因为在ERP系统中用户名和角色、权限是对应的。但口令不能统一，登录ERP系统时，系统仍然会提示用户输入ERP系统的口令。

连接方法

本文中，Workflow Server是使用Lotus Notes Server＋Linux Red Had ver7.1系统，而在ERP系统上本文所采用的是HP/Unix＋鼎新Tip-top ERP系统＋HP9000，Client端则采用一般的Windows环境＋Lotus Notes客户端软件。

两个服务器通过TCP/IP协议连接。在Workflow Server上安装InterSoft公司编制的共享软件NetTerm 4.3.0简体中文版，可以在10个以上的操作系统上运行，对远程主机环境具有良好的设置能力。

NetTerm的作用是相应客户端发出的登录ERP Server的要求，所以连接型态选TCP/IP，端口填“23”，模拟型态和键盘定义都选VT100(上述设置适用于国内多数主机)，主机名称和地址填入ERP Server对应的地址和内容。

例如当用户需要访问ERP的采购申请功能时，工作流系统中访问ERP系统采购申请功能的活动中包含以下语句（用Terminal simulator script语言编写）：

expect 10”login:”

#username “Enter UserID”

#output “^U^M”

expect 10”Password:”

#password”Enter Password”

#output”^P^M”

output”12345^M”//工作流系统提示用户输入口令后生成该行

expect 10”/”

output”exe apmt420^M”

output “a”

流程执行完这段程序时，就自动打开了ERP系统的相应功能。在用户填写完采购申请单后，ERP系统数据库中的保存操作触发事件为：以XML的格式，把采购申请单编号、创建实际、创建人等信息传送到用户本地，并被用户本地服务响应，填写到工作流表单。用户可以执行修改功能再次访问ERP系统修改采购申请单。在用户确认无误后提交，下一个申批人接到提示申批的电子邮件，点击邮件中的连接，出现反映采购流程执行情况的流程表单。依次类推。

应用情况

在实际应用上，根据用户需求定义了采购流程、付款流程、报销流程等，并在ERP系统中开放部分数据访问和维护权限给Internet上自己的外地分子公司和上游客户，解决了ERP刚实施完本部，外地分子公司采购流程无法并入集团供应部采购流程的问题，使用户提前实现了集中采购的战略构想。目前，该用户的上游近600家企业中，已经有60家提供大宗原材料的供应商使用这些流程，集中采购和比价采购使该企业在每年10多亿的采购额中节约了大约1.5％的采购成本，给企业带来了良好的经济效益。

第二篇：开源工作流框架及平台集成分析报告（范文）

开源工作流框架及平台集成分析报告

目 录

Java主要开源工作流列表.......................................................................................................1 1.1.jBpm..............................................................................................................................1 1.2.OSWorkflow.................................................................................................................1 1.3.Enhydra Shark...............................................................................................................1 1.4.Activiti5........................................................................................................................1 1.5.OpenWFE.....................................................................................................................1 1.6.Werkflow.......................................................................................................................1 1.7.OFBiz............................................................................................................................2 1.8.Flow4J...........................................................................................................................2 1.9.ObjectWeb Bonita.........................................................................................................2 1.10.OBPM...........................................................................................................................2 四大开源工作流框架分析.......................................................................................................2 2.1.JBpm.............................................................................................................................2

优点...................................................................................................................................2 缺点...................................................................................................................................3 2.2.OSWorkflow.................................................................................................................3

优点...................................................................................................................................3 缺点...................................................................................................................................3 2.3.Enhydra Shark...............................................................................................................3

优点...................................................................................................................................3 缺点...................................................................................................................................3 2.4.Activiti5........................................................................................................................4

优点...................................................................................................................................4 缺点...................................................................................................................................4 与统一开发平台集成...............................................................................................................4 3.1.流程定义插件集成.......................................................................................................4 3.2.核心包及jar包集成...................................................................................................4 3.3.部署方式.......................................................................................................................4 3.4.版本选择与维护问题...................................................................................................5 1.2.3.1.Java主要开源工作流列表

1.1.jBpm jBpm是一个灵活可扩展的工作流管理系统。作为 jBpm运行时server输入的业务流程使用简单强大的语言表达并打包在流程档案中。jBpm将工作流应用开发的便利性和杰出的企业应用集成（EAI）能力结合了起来。

1.2.OSWorkflow OSWorkflow是一个灵活的工作流引擎，设计成可嵌入到企业应用程序中。它提供了许多的持久化API支持包括：EJB,Hibernate,JDBC和其它。

1.3.Enhydra Shark Shark完全基于WfMC和OMG标准，使用 XPDL作为工作流定义语言。流程和活动的存储使用Enhydra DODS(一个开源OR映射工具)。

1.4.Activiti5 Activit5继承了jBpm4的所有优点，支持最新BPMN2.0规范，实现了流程的可视化以及创新的Activiti Cycle协作组件，此外，通过与Mule的集成加强了其集成能力。

1.5.OpenWFE OpenWFE是一个开放源码的Java工作流引擎。它是一个完整的业务处理管理套件：一个引擎，一个工作列表，一个Web界面和一个反应器（存放自动代理）。可以与应用程序很好的给合。

1.6.Werkflow Werkflow是一个灵活可扩展的基于流程和状态的工作流引擎。它的目标是满足可以想象的所有工作流程，从企业级的业务流程到小范围的用户交互流程。通过使用可插拔和分层结构，可以方便地容纳各种工作流语义.第1页 1.7.OFBiz OFBiz是一个非常著名的开源项目，提供了创建基于最新J2EE/XML规范和技术标准，构建大中型企业级、跨平台、跨数据库、跨应用服务器的多层、分布式电子商务类WEB应用系统的框架。OFBiz最主要的特点是OFBiz提供了一整套的开发基于Java的web应用程序的组件和工具。包括实体引擎, 服务引擎, 消息引擎, 工作流引擎, 规则引擎等。

1.8.Flow4J Flow4J是一个可在Eclipse平台下以拖放的方式进行工作流建模的插件.。

1.9.ObjectWeb Bonita Bonita 是一个符合WfMC规范、灵活的协同工作流系统。对于各种动作如流程概念建模、定义、实例化、流程控制和用户交互等提供了全面的集成图形工具。100% 基于浏览器、使用SOAP和XML数据绑定技术的Web Services封装了已有的工作流业务方法并将它们以基于J2EE的Web Service形式发布。

1.10.OBPM OBPM是一个开源，轻量级的BPM系统。它的目标是让非IT人员也可以轻松构建IT业务处理流程。OBPM内建工作流引擎（Workflow Engine）, Form构建器，Report设计器。OBPM支持浏览器（IE/Firefox）做为客户端，同时还提供了强大的图形客户端。

2.四大开源工作流框架分析

2.1.JBpm 优点

1、JBpm是最适合扩展的代表，是在所有开源引擎中最适宜被商业化应用的一款；

2、JBpm使用了开源框架Hibernate3, 支持当前大多数流行的数据库, 针对不同数据库有一个对应的初始化脚本文件.3、JBpm将数据的管理职能分离出去，自己专注于商务逻辑的处理

4、使用Jpdl流程定义语言，直观易懂，可以手工修改，并且有一个Eclipse流程定义插件。

5、文档丰富，用户群最大，开源组织十分活跃，被jboss收购后发展趋势良好；

第2页 缺点

1、Eclipse流程定义插件不开源；

2、Hibernate3做持久化层，会产生冗余表和数据；

3、JBpm3、JBpm4、JBpm5版本互不兼容，发展趋势不明确；

2.2.OSWorkflow 优点

1、OSWorkflow是最轻量型的代表，也是一款非常灵活和低级别定位的工作流引擎的实现框架，可视化图标的流程在osworkflow 里都可以用代码实现；

2、OSWorkflow 有着非常优秀的灵活性，它能为应用程序开发者提供集成，也能与现有的代码和数据库进行集成；

3、OSWorkflow基于Action驱动，符合框架开发人员的操作方式及编程习惯；

缺点

1、实现一个工作流系统非常繁琐，每一个流程步骤实现均需要代码改变状态字段；入门难度较高；

2、组件功能匮乏，复杂流程项目需要基于其引擎做大量的二次开发，不适用；

3、配置项和开发代码量相对较多，后期维护成本较高；

2.3.Enhydra Shark 优点

1、工作流体系最为完备和复杂，秉承“模块化”的思想，比较容易扩展；

2、代码量较少，易于阅读、易于改写、易于维护；

3、有一个Jawe来图形化定义流程，图形化功能相对较强，可以编辑活动变量，流程逻辑控制属性.缺点

1、相比其他完全开源的框架，Shark2.0后，很多组件、文档商业化，需要付费；

2、版本更新慢，代码也不再按照开源方式来完成，商业化的定位限制了其发展。

第3页 2.4.Activiti5 优点

1、Activiti最大的优势是采用了PVM（流程虚拟机），支持BPMN2.0规范及其之外的流程格式；

2、与外部服务有良好的集成能力扩展，通过与Mule的集成加强了其集成能力；

3、继承了jBpm4的所有优点，实现了流程的可视化以及创新的Activiti Cycle协作组件；

4、对流程引擎运行期实例提供管理及监控的Web控制台。

缺点

1、数据持久层采用MyBatis3，没有遵循JPA规范；网络上反应“回退功能”实现起来比较困难；

2、核心是 BPMN 2.0 的流程引擎，BPMN2规范发展的比较慢，语言本身也过于复杂可读性差。

3.与统一开发平台集成

3.1.流程定义插件集成

1.JBpm与Activiti都有基于eclipse图形化插件和基于Web的流程设计器，2.OSWorkflow推荐手工编写 xml 格式的工作流程描述符，有基于Eclipse GEF技术开发的osworkflow建模工具；

3.Shark有JAWE作为定义工具，是否可与平台IDE集成还需要预研。

3.2.核心包及jar包集成

1.都属于轻量级工作流框架：jBpm.jar 1.06M；activiti-engine-5.9 1.1MB；osworkflow-2.8.0.jar 393KB；

2.Shark核心包大小在6M左右，但是依赖jar包过于庞大，其他三个框架依赖jar包都不多，但是否与平台jar包冲突还需验证；

3.3.部署方式

1.JBpm与Activiti都可以与应用项目集成也可以单独部署；

2.OSWorkflow不可单独部署，一般推荐与spring集成，方便事务管理及功能扩展；

第4页 3.Shark可集成也可单独部署：可以直接作为java库来使用；也可以单独部署，作为CORBA ORB 或 Web 服务来使用；

3.4.版本选择与维护问题

1.JBpm4 积累文档丰富.网上具有大量的共享技术资源，也是最稳定的版本，但是目前已停止开发和更新；jBpm5基本上完全抛弃了jBpm4的代码，所有代码全部来自原先的Drools Flow，资料和文档相对较少；

2.OSWorkflow是opensymphony下的一个开源项，2.8版本稳定，文档不是很详细，有较多网络资源，曾是ERP软件开发中广泛应用的工作流框架，JBpm的出现带走了很多用户，使其发展乏力；

3.Enhydra Shark2.0后，很多组件、文档商业化，需要付费，而且版本更新慢，商业化的定位限制了其发展；

4.Activiti5是JBoss jBpm架构师加入Alfresco后的作品，继承了jBpm4的所有优点，保持开发更新中，用户不断增加，较多用户推荐，开源社区活跃，发展前景看好。

4.总结

总体来看，四款工作流引擎框架与平台集成难度都不大，但所依赖第三方jar是否与平台冲突还需具体验证；从应用项目开发角度来看，JBpm4、Activiti5友好度较高，难易程度适中容易上手，而OSWorkflow、Shark则显得较为复杂；从文档资料及后期项目维护角度来看，Activiti5无论从版本升级，网络资料及社区活跃度来看都更胜一筹，其他三款框架都多少存在一些难度和问题。

第5页

第三篇：基于WEB的工作流引擎设计和实现

基于WEB的工作流引擎设计和实现

一、引言

随着社会生产的流程化，工作流（Workflow）起着越来越重要的作业，工作流的核心是流程管理。对于企业来说，其生产经营活动就是由各种各样业务流程交织在一起组成的。然而，在企业管理中，许多流程在日常操作过程中已被习惯，而不被人们所重视，更不能被有效的管理起来。另外，客户的需求瞬息万变，而产品的生命周期也是在不断缩短，技术在不断创新。企业要在这样一个竞争和变换的外部环境中求得生存，就必须要有随需而变的能力，不断地调整和优化自身的各种业务流程，对流程进行重构和再造。为此，本文详细描述了工作流引擎的系统结构、接口设计、功能建模，以及工作流引擎在ERP系统中的应用。

二、工作流技术概述

（一）相关概念

工作流（Workflow）就是工作流程的计算模型，即将工作流程中的工作如何前后组织在一起的逻辑和规则，在计算机中以恰当的模型进行表示并对其实施计算。工作流引擎（Workflow Engine，WfE）的主要功能是通过计算机技术的支持去定义、执行和管理工作流，协调工作流执行过程中工作之间以及群体成员之间的信息交互。工作流需要依靠工作流引擎来调度、实现。

（二）工作流引擎的主要功能

工作流引擎是定义、创建、执行工作流的软件组元。作为工作流的核心应能提供以下几个方面的功能支持：解释过程定义；创建过程实例并控制其执行；调度各项活动；为用户工作表添加工作项；通过应用程序接口（API）调用应用程序；提供监督和管理功能等。

三、工作流引擎的分析及设计

（一）工作流引擎的功能结构

工作流引擎需要支持两种业务流程，即确定型工作流和非确定工作流。确定型工作流是指人们可以事先给出运行路线的一类业务流程；非确定型工作流是指人们事先不能给出运行路线的一类业务流程。业务流程的流向应根据实际情况而定。工作流引擎的功能结构图应该如图一所示：

图1 工作流引擎的功能结构图

（二）工作流引擎控制器分析

引擎控制器是工作流引擎在运行时的控制中心，引擎控制器的控制结构图如图二所示：

图二 引擎控制器的控制结构图

1．调度中心。调度中心接受从外部接口发送过来有关流程控制的请求，然后根据不同的请求类型调用相应的处理模块完成与本次请求相关的操作并将结果返回。由于是在DBMS内部实现工作流引擎的控制模型，因此有关请求的并发处理等问题完全可以交给数据库管理系统来完成，也不需要诸如请求队列等形式的数据结构。

2．任务管理。任务管理主要根据调度中心的指示完成诸如任务创建、任务状态的转换以及相关数据的维护等工作。每次“结束任务”的外部请求将触发调度中心调用“任务管理”为后继活动（如果存在的话）创建新的实例，其状态为“待定”；同时，其他不同的外部请求也将触发“任务管理”实施任务状态的切换。

3．任务指派。任务指派处理只是针对常规交互活动，通常情况下，在任务状态由“待定”切换到“等待”过程中完成任务的指派工作，即处于就绪状态的任务在通常情况下都确定了其执行者。任务指派过程首先根据任务指派基准确定可以执行此任务的群体人员，通常情况下这是一个包含多个人员的集合；然后根据任务指派方法确定由这个群体中的哪些个体来执行任务，执行任务的个体标识记录在相应任务记录的字段中。

4．依赖检查。在工作流引擎中，业务规则可以分解成活动的前依赖规则和活动的后转发规则。依赖检查指的是活动的前依赖规则的检查，调度中心在将任务切换到就绪状态之前将进行相关的前依赖规则检查，只有满足检查条件的任务才可以进行状态的切换。

前依赖规则包含顺序、与汇聚、或汇聚和投票汇聚四种规则：

第一，对于顺序前依赖规则，从前趋活动流转到当前活动跟其他前趋活动没有关系，当前活动的启动没有其他约束条件，相应任务可以立即由“待定”状态转换到“等待”状态。

第二，对于与汇聚前依赖规则，相应记录要指明所有参与与汇聚的其他前趋活动，只有所有相关的前趋活动均到达各自指定的结束状态，当前活动方可启动。第三，对于或汇聚前依赖规则，前依赖活动集为空集，此规则的检查将涉及到业务活动表中的或汇集标志，其取值可以是所有相关的前趋活动的结束标记之一或者是一个特殊的标记。如果或汇集标志不是一个特殊标记，则将检查相应前趋活动的结束标记是否和或汇集标志相同，若相同，则启动当前活动，若不相同，则不作任何处理。如果或汇集标志是一个特殊标记，则首先结束的前趋活动将启动当前活动，后结束的活动将被丢弃。

第四，对于投票汇聚活动，前依赖活动集同样为空集，当前活动要等到属于同一批次任务数目达到设置的要求方可启动。

5．转发控制。当应用发出“结束任务”的外部请求时，该请求将触发调度中心启动“转发控制”。转发控制的主要依据在工作流数据模型中定义的后转发规则，后转发规则定义了当前活动与其后继活动之间的关系。

6．启动控制。启动控制负责常规自动活动的所对应的自动执行体的启动并对其活动进行监控。

三、工作流引擎实现

（一）任务表结构

确定型任务表负责保存系统中所有确定型流程的任务实例待处理记录及任务实例处理的历史记录，工作流引擎定期扫描该任务表，将任务表中所有待处理的任务实例分发给相应流程中的相应节点。

确定型任务表的结构为：TaskList(TasklnstanceID，TasklD，TaskStep，TaskHandleTime，ProceeID，DstNodelD，lsHandled，CommmitMan)，分别为：TasklnstaneeID：同一个任务可以有多个不同的运行实例。该字段用于区别多个不同的运行实例；TasklD：用于区别不同的任务；TaskStep：记录任务运行实例在流程中的处理步骤；TaskHand]eTime：任务运行实例在相应处理步骤中的处理时间；Processed：记录任务实例所在流程的ID；DstNodelD：处理任务运行实例的后续节点；IsHandled：任务实例在后续节点是否已经处理；CommitMan：任务的处理人。

（二）工作流的流向控制

工作流引擎的一个核心功能就是要决定确定型任务表中各个任务运行实例的后续处理节点，使任务运行实例按照事先定义好的路线流动，也就是流程的流向控制。

流向控制算法描述如下：

／*控制流程流向*／

function HowControl(string processid，string nodeid)｛

string[] followIds= GetSueNodeld(processed，nodeid);

for(int i=0;i

／*后续节点同步控制*／

if(查询后续节点i所对应的条件中有无isprecondition为true的条件)对后续节点进行同步控制；

／*子流程的处理情况*／

if(后续节点i是子流程)

将子流程的第一个节点作为后续节点；

向任务表中加入一条待处理记录；

}

}

四、结语

本文介绍了一个基于Web的工作流引擎的具体实现，该工作流引擎已经在药业管理系统中得到了实际应用，基本上可以达到预期效果，说明基于Web的工作流引擎设计和实现都具有相对可行性，可以应用在具体的管理系统中。

第四篇：工作流与K2 BPM的实现

1.结构化过程

这两个模式的共同点在于：模式所涉及流程的执行路径是由运行时决定的，而非设计时确定。包括：Arbitrary cycles（强制循环模式）、Implicit termination（隐式终止模式）。 11 任意循环（Arbitrary Cycles）

 描述：

工作流中的一个点可以让一个或多个活动反复的执行。

 案例：

“修改提交”后进入“经理审批”，但未通过，又回到“修改提交”。

 K2实现：

 12 隐式终止（Implicit Termination）

 描述：

在一个流程中，如果没有活动可执行了那么流程就会终止。换句话说，在工作流中没有active 状态的活动了，而且也没有活动会被激活，这就是隐式终止。（前提：工作流不能处于死锁状态）。

有的工作流引擎不支持。 案例：

“主管审批”通过后进入“经理审批”，未通过则无下一个活动。 K2实现：

如果“主管审批”的输入为“不同意”，流程将终止。

一般都会采用显示终止，因为隐式终止可能会引起不被察觉的错误，例如意外的输入可能导致流程的结束。

 多实例过程

“多实例”是指在流程图中，一个活动在同一时刻拥有多个可运行的、处于活动状态的实例。

 13 非同步的多实例（Multiple Instances Without Synchronization）

 描述：

在流程中，一个活动可以激活多个实例，也就是说可以把一个活动分发成几个控制线程。每个控制线程之间都是相互独立的，并不需要同步它们。

 案例：在网上订购书籍，以书为单位，每一本都会独立产生一个购书实例，并且每个实例之间不需要同步数据。 K2实现：

IPC Event调用方式需要选择为Asynchronous。

 14 在设计期间预先确定的多实例（Multiple Instances With a Priori Design Time Knowledge）

 描述：

一个活动可以激活多次产生多个实例。而产生的实例的个数在流程设计时就事先知道了。一旦所有的实例都执行完成，就会激活其他活动。 案例：

有关某些特定资源的请求需要完成固定几个不同的审核流程。 K2实现

主流程结构为模式2平行拆分 + 模式3同步，IPC Event中调用方式需要选择为Synchronous。

 15 在运行期预先确定的多实例（Multiple Instances With a Priori Runtime Knowledge）

 描述：

一个活动可以激活多次产生多个实例。而产生的实例的个数是变化的，取决于实例的特点或者可用资源数目，但是在流程执行过程的某个时期，在这个活动的实例产生以前，要产生的实例个数是能确定的。所有的实例都运行完成后，激活后续活动。 案例：

处理一个订单，订单中有多本书，要分别检查每一本都有库存，所有的书都检查完成后才开始进入送货。 K2实现：

主要结构为模式6多路选择 + 模式7同步合并，IPC Event中调用方式需要选择为Synchronous。

 16 无法在运行期预先确定的多实例（Multiple Instances With a Priori Runtime Knowledge）

 描述：

在一个活动能够被多次激活的这种情况下，在指定情况下的指定活动的实例数量无论是在设计时或者运行时都不能在活动的实例被创建之前预先确定。但是，在活动被创建之前，在运行中的某个阶段，这个数量是可以预知的。一旦所有的实例都完成了，其它的活动应该被启动。这个模式和模式14的区别在于，在某些实例运行结束之后，新的实例仍能被创建。 案例：

订购100 台电脑，涉及多个供应商，但是每个供应商供应多少台电脑是不知道的，因此供应商的数量事先也不确定。但是当每次供应商送货后，就会将现在所拥有的电脑数量和所需的100 台进行比较，来决定是否要下一个供应商继续送货。 K2实现：

比较复杂，可以利用模式11任意循环实现。

 基于状态的模式

这三个模式的共同点是：模式所涉及根据当前运行的流程状态来改变流程里的执行路径，包括：Deferred choice（延迟选择模式）、Interleaved parallel routing（交替平行路由模式）、Milestone（里程碑模式）。

 17 延迟选择（Deferred Choice）

 描述：

工作流中的一个点，有一个或多个分支已经被选择。与XOR拆分相比，并没有明确的选择，但是，选择是取决于环境的。与AND拆分相比，两者中只有一个被执行。这意味着一旦环境启动了其中的一个，另一个就被取消。要注意，选择是被延迟到两个分支中的一个真正开始执行时，也就是说，选择是可以尽可能的推后的。 案例：

在收到货物之后，可选择两种方法将其送到。选择取决于相关资源的可用性。如果资源均不可用，选择会被推迟到直到其中一个资源可用为止。 K2实现：

“监听资源状况”的Destination Rules是一个Robot帐号，只实现监听作用。

 18 交替平行路由（Interleaved Parallel Routing）

 描述：

一组活动以任意的顺序执行，每个活动都被执行，他们的顺序是在运行时决定的，并且在任意一个时刻都不会有两个活动在执行。 案例：

体检流程中的活动有各种常规检查和血液检查，哪个在先哪个在后都可以，但是不可能同时检查。 K2实现：

K2并无直接实现方法，需要编码，变通解决。

 19 里程碑（Milestone）

 描述：

一个活动能否执行取决于一个指定的状态。也就是说，只有在到达一个特定的未过期的里程碑时，活动才被执行。 案例：

客户在确定交付的前两天是可以取消订单的。 K2实现：

时间上的一些状态可以在Start Rule 和Activity Escalations中实现，其他的复杂逻辑需要编程实现。

 取消模式

这两个模式的共同点在于：模式所涉及的流程在运行时disables一个活动或者整个流程，包括：Cancel activity（活动取消模式）、Cancel case（实例取消模式）。 20 取消活动（Cancel Activity）

 描述：

一个可执行的活动被强制失效了，也就是说，一个正在等待执行的活动所在线程被移除了。 案例：

网上购书时已经下了订单，“支付货款”活动激活，这时如果取消了订单，那么相应的“支付货款”活动也要取消。 K2实现：

利用K2 的API实现。

 21 取消实例（Cancel Case） 描述：

如果一个活动产生了多实例，那么仅仅撤消这个活动是不行的，要将这个活动的所有后代（实例）都移除才行。 案例：

网上购书时如果取消了购书的活动，所有因订单激活的购书流程实例都要取消。 K2实现：

利用K2 的API实现。

 其他扩展模式

21个工作流模式并不能囊括所有情况，还有其他的一些扩展模式，例如：流程启动、回退、转发、通知、代理、催办、回收、任务批处理、任务分组处理、流程合并、子流程等等。

第五篇：轻量级工作流引擎的设计与实现

第一章

引

言1.1 轻量级工作流引擎的概念 轻量级的工作流引擎指的是从够用、灵活和低成本的设计原则出发，不追求工作流引擎的功能的完备和复杂，只是实现其中必不可少的功能和特征。在设计工作流引擎时主要考虑对其数据模型的定义和解释、活动之间的协调以及任务的分配和控制等功能提供支持，而不支持诸如提供内建（built-in）的应用开发工具、对应用资料的定义和完整性维护、完善的异常处理以及长事务控制等功能。轻量级工作流引擎的概念的提出，给开发工作流管理系统的开发人员开辟了一条新的道路。工作流管理技术本身就是一项抽象复杂的技术，它致力追求从企事业各种各样的业务中抽取出一个通用的模型，由这个模型去描述所有业务的一致性，以达到“放之四海皆可用”的程度。不过，要把众多的而又错综复杂的业务都集中在这个模型中，这是一件非常困难的工作，要经过一段漫长的摸索历程。而轻量级的概念让我们认识到可以从一般性的而又简单的业务入手，为企事业快速的开发出一个适应他们本身业务需求的而又带有可扩展性可移植性的信息管理系统，为他们提高工作效率，并保证在一段很长的时间内满足不断增加的业务需求。

1.2 工作流管理系统的分类及本文的侧重点

根据工作流过程本身的特点、系统建模的方式、所使用的底层支撑技术、以及工作流过程的执行方式等的不同而对工作流管理系统进行相应的分类。

1.2.1 面向文档的与面向过程的 前者的侧着点在于将电子形式的文件、图像等在有关的人员之间进行分发，以便能够得到不同人的处理与审阅。现有的文件管理与映像管理系统均属此类。在面向过程的WFMS中，工作流被描述成一序列执行环节。与各环节相应都有待处理的资料对象。各环节的资料对象可以按不同的方式分发到其它环节中去，如可以将资料对象的值作为控制条件、或者依此资料对象组装成其它的资料对象等。高端的WFMS一般都属此类系统。

1.2.2 结构化的与即席的结构化工作流指的是在实际工作过程中会反复重复、严格按照某个固定的步骤进行的业务过程。定义此种工作流所需要的各种类型的信息可以通过对业务过程进行详细的分析而得到，从而得到完整的过程定义并在以后的应用过程中反复使用。大量的办公程序，如公文处理、审批等都属此类。即席工作流则是针对那些重复性不是很强或没有重复性的工作流程的，关于这类流程执行所需的有关参数(如参加者等)事先无法确定，而必须推迟到过程实例运行时才能确定，同时在执行过程中间还可能会发生一些意外的情况。这种动态多变的特点在提供更高灵活性的同时，也为过程的建模与执行带来更多的复杂性。1.2.3 基于邮件和基于数据库

前者使用电子邮件来完成过程实例执行过程中消息的传递、资料的分发与事件的通知。低端的系统所使用的经常就是此种方法，它可以充分发挥电子邮件系统在广域环境下的资料分发功能，但整个系统将运行于一种松散耦合的模式下。在基于数据库的WFMS中，所有的资料都保存在某种类型的DBMS中，过程的执行实际上就是对这些资料的查询与处理。高端的大规模系统所使用的一般都是此种方法。

1.2.4 任务推动的与目标拉动的前者指的是从过程的开始逐步地一个环节一个环节的执行，当某个活动实例被处理完之后，后续的有关活动将被创建并被激活，由此直至整个工作流程的完成。这是目前大多数面向过程的WFMS所使用的执行方式。而在目标拉动的WFMS中，一个业务流程被看成是一个目标。过程实例执行时，该目标将被分解得到多个相互之间按一定约束条件的关联起来的可执行的多个环节，其中各环节还可以当成是子目标而进一步进行分解。在各环节均执行完毕之后，整个过程也就完成了。目标拉动是一种全新的执行方式，下一代的WFMS将具有此种特征。应该说明的是：上述分类只是从不同的角度入手的。一般来说，后面那些特点将给WFMS带来更好的灵活性，同时也将成为那些能够支持跨机构的大规模复杂工作流管理、面向关键任务的WFMS不可缺少的特征。1.2.5 本文的侧重点

本文的侧重点不在于完全实现其中一种工作流管理系统的所有功能，更不在于实现所有种类的工作流管理系统的全部功能，前文已经说过，这是一件非常困难的事情。那么我们的侧重点在哪里呢？就在于综合以上四种工作流管理系统的主要特点，是一个面向文件的，基于数据库的，由目标拉动的结构化的工作流管理系统，并且由此去设计和实现工作流管理系统的核心――工作流引擎。从一般性来说，目前大多数的企事业的业务都是事务申请，公文流转，各项通知等等，这些业务或者需要查看，或者需要审批，而这些业务的资料基本上是以文件的形式保存在计算机上，而其中一些格式化的资料是保存在数据库中，所以面向文件和面向数据库是轻量级工作流引擎的一个重要特征。业务的发起和结束是一项过程化的任务，任务又可以分解成一个一个环节任务，而任务是带有目的性的，由这个目的去拉动这个过程中的一个一个的环节任务，促使环节任务的推进，最终达到任务完成的目的。这些业务的过程化不是随机的，而是已经严格规定好的，只有遵循这些过程化的规则和流程环节才能完成整个业务。轻量级的工作流引擎就组合了以上这些，不追求工作流引擎的功能的完备和复杂，以满足一般性业务为目的，为企事业快速开发出适合他们业务的工作流管理系统。

第二章

工作流管理系统参考模型简介在阐述工作流引擎之前，我们来了解一下工作流技术的基本知识。早在几年前，为了建立工作流管理系统的相关标准，国际上成立了一个称为“工作流管理联盟”（简称WFMC）的国际组织。她提出了有关工作流管理系统的一些规范，定义了工作流管理系统的结构及其与应用、管理工具和其它工作流管理系统之间的应用编程接口，也就是工作流系统参考模型。

WFMC给出的工作流参考模型如下图：

接口2

接口3

接口4

接口1

接口5

过程定义工具

工作流API与交换格式

工作流执行服务

工作流机

（工作流引擎）

工作流 管理工具

其它工作流 执行服务

工作流机

工作流客户应用

工作流机直接调用 的应用

图2.1 工作流参考模型

从图中可以看出，参考模型包含了五类接口，分别是：

⑴ 接口1：过程定义输入输出接口，这是工作流服务与工作流建模之间的接口，该接口提供的功能包括通信建立，工作流模型操作和工作流模型对象操作。

⑵ 接口2：客户端函数接口，这是工作流服务与客户应用之间的接口，这是最主要的接口规范，它约定所有客户方应用与工作流服务之间的功能操作方式。包括通信建立，工作流定义操作（对过程模型定义操作），过程实例管理功能，过程状态管理功能，任务项列表/任务项处理功能，数据处理过程，过程监控功能，其它的管理功能，应用程序激活。

⑶ 接口3：激活应用程序接口，这是工作流引擎和直接调用的应用程序之间的接口，包括通信建立，活动管理功能，数据处理功能。

⑷ 接口4：工作流执行服务之间的互操作接口，这是工作流管理系统之间的互操作接口，包括连接的建立，对工作流模型和其中对象的操作，对过程实例的控制和状态描述，对活动的管理，对资料进行处理。

⑸ 接口5：系统管理与监控接口，这是工作流服务和工作流管理工具之间的接口，包括资源控制，角色管理，用户管理，过程实例的管理，状态管理，审核管理。

五个接口以及对应的API函数囊括了工作流管理系统的全部功能。一个完整的工作流管理系统就是以工作流引擎为中心，向外部部件（应用程序或其它工作流引擎）提供这五个接口，提供其实现的所有功能。

第三章

系统分析与设计在所有准备工作完成后，我们就开始进行系统设计和设计，构造一个轻量级的工作流引擎。轻量级的工作流引擎并不完全实现WFMC所提出的工作流模型包含的五个接口，特别是接口4，在分布式工作流管理系统才具有该接口。既然我们从轻量级的概念出发，我们就不再明显区分各个接口的界限以及其所具有的特定的功能，以够用、灵活和低成本的设计原则去设计出我们所理解的工作流引擎。我们运用了面向对象的方法，首先从众多的业务需求中抽取出工作流模型所包含的对象，再分析各个对象之间的逻辑关系，然后提出一个系统结构，再进行模块划分，数据库设计，最终完成类的设计。我们当中所用到的建模工具就是ROSE UML。

3.1 工作流模型的设计

对工作流模型的设计是工作流引擎设计的重要组成部分。

3.1.1 工作流模型的对象

企事业经营过程就是一项项业务的实现过程，我们从一般业务入手，并对这些业务进行详细的分析，研究，其结果就是得到一般性的业务对象，从而抽象成工作流模型对象。

3.1.1.1 从一个简单的业务实例看业务的需求

目前企事业的一项基本事务就是出差管理。它主要是对企事业的人员因为某种工作上的原因需要到别的地方出差进行的管理。我们可以列出出差的相关步骤：

⑴ 申请人需要出差，并且他（她）具有出差的权利；

⑵ 申请人填写出差表格，说明因何事出差，出差何处，申请出差金额，何时回来等等和出差相关的情况；

⑶ 申请人需要其它说明的话，可以将更具体的说明以文档的形式保存下来；

⑷ 申请人确认申请无误后提交申请，等待申请的结果；

⑸ 根据规定，该申请必须先让申请人的上一级审批，那么该申请就会以一项工作项的形式交给该级领导处理；

⑹ 处理该申请的领导对该申请进行处理，他（她）会先查看该申请所有的资料，包括出差申请表和与之相关的其它文档，然后对其进行审批，审批的结果是同意那么该次申请会交给再下一级领导处理；审批的结果不同意，该申请被打回，通知申请人申请不通过的结果。等所有需要审批的领导都审批通过了，该申请就成功完成，通知申请人申请通过的结果；

⑺

申请人得到申请的结果，如果审批通过则准备出差，如果审批不通过则根据审批结果对该申请进行修改，重新提交申请； ⑻ 申请事务结束。

这是一个简单的业务实例，对该实例进行分析我们可以得到该业务的一些对象：

⑴ 申请人：他（她）属于该企事业的某个部门的成员，并且具有启动该业务的权利； ⑵ 审批领导：他（她）也属于该企事业的某个部门的成员，并且具有对该业务进行处理的权利；

⑶ 出差表格：它是该业务规定的格式化资料，并且是必须的 ⑷ 出差具体说明：它是该业务附加的资料，可以不要的

⑸ 申请人已经填写好的出差表格：它是出差表格的实例化，代表一个具体的应用 ⑹ 审批同意和不同意：它们是对该业务的处理，遵循一定的业务规则 ⑺ 申请：这是一个过程，不是一个动作，需要时间和人的活动才能完成 ⑻ 审批：这是一个活动，是过程的一部分，并且可以向另外一个活动转化

⑼ 其它应用程序：申请人要填写出差具体说明时要调用相应的外部应用程序编辑该说明并以一定的格式保存下来，审批领导要查看出差具体说明时也要调用相应的外部应用程序打开该说明并以一定的格式显示出来。

从这些业务对象，再利用工作流技术，我们可以得到工作流模型的一些基本对象：

⑴ 用户：正如申请人，审批领导，他们就是工作流管理系统的用户，由他们去使用该系统的各种功能，并且直接参与业务活动，促使业务的完成。

⑵ 角色：有些人可以申请出差，有些人对出差申请可以审批，这两种不同的人可以作为两个不同的角色。角色是具有某种使用系统特定功能的权利的一个人员或多个人员的组合。⑶ 工作流应用资料：出差申请表格，出差具体说明，这些就是对应某个具体业务（这里是出差管理）的相关资料，根据这些业务资料我们可以对该业务进行处理。

⑷ 需激活的应用程序：在需要其它应用程序提供支持的时候，会去激活这些应用程序。⑸ 流程：整个出差申请的过程就是一个流程，它从整体去描述一个业务。

⑹ 环节：又称活动，它反映了业务流程的局部情况，通常业务流程是由一个一个的环节组成。

⑺ 流程实例：将该出差申请这个业务流程实例化，就得到一个流程实例。⑻ 环节实例：将流程的其中一个环节实例化，就得到一个环节实例。

⑼ 业务规则：业务的开始和结束需要一定的条件，在处理业务的过程中必须按照一定的规则，这些都是业务规则，只有严格遵循业务规则，业务才能完成。

3.1.1.2 工作流对象的具体分析和说明

通过一个具体的业务我们可以得到工作流模型的一些对象，那么我们再对其他一般性业务进行分析，研究，我们就会找到它们的共同点，并归纳出基于这些业务的公共的对象，这些公共的对象的组合，就是一个通用的模型，也就是工作流模型，这个模型能去描述每个业务，是我们追求轻量级工作流引擎的最终成果。

⑴ 用户：业务的执行者和参与者，对应于企事业的每一个雇员，是一个独立的、具有一定行为能力和一定技术能力的人的实体；

⑵ 角色：以技能为前提，能够完成某项功能的人员的总称；

⑶ 部门：对应于企事业的静态结构划分，由企事业的实际部门设置情况来决定，可以是传统的面向职能的，也可以是现在流行的面向过程与客户的；

⑷ 职位：以行政责任为前提，代表了管理上的等级关系；

⑸ 工作组：以执行某一任务为目标而动态组建的、跨部门划分的一种组织结构；

⑹ 流程：对应于一个业务过程，表示一个业务由发起、处理、结束的一个过程；

⑺ 流程实例：对应于一个业务流程具体应用，是业务流程实例化的表现形式；

⑻ 环节：对应于业务流程中一个单一的业务操作，是流程按照业务要求的细化；

⑼ 环节实例：对应于一个环节的具体应用，是环节实例化的表现形式；

⑽ 工作流定义主信息：描述一个工作流模型的主要信息，从整体来描述工作流模型；

⑾ 工作流附件信息：描述一个工作流模型所用到的附件信息，也就是工作流应用资料，或者叫业务资料。按照WFMC提出的工作流模型，这不是工作流模型所包含的对象，可是我们对其进行格式化，把它抽取成一个模型对象，用来规定了工作流模型在具体应用时所需业务资料的格式，我们把它分为两类：

●

表格类型：这是以表格的形式保存附件信息，可以用关系结构来定义附件信息，并保存在数据库中，每一条记录就是一个该附件的实例；

●

文档类型：只是以文件形式保存附件信息，可以是work文档，也可以是文本文件，它的实例化是就是一个一个带有对应某个业务应用标志的文件，保存在硬盘上 ⑿ 工作流实例信息：描述一个工作流模型实例化的信息，也作为启动一个工作流的信息，它记录该业务流程随着时间和人员的参与处理的不断变化，直到整个业务的结束；

⒀ 工作项信息：描述参与某个业务应用时被分配到的一项任务，这就体现了参与人员和系统交互的典型特征；

⒁ 业务规则：描述业务在运行的过程中必须要遵守的规定和原则，也是业务活动得以向另一个活动推进的规则。我们把它分为四类规则，分别是： ●

自动型：它主要描述一些只给参与人员查看业务信息的业务规则，例如通知、公文流转等等业务。该类业务不需要参与人员去审批或其它人为上的处理，只需要参与人员去查看其中的内容就足够，整个业务流程的完成是全自动的。●

与聚合：业务活动的完成是需要参与该活动的所有人员都进行人为处理，其中有一个人员没对其进行处理，整个活动只能停在原地，等待所有人员的处理，当最后一个参与人员执行了处理工作，它才能完成。●

或聚合：在参与某一业务活动的人员当中只要有一个对其进行处理，整个活动就可以完成。

●

投票聚合：统计参与该活动的参与人员的处理结果，当满足一定条件该活动才能完成。

⒂ 转换条件：描述流程、活动状态改变时需要的条件，用于业务运行过程中的约束。例如流程的完成必须等待所有活动的完成才能完成，活动的完成必须按照业务规则去完成等等； ⒃ 需激活的应用程序：工作流管理系统需要其它应用程序的支持，例如编辑和查看文本文件信息等等；

⒄ 日志信息：描述工作流中所有的状态改变、事件和控制流相关资料的变化，工作流实例和环节实例的启动、结束、挂起和激活等等信息都会记录下来，以便对其进行管理。3.1.2 对象之间的逻辑关系在找出工作流模型的对象后，我们就开始分析它们之间的业务逻辑关系。

3.1.2.1 对对象进行分类以及各个分类中对象之间的关系到此为止，我们有必要对工作流模型对象进行一下分类，根据工作流对象对工作流管理系统所起的作用我们可以分成以下几类： ⑴ 组织模型

组织模型描述了企事业的组织机构关系，包括的对象有用户，部门，职位，角色，工作组，它们的关系可以用下图表示：

设置

负责

组成 组成 资格

组成 部门

职位

用户

工作组

角色

图3.1 组织模型结构

从图中可以看到它们之间的关系，用户是基本的单位，部门是由用户组成，每个用户对应一个职位，负责该职位所要求的职能，用户凭着某种资格赋予一种角色，工作组也由用户组成，也可以由角色组成。这几个基本的对象以及其关系所构成的组织模型，已经可以满足轻量级工作流引擎对组织模型的需要了。⑵ 工作流定义模型

工作流定义模型描述了工作流模型的定义信息，包括工作流定义主信息，流程定义信息，环节定义信息，工作流附件信息，业务规则。它们之间的关系如下图：

图3.2 工作流定义模型结构

包含

包含

包含

包含

遵循

包含

工作流定义

附件信息

主信息

业务规则

环节

流程

包含

流程是包含若干环节的，而环节遵循一定的业务规则，再加上工作流主信息和附件信息，共同构成工作流定义模型。⑶ 工作流实例模型

工作流实例模型描述了工作流模型实例化时的信息，通过这些信息我们可以知道实例过程中的各种状态变化和最终的结果，因而得到一个业务具体应用的情况。它包括流程实例，环节实例，工作流实例信息，工作项信息和转换条件，它们之间的关系如下图：

记录

记录

细化

细化

影响

影响

影响

影响

记录

记录

转换条件

环节实例信息

流程实例信息

工作项信息

工作流实例信息

日志信息

日志信息

细化

图3.3 工作流实例模型结构

转换条件影响工作流实例，流程实例，环节实例和工作项的状态，并由转换条件去决定它们的状态转变，工作流实例信息à流程实例信息à环节实例信息à工作项信息，自上而下逐层细化，不但从全局了解业务运行情况，而且从局部了解业务运行的细节情况。而它们的状态改变都会记录在日志中，用以追踪工作流实例的运行情况。⑷ 外部支持模型

外部支持模型在本文只包括一个对象，就是需激活的外部应用程序，严格来说这不是工作流模型的一部分，可是提供接口去激活所需的外部应用程序为工作流管理系统提供支持是工作流模型的功能之一。有了这些外部应用程序的支持，我们的工作流管理系统的功能才变得更完善。

3.1.2.2 各个模型之间的逻辑关系

不但模型中各个对象有一定的逻辑关系，而且各个模型之间也有一定的逻辑关系，如下图所示：

调用

依赖

使用

使用角色和工作组

用户定义

工作流实例模型

外部支持模型

工作流定义模型

组织模型

图3.4 模型之间的关系

组织模型的用户定义工作流定义模型；工作流定义模型使用组织模型的角色和工作组，用来规定工作流模型的启动条件和任务分配条件，因为工作流模型的启动和任务的分配必须由一定的角色或工作组完成；工作流实例模型依赖工作流定义模型，同时使用组织模型的所有对象，并且调用外部支持模型为其提供支持。3.1.3 工作流实例，流程实例，环节实例和工作项的状态转换

工作流实例，流程实例，环节实例和工作项从不同的层次去描述业务运行过程的具体情况，不同级别的用户可以看到业务运行的不同方面，创建工作流实例的用户可以看到工作流实例信息以及其状态转换，参与该工作流实例的用户可以看到工作项信息以及其状态的改变，系统管理员可以看到所有信息以及其状态的转换。

⑴ 工作流实例状态图

创建

管理员

管理员

管理员

Running（运行）

Completed（结束）

正常情况

Suspended(挂起)

terminated(终止)

Initial（初始化）

图3.5 工作流实例状态图

提交

⑵ 流程实例状态图

管理员

管理员

管理员

Running（运行）

Completed（结束）

正常情况

Suspended(挂起)

terminated(终止)

图3.6 流程实例状态图

⑶ 环节实例状态图

处理中

接受

完成正常处理

没有完成异常处理

回退处理

提交给下一环节

图3.5 环节实例状态图

⑷ 工作项状态转换图

等待操作

完成 通过

没有完成 不通过

无操作，超时

操作下一工作项

回退处理

已查看

初始化

未审批

未查看

图3.5 工作项状态图

接受

3.1.4 任务分派任务分派是工作流引擎的一个重要功能。当环节实例产生时，就会以一定的准则把需要处理的工作当作一项任务项（工作项）分派给参与该环节实例的所有用户，而这些用户是同属一个角色或者工作组的。我们又把角色和工作组进行细化，可以得到以下准则： ⑴ 基于部门的：这就是说把任务分派到某个部门的所有人员，该部门的所有人员都参与了该项任务，因而会为该部门的所有人员都产生一个工作项；

⑵ 基于职位的：这就是说把任务分派到某个职位的所有人员，同属该职位的所有人员都被分配到一项工作项；

⑶ 基于部门职位的：这就是说把任务分派到某个部门的某个职位的所有人员，同属该部门的该职位的人员都被分配到一项工作项；

⑷ 基于所有人的：这就是说把任务分派到该企事业的所有人，该企事业的所有人都被分配到一项工作项；

⑸ 基于工作组的：这就是说把任务分派到该企事业的某个特定的工作组上，同属该组的所有人员都被分配到一项工作项。

基于部门的，基于职位的，基于部门职位的和基于所有人的这四种类型，其实是基于角色的细化，通过这些准则的分类，我们尽量做到系统与企事业有较强的适应性，以及使系统在任务分派时有较大的灵活性。3.1.5 转换条件的满足

工作流实例，流程实例，环节实例和工作项的状态转换有各自特定的条件，分别如下：

⑴ 工作流实例的转换条件

工作流实例从整体看业务运行过程，工作流实例被用户创建后就进行初始化并提交给工作流引擎，由工作流引擎去处理，此时实例处于运行状态；在运行过程中，它会根据流程实例的状态而不断进行本身的状态改变；当管理员由于某种原因要挂起它时，它就处于挂起状态，直到管理员重新激活它使它处于运行状态或者终止它使它非正常结束；当它被正常处理完毕后，就正常结束。

⑵ 流程实例的转换条件

流程实例也从整体看业务的运行过程，流程实例在工作流实例初始化时就开始它的工作。在运行过程中，它会根据各个环节的完成程度来改变自己的状态，当所有环节实例都正常完成它就正常结束；管理员可能要挂起它使它处于挂起状态，直到管理员重新激活它使它处于运行状态或者终止它使它非正常结束。

⑶ 环节实例的转换条件

环节实例从某个方面看业务的运行过程，环节实例在流程实例运行时就开始它的工作处于处理中状态。之后环节实例的状态由两方面决定，一是工作项的处理结果，一是业务规则的规定。

●

如果业务规则是自动型的，不管工作项的处理结果怎样，当系统把任务项分派（给特定用户）完毕后，该环节实例就正常完成处于正常结束状态；

●

如果业务规则是与聚合的，系统分派完任务项后，当所有参与人员都正常处理完该环节各自的工作项后，该环节才正常完成处于正常结束状态；在处理过程中，只要有一个工作项是非正常处理的，该环节就非正常完成处于非正常结束状态；在处理过程中，有工作项还未被处理并且没有一个工作项被非正常处理，那么环节实例仍然处于处理中状态；

●

如果业务规则是或聚合的，系统分派任务后，只要有一个工作项是正常处理的，该环节实例就正常完成处于正常结束状态；如果所有同属该环节实例的工作项都被非正常完成，那么该环节实例就处于非正常结束状态；

●

如果业务规则是投票聚合的，系统分派任务后，统计工作项的完成程度，当正常完成的工作项数量达到一定数量时，该环节实例就正常完成处于正常结束状态；当正常完成的工作项数量不达到规定的数量时，该环节就非正常完成处于非正常结束状态；当所有工作项还没处理并且正常完成的工作项还没达到规定数量时，该环节实例仍然处于处理中状态。

⑷ 工作项的转换条件

工作项从更细节的方面看业务运行过程，工作项的状态转换要看参与人员对各自的工作项的处理情况和业务规则的规定。我们把与聚合，或聚合和投票聚合这些要人工干预的规则统称为人工型规则。

●

如果业务规则是自动型，同属该规则的工作项的状态就只有正常处理后的正常结束状态，当然如果对该工作项还没被处理则处于处理中状态，可这不对环节实例等产生影响；

●

如果业务规则是人工型，就会有正常处理和非正常处理两种情况，正常处理该工作项则使到该工作项处于正常结束状态，非正常处理该工作项则使到该工作项处于非正常结束状态。

3.2 系统结构

本着基于轻量级工作流引擎的原则，我们已经对工作流模型进行了详细的分析和详细的设计，在这里我们就提出一个系统结构，如下图所示：

工作流定义器

工作流

解析器

实例调度中心

任务管理器

任务分派器

启动控制器

工作流定义数据

工作流实例 数据

日志 数据

工作流定义接口

工作流实例接口

组织定义

数据

组织定义接口

组织定义器

状态转换器

组织

管理器

图3.6 工作流引擎系统结构图

从图中可以知道，系统提供了三类接口：组织定义接口、工作流定义接口和工作流实例接口。这三类接口实现了工作流模型的接口一，接口二，接口三和接口五规定的主要功能；系统有一个实例调度中心，这是一个很重要的部件，它控制工作流实例的运行，通过工作流解析器对该工作流模型进行解析其含义，通过任务分派器按照一定的分派准则把任务项分派给参与该工作流实例的用户，通过任务管理器管理各个任务项的信息，通过启动控制器控制工作流的启动权利和启动信息，通过状态转换器控制工作流实例、流程实例、环节实例和工作项的状态转换；组织定义器定义企事业的组织结构；工作流定义器定义工作流模型信息，并通过组织管理器得到组织定义信息，为工作流模型提供组织支持。各个部件处理的相关信息都保存在数据库中。

3.3 系统模块的划分

根据功能实现的不同我们进行模块的划分如下：

⑴ 用户管理模块：对用户信息的管理，包括注册用户信息，注销用户信息，查询用户信息等功能；

⑵ 部门管理模块：对企事业部门结构信息的管理，包括增加部门信息，删除部门信息，查询部门信息等等功能；

⑶ 职位管理模块：对企事业职能信息的管理，包括增加职位信息，删除职位信息，查询职位信息等等功能；

⑷ 角色管理模块：对企事业某种技能信息的管理，包括新增角色信息，删除角色信息，查询角色信息等等功能；-

⑸ 工作流模型管理模块：对工作流定义模型信息的管理，包括定义新的工作流模型信息，删除旧的工作流模型信息，查询工作流模型信息；

⑹ 工作流实例管理模块：对工作流实例信息的管理，包括启动一个新的工作流实例，查询工作流实例信息，按照一定的业务规则生成新的环节实例信息，为用户分派工作项，管理工作项信息，按照一定的转换条件为工作流实例、环节实例转换状态等等功能；

⑺ 系统监控模块：为工作流实例，环节实例等的状态转换信息加入日志，挂起、激活工作流实例，强制结束工作流实例，为迟迟不对自己的工作项进行处理的用户发出提醒或警告信息，查看各个工作流实例的完成程度等等功能。

功能模块的划分，为系统的实现做好充分的准备。

3.4 数据库设计

基于轻量级的工作流引擎的特点之一就是把系统相关的资料，如工作流模型定义信息，工作流实例信息，组织模型定义信息等等，都以特定的实体形式保存在关系型数据库中。

⑴ 工作流定义主信息表（workflowTable）

静态定义工作流主要信息，包括该工作流的标识ID（可以定义为以”WORKFLOW_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自动生成的序号），工作流名称，工作流描述，工作流类型（工作流的类型有自动型，人工型和混合型，自动型不需要人工参与，由工组流引擎自动执行，人工型需要人工参与，混合型包含了自动型和人工型），工作流创建日期，工作流创建者ID（即用户ID），工作流创建人名称（即用户名），工作流生命周期（每个工作流实例都有它的生命周期期限，在该期限内还没完成它的工作就直接死亡），目前该工作流实例数目（记录当前工作流实例数目），工作流启动者角色（指明该工作流可以由哪个角色发起，属于该角色的用户都可以启动该工作流模型对应的实例）。工作流重要信息还包括两方面，一是工作流附件，因为在工作流进行过程中，肯定会带有一些信息，这些信息对于出差申请来说就是出差申请表，对于公文流转来说就是以word文档形式的公文，对于通知来说可能就是以文本文档形式的通知书，等等；一是工作流流程描述，包括若干个环节（activity），这些环节有一定的顺序，表现工作流顺序执行的特征。把工作流附件和工作流流程描述从工作流定义分离出来，是基于工作流附件和工作流流程描述对于不同工作流有不同形式和数量的原因，有利于工作流附件和工作流流程描述的扩展。⑵ 工作流附件信息表（workflowAttachmentTable）

静态定义工作流所需要的附件，包括附件ID（可以定义为以”Attachment_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自动生成的序号），工作流ID（标识属于哪个工作流），附件类型（表或文件），附件名称（如果类型是表，则为该表的名称，如果是word文档，则为该文档名称，如果是文本文档，则为该文件名称），其它信息（如果类型为表格，该字段以一定的格式保存该附件表格的所有字段的各种信息，包括字段名称，字段数据类型，数据类型长度，字段描述）。⑶ 工作流流程描述表（workflowProcessTable）

静态定义工作流的流程，由若干环节（activity）组成，一个环节为一条记录，包括工作流ID（环节所属工作流ID），环节ID（可以定义为以”ACTIVITY_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自动生成的序号），环节名称（即该环节名称），环节描述（对该环节的具体描述），参与者角色ID（将相同权限的用户作为一个集合，在数据库以同一个角色操作数据库特定操作，该项标识角色ID），环节任务分派规则，上一个环节ID（保存上一个环节的ID，由这项可以判断该环节是否整个流程的开始环节，或者该环节的任务没有完成（审批不通过，或没在其生命周期期限内完成）时作回滚处理的重要数据项，根据这个数据项可以回滚到上一个环节），下一个环节ID（保存下一环节的ID，由这项可以判断该环节是否整个流程的结束环节，或者该环节的任务完成了，根据这个数据项可以启动下一环节，继续向前推进）。

⑷ 工作流实例启动描述（workflowInstanceStartUpTable）动态定义工作流实例启动信息（其实这也是工作流实例信息表）启动者在产生一个工作流实例之前必须根据工作流的定义做好准备工作，这些准备工作的信息就填入该表中，然后交付给工作流引擎。该描述包括工作流ID（所属工作流ID），工组流实例ID（标识该工作流实例，可以定义为以”WORKFLOWINSTANCE_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自动生成的序号），工作流实例描述，工作流实例创建时间，工作流实例创建者ID（启动者ID），工作流实例创建者名称，当前工作流状态（标识当前工作流实例的状态，启动者在创建后却没提交给工作流引擎前的状态为“initialized”初始化状态，之后的状态要视工作流类型而定），当前状态具体描述，当前操作者ID（当前工作流要被谁操作），当前操作者名称。工作流实例完成标志（标识该工作流实例的完成），工作流实例完成时间，当前工作流状态和当前操作者ID和当前工作流状态具体描述三项在工作流实例的运行过程中，可以动态追踪该工作流实例的运行，而这三项再加上工作流完成标志和工作流完成时间，可以知道该工作流实例的完成情况。

⑸ 工作流实例过程描述（workflowInstanceProcessingTable）以环节为单位动态描述工作流实例的处理过程，启动者创建工作流实例后，提交给工作流引擎后，工作流实例就根据工作流定义的流程进行运转了。包括工作流实例ID，工作流实例所对应环节（工作流流程就是由一系列的环节组成，按照预定义的流程一个环节过渡到另一个环节），当前该环节所处状态（这标识着该环节在处理过程中的状态，最终状态表示该环节的完成状态），当前操作者（对应的是角色），当前状态具体描述。⑹ 工作项描述（workItemTable）

动态描述已经参与该工作流实例处理的参与者（对应已处理环节的角色的每个用户）的工作情况。包括工作项ID（可以定义为以”WorkItem-_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自动生成的序号），工作项名字，工作项描述，工作流实例ID（该工作项所属的工作流实例），该环节任务分派规则（继承环节的任务分派规则，用于判断该环节任务完成方式），当前该工作项所处状态（根据不同的工作流类型有不同的状态，根据这些状态可以在参与者接口上显示不同的工作项列表），执行动作（记录执行者会对该工作项执行怎么样的动作，如果是申请事务则是审批通过或审批不通过），执行时间（记录该执行动作的时间），用户ID（标志该工作项是属于谁的。⑺

用户描述（UserTable）

该表描述所有用户的资料，包括用户ID（可以定义为以”User-_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自动生成的序号），用户名称，用户密码，用户所属部门，职位等等信息，级别是该用户的系统权限，包括普通职员，高级职员和系统管理员。⑻ 日志信息描述（LogTable）

描述用户的工作日志，便于对各种操作进行追踪。包括日志ID（可以定义为以”Log-_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自动生成的序号）等等，其中有一项是相关工作项ID，这是当参与者对原始工作项进行执行操作动作时的工作项。⑼ 角色信息（RoleTable）

描述角色的信息，包括角色ID（可以定义为以”Role__xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自动生成的序号），角色名称，部门名称，职位名称，角色描述。角色由部门和职位组成。

⑽ 部门信息（DepartmentTable）

描述部门的信息，包括部门ID（可以定义为以” Depatment_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自动生成的序号），部门名称，部门其它信息。

⑾ 职位信息（PositionTable）

描述职位的信息，包括职位ID（可以定义为以” Position_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自动生成的序号），职位名称，职位其它信息。

除了以上这些主要表以外，还有一些我们是在定义工作流模型的时候才加入数据库的，如对应工作流附件类型为表的表格。为了减少网络流量和提高系统的运行速度，我们把一些有关联的数据库操作写成存储过程：

⑴ 删除工作流模型存储过程：删除一个工作流模型，必须删除它的工作流定义主信息，同时删除对应的附件信息，附件为表的表格，环节信息；

⑵ 创建附件类型为表的表格：定义附件信息时已经把该表格的字段信息保存在该附件信息的其它信息字段中，并且有一定的格式，那么我们从该字段中按照一定的格式还原表格的字段信息，并根据这些信息在数据库中创建该表格。

3.5 类的设计

用面向对象的方法和UML建模工具，再根据系统结构图，模块的划分和数据库的设计，我们把对象转化成类，进行类的设计。我们把整个系统的类分成三部分，一是实体类，二是业务类，三是接口类。

3.5.1 实体类的设计

工作流模型的对象就是一个一个的实体，实体类又分为数据库访问类和值对象类。数据库访问类是对存储在数据库的实体信息进行访问（插入，删除，更新，查询）的类，值对象类是在客户端和服务器端之间交换资料的实体信息类。

3.5.1.1 数据库访问类

⑴ 数据库连接类：该类是其它数据库访问类的父类，管理数据库的连接，负责从数据库连接池找可用的数据库连接给其它数据库访问类使用，使用完毕后负责放回连接池，类图如下图：

说明：属性只有一个connection，它代表数据库的一条连接，类型为Connection，方法有一个构造函数workflowDAO()和一个关闭连接的函数closeConnection()。WorkflowDAO()实现从数据库连接池找一个可用连接并赋值给属性connection，closeConnection()负责把连接放回数据库连接池。

⑵ 工作流定义主信息访问类：对应数据库的工作流定义主信息表，该类封装了对该表格记录的各种操作，就是插入或删除一条工作流定义主信息，查询特定工作流定义信息或者所有工作流定义信息，类图如下图：

说明：构造函数WFDefineMainInfoDAO()调用父类构造函数，从数据库连接池中找一个可用的数据库连接（其它数据库访问类也一样）。

⑶ 工作流流程信息访问类：对应工作流流程描述表，该类封装了对该表格记录的各种操作，流程是由若干环节组成，就是插入或删除一条环节信息，查询同属于一个流程的环节信息等等，类图如下图：

说明：findWorkflowFirlstActivityInfo()函数负责找该工作流模型的第一个环节的信息，findWorkflowNextActivityID()负责根据当前环节ID找下一环节的信息。

⑷ 工作流附件信息访问类：对应工作流附件信息表，该类封装了对该表格记录的各种操作，就是插入或删除一条工作流附件信息，查询同属于一个工作流模型的附件信息。类图如下：

⑸ 工作流附件类型为表的信息访问类：对应工作流附件类型为表格的信息表，该类封装了该表记录的各种操作，就是插入或查询一条工作流附件类型为表格的具体信息，类图如下：

⑹ 工作流实例启动信息访问类：对应工作流实例启动信息表，该类封装了该表记录的各种操作，就是插入或查询一条工作流启动信息，查询同属于一个用户的工作流实例启动信息，更新部分字段信息，类图如下：

说明：selectFinishedWorkflowInstanceStartUpInfoVO()负责查询特定用户启动的并且已经完成的工作流信息，selectNotFinishedWorkflowInstanceStartUpInfoVO()负责查询特定用户启动的并且还没有完成的工作流信息，updateWFInstFinishedFields()负责在工作流实例结束时更新特定的字段信息，updateWFInstProcessingFields()负责在工作流实例运行工程中更新特定的字段信息。

⑺ 工作流实例过程信息访问类：对应工作流实例过程信息表，该类封装了该表格记录的各种操作，每一条记录实际上是一个环节实例，就是插入、删除或查询一条环节实例信息，查询指定工作流实例的所有环节信息，更新部分信息字段，类图如下：

说明：SetWFInstProcessingCurrentPerformerNumField()负责更新已经处理该环节实例对应的工作项的参与该环节实例的用户数目，updateWFInstProcessingFields()负责在环节实例处理过程中更新特定的字段信息。

⑻ 工作项信息访问表：对应工作项表，该类封装了该表格记录的各种操作，就是插入或删除一条工作项信息，查询工作项信息，更新工作项信息，类图如下：

说明：selectFinishedWorkItemVO()负责查询特定用户已经处理完毕的工作项信息，selectNotYetFinishedWorkItemVO()负责查询还没有处理的工作项信息，updateWorkItemFields()负责更新工作项在处理过程中的特定字段信息，isPerformedInWorkItemByUser()负责判断该工作项是否已经处理完毕。

⑼ 用户信息访问表：对应用户信息表，该类封装了该表格记录的各种操作，就是插入、删除或查询一条用户信息，查询特定角色对应的用户信息，类图如下：

说明：selectCountRS()负责统计同属于一个角色的用户数目。

⑽ 角色信息访问类：对应角色信息表，该类封装了该表记录的各种操作，就是插入、删除或查询一条角色信息，查询所有角色信息，类图如下：

⑾ 部门信息访问类：对应部门信息表，该类封装了该表记录的各种操作，就是插入、删除或查询一条部门信息，查询所有部门信息，类图如下：

⑿ 职位信息访问类：对应职位信息表，该类封装了该表记录的各种操作，就是插入、删除或查询一条职位信息，查询所有职位信息，类图如下：

⒀ 日志信息访问类：对应日志信息表，该类封装了该表记录的各种操作，就是插入、删除一条日志信息，查询特定的日志信息，类图如下：

3.5.1.2 值对象类

值对象类其实是一种数据结构，用于客户机和服务器之间的数据交换，也用于对象实例的数据传递，它有若干属性，可是很少方法，实例化后就对应数据库表的一条记录。

⑴ 工作流定义主信息值对象类：可以保存工作流主信息表的一条记录信息，类图如下：

⑵ 工作流流程信息值对象类：可以保存工作流流程信息表的一条记录信息，类图如下：

⑶ 工作流附件信息值对象类：可以保存工作流附件信息表的一条记录信息，类图如下：

说明：SetOtherInfo()负责以一定格式把工作流附件类型为表的表格字段信息保存在OtherInfo中，GetOtherInfo()负责从OtherInfo中以一定的格式还原工作流附件为表的表格字段信息。

⑷ 工作流附件类型为表的信息值对象类：可以保存工作流附件类型为表的信息表的一条记录信息，类图如下：

说明：tableName就是工作流附件类型为表的表格名称，fieldValue就是对应该表的一条记录的各个字段值，用可变长数组Vector保存下来。

⑸ 工作流实例启动信息值对象类：可以保存工作流实例启动信息表的一条记录信息，类图如下：

⑹ 工作流实例过程信息值对象类：可以保存工作流实例过程信息表的一条记录信息，类图如下：

⑺ 工作项信息值对象类：可以保存工作项信息表的一条记录信息，类图如下：

⑻ 用户信息值对象类：可以保存用户信息表的一条记录信息，类图如下：

⑼ 角色信息值对象类：可以保存角色信息表的一条记录信息，类图如下：

⑽ 部门信息值对象类：可以保存部门信息表的一条记录信息，类图如下：

⑾ 职位信息值对象类：可以保存职位信息表的一条记录信息，类图如下：

⑿ 日志信息值对象类：可以保存日志信息表的一条记录信息，类图如下：

⒀ 信息集合值对象类：可以保存各种信息的一个集合，当需要返回多条记录信息的时候可以使用该类，类图如下：

说明：只有一个属性，是一个可变长数组，可以存放不定数量的记录信息。3.5.2 业务类的设计

业务类，其实就是边界类，它根据系统的需求按照一定的方式把各个实体类联系起来，以实现系统的各种功能。按照实现功能的不同我们可以分为用户管理类，角色管理类，部门管理类，职位管理类，工作流模型管理类，工作流实例管理类，系统监控管理类。

⑴ 用户管理类：负责用户的注册，注销，检测合法性，查找用户信息，类图如下：

⑵ 角色管理类：负责新增加角色，删除角色，查找角色信息，类图如下：

⑶ 部门管理类：负责新增加部门，删除部门，查找部门信息，类图如下：

⑷ 职位管理类：负责新增加职位，删除职位，查找部门信息，类图如下：

⑸ 工作流模型管理类：负责工作流模型的定义，解析，类图如下：

⑹ 工作流实例管理类：负责工作流实例的创建，维护各种实例的状态信息，分派任务给用户，用户处理工作项等等的工作，类图如下：

说明：uploadAttachmentToServer()负责把工作流附件类型为文档的文档上传到服务器特定目录下。

⑺系统监控管理类：是一个综合类，主要通过调用其它管理类的功能来实现本身的功能，就是查看工作流实例的过程状态，完成程度，根据一定的条件有必要控制实例的挂起，激活，结束，查看各个参与用户的工作情况，在出现工作误时、意外、异常等等情况时采取一定的措施保证整个实例的完成。而所有这些都保存在日志中。

3.5.3 接口类的设计

接口类是工作流引擎提供给外部应用的类，应用系统通过调用这些类，来实现一定的应用功能。我们在接口类的设计上，采取格式统一、隐藏系统复杂性、功能调用方便的原则，尽量为外部应用系统提供简洁、易懂的功能调用接口。因而我们把这些类都设计成只有一个业务类实例，一个ToDoWhat()方法的类，并且每一个业务类对应一个接口类。在这些接口类中，业务类实例作为它的一个数据成员，ToDoWhat()方法有两个参数，toDoCode（工作代码）和object（数据交换对象），工作代码表示要调用的功能的标识，数据交换对象表示功能调用要处理的数据（应用数据）。从本质上来说，就是根据不同的工作代码调用业务类实例的不同方法，对各种应用数据进行处理。

第四章

系统实现系统的实现主要包括关键问题的解决方案和一个工作流管理应用系统的实践。首先提出关键问题，然后给出解决方案，最后提出一个应用架构，利用J2EE技术和数据库技术实现一个基于轻量级工作流引擎的简单工作流管理应用系统。

4.1 关键问题的解决方案

在实现工作流引擎的时候，有一些关键问题，例如启动工作流实例，推动工作流实例的进程，类型为文档的附件的处理等等，都是要重点解决的。4.1.1 启动工作流实例

当根据各种业务需求创建了对应的工作流模型，根据结构组织情况创建了组织模型后，用户就可以创建工作流实例并启动它。用户把工作流实例的信息提交给工作流引擎，那么工作流引擎如何工作呢？工作流引擎其实做了一系列的工作，其处理过程如下：

⑴ 工作流引擎得到用户创建的工作流实例数据，记录在工作流实例启动信息表中；

⑵ 工作流引擎解析对应该工作流实例的工作流模型的含义，获得必要信息提供给工作流实例使用；

⑶ 工作流引擎根据这些必要信息找到工作流模型对应流程的第一个环节信息，并生成该工作流实例的第一个环节实例，记录在工作流实例过程描述表中；

⑷ 工作流引擎根据任务分派原则开始把任务项分派给参与该环节实例的所有用户；

⑸ 工作流引擎根据该环节定义的参与者角色，找出所有同属于该角色的所有用户，为各个用户都生成一个工作项，记录在工作项信息表中，工作项要继承该环节定义的业务规则，完成任务的分派；

⑹ 工作流引擎根据该环节定义的业务规则，如果该环节是自动型的，则为该环节的参与用户分派完任务后立刻就根据该环节信息去找下一个环节的信息，进行下一环节实例的处理；如果该环节不是自动型的，是需要人工参与处理的，则工作流引擎暂停该工作流实例的处理工作，等待参与用户处理的结果；

⑺ 启动工作流实例的工作结束。

4.1.2 推进工作流实例的进程

⑴ 如果上一环节定义的业务规则是自动型的，则立刻根据当前环节信息查找下一环节；

⑵ 如果上一环节定义的业务规则是不是自动型的，则等待参与用户对各自的工作项进行处理，当每一个用户处理完后，工作流引擎都要判断该环节实例是否结束，结束的条件是业务规则的规定和用户的处理结果。

①

如果业务规则是与聚合，当当前用户的处理结果是非正常处理的话，该环节实例就结束，并且该工作流实例也结束，通知其他还没处理的用户该环节已经结束，并记录在相应的数据库表中；当当前用户的处理结果是正常处理的话，则再判断是否所有参与的用户都处理完毕，如果是则结束该环节，通知其他用户该环节已经结束，并记录在相应的数据库表中，然后查找下一环节，如果不是则等待其他还没处理的用户的处理结果。

②

如果业务规则是或聚合，当当前用户的处理结果是正常处理的话，该环节的实例就结束，并且该工作流实例也结束，通知其他参与还没处理的用户该环节实例已经结束，记录在相应的数据库表中，然后查找下一环节；当当前用户的处理结果是非正常的话，则等待其他还没处理的用户的处理结果。

③

如果业务规则是投票聚合，当当前用的处理结果是正常处理的话，则使统计正常处理结果的计数器加一，然后判断该统计数量是否已经达到规定的数量，如果是则结束该环节实例，并通知其他还没处理的用户该环节实例已经结束，记录在数据库表中，然后查找下一环节；当当前用的处理结果是非正常处理的话，则不统计，等待其他还没处理的用户的处理结果。

⑶ 当前环节实例结束后，工作流引擎就找下一环节处理，如果没有下一环节，则结束该工作流实例，记录在数据库表中，如果还有环节，则同样生成环节实例，进行任务分派，等待环节实例的结束。工作流引擎就是这样推进工作流实例进程，从一个实例环节到下一个实例环节，直到工作流实例结束为止。

4.1.3 类型为文档的附件的处理

对于文档形式的附件，我们采用上传文件到服务器的方法，用户编辑好文档后，以规定的文件名上传到服务器中特定的目录中，当用户要查看该文档时，工作流引擎会根据该附件文档对应的信息得到其文件名，用户根据该文件名下载到本地中，同时调用外部应用程序如work2000、记事本打开给用户浏览其内容。

4.2 一个简单工作流管理系统的实现

现在，我们利用J2EE技术把工作流引擎开发出来，并基于该引擎做一个简单的应用系统，以证明系统设计的可行性。我们用Jbuilder9.0做开发工具，用MS SQLSERVER2000做数据库管理系统。4.2.1 系统应用框架

工作流实例管理器

工作流模型管理器

组织管理器

系统监控器

工作流引擎

应用服务器

数据库

Web界面

文档管理系统

图4.1 系统应用框架

4.2.2 J2EE相关技术的应用

J2EE为多层Web应用系统提供了容器平台，用J2EE技术把工作流管理系统开发成一个多层Web应用系统，是最合适不过了。

4.2.2.1 J2EE核心模式和类的实现

模式是特定问题的可重现的解决方案，使用模式有莫大的好处。模式可以权衡已经被证实的解决方案，为交流提供一个共同的词汇，约束解决方案的范围。J2EE核心模式是在J2EE平台上应用的模式，它在表示层，业务层，集成层都有特定的模式，为基于J2EE平台的开发提供很好的解决方案。对类的实现我们采用了J2EE核心模式，主要运用的核心模式是业务层的ValueObject（值对象）和集成层的DAO（DataAccessObject，数据访问对象）。

⑴ 值对象：基于多层应用架构的系统，客户端和服务器端往往有大量的数据交换，而且客户端调用的方法都是远程的，不是本地的，为了减轻网络负载，提高应用程序的性能，用值对象封装业务数据，在客户端和服务器端进行数据交换。因而我们把所有工作流对象都用值对象表示，像工作流定义主信息值对象类（WFDefineMainInfo）。在这些值对象中，所有属性和方法都是声明为公共的，并且很少方法，很多属性，这些属性就是对应的工作流对象的属性，也对应了数据库中表的某个字段。

⑵ 数据访问对象：基于关系数据库技术的系统，会对数据库进行频繁的访问，数据库表的众多，对某个表操作的方式的众多，如果不对这些表和表的操作方式进行必要的归类，只会造成模块聚合度的降低，代码混乱的后果。我们使用数据访问对象，来抽象和封装对数据库的访问，所有涉及到数据库访问的情况都使用数据访问对象去实现。工作流对象的所有数据都保存在数据库中，我们为每个对象数据的数据库操作都封装在数据访问对象中，像工作流定义主信息访问类（WFDefineMainInfoDAO）。4.2.2.2 JavaBean技术与类的实现

JavaBean是基于Java技术的软件构件模型，它是Java语言编写的可移植的不依赖于平台的软件构件模块。我们把系统所有的类都实现为一个一个的JavaBean，提高类的可重用性，有利于日后的功能扩展。另外，JavaBean应用到JSP中，可以为JSP应用带来更好的可伸缩性。

4.2.2.3 JBOSS应用服务器和工作流引擎的实现

应用服务器我们采用JBOSS，这是一个免费的产品，它提供数据库访问（JDBC）、命名机制（JNDI）服务等服务，支持数据库连接池、实例连接池，这些为我们的工作流引擎的实现提供了支持，给系统开发带来很大的方便。

⑴ 对数据库访问的支持：JBOSS通过对特定数据库管理系统的配置（XML文件），并实例化对数据库的若干连接，放进数据库连接池中，提供给系统使用。在JBOSS运行过程中，对这些数据库进行有效的管理，减轻了工作流引擎的工作负担。①

配置方法 mssql-ds.xml文件：

MSSQLDS/* 数据源名字 */

jdbc:microsoft:sqlserver://localhost:1433;DatabaseName=WorkflowDB /* 连接URL，包括服务器

地址，数据库名称 */

com.microsoft.jdbc.sqlserver.SQLServerDriver /* sqlserver驱动 */

workflowUser /* 用户名称 */

123456 /* 用户密码 */

②

调用方法（使用JNDI机制）部分代码：

InitialContext ctx = new InitialContext();//初始化上下文

DataSource ds =(DataSource)ctx.lookup(“java:/MSSQLDS”);

//根据数据源名字查找已经配置好的数据源

Connection conn = ds.getConnection();

//调用该方法可以得到对数据库的一条连接，而这条连接已经被JBOSS初始化，实际上是从数据库连接池中找到一条可用的连接而已，然后通过该连接就可以对数据库进行各种操作，操作完毕后不用显式关闭，JBOSS会自动回收该连接，把该连接重新放入连接池中。

⑵ 对对象实例化的支持

当系统第一次生成某个对象实例时，JBOSS就对该实例进行管理，把该实例放入实例池中，并不释放它，当系统再次要生成该实例时，不再进行该对象的实例化，而是JBOSS从实例池中找到该实例并提供给系统使用，这明显提高系统运行速度。

⑶ 对线程的支持

当不同的用户登陆系统，并且对系统所有功能的使用，JBOSS会为每个用户分配一个线程去为他们工作，这些线程放入线程池中，JBOSS在运行过程中始终对这个线程池进行管理，提高系统的并发性能。

4.2.2.4 Jsp/Servlet技术和系统界面的实现

JSP技术可以方便的建立动态Web页面，提供一个友好的用户界面，并且很方便的调用JavaBean，完成复杂的业务功能；Servlet提供在Web进行请求和响应服务的功能，客户端对服务器提供的服务的所有请求和响应都通过Servlet实现。JSP最终解析为Servlet。

⑴ JSP调用JavaBean

下面是创建工作流定义主信息的JSP页面部分代码：

class=“wfsystem.interfacepack.client.workflowManager” />

„

<%

WFDefineMainInfo wfDefinemaininfo =new WFDefineMainInfo();

„ // 填充工作流定义主信息值对象WFDefineMainInfo 实例

wfManager.ToDoWhat(0,(Object)wfDefinemaininfo);//调用接口类的方法，0对应创建工作流主信息的方法代码

%>

⑵ Servlet请求和响应服务 下面是请求得到表单信息（这些信息就是工作流定义主信息值对象的内容）部分代码：

<%

String workflowname = request.getParameter(“workflowname”);

String workflowDesc = request.getParameter(“workflowDesc”);

//request就是请求对象，调用其方法getParameter()可以得到表单的信息

„ //一个一个的得到信息

%>

下面是响应用户的部分代码：

<%

response.sendRedirect(“defineWorkflowModel-mainInfo.jsp”);// response就是响应对象，调用其方法sendRedirect()向用户发送一个页面重定向的应答。

%>

4.2.3 具体编码实现

接下来的工作就是编码工作，以Jbulider9.0作为开发工具，以VSS（Microsoft Visual SourceSafe6.0）作为版本控制工具，进行代码编写，进行单元测试，综合测试，最后得到一个基于轻量级工作流引擎的简单的工作流管理系统。

第五章

系统的不足

本文探讨的轻量级工作流引擎，尽管有很多的优点，可是它从够用、灵活和低成本的设计原则出发，不追求工作流引擎的功能的完备和复杂，所以存在着一些不足：

⑴ 不支持复杂业务：本文探讨的轻量级工作流引擎是从一般业务的需求设计工作流模型，我们只实现了活动的单分支，就是组成工作流流程的活动是一个活动只有一个后续活动，而复杂业务可能一个活动后面出现多分支，有多个后续活动，形成一个树型的结构。所以对复杂业务的不支持是本文探讨的工作流引擎的最大的不足。

⑵ 不支持复杂的组织结构：本文探讨的工作流引擎只是以职能型的机构模型去描述组织结构，主要以部门和职位组成一个角色，任务分配也只是按照部门和职位的不同组合去分配，可是复杂的组织结构模型可以定义多重角色，临时工作组等等。

⑶ 不支持提供内建（built-in）的应用开发工具，例如是可视化工作流建模工具，FORM设计工具，这些在本文探讨的工作流引擎都没有实现一定的接口。

⑷ 在定义应用数据方面不支持所有数据类型和完整性维护，只支持字符型类型和进行一些简单的数据保存工作。

⑸ 没有完善的异常处理功能。对异常的捕捉和处理并不完善，没能及时把错误信息显示给用户。

⑹ 没有完善的事务控制功能。只实现了一些简单的事务控制，没有对复杂事务的控制。

第六章

总

结本文主要探讨了轻量级工作流引擎的设计与实现，首先我们要了解有关工作流技术的相关知识，然后说明开发轻量级工作流引擎的原因，再从企事业一般业务需求入手，抽象出工作流对象，分析其之间的逻辑关系，组成工作流模型，跟着提出一个系统结构，进行模块划分，数据库设计，类的设计，最后利用J2EE技术，用MS SQLSERVER2000作后台数据库，Jbuilder9.0作开发工具，VSS作版本控制，实现工作流引擎的开发，并基于该工作流引擎作一个简单的应用系统，最终实现为一个工作流管理系统。该管理系统的正常运行，充分体现了轻量级工作流引擎在企事业业务的开发过程中的价值。参考文献[1] 范玉顺著，《工作流管理技术基础》，清华大学出版社 [2] Deepak Alus等著，《J2EE核心模式》，机械工业出版社 [3] 王克红等著，《Java技术教程（中级篇）》，清华大学出版社

[4] Wendy Boggs等著，《UML With Rational Rose从入门到精通》，电子工业出版社

[5] Borland公司著，《Borland Jbuilder实用技术手册》，电子工业出版社 [6] 何清法等著，《基于关系结构的轻量级工作流引擎》，中国科学院计算技术研究所 [7] Joseph L.Weber著，《Java 2 编程详解》，电子工业出版社

本文来自CSDN博客，转载请

标

明

出

处http://blog.csdn.net/hjt79/archive/2004/08/15/75484.aspx

：