跨部门的工作流引擎模式研究

刘恩海 李 甜 陈媛媛(河北工业大学计算机科学与技术系 天津 300401)

0 引 言

工作流是业务流程在计算机应用环境下的自动化，是各操作步骤之间业务规则的抽象、概括描述。工作流技术是电子政务的核心，是企业管理以及政府部门工作中不可或缺的部分。工作流管理系统的目标是使企业中大量基于知识与规则的任务和活动能够相互协调一致、高效运转[1]。

工作流引擎是工作流管理系统的核心，它与企业核心利益息息相关[2]。目前国内外的开源工作流有JBPM、Activiti、OSWorkflow等。由于这些工作流大多结构复杂、灵活性差，流程变更频繁，运维投入很大，在国内企业的使用情况并不理想，普及率也较低[3]。

本文基于工作流研究的现状，通过借鉴传统的工作流模型，开发了一套基于Web的跨部门工作流引擎。跨部门工作流引擎帮助企业解决各个部门和系统内部的任务自动化、数据集成、以及控制管理的难题，消除企业内各部门之间的隔阂，为跨部门的业务流程带来了出色的效率、灵活度、合规性、以及可监控性。

本文从数据表和ER图出发，对审核流程进行详细介绍，使后续开发者可以根据自身不同需求进行二次开发，设计出更适合自身需求的工作流，其原型已在廊坊市计量信息管理服务平台中应用。

1 工作流引擎模型的设计

工作流模型是对现实世界中业务过程的抽象，并用一种形式化的、计算机可处理的方式表示出来。工作流模型是工作流引擎执行的前提和基础，在进行工作流设计前必须先选定相应的工作流模型。

本文所设计的工作流引擎模型由两部分组成：工作流定义模块和工作流引擎模块。工作流引擎结构功能如图1所示。

图1 工作流引擎功能结构

在图1中，工作流定义模块负责工作流的定义、解释及维护；工作流引擎模块负责对整个工作流程及工作项的创建、激活、挂起、终止等行为进行监控, 控制工作项的状态转换逻辑[4]。

1.1 工作流的数据模型设计

工作流定义是工作流引擎中至为重要的一部分[5]。工作流节点设计是工作流定义的核心部分，不同组织给出了各自的工作流节点模型,比较著名的有:WFMC,WIDE,WAMO,Active Workflow[6]。

本文基于关系型数据库MySQL设计了数据模型，将区域、部门、岗位、节点、角色、用户等工作流引擎要素以及各要素间的逻辑关系通过数据表的形式来展现。工作流引擎通常使用数据来控制流程[7]。工作流节点设计为双向链表形式，以实现工作在工作流上能够上下移动。数据模型设计如图2所示。

图2 工作流引擎E-R图

本文所设计的工作流引擎模型中，工作流节点由工作流类型、区域类型、部门类型- 岗位共同决定，其中，为防止添加工作流节点时出现某部门没有该岗位的情况，部门类型- 岗位又需要由部门和岗位共同决定。另外，部门类型- 岗位表和用户- 部门- 岗位表为关联表，其作用是将部门、岗位、用户之间m∶n的逻辑关系处理为1∶n的逻辑关系，简化实际的代码编写。工作流引擎负责维护工作流，当用户修改工作流后，工作流引擎必须能够及时将改动后的工作流存入数据表，并确保逻辑关系准确无误。

1.2 工作流审核状态模型设计

申请人发起的申请从提交到审批的过程中，涉及到四种不同状态之间的转换：待办、在办、已办和搁置，工作状态由用户的操作触发得到转换。当一个申请被创建时，该申请进入“未办”状态；审核员点击查看工作，但未进行提交，该申请进入“在办”状态；审核人员进行搁置操作，进入“搁置”状态；审核员进行办结操作，申请进入“办结”状态[8]。工作的状态转换如图3所示。

图3 工作状态图

字段状态如表1所示。

表1 字段状态表

2 工作流引擎的实现

大部分开源工作流只提供同一部门审核功能，极少数工作流虽然可以实现跨部门审核功能，但又局限于同一主体。应用度最广的JBPM工作流引擎，从设计上就没有考虑“回退”、“取回”等业务场景。本文将不同主体视为同一主体下的部门，并结合搁置、退回、取回等实际情况，实现了跨主体审核的功能。本文中，每种申请类型对应不同主体，每个用户对应多种申请类型。用户提交申请之后，选择相对应的审核人。无论申请人的部门岗位如何复杂，都能够根据引擎模型准确查找到下一审核人。数据流图如图4所示。

