基于關(guān)系數(shù)據(jù)庫的工作流在管理信息系統(tǒng)的應(yīng)用

2013-12-12 09:21:06 電力信息化　點擊量：評論 (0)

摘要：通過對關(guān)鍵業(yè)務(wù)的實際開發(fā)需求的分析，提出了一個適用于關(guān)鍵業(yè)務(wù)開發(fā)的基于關(guān)系結(jié)構(gòu)的工作流引擎的框架結(jié)構(gòu)。系統(tǒng)提供對企業(yè)整體協(xié)作流程的控制、分析、對部門運作狀態(tài)的實時記錄等功能；并可以高效地完成

的任務(wù)，COMPLETION_FLAG表示相應(yīng)任務(wù)的結(jié)束標記。

3．3．2引擎控制器

引擎控制器是工作流引擎在運行時的控制中心，圖3給出了引擎控制器的控制結(jié)構(gòu)圖。

 調(diào)度中心

調(diào)度中心接受從外部接口發(fā)送過來有關(guān)流程控制的請求（如業(yè)務(wù)初始化、獲取任務(wù)以及結(jié)束任務(wù)等），然后根據(jù)不同的請求類型調(diào)用相應(yīng)的處理模塊完成與本次請求相關(guān)的操作并將結(jié)果返回。由于是在DBMS內(nèi)部實現(xiàn)工作流引擎的控制模型，因此有關(guān)請求的并發(fā)處理等問題完全可以交給數(shù)據(jù)庫管理系統(tǒng)來完成，也不需要諸如請求隊列等形式的數(shù)據(jù)結(jié)構(gòu)。因此，事實上可以將調(diào)度中心看成一個多線程的并發(fā)服務(wù)器，它可以對多個外部請求提供并發(fā)服務(wù)。對外部請求的處理過程中肯定會涉及到對內(nèi)部數(shù)據(jù)結(jié)構(gòu)（即工作流引擎的數(shù)據(jù)模型）中有關(guān)數(shù)據(jù)的讀寫和更改操作，這些數(shù)據(jù)的完整性和互斥操作則可以通過DBMS提供的各種加鎖機制來實現(xiàn)，從而實現(xiàn)了多個外部請求之間的獨立性。

 任務(wù)管理

任務(wù)管理主要根據(jù)調(diào)度中心的指示完成諸如任務(wù)創(chuàng)建、任務(wù)狀態(tài)的轉(zhuǎn)換以及相關(guān)數(shù)據(jù)的維護等工作。每次“結(jié)束任務(wù)”的外部請求將觸發(fā)調(diào)度中心調(diào)用“任務(wù)管理”為后繼活動（如果存在的話）創(chuàng)建新的實例，其狀態(tài)為“Pending”；同時，其他不同的外部請求也將觸發(fā)“任務(wù)管理”實施任務(wù)狀態(tài)的切換。

 任務(wù)指派

任務(wù)指派處理只是針對常規(guī)交互活動，通常情況下，在任務(wù)狀態(tài)由“Pending”切換到“Waiting”過程中完成任務(wù)的指派工作，即處于就緒狀態(tài)的任務(wù)在通常情況下都確定了其執(zhí)行者（FCFA除外）。任務(wù)指派過程首先根據(jù)任務(wù)指派基準確定可以執(zhí)行此任務(wù)的群體人員，通常情況下這是一個包含多個人員的集合；然后根據(jù)任務(wù)指派方法確定由這個群體中的哪些個體來執(zhí)行任務(wù)，執(zhí)行任務(wù)的個體標識記錄在相應(yīng)任務(wù)記錄的STAFF_ID字段中。這里有兩點需要特別強調(diào)：

1）如果任務(wù)指派方法是“ALL”的話，將對當前的任務(wù)記錄進行拷貝，即保證每一執(zhí)行任務(wù)的個體在TO_DO_TASK_LIST中都有一條對應(yīng)的記錄；

2）如果任務(wù)指派方法是“FCFA”的話，事實上在任務(wù)指派階段不不作任何工作，即相應(yīng)任務(wù)記錄的STAFF_ID字段為空。此時任務(wù)指派工作自動隱含在獲取任務(wù)的請求中，即誰先發(fā)出獲取任務(wù)的請求，就自動將此類型的任務(wù)分配給誰。

 依賴檢查

依賴檢查指的是活動的前依賴規(guī)則的檢查，調(diào)度中心在將任務(wù)切換到就緒狀態(tài)之前將進行相關(guān)的前依賴規(guī)則檢查，只有滿足檢查條件的任務(wù)才可以進行狀態(tài)的切換。

上一頁 1 2 3 4 5 6 7 下一頁