劉恩海 李 甜 陳媛媛(河北工業(yè)大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)系 天津 300401)

0 引 言

工作流是業(yè)務(wù)流程在計(jì)算機(jī)應(yīng)用環(huán)境下的自動化，是各操作步驟之間業(yè)務(wù)規(guī)則的抽象、概括描述。工作流技術(shù)是電子政務(wù)的核心，是企業(yè)管理以及政府部門工作中不可或缺的部分。工作流管理系統(tǒng)的目標(biāo)是使企業(yè)中大量基于知識與規(guī)則的任務(wù)和活動能夠相互協(xié)調(diào)一致、高效運(yùn)轉(zhuǎn)[1]。

工作流引擎是工作流管理系統(tǒng)的核心，它與企業(yè)核心利益息息相關(guān)[2]。目前國內(nèi)外的開源工作流有JBPM、Activiti、OSWorkflow等。由于這些工作流大多結(jié)構(gòu)復(fù)雜、靈活性差，流程變更頻繁，運(yùn)維投入很大，在國內(nèi)企業(yè)的使用情況并不理想，普及率也較低[3]。

本文基于工作流研究的現(xiàn)狀，通過借鑒傳統(tǒng)的工作流模型，開發(fā)了一套基于Web的跨部門工作流引擎。跨部門工作流引擎幫助企業(yè)解決各個部門和系統(tǒng)內(nèi)部的任務(wù)自動化、數(shù)據(jù)集成、以及控制管理的難題，消除企業(yè)內(nèi)各部門之間的隔閡，為跨部門的業(yè)務(wù)流程帶來了出色的效率、靈活度、合規(guī)性、以及可監(jiān)控性。

本文從數(shù)據(jù)表和ER圖出發(fā)，對審核流程進(jìn)行詳細(xì)介紹，使后續(xù)開發(fā)者可以根據(jù)自身不同需求進(jìn)行二次開發(fā)，設(shè)計(jì)出更適合自身需求的工作流，其原型已在廊坊市計(jì)量信息管理服務(wù)平臺中應(yīng)用。

1 工作流引擎模型的設(shè)計(jì)

工作流模型是對現(xiàn)實(shí)世界中業(yè)務(wù)過程的抽象，并用一種形式化的、計(jì)算機(jī)可處理的方式表示出來。工作流模型是工作流引擎執(zhí)行的前提和基礎(chǔ)，在進(jìn)行工作流設(shè)計(jì)前必須先選定相應(yīng)的工作流模型。

本文所設(shè)計(jì)的工作流引擎模型由兩部分組成：工作流定義模塊和工作流引擎模塊。工作流引擎結(jié)構(gòu)功能如圖1所示。

圖1 工作流引擎功能結(jié)構(gòu)

在圖1中，工作流定義模塊負(fù)責(zé)工作流的定義、解釋及維護(hù)；工作流引擎模塊負(fù)責(zé)對整個工作流程及工作項(xiàng)的創(chuàng)建、激活、掛起、終止等行為進(jìn)行監(jiān)控, 控制工作項(xiàng)的狀態(tài)轉(zhuǎn)換邏輯[4]。

1.1 工作流的數(shù)據(jù)模型設(shè)計(jì)

工作流定義是工作流引擎中至為重要的一部分[5]。工作流節(jié)點(diǎn)設(shè)計(jì)是工作流定義的核心部分，不同組織給出了各自的工作流節(jié)點(diǎn)模型,比較著名的有:WFMC,WIDE,WAMO,Active Workflow[6]。

本文基于關(guān)系型數(shù)據(jù)庫MySQL設(shè)計(jì)了數(shù)據(jù)模型，將區(qū)域、部門、崗位、節(jié)點(diǎn)、角色、用戶等工作流引擎要素以及各要素間的邏輯關(guān)系通過數(shù)據(jù)表的形式來展現(xiàn)。工作流引擎通常使用數(shù)據(jù)來控制流程[7]。工作流節(jié)點(diǎn)設(shè)計(jì)為雙向鏈表形式，以實(shí)現(xiàn)工作在工作流上能夠上下移動。數(shù)據(jù)模型設(shè)計(jì)如圖2所示。

圖2 工作流引擎E-R圖