图4 工作流引擎数据流图

在应用本工作流引擎的系统中，申请人需要将信息上传，选择合适的工作流之后，系统自动获取到正确的审核人供申请人选择，审核成功或者失败都需要将审核结果发送至申请员。如何获取到适合该申请人的审核流程，和选择审核流程之后如何精确查找下一审核人，是工作流引擎的关键所在。以本工作流引擎中已有的审核流程为例，如图5所示。

图5 审核流程交互活动图

以图示为例，省级管理部门受理工作申请时，根据情况判断当前申请是否合格。如合格，则进行办结操作，审核流程结束，消息反馈申请人；如不合格，则省级管理部门可选择将申请回退给上一审核人或申请人，即市级管理部门或县级技术机构，此时上级审核人修改审核意见或申请人修改申请，重新提交。

2.1 查找下一审核人

申请人发起申请后，流程具体如下：

(1) 申请人登录系统后，首先选择申请类型。系统根据用户选择的申请类型，获取申请类型id(apply_type_id)。

(2) 根据申请类型id从工作类型- 申请类型表中获得所有对应工作流类型id。

(3) 用户选择工作流类型，系统获取工作流类型id(workflow_type_id)。

(4) 根据工作流类型id(workflow_type_id)从工作流节点表中获取下一工作流节点。工作流节点表中每一条数据都记录了包括工作流类型在内的区域类型id、部门类型id、岗位id、部门类型- 岗位id以及上一工作流节点和下一工作流节点，当系统获取到工作流类型id时就能够获取到所有需要的信息。

(5) 由工作流节点获取到用户的区域类型，此时系统可以根据申请人当前区域类型获取上级区域类型信息。

(6) 在申请人的上级区域信息中寻找工作流节点表中的部门类型- 岗位信息，分别由部门类型和岗位找到部门信息和岗位信息。

(7) 由部门岗位信息找到当前部门岗位下的所有用户，如果有符合要求的审核人，则直接返回用户id(user_id)。

(8) 获取用户提交的申请信息。

(9) 将这一申请提交至下一审核人处。

以应用本文所设计的工作流引擎的系统为例，工作流申请活动图如图6所示。申请人提交工作，下一审核人查看工作之后可进行退回、搁置、同意操作，同意申请之后系统会判断是否存在下一审核人，若存在下一审核人，则同时更新本审核人工作记录并生成下一审核人工作记录，完成后将工作移交新的审核人，重复之前的判定步骤。

图6 工作流申请活动图

2.2 工作流的取回

当审核申请提交之后，如果想要修改申请，申请人可以进行取回操作。发起取回申请时，首先判断当前申请状态，是否有人进行了审核，如果已有人审核则不能进行取回操作；只有当申请为待办状态时，即工作流状态字段均为0的情况下才会进行取回操作。

取回过程代码摘要如下：

//获取USERID

＄userId = get_user_id();

//获取当前用户下的待办信息

＄map[′isClicked′] =′0′;

＄this->getMyJobByUserIdIsClickedIsCommitedIsShelved(＄userId, ＄map);

＄this->assign(′YZBODY′,this->fetch(′unfinished′));

＄this->display(YZTemplate);

//获取当前工作流节点信息

＄workflowNodeId = I(′get.id′);

if(!is_numeric(＄workflowLogId)‖empty(＄workflowNodeId))

{

＄this->_empty();

return;

}

//判断当前结点是否属于用户

if(＄workflowNode [′user_id′] !=＄userId)

{

＄this->error = ″当前结点并不属于当前用户″;

＄this->_empty();

return;

}

//更新工作表

＄workType=WorkflowType->where(workflowNodeId)->select();

＄workflowType->is_clicked=’0’;

具体流程如下：

(1) 申请人发起取回申请。

(2) 判断当前申请的工作状态字段表信息，“is_clicked”是否为0，如果是，则记录当前工作id。

(3) 根据工作id获取当前申请的工作流节点id。

(4) 根据工作流节点id获取当前工作流节点表信息。

(5) 将下一工作流节点信息置为0。

(6) 更新工作流表中链路信息。

工作流取回流程数据流图如图7所示。

图7 工作流取回数据流程图

