基于工作流引擎的信息系統通用框架設計

（成都信息工程學院 網絡工程系， 四川 成都 610041）

摘 要：主要介紹了一種基于工作流引擎的信息系統通用框架設計。針對網絡信息系統，通過修改數據庫中的數據，就可以自動構建整個信息系統的框架。基于大多數關鍵業務均離不開工作流的支持，采用關系結構的理念來設計工作流引擎，并詳細地給出了相關的框架模型、機構模型、信息模型和控制模型的設計原理以及具體的表示和實現方法。應用該方法大大縮短了基于信息系統的項目開發周期，提高了工作效率。

關鍵詞： 通用框架； 工作流引擎； 關鍵業務； 關系

中圖法分類號： TP391文獻標識碼： A

文章編號： 1001 3695(2006)08 0222 03

Workflow Engine based Information System’ s General Framework Design



FANG Rui， HAN Bin， GAN Gang

(Dept.of Network Engineering， Chengdu University of Information Technology， Chengdu Sichuan 610041， China)

Abstract: It mainly introduces a method to design a workflow engine based nformation system’ s general framework.In allusion to network based information system， we can set up the whole information system and systematic managing mode through modifying some data in the database. Workflow technology plays an important role in the development of critical business applications. The concepts of relationship is adopted to design the workflow engine are thoroughly discussed in the paper. Also， this paper sets forth the principle to design，the representation of the way to implement the framework，organization， information and control model of the workflow engine，respectively.This method will shorten the developing period of the project which is based on the C/S mode information system，and will enhance our working efficiency as well.

Key words: General Framework; Workflow Engine;Critical Business; Relationship 

隨著信息技術的高速發展，越來越多的企業需要建設各種各樣的信息系統，這些系統應用已不僅僅停留在諸如文檔處理、公文流轉以及信息發布等這些簡單的業務層面上。越來越多的企業或部門要求將信息技術的應用擴展到關鍵業務中。在實際應用中，目前將工作流管理系統引入控制信息系統執行過程。在國際工作流管理聯盟（WfMC）的工作流參考模型中，工作流引擎是工作流管理系統的核心。工作流引擎是為工作流管理系統的定義提供支持；同時在運行時提供解釋和執行服務的一組數據模型和軟件。

根據文獻中對工作流引擎體系結構的討論，我們將基于工作流引擎的信息系統框架定義為數據模型和控制模型。其中基于工作流引擎信息系統框架的數據模型又分為框架模型、機構模型和信息模型三類。

本文以開發某省電信部門的物流信息系統為基礎，同時結合其他不同的企業和部門的關鍵業務的特點，在傳統的DBMS基礎上來討論一個基于工作流引擎信息系統框架具體的設計原理與實現方法。

1 系統技術方案

基于工作流引擎信息系統的通用框架主要包括系統框架和工作流引擎兩大部分。

在此采用關系結構數據庫為開發平臺，即信息系統通用框架的數據模型（框架模型、機構模型和信息模型）全部通過關系結構來表達；控制工作流引擎運作的各種程序邏輯（即控制模型）也是通過常規關系數據庫管理系統中所提供的存儲過程、觸發器以及事務等機制來實現。這樣的好處有：①與系統框架有關各類參數和與工作流引擎相關的各種控制數據（包括業務活動的狀態數據）均可以存儲在數據庫系統中；②與此相關的數據的完整性可以由數據庫管理系統來維護；③利用關系結構可以方便地定義通用框架和工作流引擎中的各種數據格式和數據結構；④可以方便地利用數據庫管理系統提供的各種DML語句來操縱工作流引擎所需的各種數據。

從開發應用系統的角度來看，在同一數據庫環境下，為開發者提供一個基于關系結構的工作流引擎的信息系統通用框架，便很容易在其基礎上構建自己的應用系統，開發人員只需要關心關鍵業務即可，此舉大大降低了開發應用系統的難度。

因此，采用基于關系結構的工作流引擎信息系統通用框架來構建常規的信息系統，開發時間將大大縮短。

2 系統實現

2.1 數據模型

基于關系結構的工作流引擎信息系統框架的數據模型包括框架模型、機構模型和信息模型三部分。通過數據模型，可以方便地描述系統的框架，關鍵業務的業務規則、活動的依賴關系以及任務的指派等特征。它們均通過統一的關系結構來定義。圖1給出了數據模型的ER圖（限于篇幅只給出核心表結構）。

2.1.1 框架模型

框架模型描述的是系統的模塊組成與用戶所擁有模塊的關系。相關的表主要有SysFunc（系統模塊表）、SysUser（系統用戶）、UserInFunc（用戶模塊關系表）、SysRole（系統角色）、RoleInFunc（角色模塊關系表）和SysLog（系統日志表）。表之間的關系在圖1中標出。

SysUser表是記錄系統所有用戶信息的地方，包括系統的認證，其中IfOnLeave表示用戶是否處于休假，IfLogging表示相關的用戶是否登錄到系統。這兩個信息在工作流引擎中將被作為任務分配的提示信息。