本文所設(shè)計(jì)的工作流引擎模型中，工作流節(jié)點(diǎn)由工作流類型、區(qū)域類型、部門類型- 崗位共同決定，其中，為防止添加工作流節(jié)點(diǎn)時(shí)出現(xiàn)某部門沒有該崗位的情況，部門類型- 崗位又需要由部門和崗位共同決定。另外，部門類型- 崗位表和用戶- 部門- 崗位表為關(guān)聯(lián)表，其作用是將部門、崗位、用戶之間m∶n的邏輯關(guān)系處理為1∶n的邏輯關(guān)系，簡化實(shí)際的代碼編寫。工作流引擎負(fù)責(zé)維護(hù)工作流，當(dāng)用戶修改工作流后，工作流引擎必須能夠及時(shí)將改動后的工作流存入數(shù)據(jù)表，并確保邏輯關(guān)系準(zhǔn)確無誤。

1.2 工作流審核狀態(tài)模型設(shè)計(jì)

申請人發(fā)起的申請從提交到審批的過程中，涉及到四種不同狀態(tài)之間的轉(zhuǎn)換：待辦、在辦、已辦和擱置，工作狀態(tài)由用戶的操作觸發(fā)得到轉(zhuǎn)換。當(dāng)一個申請被創(chuàng)建時(shí)，該申請進(jìn)入“未辦”狀態(tài)；審核員點(diǎn)擊查看工作，但未進(jìn)行提交，該申請進(jìn)入“在辦”狀態(tài)；審核人員進(jìn)行擱置操作，進(jìn)入“擱置”狀態(tài)；審核員進(jìn)行辦結(jié)操作，申請進(jìn)入“辦結(jié)”狀態(tài)[8]。工作的狀態(tài)轉(zhuǎn)換如圖3所示。

圖3 工作狀態(tài)圖

字段狀態(tài)如表1所示。

表1 字段狀態(tài)表

2 工作流引擎的實(shí)現(xiàn)

大部分開源工作流只提供同一部門審核功能，極少數(shù)工作流雖然可以實(shí)現(xiàn)跨部門審核功能，但又局限于同一主體。應(yīng)用度最廣的JBPM工作流引擎，從設(shè)計(jì)上就沒有考慮“回退”、“取回”等業(yè)務(wù)場景。本文將不同主體視為同一主體下的部門，并結(jié)合擱置、退回、取回等實(shí)際情況，實(shí)現(xiàn)了跨主體審核的功能。本文中，每種申請類型對應(yīng)不同主體，每個用戶對應(yīng)多種申請類型。用戶提交申請之后，選擇相對應(yīng)的審核人。無論申請人的部門崗位如何復(fù)雜，都能夠根據(jù)引擎模型準(zhǔn)確查找到下一審核人。數(shù)據(jù)流圖如圖4所示。

圖4 工作流引擎數(shù)據(jù)流圖

在應(yīng)用本工作流引擎的系統(tǒng)中，申請人需要將信息上傳，選擇合適的工作流之后，系統(tǒng)自動獲取到正確的審核人供申請人選擇，審核成功或者失敗都需要將審核結(jié)果發(fā)送至申請員。如何獲取到適合該申請人的審核流程，和選擇審核流程之后如何精確查找下一審核人，是工作流引擎的關(guān)鍵所在。以本工作流引擎中已有的審核流程為例，如圖5所示。

圖5 審核流程交互活動圖

以圖示為例，省級管理部門受理工作申請時(shí)，根據(jù)情況判斷當(dāng)前申請是否合格。如合格，則進(jìn)行辦結(jié)操作，審核流程結(jié)束，消息反饋申請人；如不合格，則省級管理部門可選擇將申請回退給上一審核人或申請人，即市級管理部門或縣級技術(shù)機(jī)構(gòu)，此時(shí)上級審核人修改審核意見或申請人修改申請，重新提交。

2.1 查找下一審核人

申請人發(fā)起申請后，流程具體如下：

(1) 申請人登錄系統(tǒng)后，首先選擇申請類型。系統(tǒng)根據(jù)用戶選擇的申請類型，獲取申請類型id(apply_type_id)。

(2) 根據(jù)申請類型id從工作類型- 申請類型表中獲得所有對應(yīng)工作流類型id。

(3) 用戶選擇工作流類型，系統(tǒng)獲取工作流類型id(workflow_type_id)。

(4) 根據(jù)工作流類型id(workflow_type_id)從工作流節(jié)點(diǎn)表中獲取下一工作流節(jié)點(diǎn)。工作流節(jié)點(diǎn)表中每一條數(shù)據(jù)都記錄了包括工作流類型在內(nèi)的區(qū)域類型id、部門類型id、崗位id、部門類型- 崗位id以及上一工作流節(jié)點(diǎn)和下一工作流節(jié)點(diǎn)，當(dāng)系統(tǒng)獲取到工作流類型id時(shí)就能夠獲取到所有需要的信息。

