田雅軒

【摘 要】目前，大多數(shù)工作流引擎流程復(fù)雜、環(huán)節(jié)較多，維護起來難度較大。并且在工作流發(fā)生變動的情況下，很容易影響到任務(wù)正常流轉(zhuǎn)。為應(yīng)對工作流引擎在使用過程中出現(xiàn)的加載效率低、靈活性小、流轉(zhuǎn)受阻等問題，提出了基于目錄樹結(jié)構(gòu)的工作流引擎設(shè)計。

【關(guān)鍵詞】工作流；工作流引擎；目錄樹；節(jié)點

【Abstract】Most of the current workflow engine process complex， more links， it is difficult to maintain. And if changes in workflow， it is easy to affect the normal circulation of official document. For the problem of loading efficiency to deal with workflow engine used in the process of low， small， flexible transfer resistance， puts forward the design of workflow engine based on tree structure.

【Key words】Workflow； Workflow engine； The directory tree； Node

1 設(shè)計背景與目標

工作流引擎是根據(jù)角色、分工和條件的不同，提供對各應(yīng)用系統(tǒng)有決定作用的信息傳遞路由解決方案[1]。目前，市場上的工作流引擎系統(tǒng)，流程事項的各環(huán)節(jié)和流轉(zhuǎn)路徑相對比較固定，當流程發(fā)生變化時，只能通過修改代碼方式進行解決，因此，程序維護量比較大[2]。

工作流的變動不僅影響到程序的更改，同時，還會影響到占用該工作流的任務(wù)正常流轉(zhuǎn)，造成任務(wù)流轉(zhuǎn)受阻。雖然現(xiàn)在推出了很多工作流引擎的框架，例如，Shark和JBPM[3]，可以在此基礎(chǔ)上制定個性化工作流引擎，來滿足我們對工作流靈活性和易維護性得要求[4]，但是當工作流進行更改時，必須將正在使用該工作流的任務(wù)進行清理，任務(wù)必須走完流程或者被刪除重新發(fā)布，否則無法修改工作流內(nèi)容。因此，雖然解決了靈活性問題，但在工作流維護方面又增加了額外的工作量。為此，基于.Net平臺，開發(fā)了一種較輕量級的工作流引擎，用于任務(wù)流轉(zhuǎn)。

同時，為了保證在修改工作流的同時能夠正確處理占用該工作流且未流轉(zhuǎn)結(jié)束的任務(wù)。最終確定設(shè)計方案為：在更新或刪除工作流時，如存在使用該工作流且未結(jié)束流轉(zhuǎn)過程的任務(wù)，需要對任務(wù)的路由方向重新設(shè)置。

2 工作流引擎模型構(gòu)建

本工作流引擎在架構(gòu)上采用了目錄樹結(jié)構(gòu)方式，審批環(huán)節(jié)和審批人作為樹的葉子節(jié)點，若為審批組則該節(jié)點下需要關(guān)聯(lián)審批組人員，則審批組內(nèi)的審批人員作為葉子節(jié)點。

2.1 節(jié)點模型

2.1.1 審批環(huán)節(jié)名稱

在審批環(huán)節(jié)名稱設(shè)置方面，所有名稱采用結(jié)構(gòu)化處理，即環(huán)節(jié)名稱全部從節(jié)點名稱表中選取。

2.1.2 審批對象

審批人即審批對象是在任務(wù)流轉(zhuǎn)至各環(huán)節(jié)時處理該文的經(jīng)辦人，每個審批環(huán)節(jié)均有不同審批人負責任務(wù)審核、批閱和簽批。審批對象分為五類：審批個人、審批組、返回發(fā)文者、本部門負責人、總負責人。

1）審批個人

即選擇指定的人員作為審批人，當任務(wù)流轉(zhuǎn)至特定環(huán)節(jié)時，由此人負責任務(wù)的審批，其他人均看不到該文，也無法進行審批。

2）審批組

