第一篇：基于WEB的工作流引擎設計和實現

基于WEB的工作流引擎設計和實現

一、引言

隨著社會生產的流程化，工作流（Workflow）起著越來越重要的作業，工作流的核心是流程管理。對于企業來說，其生產經營活動就是由各種各樣業務流程交織在一起組成的。然而，在企業管理中，許多流程在日常操作過程中已被習慣，而不被人們所重視，更不能被有效的管理起來。另外，客戶的需求瞬息萬變，而產品的生命周期也是在不斷縮短，技術在不斷創新。企業要在這樣一個競爭和變換的外部環境中求得生存，就必須要有隨需而變的能力，不斷地調整和優化自身的各種業務流程，對流程進行重構和再造。為此，本文詳細描述了工作流引擎的系統結構、接口設計、功能建模，以及工作流引擎在ERP系統中的應用。

二、工作流技術概述

（一）相關概念

工作流（Workflow）就是工作流程的計算模型，即將工作流程中的工作如何前后組織在一起的邏輯和規則，在計算機中以恰當的模型進行表示并對其實施計算。工作流引擎（Workflow Engine，WfE）的主要功能是通過計算機技術的支持去定義、執行和管理工作流，協調工作流執行過程中工作之間以及群體成員之間的信息交互。工作流需要依靠工作流引擎來調度、實現。

（二）工作流引擎的主要功能

工作流引擎是定義、創建、執行工作流的軟件組元。作為工作流的核心應能提供以下幾個方面的功能支持：解釋過程定義；創建過程實例并控制其執行；調度各項活動；為用戶工作表添加工作項；通過應用程序接口（API）調用應用程序；提供監督和管理功能等。

三、工作流引擎的分析及設計

（一）工作流引擎的功能結構

工作流引擎需要支持兩種業務流程，即確定型工作流和非確定工作流。確定型工作流是指人們可以事先給出運行路線的一類業務流程；非確定型工作流是指人們事先不能給出運行路線的一類業務流程。業務流程的流向應根據實際情況而定。工作流引擎的功能結構圖應該如圖一所示：

圖1 工作流引擎的功能結構圖

（二）工作流引擎控制器分析

引擎控制器是工作流引擎在運行時的控制中心，引擎控制器的控制結構圖如圖二所示：

圖二 引擎控制器的控制結構圖

1．調度中心。調度中心接受從外部接口發送過來有關流程控制的請求，然后根據不同的請求類型調用相應的處理模塊完成與本次請求相關的操作并將結果返回。由于是在DBMS內部實現工作流引擎的控制模型，因此有關請求的并發處理等問題完全可以交給數據庫管理系統來完成，也不需要諸如請求隊列等形式的數據結構。

2．任務管理。任務管理主要根據調度中心的指示完成諸如任務創建、任務狀態的轉換以及相關數據的維護等工作。每次“結束任務”的外部請求將觸發調度中心調用“任務管理”為后繼活動（如果存在的話）創建新的實例，其狀態為“待定”；同時，其他不同的外部請求也將觸發“任務管理”實施任務狀態的切換。

3．任務指派。任務指派處理只是針對常規交互活動，通常情況下，在任務狀態由“待定”切換到“等待”過程中完成任務的指派工作，即處于就緒狀態的任務在通常情況下都確定了其執行者。任務指派過程首先根據任務指派基準確定可以執行此任務的群體人員，通常情況下這是一個包含多個人員的集合；然后根據任務指派方法確定由這個群體中的哪些個體來執行任務，執行任務的個體標識記錄在相應任務記錄的字段中。

4．依賴檢查。在工作流引擎中，業務規則可以分解成活動的前依賴規則和活動的后轉發規則。依賴檢查指的是活動的前依賴規則的檢查，調度中心在將任務切換到就緒狀態之前將進行相關的前依賴規則檢查，只有滿足檢查條件的任務才可以進行狀態的切換。

前依賴規則包含順序、與匯聚、或匯聚和投票匯聚四種規則：

第一，對于順序前依賴規則，從前趨活動流轉到當前活動跟其他前趨活動沒有關系，當前活動的啟動沒有其他約束條件，相應任務可以立即由“待定”狀態轉換到“等待”狀態。

第二，對于與匯聚前依賴規則，相應記錄要指明所有參與與匯聚的其他前趨活動，只有所有相關的前趨活動均到達各自指定的結束狀態，當前活動方可啟動。第三，對于或匯聚前依賴規則，前依賴活動集為空集，此規則的檢查將涉及到業務活動表中的或匯集標志，其取值可以是所有相關的前趨活動的結束標記之一或者是一個特殊的標記。如果或匯集標志不是一個特殊標記，則將檢查相應前趨活動的結束標記是否和或匯集標志相同，若相同，則啟動當前活動，若不相同，則不作任何處理。如果或匯集標志是一個特殊標記，則首先結束的前趨活動將啟動當前活動，后結束的活動將被丟棄。

第四，對于投票匯聚活動，前依賴活動集同樣為空集，當前活動要等到屬于同一批次任務數目達到設置的要求方可啟動。

5．轉發控制。當應用發出“結束任務”的外部請求時，該請求將觸發調度中心啟動“轉發控制”。轉發控制的主要依據在工作流數據模型中定義的后轉發規則，后轉發規則定義了當前活動與其后繼活動之間的關系。

6．啟動控制。啟動控制負責常規自動活動的所對應的自動執行體的啟動并對其活動進行監控。

三、工作流引擎實現

（一）任務表結構

確定型任務表負責保存系統中所有確定型流程的任務實例待處理記錄及任務實例處理的歷史記錄，工作流引擎定期掃描該任務表，將任務表中所有待處理的任務實例分發給相應流程中的相應節點。

確定型任務表的結構為：TaskList(TasklnstanceID，TasklD，TaskStep，TaskHandleTime，ProceeID，DstNodelD，lsHandled，CommmitMan)，分別為：TasklnstaneeID：同一個任務可以有多個不同的運行實例。該字段用于區別多個不同的運行實例；TasklD：用于區別不同的任務；TaskStep：記錄任務運行實例在流程中的處理步驟；TaskHand]eTime：任務運行實例在相應處理步驟中的處理時間；Processed：記錄任務實例所在流程的ID；DstNodelD：處理任務運行實例的后續節點；IsHandled：任務實例在后續節點是否已經處理；CommitMan：任務的處理人。

（二）工作流的流向控制

工作流引擎的一個核心功能就是要決定確定型任務表中各個任務運行實例的后續處理節點，使任務運行實例按照事先定義好的路線流動，也就是流程的流向控制。

流向控制算法描述如下：

／*控制流程流向*／

function HowControl(string processid，string nodeid)｛

string[] followIds= GetSueNodeld(processed，nodeid);

for(int i=0;i

／*后續節點同步控制*／

if(查詢后續節點i所對應的條件中有無isprecondition為true的條件)對后續節點進行同步控制；

／*子流程的處理情況*／

if(后續節點i是子流程)

將子流程的第一個節點作為后續節點；

向任務表中加入一條待處理記錄；

}

}

四、結語

本文介紹了一個基于Web的工作流引擎的具體實現，該工作流引擎已經在藥業管理系統中得到了實際應用，基本上可以達到預期效果，說明基于Web的工作流引擎設計和實現都具有相對可行性，可以應用在具體的管理系統中。

第二篇：輕量級工作流引擎的設計與實現

第一章

引

言1.1 輕量級工作流引擎的概念 輕量級的工作流引擎指的是從夠用、靈活和低成本的設計原則出發，不追求工作流引擎的功能的完備和復雜，只是實現其中必不可少的功能和特征。在設計工作流引擎時主要考慮對其數據模型的定義和解釋、活動之間的協調以及任務的分配和控制等功能提供支持，而不支持諸如提供內建（built-in）的應用開發工具、對應用資料的定義和完整性維護、完善的異常處理以及長事務控制等功能。輕量級工作流引擎的概念的提出，給開發工作流管理系統的開發人員開辟了一條新的道路。工作流管理技術本身就是一項抽象復雜的技術，它致力追求從企事業各種各樣的業務中抽取出一個通用的模型，由這個模型去描述所有業務的一致性，以達到“放之四海皆可用”的程度。不過，要把眾多的而又錯綜復雜的業務都集中在這個模型中，這是一件非常困難的工作，要經過一段漫長的摸索歷程。而輕量級的概念讓我們認識到可以從一般性的而又簡單的業務入手，為企事業快速的開發出一個適應他們本身業務需求的而又帶有可擴展性可移植性的信息管理系統，為他們提高工作效率，并保證在一段很長的時間內滿足不斷增加的業務需求。

1.2 工作流管理系統的分類及本文的側重點

根據工作流過程本身的特點、系統建模的方式、所使用的底層支撐技術、以及工作流過程的執行方式等的不同而對工作流管理系統進行相應的分類。

1.2.1 面向文檔的與面向過程的 前者的側著點在于將電子形式的文件、圖像等在有關的人員之間進行分發，以便能夠得到不同人的處理與審閱。現有的文件管理與映像管理系統均屬此類。在面向過程的WFMS中，工作流被描述成一序列執行環節。與各環節相應都有待處理的資料對象。各環節的資料對象可以按不同的方式分發到其它環節中去，如可以將資料對象的值作為控制條件、或者依此資料對象組裝成其它的資料對象等。高端的WFMS一般都屬此類系統。

1.2.2 結構化的與即席的結構化工作流指的是在實際工作過程中會反復重復、嚴格按照某個固定的步驟進行的業務過程。定義此種工作流所需要的各種類型的信息可以通過對業務過程進行詳細的分析而得到，從而得到完整的過程定義并在以后的應用過程中反復使用。大量的辦公程序，如公文處理、審批等都屬此類。即席工作流則是針對那些重復性不是很強或沒有重復性的工作流程的，關于這類流程執行所需的有關參數(如參加者等)事先無法確定，而必須推遲到過程實例運行時才能確定，同時在執行過程中間還可能會發生一些意外的情況。這種動態多變的特點在提供更高靈活性的同時，也為過程的建模與執行帶來更多的復雜性。1.2.3 基于郵件和基于數據庫

前者使用電子郵件來完成過程實例執行過程中消息的傳遞、資料的分發與事件的通知。低端的系統所使用的經常就是此種方法，它可以充分發揮電子郵件系統在廣域環境下的資料分發功能，但整個系統將運行于一種松散耦合的模式下。在基于數據庫的WFMS中，所有的資料都保存在某種類型的DBMS中，過程的執行實際上就是對這些資料的查詢與處理。高端的大規模系統所使用的一般都是此種方法。

1.2.4 任務推動的與目標拉動的前者指的是從過程的開始逐步地一個環節一個環節的執行，當某個活動實例被處理完之后，后續的有關活動將被創建并被激活，由此直至整個工作流程的完成。這是目前大多數面向過程的WFMS所使用的執行方式。而在目標拉動的WFMS中，一個業務流程被看成是一個目標。過程實例執行時，該目標將被分解得到多個相互之間按一定約束條件的關聯起來的可執行的多個環節，其中各環節還可以當成是子目標而進一步進行分解。在各環節均執行完畢之后，整個過程也就完成了。目標拉動是一種全新的執行方式，下一代的WFMS將具有此種特征。應該說明的是：上述分類只是從不同的角度入手的。一般來說，后面那些特點將給WFMS帶來更好的靈活性，同時也將成為那些能夠支持跨機構的大規模復雜工作流管理、面向關鍵任務的WFMS不可缺少的特征。1.2.5 本文的側重點

