網上到處都有一篇被稱為《優秀的工作流殷勤的144個標準》的文章，文章寫的很全面，但其對實際應用的滿足程度還是需要改進的，我在此拋磚引玉的對其做了寫評價和擴展，在我的《面向業務開發應用》博文中有部分體現。希望網友有所借鑒。

一般性功能 (General Functions)
1. 免程序開發(No Programming or Scripting)??
??評論：很多工作流廠商都在狂吹自己的零代碼特性，但實際應用卻需要大量腳本，所以他自己也達不到，很多事前/事后動作要免程序就必須引入“自動執行步驟”的概念

2. 可處理大量流程工作 (Volume Transaction Processing)
評論：這與應用場合有關，用友的ERP 20多個用戶就十幾萬元，服務器的負載比上千用戶工作流可能都大。
? ?? ? 在架構上，如果是常規的B/S，只能通過服務器群集解決大用戶量接入問題，但如果能夠將業務處理的計算工作分配到客戶端，將會是另一個世界。

3. 三層式彈性化架構(Three Tier, Scaleable Architecture)

4. 穩定的信息傳遞架構(Robust Message Transports)

5. 流程反向回傳/抽單(Process Rollback)
?? 評論： 國內的叫法是回退流，但回退操作復雜，易對業務流程造成很大傷害，很多國際大牌產品并不支持，真正的操作應是撤銷失效。

6. 支持LDAP 目錄服務

7. 支持企業級數據庫 (Support for Enterprise Databases)

8. 動態用戶授權(Active User Licensing)
? ? 評論：有關系統授權數的問題，還應該具有一種功能為預約授權，如如果授權數有限，則大老板必須具有登錄能力，這個坑一直要給他留。

