工作流引擎七大原理

　　工作流引擎

工作流管理聯盟(Workflow Management Coalition, WfMC)早已定義了工作流技術的標準體系，但並未指明具體實現的方法。工作流引擎在實現方法上可以基於不同的軟體技術架構，引擎本身應該是與具體業務無關的，但又需要考慮各類應用領域，工作流引擎設計的重點應該是有一定差異的，但無論基於什麼架構，無論基於哪個領域，有些原理是相通的。

主要是以下方面

　　一、易用性原理

工作流引擎在多數應用中是由客戶或實施人員來設計相關業務流程，因此易用性相當重要，有些工作流引擎的設定器，在設計流程時按照程式碼語言的語法，或其它技術化強的術語去設定，讓人不知道如何開始，也不太容易明白相關設定的具體意義。因此要求圖形化視覺效果，包括流程設計時的圖形化和流程應用時的圖形化。設計時的圖形化以拖拉的方式就能去設定流程，應用時圖形化讓使用者非常直觀的感覺到流程運作情況;也要求操作便利，提供滑鼠單雙擊、鍵盤捷徑、工具欄、流程匯入匯出、列印、節點導航、流程複製貼上、流程校驗等等功能方便使用者快速設定流程

　　二、功能完整性原理

工作流引擎必須支援各種流程特性，包括序列流程、並行流程(分流合流)、子流程、條件路徑、條件人員、環節資訊許可權設定、普通環節、機構環節、會籤環節等等，這裡就不一一列舉了。既然提供使用者在程式碼外定義流程，那麼流程定義工具就要求能夠支撐到所有流程特性。

　　三、資料完整性原理

工作流本身對於業務系統而言，其作用是隱藏在背後，業務系統包括大量的業務處理資料，工作流引擎本身也有資料的處理，如何保證業務資料和流程資料的事務完整性?如何設計才能保證業務資料與流程資料的關聯完整性?流程是自定義的情況下，業務資料如何統計?這些都是設計工作流引擎及工作流應用框架時必須解決的。

相關文章:什麼是OA工作流? OA工作流詳細介紹 工作流三個最重要的特徵

　　四、伸縮性原理

設想一個企業應用，如果公司只幾十個人，又在一個辦公室，工作流應用的價值不是很大，真正有價值的工作流應用是在集團公司大量煩瑣的事件處理，如省級郵政的OA系統，15000的使用者量，跨各個地市的不同流程模式。還有就是大的業務處理量，處理環節涉及多個職能部門，流程引擎協調和處理這些部門和人員之間的工作等，這些應用場景均是大處理量，流程跨越大，而且業務流程本身會有調整，會有不同組織結構層次複用同一流程模式的需求，因此在處理能力上需要有伸縮性，流程設定上也需要有伸縮性。

　　五、擴充套件性原理

工作流引擎設定工具能包括各種特殊許可權的支撐，如交接、跳轉、自動處理、終止流程、自定義時限等等，企業在某些特殊情況下應用流程時不一定需要按照流程設定去運作，流程設定工具能擴充套件特殊許可權的`功能去實現這樣一些特殊要求。 工作流應用框架能夠支撐業務上的擴充套件，如與財務系統整合、ERP整合、訊息平臺的整合、SPS的整合、INFOPATH的整合等。

　　六、介面原理

其實介面是工作流引擎的關鍵，也是物件導向設計與分析的關鍵，工作流應用筐架只需做“我要做什麼”，工作流引擎返回結果，內部“我怎麼做”，是不需要攪在一塊的。關鍵介面包括：啟動、傳送、回收、退回、訊息通知、結束等等，當然實際業務需求中的介面需求遠不止這些。

　　七、可行性原理

現在工作流技術非常流行，很多朋友希望能開發自己的工作流引擎，如果要自己開發，其實可以先考慮以下幾個問題。

1、 經濟的可行性：工作流引擎是需要能幫助客戶創造價值才有前途的，如果我們自行開發的工作流引擎給客戶帶來多大價值，獲得多少回報，對比付出的成本及浪費的機會成本，收益如何?有得賺再自己做。

2、 技術可行性：工作流引擎設計並不複雜，關鍵是穩定、成熟的過程中，其它技術都在發展，工作流引擎需要整合的技術甚至解決方案的思想也在進步，工作流引擎能否與時俱進?盤算一下，如果有把握再自己做。

3、 時間的可行性：工作流引擎本身對客戶來說沒有價值，但可以降低應用開發的成本。具體的企業應用需要工作流引擎時，是否在規定的工期內能夠提供一個穩定可靠的工作流引擎去實現具體應用?計劃一下，來得及再自己做。