這是我們（東方易維）工作流產品設計過程中采取的設計：

一、流程實例的狀態(tài)

   狀態(tài)分為5種：實例化、執(zhí)行中、掛起、手工結束、正常結束。

   狀態(tài)的變遷如下圖：

二、節(jié)點實例的狀態(tài)

狀態(tài)分為5種：實例化、執(zhí)行中、掛起、手工結束、正常結束。

狀態(tài)的變遷如下圖：

三、具體節(jié)點的狀態(tài)

   細分：

A、人工節(jié)點、等待節(jié)點

這兩個節(jié)點被觸發(fā)后存在一個執(zhí)行等待的過程，所以可以被用戶直接掛起和手工結束。人工節(jié)點的掛起意味著所有未完成工作項的掛起，同時相應時間服務的時間計算的掛起。手工結束會使流程跳過該節(jié)點（所有工作項手工結束），繼續(xù)往后流轉。

B、開始節(jié)點、結束節(jié)點、分支節(jié)點、自動節(jié)點

這些節(jié)點的特點在于被觸發(fā)后立刻執(zhí)行和流轉，所以不會存在掛起和手工結束的狀態(tài)。

C、并發(fā)節(jié)點、匯聚節(jié)點

并發(fā)節(jié)點和匯聚節(jié)點不存在掛起的狀態(tài)，同時不能被用戶直接手工結束，它們的狀態(tài)受流程實例狀態(tài)和相關節(jié)點實例狀態(tài)的影響。

并發(fā)節(jié)點和匯聚節(jié)點的情況復雜一些，分模式討論

圖1

1、同步匯聚（圖1）

根據情況觸發(fā)節(jié)點0、節(jié)點1、節(jié)點2中的一個或多個，匯聚節(jié)點等待所有實際觸發(fā)的節(jié)點完成后再執(zhí)行流轉。中間匯聚節(jié)點只會產生一個實例。

1.1、正常流轉時的處理策略

當匯聚節(jié)點未被觸發(fā)時（即節(jié)點0、節(jié)點1、節(jié)點2都未執(zhí)行結束），并發(fā)節(jié)點處于執(zhí)行狀態(tài)，一旦匯聚節(jié)點被觸發(fā)（即節(jié)點0、節(jié)點1、節(jié)點2有一個執(zhí)行結束），并發(fā)節(jié)點正常結束并且匯聚節(jié)點處于執(zhí)行狀態(tài)，所有并發(fā)出的節(jié)點實例執(zhí)行結束后，匯聚節(jié)點正常結束，流程繼續(xù)流轉。

1.2、用戶掛起、手工結束相關節(jié)點的處理策略

1.2.1、匯聚節(jié)點未激活時

節(jié)點0、節(jié)點1、節(jié)點2的掛起和恢復執(zhí)行不會影響并發(fā)節(jié)點的狀態(tài)（依舊處于執(zhí)行狀態(tài)）；節(jié)點0、節(jié)點1、節(jié)點2的任一手工結束都會觸發(fā)匯聚節(jié)點，使并發(fā)節(jié)點正常結束，如果所有并發(fā)的節(jié)點實例都結束（包括手工結束和正常結束），匯聚節(jié)點正常結束，觸發(fā)流程流轉。

1.2.2、匯聚節(jié)點已激活時

節(jié)點0、節(jié)點1、節(jié)點2的掛起和恢復執(zhí)行不會影響匯聚節(jié)點的狀態(tài)（依舊處于執(zhí)行狀態(tài)）；節(jié)點0、節(jié)點1、節(jié)點2的手工結束會影響匯聚節(jié)點的狀態(tài)，每個節(jié)點實例的手工結束會引起匯聚節(jié)點的判斷，如果所有并發(fā)的節(jié)點實例（包括正常結束和手工結束）都結束，匯聚節(jié)點正常結束，觸發(fā)流程流轉。

1.3、用戶掛起、手工結束流程的處理策略

1.3.1、匯聚節(jié)點未激活時

流程的掛起和恢復執(zhí)行不會影響并發(fā)節(jié)點的狀態(tài)（依舊處于執(zhí)行狀態(tài)），節(jié)點0、節(jié)點1、節(jié)點2會被全部掛起或恢復；流程的手工結束會引起所有節(jié)點的手工結束。

1.3.2、匯聚節(jié)點已激活時

