武鵬 李文倚 劉小白


摘要:基于工作流引擎工具,設計了遺留系統集成工作流引擎的嵌入式結構,實現了遺留系統與工作流引擎用戶和權限數據的同步及工作流引擎節點配置的無縫集成,解決了遺留系統流程處理靈活性與可擴展性不強、難以實現用戶級靈活定制和不能快速滿足企業應用的問題,對于遺留系統流程重構具有一定的借鑒意義。
關鍵詞:工作流;系統集成;遺留系統;流程重構
DOIDOI:10.11907/rjdk.161456
中圖分類號:TP319
文獻標識碼:A 文章編號:1672-7800(2016)005-0097-02
0 引言
隨著信息系統的深入應用,各企業和組織內部產生了大量作為業務支撐的遺留系統[1]。為了滿足新的業務需求,對相關系統進行優化與重構不可避免。其中,隨著管理提升和審核流程的變更,作為系統重要功能的各類審核流程管理功能暴露出了如下主要問題:①不少遺留系統獨立開發的流程管理模塊使用了偽流程方式,依賴于流程節點序列編碼,缺乏靈活性與可擴展性;②在流程節點設計方面未能實現用戶級靈活定制,需要開發人員操作后臺數據庫或硬編碼進行人工干預。
一般的工作流產品或工具都能夠可視化地進行流程建模,并靈活適應流程節點的變化需要[2]。但通常基于工作流的信息系統開發要針對具體的工作流產品進行架構、設計和實現,既定架構、設計和實現的遺留系統并不能很好地且輕量地使用工作流工具,以發揮工作流技術的優勢。
針對上述問題,本文首先引入了工作流引擎工具,然后在原有系統架構、設計和實現的基礎上完成了工作流引擎嵌入結構設計并加以實現,通過二次開發解決了工作流引擎在現有系統中動態嵌入的問題,最終以某遺留系統為例成功完成了審核流程的重構,提高了系統的可用性與靈活性,解決了實際應用問題。
1 具體問題分析
目前某應用系統的流程管理功能基于自行開發的流程管理模塊,如表1所示。其流程管理機制是將每個流程活動狀態用一組整數序列(1,2,10,50,100,150,200)來表示,每個整數值代表一個審核狀態,讓程序記錄該狀態以便知道操作順序,以及當前處于什么狀態。然而這種機制不支持靈活修改,如表1所示。假設 “錄入完畢“和“經過了第一次審核”之間多一個活動,則意味著需要在1和2之間增加一個整數。若要滿足需求,只能重新設計相應序列并修改相關實現。
一般的解決方案是引入工作流引擎代替現有流程處理模式,以實現流程用戶級靈活自定制,提高可用性與靈活性。但面對架構、設計和實現已經成型的遺留系統,一個成熟的工作流引擎本身的可定制性有限,要實現工作流引擎與遺留系統的無縫集成,有如下問題需要解決:①遺留系統的業務數據與工作流引擎的流程實例建立關聯;②遺留系統與工作流引擎管理器用戶數據和權限數據的同步及流程節點配置的無縫集成。以下針對上述具體問題進行分析并提出解決方案。
2 設計思路與實現
2.1 遺留系統集成工作流引擎嵌入式結構
通常工作流的使用有以下幾個典型步驟:①使用工作流中類似企業管理器的工具建立用戶、組織結構和角色等基礎元素;②針對業務流程完成數據庫及數據庫表、頁面和表單設計;③使用工作流的可視化流程建模設計器完成流程建模;④在建好的流程中配置流程節點屬性。這些都建立在工作流引擎之上,依托設計器等工具即可將使用設計器設計的表單與流程建模得到的流程節點關聯起來。每張數據庫表都有類似TaskID(任務ID)的字段,該字段標識一個流程任務,由工作流引擎自動維護[3]。
其中流程建模通常是由流程節點加上一定的條件節點,按照一定規則互相連接完成。流程流轉的對象實際上是表單信息,而將表單與流程相關聯的關鍵在于流程節點的設置。通過對流程節點屬性的設置,以及表單對應的后臺數據庫表中的TaskID字段來關聯信息系統中的基本業務單元、相應表單、所在流程以及對應節點。表單的提交將發起一個流程實例,表單的處理使流程實例順著一個個節點流轉,而“提交”等處理事件將在表單設計過程中固化到表單或表單的后臺代碼中[4]。
對于一個已經開發完成并運行多年的遺留系統而言,系統所有的Web頁面、后臺業務邏輯和數據庫表結構設計都已完成,直接使用工作流相關工具進行設計和配置無法建立表單和流程實例之間的關聯。因此,本文設計了遺留系統集成工作流引擎的嵌入式結構,解決了上述問題。
本文在現有遺留系統的架構、設計和實現基礎上,設計中間表作為遺留系統和工作流引擎的適配器和橋接器,建立表單和流程實例之間對應關系。具體思路如下:針對應用系統中表單的構成(例如:在基本信息審核中是以油氣田為單位,每個油氣田下又有所屬油氣田的具體信息表,即存在兩個基本單元:油氣田代碼和具體信息表代碼,分別用于標識油氣田和所屬油氣田的具體信息表),建立并記錄工作流引擎中TaskID(流程實例對象)與油氣田代碼和具體信息表代碼的關聯。同時,如果節點和表單直接關聯,工作流引擎中有一個ProcID(流程處理過程對象),每一步流轉通過它來標識,如果一個節點一步一次處理一個表單信息到下一個節點,由于沒有分支,則不需要知道此表單具體對應哪個ProcID;如果一個節點一步一次處理不止一個表單,待處理任務中會有不止一個ProcID,而每一個ProcID對應一個表單,則需要記錄ProcID分別對應哪個表單,以區分處理。
本文據此設計了一個類似(TaskID、ProcID、油氣田代碼、具體信息表代碼)的關系將流程實例和具體的待處理信息關聯起來,并提出了如下通用解決方案:依據具體的業務流程處理要求,在工作流的后臺數據庫或應用系統的數據庫中添加一張中間表來記錄TaskID、ProcID和具體業務的關聯關系,如圖1、圖2所示。改變已有的處理機制,使用一張中間表作為橋接,在遺留系統的業務表單同后臺工作流引擎的內部處理機制(流程流轉、處理記錄等)之間建立橋梁,形成遺留系統集成工作流引擎的嵌入式結構,并關聯業務處理與流程實例,將遺留系統應用工作流的難度從技術層面轉移到業務層面,從而使應用工作流技術進行遺留系統重構變得可行和簡單。
本文以Liveflow工作流引擎為例,在啟動一個流程時同時寫中間表,借助工作流引擎內在提交方法Post(objBPCn, "提交", out o, 0, "", SetFields(fieldsName, fieldsValue), null, null)寫入這種關系,其中SetFields(fieldsName, fieldsValue) 是表單數據集合參數。通過此方法把ProcID、油氣田代碼、具體信息表代碼在啟動時寫入中間表。進行流程節點處理時,對同一油氣田代碼和具體信息表代碼更新ProcID,使中間表永遠存儲最新處理完的ProcID。
通過該方式為遺留系統使用工作流的二次開發接口重寫“提交”和“處理”建立了基礎,也為單節點中多表單信息的批量處理提供了解決方案。要在工作流引擎中的單節點中處理多表單信息,只需在中間表中建立一對多關系,然后使用工作流的二次開發接口,重寫“提交”和“處理”事件。當用戶在審核處理界面操作時,相應的“提交”和“審核”事件將通過工作流引擎的內部處理機制與工作流引擎進行一系列交互,以保證每一次處理都知道處理內容以及下一個節點的接收內容,并由工作流引擎自動維護節點狀態信息,以保證業務流程的處理過程在使用工作流設計器建模后形成的流程中作為一個個流程實例進行體現。
2.2 數據同步及工作流引擎節點配置無縫集成
本文直接從工作流引擎后臺數據庫中讀取流程實例的各節點“狀態”信息,通過LiveFlow建立在BPFC(Business Process Foundation Class)上的基于COM的二次開發接口BPO (Business Process Object)映射和同步工作流產品與遺留系統的用戶信息數據庫表,完成遺留系統與工作流引擎管理器用戶數據和權限數據的同步。在遺留系統的系統管理模塊集成流程節點的審核用戶配置,將工作流引擎流程節點的配置與遺留系統進行無縫集成。工作流引擎維護的流程節點的配置,已經集成在遺留系統的系統管理模塊中來完成。
3 結語
本文完成了遺留系統集成工作流引擎的嵌入式結構設計,同時以LiveFlow工作流引擎為例完成了遺留系統與工作流引擎管理器用戶和權限數據的同步及流程節點配置的無縫集成,實現了遺留系統數據審核流程用戶級靈活自定制,有效提高了系統的可用性與靈活性,對使用工作流技術重構遺留系統流程具有實際意義和一定的借鑒價值。
參考文獻:
[1]張一川,汪德帥,劉瑩,等.基于業務服務的企業遺留系統集成框架[J].計算機應用, 2008,28(B06):263-265.
[2]蔡孝武,韓永國,藍科.一種輕量級工作流引擎的研究與設計[J].計算機工程, 2010,36(20):78-79.
[3]羅海濱,范玉順,吳澄.工作流技術綜述[J].軟件學報,2000,11(7):899-907.
[4]王凱,張毅坤,楊凱峰,等.面向OA系統的工作流引擎研發[J].計算機工程與設計,2008,29(19):4967-4971.
(責任編輯:黃 健)