py工作流是國內比較好的工作流之一。大概看過它的一些文件，分析一下。
1、路由模型
py支援的工作流模式其實並不多，只是支援1到7七種模式而已，其中比較重要的是模式6和模式7，即m選n分支和
m選n聚合，看過它的實現，利用轉移線條件來觸發轉移線，從而觸發後續的節點。這樣做比較簡單，但是同時也存在很多問題，例如在路由非常複雜的情況下，例如多個分支節點的串聯，以及併發路由存在多個節點時，這種做法實現起來就非常困難。另外，併發路由的工作流變數會存在相互衝突的情況，也包括業務資料的衝突。可以說py的路由模型還是很簡單的，支援簡單的業務可能沒有問題，對於複雜的業務可能需要很多其他額外的辦法。當然，很多國內的工作流甚至連模式6和模式7都支援不了，同時工作流的應用目前還具有很濃的「審批」的影子（貌似有人很討厭審批這個說法），所以目前的路由模型應該滿足需求了。
2、任意路由和回退
沒有看到任意路由和回退的複雜示例。關於任意路由，產品說明中說到可以在整個流程範圍內任意自由路由，我覺得這個說法本來就是有問題的，併發路由的情況下，併發支線往主線上跳轉，這種情況會有很多問題存在，其他並行的支線如何處理？或者說根本就沒有考慮到這些複雜的情況？回退也是一樣的道理，至於業務補償的提出還是不錯的，不過推給了使用者自己設定回退動作。
3、關於wfmc和bpel規範
看看流程定義檔案就知道了，它不支援任何規範。敢說國內工作流的流程定義就沒有遵循規範的。
4、參與者的指定
提供了組織機構、角色、個人這三種常見的參與者設定模式，還提供了流程啟動者、活動執行者、從相關資料或從規則邏輯中獲取參與者的模式。
5、工作的**和代辦
6、時間服務
提供了四種時限。活動提醒、活動執行、流程提醒、流程執行。
7、業務開發
感覺這是非常出彩的地方，在乙個簡單的示例中幾乎不需要任何編碼，比如乙個簡單的請假管理。看看它的流程定義檔案，它幾乎將整個業務表單都嵌入到流程定義裡去了。這樣做是否合適？我個人傾向於引擎與業務完全分開，通過反射或者某種對映將兩者關聯到一起。如果是使用者自己開發已有的複雜業務，如何將工作流嵌入？至於studio也是非常出色的，具有開發除錯的功能。呼叫介面非常的清晰。
總結一下：py工作流還是乙個不錯的工作流引擎，拋開它的宣傳，感覺引擎的實現還是有些簡單，或者說只是滿足了目前的一些常見需求，至於所說的soa和服務編排，我覺得目前還不現實。它的優勢在於與其平台的完全融合，能夠利用很多既有設施，可是這又何嘗不是把雙刃劍？另外，強大的市場宣傳和良好的服務團隊也是選擇工作流時的重要考慮。
工作流模型分析
工作流模型分析 多例項模型 所謂多例項模型，指的是流程中的同乙個活動，同時存在多個例項。1 非同步 多個例項產生後，這些例項各自為政，互不影響。因為互不影響，所以非同步的多例項模型的產生的例項數是任意的。當說到可以產生的 例項數時，我們說的都是同步的情況，就如下面三點。2 定義期決定例項數 說的簡單...
工作流需求分析
使用者的需求大概分為兩部分 一部分是整個專案完全基於工作流來搭建開發，這也是很多任務作流廠商患有 平台壓迫症 的原因 另一部分是將工作流作為業務元件加入已有的專案中，推動業務的 審批 流轉。前者的要求顯然更高，但也意味著有更多的利潤。其實這一部分的使用者又可以進一步的細分 一是技術能力比較差的公司，...
工作流建模 工作流概念
工作流建模 工作流概念 1 案例 工作流系統得基本目的是處理案例。每個案例都有乙個唯一標識，而且每個案例的生命週期都是有限的。案例生命週期都處於某個特定狀態，該狀態由三個元素組成 1 案例相關的屬性的值 案例屬性是一系列同案例相關的變數。能夠用來管理案例。正是通過這些變數，才有可能指出在特定條件下某...