(5) 由工作流節(jié)點(diǎn)獲取到用戶的區(qū)域類型，此時(shí)系統(tǒng)可以根據(jù)申請人當(dāng)前區(qū)域類型獲取上級區(qū)域類型信息。

(6) 在申請人的上級區(qū)域信息中尋找工作流節(jié)點(diǎn)表中的部門類型- 崗位信息，分別由部門類型和崗位找到部門信息和崗位信息。

(7) 由部門崗位信息找到當(dāng)前部門崗位下的所有用戶，如果有符合要求的審核人，則直接返回用戶id(user_id)。

(8) 獲取用戶提交的申請信息。

(9) 將這一申請?zhí)峤恢料乱粚徍巳颂帯?/p>

以應(yīng)用本文所設(shè)計(jì)的工作流引擎的系統(tǒng)為例，工作流申請活動圖如圖6所示。申請人提交工作，下一審核人查看工作之后可進(jìn)行退回、擱置、同意操作，同意申請之后系統(tǒng)會判斷是否存在下一審核人，若存在下一審核人，則同時(shí)更新本審核人工作記錄并生成下一審核人工作記錄，完成后將工作移交新的審核人，重復(fù)之前的判定步驟。

圖6 工作流申請活動圖

2.2 工作流的取回

當(dāng)審核申請?zhí)峤恢?，如果想要修改申請，申請人可以進(jìn)行取回操作。發(fā)起取回申請時(shí)，首先判斷當(dāng)前申請狀態(tài)，是否有人進(jìn)行了審核，如果已有人審核則不能進(jìn)行取回操作；只有當(dāng)申請為待辦狀態(tài)時(shí)，即工作流狀態(tài)字段均為0的情況下才會進(jìn)行取回操作。

取回過程代碼摘要如下：

//獲取USERID

＄userId = get_user_id();

//獲取當(dāng)前用戶下的待辦信息

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

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

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

＄this->display(YZTemplate);

//獲取當(dāng)前工作流節(jié)點(diǎn)信息

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

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

{

＄this->_empty();

return;

}

//判斷當(dāng)前結(jié)點(diǎn)是否屬于用戶

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

{

＄this->error = ″當(dāng)前結(jié)點(diǎn)并不屬于當(dāng)前用戶″;

＄this->_empty();

return;

}

//更新工作表

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

＄workflowType->is_clicked=’0’;

具體流程如下：

(1) 申請人發(fā)起取回申請。

(2) 判斷當(dāng)前申請的工作狀態(tài)字段表信息，“is_clicked”是否為0，如果是，則記錄當(dāng)前工作id。

(3) 根據(jù)工作id獲取當(dāng)前申請的工作流節(jié)點(diǎn)id。

(4) 根據(jù)工作流節(jié)點(diǎn)id獲取當(dāng)前工作流節(jié)點(diǎn)表信息。

(5) 將下一工作流節(jié)點(diǎn)信息置為0。

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

工作流取回流程數(shù)據(jù)流圖如圖7所示。

圖7 工作流取回?cái)?shù)據(jù)流程圖

2.3 工作流的退回

當(dāng)審核人在審核過程中發(fā)現(xiàn)申請存在問題時(shí)，可以將申請退回。申請被退回時(shí)，系統(tǒng)首先判斷是否存在上一審核人，如果存在，則審核人可以選擇退回上一審核人或退回申請人：選擇退回上一審核人，則工作流審核權(quán)交回上一審核人，上一審核人可以選擇提出修改意見提交給下一審核人；或者選擇退回申請人。

退回過程邏輯代碼摘要如下：

elseif(＄type == 1)

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

{

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

＄this->_empty();

return;

}

}

具體步驟如下：

(1) 獲取當(dāng)前工作流的工作狀態(tài)表信息；

(2) 重置當(dāng)前工作流的工作狀態(tài)表，將“is_clicked”和“is_commited”置為0；

(3) 獲取當(dāng)前工作流節(jié)點(diǎn)表信息；

(4) 判斷上一工作流節(jié)點(diǎn)是否為根節(jié)點(diǎn)；

(5) 刪除當(dāng)前工作流下一節(jié)點(diǎn)信息；

(6) 更新當(dāng)前工作流節(jié)點(diǎn)表中當(dāng)前節(jié)點(diǎn)信息為根節(jié)點(diǎn)。

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

圖8 工作流退回?cái)?shù)據(jù)流圖

2.4 工作流的刪除

當(dāng)審核申請?zhí)峤恢?，申請人發(fā)現(xiàn)存在問題較為嚴(yán)重?zé)o法修改時(shí)，可以將工作流刪除，邏輯代碼摘要如下：

//判斷當(dāng)用流程在當(dāng)前用戶下未提交

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