審批組可以選擇一個部門，例如，測試組、研發(fā)組、項目組；也可以預(yù)先設(shè)置一個小組作為審批組，例如，部門領(lǐng)導(dǎo)組、工會小組、黨員組。當任務(wù)流轉(zhuǎn)至特定環(huán)節(jié)前，需要用戶從該審批組中選擇人員作為下一審批人。

3）返回發(fā)文者

任務(wù)在上一環(huán)審批結(jié)束后會自動返回至發(fā)文者進行處理。例如，當系統(tǒng)維護費的預(yù)算經(jīng)中心領(lǐng)導(dǎo)審批后返回給發(fā)文者，發(fā)文者上傳發(fā)票后繼續(xù)下一流程審批。

4）本部門負責人

任務(wù)在發(fā)布后或上一審批結(jié)束后，自動流轉(zhuǎn)至本部門領(lǐng)導(dǎo)進行審批，當本部門領(lǐng)導(dǎo)大于兩位以上，則需要用戶手工選擇其中一位審批領(lǐng)導(dǎo)。

5）總負責人

任務(wù)在發(fā)布后或上一審批結(jié)束后，自動流轉(zhuǎn)至總負責人進行審批，當總負責人大于兩位以上，則需要用戶手工選擇其中一位審批領(lǐng)導(dǎo)。

2.2 工作流操作

工作流的操作包括工作流的建立、刪除，以及更新工作流，工作的修改操作還包括了：刪除節(jié)點、插入節(jié)點、更新節(jié)點內(nèi)容。其中刪除工作流、更新工作流（包括：刪除節(jié)點、插入節(jié)點、更新節(jié)點內(nèi)容），此類操作在執(zhí)行時，需要判斷當前操作的工作流是否被占用，如有任務(wù)使用此工作流并且該任務(wù)未流轉(zhuǎn)結(jié)束，則該任務(wù)將被“掛起”，需要將該任務(wù)轉(zhuǎn)向其他節(jié)點，進行下一步流轉(zhuǎn)。

2.3 工作流接口設(shè)計

在工作流設(shè)置過程中，通過調(diào)用workflow_interface（）接口選擇節(jié)點類型并對工作流進行實例化。最終能夠?qū)崿F(xiàn)三種類型的工作流，第一個種是以個人為審批對象的工作流person_approveflow（）；第二種是以組為審批對象的工作流group_approveflow（），每次任務(wù)在流轉(zhuǎn)到下一環(huán)節(jié)之前，需要從該組選擇下一審批人，然后進行流轉(zhuǎn)；第三種是個人審批與組審批相結(jié)合的工作流person_groupflow（），即有些環(huán)節(jié)需要從組中選擇下一審批人，有些環(huán)節(jié)已固定審批人員，不用選擇。

3 工作流引擎實現(xiàn)

3.1 工作流創(chuàng)建

在工作流構(gòu)建的過程中，需要將用戶的選項內(nèi)容以及關(guān)聯(lián)的表內(nèi)容進行抓取，傳輸至工作流程表中，并生成目錄樹。具體事項如下：

1）通過public ActionResult Index（）函數(shù)進行初始化；

2）通過遞歸方式：函數(shù)ActionResultCreate（DataTable table， LCSZ lcsz， string id），分別創(chuàng)建各子樹，并進行實例化。

3.2 工作流調(diào)用

通過前序遍歷樹的遞歸方式調(diào)用工作流進行流轉(zhuǎn)，并自左向右遍歷樹的每一個節(jié)點，currentnode 為當前節(jié)點，nextnode為下一節(jié)點，先訪問第一個子樹，直到訪問至葉子節(jié)點，再訪問該層的兄弟節(jié)點，再遍歷另一個兄弟子樹，直至遍歷全部節(jié)點，即流程全部走完。

3.3 工作流修改/刪除