流程的掛起和恢復執(zhí)行不會影響匯聚節(jié)點的狀態(tài)（依舊處于執(zhí)行狀態(tài)），節(jié)點0、節(jié)點1、節(jié)點2未執(zhí)行結束的實例會被全部掛起或恢復；流程的手工結束會引起所有節(jié)點的手工結束。

2、nOutOfM匯聚（圖1）

根據情況觸發(fā)節(jié)點0、節(jié)點1、節(jié)點2中的一個或多個，匯聚節(jié)點等待N個實際觸發(fā)的節(jié)點完成后即執(zhí)行流轉（N>0且N<M，M為實際觸發(fā)的節(jié)點個數），在N<=0和N>=M的情況下即為同步匯聚。中間匯聚節(jié)點只會產生一個實例。

2.1、正常流轉時的處理策略

當匯聚節(jié)點未被觸發(fā)時（即節(jié)點0、節(jié)點1、節(jié)點2都未執(zhí)行結束），并發(fā)節(jié)點處于執(zhí)行狀態(tài)，一旦匯聚節(jié)點被觸發(fā)（即節(jié)點0、節(jié)點1、節(jié)點2有一個執(zhí)行結束），并發(fā)節(jié)點正常結束并且匯聚節(jié)點處于執(zhí)行狀態(tài)，N個并發(fā)出的節(jié)點實例執(zhí)行結束后，匯聚節(jié)點正常結束，流程繼續(xù)流轉，M-N的節(jié)點實例被手工結束。

2.2、用戶掛起、手工結束相關節(jié)點的處理策略

2.2.1、匯聚節(jié)點未激活時

節(jié)點0、節(jié)點1、節(jié)點2的掛起和恢復執(zhí)行不會影響并發(fā)節(jié)點的狀態(tài)（依舊處于執(zhí)行狀態(tài)）；節(jié)點0、節(jié)點1、節(jié)點2的任一手工結束都會觸發(fā)匯聚節(jié)點，使并發(fā)節(jié)點正常結束，如果N個并發(fā)的節(jié)點實例都手工結束，并發(fā)節(jié)點正常結束，觸發(fā)匯聚節(jié)點，匯聚節(jié)點正常結束，觸發(fā)流程流轉，M-N的節(jié)點實例被手工結束。

2.2.2、匯聚節(jié)點已激活時

節(jié)點0、節(jié)點1、節(jié)點2的掛起和恢復執(zhí)行不會影響匯聚節(jié)點的狀態(tài)（依舊處于執(zhí)行狀態(tài)）；節(jié)點0、節(jié)點1、節(jié)點2的手工結束會影響匯聚節(jié)點的狀態(tài)，每個節(jié)點實例的手工結束會引起匯聚節(jié)點的判斷，如果N個并發(fā)的節(jié)點實例（包括正常結束和手工結束）都結束，匯聚節(jié)點正常結束，觸發(fā)流程流轉，M-N的節(jié)點實例被手工結束。

2.3、用戶掛起、手工結束流程的處理策略

2.3.1、匯聚節(jié)點未激活時

流程的掛起和恢復執(zhí)行不會影響并發(fā)節(jié)點的狀態(tài)（依舊處于執(zhí)行狀態(tài)），節(jié)點0、節(jié)點1、節(jié)點2會被全部掛起或恢復；流程的手工結束會引起所有節(jié)點的手工結束。

2.3.2、匯聚節(jié)點已激活時

流程的掛起和恢復執(zhí)行不會影響匯聚節(jié)點的狀態(tài)（依舊處于執(zhí)行狀態(tài)），節(jié)點0、節(jié)點1、節(jié)點2未執(zhí)行結束的實例會被全部掛起或恢復；流程的手工結束會引起所有節(jié)點的手工結束。

3、辨別匯聚（圖1）

是nOutOfM匯聚的特例，N=1

4、多實例匯聚（圖2）

圖2

根據情況觸發(fā)節(jié)點0、節(jié)點1中的一個或多個，節(jié)點0和節(jié)點1任意一個執(zhí)行結束后都會觸發(fā)匯聚節(jié)點產生一個新的實例，匯聚節(jié)點實例緊接著觸發(fā)節(jié)點2，節(jié)點2也會產生多個實例。

4.1、正常流轉時的處理策略

