原文地址：http://www.tkk7.com/RongHao/archive/2007/10/30/157009.html

對于當前的工作流應用來說，人工節(jié)點無疑扮演著一個非常重要的角色。因為無論是傳統(tǒng)的協(xié)同辦公系統(tǒng)還是越來越多的企業(yè)應用，都需要有人參與到具體的流程中來。這篇文章著重分析工作流應用中人工節(jié)點所涉及到的參與者模式以及與此關聯(lián)的工作項模式，最后會提供部分的解決方案作為參考。

先簡單說說什么是人工節(jié)點。

人工節(jié)點的概念是與自動節(jié)點相對的。顧名思義，人工節(jié)點就是需要有人參與的節(jié)點，在實際流程中，它體現(xiàn)在產(chǎn)生由人完成的工作項以及由人決定一些決策變量，這些決策變量會對流程的運行產(chǎn)生影響（例如分支的選擇等等）。自動節(jié)點則是由工作流引擎自己調用完成，不需要人的參與，通常是執(zhí)行定制的業(yè)務操作。相比較而言，人工節(jié)點更多的應用在管理流程里，而自動節(jié)點更多的則是應用在企業(yè)業(yè)務流程里。

人工節(jié)點的職責有三個：第一是決定該節(jié)點的參與者；第二是根據(jù)參與者生成需要人來處理的工作項；最后是當工作項被參與者處理完畢時，它將繼續(xù)觸發(fā)流程的流轉。參與者處理工作項時可以處理相應的業(yè)務和設置流程決策變量。

下面我們就按照這三個職責分別對人工節(jié)點所涉及到的參與者模式和工作項模式進行分析。

1、  決定參與者模式

換句話說就是決定該節(jié)點的參與者，這里有兩種模式：引擎自動獲取和最終用戶指定。
 

1．1引擎自動獲取

所謂引擎自動獲取就是由引擎在運行期計算實際的節(jié)點參與者，不需要最終用戶的參與。這個計算基于流程定義時對該節(jié)點參與者的定義。

（1）    直接指定人員、部門或角色

這種情況最簡單，也最直接，用戶定義節(jié)點時直接在組織用戶樹里選定人員、部門或角色，然后在運行期根據(jù)定義執(zhí)行與或者是或的運算。大多數(shù)的工作流引擎都支持這種模式。但很明顯它也存在著很大的局限性，它是靜態(tài)的，一旦流程定義完畢參與者也就跟著固定下來，運行期的任何變化都不會對參與者造成影響，一個很簡單的需求，請假流程，節(jié)點的參與者需要是當前申請者的部門領導，因為申請者在定義期是不確定的，所以根本無法指定節(jié)點的參與者，所以這種模式遠遠滿足不了用戶稍微復雜一點的需求。

（2）    調用用戶定制的計算參與者代碼

這種情況通常是由引擎提供一個接口或是父類，用戶需要實現(xiàn)或是繼承這個接口或父類，然后實現(xiàn)相應的方法。這個方法通常會傳遞進一個執(zhí)行上下文的參數(shù)，用戶代碼通過這個上下文可以訪問到當前流程實例的信息，例如當前節(jié)點狀態(tài)，工作流變量等等，然后用戶可以根據(jù)實際業(yè)務和當前流程實例信息進行邏輯計算，最后返回一個參與者的ID集合。對于上一個模式里提到的計算當前申請者部門領導的例子，這個模式實現(xiàn)起來非常簡單，首先獲得當前申請者ID，然后在根據(jù)這個ID找出該申請者部門再找出該部門領導即可。

實際流程運行到該節(jié)點就會調用用戶自己定制的計算參與者的代碼，方法返回的參與者ID即作為該節(jié)點的實際參與者。

這種模式對于工作流引擎的實現(xiàn)而言最為簡單，因為它把最大的復雜性都拋給了用戶，由用戶代碼來計算實際的參與者。實際上很多開源的工作流引擎采用的都是這種方式，例如JBPM。但是這種方式給用戶帶來最大靈活性的同時也帶來了復雜和煩瑣。特別是當面對一個數(shù)量巨大的流程需求時，為每一個流程的每一個人工節(jié)點都定義一個參與者計算類是讓人頭疼的。再加上現(xiàn)在強調業(yè)務的敏捷，業(yè)務里的改變要迅速反饋到流程的定義里，讓最終用戶來編寫或修改這個參與者計算類不現(xiàn)實也不可能。補充一下，這也是用戶在考慮采用開源的工作流引擎還是商業(yè)工作流引擎時需要著重考慮的一個方面。

（3）    指定前續(xù)節(jié)點的參與者

實際上是用戶在節(jié)點定義時指定參與者為前續(xù)某個節(jié)點的參與者，當流程運行到該節(jié)點，引擎會自動獲取所指定的前續(xù)節(jié)點的參與者作為該節(jié)點的實際參與者。

這個模式實現(xiàn)起來并不困難，大多數(shù)商業(yè)工作流引擎都對該模式進行了支持。它能夠滿足用戶的部分特定需求。

