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和服務編排，我覺得目前還不現實。它的優勢在于與其平臺的完全融合，能夠利用很多既有設施，可是這又何嘗不是把雙刃劍？另外，強大的市場宣傳和良好的服務團隊也是選擇工作流時的重要考慮。

http://www.aygfsteel.com/ronghao 榮浩原創，轉載請注明出處：）