本文的側重點不在于完全實現其中一種工作流管理系統的所有功能，更不在于實現所有種類的工作流管理系統的全部功能，前文已經說過，這是一件非常困難的事情。那么我們的側重點在哪里呢？就在于綜合以上四種工作流管理系統的主要特點，是一個面向文件的，基于數據庫的，由目標拉動的結構化的工作流管理系統，并且由此去設計和實現工作流管理系統的核心――工作流引擎。從一般性來說，目前大多數的企事業的業務都是事務申請，公文流轉，各項通知等等，這些業務或者需要查看，或者需要審批，而這些業務的資料基本上是以文件的形式保存在計算機上，而其中一些格式化的資料是保存在數據庫中，所以面向文件和面向數據庫是輕量級工作流引擎的一個重要特征。業務的發起和結束是一項過程化的任務，任務又可以分解成一個一個環節任務，而任務是帶有目的性的，由這個目的去拉動這個過程中的一個一個的環節任務，促使環節任務的推進，最終達到任務完成的目的。這些業務的過程化不是隨機的，而是已經嚴格規定好的，只有遵循這些過程化的規則和流程環節才能完成整個業務。輕量級的工作流引擎就組合了以上這些，不追求工作流引擎的功能的完備和復雜，以滿足一般性業務為目的，為企事業快速開發出適合他們業務的工作流管理系統。

第二章

工作流管理系統參考模型簡介在闡述工作流引擎之前，我們來了解一下工作流技術的基本知識。早在幾年前，為了建立工作流管理系統的相關標準，國際上成立了一個稱為“工作流管理聯盟”（簡稱WFMC）的國際組織。她提出了有關工作流管理系統的一些規范，定義了工作流管理系統的結構及其與應用、管理工具和其它工作流管理系統之間的應用編程接口，也就是工作流系統參考模型。

WFMC給出的工作流參考模型如下圖：

接口2

接口3

接口4

接口1

接口5

過程定義工具

工作流API與交換格式

工作流執行服務

工作流機

（工作流引擎）

工作流 管理工具

其它工作流 執行服務

工作流機

工作流客戶應用

工作流機直接調用 的應用

圖2.1 工作流參考模型

從圖中可以看出，參考模型包含了五類接口，分別是：

⑴ 接口1：過程定義輸入輸出接口，這是工作流服務與工作流建模之間的接口，該接口提供的功能包括通信建立，工作流模型操作和工作流模型對象操作。

⑵ 接口2：客戶端函數接口，這是工作流服務與客戶應用之間的接口，這是最主要的接口規范，它約定所有客戶方應用與工作流服務之間的功能操作方式。包括通信建立，工作流定義操作（對過程模型定義操作），過程實例管理功能，過程狀態管理功能，任務項列表/任務項處理功能，數據處理過程，過程監控功能，其它的管理功能，應用程序激活。

⑶ 接口3：激活應用程序接口，這是工作流引擎和直接調用的應用程序之間的接口，包括通信建立，活動管理功能，數據處理功能。

⑷ 接口4：工作流執行服務之間的互操作接口，這是工作流管理系統之間的互操作接口，包括連接的建立，對工作流模型和其中對象的操作，對過程實例的控制和狀態描述，對活動的管理，對資料進行處理。

⑸ 接口5：系統管理與監控接口，這是工作流服務和工作流管理工具之間的接口，包括資源控制，角色管理，用戶管理，過程實例的管理，狀態管理，審核管理。

五個接口以及對應的API函數囊括了工作流管理系統的全部功能。一個完整的工作流管理系統就是以工作流引擎為中心，向外部部件（應用程序或其它工作流引擎）提供這五個接口，提供其實現的所有功能。

第三章

系統分析與設計在所有準備工作完成后，我們就開始進行系統設計和設計，構造一個輕量級的工作流引擎。輕量級的工作流引擎并不完全實現WFMC所提出的工作流模型包含的五個接口，特別是接口4，在分布式工作流管理系統才具有該接口。既然我們從輕量級的概念出發，我們就不再明顯區分各個接口的界限以及其所具有的特定的功能，以夠用、靈活和低成本的設計原則去設計出我們所理解的工作流引擎。我們運用了面向對象的方法，首先從眾多的業務需求中抽取出工作流模型所包含的對象，再分析各個對象之間的邏輯關系，然后提出一個系統結構，再進行模塊劃分，數據庫設計，最終完成類的設計。我們當中所用到的建模工具就是ROSE UML。

3.1 工作流模型的設計

對工作流模型的設計是工作流引擎設計的重要組成部分。

3.1.1 工作流模型的對象

企事業經營過程就是一項項業務的實現過程，我們從一般業務入手，并對這些業務進行詳細的分析，研究，其結果就是得到一般性的業務對象，從而抽象成工作流模型對象。

3.1.1.1 從一個簡單的業務實例看業務的需求

目前企事業的一項基本事務就是出差管理。它主要是對企事業的人員因為某種工作上的原因需要到別的地方出差進行的管理。我們可以列出出差的相關步驟：

⑴ 申請人需要出差，并且他（她）具有出差的權利；

⑵ 申請人填寫出差表格，說明因何事出差，出差何處，申請出差金額，何時回來等等和出差相關的情況；

⑶ 申請人需要其它說明的話，可以將更具體的說明以文檔的形式保存下來；

⑷ 申請人確認申請無誤后提交申請，等待申請的結果；

⑸ 根據規定，該申請必須先讓申請人的上一級審批，那么該申請就會以一項工作項的形式交給該級領導處理；

⑹ 處理該申請的領導對該申請進行處理，他（她）會先查看該申請所有的資料，包括出差申請表和與之相關的其它文檔，然后對其進行審批，審批的結果是同意那么該次申請會交給再下一級領導處理；審批的結果不同意，該申請被打回，通知申請人申請不通過的結果。等所有需要審批的領導都審批通過了，該申請就成功完成，通知申請人申請通過的結果；

⑺

申請人得到申請的結果，如果審批通過則準備出差，如果審批不通過則根據審批結果對該申請進行修改，重新提交申請； ⑻ 申請事務結束。

這是一個簡單的業務實例，對該實例進行分析我們可以得到該業務的一些對象：

⑴ 申請人：他（她）屬于該企事業的某個部門的成員，并且具有啟動該業務的權利； ⑵ 審批領導：他（她）也屬于該企事業的某個部門的成員，并且具有對該業務進行處理的權利；

⑶ 出差表格：它是該業務規定的格式化資料，并且是必須的 ⑷ 出差具體說明：它是該業務附加的資料，可以不要的

⑸ 申請人已經填寫好的出差表格：它是出差表格的實例化，代表一個具體的應用 ⑹ 審批同意和不同意：它們是對該業務的處理，遵循一定的業務規則 ⑺ 申請：這是一個過程，不是一個動作，需要時間和人的活動才能完成 ⑻ 審批：這是一個活動，是過程的一部分，并且可以向另外一個活動轉化

⑼ 其它應用程序：申請人要填寫出差具體說明時要調用相應的外部應用程序編輯該說明并以一定的格式保存下來，審批領導要查看出差具體說明時也要調用相應的外部應用程序打開該說明并以一定的格式顯示出來。

從這些業務對象，再利用工作流技術，我們可以得到工作流模型的一些基本對象：

⑴ 用戶：正如申請人，審批領導，他們就是工作流管理系統的用戶，由他們去使用該系統的各種功能，并且直接參與業務活動，促使業務的完成。

⑵ 角色：有些人可以申請出差，有些人對出差申請可以審批，這兩種不同的人可以作為兩個不同的角色。角色是具有某種使用系統特定功能的權利的一個人員或多個人員的組合。⑶ 工作流應用資料：出差申請表格，出差具體說明，這些就是對應某個具體業務（這里是出差管理）的相關資料，根據這些業務資料我們可以對該業務進行處理。

⑷ 需激活的應用程序：在需要其它應用程序提供支持的時候，會去激活這些應用程序。⑸ 流程：整個出差申請的過程就是一個流程，它從整體去描述一個業務。

⑹ 環節：又稱活動，它反映了業務流程的局部情況，通常業務流程是由一個一個的環節組成。

⑺ 流程實例：將該出差申請這個業務流程實例化，就得到一個流程實例。⑻ 環節實例：將流程的其中一個環節實例化，就得到一個環節實例。

⑼ 業務規則：業務的開始和結束需要一定的條件，在處理業務的過程中必須按照一定的規則，這些都是業務規則，只有嚴格遵循業務規則，業務才能完成。

3.1.1.2 工作流對象的具體分析和說明

通過一個具體的業務我們可以得到工作流模型的一些對象，那么我們再對其他一般性業務進行分析，研究，我們就會找到它們的共同點，并歸納出基于這些業務的公共的對象，這些公共的對象的組合，就是一個通用的模型，也就是工作流模型，這個模型能去描述每個業務，是我們追求輕量級工作流引擎的最終成果。

⑴ 用戶：業務的執行者和參與者，對應于企事業的每一個雇員，是一個獨立的、具有一定行為能力和一定技術能力的人的實體；

⑵ 角色：以技能為前提，能夠完成某項功能的人員的總稱；

⑶ 部門：對應于企事業的靜態結構劃分，由企事業的實際部門設置情況來決定，可以是傳統的面向職能的，也可以是現在流行的面向過程與客戶的；

⑷ 職位：以行政責任為前提，代表了管理上的等級關系；

⑸ 工作組：以執行某一任務為目標而動態組建的、跨部門劃分的一種組織結構；

⑹ 流程：對應于一個業務過程，表示一個業務由發起、處理、結束的一個過程；

⑺ 流程實例：對應于一個業務流程具體應用，是業務流程實例化的表現形式；

⑻ 環節：對應于業務流程中一個單一的業務操作，是流程按照業務要求的細化；

⑼ 環節實例：對應于一個環節的具體應用，是環節實例化的表現形式；

⑽ 工作流定義主信息：描述一個工作流模型的主要信息，從整體來描述工作流模型；

⑾ 工作流附件信息：描述一個工作流模型所用到的附件信息，也就是工作流應用資料，或者叫業務資料。按照WFMC提出的工作流模型，這不是工作流模型所包含的對象，可是我們對其進行格式化，把它抽取成一個模型對象，用來規定了工作流模型在具體應用時所需業務資料的格式，我們把它分為兩類：

●

表格類型：這是以表格的形式保存附件信息，可以用關系結構來定義附件信息，并保存在數據庫中，每一條記錄就是一個該附件的實例；

●

文檔類型：只是以文件形式保存附件信息，可以是work文檔，也可以是文本文件，它的實例化是就是一個一個帶有對應某個業務應用標志的文件，保存在硬盤上 ⑿ 工作流實例信息：描述一個工作流模型實例化的信息，也作為啟動一個工作流的信息，它記錄該業務流程隨著時間和人員的參與處理的不斷變化，直到整個業務的結束；

⒀ 工作項信息：描述參與某個業務應用時被分配到的一項任務，這就體現了參與人員和系統交互的典型特征；