當匯聚節(jié)點未被觸發(fā)時（即節(jié)點0、節(jié)點1都未執(zhí)行結束），并發(fā)節(jié)點處于執(zhí)行狀態(tài)，一旦匯聚節(jié)點被觸發(fā)（即節(jié)點0、節(jié)點1有一個執(zhí)行結束），匯聚節(jié)點會緊接著觸發(fā)節(jié)點2，匯聚節(jié)點正常結束。所有并發(fā)出的節(jié)點實例執(zhí)行結束后，并發(fā)節(jié)點正常結束。

4.2、用戶掛起、手工結束相關節(jié)點的處理策略

節(jié)點0、節(jié)點1的掛起和恢復執(zhí)行不會影響并發(fā)節(jié)點的狀態(tài)（依舊處于執(zhí)行狀態(tài)）；節(jié)點0、節(jié)點1的手工結束會影響并發(fā)節(jié)點和匯聚節(jié)點的狀態(tài)，每個節(jié)點實例的手工結束會引起匯聚節(jié)點產生新的實例并觸發(fā)節(jié)點2，同時會引起并發(fā)節(jié)點的判斷，如果所有并發(fā)的節(jié)點實例都手工結束，并發(fā)節(jié)點正常結束。

4.3、用戶掛起、手工結束流程的處理策略

流程的掛起和恢復執(zhí)行不會影響并發(fā)節(jié)點的狀態(tài)（依舊處于執(zhí)行狀態(tài)），節(jié)點0、節(jié)點1、節(jié)點2會被全部掛起或恢復；流程的手工結束會引起所有未結束節(jié)點的手工結束。

5、隱式結束，沒有匯聚節(jié)點與并發(fā)節(jié)點對應（圖3）

圖3

所有節(jié)點結束時（正常結束或手工結束），并發(fā)節(jié)點正常結束。流程的手工結束會引起所有未結束節(jié)點的手工結束。

四、流程實例狀態(tài)變化對節(jié)點實例狀態(tài)造成的影響

1、流程實例的掛起

   A類節(jié)點掛起，B、C類節(jié)點不受影響。同時在流程實例恢復執(zhí)行之前，A類節(jié)點不允許用戶直接恢復執(zhí)行。

2、流程實例的手工結束

   所有節(jié)點全部手工結束。

五、節(jié)點實例狀態(tài)變化對流程實例狀態(tài)造成的影響

隱式結束的情況下，節(jié)點的手工結束或正常結束都會觸發(fā)流程的判斷，如果所有的節(jié)點都已結束則流程結束。

用戶的需求大概分為兩部分：一部分是整個項目完全基于工作流來搭建開發(fā)，這也是很多工作流廠商患有“平臺壓迫癥”的原因；另一部分是將工作流作為業(yè)務組件加入已有的項目中，推動業(yè)務的“審批”流轉。

前者的要求顯然更高，但也意味著有更多的利潤。其實這一部分的用戶又可以進一步的細分：一是技術能力比較差的公司，他們通過層層外包接到項目，而又沒有實力自己開發(fā)，于是想通過采購工作流加上幾個剛入門的程序員來完成整個項目的開發(fā)（這類用戶往往也是業(yè)務平臺最大的客戶群），他們想著是一整套的開發(fā)解決方案，甚至包括業(yè)務分析；二是對業(yè)務編程的需求，他們需要流程引擎能夠侵入業(yè)務編程的內部，對業(yè)務的狀態(tài)和生命周期進行靈活的管理，從而最大程度的簡化開發(fā)或者說滿足一些復雜業(yè)務編程的需要。

后者的需求則比較簡單，多是某一行業(yè)的項目公司，突然碰到有審批的需求了，采用工作流多是滿足人工“審批”的需要，以及部分的統(tǒng)計分析。

需要承認，工作流其實與最終用戶還差得很遠，也就是說在眾多廠商的網頁上，那副著名的業(yè)務流程生命周期其實是一句空話。一句話說，就是那個什么流程設計器是給程序員用的，至于用戶，哪涼快哪去。也就是說現在的工作流還不能給最終用戶提供價值。OK，既然工作流的價值是提供給集成商的，集成商就會考慮成本，于是工作流能否提供一個完整的開發(fā)解決方案就成了最重要的考量。

最后說說市場。工作流其實有著很大的市場，只不過這個市場被開源工作流和平臺瓜分掉了。因為目前的工作流不能給最終用戶提供價值，所以集成商在遇到審批的需求時，首先想到的會是開源的工作流引擎，從jbpm、osworkflow的流行也可以看出這一點，并且知識的積累確實比購買工作流來的劃算，同時很多公司通過積累也會有自己的流程組件，這并沒有太大的難度。難度留給技術能力一般的公司，他們首先想到的會是一整套解決方案而不僅僅止于流程服務，于是平臺出現了，平臺說：“灰殼顯靈，銀彈來了。”

