對於當前的工作流應用來說，人工節點無疑扮演著乙個非常重要的角色。因為無論是傳統的協同辦公系統還是越來越多的企業應用，都需要有人參與到具體的流程中來。這篇文章著重分析工作流應用中人工節點所涉及到的參與者模式以及與此關聯的工作項模式，最後會提供部分的解決方案作為參考。
先簡單說說什麼是人工節點。
人工節點的概念是與自動節點相對的。顧名思義，人工節點就是需要有人參與的節點，在實際流程中，它體現在產生由人完成的工作項以及由人決定一些決策變數，這些決策變數會對流程的執行產生影響（例如分支的選擇等等）。自動節點則是由工作流引擎自己呼叫完成，不需要人的參與，通常是執行定製的業務操作。相比較而言，人工節點更多的應用在管理流程裡，而自動節點更多的則是應用在企業業務流程裡。
人工節點的職責有三個：第一是決定該節點的參與者；第二是根據參與者生成需要人來處理的工作項；最後是當工作項被參與者處理完畢時，它將繼續觸發流程的流轉。參與者處理工作項時可以處理相應的業務和設定流程決策變數。
下面我們就按照這三個職責分別對人工節點所涉及到的參與者模式和工作項模式進行分析。
1、決定參與者模式
換句話說就是決定該節點的參與者，這裡有兩種模式：引擎自動獲取和終端使用者指定。
1．1引擎自動獲取
所謂引擎自動獲取就是由引擎在執行期計算實際的節點參與者，不需要終端使用者的參與。這個計算基於流程定義時對該節點參與者的定義。
（1）直接指定人員、部門或角色
這種情況最簡單，也最直接，使用者定義節點時直接在組織使用者樹里選定人員、部門或角色，然後在執行期根據定義執行與或者是或的運算。大多數的工作流引擎都支援這種模式。但很明顯它也存在著很大的侷限性，它是靜態的，一旦流程定義完畢參與者也就跟著固定下來，執行期的任何變化都不會對參與者造成影響，乙個很簡單的需求，請假流程，節點的參與者需要是當前申請者的部門領導，因為申請者在定義期是不確定的，所以根本無法指定節點的參與者，所以這種模式遠遠滿足不了使用者稍微複雜一點的需求。
（2）呼叫使用者定製的計算參與者**
這種情況通常是由引擎提供乙個介面或是父類，使用者需要實現或是繼承這個介面或父類，然後實現相應的方法。這個方法通常會傳遞進乙個執行上下文的引數，使用者**通過這個上下文可以訪問到當前流程例項的資訊，例如當前節點狀態，工作流變數等等，然後使用者可以根據實際業務和當前流程例項資訊進行邏輯計算，最後返回乙個參與者的
id集合。對於上乙個模式裡提到的計算當前申請者部門領導的例子，這個模式實現起來非常簡單，首先獲得當前申請者
id，然後在根據這個
id找出該申請者部門再找出該部門領導即可。
實際流程執行到該節點就會呼叫使用者自己定製的計算參與者的**，方法返回的參與者
id即作為該節點的實際參與者。
這種模式對於工作流引擎的實現而言最為簡單，因為它把最大的複雜性都拋給了使用者，由使用者**來計算實際的參與者。實際上很多開源的工作流引擎採用的都是這種方式，例如
jbpm
。但是這種方式給使用者帶來最大靈活性的同時也帶來了複雜和煩瑣。特別是當面對乙個數量巨大的流程需求時，為每乙個流程的每乙個人工節點都定義乙個參與者計算類是讓人頭疼的。再加上現在強調業務的敏捷，業務裡的改變要迅速反饋到流程的定義裡，讓終端使用者來編寫或修改這個參與者計算類不現實也不可能。補充一下，這也是使用者在考慮採用開源的工作流引擎還是商業工作流引擎時需要著重考慮的乙個方面。
（3）指定前續節點的參與者
實際上是使用者在節點定義時指定參與者為前續某個節點的參與者，當流程執行到該節點，引擎會自動獲取所指定的前續節點的參與者作為該節點的實際參與者。
這個模式實現起來並不困難，大多數商業工作流引擎都對該模式進行了支援。它能夠滿足使用者的部分特定需求。
（4）更為複雜的情況
使用者的需求永遠是複雜的，引擎所要做得就是盡量降低這種複雜性，流程的變化要能夠迅速跟上業務的變化。考慮下面兩種稍微複雜一點但是又很常見的需求。需求一：參與者為當前申請者的部門領導且職位為副總；需求二：參與者需要是測試部的所有女同事。這兩種需求模式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來完成。這裡需要實現乙個簡單的負載均衡。其實這種情況只是智慧型決策的一種最簡單的情況，所謂智慧型決策是指系統能夠根據一定的指標（由資料分析，例如人員的處理效率，工作負載等等）和規則來決定該節點的參與者。
3、工作項完成模式
這個模式在參與者執行模式為同時參與時有效。在說到這個模式之前，先簡單說說工作項可能存在的幾種特殊狀態，這些狀態包括掛起、人工終止和委派。掛起就是工作項暫時停止執行，掛起會影響到流程的流轉，會導致流程的掛起。人工終止則是人工手動改變該工作項的狀態，使該工作項終止執行，這個人通常會是管理員。人工終止也會對流程流轉產生影響，當除去該工作項之外的所有工作項都完成時，人工終止該工作項會觸發流程的流轉。委派就是將該工作項委派給他人完成，同時該工作項也就結束了。人工終止和委派是工作項結束的特殊狀態。
3.1全部完成
當所有工作項都結束時觸發節點的結束和流程的流轉。
3.2完成規定的個數
節點定義時指定工作項必須完成的個數，當完成的工作項達到這個指定的個數時觸發節點的結束和流程的流轉。
3.3完成規定的百分比
節點定義時指定工作項必須完成的百分比，當完成的工作項佔所有工作項的比例達到這個指定的百分比時觸發節點的結束和流程的流轉。
其實這裡很明顯的可以看出不管是所謂的參與者執行模式還是工作項完成模式不過都是一定的規則，既然是一定的規則那必然就限定了應用的靈活性，使用者能否自定義規則？根據業務靈活地修改規則？規則引擎
+dsl
應該是乙個不錯的選擇。
工作流參與者和工作項模式分析
對於當前的工作流應用來說，人工節點無疑扮演著乙個非常重要的角色。因為無論是傳統的協同辦公系統還是越來越多的企業應用，都需要有人參與到具體的流程中來。這篇文章著重分析工作流應用中人工節點所涉及到的參與者模式以及與此關聯的工作項模式，最後會提供部分的解決方案作為參考。先簡單說說什麼是人工節點。人工節點的...
StarFlow 工作流 5種設定參與者的模式
5中設定環節參與者模式 1 配置流程是設定固定參與者 2 與流程啟動者相同 3 a環節的參與者保持與b環節參與者相同 4 提供乙個介面。動態獲取參與者 下面的例項提供四種實現方式 流程圖 例項 processengine processengine new configuration buildpr...
分析模式 之 參與者 Party
在我們分析模型的時候經常會遇到不同型別的事物在某些特性上有共同點，比如，人和公司，他們都有位址，電子郵件等屬性，在分析模型的時候，我們可能得出如下的模型 看到上述的模型的時候，我們是否會覺得模型中的冗餘呢？很顯然，我們會想如何將這兩者融合在一起呢，我們偉大的martin fowler同志提出了par...