⒁ 業務規則：描述業務在運行的過程中必須要遵守的規定和原則，也是業務活動得以向另一個活動推進的規則。我們把它分為四類規則，分別是： ●

自動型：它主要描述一些只給參與人員查看業務信息的業務規則，例如通知、公文流轉等等業務。該類業務不需要參與人員去審批或其它人為上的處理，只需要參與人員去查看其中的內容就足夠，整個業務流程的完成是全自動的。●

與聚合：業務活動的完成是需要參與該活動的所有人員都進行人為處理，其中有一個人員沒對其進行處理，整個活動只能停在原地，等待所有人員的處理，當最后一個參與人員執行了處理工作，它才能完成。●

或聚合：在參與某一業務活動的人員當中只要有一個對其進行處理，整個活動就可以完成。

●

投票聚合：統計參與該活動的參與人員的處理結果，當滿足一定條件該活動才能完成。

⒂ 轉換條件：描述流程、活動狀態改變時需要的條件，用于業務運行過程中的約束。例如流程的完成必須等待所有活動的完成才能完成，活動的完成必須按照業務規則去完成等等； ⒃ 需激活的應用程序：工作流管理系統需要其它應用程序的支持，例如編輯和查看文本文件信息等等；

⒄ 日志信息：描述工作流中所有的狀態改變、事件和控制流相關資料的變化，工作流實例和環節實例的啟動、結束、掛起和激活等等信息都會記錄下來，以便對其進行管理。3.1.2 對象之間的邏輯關系在找出工作流模型的對象后，我們就開始分析它們之間的業務邏輯關系。

3.1.2.1 對對象進行分類以及各個分類中對象之間的關系到此為止，我們有必要對工作流模型對象進行一下分類，根據工作流對象對工作流管理系統所起的作用我們可以分成以下幾類： ⑴ 組織模型

組織模型描述了企事業的組織機構關系，包括的對象有用戶，部門，職位，角色，工作組，它們的關系可以用下圖表示：

設置

負責

組成 組成 資格

組成 部門

職位

用戶

工作組

角色

圖3.1 組織模型結構

從圖中可以看到它們之間的關系，用戶是基本的單位，部門是由用戶組成，每個用戶對應一個職位，負責該職位所要求的職能，用戶憑著某種資格賦予一種角色，工作組也由用戶組成，也可以由角色組成。這幾個基本的對象以及其關系所構成的組織模型，已經可以滿足輕量級工作流引擎對組織模型的需要了。⑵ 工作流定義模型

工作流定義模型描述了工作流模型的定義信息，包括工作流定義主信息，流程定義信息，環節定義信息，工作流附件信息，業務規則。它們之間的關系如下圖：

圖3.2 工作流定義模型結構

包含

包含

包含

包含

遵循

包含

工作流定義

附件信息

主信息

業務規則

環節

流程

包含

流程是包含若干環節的，而環節遵循一定的業務規則，再加上工作流主信息和附件信息，共同構成工作流定義模型。⑶ 工作流實例模型

工作流實例模型描述了工作流模型實例化時的信息，通過這些信息我們可以知道實例過程中的各種狀態變化和最終的結果，因而得到一個業務具體應用的情況。它包括流程實例，環節實例，工作流實例信息，工作項信息和轉換條件，它們之間的關系如下圖：

記錄

記錄

細化

細化

影響

影響

影響

影響

記錄

記錄

轉換條件

環節實例信息

流程實例信息

工作項信息

工作流實例信息

日志信息

日志信息

細化

圖3.3 工作流實例模型結構

轉換條件影響工作流實例，流程實例，環節實例和工作項的狀態，并由轉換條件去決定它們的狀態轉變，工作流實例信息à流程實例信息à環節實例信息à工作項信息，自上而下逐層細化，不但從全局了解業務運行情況，而且從局部了解業務運行的細節情況。而它們的狀態改變都會記錄在日志中，用以追蹤工作流實例的運行情況。⑷ 外部支持模型

外部支持模型在本文只包括一個對象，就是需激活的外部應用程序，嚴格來說這不是工作流模型的一部分，可是提供接口去激活所需的外部應用程序為工作流管理系統提供支持是工作流模型的功能之一。有了這些外部應用程序的支持，我們的工作流管理系統的功能才變得更完善。

3.1.2.2 各個模型之間的邏輯關系

不但模型中各個對象有一定的邏輯關系，而且各個模型之間也有一定的邏輯關系，如下圖所示：

調用

依賴

使用

使用角色和工作組

用戶定義

工作流實例模型

外部支持模型

工作流定義模型

組織模型

圖3.4 模型之間的關系

組織模型的用戶定義工作流定義模型；工作流定義模型使用組織模型的角色和工作組，用來規定工作流模型的啟動條件和任務分配條件，因為工作流模型的啟動和任務的分配必須由一定的角色或工作組完成；工作流實例模型依賴工作流定義模型，同時使用組織模型的所有對象，并且調用外部支持模型為其提供支持。3.1.3 工作流實例，流程實例，環節實例和工作項的狀態轉換

工作流實例，流程實例，環節實例和工作項從不同的層次去描述業務運行過程的具體情況，不同級別的用戶可以看到業務運行的不同方面，創建工作流實例的用戶可以看到工作流實例信息以及其狀態轉換，參與該工作流實例的用戶可以看到工作項信息以及其狀態的改變，系統管理員可以看到所有信息以及其狀態的轉換。

⑴ 工作流實例狀態圖

創建

管理員

管理員

管理員

Running（運行）

Completed（結束）

正常情況

Suspended(掛起)

terminated(終止)

Initial（初始化）

圖3.5 工作流實例狀態圖

提交

⑵ 流程實例狀態圖

管理員

管理員

管理員

Running（運行）

Completed（結束）

正常情況

Suspended(掛起)

terminated(終止)

圖3.6 流程實例狀態圖

⑶ 環節實例狀態圖

處理中

接受

完成正常處理

沒有完成異常處理

回退處理

提交給下一環節

圖3.5 環節實例狀態圖

⑷ 工作項狀態轉換圖

等待操作

完成 通過

沒有完成 不通過

無操作，超時

操作下一工作項

回退處理

已查看

初始化

未審批

未查看

圖3.5 工作項狀態圖

接受

3.1.4 任務分派任務分派是工作流引擎的一個重要功能。當環節實例產生時，就會以一定的準則把需要處理的工作當作一項任務項（工作項）分派給參與該環節實例的所有用戶，而這些用戶是同屬一個角色或者工作組的。我們又把角色和工作組進行細化，可以得到以下準則： ⑴ 基于部門的：這就是說把任務分派到某個部門的所有人員，該部門的所有人員都參與了該項任務，因而會為該部門的所有人員都產生一個工作項；

⑵ 基于職位的：這就是說把任務分派到某個職位的所有人員，同屬該職位的所有人員都被分配到一項工作項；

⑶ 基于部門職位的：這就是說把任務分派到某個部門的某個職位的所有人員，同屬該部門的該職位的人員都被分配到一項工作項；

⑷ 基于所有人的：這就是說把任務分派到該企事業的所有人，該企事業的所有人都被分配到一項工作項；

⑸ 基于工作組的：這就是說把任務分派到該企事業的某個特定的工作組上，同屬該組的所有人員都被分配到一項工作項。

基于部門的，基于職位的，基于部門職位的和基于所有人的這四種類型，其實是基于角色的細化，通過這些準則的分類，我們盡量做到系統與企事業有較強的適應性，以及使系統在任務分派時有較大的靈活性。3.1.5 轉換條件的滿足

工作流實例，流程實例，環節實例和工作項的狀態轉換有各自特定的條件，分別如下：

⑴ 工作流實例的轉換條件

工作流實例從整體看業務運行過程，工作流實例被用戶創建后就進行初始化并提交給工作流引擎，由工作流引擎去處理，此時實例處于運行狀態；在運行過程中，它會根據流程實例的狀態而不斷進行本身的狀態改變；當管理員由于某種原因要掛起它時，它就處于掛起狀態，直到管理員重新激活它使它處于運行狀態或者終止它使它非正常結束；當它被正常處理完畢后，就正常結束。

⑵ 流程實例的轉換條件

流程實例也從整體看業務的運行過程，流程實例在工作流實例初始化時就開始它的工作。在運行過程中，它會根據各個環節的完成程度來改變自己的狀態，當所有環節實例都正常完成它就正常結束；管理員可能要掛起它使它處于掛起狀態，直到管理員重新激活它使它處于運行狀態或者終止它使它非正常結束。

⑶ 環節實例的轉換條件

環節實例從某個方面看業務的運行過程，環節實例在流程實例運行時就開始它的工作處于處理中狀態。之后環節實例的狀態由兩方面決定，一是工作項的處理結果，一是業務規則的規定。

●

如果業務規則是自動型的，不管工作項的處理結果怎樣，當系統把任務項分派（給特定用戶）完畢后，該環節實例就正常完成處于正常結束狀態；

●

如果業務規則是與聚合的，系統分派完任務項后，當所有參與人員都正常處理完該環節各自的工作項后，該環節才正常完成處于正常結束狀態；在處理過程中，只要有一個工作項是非正常處理的，該環節就非正常完成處于非正常結束狀態；在處理過程中，有工作項還未被處理并且沒有一個工作項被非正常處理，那么環節實例仍然處于處理中狀態；

●

如果業務規則是或聚合的，系統分派任務后，只要有一個工作項是正常處理的，該環節實例就正常完成處于正常結束狀態；如果所有同屬該環節實例的工作項都被非正常完成，那么該環節實例就處于非正常結束狀態；

●

如果業務規則是投票聚合的，系統分派任務后，統計工作項的完成程度，當正常完成的工作項數量達到一定數量時，該環節實例就正常完成處于正常結束狀態；當正常完成的工作項數量不達到規定的數量時，該環節就非正常完成處于非正常結束狀態；當所有工作項還沒處理并且正常完成的工作項還沒達到規定數量時，該環節實例仍然處于處理中狀態。

⑷ 工作項的轉換條件

工作項從更細節的方面看業務運行過程，工作項的狀態轉換要看參與人員對各自的工作項的處理情況和業務規則的規定。我們把與聚合，或聚合和投票聚合這些要人工干預的規則統稱為人工型規則。

●

如果業務規則是自動型，同屬該規則的工作項的狀態就只有正常處理后的正常結束狀態，當然如果對該工作項還沒被處理則處于處理中狀態，可這不對環節實例等產生影響；

●

如果業務規則是人工型，就會有正常處理和非正常處理兩種情況，正常處理該工作項則使到該工作項處于正常結束狀態，非正常處理該工作項則使到該工作項處于非正常結束狀態。

3.2 系統結構

本著基于輕量級工作流引擎的原則，我們已經對工作流模型進行了詳細的分析和詳細的設計，在這里我們就提出一個系統結構，如下圖所示：

工作流定義器

工作流

解析器

實例調度中心

任務管理器

任務分派器

啟動控制器

工作流定義數據

工作流實例 數據

日志 數據

工作流定義接口

工作流實例接口

組織定義

數據

組織定義接口

組織定義器

狀態轉換器

組織

管理器

圖3.6 工作流引擎系統結構圖