關于平臺，有一個很時髦的流行詞匯，叫“業(yè)務應用基礎平臺”，稍候待續(xù)。 py工作流是國內比較好的工作流之一。大概看過它的一些文檔，分析一下。
1、路由模型
 py支持的工作流模式其實并不多，只是支持1到7七種模式而已，其中比較重要的是模式6和模式7，即M選N分支和M選N聚合，看過它的實現，利用轉移線條件來觸發(fā)轉移線，從而觸發(fā)后續(xù)的節(jié)點。這樣做比較簡單，但是同時也存在很多問題，例如在路由非常復雜的情況下，例如多個分支節(jié)點的串聯，以及并發(fā)路由存在多個節(jié)點時，這種做法實現起來就非常困難。另外，并發(fā)路由的工作流變量會存在相互沖突的情況，也包括業(yè)務數據的沖突。可以說py的路由模型還是很簡單的，支持簡單的業(yè)務可能沒有問題，對于復雜的業(yè)務可能需要很多其他額外的辦法。當然，很多國內的工作流甚至連模式6和模式7都支持不了，同時工作流的應用目前還具有很濃的“審批”的影子（貌似有人很討厭審批這個說法），所以目前的路由模型應該滿足需求了。
2、任意路由和回退
 沒有看到任意路由和回退的復雜示例。關于任意路由，產品說明中說到可以在整個流程范圍內任意自由路由，我覺得這個說法本來就是有問題的，并發(fā)路由的情況下，并發(fā)支線往主線上跳轉，這種情況會有很多問題存在，其他并行的支線如何處理？或者說根本就沒有考慮到這些復雜的情況？回退也是一樣的道理，至于業(yè)務補償的提出還是不錯的，不過推給了用戶自己設置回退動作。
3、關于WFMC和BPEL規(guī)范
 看看流程定義文件就知道了，它不支持任何規(guī)范。敢說國內工作流的流程定義就沒有遵循規(guī)范的。
4、參與者的指定
 提供了組織機構、角色、個人這三種常見的參與者設置模式，還提供了流程啟動者、活動執(zhí)行者、從相關數據或從規(guī)則邏輯中獲取參與者的模式。
5、工作的代理和代辦
6、時間服務
 提供了四種時限。活動提醒、活動執(zhí)行、流程提醒、流程執(zhí)行。
7、業(yè)務開發(fā)
 感覺這是非常出彩的地方，在一個簡單的示例中幾乎不需要任何編碼，比如一個簡單的請假管理。看看它的流程定義文件，它幾乎將整個業(yè)務表單都嵌入到流程定義里去了。這樣做是否合適？我個人傾向于引擎與業(yè)務完全分開，通過反射或者某種映射將兩者關聯到一起。如果是用戶自己開發(fā)已有的復雜業(yè)務，如何將工作流嵌入？至于studio也是非常出色的，具有開發(fā)調試的功能。調用接口非常的清晰。
總結一下：py工作流還是一個不錯的工作流引擎，拋開它的宣傳，感覺引擎的實現還是有些簡單，或者說只是滿足了目前的一些常見需求，至于所說的SOA和服務編排，我覺得目前還不現實。它的優(yōu)勢在于與其平臺的完全融合，能夠利用很多既有設施，可是這又何嘗不是把雙刃劍？另外，強大的市場宣傳和良好的服務團隊也是選擇工作流時的重要考慮。 委辦是什么？即分發(fā)給A的工作項可以委派給B代為進行處理。委辦只針對個人。委派給組織或崗位似乎沒有意義。
一、委辦的分類
 1、用戶單一工作項的委辦以及收回委辦
 2、用戶所有工作項的委辦，全權委辦
 3、用戶按流程劃分工作項的委辦，基于模板的全權委辦，也可以理解為基于業(yè)務的委辦