工作流程內(nèi)容一旦發(fā)生變化，例如，工作流被修改，包括：增加節(jié)點、刪除節(jié)點、修改節(jié)點、刪除工作流，都將觸發(fā)check_trigger觸發(fā)器。通過check_trigger掃描當前流轉(zhuǎn)過程中的任務(wù)是否占用該工作流，如果有任務(wù)被占用，工作流引擎自動將任務(wù)置為“掛起”狀態(tài)，需要將該任務(wù)進行重置，重置方案為：1）將任務(wù)退回至初始狀態(tài)；2）轉(zhuǎn)到其他工作流節(jié)點；3）轉(zhuǎn)到本工作流未被刪除/修改的節(jié)點，如果該工作流即將被刪除，那么只能轉(zhuǎn)移到其他工作流節(jié)點；最后更新或刪除工作流。在程序執(zhí)行的過程中，首先一旦出現(xiàn)TriggerAction.Delete和TriggerAction.Update操作，則執(zhí)行triggContext.TriggerAction觸發(fā)任務(wù)，即將其變?yōu)椤皰炱稹睜顟B(tài)，由修改者對任務(wù)重新設(shè)置。

4 工作流引擎性能測試

一般的工作流引擎是通過數(shù)據(jù)庫調(diào)取流轉(zhuǎn)路徑的數(shù)據(jù)，而本設(shè)計則是直接訪問已生成的目錄樹，來調(diào)取任務(wù)流轉(zhuǎn)路由。記錄了1個用戶，10個用戶、50個用戶，100個用戶并發(fā)調(diào)用兩種工作流的平均執(zhí)行時間，過程為從任務(wù)流轉(zhuǎn)活動開始到結(jié)束。其中，1個用戶時，使用一般工作流引擎平均執(zhí)行時間為2.607s，基于目錄樹的工作流引擎平均執(zhí)行時間為1.477s；10個用戶時，平均執(zhí)行時間分別為3.261s與1.763s；50個用戶時，平均執(zhí)行時間分別為3.715s與1.904s；100個用戶時，平均執(zhí)行時間分別為4.213s與2.024s。以上測試可以看出，對于執(zhí)行同一類活動，使用本設(shè)計的工作流引擎比一般工作流引擎所用要少得多。且隨著并發(fā)數(shù)量的增加，這一現(xiàn)象變得更加顯著。

5 結(jié)束語

基于目錄樹的工作流引擎在建立工作流的過程中，操作簡單，易于修改。在工作流調(diào)用過程中，通過性能測試得出平均執(zhí)行時間為1.792秒，時間復(fù)雜度為O（n），執(zhí)行效率較高。并針對現(xiàn)有工作流設(shè)置過程中存在修改后造成流轉(zhuǎn)中任務(wù)路由錯誤或受阻的情況，設(shè)計了工作流修改與任務(wù)流轉(zhuǎn)聯(lián)動的機制，保證了占用所修改工作流的任務(wù)能夠重新選擇節(jié)點進行新的路由。由于該工作流的設(shè)計剛初步完成，在有些流轉(zhuǎn)功能上還需要手工的參與，在實現(xiàn)全部自動化路由方面，需要進一步完善。

【參考文獻】

[1]武凌.工作流知識管理系統(tǒng)工作流引擎的研究[J].計算機技術(shù)與發(fā)展，2010，20（8）：112-115.Wu Ling. Study on workflow knowledge management system workflow engine. Computer technology and development. 2010，20（8）：112-115.

[2]許悅珊.嵌入式工作流引擎的設(shè)計與應(yīng)用[J].計算機時代，2009，199（1）：20-24.Xu RuiShan. Design and application of embedded workflow engine. Computer Era. 2009，199（1）：20-24.

[3]馬亞鋒，張玉扣.教研視野下主流開源工作流引擎對比分析[J].成才之路， 2014，413（1）：60.Ma Yafeng， Zhang Yukou. Analysis of teaching from the perspective of mainstream open source workflow engine. The road to success，2014，413（1）：60.

[4]馮天佑，梁立宇，李成華，等.基于Activiti工作流引擎技術(shù)的電力行業(yè)業(yè)務(wù)流程管理系統(tǒng)[J].信息通信，2013，130（8）：57-58.Feng Tianyou， Liang Liyu， Li Chenghua et al. Business process management system for power industry Activiti based workflow technology. The information communication. 2013，130（8）：57-58.

[責任編輯：王楠]