從圖中可以知道，系統提供了三類接口：組織定義接口、工作流定義接口和工作流實例接口。這三類接口實現了工作流模型的接口一，接口二，接口三和接口五規定的主要功能；系統有一個實例調度中心，這是一個很重要的部件，它控制工作流實例的運行，通過工作流解析器對該工作流模型進行解析其含義，通過任務分派器按照一定的分派準則把任務項分派給參與該工作流實例的用戶，通過任務管理器管理各個任務項的信息，通過啟動控制器控制工作流的啟動權利和啟動信息，通過狀態轉換器控制工作流實例、流程實例、環節實例和工作項的狀態轉換；組織定義器定義企事業的組織結構；工作流定義器定義工作流模型信息，并通過組織管理器得到組織定義信息，為工作流模型提供組織支持。各個部件處理的相關信息都保存在數據庫中。

3.3 系統模塊的劃分

根據功能實現的不同我們進行模塊的劃分如下：

⑴ 用戶管理模塊：對用戶信息的管理，包括注冊用戶信息，注銷用戶信息，查詢用戶信息等功能；

⑵ 部門管理模塊：對企事業部門結構信息的管理，包括增加部門信息，刪除部門信息，查詢部門信息等等功能；

⑶ 職位管理模塊：對企事業職能信息的管理，包括增加職位信息，刪除職位信息，查詢職位信息等等功能；

⑷ 角色管理模塊：對企事業某種技能信息的管理，包括新增角色信息，刪除角色信息，查詢角色信息等等功能；-

⑸ 工作流模型管理模塊：對工作流定義模型信息的管理，包括定義新的工作流模型信息，刪除舊的工作流模型信息，查詢工作流模型信息；

⑹ 工作流實例管理模塊：對工作流實例信息的管理，包括啟動一個新的工作流實例，查詢工作流實例信息，按照一定的業務規則生成新的環節實例信息，為用戶分派工作項，管理工作項信息，按照一定的轉換條件為工作流實例、環節實例轉換狀態等等功能；

⑺ 系統監控模塊：為工作流實例，環節實例等的狀態轉換信息加入日志，掛起、激活工作流實例，強制結束工作流實例，為遲遲不對自己的工作項進行處理的用戶發出提醒或警告信息，查看各個工作流實例的完成程度等等功能。

功能模塊的劃分，為系統的實現做好充分的準備。

3.4 數據庫設計

基于輕量級的工作流引擎的特點之一就是把系統相關的資料，如工作流模型定義信息，工作流實例信息，組織模型定義信息等等，都以特定的實體形式保存在關系型數據庫中。

⑴ 工作流定義主信息表（workflowTable）

靜態定義工作流主要信息，包括該工作流的標識ID（可以定義為以”WORKFLOW_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自動生成的序號），工作流名稱，工作流描述，工作流類型（工作流的類型有自動型，人工型和混合型，自動型不需要人工參與，由工組流引擎自動執行，人工型需要人工參與，混合型包含了自動型和人工型），工作流創建日期，工作流創建者ID（即用戶ID），工作流創建人名稱（即用戶名），工作流生命周期（每個工作流實例都有它的生命周期期限，在該期限內還沒完成它的工作就直接死亡），目前該工作流實例數目（記錄當前工作流實例數目），工作流啟動者角色（指明該工作流可以由哪個角色發起，屬于該角色的用戶都可以啟動該工作流模型對應的實例）。工作流重要信息還包括兩方面，一是工作流附件，因為在工作流進行過程中，肯定會帶有一些信息，這些信息對于出差申請來說就是出差申請表，對于公文流轉來說就是以word文檔形式的公文，對于通知來說可能就是以文本文檔形式的通知書，等等；一是工作流流程描述，包括若干個環節（activity），這些環節有一定的順序，表現工作流順序執行的特征。把工作流附件和工作流流程描述從工作流定義分離出來，是基于工作流附件和工作流流程描述對于不同工作流有不同形式和數量的原因，有利于工作流附件和工作流流程描述的擴展。⑵ 工作流附件信息表（workflowAttachmentTable）

靜態定義工作流所需要的附件，包括附件ID（可以定義為以”Attachment_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自動生成的序號），工作流ID（標識屬于哪個工作流），附件類型（表或文件），附件名稱（如果類型是表，則為該表的名稱，如果是word文檔，則為該文檔名稱，如果是文本文檔，則為該文件名稱），其它信息（如果類型為表格，該字段以一定的格式保存該附件表格的所有字段的各種信息，包括字段名稱，字段數據類型，數據類型長度，字段描述）。⑶ 工作流流程描述表（workflowProcessTable）

靜態定義工作流的流程，由若干環節（activity）組成，一個環節為一條記錄，包括工作流ID（環節所屬工作流ID），環節ID（可以定義為以”ACTIVITY_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自動生成的序號），環節名稱（即該環節名稱），環節描述（對該環節的具體描述），參與者角色ID（將相同權限的用戶作為一個集合，在數據庫以同一個角色操作數據庫特定操作，該項標識角色ID），環節任務分派規則，上一個環節ID（保存上一個環節的ID，由這項可以判斷該環節是否整個流程的開始環節，或者該環節的任務沒有完成（審批不通過，或沒在其生命周期期限內完成）時作回滾處理的重要數據項，根據這個數據項可以回滾到上一個環節），下一個環節ID（保存下一環節的ID，由這項可以判斷該環節是否整個流程的結束環節，或者該環節的任務完成了，根據這個數據項可以啟動下一環節，繼續向前推進）。

⑷ 工作流實例啟動描述（workflowInstanceStartUpTable）動態定義工作流實例啟動信息（其實這也是工作流實例信息表）啟動者在產生一個工作流實例之前必須根據工作流的定義做好準備工作，這些準備工作的信息就填入該表中，然后交付給工作流引擎。該描述包括工作流ID（所屬工作流ID），工組流實例ID（標識該工作流實例，可以定義為以”WORKFLOWINSTANCE_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自動生成的序號），工作流實例描述，工作流實例創建時間，工作流實例創建者ID（啟動者ID），工作流實例創建者名稱，當前工作流狀態（標識當前工作流實例的狀態，啟動者在創建后卻沒提交給工作流引擎前的狀態為“initialized”初始化狀態，之后的狀態要視工作流類型而定），當前狀態具體描述，當前操作者ID（當前工作流要被誰操作），當前操作者名稱。工作流實例完成標志（標識該工作流實例的完成），工作流實例完成時間，當前工作流狀態和當前操作者ID和當前工作流狀態具體描述三項在工作流實例的運行過程中，可以動態追蹤該工作流實例的運行，而這三項再加上工作流完成標志和工作流完成時間，可以知道該工作流實例的完成情況。

⑸ 工作流實例過程描述（workflowInstanceProcessingTable）以環節為單位動態描述工作流實例的處理過程，啟動者創建工作流實例后，提交給工作流引擎后，工作流實例就根據工作流定義的流程進行運轉了。包括工作流實例ID，工作流實例所對應環節（工作流流程就是由一系列的環節組成，按照預定義的流程一個環節過渡到另一個環節），當前該環節所處狀態（這標識著該環節在處理過程中的狀態，最終狀態表示該環節的完成狀態），當前操作者（對應的是角色），當前狀態具體描述。⑹ 工作項描述（workItemTable）

動態描述已經參與該工作流實例處理的參與者（對應已處理環節的角色的每個用戶）的工作情況。包括工作項ID（可以定義為以”WorkItem-_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自動生成的序號），工作項名字，工作項描述，工作流實例ID（該工作項所屬的工作流實例），該環節任務分派規則（繼承環節的任務分派規則，用于判斷該環節任務完成方式），當前該工作項所處狀態（根據不同的工作流類型有不同的狀態，根據這些狀態可以在參與者接口上顯示不同的工作項列表），執行動作（記錄執行者會對該工作項執行怎么樣的動作，如果是申請事務則是審批通過或審批不通過），執行時間（記錄該執行動作的時間），用戶ID（標志該工作項是屬于誰的。⑺

用戶描述（UserTable）

該表描述所有用戶的資料，包括用戶ID（可以定義為以”User-_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自動生成的序號），用戶名稱，用戶密碼，用戶所屬部門，職位等等信息，級別是該用戶的系統權限，包括普通職員，高級職員和系統管理員。⑻ 日志信息描述（LogTable）

描述用戶的工作日志，便于對各種操作進行追蹤。包括日志ID（可以定義為以”Log-_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自動生成的序號）等等，其中有一項是相關工作項ID，這是當參與者對原始工作項進行執行操作動作時的工作項。⑼ 角色信息（RoleTable）

描述角色的信息，包括角色ID（可以定義為以”Role__xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自動生成的序號），角色名稱，部門名稱，職位名稱，角色描述。角色由部門和職位組成。

⑽ 部門信息（DepartmentTable）

描述部門的信息，包括部門ID（可以定義為以” Depatment_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自動生成的序號），部門名稱，部門其它信息。

⑾ 職位信息（PositionTable）

描述職位的信息，包括職位ID（可以定義為以” Position_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自動生成的序號），職位名稱，職位其它信息。

除了以上這些主要表以外，還有一些我們是在定義工作流模型的時候才加入數據庫的，如對應工作流附件類型為表的表格。為了減少網絡流量和提高系統的運行速度，我們把一些有關聯的數據庫操作寫成存儲過程：

⑴ 刪除工作流模型存儲過程：刪除一個工作流模型，必須刪除它的工作流定義主信息，同時刪除對應的附件信息，附件為表的表格，環節信息；

⑵ 創建附件類型為表的表格：定義附件信息時已經把該表格的字段信息保存在該附件信息的其它信息字段中，并且有一定的格式，那么我們從該字段中按照一定的格式還原表格的字段信息，并根據這些信息在數據庫中創建該表格。

3.5 類的設計

用面向對象的方法和UML建模工具，再根據系統結構圖，模塊的劃分和數據庫的設計，我們把對象轉化成類，進行類的設計。我們把整個系統的類分成三部分，一是實體類，二是業務類，三是接口類。

3.5.1 實體類的設計

工作流模型的對象就是一個一個的實體，實體類又分為數據庫訪問類和值對象類。數據庫訪問類是對存儲在數據庫的實體信息進行訪問（插入，刪除，更新，查詢）的類，值對象類是在客戶端和服務器端之間交換資料的實體信息類。

3.5.1.1 數據庫訪問類

⑴ 數據庫連接類：該類是其它數據庫訪問類的父類，管理數據庫的連接，負責從數據庫連接池找可用的數據庫連接給其它數據庫訪問類使用，使用完畢后負責放回連接池，類圖如下圖：

說明：屬性只有一個connection，它代表數據庫的一條連接，類型為Connection，方法有一個構造函數workflowDAO()和一個關閉連接的函數closeConnection()。WorkflowDAO()實現從數據庫連接池找一個可用連接并賦值給屬性connection，closeConnection()負責把連接放回數據庫連接池。

⑵ 工作流定義主信息訪問類：對應數據庫的工作流定義主信息表，該類封裝了對該表格記錄的各種操作，就是插入或刪除一條工作流定義主信息，查詢特定工作流定義信息或者所有工作流定義信息，類圖如下圖：

說明：構造函數WFDefineMainInfoDAO()調用父類構造函數，從數據庫連接池中找一個可用的數據庫連接（其它數據庫訪問類也一樣）。

⑶ 工作流流程信息訪問類：對應工作流流程描述表，該類封裝了對該表格記錄的各種操作，流程是由若干環節組成，就是插入或刪除一條環節信息，查詢同屬于一個流程的環節信息等等，類圖如下圖：