二、委辦的觸發(fā)與終止
 1、對于單一工作項的委辦，在待簽收和待辦工作項列表需要出現委辦的功能按鈕，由用戶選擇其他用戶代為辦理。工作項委辦后進入委辦工作項列表，用戶可以收回委辦，同時用戶和被委辦人都可以對該工作項進行辦理，用戶自己處理則工作項自動被收回委辦。
 2、對于全權委辦以及基于模板的全權委辦，需要委辦申請單。用戶通過填寫委辦申請單，將某段時期內工作項列表的處理工作委派給他人。消息通知：當用戶將工作委派給指定的被委辦人時，被委辦人可以收到提醒消息。
 3、委辦的自動終止以及手動結束：當委托的時間到期時，委辦功能自動終止，委辦申請記錄將只讀。用戶也可以手動結束委托，邏輯刪除或對委辦申請記錄進行修改。維護委辦申請列表。
三、委辦工作項列表
 1、用戶可以在委辦列表里對委辦的工作項狀態(tài)進行跟蹤，對于還未被被委辦人簽收的工作項可以收回或直接辦理
 2、被委辦的工作項進入委辦人的委辦列表
 3、被委辦的工作項按狀態(tài)進入被委辦人的待簽、待辦和辦結列表，注明是被委辦即可
 4、委辦工作項的再委辦，工作項增加委辦的說明字段，委辦工作項的依次狀態(tài)影響
四、其他
 1、提交工作項頁面，選擇用戶出現委辦人時，名字紅現，括弧注明其將被委辦的被委辦人
 2、提交工作項頁面，選擇部門或角色包含委辦人時，不做處理。引擎生成工作項時做出處理，對工作項做出委托說明
 3、流程跟蹤列表，增加委辦說明字段 既然是與用戶相關的權限，那么權限的表現則一定與UI緊密相連。工作流管理系統(tǒng)里，用戶與工作流的交互界面有四種：
1、流程設計器
    流程設計器的功能比較單一：定義或更新流程定義。里面涉及到包、模板和版本的概念。資源即流程模板（例如發(fā)文模板、收文模板），權限可以細分為：維護、只讀以及不可見。
2、流程管理控制臺
  對流程實例（包括活動實例和工作項實例）進行管理。這里對資源的劃分有兩種方式：操作和數據。從操作來分比較瑣碎，例如：流程實例的掛起、終止、恢復、跳轉，活動實例的掛起、終止、恢復等等，當然可以做一種集合，例如：對流程實例的管理、對活動實例的管理、對工作項實例的管理、時間服務的管理等等。從數據劃分則很好理解，例如：發(fā)文的流程實例、收文的活動實例等等。兩種方式的組合構成最終的權限。
3、工作項列表
    這個似乎沒什么好說的，工作項直接分配到用戶、部門和崗位。
4、與流程相關的業(yè)務數據
    用戶對業(yè)務自身的權限以及不同流程節(jié)點對業(yè)務的權限。看問題的兩種方式。業(yè)務數據處于流程中時由流程決定權限，例如擬稿時可以操作哪些字段，審批時是否可以上傳附件等等。流程結束后，業(yè)務數據歸檔，此時的權限由業(yè)務權限+流程權限組合。簡單的一個例子：普通用戶A可以在發(fā)文模塊里看到自己參與過的所有發(fā)文文件，發(fā)文管理員B則可以看到發(fā)文模塊里所有的發(fā)文文件。
    
結合具體的業(yè)務需求：
1、主控崗位的提出。例如發(fā)文管理，存在主控崗位，可以對所有的發(fā)文流程進行管理，催辦、督辦等等。
2、大集中模式下對數據的再劃分。還是以發(fā)文管理為例，北京公司的發(fā)文管理員對北京的發(fā)文數據進行管理，上海公司的發(fā)文管理員則只能對上海的發(fā)文數據進行管理。

最終的權限分類：
1、流程設計器里流程模板的可見與不可見。可見即可維護。
2、流程管理按操作來分顯得沒有實際的意義，用戶關注的是業(yè)務數據即操作的范圍。流程實例（活動實例）的可見與不可見。可見即可操作。更進一步說，用戶甚至根本都不會登錄到流程管理控制臺，他會傾向于在業(yè)務菜單里有自己相應的流程管理功能，例如在發(fā)文管理里增加發(fā)文催辦、督辦等等。
3、不用
4、往業(yè)務權限表里增加流程參與者的權限信息。

總結：總是感覺工作流管理部分的權限不是那么的必要，流程定義的復雜度讓最終用戶很難直接使用，流程實例的管理更多的是契合到業(yè)務中去，而這種契合表現則是流程數據按業(yè)務進行劃分后的管理。