2.3 工作流的退回

当审核人在审核过程中发现申请存在问题时，可以将申请退回。申请被退回时，系统首先判断是否存在上一审核人，如果存在，则审核人可以选择退回上一审核人或退回申请人：选择退回上一审核人，则工作流审核权交回上一审核人，上一审核人可以选择提出修改意见提交给下一审核人；或者选择退回申请人。

退回过程逻辑代码摘要如下：

elseif(＄type == 1)

{if(!＄WorkflowLogL->backToStart())

{

＄this->error =＄WorkflowLogL->getError();

＄this->_empty();

return;

}

}

具体步骤如下：

(1) 获取当前工作流的工作状态表信息；

(2) 重置当前工作流的工作状态表，将“is_clicked”和“is_commited”置为0；

(3) 获取当前工作流节点表信息；

(4) 判断上一工作流节点是否为根节点；

(5) 删除当前工作流下一节点信息；

(6) 更新当前工作流节点表中当前节点信息为根节点。

工作流退回流程如图8所示。

图8 工作流退回数据流图

2.4 工作流的删除

当审核申请提交之后，申请人发现存在问题较为严重无法修改时，可以将工作流删除，逻辑代码摘要如下：

//判断当用流程在当前用户下未提交

if(＄workflowLog[′is_commited′] == 1)

{E(″当前用户userId并不是当前审核结点id的待在办人″);

}

//判断申请人为当前用户

if(＄project[′user_id′] !=＄userId)

{E(″当前项目的申请人＄project[user_id]非当前用户userId″);

}

//删除所有节点表信息

＄WorkflowL->deleteByProjectId(＄projectId);

//删除工作状态信息

＄WorkflowLogL->deleteByWorkflowId(＄workflowId);

具体流程如下：

(1) 获取当前用户信息；

(2) 获取当前工作流状态表信息，判断当前状态节点是否为当前用户，“否”则无操作权限；

(3) 判断当前工作流状态，“is_committed”是否为0；

(4) 获取工作流节点表信息，判断当前节点是否为根节点，“否”则无操作权限；

(5) 删除当前工作流中节点表信息；

(6) 删除当前工作流中工作状态信息；

(7) 重置当前工作流关联数据表中信息为空。

删除操作流程图如9所示。

图9 删除流程图

2.5 工作流的审批

工作流提交之后，审核人可以对工作进行搁置、取消搁置、退回、提交下一审核人和办结操作。审批流程涉及到整体数据的流向，是工作流中最为复杂的一部分。流程图如10所示。

图10 审批流程图

具体流程如下：

(1) 获取当前用户信息(user-id)；

(2) 获取当前工作流节点表信息；

(3) 判断当前用户所在节点是否为根节点，是则当前用户为提交人，否则当前用户为审核人。

根据当前用户信息，系统判断用户可执行的下一步操作：

1) 当用户为申请人，步骤如下：

(1) 获取当前工作流适用的工作流类型表信息；

(2) 获取当前申请类型表信息；

(3) 根据申请类型和工作流类型信息获取工作流节点表信息；

(4) 选择下一工作流节点，生成工作流节点信息存入工作流节点表；

(5) 生成工作信息存入工作表。

2) 当用户为审核人，审核人可以对工作流进行提交、搁置、退回、办结等操作，根据不同操作，进行如下分类：

(1) 如果用户进行同意或办结操作：

① 获取工作流节点表信息。

② 判断是否为终节点：若为终节点，则获取工作表信息，将工作表中 “is_commited”字段置为1并存入工作表；若非终节点，则进行如下操作。

③ 获取当前工作流审核信息，判断当前用户是否在审核用户列表，如果“否”则提示无权限操作。

④ 获取当前工作流节点信息，将当前工作流节点存入下一节点信息。

⑤ 获取当前工作信息，将当前用户id存入工作信息表。

⑥ 更新工作信息表，将工作状态“is_commited”字段置为1。

(2) 如果用户进行的是搁置操作，逻辑代码摘要如下：

//查询是否为在办

＄map = array();

＄map[′id′] =＄workflowLogId;

＄map[′is_commited′] = ′0′;

if(＄WorkflowLogM->where(＄map)->find() == null)

{＄this->error =″该流程已办结，不适用搁置操作″;

＄this->_empty();

}

//更新搁置数据

＄data = array();

＄data[′id′] = workflowLogId;