說明：findWorkflowFirlstActivityInfo()函數負責找該工作流模型的第一個環節的信息，findWorkflowNextActivityID()負責根據當前環節ID找下一環節的信息。

⑷ 工作流附件信息訪問類：對應工作流附件信息表，該類封裝了對該表格記錄的各種操作，就是插入或刪除一條工作流附件信息，查詢同屬于一個工作流模型的附件信息。類圖如下：

⑸ 工作流附件類型為表的信息訪問類：對應工作流附件類型為表格的信息表，該類封裝了該表記錄的各種操作，就是插入或查詢一條工作流附件類型為表格的具體信息，類圖如下：

⑹ 工作流實例啟動信息訪問類：對應工作流實例啟動信息表，該類封裝了該表記錄的各種操作，就是插入或查詢一條工作流啟動信息，查詢同屬于一個用戶的工作流實例啟動信息，更新部分字段信息，類圖如下：

說明：selectFinishedWorkflowInstanceStartUpInfoVO()負責查詢特定用戶啟動的并且已經完成的工作流信息，selectNotFinishedWorkflowInstanceStartUpInfoVO()負責查詢特定用戶啟動的并且還沒有完成的工作流信息，updateWFInstFinishedFields()負責在工作流實例結束時更新特定的字段信息，updateWFInstProcessingFields()負責在工作流實例運行工程中更新特定的字段信息。

⑺ 工作流實例過程信息訪問類：對應工作流實例過程信息表，該類封裝了該表格記錄的各種操作，每一條記錄實際上是一個環節實例，就是插入、刪除或查詢一條環節實例信息，查詢指定工作流實例的所有環節信息，更新部分信息字段，類圖如下：

說明：SetWFInstProcessingCurrentPerformerNumField()負責更新已經處理該環節實例對應的工作項的參與該環節實例的用戶數目，updateWFInstProcessingFields()負責在環節實例處理過程中更新特定的字段信息。

⑻ 工作項信息訪問表：對應工作項表，該類封裝了該表格記錄的各種操作，就是插入或刪除一條工作項信息，查詢工作項信息，更新工作項信息，類圖如下：

說明：selectFinishedWorkItemVO()負責查詢特定用戶已經處理完畢的工作項信息，selectNotYetFinishedWorkItemVO()負責查詢還沒有處理的工作項信息，updateWorkItemFields()負責更新工作項在處理過程中的特定字段信息，isPerformedInWorkItemByUser()負責判斷該工作項是否已經處理完畢。

⑼ 用戶信息訪問表：對應用戶信息表，該類封裝了該表格記錄的各種操作，就是插入、刪除或查詢一條用戶信息，查詢特定角色對應的用戶信息，類圖如下：

說明：selectCountRS()負責統計同屬于一個角色的用戶數目。

⑽ 角色信息訪問類：對應角色信息表，該類封裝了該表記錄的各種操作，就是插入、刪除或查詢一條角色信息，查詢所有角色信息，類圖如下：

⑾ 部門信息訪問類：對應部門信息表，該類封裝了該表記錄的各種操作，就是插入、刪除或查詢一條部門信息，查詢所有部門信息，類圖如下：

⑿ 職位信息訪問類：對應職位信息表，該類封裝了該表記錄的各種操作，就是插入、刪除或查詢一條職位信息，查詢所有職位信息，類圖如下：

⒀ 日志信息訪問類：對應日志信息表，該類封裝了該表記錄的各種操作，就是插入、刪除一條日志信息，查詢特定的日志信息，類圖如下：

3.5.1.2 值對象類

值對象類其實是一種數據結構，用于客戶機和服務器之間的數據交換，也用于對象實例的數據傳遞，它有若干屬性，可是很少方法，實例化后就對應數據庫表的一條記錄。

⑴ 工作流定義主信息值對象類：可以保存工作流主信息表的一條記錄信息，類圖如下：

⑵ 工作流流程信息值對象類：可以保存工作流流程信息表的一條記錄信息，類圖如下：

⑶ 工作流附件信息值對象類：可以保存工作流附件信息表的一條記錄信息，類圖如下：

說明：SetOtherInfo()負責以一定格式把工作流附件類型為表的表格字段信息保存在OtherInfo中，GetOtherInfo()負責從OtherInfo中以一定的格式還原工作流附件為表的表格字段信息。

⑷ 工作流附件類型為表的信息值對象類：可以保存工作流附件類型為表的信息表的一條記錄信息，類圖如下：

說明：tableName就是工作流附件類型為表的表格名稱，fieldValue就是對應該表的一條記錄的各個字段值，用可變長數組Vector保存下來。

⑸ 工作流實例啟動信息值對象類：可以保存工作流實例啟動信息表的一條記錄信息，類圖如下：

⑹ 工作流實例過程信息值對象類：可以保存工作流實例過程信息表的一條記錄信息，類圖如下：

⑺ 工作項信息值對象類：可以保存工作項信息表的一條記錄信息，類圖如下：

⑻ 用戶信息值對象類：可以保存用戶信息表的一條記錄信息，類圖如下：

⑼ 角色信息值對象類：可以保存角色信息表的一條記錄信息，類圖如下：

⑽ 部門信息值對象類：可以保存部門信息表的一條記錄信息，類圖如下：

⑾ 職位信息值對象類：可以保存職位信息表的一條記錄信息，類圖如下：

⑿ 日志信息值對象類：可以保存日志信息表的一條記錄信息，類圖如下：

⒀ 信息集合值對象類：可以保存各種信息的一個集合，當需要返回多條記錄信息的時候可以使用該類，類圖如下：

說明：只有一個屬性，是一個可變長數組，可以存放不定數量的記錄信息。3.5.2 業務類的設計

業務類，其實就是邊界類，它根據系統的需求按照一定的方式把各個實體類聯系起來，以實現系統的各種功能。按照實現功能的不同我們可以分為用戶管理類，角色管理類，部門管理類，職位管理類，工作流模型管理類，工作流實例管理類，系統監控管理類。

⑴ 用戶管理類：負責用戶的注冊，注銷，檢測合法性，查找用戶信息，類圖如下：

⑵ 角色管理類：負責新增加角色，刪除角色，查找角色信息，類圖如下：

⑶ 部門管理類：負責新增加部門，刪除部門，查找部門信息，類圖如下：

⑷ 職位管理類：負責新增加職位，刪除職位，查找部門信息，類圖如下：

⑸ 工作流模型管理類：負責工作流模型的定義，解析，類圖如下：

⑹ 工作流實例管理類：負責工作流實例的創建，維護各種實例的狀態信息，分派任務給用戶，用戶處理工作項等等的工作，類圖如下：

說明：uploadAttachmentToServer()負責把工作流附件類型為文檔的文檔上傳到服務器特定目錄下。

⑺系統監控管理類：是一個綜合類，主要通過調用其它管理類的功能來實現本身的功能，就是查看工作流實例的過程狀態，完成程度，根據一定的條件有必要控制實例的掛起，激活，結束，查看各個參與用戶的工作情況，在出現工作誤時、意外、異常等等情況時采取一定的措施保證整個實例的完成。而所有這些都保存在日志中。

3.5.3 接口類的設計

接口類是工作流引擎提供給外部應用的類，應用系統通過調用這些類，來實現一定的應用功能。我們在接口類的設計上，采取格式統一、隱藏系統復雜性、功能調用方便的原則，盡量為外部應用系統提供簡潔、易懂的功能調用接口。因而我們把這些類都設計成只有一個業務類實例，一個ToDoWhat()方法的類，并且每一個業務類對應一個接口類。在這些接口類中，業務類實例作為它的一個數據成員，ToDoWhat()方法有兩個參數，toDoCode（工作代碼）和object（數據交換對象），工作代碼表示要調用的功能的標識，數據交換對象表示功能調用要處理的數據（應用數據）。從本質上來說，就是根據不同的工作代碼調用業務類實例的不同方法，對各種應用數據進行處理。

第四章

系統實現系統的實現主要包括關鍵問題的解決方案和一個工作流管理應用系統的實踐。首先提出關鍵問題，然后給出解決方案，最后提出一個應用架構，利用J2EE技術和數據庫技術實現一個基于輕量級工作流引擎的簡單工作流管理應用系統。

4.1 關鍵問題的解決方案

在實現工作流引擎的時候，有一些關鍵問題，例如啟動工作流實例，推動工作流實例的進程，類型為文檔的附件的處理等等，都是要重點解決的。4.1.1 啟動工作流實例

當根據各種業務需求創建了對應的工作流模型，根據結構組織情況創建了組織模型后，用戶就可以創建工作流實例并啟動它。用戶把工作流實例的信息提交給工作流引擎，那么工作流引擎如何工作呢？工作流引擎其實做了一系列的工作，其處理過程如下：

⑴ 工作流引擎得到用戶創建的工作流實例數據，記錄在工作流實例啟動信息表中；

⑵ 工作流引擎解析對應該工作流實例的工作流模型的含義，獲得必要信息提供給工作流實例使用；

⑶ 工作流引擎根據這些必要信息找到工作流模型對應流程的第一個環節信息，并生成該工作流實例的第一個環節實例，記錄在工作流實例過程描述表中；

⑷ 工作流引擎根據任務分派原則開始把任務項分派給參與該環節實例的所有用戶；

⑸ 工作流引擎根據該環節定義的參與者角色，找出所有同屬于該角色的所有用戶，為各個用戶都生成一個工作項，記錄在工作項信息表中，工作項要繼承該環節定義的業務規則，完成任務的分派；

⑹ 工作流引擎根據該環節定義的業務規則，如果該環節是自動型的，則為該環節的參與用戶分派完任務后立刻就根據該環節信息去找下一個環節的信息，進行下一環節實例的處理；如果該環節不是自動型的，是需要人工參與處理的，則工作流引擎暫停該工作流實例的處理工作，等待參與用戶處理的結果；

⑺ 啟動工作流實例的工作結束。

4.1.2 推進工作流實例的進程

⑴ 如果上一環節定義的業務規則是自動型的，則立刻根據當前環節信息查找下一環節；

⑵ 如果上一環節定義的業務規則是不是自動型的，則等待參與用戶對各自的工作項進行處理，當每一個用戶處理完后，工作流引擎都要判斷該環節實例是否結束，結束的條件是業務規則的規定和用戶的處理結果。

①

如果業務規則是與聚合，當當前用戶的處理結果是非正常處理的話，該環節實例就結束，并且該工作流實例也結束，通知其他還沒處理的用戶該環節已經結束，并記錄在相應的數據庫表中；當當前用戶的處理結果是正常處理的話，則再判斷是否所有參與的用戶都處理完畢，如果是則結束該環節，通知其他用戶該環節已經結束，并記錄在相應的數據庫表中，然后查找下一環節，如果不是則等待其他還沒處理的用戶的處理結果。

②

如果業務規則是或聚合，當當前用戶的處理結果是正常處理的話，該環節的實例就結束，并且該工作流實例也結束，通知其他參與還沒處理的用戶該環節實例已經結束，記錄在相應的數據庫表中，然后查找下一環節；當當前用戶的處理結果是非正常的話，則等待其他還沒處理的用戶的處理結果。

③

