當面對一個完整的工作流系統時，你可能會被它眾多的功能所困惑：流程流轉模式、時間服務、組織適配、表單權限等等。但是如果我們轉換一種思路，首先從用戶使用的角度來進行分析，工作流系統的組成就會變得異常清晰。實際在現實開發中，整個系統也是由用戶的業務需求一步步迭代而來。

 

一、        從用戶的角度分析工作流系統的組成

這里的用戶分為兩類：一類是應用系統開發人員（以后簡稱開發人員），一類是應用系統的最終用戶（以后簡稱最終用戶）。對于最終用戶而言，工作流系統往往是不能直接使用的，它需要由IT部門的開發人員嵌入到應用系統中。開發人員才是工作流系統的直接使用者，這造成了問題：工作流系統更多關注于開發人員的需求，例如如何快速開發、如何更好的嵌入業務邏輯等等，而最終用戶的需求被或多或少的忽略了。

這里從最終用戶的角度進行分析。

 

1、                    面向開發人員的流程設計器

最終用戶通過流程設計器對業務流程進行描述，實際是一個流程建模的過程。理論上，業務分析師完成這個業務流程建模的過程，并且業務分析師往往被假定為非技術人員。對于業務分析而言，流程建模通常是抽象的，一定程度上是模糊的，建模的目的在于通過圖形的形式向其他人解釋一個業務的過程，圖形只是一種方式，采用它只是它更易于理解和易于溝通，實際類似于DSL。實際上企業的規章制度、文字描述的執行流程都是對業務流程具體的描述方式。

 

對于工作流而言，這個建模所產生的流程是需要被引擎執行的。這就要求流程中每一個節點的定義都是要有明確含義的，它需要被計算機明確而準確的解釋。同時，出于集成業務系統的需要，流程模型定義往往帶有很多額外的屬性。

 

所以現實中的流程設計器往往屬性配置繁多。導致最終用戶在打開設計器后根本無從修改和建模，他需要關注很多與業務無關的配置，無意中的修改往往產生流程無法運行的后果。

 

2、                    工作項列表

即任務列表。工作流系統通過工作項列表進行人工任務的分配。最終用戶通過該列表簽收、處理每天的工作，工作以工作項的形式展現。對于工作項，用戶有著多種業務操作：簽收、完成提交、收回、回退等等。對于分配給他人的工作項，也存在著多種業務操作：催辦、提醒、時間限定等等。

 

3、                    流程追蹤

用戶在處理工作項時，對該工作在流程中所處的位置進行查看，了解當前流程的狀態和執行情況。一般情況下，流程追蹤以圖形化的方式展現。用戶通過不同的圖標和標示來區分流程中各個節點的狀態和參與者信息。

 

4、                    流程實例管理

包括流程實例、節點實例、工作項實例的管理。改變狀態，包括了掛起、重新啟動、終止、跳轉等等。主要目的在于對流程人為執行錯誤進行人工干預以及對流程信息的監控。

 

二、        系統架構

從用戶的角度分析完工作流系統的組成，這里從開發人員的角度分析工作流系統的架構。系統架構里的每一部分是如何與用戶使用的部分進行對應，以及每一部分在實現時需要注意的事項。

 

1、                    整體構成

如圖，各模塊分層組織，位于上層的模塊依賴于底層的模塊。正如你所看到的，流程定義模型位于整個工作流系統的最低層，因為它是整個工作流系統的基礎。

 

流程定義模型：定義對流程進行描述的所有對象。因為對流程進行描述的本質就是利用這些模型進行建模，所以這些模型對象的實現直接決定著工作流系統對流程的描述能力。

 

組織結構適配器：工作流系統在與業務系統進行集成時，需要進行組織適配，通過這一過程將業務系統里的組織機構導入到工作流系統里。具體實現時，工作流系統需要建立起自己的組織機構模型（包含在流程定義模型里），要適應多種業務系統，往往需要建立多套模型，根據具體情況進行切換。有多種方式完成這個適配，最簡單的方式是利用SQL配置讀取數據進行語義轉換。

 

流程設計器：供用戶使用的可視化圖形工具。每種圖形都對應著一種流程定義模型。具體的實現有Swing、SWT，但是基于AJAX的WEB設計器無疑會提供更好的可用性。

 

流程執行引擎：將流程定義模型解釋為流程實例模型。利用這些流程實例模型完成流程的調度和執行。在工作流系統里，執行引擎是整個系統的核心。實現時不僅需要考慮各種流程調度的實現，還要考慮執行的效率、緩存、日志等等。

 

工作項引擎：解析參與者定義模型和工作項定義模型，生成相應的工作項。對用戶對工作項的操作作出響應。

 

WEB應用：工作流系統的WEB展現。包括了工作項列表、流程追蹤以及流程實例管理的操作和顯示。

 

