摘 要: 針對業務流程管理系統" title="管理系統">管理系統中業務流程的快速、靈活實現,對工作流" title="工作流">工作流引擎的設計和實現方法進行了研究,提出了一種新的基于BizTalk Server的工作流引擎實現方案。
關鍵詞: 業務流程管理系統 工作流 工作流引擎 BizTalk Server 2004
由于信息技術的發展和日趨激烈的商業競爭,人們不再滿足于獨立、零散的辦公自動化和計算機應用,而是需要綜合化、集成化的解決方案。因此,作為一種對常規性業務進行管理調度的技術,業務流程管理系統的出現是必然的。隨著國家電信體制改革的繼續深化,電信行業多元化的競爭格局正在加速形成,各電信運營企業的發展環境面臨著嚴峻的形勢。雖然目前各電信企業為了提高服務質量與管理效益,都已經建立了一整套的業務流程規范指導各自的業務活動,但是許多業務流程的實際運行還是采用填寫紙介質業務表單文件、傳遞紙介質文件(例如、傳真)的方式處理。即使有一些零散的IT系統,也缺乏一體化、端到端全過程的IT技術支持,無法從根本上改變傳統手工作業的低效率,缺乏有效過程控制管理,與企業IT信息化的要求并不相符。這種狀況也影響了業務流程規范化的全面推進和實施。要獲得業務流程規范化的全面、真正實施和提高服務質量與運行效率,必須引進業務流程管理系統,實現業務流程電子化、信息化,將業務流程中的信息流轉與控制管理從手工填寫紙介質表單、傳遞紙介質文件的手工作業方式中解放出來,從而實現企業經營模式從“以網絡為中心”向“以客戶為中心”的轉變,達到增強企業自身生命力和提高企業競爭力的目的。
1 工作流參考模型
工作流參考模型由工作流管理聯盟WFMC(Workflow Management Coalition)提出,是工作流管理系統的一個參考模型。本文所提到業務流程管理系統仍以此參考模型作為抽象的依據框架。其框架如圖1所示。從圖1中可知,模型由六個組件組成:
(1)工作流核心服務。即工作流引擎,主要功能是讀取工作流定義,根據工作流定義驅動工作流的流轉。
(2)流程定義工具。實現以圖形化拖拽的方式定義工作流的功能,將現實的各種業務流程轉化為其計算機表現形式。
(3)工作流的客戶端應用。可以是B/S或C/S結構。它向用戶提供一個工作界面,用來啟動、驅動業務流程。客戶端應用通過接口2與引擎交互。
(4)其他外部系統。在工作流運行過程中,工作流引擎還可以與外部各種應用程序交互,這里可通過定義好的接口3來完成。
(5)其他工作流核心服務。指其他工作流引擎服務。通過接口4實現多個工作流引擎交互與協作。
(6)管理與監視工具。用于整個系統的管理與監視。
此模型為工作流管理系統確立了一個基本、合理的框架。整個管理系統的核心是工作流引擎。工作流引擎是流程流動的驅動源,它負責解釋工作流的流程定義,創建并初始化流程實例,控制流程實例的運轉走向,并記錄其狀態變化等。
2 Microsoft BizTalk Server 2004簡介
Microsoft BizTalk Server 2004是微軟最新推出的企業應用集成平臺,旨在促進企業內部及企業之間電子商務流程的協作。該產品構筑在MS.NET Framework之上,并且與VS .NET 2003和Office System緊密集成,能夠為用戶提供增強的商務流程整合能力、新的商務行為監控特性以及高度伸縮的新式規則引擎,使開發者、專業IT工作者和商業分析家能夠非常輕松地在Internet上建立一個跨平臺、跨應用、跨企業的動態業務過程。
3 工作流引擎方案實現
3.1 業務流程管理系統
參照上述工作流參考模型,在為國內某電信運營商開發的業務流程管理系統中,采用了如圖2所示的整體框架。此框架上層是以MS SharePoint Portal門戶系統為依托、即插即用的UI組件,中間是工作流應用系統" title="應用系統">應用系統,底層是BizTalk EAI Adapter總線系統。底端利用BizTalk Server自身的各種Adapter和各種異構系統互連互通。其中工作流應用系統由輔助工具、系統管理模塊、任務節點組件、建模輔助工具等構成。工作流應用系統中的輔助支持工具包含客戶資料管理、知識幫助(專家資源、案例庫)、便箋、留言板、滾動消息等應用模塊;任務節點組件包含在Visual Studio .NET環境下開發的業務操作組件、判斷選項組件、查看視圖組件;建模輔助工具包含UI組件庫、工作流模型庫、流程任務規范定義等模塊。BizTalk工作流建模工具以圖形化拖拽的方式建立流程模型并配置屬性。工作流引擎采用BizTalk Server2004(簡稱BTS),是整個系統運轉的控制核心。它根據建模輔助工具的輸出結果,調用任務節點組件,利用適配器接口和各種異構系統及后臺數據庫交互,實現了各流程穩定流轉、各系統平滑互通的目標。
3.2 通用任務節點抽象
BTS提供了消息定義/消息轉換映射、傳輸管道創建、流程/任務編排、端口定義、傳輸協議選擇等一系列開發工具。利用BTS做引擎的一般流程開發方法和步驟為:(1)定義各消息格式(Schema)并創建不同格式消息間的轉換映射(Map);(2)編配流程圖,即定義各流程的任務節點(Orchestration)并配置收發端口和傳輸協議(Prot Configure);(3)編譯(Build)并部署流程(Deploy),成功后就得到可以運行的流程。BTS具有較強的功能,但同時開發難度和繁瑣度也很高。在流程數目較少、任務節點簡單的情況下可以采用上述開發方法。但是,在實際開發業務流程管理系統時,不僅流程的數目繁多,而且各流程在任務數目、任務類型上差別很大。如果按照上述開發方法,即針對每個流程開發一個流程圖并進行配置,無疑會極大地增加開發人員的工作量,耗費大量人力、物力,而且在運行維護階段要面對的任務也是異常艱巨的,遠遠達不到系統開發的進度要求和后期維護難度要求。鑒于以上原因,經過研究改進,綜合考慮各類型流程和任務的共同特性,最后在任務級別上得到統一的抽象:即雖然流程在業務邏輯、任務數目上有很大差別,但畢竟都是不同類型任務的某種組合(例如任務類型有判斷節點、操作節點、選擇節點、子流程節點、查看節點)。如果在一個Orchestration(編排,BizTalk的流程定義)能夠實現對每一種類型任務的處理,則這個Orchestration就是所有不同類型任務的共同抽象模版,即通用任務節點抽象。這樣可以拋開BTS復雜的開發界面,結合本業務流程管理系統的另一功能模塊——建模工具,快速靈活地搭建各種類型的流程。實際運行時,BTS只需根據任務抽象模版實例化" title="實例化">實例化一個任務并反復循環,直到流程結束。
通用任務節點抽象如圖3所示。
3.3 數據模型
本業務流程管理系統采用SQL Server 2000作為數據庫系統,用來存儲系統所用到的各種數據表。本系統數據模型包括機構數據模型和業務數據模型兩部分。機構數據模型描述企業或者部門的組織機構關系,業務數據模型則定義工作流引擎中所用到的各種控制數據和流程實例數據。通過數據模型,可以方便地描述關鍵業務的業務規則、任務的依賴關系以及任務的部門/角色指派等特征。本文只討論與工作流引擎關系緊密的業務數據模型。圖4給出了業務數據模型之信息模型的ER圖(只給出核心表結構)。
(1)流程模型表WorkFlow Table
此表主要記錄各種類型流程的定義,表格中的數據由建模工具在流程定義階段生成。其中:
Guid字段是主鍵,表示流程編號;
TypeId字段表示流程類型編號;
Name字段表示流程名稱;
TimeLimit字段表示流程結束時限;
TimeConfig字段表示此流程參照的時間配置,它同時是時間配置表的主鍵;
Operator字段表示流程的授權發起人(或角色)。
(2)任務模型表 WorkTask Table
此表主要記錄各種類型任務的定義,其數據也是在流程定義階段由建模工具生成,包括任務編號、任務名稱以及綁定頁面地址URL等。
(3)任務聯結表WorkLink Table
此表主要記錄任務間的連線數據屬性,包括頭、尾節點標識及條件。
(4)流程實例表WorktFlowInstance
此表主要記錄正在運行和已經結束的流程實例的相關信息,其每條記錄由工作流引擎從流程模型表實例化得到。相關字段記錄了對應流程實例所屬流程模型類型、流程名稱、當前活動節點位置、開始時間、運行狀態(運行、掛起或正常結束)、流程實例發起人以及是否超時等狀態信息。
(5)任務實例表 WorkTaskInstance Table
記錄正在運行和已經結束的任務實例的信息。它的數據由工作流引擎從任務模型表實例化得到。
(6)時間配置表 TimeConfig Table
記錄企業的工作時間制度,即上下班時間、午休時間以及告警/預警占全部時限的百分比。根據此表,工作流引擎由流程和任務的相對時長換算成絕對時長。
3.4 引擎核心控制算法
在抽象任務節點中調用代碼,以動態、實時地獲取下一步任務。當前任務提交后,通過對流程模型、任務模型表的操作實例化下一步任務。實例化任務的算法如圖5所示。
3.5 工作流引擎運轉過程
流程發起人在客戶應用端啟動一個流程,則系統自動向引擎接收端口發送一個消息。引擎在收到此消息后被激活,經過如下步驟完成運轉過程:
(1)引擎根據當前提交的消息,初始化提交任務實例,即向相關崗位角色分配第一個(如果不是在流程剛啟動時,就是“下一條”)任務。
(2)引擎調用超時處理模塊" title="處理模塊">處理模塊,開始對剛分配的任務計時。此時引擎處于等待狀態,等待任務責任人完成任務后提交消息。如果任務沒有在規定的時間內完成,任務將被標志為超時。超時處理模塊此時將通過頁面醒目顯示、即時消息等方式通知任務責任人或根據需要通知上級責任人。特定類型任務(如審批等)超時后自動流轉到下一任務,其他情況下引擎再次進入等待狀態,直到任務完成。
(3)任務責任人完成任務后,系統自動發送一個提交消息給引擎。引擎收到此消息后超時模塊結束。引擎根據接收消息判斷流程操作人員(即此時的任務責任人)是否要結束流程。因為流程在某些任務節點可以被無條件人工結束。
(4)如果流程被人工結束,則轉到(8)。
(5)如果不是異常結束,則調用“任務指派”代碼功能模塊,得到下一步需要指派的任務列表。
(6)判斷任務列表中任務數量是否為零。如果為零則說明所有的任務已經完成,直接轉到(8)。
(7)否則,對該任務列表中的首個任務調用指派任務處理模塊進行任務的實例化。實例化完畢后轉到(6)。
(8)引擎初始化返回消息,該流程執行完畢。
基于此工作流引擎方案的業務流程管理系統很好地滿足了客戶的需求,并已在某省公司成功上線運行及在其他地市級公司全面推廣。此方案的優點為:
(1)簡單快速。各任務節點被抽象后,開發階段就不用過多考慮任務類型的細節問題,這樣整個開發過程被大大縮短,從得到需求到流程上線運行只需一兩天時間。
(2)靈活穩定。強大的代碼支持功能可以靈活地根據需求很快地對流程做出相應調整,并且不影響系統的正常運行,使系統的穩定性得到有效保證。
參考文獻
1 蒲 春,陳淳鑫.工作流系統中系統管理模塊的設計與實現[J].微型機與應用,2004;23(4)
2 范玉順.工作流管理技術基礎[M].北京:清華大學出版社,2001
3 WFMC.FMC-TC-1025 1.0 Workflow Management Microsoft.Coalition Draft[R].2002
4 Microsoft.Microsoft BizTalk Server 2004評估指南[R].http://www.eu.microsoft.com/china/biztalk/community/Product/a3.asp