UserInFunc / RoleInFunc表是用來表示系統用戶/角色與系統模塊之間的關系，記錄不同的用戶/角色擁有哪些不同的模塊以及對該模塊的操作權限。

2.1.2 機構模型

機構模型描述的是企業或者部門的組織機構關系。相關的表主要有SysUser，Department，Team，UserInTeam，SysRole和UserInRole。表之間的關系已經在圖1中標出。

Department和Team分別表示部門和團隊，部門通常表示縱向的行政隸屬關系，而團隊通常表示橫向的合作關系。Department和Team分別通過相應的SuperDeptID和SuperTeamID關聯使得在部門之間和團隊之間分別形成樹狀的上下級關系。

機構模型中的部門、團隊、人員以及相互間的關系為大型企業尤其是從事技術工作的企業的機構建模提供了有力的支持，同時也為現代企業流行的管理模式——“矩陣管理”提供了支持。當然，對于小型機構而言，可以考慮只定義Department或者Team其中之一。由于Department與Team之間在ER圖中并無聯系，因此缺少其中一個并不會破壞機構模型的完整性。

SysRole進一步擴展了機構模型的建模能力，關系UserInRole在SysUser與SysRole之間建立起關聯。在機構模型中引入角色這一概念主要是為了增強任務指派的能力。

2.1.3 信息模型

信息模型定義工作流引擎中所用到的各種控制數據。信息模型的核心是控制節點表ControlNode，其他相關的表結構主要有業務過程Process、活動節點表Activity、任務指派規則表AssignRule、任務狀態表TaskStatus、任務列表ToDoTaskList以及已完成的任務列表HaveDoneTasks。

(1)活動類型。每個業務過程由若干業務活動組成，不同的業務活動通過各不相同的ActID來唯一標志，ActType則指明相應活動的類型。活動類型可分為：①Initial——初始化活動。業務過程的第一個活動，不針對具體業務環節。②Normal——常規交互活動。一般的人機交互活動類型。③Dummy——啞活動。不針對具體業務環節，它可以作為某些活動的虛擬后繼活動，還可以使用它來構造更為復雜的業務規則。④Completion——終結活動表明相應業務過程的終結，不針對具體業務環節。

(2)控制類型。表ControlNode中的CtrNodeType表示控制類型。控制節點的類型為：①Direct——無條件轉移，不做任何動作，直接激活下一個節點。②AND_Branch——與分支控制，流經此處的任務將進行與分支。③AND_Merge——與合并控制，流經此處的任務將進行與合并同步。④OR_Branch——或分支控制，流經此處的任務將進行或分支。⑤OR_Merge——或合并控制，流經此處的任務將進行或合并同步。⑥Vote_Merge——投票合并控制，通過查找TaskStatus表來決定投票結果。其中②~⑤通過查找TaskStatus表來決定下一動作。為滿足業務要求，用戶可以自定義其他的控制節點類型。

(3)任務狀態。任務狀態表TaskStatus實際就是一個保存一個流程實例的所有活動節點的狀態圖集。該表在一個流程實例產生之時一并產生所有活動節點的初始狀態。生成以后則由控制節點來動態修改其狀態。任何活動節點實例的狀態可能是：①Sleeping——睡眠狀態，流程實例創建時統一設置所有活動節點為該狀態，等待喚醒。②Waiting——就緒狀態，前趨控制節點將活動喚醒，等待人工處理。③Processing——處理狀態，表示正在進行人工處理，等待處理結果。④Done_Passed——處理結束通過狀態，表示人工處理結束，移交給控制節點繼續下一步處理。⑤Done_Vetoed——處理結束未通過狀態，表示人工處理結束，處理意見為“否決”，同時移交給控制節點繼續下一步處理。

表TaskStatus實際上是一個流程實例的狀態圖，在流程創建初期一并創建。一個活動可以同時具有多個實例，即任務，這些實例可以是屬于同一批次的，也可能屬于不同批次。表TaskStatus中用SerialNo（流水號）來標志任務所屬批次，同一批次的任務具有相同的流水號。不同的任務之間則通過SerialNo進行標志。

(4)任務隊列和已完成任務隊列。任務隊列ToDoTaskList用于記錄那些已經創建但尚未完成的任務。根據控制算法，在表TaskStatus中將后繼節點狀態設置為Waiting，同時向ToDo TaskList 表中添加一條信息，系統用戶在登錄后，可以通過查詢該任務隊列看到該任務。在用戶處理過程時，將其設為Processing狀態，防止其他用戶對正在處理的任務再進行處理，造成結果不一致。

已完成任務隊列HaveDoneTasks 用于記錄那些已經正常結束的任務，CompletionFlag表示相應任務的結束標記。 User ID表示執行此任務的實際人員，GrantorID若不為空，則表示此次任務的執行過程是經過授權的，GrantorID指明相應的授權人員。