{E(″當(dāng)前用戶userId并不是當(dāng)前審核結(jié)點(diǎn)id的待在辦人″);

}

//判斷申請人為當(dāng)前用戶

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

{E(″當(dāng)前項(xiàng)目的申請人＄project[user_id]非當(dāng)前用戶userId″);

}

//刪除所有節(jié)點(diǎn)表信息

＄WorkflowL->deleteByProjectId(＄projectId);

//刪除工作狀態(tài)信息

＄WorkflowLogL->deleteByWorkflowId(＄workflowId);

具體流程如下：

(1) 獲取當(dāng)前用戶信息；

(2) 獲取當(dāng)前工作流狀態(tài)表信息，判斷當(dāng)前狀態(tài)節(jié)點(diǎn)是否為當(dāng)前用戶，“否”則無操作權(quán)限；

(3) 判斷當(dāng)前工作流狀態(tài)，“is_committed”是否為0；

(4) 獲取工作流節(jié)點(diǎn)表信息，判斷當(dāng)前節(jié)點(diǎn)是否為根節(jié)點(diǎn)，“否”則無操作權(quán)限；

(5) 刪除當(dāng)前工作流中節(jié)點(diǎn)表信息；

(6) 刪除當(dāng)前工作流中工作狀態(tài)信息；

(7) 重置當(dāng)前工作流關(guān)聯(lián)數(shù)據(jù)表中信息為空。

刪除操作流程圖如9所示。

圖9 刪除流程圖

2.5 工作流的審批

工作流提交之后，審核人可以對工作進(jìn)行擱置、取消擱置、退回、提交下一審核人和辦結(jié)操作。審批流程涉及到整體數(shù)據(jù)的流向，是工作流中最為復(fù)雜的一部分。流程圖如10所示。

圖10 審批流程圖

具體流程如下：

(1) 獲取當(dāng)前用戶信息(user-id)；

(2) 獲取當(dāng)前工作流節(jié)點(diǎn)表信息；

(3) 判斷當(dāng)前用戶所在節(jié)點(diǎn)是否為根節(jié)點(diǎn)，是則當(dāng)前用戶為提交人，否則當(dāng)前用戶為審核人。

根據(jù)當(dāng)前用戶信息，系統(tǒng)判斷用戶可執(zhí)行的下一步操作：

1) 當(dāng)用戶為申請人，步驟如下：

(1) 獲取當(dāng)前工作流適用的工作流類型表信息；

(2) 獲取當(dāng)前申請類型表信息；

(3) 根據(jù)申請類型和工作流類型信息獲取工作流節(jié)點(diǎn)表信息；

(4) 選擇下一工作流節(jié)點(diǎn)，生成工作流節(jié)點(diǎn)信息存入工作流節(jié)點(diǎn)表；

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

2) 當(dāng)用戶為審核人，審核人可以對工作流進(jìn)行提交、擱置、退回、辦結(jié)等操作，根據(jù)不同操作，進(jìn)行如下分類：

(1) 如果用戶進(jìn)行同意或辦結(jié)操作：

① 獲取工作流節(jié)點(diǎn)表信息。

② 判斷是否為終節(jié)點(diǎn)：若為終節(jié)點(diǎn)，則獲取工作表信息，將工作表中 “is_commited”字段置為1并存入工作表；若非終節(jié)點(diǎn)，則進(jìn)行如下操作。

③ 獲取當(dāng)前工作流審核信息，判斷當(dāng)前用戶是否在審核用戶列表，如果“否”則提示無權(quán)限操作。

④ 獲取當(dāng)前工作流節(jié)點(diǎn)信息，將當(dāng)前工作流節(jié)點(diǎn)存入下一節(jié)點(diǎn)信息。

⑤ 獲取當(dāng)前工作信息，將當(dāng)前用戶id存入工作信息表。

⑥ 更新工作信息表，將工作狀態(tài)“is_commited”字段置為1。

(2) 如果用戶進(jìn)行的是擱置操作，邏輯代碼摘要如下：

//查詢是否為在辦

＄map = array();

＄map[′id′] =＄workflowLogId;

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

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

{＄this->error =″該流程已辦結(jié)，不適用擱置操作″;

＄this->_empty();

}

//更新擱置數(shù)據(jù)

＄data = array();

＄data[′id′] = workflowLogId;

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

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

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

具體步驟如下：

① 判斷當(dāng)前申請的工作狀態(tài)是否為完結(jié)，即工作狀態(tài)表中“is_commited”字段是否為1，若為1則證明工作已完結(jié)，返回提示信息。

