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

 

一、        從用戶的角度分析工作流系統(tǒng)的組成

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

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

 

1、                    面向開發(fā)人員的流程設計器

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

 

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

 

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

 

2、                    工作項列表

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

 

3、                    流程追蹤

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

 

4、                    流程實例管理

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

 

二、        系統(tǒng)架構

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

 

1、                    整體構成

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

 

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

 

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

 

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

 

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

 

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

 

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

 

流程仿真：對建立好的流程模型進行運行仿真，模擬流程模型的執(zhí)行過程。目的在于發(fā)現(xiàn)流程建模過程中的疏漏，發(fā)現(xiàn)由此導致的流程不能運行。

 

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

 

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

 

2、                    基于事件的流程執(zhí)行引擎

流程執(zhí)行引擎的主要職責就是負責流程的調(diào)度和執(zhí)行。

 

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

 

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

 

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

 

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

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

 

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

 

實現(xiàn)時，工作項生成器根據(jù)任務參與者的執(zhí)行模式典型的分為四種情況：

 

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

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

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

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

 

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

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

 

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

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

 

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

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