如果業務規則是投票聚合，當當前用的處理結果是正常處理的話，則使統計正常處理結果的計數器加一，然后判斷該統計數量是否已經達到規定的數量，如果是則結束該環節實例，并通知其他還沒處理的用戶該環節實例已經結束，記錄在數據庫表中，然后查找下一環節；當當前用的處理結果是非正常處理的話，則不統計，等待其他還沒處理的用戶的處理結果。

⑶ 當前環節實例結束后，工作流引擎就找下一環節處理，如果沒有下一環節，則結束該工作流實例，記錄在數據庫表中，如果還有環節，則同樣生成環節實例，進行任務分派，等待環節實例的結束。工作流引擎就是這樣推進工作流實例進程，從一個實例環節到下一個實例環節，直到工作流實例結束為止。

4.1.3 類型為文檔的附件的處理

對于文檔形式的附件，我們采用上傳文件到服務器的方法，用戶編輯好文檔后，以規定的文件名上傳到服務器中特定的目錄中，當用戶要查看該文檔時，工作流引擎會根據該附件文檔對應的信息得到其文件名，用戶根據該文件名下載到本地中，同時調用外部應用程序如work2000、記事本打開給用戶瀏覽其內容。

4.2 一個簡單工作流管理系統的實現

現在，我們利用J2EE技術把工作流引擎開發出來，并基于該引擎做一個簡單的應用系統，以證明系統設計的可行性。我們用Jbuilder9.0做開發工具，用MS SQLSERVER2000做數據庫管理系統。4.2.1 系統應用框架

工作流實例管理器

工作流模型管理器

組織管理器

系統監控器

工作流引擎

應用服務器

數據庫

Web界面

文檔管理系統

圖4.1 系統應用框架

4.2.2 J2EE相關技術的應用

J2EE為多層Web應用系統提供了容器平臺，用J2EE技術把工作流管理系統開發成一個多層Web應用系統，是最合適不過了。

4.2.2.1 J2EE核心模式和類的實現

模式是特定問題的可重現的解決方案，使用模式有莫大的好處。模式可以權衡已經被證實的解決方案，為交流提供一個共同的詞匯，約束解決方案的范圍。J2EE核心模式是在J2EE平臺上應用的模式，它在表示層，業務層，集成層都有特定的模式，為基于J2EE平臺的開發提供很好的解決方案。對類的實現我們采用了J2EE核心模式，主要運用的核心模式是業務層的ValueObject（值對象）和集成層的DAO（DataAccessObject，數據訪問對象）。

⑴ 值對象：基于多層應用架構的系統，客戶端和服務器端往往有大量的數據交換，而且客戶端調用的方法都是遠程的，不是本地的，為了減輕網絡負載，提高應用程序的性能，用值對象封裝業務數據，在客戶端和服務器端進行數據交換。因而我們把所有工作流對象都用值對象表示，像工作流定義主信息值對象類（WFDefineMainInfo）。在這些值對象中，所有屬性和方法都是聲明為公共的，并且很少方法，很多屬性，這些屬性就是對應的工作流對象的屬性，也對應了數據庫中表的某個字段。

⑵ 數據訪問對象：基于關系數據庫技術的系統，會對數據庫進行頻繁的訪問，數據庫表的眾多，對某個表操作的方式的眾多，如果不對這些表和表的操作方式進行必要的歸類，只會造成模塊聚合度的降低，代碼混亂的后果。我們使用數據訪問對象，來抽象和封裝對數據庫的訪問，所有涉及到數據庫訪問的情況都使用數據訪問對象去實現。工作流對象的所有數據都保存在數據庫中，我們為每個對象數據的數據庫操作都封裝在數據訪問對象中，像工作流定義主信息訪問類（WFDefineMainInfoDAO）。4.2.2.2 JavaBean技術與類的實現

JavaBean是基于Java技術的軟件構件模型，它是Java語言編寫的可移植的不依賴于平臺的軟件構件模塊。我們把系統所有的類都實現為一個一個的JavaBean，提高類的可重用性，有利于日后的功能擴展。另外，JavaBean應用到JSP中，可以為JSP應用帶來更好的可伸縮性。

4.2.2.3 JBOSS應用服務器和工作流引擎的實現

應用服務器我們采用JBOSS，這是一個免費的產品，它提供數據庫訪問（JDBC）、命名機制（JNDI）服務等服務，支持數據庫連接池、實例連接池，這些為我們的工作流引擎的實現提供了支持，給系統開發帶來很大的方便。

⑴ 對數據庫訪問的支持：JBOSS通過對特定數據庫管理系統的配置（XML文件），并實例化對數據庫的若干連接，放進數據庫連接池中，提供給系統使用。在JBOSS運行過程中，對這些數據庫進行有效的管理，減輕了工作流引擎的工作負擔。①

配置方法 mssql-ds.xml文件：

MSSQLDS/* 數據源名字 */

jdbc:microsoft:sqlserver://localhost:1433;DatabaseName=WorkflowDB /* 連接URL，包括服務器

地址，數據庫名稱 */

com.microsoft.jdbc.sqlserver.SQLServerDriver /* sqlserver驅動 */

workflowUser /* 用戶名稱 */

123456 /* 用戶密碼 */

②

調用方法（使用JNDI機制）部分代碼：

InitialContext ctx = new InitialContext();//初始化上下文

DataSource ds =(DataSource)ctx.lookup(“java:/MSSQLDS”);

//根據數據源名字查找已經配置好的數據源

Connection conn = ds.getConnection();

//調用該方法可以得到對數據庫的一條連接，而這條連接已經被JBOSS初始化，實際上是從數據庫連接池中找到一條可用的連接而已，然后通過該連接就可以對數據庫進行各種操作，操作完畢后不用顯式關閉，JBOSS會自動回收該連接，把該連接重新放入連接池中。

⑵ 對對象實例化的支持

當系統第一次生成某個對象實例時，JBOSS就對該實例進行管理，把該實例放入實例池中，并不釋放它，當系統再次要生成該實例時，不再進行該對象的實例化，而是JBOSS從實例池中找到該實例并提供給系統使用，這明顯提高系統運行速度。

⑶ 對線程的支持

當不同的用戶登陸系統，并且對系統所有功能的使用，JBOSS會為每個用戶分配一個線程去為他們工作，這些線程放入線程池中，JBOSS在運行過程中始終對這個線程池進行管理，提高系統的并發性能。

4.2.2.4 Jsp/Servlet技術和系統界面的實現

JSP技術可以方便的建立動態Web頁面，提供一個友好的用戶界面，并且很方便的調用JavaBean，完成復雜的業務功能；Servlet提供在Web進行請求和響應服務的功能，客戶端對服務器提供的服務的所有請求和響應都通過Servlet實現。JSP最終解析為Servlet。

⑴ JSP調用JavaBean

下面是創建工作流定義主信息的JSP頁面部分代碼：

class=“wfsystem.interfacepack.client.workflowManager” />

?

<%

WFDefineMainInfo wfDefinemaininfo =new WFDefineMainInfo();

? // 填充工作流定義主信息值對象WFDefineMainInfo 實例

wfManager.ToDoWhat(0,(Object)wfDefinemaininfo);//調用接口類的方法，0對應創建工作流主信息的方法代碼

%>

⑵ Servlet請求和響應服務 下面是請求得到表單信息（這些信息就是工作流定義主信息值對象的內容）部分代碼：

<%

String workflowname = request.getParameter(“workflowname”);

String workflowDesc = request.getParameter(“workflowDesc”);

//request就是請求對象，調用其方法getParameter()可以得到表單的信息

? //一個一個的得到信息

%>

下面是響應用戶的部分代碼：

<%

response.sendRedirect(“defineWorkflowModel-mainInfo.jsp”);// response就是響應對象，調用其方法sendRedirect()向用戶發送一個頁面重定向的應答。

%>

4.2.3 具體編碼實現

接下來的工作就是編碼工作，以Jbulider9.0作為開發工具，以VSS（Microsoft Visual SourceSafe6.0）作為版本控制工具，進行代碼編寫，進行單元測試，綜合測試，最后得到一個基于輕量級工作流引擎的簡單的工作流管理系統。

第五章

系統的不足

本文探討的輕量級工作流引擎，盡管有很多的優點，可是它從夠用、靈活和低成本的設計原則出發，不追求工作流引擎的功能的完備和復雜，所以存在著一些不足：

⑴ 不支持復雜業務：本文探討的輕量級工作流引擎是從一般業務的需求設計工作流模型，我們只實現了活動的單分支，就是組成工作流流程的活動是一個活動只有一個后續活動，而復雜業務可能一個活動后面出現多分支，有多個后續活動，形成一個樹型的結構。所以對復雜業務的不支持是本文探討的工作流引擎的最大的不足。

⑵ 不支持復雜的組織結構：本文探討的工作流引擎只是以職能型的機構模型去描述組織結構，主要以部門和職位組成一個角色，任務分配也只是按照部門和職位的不同組合去分配，可是復雜的組織結構模型可以定義多重角色，臨時工作組等等。

⑶ 不支持提供內建（built-in）的應用開發工具，例如是可視化工作流建模工具，FORM設計工具，這些在本文探討的工作流引擎都沒有實現一定的接口。

⑷ 在定義應用數據方面不支持所有數據類型和完整性維護，只支持字符型類型和進行一些簡單的數據保存工作。

⑸ 沒有完善的異常處理功能。對異常的捕捉和處理并不完善，沒能及時把錯誤信息顯示給用戶。

⑹ 沒有完善的事務控制功能。只實現了一些簡單的事務控制，沒有對復雜事務的控制。

第六章

總

結本文主要探討了輕量級工作流引擎的設計與實現，首先我們要了解有關工作流技術的相關知識，然后說明開發輕量級工作流引擎的原因，再從企事業一般業務需求入手，抽象出工作流對象，分析其之間的邏輯關系，組成工作流模型，跟著提出一個系統結構，進行模塊劃分，數據庫設計，類的設計，最后利用J2EE技術，用MS SQLSERVER2000作后臺數據庫，Jbuilder9.0作開發工具，VSS作版本控制，實現工作流引擎的開發，并基于該工作流引擎作一個簡單的應用系統，最終實現為一個工作流管理系統。該管理系統的正常運行，充分體現了輕量級工作流引擎在企事業業務的開發過程中的價值。參考文獻[1] 范玉順著，《工作流管理技術基礎》，清華大學出版社 [2] Deepak Alus等著，《J2EE核心模式》，機械工業出版社 [3] 王克紅等著，《Java技術教程（中級篇）》，清華大學出版社

[4] Wendy Boggs等著，《UML With Rational Rose從入門到精通》，電子工業出版社

[5] Borland公司著，《Borland Jbuilder實用技術手冊》，電子工業出版社 [6] 何清法等著，《基于關系結構的輕量級工作流引擎》，中國科學院計算技術研究所 [7] Joseph L.Weber著，《Java 2 編程詳解》，電子工業出版社

本文來自CSDN博客，轉載請

標

明

出

處http://blog.csdn.net/hjt79/archive/2004/08/15/75484.aspx

：

第三篇：JAVA工作流引擎原理學習

JAVA工作流引擎原理學習