9. 統一的登入ID 與密碼(Unified ID/Password)
原意： 使用者在進入上述系統時，不需要以不同的ID登入兩次
評論：實現SSO有多種方式，其一是第9點所提，比如AD集成就是一個很常見的實現途徑，但由于很多企業沒有AD集成，就需要采用另一種方式，即自動登錄：系統通過識別登錄人的主機、客戶端ID等復合條件自動判斷是否允許其登錄，自動登錄往往結合了系統啟動自動運行（比如QQ的模式），但由于絕大部分工作流產品都是B/S架構，實現起來很滑稽(系統啟動后自動談出個IE來，客戶一巴掌關掉就像拍死支蒼蠅）。

10. 使用者網域安全性(User Domain Security)
??評論： 安全接入考慮的是認證過程的安全（通道加密，認證流程的可靠性等），在企業內部工作不需要太多限制，而異地接入一方面可采用諸如一次性密碼等方式，還需要有能力對登錄用戶的異地訪問權進行限制。甚至對業務流程進行異地操作限制。這點很多產品做不到。

流程與窗體設計功能 (Designer)
11. 圖形化工作流程圖(Graphical Workflow Maps)
評論： 現在絕大部分的產品都是用圖形化流圖，但都是單一流圖，稍微復雜些的流程會產生大量的交叉，可讀性還不如配置方式的好看，根本的解決方法是多視角流程圖。目前沒有哪家廠家提供。

2. 基于角色的路由(Role Based Routing)
原意：基于角色的路由不同于以員工姓名為依據，如果職務發生變化(這在企業是屢見不鮮的常事)，流程設計不需變動。
評論： 目前工作流產品都是僅加入角色允許操作選項，這種功能會造成很多麻煩，比如我想實現除A以外所有K角色的人都可操作，只能設置一個K‘角色，然后新增人員時還要小心翼翼的處理K與K’，根本的方法是增加拒絕的選項

13. 平行會簽(Parallel Routing)
原意：企業內部有許多作業必需平行處理以提高效率，舉例來說：有 5 位部門經理需要提出年度預算報告，每一部門之報告為獨立提出，故可將五位經理定義在同一步驟內，各自處理后再統一送到下一步驟。
評論：諸多會簽可有另一種處理方式：各個簽收業務是總簽發業務的從屬業務，啟動總簽發業務后會自動根據要求簽收的成員創建簽收子業務，每個簽收子業務可以獨立運行，總簽發業務在所有簽收子業務完成后進入下一步驟。

14. 基于關系的路由(Relationship Based Routings)
原意：大部分企業流程是構建在從屬關系上的：申請差旅費需由部門經理核準、員工績效由上級主管評定…等等。如果通過指定某人向某人匯報來實現關系路由顯然不科學（對大的企業也不可能），所以能依據從屬關系來決定流程傳遞方向的功能更顯重要。
評論：在實際企業中經常存在一個員工有兩個上級的情況，此時的“關系路由”會非常錯亂，解決的途徑就是要使系統的組織管理部分支持“多身份管理”，如余責成以副站長身份時上級是吳站長，而以潛伏間諜身份時上級是xxx。

15. 工作隊列(Queues)
原意：在企業內經常有“多人處理同一種工作”的情況。為提高工作效率，合理分配工作量，對于這種隊列工作方式而言，合理的處理方法不是直接傳送給特定個人，而是傳送至Queue，Queue 的成員一旦有時間，便可向Queue
要求接收新的工作。
評論：采用隊列的方式，引擎內部不可避免的要進行輪詢運算，這種輪詢運算是非常耗資源的，另一種解決方式是“等待信號"模式，即客戶端完成手頭工作后立即發出空閑信號，系統將新業務傳遞給它處理，這種模式的效率會非常高，但由于基于B/S的架構是短鏈接的無模式體系，實現起來非常困難，解決的途徑就是拋開基于web的 B/S架構，直接使用基于長連接的新的通信架構。

16. 圖形化數據路由(Graphical Data Routing)

17. 動態會簽(Dynamic Routing)

18. 條件化步驟(Conditional Steps)

19. 條件化步驟跳躍(Conditional Jumps)

20. 條件化取消流程(Conditional Aborts)
評論：除了取消流程操作支持，還需要有刪除記錄的支持，比如對于一些不需要保存的臨時授權審批記錄，在關閉時自動刪除記錄會節省數據庫空間，加快系統的運行速度

21. 條件化退回(Conditional Returns)

22. 條件化收件人(Conditional Recipients)
原意：在許多企業環境里，工作的分派是依照各人的職責或它的專長。因此，工作流程自動化軟件必需提供依實際狀況決定分派工作給誰的功能。
評論：目前很多產品支持步驟定義“靜態”的操作人，通過流轉條件到對應流轉步驟時，操作人可以處理業務，對于動態操作，目前僅有“自由流”或“群組”支持，而缺乏更加靈活的操作設定 ，如下一步操作人是由以前交互操作，甚至計算出來的人員。因此很多應用場景仍然無法支持。

23. 條件定義清單(Event Condition Tables)
原意：現代企業組織內，每天都要面對各種例外狀況與特殊事件。因此，邏輯判斷與例外處理功能是否強大，是決定工作流程軟件優劣的重要指標，它可以依照企業內的規范，以及個案的特殊狀況，聰明地將工作傳遞到正確的處
理人員手上。
24. 條件定義清單與其它步驟互動(Status Variables in Event Condition Tables)
愿意：在許多情況下，我們必需由其它步驟的處理狀況(或現況)來決定工作/決策的未來動向。應該要求軟件實現提供其它步驟目前的狀況信息，工作流設計工具能使用其它步驟的現況資料，來定義此步驟條件清單以控制資料的流
向。
23，24評論： 使用鏈表式工作流引擎的架構（如PETRINET,FSM等），對于分支的處理都是采用子鏈方式解決，一到跨鏈流轉就歇菜，因此對于復雜的流轉及例外，這種引擎體系是病根，根本的解決途徑是采用網狀流轉引擎

25. 退件(Return Step)

26. 動態定義群組(Dynamic Groups)
原意：“群組”（或我們熟知的“項目小組”）常常是為了完成特定工作而成立的編組，而工作流軟件必須能定義并使用動態編組功能以適應這種業務需求。所謂“動態”是指能在流程執行時動態指定群組成員，而非在流程設計時。用戶可以直接輸入群組的成員名單、或由數據庫讀取名單或從數據庫讀取名單。
評論：這是很重要的一項功能，但貌似不少國內產品并不提供這種功能，就該功能還需要擴展，及群組需要有運算能力，如流程中定義的A組，B組，在執行P步驟時要求執行人是A+B.

27. 整合智能型窗體設計工具(Integrated Intelligent Forms Designer)

28. 表格透過服務器端連接數據庫(Server-Side Database Connectivity for Forms)

29. 表格通用變量(Global Variables in Forms)

30. 電子簽章(Signatures)

轉載于:https://www.cnblogs.com/louisding/archive/2012/11/05/2756108.html

總結

以上是生活随笔為你收集整理的有关“优秀工作流引擎”的评价的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。