② 如果“is_commited”字段為 “0”，更新當(dāng)前工作流日志信息，即將“is_ abeyanced”字段置為“1”。

(3) 如果用戶進(jìn)行取消擱置操作，邏輯代碼摘要如下：

//查詢是否為待辦，且已擱置

＄map = array();

＄map[′id′] =＄workflowLogId;

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

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

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

{＄this->error = ″該流程已辦結(jié)，不適用擱置操作″;

＄this->_empty();

return false;

}

//更新擱置數(shù)據(jù)

＄data = array();

＄data[′id′] = workflowLogId;

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

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

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

具體步驟如下：

① 判斷當(dāng)前申請的工作狀態(tài)是否為擱置，即工作狀態(tài)表中“is_ abeyanced”字段是否為1，如果為“0”則返回不存在擱置的提示信息；

② 更新當(dāng)前工作流日志信息，將“is_ abeyanced”字段置為“0”。

3 結(jié) 語

一直以來工作流問題都是企業(yè)管理中的核心，良好的工作流能夠使各部門在工作處理、審批過程中節(jié)省更多的人力，釋放更多的資源，提高企業(yè)管理的工作效率[9]。目前跨部門工作流在國外已經(jīng)有廣泛應(yīng)用，例如醫(yī)療系統(tǒng)中的掛號預(yù)約流程，啟用工作流模型的預(yù)約系統(tǒng)相較普通預(yù)約系統(tǒng)效率提升40%～45%[10]。目前跨部門工作流還是以應(yīng)用的方式集成于系統(tǒng)中，更長遠(yuǎn)的說，相同的工作流方法可以被應(yīng)用于任何基于互聯(lián)網(wǎng)的基礎(chǔ)應(yīng)用程序中[11]。

本文從數(shù)據(jù)流出發(fā)，詳細(xì)闡述了整個申請流程中的數(shù)據(jù)轉(zhuǎn)移情況，更加直觀地將工作流問題以計(jì)算機(jī)形式說明，使工作流不再單純地局限于書面表達(dá)。通過閱讀本文，能夠更加清晰地理解工作流的申請審核流程。在應(yīng)用了本工作流的系統(tǒng)中，實(shí)現(xiàn)了對跨越不同部門和主體的業(yè)務(wù)流程的靈活控制，縮減了跨部門業(yè)務(wù)的響應(yīng)時(shí)間，極大地降低了工作流的實(shí)現(xiàn)難度，簡化了業(yè)務(wù)流程操作。本工作流適用于非常廣泛的審核情況，并能夠根據(jù)不同需求進(jìn)行二次開發(fā)，方便對工作項(xiàng)目進(jìn)行管理、分派，提高了工作效率。

[1] 蔡孝武, 韓永國, 藍(lán)科. 一種輕量級工作流引擎的研究與設(shè)計(jì)[J]. 計(jì)算機(jī)工程, 2010, 36(20):78- 79.

[2] 楊明順, 韓周鵬, 余婷,等. 一種輕型工作流引擎的設(shè)計(jì)與實(shí)現(xiàn)[J]. 西安理工大學(xué)學(xué)報(bào), 2013, 29(1):20- 26.

[3] 徐新權(quán)，孟江濤，劉宏志，等. 基于 SAP 工作流引擎的應(yīng)用[J].計(jì)算機(jī)應(yīng)用, 2013，33( S2) : 251- 255.

[4] 路春光, 孟麗麗, 郝立文,等. 基于WEB的柔性工作流引擎的設(shè)計(jì)[J]. 微計(jì)算機(jī)信息, 2006, 22(15):21- 23.

[5] 葛中澤. 工作流引擎設(shè)計(jì)關(guān)鍵技術(shù)的實(shí)現(xiàn)[J]. 鄂州大學(xué)學(xué)報(bào), 2015(5):107- 109.

[6] 徐亮, 張莉, 樊志強(qiáng). 一種基于UML的實(shí)時(shí)工作流建模方法研究[J]. 計(jì)算機(jī)研究與發(fā)展, 2010, 47(7):1184- 1191.

[7] 侯培文, 劉軍利. 輕型工作流引擎在工作流管理系統(tǒng)中的應(yīng)用[J]. 電腦開發(fā)與應(yīng)用, 2010, 23(2):46- 48.

[8] 朱春旭, 王小剛, 殷振華. JBPM4工作流引擎在科研項(xiàng)目管理系統(tǒng)中的應(yīng)用研究[J]. 電子技術(shù)與軟件工程, 2017(1):193- 195.

[9] 羅海濱, 范玉順, 吳澄. 工作流技術(shù)綜述[J]. 軟件學(xué)報(bào), 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.