原文地址：http://www.blogjava.net/RongHao/archive/2007/10/30/157009.html
對於當前的工作流應用來說，人工節點無疑扮演着一個非常重要的角色。因爲無論是傳統的協同辦公系統還是越來越多的企業應用，都需要有人蔘與到具體的流程中來。這篇文章着重分析工作流應用中人工節點所涉及到的參與者模式以及與此關聯的工作項模式，最後會提供部分的解決方案作爲參考。
先簡單說說什麼是人工節點。
人工節點的概念是與自動節點相對的。顧名思義，人工節點就是需要有人蔘與的節點，在實際流程中，它體現在產生由人完成的工作項以及由人決定一些決策變量，這些決策變量會對流程的運行產生影響（例如分支的選擇等等）。自動節點則是由工作流引擎自己調用完成，不需要人的參與，通常是執行定製的業務操作。相比較而言，人工節點更多的應用在管理流程裏，而自動節點更多的則是應用在企業業務流程裏。
人工節點的職責有三個：第一是決定該節點的參與者；第二是根據參與者生成需要人來處理的工作項；最後是當工作項被參與者處理完畢時，它將繼續觸發流程的流轉。參與者處理工作項時可以處理相應的業務和設置流程決策變量。
下面我們就按照這三個職責分別對人工節點所涉及到的參與者模式和工作項模式進行分析。
<!--[if !supportLists]-->1、 <!--[endif]-->決定參與者模式
換句話說就是決定該節點的參與者，這裏有兩種模式：引擎自動獲取和最終用戶指定。
1．1引擎自動獲取
所謂引擎自動獲取就是由引擎在運行期計算實際的節點參與者，不需要最終用戶的參與。這個計算基於流程定義時對該節點參與者的定義。
<!--[if !supportLists]-->（1） <!--[endif]-->直接指定人員、部門或角色
這種情況最簡單，也最直接，用戶定義節點時直接在組織用戶樹裏選定人員、部門或角色，然後在運行期根據定義執行與或者是或的運算。大多數的工作流引擎都支持這種模式。但很明顯它也存在着很大的侷限性，它是靜態的，一旦流程定義完畢參與者也就跟着固定下來，運行期的任何變化都不會對參與者造成影響，一個很簡單的需求，請假流程，節點的參與者需要是當前申請者的部門領導，因爲申請者在定義期是不確定的，所以根本無法指定節點的參與者，所以這種模式遠遠滿足不了用戶稍微複雜一點的需求。
<!--[if !supportLists]-->（2） <!--[endif]-->調用用戶定製的計算參與者代碼
這種情況通常是由引擎提供一個接口或是父類，用戶需要實現或是繼承這個接口或父類，然後實現相應的方法。這個方法通常會傳遞進一個執行上下文的參數，用戶代碼通過這個上下文可以訪問到當前流程實例的信息，例如當前節點狀態，工作流變量等等，然後用戶可以根據實際業務和當前流程實例信息進行邏輯計算，最後返回一個參與者的ID集合。對於上一個模式裏提到的計算當前申請者部門領導的例子，這個模式實現起來非常簡單，首先獲得當前申請者ID，然後在根據這個ID找出該申請者部門再找出該部門領導即可。
實際流程運行到該節點就會調用用戶自己定製的計算參與者的代碼，方法返回的參與者ID即作爲該節點的實際參與者。
這種模式對於工作流引擎的實現而言最爲簡單，因爲它把最大的複雜性都拋給了用戶，由用戶代碼來計算實際的參與者。實際上很多開源的工作流引擎採用的都是這種方式，例如JBPM。但是這種方式給用戶帶來最大靈活性的同時也帶來了複雜和煩瑣。特別是當面對一個數量巨大的流程需求時，爲每一個流程的每一個人工節點都定義一個參與者計算類是讓人頭疼的。再加上現在強調業務的敏捷，業務裏的改變要迅速反饋到流程的定義裏，讓最終用戶來編寫或修改這個參與者計算類不現實也不可能。補充一下，這也是用戶在考慮採用開源的工作流引擎還是商業工作流引擎時需要着重考慮的一個方面。
<!--[if !supportLists]-->（3） <!--[endif]-->指定前續節點的參與者
實際上是用戶在節點定義時指定參與者爲前續某個節點的參與者，當流程運行到該節點，引擎會自動獲取所指定的前續節點的參與者作爲該節點的實際參與者。
這個模式實現起來並不困難，大多數商業工作流引擎都對該模式進行了支持。它能夠滿足用戶的部分特定需求。
<!--[if !supportLists]-->（4） <!--[endif]-->更爲複雜的情況
用戶的需求永遠是複雜的，引擎所要做得就是儘量降低這種複雜性，流程的變化要能夠迅速跟上業務的變化。考慮下面兩種稍微複雜一點但是又很常見的需求。需求一：參與者爲當前申請者的部門領導且職位爲副總；需求二：參與者需要是測試部的所有女同事。這兩種需求模式1、3都不能滿足，2可以，但是正如提到的那樣，模式2可能會非常的煩瑣，不能適應業務的敏捷。其實這裏的複雜性主要體現在：1、這裏的參與者可能是運行期決定的；2、參與者的限制條件可能非常多，而這些條件不是簡單的部門、角色或職位所能描述的。
對於一般的工作流引擎而言，它們都會選擇模式2的實現，讓用戶自己實現邏輯。實際在後面的部分解決方案裏，我們會看到更爲好一點的實現方式。
1.2最終用戶指定
運行期由最終用戶來決定節點的參與者。這也是中國國情所獨有的特色。這種模式最爲常見的就是用戶提交工作項時的提交頁面，用戶在該頁面上選定下一節點（多數分支用戶選定時）和下一節點的參與者。這種模式本身並不困難，問題在於在提交頁面需要給用戶提供一個參與者的選擇範圍，讓用戶進行選擇。而關於這個選擇範圍，則又回到前面所提到的引擎自動獲取的模式，這個範圍同樣是需要引擎計算的。於是又回到了剛剛討論過的四種模式。
2、參與者執行模式
現在，已經獲得了節點的參與者。引擎下一步將會根據這個參與者生成工作項，注意，這裏的參與者可能是一個人，也可能會是一個人員範圍（即多個人）。於是就產生了參與者的執行模式，也可以理解爲工作項的生成模式。
2.1競爭參與
當有多個參與者參與這個節點時就會產生競爭參與這個模式。同樣一個工作，A可以完成，B也可以完成，於是就產生競爭，誰先開始這項工作，就由誰負責完成該工作。
2.2順序參與
多個參與者按照指定的順序完成該工作項。A完成之後由B完成，B完成之後再交給C完成。
2.3同時參與
多個參與者同時對工作進行處理，所有參與者均完成後，流程繼續向後流轉。這個模式其實比較複雜，因爲這裏同時涉及到一個完成規則：是所有參與者均完成工作項後流程流轉，還是有其他規則？例如完成2個工作項即可流轉，完成80%的工作項即可流轉。稍候會討論到。
2.4負載均衡
這也是一個常見的需求。這項工作A和B都可以完成，但是A目前有10個待辦工作項，B只有2個待辦工作項。於是用戶期望該工作交由B來完成。這裏需要實現一個簡單的負載均衡。其實這種情況只是智能決策的一種最簡單的情況，所謂智能決策是指系統能夠根據一定的指標（由數據分析，例如人員的處理效率，工作負載等等）和規則來決定該節點的參與者。
<!--[if !supportLists]-->3、<!--[endif]-->工作項完成模式
這個模式在參與者執行模式爲同時參與時有效。在說到這個模式之前，先簡單說說工作項可能存在的幾種特殊狀態，這些狀態包括掛起、人工終止和委派。掛起就是工作項暫時停止執行，掛起會影響到流程的流轉，會導致流程的掛起。人工終止則是人工手動改變該工作項的狀態，使該工作項終止執行，這個人通常會是管理員。人工終止也會對流程流轉產生影響，當除去該工作項之外的所有工作項都完成時，人工終止該工作項會觸發流程的流轉。委派就是將該工作項委派給他人完成，同時該工作項也就結束了。人工終止和委派是工作項結束的特殊狀態。
3.1全部完成
當所有工作項都結束時觸發節點的結束和流程的流轉。
3.2完成規定的個數
節點定義時指定工作項必須完成的個數，當完成的工作項達到這個指定的個數時觸發節點的結束和流程的流轉。
3.3完成規定的百分比
節點定義時指定工作項必須完成的百分比，當完成的工作項佔所有工作項的比例達到這個指定的百分比時觸發節點的結束和流程的流轉。
其實這裏很明顯的可以看出不管是所謂的參與者執行模式還是工作項完成模式不過都是一定的規則，既然是一定的規則那必然就限定了應用的靈活性，用戶能否自定義規則？根據業務靈活地修改規則？規則引擎+DSL應該是一個不錯的選擇。
http://www.blogjava.net/ronghao 榮浩原創，轉載請註明出處：）