工作流是業務流程的全部或部分自動化，在此過程中，文檔、信息或任務按照一定的過程規則流轉，實現組織成員間的協同工作，以達到業務的整體目標。工作流管理系統是支持企業經營過程高效執行并監控其執行過程的計算機軟件系統。典型的WFMS至少由如下幾個模塊組成：業務流程建模定義工具、過程定義、工作流執行環境（引擎）、任務管理。當然還會包括應用和IT工具。常用的工作流引擎有osworkflow,jbpm,shark。剛學習了一點osworkflow，現在轉向jbpm，公司要求，沒辦法。osworkflow，最大特點就是靈活，這個網上都說遍了。也就是說它提供了一個引摯，在此基礎上你可以進行擴展，可以自已寫一些條件、動作類，只是繼承它的接口就行，不需要修改它的源代碼。他只提供一個工作流控制框架給你，他也只專注于管理工作流自身的東西，對其他的東西不管，其他的功能對他來說都只是一個插件組件。所以你可以自己擴展里面的功能，例如用戶管理模式，工作流本身不帶用戶模式，他公司的另外一個項目osuser，可以結合使用來管理用戶權限，當然你可以不用osuer，自己建立自己的用戶模式，其實就是建立自己的運行判斷條件；支持多種插件式的持久化機制；他的數據表也很少，就三個……

Shark的流程定義語言是XPDL，我們知道，XPDL的兩個最重要的概念是Process和Activity。XPDL中的Activity是基于UML1.x中的活動圖的概念。活動圖天生的適于工作流程建模，它相對于狀態圖的一個最大的優點是容易做并發線程的分叉控制，這些并發線程可以同時執行也可以順序執行；它還有一個優點是有泳道的概念，可以控制工作流引擎中的任務的產生。Shark的如來神掌是活動圖。Osworkflow的如來神掌又是什么呢？我們知道，它有個重要概念是State……呵呵，我們知道了，它的如來神掌是FSM。不知道FSM是什么東西？？那你讀大學時肯定不是好學生；當然了，不知道也不打緊，你把他類似理解為狀態圖就可以了。Osworkflow中的State是由step和status聯合表達的，一個State就是一個step中的某個status；而state的轉換由action來驅動，類似狀態圖中的event,因為一個event對應一個action嘛。Jbpm的如來神掌就沒有上面的簡單了，它結合應用了狀態圖+活動圖+PetriNet的知識，而且，這里的活動圖還是UML2.0版的。UML2.0的活動圖中，節點不叫活動（Activity）而叫動作(action)，活動成了一個高層次的概念，它包含一個動作序列。一個活動圖展現一系列的動作，這些動作組成了活動。Jbpm把action也改名了，稱為state。Jbpm使用的狀態圖的概念有transition/event等，這個自己去看吧。Jbpm來內部實現中還采用了PetriNet的概念，如token,signal等。什么？又不知道PetriNet什么東東？那你大學是學計算機的嗎？不是？那你可能是學文科的，學機械/電氣/土木工程/交通運輸等專業都有接觸PetriNet的課程，如果沒有學過，還是看看jbpm吧，反正我們也不搞理論，知道大致概念就行。

軟件學習到迅騰國際，老師都會給你提供這些資料的，只要你問就可以了，至于地址嗎？自己查吧！我也只知道哪里是學習軟件的。我是在北京學的。

第四篇：基于Web的工作流管理系統的設計與實現

摘要:Internet/Intranet應用的普及和Web技術的發展，為Web工作流管理系統的實現提供了一個理想的平臺，而基于Web的工作流管理服務為異地辦公及跨企業的合作提供了良好的基礎，采用Web技術已成為新一代工作流管理系統的主要特征。本文研究開發的工作流管理系統原型將Web技術

與XML相結合，給出了基于xml的過程定義語言與工作流執行機的設計與實現方法。

關鍵詞：工作流、工作流管理系統、XML，集成、工作流執行機

Abstract:The rapid growth of Internet/Intranet usage and development of Web technologies,provides a ideal platform to construct a Web_based workflow management.And the Web_based workflow management service provides condition for distributed working and inter-enterprise corporatin ,and it has become the characteristic of the next-generation workflow management.The WFMS prototype which this paper researched on combines the Web technologies and XML ,and provides a method of designing and implementing xml_based process definition language and workflow engine.keywords:Workflow ,workflow management systems ,XML,Integration、Workflow Engine

1、引言

工作流的概念起源于生產制造業與辦公自動化領域。工作流是一類能夠完全或部分自動執行的經營過程，根據一系列過程規則，文檔、信息或任務在不同的執行者之間傳遞、執行。工作流的目的是通過將工作分解成定義良好的任務、角色，按照一定的規則和過程來執行這些任務并對它們進行監控，達到提高辦事效率、降低生產成本，提高企業生產經營管理水平和企業競爭力，實現現代企業經營過程重組（BRP）、經營過程自動化。

根據工作流系統所采用的任務項傳遞機制的不同，工作流管理系統主要有三種方式：（1）、基于文件的工作流管理系統——以共享文件的方式來完成任務。這種類型的產品是產生最早、發展最成熟、最具多樣性的，通常包含有Client/Server模式的圖像、文檔與數據庫管理系統。（2）、基于消息的工作流管理系統——通過用戶的電子郵件系統來傳遞文檔信息。這種產品都實現了一種或多種電子郵件系統的集成。（3）基于Web的工作流管理系統——隨著計算機網絡技術的發展和Internet應用的不斷普及，Web技術因其界面的一致、簡單及與平臺的無關性，在其出現之后就得了迅速發展。同時Internet的發展及企業Intranet的建構為人們提供一個理想的協同工作環境，同時也使基于Web的工作流管理系統成為可能。

Web應用程序開放、跨平臺的特性使基于Web的工作管理系統已經成為一種必然的發展趨勢。但目前因為不同的研究者、廠商使用不同的工作流的描述方法，這樣就造成了不同的工作流產品之間不能進行互操作，因而在很大程度上阻礙了工作流技術的推廣與應用。

為了使工作流管理系統具有的良好的互操作性，本文研究開發了一個基于Web的工作流管理系統，其中工作流過程定義采用了基于XML的過程定義語言。XML是用來描述文檔的組織結構，XML具有簡單、自定義的優點，可以實現不同產商之間的工作流產品之間的互操作性，實現異構信息的集成。

本文首先介紹了當前工作流管理系統的一些相關概念，分析了在本系統中的一些關鍵技術，包括系統的體系結構，工作流模型中的主要實體的XML描述及工作流執行機的設計與實現等。

2、工作流管理系統的介紹

基于Web的工作流管理技術是實現企業協同工作環境的一個良好方法，它能方便的與企業內原有的應用、信息集成。

為了實現對業務過程的工作流管理，需要相應的軟件系統的支撐。此種軟件系統為工作流管理系統（Workflow Management System,WfMS）。根據WfMC 的定義，工作流管理系統是“一種在工作流形式化表示的驅動下，通過軟件的執行而完成工作流定義、管理及執行的系統”，其主要目標是對業務過程中各活動發生的發后次序及同活動相關的相應人力或信息資源的調用，進行管理而實現業務過程的自動化。工作流的過程定義是指對業務過程的形式化表示，它定義了過程運行中的活動和所涉及到的各種信息。這些信息包括過程的開始和完成條件、構成過程的活動以及進行活動間導航的規則、用戶所需要完成的任務、可能被調用的應用、工作流機的引用關系以及與工作流數據的定義。其中活動指的是工作流中的一個邏輯步驟；工作流實例指的是工作流的一次執行過程；工作流機是一個為工作流實例的執行提供運行服務環境的軟件或“引擎”，它是工作流執行服務的核心，負責對解釋過程定義、控制過程實例的執行、控制工作流中各個活動的執行順序、并完成與其它工作流機的交互與通訊。

1994年11月，工作流管理聯盟發布了工作流管理系統的參考模型(見圖1)，該模型定義了一個基本的工作流管理系統所需要的6個基本模塊，并制定了各模塊之間的接口標準。其基本的模塊功能如下：

1）過程定義工具：為用戶提供一種對實際業務過程進行分析、建模的手段，并生成業務過程的可被計算機處理的形式化描述。

2）工作流執行服務：它借助于一個或多個工作流機，激活并解釋過程定義的全部或部分，并同外部的應用程序進行交互，完成工作流過程實例的創建、執行與管理，為工作流程的運行提供一個運行時環境。

3）其他工作流執行服務：在大型的WfMS中，工作流可能需要多個工作流機共同完成，甚至需要其他異質的工作流執行服務來輔助來完成，這涉及到WfMS系統之間的互聯。

4）客戶應用程序：它給用戶提供一種手段，以處理過程實例運行過程中需要人工干預的任務。每一個這樣的任務就被稱為一個工作項。WfMS為每一個用戶維護一個工作項列表，它表示當前需要該用戶處理的所有任務。

5）被調應用程序：指工作流執行服務在過程實例的運行過程中，調用的、用以對應用數據進行處理的程序。在過程定義中包含這種應用程序的詳細信息，如類型、地址等。

6）管理及監控工具：其功能是對WfMS中過程實例的狀態進行監控與管理，如用戶管理、角色管理、審計管理、資源控制等。

3、基于Web的工作流管理系統的總體結構

體系結構的設計主要遵循如下3條原則：

（1）、基于Internet/Intranet分布式計算環境，面向跨部門、跨企業的分布式工作流管理。

（2）、集成已有的各種信息資源，如電子郵件、文檔管理、圖形瀏覽、資源管理等，充分發揮這些資源的綜合潛力。

（3）、與工作流管理聯盟參考模型保持一致，其中過程定義語言采用XML－WPDL（基于XML的過程定義語言），以利于實現不同企業的WfMS系統的互操作。按照上述原則所設計的Web_WfMS的體系結構如圖2所示：

整個系統的工作方式如下：

(1)、工作流應用建模人員通過Web瀏覽器將過程及表單定義工具從Web服務器上下載下來，完成應用系統的建模，即實際工作流程的定義。建模結果以XML-WPDL文檔保存在服務器中，并可反復修改。

(2)、客戶端用戶通過瀏覽器登錄到Web服務器，此時可以啟動新的流程、處理其工作項等。每個工作項都與一個表單對應。在表單中以各種不同的方式表示需要處理的數據。用戶可以通過客戶端所提供的各種工具（如CAD系統、CAPP系統、字處理系統）對這些數據進行處理。在此過程中可以與數據庫系統進行交互，如查詢數據庫中信息，或將某些應用數據保存到數據庫中等。處理完成之后可將其提交，然后工作流執行機將根據表單中數據生成下一個工作項，并通知相應的用戶進行處理，如此直至整個流程的完成。

(3)、管理人員使用工作流管理監控工具對工作流的運行實例、活動實例的狀態情況進行監控和管理，如掛起、重啟動、終止某個過程實例。

4、基于Web的工作流管理系統的設計原理與實現機制

基于Web_WfMS的總體設計，將從工作流模型、工作流執行機、安全權限控制等3個方面討論本系統的實現機制。

4.1 工作流模型

工作流模型是整個工作流系統設計的基礎，也是過程定義人員進行系統二次開發的基礎，模型描述能力的強弱決定了系統所支持應用范圍以及系統的靈活度。在工作流模型方面，工作流管理聯盟定義的過程元模型定義了6個基本實體：過程定義、活動、轉換條件、工作流相關數據、角色、需要激活的應用程序。

