工作流引擎
工作流管理聯盟(WFMC)已經定義了工作流技術的標準體系，但是還沒有規定具體的實現方法。工作流引擎的實現方法可以基於不同的軟件技術架構。引擎本身應該是獨立於具體業務的，但是需要考慮各種應用領域。工作流引擎設計的側重點應該是不壹樣的，但無論基於什麽架構或領域，有些原理是相同的。
主要表現在以下幾個方面:1。可用性原則。
在大多數應用中，工作流引擎是由客戶或實現者設計的，因此可用性非常重要。有些工作流引擎設置器在設計流程時是根據代碼語言的語法或者其他專業術語來設置的，讓人無從下手，也不容易理解相關設置的具體含義。所以需要圖形視覺效果，包括工藝設計中的圖形和工藝應用中的圖形。圖形化設計可以通過拖拽來設置流程，圖形化應用讓用戶非常直觀的感受流程的操作；還要求操作方便，提供鼠標單雙擊、鍵盤快捷鍵、工具欄、流程導入導出、打印、節點導航、流程復制粘貼、流程驗證等功能，方便用戶快速設置流程。
第二，功能完整性原則
工作流引擎必須支持各種流程特征，包括串行流程、並行流程(分流和合流)、子流程、條件路徑、條件人員、鏈接信息權限設置、常用鏈接、機構鏈接、會簽鏈接等。，這裏就不壹壹列舉了。由於用戶被提供在代碼之外定義過程，過程定義工具應該能夠支持所有的過程特性。
第三，數據完整性原則
工作流本身隱藏在業務系統的背後，業務系統包含了大量的業務處理數據，工作流引擎本身就有數據處理。如何保證業務數據和流程數據的事務完整性？如何設計才能保證業務數據和流程數據的完整性？流程自定義時如何統計業務數據？這些都是設計工作流引擎和工作流應用框架時必須解決的問題。
第四，可擴展性原則
想象壹個企業應用程序。如果公司只有幾十個人，在壹個辦公室，工作流應用的價值不是很大。真正有價值的工作流應用是集團公司大量繁瑣的事件處理，比如省郵政的OA系統，15000的用戶數，跨城市不同的流程模式。還有大量的業務處理。處理環節涉及多個職能部門，流程引擎協調處理這些部門和人員之間的工作。這些應用場景都是大吞吐量的，流程跨度大，業務流程本身也會有調整，會有不同的組織結構層級重用同壹個流程模型。所以在處理能力和工藝設置上要靈活。
五、發展性原則
工作流引擎設置工具可以包括對各種特殊權限的支持，如移交、跳轉、自動處理、流程終止、自定義時限等。企業在壹些特殊情況下應用流程時，不壹定需要按照流程設置來操作，流程設置工具可以擴展特殊權限的功能來實現這樣的特殊需求。工作流應用框架可以支持業務擴展，如與財務系統、ERP、消息平臺、SPS、INFOPATH等的集成。
不及物動詞界面原理
事實上，接口是工作流引擎的關鍵，也是面向對象設計和分析的關鍵。工作流應用筐只需要做“我想做什麽”，工作流引擎返回結果，內部的“我怎麽做”不需要混在壹起。關鍵接口包括:開始、發送、回收、返回、消息通知、結束等。當然，實際業務需求中的接口需求遠不止這些。
七。可行性原則
現在工作流技術非常流行，很多朋友都想開發自己的工作流引擎。如果想自己開發，其實可以先考慮以下幾個問題。
1.經濟可行性:工作流引擎需要幫助客戶創造價值才有前途。我們自主研發的工作流引擎給客戶帶來了多少價值，獲得了多少回報？對比付出的成本和浪費的機會成本，收益是多少？掙錢就自己幹。
2.技術可行性:工作流引擎的設計並不復雜。關鍵是在穩定成熟的過程中，其他技術也在發展，工作流引擎需要集成的技術甚至解決方案的思路也在進步。工作流引擎能否與時俱進？想好了，有把握就自己做。
3.時間可行性:工作流引擎本身對客戶沒有價值，但是可以降低應用開發的成本。當具體的企業應用需要工作流引擎時，能否提供穩定可靠的工作流引擎，在規定的時限內實現具體的應用？以後自己計劃，自己做。