流程仿真：對建立好的流程模型進行運行仿真，模擬流程模型的執行過程。目的在于發現流程建模過程中的疏漏，發現由此導致的流程不能運行。

 

時間服務：提供對整個流程實例執行時間和任務執行時間的控制，根據規則觸發相應的時間事件，例如任務超時、任務預警等等。根據規則自動觸發啟動新的流程實例。

 

業務集成：提供工作流系統與業務系統的契合方式。典型的實現包括通過注冊事件監聽器和提供接口抽象類調用業務系統代碼、提供API給業務系統調用、工作項驅動業務表單和腳本引擎執行業務邏輯腳本等等。特定于工作項驅動業務表單，為方便開發，絕大多數的工作流廠商都提供了電子表單的實現。

 

2、                    基于事件的流程執行引擎

流程執行引擎的主要職責就是負責流程的調度和執行。

 

首先需要將流程定義模型解釋為流程實例模型，在定義模型和實例模型之間建立起對應關系。一個簡單的對應關系如下圖所示：

 

執行引擎將流程定義模型的屬性讀取到相應的實例模型里，由實例模型完成流程的調度和執行。當然，上圖只是一個簡單的描述，實際情況要復雜的多，特別是節點定義（ActivityDefinition），根據實際應用，往往存在著多種類型，典型的有開始節點（StartDefinition）、任務節點（TaskDefinition）、自動節點（AutoDefinition）、分裂節點（SplitDefinition）、匯聚節點（JoinDefinition）、結束節點（EndDefinition）等等。這些節點的實例根據類型的不同執行不同的邏輯。其中，分裂節點實例和匯聚節點實例負責流程的調度，它們決定流程的流向，通常情況下，它們會調用一個腳本引擎執行一段腳本來決定流程的流向，同時，也會提供對外暴露的接口，由業務系統實現，接口返回的結果決定流程的流向。任務節點實例和自動節點實例則負責流程的執行，為保證流程執行引擎職責的清晰以及對外圍設施的松耦合，它們只是發布相關的事件，通過事件發布/訂閱機制來觸發具體的邏輯執行。

 

典型的事件有流程啟動事件、流程結束事件、進入節點事件、離開節點事件、時間事件等。例如，任務節點實例的進入節點事件將會觸發工作項引擎生成工作項（Workitem），并觸發時間服務器開始計時。

 

3、                    基于充血模型的工作項引擎

對最終用戶而言，大部分的業務操作都集中在對工作項的操作上。常見的包括工作項的提交、收回、委派、追加和退回。這些操作從系統設計的角度不僅涉及到工作項（Workitem）對象內部狀態的變化，而且影響到流程執行引擎的調度以及相關的其他工作項對象狀態。

 

工作項引擎的職責包括兩部分。第一，監聽任務節點實例的進入事件，生成工作項實例。第二，處理上面提到的各種工作項操作。

 

實現時，工作項生成器根據任務參與者的執行模式典型的分為四種情況：

 

競爭參與，當有多個參與者參與該任務時，產生競爭，誰先開始這項工作，就由誰負責完成該工作。此時，工作項生成器生成多個工作項實例，在某個工作項完成時會終止其余工作項。

順序參與，多個參與者按照指定的順序完成該工作。A完成之后由B完成，B完成之后再交給C完成。此時，工作項生成器生成多個工作項實例，根據順序依次激活各個工作項。

共同參與，多個參與者同時對工作進行處理。此時，工作項生成器生成多個工作項實例并全部激活。

智能決策，存在多個參與者的情況下，工作項生成器能夠根據一定的指標（由數據分析，例如人員的處理效率，工作負載等等）和規則來決定該節點的參與者并為其生成相應工作項。這里涉及到算法。

 

對于工作流系統而言，各種流程實例對象都是充血模型。特定于各種工作項操作的處理，此時的工作項對象亦設計為充血模型，將業務邏輯封裝到領域模型里，簡化領域模型之間的交互，省去頻繁的get/set。由領域模型再委派到具體的處理類里。

Client->(Business Facade)->Domain Model->service->Data Access(DAO)

 

4、                    工作項驅動業務表單的業務集成方式

最終用戶對任務的處理，必然由工作項對應著某一業務表單。用戶在工作項列表里選擇自己需要辦理的工作項，由工作項導航到業務表單。

 

特定于WEB系統，業務表單的導航由url完成。在流程定義模型設計時，將url設置入節點屬性，生成工作項時將此url保存在工作項對象屬性里。點擊工作項詳細信息時即打開該url，完成到業務表單的導航。業務表單頁面通常需要引入處理工作項邏輯的父頁面或者導入定制的js庫，這些父頁面或js庫由工作流產品提供。這樣，對于業務表單編寫，工作流邏輯是透明的。

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