各種不同的建模工具僅是對工作流模型的一種形式化的描述，為了實現不同的WfMS的過程定義能相互交互，在本系統中采用了其于XML的過程定義語言對過程建模進行描述（如圖3）。

下面將分別介紹XML_WPDL的過程定義、活動和轉換條件三種實體的描述。

① 過程定義

② 活動定義

③ 轉移條件：

4.2 工作流機的實現與異常處理機制

4.2.1 工作流機的實現

工作流執行服務是工作流管理系統的核心。工作流執行服務由一個或多個工作流機組成。工作流機實際上是企業經營過程的任務調度器，在某種程序上還是企業資源的分配器。在采用工作流管理系統支持經營過程運行的企業中，工作流機可以看成是企業的業務操作系統（BOS）。工作流機的主要功能是：解釋過程定義、負責調試流程的運行、即創建和管理過程實例運行、調度活動的運行并創建要處理的工作項、維護工作流控制數據和相關數據、維護用戶的工作列表。工作流執行機的結構如圖4所示：

圖4 工作流執行服務的結構圖

其具體的執行過程：工作流機接受從外部接口發送過來有關過程控制的請求（如過程初始化、獲取活動以及結束活動等），然后根據不同的請求類型調用相應的處理模塊完成與本次請求相關的操作并將結果返回。事實上可以將工作流機看成一個多線程的并發服務器，它可以對多個外部請求提供并發服務。對外部請求的處理過程中肯定會涉及到對工作流相關數據的讀寫和更改操作，同時工作流機還維護著工作流的控制數據，通過工作流控制數據來辨別每個過程或活動實例的狀態，并推動著工作流過程的執行。過程、活動、工作項構成了工作流機的主要邏輯。在我們的系統中采用了對象的封裝和繼承的方法，把它包裝為普通的C＃類。三個類的定義如下：

(1)、public class WEProInstanceManager {} //工作流執行機的過程實例的管理類

(2)、public class WEActInstanceManager {} //工作流執行機的活動實例的管理類

(3)、public class WEWorkItemManager {} //工作流工作列表管理類

4.2.2 工作流機的異常處理

工作流的錯誤包含兩種錯誤，一是流程錯誤，如活動的執行者不存在，活動的應用程序定義錯誤等；另一類是系統的錯誤，如：網絡不通，數據庫系統異常。對于工作流執行機來說，前類異常是屬于無法處理的錯誤，只能進行錯誤的通知；后者是執行機可以處理的錯誤，如數據庫異常或連接臨時中斷等等，執行機可以進行容錯處理，例如：在數據庫恢復后自動重新建立連接。執行機對可能出現的錯誤進行編碼，并附有對應的描述信息。

在我們的系統中采用了C＃的異常處理思想(在C＃的編程思想中，系統的錯誤是通過捕獲異常來實現的)，拋出的異常通過異常類WEException來描述。WEException類繼承了C＃的異常處理類Exception。并覆蓋了Exception類的屬性Message(){get{}},其中WEException類中保存了可識別的異常對照表。在C#的異常處理中，在出錯的地方將異常拋出，不進行處理。異常被拋到更高的層次，直到某個層次能夠進行這種異常的處理。

4.3、工作流管理系統的安全權限控制

工作流管理系統對安全性要求較高，為了達到要求，必須做到充分的安全控制。在我們的系統中，共設置了5層安全控制級別。

1)、用戶鑒定：用戶登陸系統，需要用戶輸入用戶名和密碼，以便確認和登記。

2)、服務器訪問控制：保證只有授權用戶，才可登陸指定的服務器。

3)、數據庫訪問控制：對數據庫的訪問進行控制

4)、文檔訪問控制：對數據庫中的文檔進行權限控制。

5)、文檔中的域訪問控制：對文檔中的部分內容進行控制。通過以上五層安全控制再加上一些安全機制如：系統級權限控制、電子簽名和加密等，使得整個安全機制達到了系統對安全的需要。

5、結束語：

以Web作為工作流管理系統的底層通訊支持使系統具有開放、一致和方便使用的特點，使企業中處于孤島的信息能相互集成。本系統采用的基于XML的過程定義語言的工作流管理系統，不僅適應分布辦公，更以系統開放的環境為實現跨部門、跨企業的供應鏈的不同工作流互操作打下了基礎，使客戶、供應商、或合作者都可以方便的參與企業的工作流，提高工作效率。參考文獻

[1]WfMC,“The Workflow Reference Model”.(WfMC-TC00-1003),Technical Report,Workflow Management Coalition,Hamnshire.1995.[2]史美林、楊光信、向勇等。WFMS：工作流管理系統[J]。計算機學報，1999（3）：326~328。

[3]范玉順。工作流管理技術基礎—實現企業經營過程重組與經營過程自動化的核心技術[M].北京：清華大學出版社，2001。

[4]Mohan C.Recent Trendsin Workflow Management Products,Standards, and Research.URLhttp://www.tmdps.cn,1999-10

第五篇：工作流引擎五大接口

工作流引擎的五大接口

工作流參考模型確定了工作流管理系統的基本架構。該架構是開發工作流軟件時應當采納的系統模型，當然，一個工作流管理系統也可以不遵循這個模型標準，或只實現這個模型的一部分，但事實證明，這個模型結構是目前最為合理的。

系統的核心部分是工作流引擎，引擎是驅動流程流動的主要部件，它負責解釋工作流流程定義，創建并初始化流程實例，控制流程流動的路徑，記錄流程運行狀態，掛 起或喚醒流程，終止正在運行的流程，與其他引擎之間通訊等等工作。WfMC沒有針對引擎的實現提供具體的標準，因為對引擎做過多的約束并沒有多大的現實意 義。

一個工作流管理系統可以包含一個或多個引擎，并通過API向外部提供五個方面的功能服務，這些功能分別為：

· 接口1－流程定義的導入導出

· 接口2－同客戶端應用程序和工作列表處理程序之間的交互

· 接口3－軟件工具和應用程序的調用

· 接口4－不同工作流管理系統之間的協同工作

· 接口5－管理和監視功能

接口1－流程定義的導入導出

許多不同廠商提供的工具可以進行工作流流程的分析、建模、描述和歸檔等工作。這些工具需要識別公共的流程交換格式，以支持在這些不同的產品之間傳送工作流程流程定義。接口1便定義了這樣的交換格式。此外，接口1還定義了設計環境與運行環境之間交換的規范，以使不同的建模工具產生的流程定義可以輸入到不同的工作流產品的運行環境中。

為了提供一個訪問和描述工作流定義的公共方法，需要引入一個工作流元數據模型（meta－data Model），這個模型確定了流程定義中用到的一般的實體，這些實體都有不同的屬性，不同廠商開發的工具可以根據公共的交換形式向工作流運行環境傳送這些模型，傳送可以通過API實現，也可以通過批量（Batch）傳送實現。

元模型提供了流程定義交換中用到的基本的實體及其屬性，這些都是工作流流程的組成部分，這些實體包括：

工作流流程定義 工作流流程活動 過渡信息（Transition Information）工作流參與者 組織模型 工作流應用程序 工作流相關類型 工作流相關數據 系統和環境數據 數據類型和表達式

流程定義的交換

在不同的系統之間傳遞流程定義數據可能需要不同的機制，但在所有的情況下，流程定義數據的表達必須是一致的，這些表達包括一些公共的對象、關系及其屬性。接口２與接口３：

工作流管理系統必須提供同用戶之間交互的通道，以便用戶參與到系統的運行中。接口2主要完成這方面的功能。

WfMC在關于接口2 的規范中定義了工作流管理系統必須提供的類型、數據結構、API和錯誤代碼，并以C語言頭文件的形式提供。接口2所提供的功能大致可以分為一下五個方面：

1、會話的建立和與撤銷；

2、獲取工作流流程定義及狀態；

3、工作流流程實例的操作，如創建、掛起、終止流程，獲取和設置流程屬性等；

4、工作流活動實例的操作，如獲取和設置活動的屬性，改變活動的狀態等；

5、工作列表（worklist）及工作項（workitem）的操作，如獲取工作列表，處理工作項等。

通過這些功能，用戶可以完成與工作流管理系統之間交互的所有任務：登錄系統、打開自己的工作列表、處理自己的工作任務、將完成的任務提交給系統、將自己的任務轉交給其他用戶等等。

工作流系統在運行過程中有時需要調用外部應用程序，以完成系統不能完成的工作（比如，發送Email或傳真，掃描文件等），或者與其他系統集成到一起。此時可以通過接口3來完成。

接口3的功能同接口2的功能大部分是相同的，因此，這兩個接口有融合的趨勢。接口3主要規定了調用外部應用程序的函數規范，以及外部應用程序返回數據的格式。

接口4－不同工作流管理系統之間的協同工作

在企業級的工作流系統中，流程往往需要跨越多個服務器或系統，比如應用于跨國公司或大型集團公司的工作流系統經常會有這種的需求，此時就需要服務器或系統之間進行通訊，交換流程控制信息和流程定義等數據，以實現流程跨地域運行。WfMC在規范中以C函數的形式提供了這些控制的定義，其中包括以下幾個方面的功能：

1、創建流程實例；

2、獲取流程實例狀態；

3、獲取和設置流程實例屬性；

4、啟動或終止流程實例；

5、改變流程實例的狀態；

6、改變流程實例的屬性；

7、更新流程實例 服務器或系統之間信息交換的格式有多種，例如：文件、數據庫表、E-mail或直接通過網絡傳送的數據流等等。

接口5－管理和監視功能

此接口提供給用戶管理和監控系統的運行狀態、查看系統運行的歷史記錄的功能。WfMC在此接口的規范中定義了各種審計信息的數據格式，這些格式包括：

1.流程實例（Process Instance）審計信息：包括創建、啟動流程實例和子流程實例的審計數據；流程實例狀態變化的審計數據；流程實例屬性變化的審計數據；

2.活動實例（Activity Instance）審計信息：包括活動實例狀態變化的審計數據；活動實例屬性變化的審計數據；

3.工作項（Workitem）審計信息：包括工作項狀態變化的審計數據；工作項分配合重新分配的審計數據；工作項屬性變化的審計數據；

4.遠程操作審計信息：包括開始和停止會話（Session）的審計數據；遠程創建流程實例和遠程改變流程實例狀態的審計數據；遠程獲取和設置流程實例屬性的審計數據；會話管理的審計數據； 5.流程定義審計信息；

6.擴展的審計信息及專用的審計信息這些審計數據在系統運行時刻由系統自動記錄在數據庫或文件中，可通過系統提供的API進行統計和查詢，或者通過系統工具導出到系統外部。

另外，此接口還要提供系統管理與流程控制的功能，如：系統流程數據的備份和恢復，用戶管理，流程管理等等。

通過這五個接口，工作流管理系統可以同外部的軟件工具進行交互，這些工具可以由同一廠商提供，也可以由不同的廠商提供，但前提是這些工具都必須遵循WfMC的規范。用戶也可以有充分的選擇空間來決定哪一廠商的產品，或者自己開發屬于哪一個接口的工具。

這五個接口一般通過API的形式提供給用戶或軟件開發商，這些API稱為WAPI（Workflow API），也有廠商將API封裝成組件形式提供，以簡化開發難度、降低成本并提高效率。

可以用下面的圖來表示這五個接口的作用：