＄data[′is_shelved′] = ″1″;

＄data[′commit′] = I(′post.commit′);

＄WorkflowLogM->data(＄data)->save();

具体步骤如下：

① 判断当前申请的工作状态是否为完结，即工作状态表中“is_commited”字段是否为1，若为1则证明工作已完结，返回提示信息。

② 如果“is_commited”字段为 “0”，更新当前工作流日志信息，即将“is_ abeyanced”字段置为“1”。

(3) 如果用户进行取消搁置操作，逻辑代码摘要如下：

//查询是否为待办，且已搁置

＄map = array();

＄map[′id′] =＄workflowLogId;

＄map[′is_commited′] = ′0′;

＄map[′is_shelved′] = ′1′;

if(＄WorkflowLogM->where(＄map)->find() == null)

{＄this->error = ″该流程已办结，不适用搁置操作″;

＄this->_empty();

return false;

}

//更新搁置数据

＄data = array();

＄data[′id′] = workflowLogId;

＄data[′is_shelved′] = ″0″;

＄data[′commit′] = I(′post.commit′);

＄WorkflowLogM->data(＄data)->save();

具体步骤如下：

① 判断当前申请的工作状态是否为搁置，即工作状态表中“is_ abeyanced”字段是否为1，如果为“0”则返回不存在搁置的提示信息；

② 更新当前工作流日志信息，将“is_ abeyanced”字段置为“0”。

3 结 语

一直以来工作流问题都是企业管理中的核心，良好的工作流能够使各部门在工作处理、审批过程中节省更多的人力，释放更多的资源，提高企业管理的工作效率[9]。目前跨部门工作流在国外已经有广泛应用，例如医疗系统中的挂号预约流程，启用工作流模型的预约系统相较普通预约系统效率提升40%～45%[10]。目前跨部门工作流还是以应用的方式集成于系统中，更长远的说，相同的工作流方法可以被应用于任何基于互联网的基础应用程序中[11]。

本文从数据流出发，详细阐述了整个申请流程中的数据转移情况，更加直观地将工作流问题以计算机形式说明，使工作流不再单纯地局限于书面表达。通过阅读本文，能够更加清晰地理解工作流的申请审核流程。在应用了本工作流的系统中，实现了对跨越不同部门和主体的业务流程的灵活控制，缩减了跨部门业务的响应时间，极大地降低了工作流的实现难度，简化了业务流程操作。本工作流适用于非常广泛的审核情况，并能够根据不同需求进行二次开发，方便对工作项目进行管理、分派，提高了工作效率。

[1] 蔡孝武, 韩永国, 蓝科. 一种轻量级工作流引擎的研究与设计[J]. 计算机工程, 2010, 36(20):78- 79.

[2] 杨明顺, 韩周鹏, 余婷,等. 一种轻型工作流引擎的设计与实现[J]. 西安理工大学学报, 2013, 29(1):20- 26.

[3] 徐新权，孟江涛，刘宏志，等. 基于 SAP 工作流引擎的应用[J].计算机应用, 2013，33( S2) : 251- 255.

[4] 路春光, 孟丽丽, 郝立文,等. 基于WEB的柔性工作流引擎的设计[J]. 微计算机信息, 2006, 22(15):21- 23.

[5] 葛中泽. 工作流引擎设计关键技术的实现[J]. 鄂州大学学报, 2015(5):107- 109.

[6] 徐亮, 张莉, 樊志强. 一种基于UML的实时工作流建模方法研究[J]. 计算机研究与发展, 2010, 47(7):1184- 1191.

[7] 侯培文, 刘军利. 轻型工作流引擎在工作流管理系统中的应用[J]. 电脑开发与应用, 2010, 23(2):46- 48.

[8] 朱春旭, 王小刚, 殷振华. JBPM4工作流引擎在科研项目管理系统中的应用研究[J]. 电子技术与软件工程, 2017(1):193- 195.

[9] 罗海滨, 范玉顺, 吴澄. 工作流技术综述[J]. 软件学报, 2000, 11(7):899- 907.

[10] Rahman M, Maccaull W. An Application Suite for Service Enabled Workflow[J]. Procedia Computer Science, 2016, 83:480- 487.

[11] George S, David K. Workflow Enabled data Processing in a Concurrent Engineering Environment[J]. Procedia Technology, 2016, 24:1643- 1650.