2.1.4 任務指派

任務指派是指依照某種規則將任務分配給具體人員來執行。只有常規交互活動才涉及到任務指派的問題；其他活動要么在前臺不具備實際的應用邏輯，要么由工作流引擎自動調用，因此與任務指派無關。

在前文中已經提到了許多表和字段將聯合用于工作流引擎的任務指派，其核心表結構為AssignRule，每一個常規交互活動在AssignRule表均對應一條記錄。BasedOn指明任務指派的基準，它可以取值為

（1）Dept_Based。基于部門進行任務指派，DeptID用于指定執行此活動的部門。

（2）Team_Based。基于團隊進行任務指派，TeamID用于指定執行此活動的團隊。

（3）Role_Based。基于角色進行任務指派，RoleID用于指定執行此活動的角色。

（4）User_Defined。基于自定義的方式進行任務指派，ExeFuncID指明相應的自定義執行程序。

任務指派的基準確定了可以執行相應任務的群體，具體指派到哪些實際人員還取決于任務指派方法Method，Method可以取值為

（1）All。任務將分配給由BasedOn指定的群體中的所有人員。

（2）Least_Working_List。任務將分配給指定群體中的工作量最少的人員，工作量的多少可以通過ToDoTaskList的統計數據得到。

（3）FCFA。先來先分配， 即將任務隊列中最早創建的任務分配給相應群體中最先提出執行任務請求的個體，任務的創建時間由DateCreated指示。

（4）Priority。基于優先數分配，只適合于Role_Based任務指派基準。在表UserInRole中有個字段PriorityNo用于指定相應人員的優先級。本例中指列出了四種指派方法，用戶可以根據具體需要來添加新的任務指派方法。

2.2 控制模型

控制模型將信息模型、機構模型和框架模型有機地結合在一起，它根據其中定義的業務規則來流轉業務流程，控制模型是工作引擎的控制中心。圖2是基于工作引擎的信息系統通用框架的結構圖。

(1)調度中心。調度中心接收從個性化界面（外部接口）發送過來流程控制的請求（如業務初始化、獲取任務以及結束任務等）。根據不同請求類型調用相應的處理模塊完成與本次請求相關的操作并將結果返回。該操作是基于DBMS的并發機制和鎖機制來實現工作流引擎的控制模型，不需要諸如請求隊列等形式的數據結構。從而實現了多個外部請求之間的獨立性。

(2)狀態圖管理。調度中心在收到活動節點狀態變化觸發后，根據其后繼控制節點的類型，調用不同的算法，計算并設置控制節點后繼節點的狀態來生成狀態圖。轉換關系如圖3所示。 

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

(4)任務指派。任務指派處理只是針對NORMAL活動。通常情況下，在任務狀態由“SLEEPING”切換到“WAITING”過程中完成任務的指派工作，即處于就緒狀態的任務在通常情況下確定了其執行者（FCFA除外）。任務指派過程首先根據任務指派基準確定可以執行此任務的群體人員。通常情況下這是一個包含多個人員的集合，然后根據任務指派方法確定由這個群體中的哪些個體來執行任務，執行任務的個體標志記錄在相應任務記錄的UserID字段中。

3 應用實例

本文所討論的基于工作流引擎的信息系統框架是在一個具體的應用基礎之上提煉出來的，即某省電信部門的物流信息系統。這是一個中型的信息系統，涉及的行業部門較多。在關鍵業務中，大部分業務過程均比較復雜，如物資出庫業務，業務活動就超過八個，它們既有順序關系也有并行關系，大部分均包含往復關系，相互間的依賴關系也比較復雜。我們采用Microsoft公司的SQL Server 2000和Microsoft Visual Studio.NET 2003作為開發工具，在應用邏輯中嵌入對工作流引擎的調用從而實現流程的控制。目前，該系統已經全部開發完畢，其測試工作也已完成并將正式投入運行。實際的應用表明，由于該基于工作流引擎的信息系統框架支持，使得我們的程序員集中精力于應用邏輯的開發。應用本系統框架開發基于流程的信息系統將大大縮短開發周期，特別是在作原型開發時，效率非常高，且易于維護。

參考文獻：

[1] David M Kroenke. Database Processing Fundamentals， Design， and Implementation[M].施伯樂，等.北京：電子工業出版社，2002.

[2] WfMC.Workflow Management Coalition Specification:Terminology Glossary.Document Number WFMC TC 1011， Brussels[EB/OL].http://www.wfmc.org/，1996.

[3] R Tagg， et al . Preliminary Design of a Lightweight Workflow Server[C]. Australia：The 8th Australasian Conf. on Information Systems， 1997. 

作者簡介：方睿(1974 )，男，碩士研究生，研究方向為信息系統與數據庫、網絡工程；韓斌(1974-)，男，碩士研究生，研究方向為嵌入式系統、接口技術，人工智能；甘剛(1974-)，男，碩士研究生，研究方向為網絡工程、信息安全。

注：本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文。