（4）    更為復雜的情況

用戶的需求永遠是復雜的，引擎所要做得就是盡量降低這種復雜性，流程的變化要能夠迅速跟上業(yè)務的變化。考慮下面兩種稍微復雜一點但是又很常見的需求。需求一：參與者為當前申請者的部門領導且職位為副總；需求二：參與者需要是測試部的所有女同事。這兩種需求模式1、3都不能滿足，2可以，但是正如提到的那樣，模式2可能會非常的煩瑣，不能適應業(yè)務的敏捷。其實這里的復雜性主要體現(xiàn)在：1、這里的參與者可能是運行期決定的；2、參與者的限制條件可能非常多，而這些條件不是簡單的部門、角色或職位所能描述的。

對于一般的工作流引擎而言，它們都會選擇模式2的實現(xiàn)，讓用戶自己實現(xiàn)邏輯。實際在后面的部分解決方案里，我們會看到更為好一點的實現(xiàn)方式。

1.2最終用戶指定

   運行期由最終用戶來決定節(jié)點的參與者。這也是中國國情所獨有的特色。這種模式最為常見的就是用戶提交工作項時的提交頁面，用戶在該頁面上選定下一節(jié)點（多數(shù)分支用戶選定時）和下一節(jié)點的參與者。這種模式本身并不困難，問題在于在提交頁面需要給用戶提供一個參與者的選擇范圍，讓用戶進行選擇。而關于這個選擇范圍，則又回到前面所提到的引擎自動獲取的模式，這個范圍同樣是需要引擎計算的。于是又回到了剛剛討論過的四種模式。

2、參與者執(zhí)行模式

   現(xiàn)在，已經(jīng)獲得了節(jié)點的參與者。引擎下一步將會根據(jù)這個參與者生成工作項，注意，這里的參與者可能是一個人，也可能會是一個人員范圍（即多個人）。于是就產(chǎn)生了參與者的執(zhí)行模式，也可以理解為工作項的生成模式。

2.1競爭參與

當有多個參與者參與這個節(jié)點時就會產(chǎn)生競爭參與這個模式。同樣一個工作，A可以完成，B也可以完成，于是就產(chǎn)生競爭，誰先開始這項工作，就由誰負責完成該工作。

2.2順序參與

   多個參與者按照指定的順序完成該工作項。A完成之后由B完成，B完成之后再交給C完成。

2.3同時參與

   多個參與者同時對工作進行處理，所有參與者均完成后，流程繼續(xù)向后流轉。這個模式其實比較復雜，因為這里同時涉及到一個完成規(guī)則：是所有參與者均完成工作項后流程流轉，還是有其他規(guī)則？例如完成2個工作項即可流轉，完成80%的工作項即可流轉。稍候會討論到。

2.4負載均衡

   這也是一個常見的需求。這項工作A和B都可以完成，但是A目前有10個待辦工作項，B只有2個待辦工作項。于是用戶期望該工作交由B來完成。這里需要實現(xiàn)一個簡單的負載均衡。其實這種情況只是智能決策的一種最簡單的情況，所謂智能決策是指系統(tǒng)能夠根據(jù)一定的指標（由數(shù)據(jù)分析，例如人員的處理效率，工作負載等等）和規(guī)則來決定該節(jié)點的參與者。

3、工作項完成模式

這個模式在參與者執(zhí)行模式為同時參與時有效。在說到這個模式之前，先簡單說說工作項可能存在的幾種特殊狀態(tài)，這些狀態(tài)包括掛起、人工終止和委派。掛起就是工作項暫時停止執(zhí)行，掛起會影響到流程的流轉，會導致流程的掛起。人工終止則是人工手動改變該工作項的狀態(tài)，使該工作項終止執(zhí)行，這個人通常會是管理員。人工終止也會對流程流轉產(chǎn)生影響，當除去該工作項之外的所有工作項都完成時，人工終止該工作項會觸發(fā)流程的流轉。委派就是將該工作項委派給他人完成，同時該工作項也就結束了。人工終止和委派是工作項結束的特殊狀態(tài)。
 

3.1全部完成

當所有工作項都結束時觸發(fā)節(jié)點的結束和流程的流轉。

3.2完成規(guī)定的個數(shù)

節(jié)點定義時指定工作項必須完成的個數(shù)，當完成的工作項達到這個指定的個數(shù)時觸發(fā)節(jié)點的結束和流程的流轉。 

3.3完成規(guī)定的百分比

節(jié)點定義時指定工作項必須完成的百分比，當完成的工作項占所有工作項的比例達到這個指定的百分比時觸發(fā)節(jié)點的結束和流程的流轉。
 

其實這里很明顯的可以看出不管是所謂的參與者執(zhí)行模式還是工作項完成模式不過都是一定的規(guī)則，既然是一定的規(guī)則那必然就限定了應用的靈活性，用戶能否自定義規(guī)則？根據(jù)業(yè)務靈活地修改規(guī)則？規(guī)則引擎+DSL應該是一個不錯的選擇。