第一篇：如何基于工作流,實(shí)現(xiàn)OA-ERP集成

如何基于工作流，實(shí)現(xiàn)OA-ERP集成

2002-10-30 13:15

郭應(yīng)中、吳科/(AMT)

引言

ERP系統(tǒng)是對(duì)企業(yè)能夠提供業(yè)務(wù)數(shù)據(jù)支持的信息系統(tǒng)，OA系統(tǒng)是實(shí)現(xiàn)公文收發(fā)、流轉(zhuǎn)、簽發(fā)、歸檔等群組化辦公作業(yè)自動(dòng)化的信息系統(tǒng)。兩者都是為實(shí)現(xiàn)單一目標(biāo)而運(yùn)行的信息系統(tǒng)。

在企業(yè)的業(yè)務(wù)活動(dòng)中，經(jīng)常有些業(yè)務(wù)是貫穿ERP和OA兩個(gè)系統(tǒng)的。比如采購流程：采購申請(qǐng)生成、采購定單生成、驗(yàn)收單生成是在ERP系統(tǒng)進(jìn)行；采購單申批、入庫準(zhǔn)備單流轉(zhuǎn)在OA系統(tǒng)進(jìn)行。企業(yè)中存在對(duì)OA和ERP兩個(gè)系統(tǒng)集成的需求。另外，ERP系統(tǒng)和OA系統(tǒng)實(shí)施的難度差別造成一個(gè)時(shí)期內(nèi)系統(tǒng)覆蓋范圍不同，將兩個(gè)系統(tǒng)集成，ERP的實(shí)施效果可以事半功倍。

將兩個(gè)系統(tǒng)集成，涉及到組織、角色、任務(wù)和過程的定義和管理。通過工作流系統(tǒng)進(jìn)行集成，不但可以把兩個(gè)系統(tǒng)中的多個(gè)模型統(tǒng)一，還可以使企業(yè)專注于應(yīng)用業(yè)務(wù)，更方便地進(jìn)行企業(yè)流程重組（BPR）。

對(duì)ERP和OA兩個(gè)系統(tǒng)的集成，主要的工作有集成方案的確定、系統(tǒng)集成功能范圍的確定、工作流系統(tǒng)的創(chuàng)建或改造、組織模型的統(tǒng)一等。

集成方案的確定

實(shí)現(xiàn)OA和ERP系統(tǒng)的集成，通常的實(shí)現(xiàn)方案有以下三種：

1、更換原有的ERP系統(tǒng)，選擇能夠同時(shí)提供OA和ERP解決方案的供應(yīng)商。

同時(shí)提供OA和ERP解決方案的供應(yīng)商，其產(chǎn)品在設(shè)計(jì)階段就考慮到了兩個(gè)系統(tǒng)的集成。但是目前這樣的方案往往是供應(yīng)商出于市場(chǎng)份額的考慮而提供的，由于開發(fā)規(guī)模、成本和周期的限制，所提供的ERP－OA一體化方案的功能往往比較簡(jiǎn)單，不能滿足企業(yè)個(gè)性化的需求。而且，ERP系統(tǒng)在企業(yè)內(nèi)運(yùn)行一段時(shí)間后，更換新的系統(tǒng)，會(huì)面臨新舊系統(tǒng)間數(shù)據(jù)移植的巨大工作量、用戶不愿意舍棄熟悉的界面和高昂的費(fèi)用等困難。所以這個(gè)方案只能被未實(shí)施ERP系統(tǒng)企業(yè)中的少部分企業(yè)使用；

2、使用ERP供應(yīng)商的合作伙伴提供的集成方案。

例如Lotus Notes為SAP、Oracle、JDE等公司的ERP產(chǎn)品都提供了集成化的解決方案。其方法是：在OA Server和ERP Server之間通過數(shù)據(jù)庫連接工具DECS連接。在ERP 系統(tǒng)的DB 建立大量視圖供OA訪問，在OA Server上建立關(guān)系型數(shù)據(jù)庫，存儲(chǔ)定期從ERP系統(tǒng)中按照字段映射過來的靜態(tài)數(shù)據(jù)，作為OA系統(tǒng)組織和資源定義的依據(jù)。OA系統(tǒng)中的表單鑒審后可以通過ERP系統(tǒng)的Interface table寫入ERP系統(tǒng)。

這種方案可以兩個(gè)系統(tǒng)的高度集成，但是存在以下問題：

（1）不是所有的ERP系統(tǒng)都有相應(yīng)的集成方案提供。Lotus Notes僅對(duì)大型而且著名的ERP產(chǎn)品提供了這樣的集成方案；

（2）這個(gè)方案的實(shí)現(xiàn)和維護(hù)費(fèi)用非常高。如果在新增流程，需要在ERP系統(tǒng)中新增視圖，在OA系統(tǒng)中新增表單。對(duì)于大型的ERP系統(tǒng)，其數(shù)據(jù)庫中的table有近萬個(gè)，加上在OA中創(chuàng)建表單，都是企業(yè)IT人員無法獨(dú)立完成的，仍需要方案提供者的服務(wù)。即使是方案的提供者，在使用這種工具完成兩個(gè)應(yīng)用系統(tǒng)結(jié)合 時(shí)，也必須同時(shí)對(duì)兩個(gè)系統(tǒng)了如指掌。然而，不論在國內(nèi)和國外，同時(shí)能夠深層次了解兩個(gè)系統(tǒng)的技術(shù)人員極為緊缺，加上高昂的購買費(fèi)用，企業(yè)很難接受；

（3）ERP實(shí)施模塊增加，特別是ERP系統(tǒng)的升級(jí)，都會(huì)造成集成化系統(tǒng)的癱瘓，限制了企業(yè)的業(yè)務(wù)發(fā)展。

因此，此方案的應(yīng)用仍然比較少。

3、通過工作流系統(tǒng)，實(shí)現(xiàn)工作流程在兩個(gè)平臺(tái)上切換。

在工作流系統(tǒng)的管理下，用戶通過遠(yuǎn)程登錄工具和模擬鍵盤錄入，實(shí)現(xiàn)OA平臺(tái)和ERP平臺(tái)之間的簡(jiǎn)單切換。系統(tǒng)架構(gòu)圖如下：

圖1集成后的系統(tǒng)架構(gòu)

對(duì)應(yīng)上圖的每個(gè)步驟說明如下：

1.用戶登錄OA系統(tǒng)后，Workflow Server根據(jù)OA系統(tǒng)中人員配置管理功能確認(rèn)其身份，此用戶同時(shí)得到了相應(yīng)的權(quán)限；

2.身份確認(rèn)后，Workflow Server再根據(jù)此用戶在其權(quán)限內(nèi)申請(qǐng)的工作流程提供工作流表單，并在表單上顯示用戶對(duì)應(yīng)的組織結(jié)構(gòu)的層次度；

3.用戶在工作流表單上填寫本流程執(zhí)行需要的數(shù)據(jù)，這些數(shù)據(jù)可能是請(qǐng)假天數(shù)、請(qǐng)假原因等不涉及ERP系統(tǒng)的數(shù)據(jù)，也可能是訪問ERP系統(tǒng)的參數(shù)。如果在流程執(zhí)行時(shí)僅僅需要在ERP系統(tǒng)中執(zhí)行查詢，工作流表單的填寫要在訪問ERP系統(tǒng)后進(jìn)行。

4.當(dāng)工作流程執(zhí)行到ERP系統(tǒng)上的作業(yè)時(shí)，工作流系統(tǒng)自動(dòng)引導(dǎo)用戶進(jìn)入ERP系統(tǒng)。通過OA系統(tǒng)本身的Script語言結(jié)合Terminal simulator script語言編寫的訪問ERP系統(tǒng)的任務(wù)項(xiàng)，根據(jù)執(zhí)行的流程類型、順序、工作流表單參數(shù)，用戶可以直接進(jìn)入ERP系統(tǒng)相應(yīng)的功能模塊。

5.用戶操作ERP系統(tǒng)?？梢愿鶕?jù)權(quán)限執(zhí)行不同的操作。以采購申請(qǐng)為例，用戶可以填寫需要采購的物料編號(hào)、采購數(shù)量、價(jià)格范圍、供應(yīng)商等，存儲(chǔ)后保存在ERP DB中；

6.ERP DB保存后，通過ERP系統(tǒng)界面向用戶提示保存成功；

7.ERP系統(tǒng)將保存成功的單據(jù)編號(hào)和單據(jù)狀態(tài)等信息傳送到工作流系統(tǒng)。根據(jù)需要，用戶可以把ERP系統(tǒng)生成的表單導(dǎo)出為Excel文件保存在本地；

8.當(dāng)工作流系統(tǒng)收到ERP系統(tǒng)傳來的信息后，進(jìn)行格式檢查，確認(rèn)無誤后繼續(xù)執(zhí)行；

9.用戶在屏幕上審查工作流系統(tǒng)執(zhí)行情況是否正確，確認(rèn)無誤后，將工作流表單傳送到Workflow Server，保存在本地的Excel文件也可以作為附件提交；

10.Workflow Server收到用戶傳來的工作流表單，并據(jù)此將工作流表單和附件傳送到下一個(gè)執(zhí)行者。

同前面兩種方案比較，這種方案的適應(yīng)性非常強(qiáng)，開發(fā)量、開放難度和費(fèi)用都比較低。因此為本文采用。

系統(tǒng)集成功能范圍的確定

如果把企業(yè)內(nèi)所有的流程都通過工作流系統(tǒng)在OA和ERP系統(tǒng)中實(shí)現(xiàn)，不僅沒有必要，而且有些流程是不適合在信息系統(tǒng)中實(shí)現(xiàn)的。因此，需要對(duì)系統(tǒng)集成的功能范圍進(jìn)行確定。

企業(yè)內(nèi)部流程是由一個(gè)個(gè)動(dòng)作組成的，根據(jù)動(dòng)作發(fā)生的頻率和流程特點(diǎn)，可以分為以下三個(gè)類別：

A類：發(fā)生頻率高而且執(zhí)行簡(jiǎn)單。如各種申請(qǐng)的上呈、核簽、否決、查詢；

B類：發(fā)生頻率一般，執(zhí)行方法復(fù)雜而且經(jīng)常發(fā)生變化。如會(huì)簽，往往人數(shù)不定，層次不定，后續(xù)動(dòng)作不定；

C；類：發(fā)生頻率特別低，或者其所在流程不具備管理意義。如衛(wèi)生值日流程中的所有動(dòng)作；

為使集成工作簡(jiǎn)單而有效，系統(tǒng)集成的功能應(yīng)集中在由A類動(dòng)作組成流程的范圍內(nèi)。在集成工作前階段，工作流系統(tǒng)中計(jì)劃實(shí)現(xiàn)的流程中，需要OA和ERP兩個(gè)系統(tǒng)共同完成的流程有：

1．物料信息維護(hù)。當(dāng)物料新增或停用時(shí)，經(jīng)過層層簽字，在ERP系統(tǒng)中做相應(yīng)處理；

2．采購流程。采購申請(qǐng)、審核、采購申請(qǐng)匯總、分單驗(yàn)收、入庫流程；

3．付款流程。付款申請(qǐng)、發(fā)票校驗(yàn)、審核、通知付款、付款登記；

4．報(bào)銷流程。單據(jù)填寫、網(wǎng)上審核、票據(jù)檢查、登記入帳；

工作流系統(tǒng)的改造或重構(gòu)

按照工作流管理聯(lián)盟的定義，工作流是一類能夠完全或部分自動(dòng)執(zhí)行的經(jīng)營過程，將文檔、信息和任務(wù)在不同的執(zhí)行者之間傳遞、執(zhí)行。

傳統(tǒng)的工作流系統(tǒng)中，每一個(gè)業(yè)務(wù)流程都要根據(jù)企業(yè)內(nèi)的業(yè)務(wù)流程完整構(gòu)建出來的。這樣每一個(gè)業(yè)務(wù)流程都有大量的代碼來實(shí)現(xiàn)，流程的創(chuàng)建和維護(hù)工作量很大。

仔細(xì)分析企業(yè)內(nèi)的眾多業(yè)務(wù)流程中，相當(dāng)部分的流程是有共同部分的，每個(gè)流程中都有功能重復(fù)的代碼。動(dòng)態(tài)工作流把完整的工作流分解為若干個(gè)活動(dòng)（Task）（對(duì)象），使工作流建模工作得以簡(jiǎn)化，可以實(shí)現(xiàn)更復(fù)雜的工作流系統(tǒng)。

活動(dòng)是動(dòng)態(tài)工作流的一個(gè)重要概念：工作流是一組有關(guān)聯(lián)關(guān)系的活動(dòng)的集合。一個(gè)活動(dòng)與其它活動(dòng)之間有順序，分支，循環(huán)，調(diào)用的關(guān)系，還有并行、有同步的關(guān)系。

按照動(dòng)態(tài)工作流的概念，一個(gè)完整的工作流程被分解為若干個(gè)活動(dòng)（Task）和活動(dòng)間的邏輯控制器。每個(gè)活動(dòng)不和其它活動(dòng)作任何直接交互，交互完全在邏輯控制器間進(jìn)行。如圖2所示：

圖2動(dòng)態(tài)工作流系統(tǒng)結(jié)構(gòu)

每個(gè)活動(dòng)都有進(jìn)入條件，工作條件，中斷條件，完成條件，暫停條件及繼續(xù)條件。執(zhí)行時(shí)，判斷每個(gè)工作項(xiàng)是否可以進(jìn)入，可以則進(jìn)行進(jìn)入處理，然后，判斷需要是否中斷或暫停?；顒?dòng)的結(jié)構(gòu)圖如圖3：

圖3活動(dòng)的內(nèi)部結(jié)構(gòu)

圖3中，一個(gè)活動(dòng)有不同的狀態(tài)集、輸入集、輸出集。狀態(tài)集包括等待、執(zhí)行和完成。輸入集和輸出集分別由若干個(gè)輸入和輸出組成。輸入來源可以是本活動(dòng)的輸出，也可以是其它活動(dòng)的輸入或輸出或狀態(tài)。當(dāng)輸入集中某項(xiàng)輸入狀態(tài)發(fā)生改變時(shí)，將觸發(fā)工作項(xiàng)的狀態(tài)發(fā)生改變。達(dá)到完成狀態(tài)時(shí)，將產(chǎn)生輸出集。輸入不同，觸發(fā)的執(zhí)行過程和產(chǎn)生的輸出集不同。當(dāng)多個(gè)輸入集同時(shí)被激活時(shí)，按優(yōu)先級(jí)執(zhí)行。

工作流系統(tǒng)的動(dòng)作和邏輯控制器采用Java Bean和關(guān)系型數(shù)據(jù)庫實(shí)現(xiàn)，可以設(shè)計(jì)為可視的圖形元件，也可以設(shè)計(jì)為不可視的邏輯處理元件。這樣做的好處是把工作流系統(tǒng)的各個(gè)活動(dòng)做成代碼行數(shù)小、功能明確的黑盒子，實(shí)現(xiàn)動(dòng)態(tài)的工作流系統(tǒng)，并在多環(huán)境下運(yùn)行。

OA系統(tǒng)和ERP系統(tǒng)都可能自帶工作流功能。但ERP系統(tǒng)的工作流功能缺乏開放性和適應(yīng)性，并且ERP系統(tǒng)開發(fā)商不允許對(duì)其進(jìn)行修改，因此其工作流功能的存在在集成中實(shí)際上是一個(gè)障礙。完成系統(tǒng)集成后，ERP的部分功能會(huì)由系統(tǒng)管理員設(shè)定為只能通過遠(yuǎn)程登錄的方式訪問，這是要對(duì)ERP系統(tǒng)原有的工作流系統(tǒng)做重新的設(shè)置，以免系統(tǒng)運(yùn)行出錯(cuò)。

OA的工作流功能，如果不能實(shí)現(xiàn)動(dòng)態(tài)工作流機(jī)制，是無法滿足集成的需要的。這時(shí)要對(duì)其工作流功能進(jìn)行重構(gòu)。如果已經(jīng)實(shí)現(xiàn)了動(dòng)態(tài)工作流機(jī)制，也要增加一些訪問ERP系統(tǒng)的功能動(dòng)作。

如果選擇其它的工作流系統(tǒng)支持集成工作，雖然理論上可行，但是開發(fā)量未必減少，系統(tǒng)復(fù)雜度、維護(hù)量和費(fèi)用必然上升，所以本文建議采用對(duì)原有的OA系統(tǒng)的工作流功能進(jìn)行改造，實(shí)現(xiàn)企業(yè)的工作流系統(tǒng)。

組織模型的統(tǒng)一

OA系統(tǒng)和ERP系統(tǒng)都有各自的組織模型。OA的組織模型是服務(wù)于企業(yè)行政組織層面的，ERP的組織模型則是服務(wù)于企業(yè)業(yè)務(wù)層面的。在用工作流系統(tǒng)對(duì)兩個(gè)系統(tǒng)集成時(shí)，要對(duì)兩個(gè)系統(tǒng)的組織模型進(jìn)行統(tǒng)一。在本方案中，就是要對(duì)OA系統(tǒng)的組織模型重新定義。

ERP系統(tǒng)的組織模型比OA系統(tǒng)要復(fù)雜，不同的ERP系統(tǒng)有不同的組織模型。以O(shè)racle Application為例，其組織模型為：賬簿集－法律實(shí)體－操作單元－庫存組織，再往下是更細(xì)致的劃分，可以做到用戶－角色－所屬組織－權(quán)限的一一對(duì)應(yīng)，權(quán)限的設(shè)置可以明確到字段。

對(duì)OA系統(tǒng)的組織模型的重定義，主要是增加OA系統(tǒng)組織結(jié)構(gòu)的層次數(shù)量，建立新組織結(jié)構(gòu)數(shù)據(jù)庫，把ERP用戶和OA用戶都在新的組織結(jié)構(gòu)中反映出來。注意OA系統(tǒng)中的用戶名要和ERP系統(tǒng)中的用戶名統(tǒng)一，因?yàn)樵贓RP系統(tǒng)中用戶名和角色、權(quán)限是對(duì)應(yīng)的。但口令不能統(tǒng)一，登錄ERP系統(tǒng)時(shí)，系統(tǒng)仍然會(huì)提示用戶輸入ERP系統(tǒng)的口令。

連接方法

本文中，Workflow Server是使用Lotus Notes Server＋Linux Red Had ver7.1系統(tǒng)，而在ERP系統(tǒng)上本文所采用的是HP/Unix＋鼎新Tip-top ERP系統(tǒng)＋HP9000，Client端則采用一般的Windows環(huán)境＋Lotus Notes客戶端軟件。

兩個(gè)服務(wù)器通過TCP/IP協(xié)議連接。在Workflow Server上安裝InterSoft公司編制的共享軟件NetTerm 4.3.0簡(jiǎn)體中文版，可以在10個(gè)以上的操作系統(tǒng)上運(yùn)行，對(duì)遠(yuǎn)程主機(jī)環(huán)境具有良好的設(shè)置能力。

NetTerm的作用是相應(yīng)客戶端發(fā)出的登錄ERP Server的要求，所以連接型態(tài)選TCP/IP，端口填“23”，模擬型態(tài)和鍵盤定義都選VT100(上述設(shè)置適用于國內(nèi)多數(shù)主機(jī))，主機(jī)名稱和地址填入ERP Server對(duì)應(yīng)的地址和內(nèi)容。

例如當(dāng)用戶需要訪問ERP的采購申請(qǐng)功能時(shí)，工作流系統(tǒng)中訪問ERP系統(tǒng)采購申請(qǐng)功能的活動(dòng)中包含以下語句（用Terminal simulator script語言編寫）：

expect 10”login:”

#username “Enter UserID”

#output “^U^M”

expect 10”Password:”

#password”Enter Password”

#output”^P^M”

output”12345^M”//工作流系統(tǒng)提示用戶輸入口令后生成該行

expect 10”/”

output”exe apmt420^M”

output “a”

流程執(zhí)行完這段程序時(shí)，就自動(dòng)打開了ERP系統(tǒng)的相應(yīng)功能。在用戶填寫完采購申請(qǐng)單后，ERP系統(tǒng)數(shù)據(jù)庫中的保存操作觸發(fā)事件為：以XML的格式，把采購申請(qǐng)單編號(hào)、創(chuàng)建實(shí)際、創(chuàng)建人等信息傳送到用戶本地，并被用戶本地服務(wù)響應(yīng)，填寫到工作流表單。用戶可以執(zhí)行修改功能再次訪問ERP系統(tǒng)修改采購申請(qǐng)單。在用戶確認(rèn)無誤后提交，下一個(gè)申批人接到提示申批的電子郵件，點(diǎn)擊郵件中的連接，出現(xiàn)反映采購流程執(zhí)行情況的流程表單。依次類推。

應(yīng)用情況

在實(shí)際應(yīng)用上，根據(jù)用戶需求定義了采購流程、付款流程、報(bào)銷流程等，并在ERP系統(tǒng)中開放部分?jǐn)?shù)據(jù)訪問和維護(hù)權(quán)限給Internet上自己的外地分子公司和上游客戶，解決了ERP剛實(shí)施完本部，外地分子公司采購流程無法并入集團(tuán)供應(yīng)部采購流程的問題，使用戶提前實(shí)現(xiàn)了集中采購的戰(zhàn)略構(gòu)想。目前，該用戶的上游近600家企業(yè)中，已經(jīng)有60家提供大宗原材料的供應(yīng)商使用這些流程，集中采購和比價(jià)采購使該企業(yè)在每年10多億的采購額中節(jié)約了大約1.5％的采購成本，給企業(yè)帶來了良好的經(jīng)濟(jì)效益。

第二篇：開源工作流框架及平臺(tái)集成分析報(bào)告（范文）

開源工作流框架及平臺(tái)集成分析報(bào)告

目 錄

Java主要開源工作流列表.......................................................................................................1 1.1.jBpm..............................................................................................................................1 1.2.OSWorkflow.................................................................................................................1 1.3.Enhydra Shark...............................................................................................................1 1.4.Activiti5........................................................................................................................1 1.5.OpenWFE.....................................................................................................................1 1.6.Werkflow.......................................................................................................................1 1.7.OFBiz............................................................................................................................2 1.8.Flow4J...........................................................................................................................2 1.9.ObjectWeb Bonita.........................................................................................................2 1.10.OBPM...........................................................................................................................2 四大開源工作流框架分析.......................................................................................................2 2.1.JBpm.............................................................................................................................2

優(yōu)點(diǎn)...................................................................................................................................2 缺點(diǎn)...................................................................................................................................3 2.2.OSWorkflow.................................................................................................................3

優(yōu)點(diǎn)...................................................................................................................................3 缺點(diǎn)...................................................................................................................................3 2.3.Enhydra Shark...............................................................................................................3

優(yōu)點(diǎn)...................................................................................................................................3 缺點(diǎn)...................................................................................................................................3 2.4.Activiti5........................................................................................................................4

優(yōu)點(diǎn)...................................................................................................................................4 缺點(diǎn)...................................................................................................................................4 與統(tǒng)一開發(fā)平臺(tái)集成...............................................................................................................4 3.1.流程定義插件集成.......................................................................................................4 3.2.核心包及jar包集成...................................................................................................4 3.3.部署方式.......................................................................................................................4 3.4.版本選擇與維護(hù)問題...................................................................................................5 1.2.3.1.Java主要開源工作流列表

1.1.jBpm jBpm是一個(gè)靈活可擴(kuò)展的工作流管理系統(tǒng)。作為 jBpm運(yùn)行時(shí)server輸入的業(yè)務(wù)流程使用簡(jiǎn)單強(qiáng)大的語言表達(dá)并打包在流程檔案中。jBpm將工作流應(yīng)用開發(fā)的便利性和杰出的企業(yè)應(yīng)用集成（EAI）能力結(jié)合了起來。

1.2.OSWorkflow OSWorkflow是一個(gè)靈活的工作流引擎，設(shè)計(jì)成可嵌入到企業(yè)應(yīng)用程序中。它提供了許多的持久化API支持包括：EJB,Hibernate,JDBC和其它。

1.3.Enhydra Shark Shark完全基于WfMC和OMG標(biāo)準(zhǔn)，使用 XPDL作為工作流定義語言。流程和活動(dòng)的存儲(chǔ)使用Enhydra DODS(一個(gè)開源OR映射工具)。

1.4.Activiti5 Activit5繼承了jBpm4的所有優(yōu)點(diǎn)，支持最新BPMN2.0規(guī)范，實(shí)現(xiàn)了流程的可視化以及創(chuàng)新的Activiti Cycle協(xié)作組件，此外，通過與Mule的集成加強(qiáng)了其集成能力。

1.5.OpenWFE OpenWFE是一個(gè)開放源碼的Java工作流引擎。它是一個(gè)完整的業(yè)務(wù)處理管理套件：一個(gè)引擎，一個(gè)工作列表，一個(gè)Web界面和一個(gè)反應(yīng)器（存放自動(dòng)代理）。可以與應(yīng)用程序很好的給合。

1.6.Werkflow Werkflow是一個(gè)靈活可擴(kuò)展的基于流程和狀態(tài)的工作流引擎。它的目標(biāo)是滿足可以想象的所有工作流程，從企業(yè)級(jí)的業(yè)務(wù)流程到小范圍的用戶交互流程。通過使用可插拔和分層結(jié)構(gòu)，可以方便地容納各種工作流語義.第1頁 1.7.OFBiz OFBiz是一個(gè)非常著名的開源項(xiàng)目，提供了創(chuàng)建基于最新J2EE/XML規(guī)范和技術(shù)標(biāo)準(zhǔn)，構(gòu)建大中型企業(yè)級(jí)、跨平臺(tái)、跨數(shù)據(jù)庫、跨應(yīng)用服務(wù)器的多層、分布式電子商務(wù)類WEB應(yīng)用系統(tǒng)的框架。OFBiz最主要的特點(diǎn)是OFBiz提供了一整套的開發(fā)基于Java的web應(yīng)用程序的組件和工具。包括實(shí)體引擎, 服務(wù)引擎, 消息引擎, 工作流引擎, 規(guī)則引擎等。

1.8.Flow4J Flow4J是一個(gè)可在Eclipse平臺(tái)下以拖放的方式進(jìn)行工作流建模的插件.。

1.9.ObjectWeb Bonita Bonita 是一個(gè)符合WfMC規(guī)范、靈活的協(xié)同工作流系統(tǒng)。對(duì)于各種動(dòng)作如流程概念建模、定義、實(shí)例化、流程控制和用戶交互等提供了全面的集成圖形工具。100% 基于瀏覽器、使用SOAP和XML數(shù)據(jù)綁定技術(shù)的Web Services封裝了已有的工作流業(yè)務(wù)方法并將它們以基于J2EE的Web Service形式發(fā)布。

1.10.OBPM OBPM是一個(gè)開源，輕量級(jí)的BPM系統(tǒng)。它的目標(biāo)是讓非IT人員也可以輕松構(gòu)建IT業(yè)務(wù)處理流程。OBPM內(nèi)建工作流引擎（Workflow Engine）, Form構(gòu)建器，Report設(shè)計(jì)器。OBPM支持瀏覽器（IE/Firefox）做為客戶端，同時(shí)還提供了強(qiáng)大的圖形客戶端。

2.四大開源工作流框架分析

2.1.JBpm 優(yōu)點(diǎn)

1、JBpm是最適合擴(kuò)展的代表，是在所有開源引擎中最適宜被商業(yè)化應(yīng)用的一款；

2、JBpm使用了開源框架Hibernate3, 支持當(dāng)前大多數(shù)流行的數(shù)據(jù)庫, 針對(duì)不同數(shù)據(jù)庫有一個(gè)對(duì)應(yīng)的初始化腳本文件.3、JBpm將數(shù)據(jù)的管理職能分離出去，自己專注于商務(wù)邏輯的處理

4、使用Jpdl流程定義語言，直觀易懂，可以手工修改，并且有一個(gè)Eclipse流程定義插件。

5、文檔豐富，用戶群最大，開源組織十分活躍，被jboss收購后發(fā)展趨勢(shì)良好；

第2頁 缺點(diǎn)

1、Eclipse流程定義插件不開源；

2、Hibernate3做持久化層，會(huì)產(chǎn)生冗余表和數(shù)據(jù)；

3、JBpm3、JBpm4、JBpm5版本互不兼容，發(fā)展趨勢(shì)不明確；

2.2.OSWorkflow 優(yōu)點(diǎn)

1、OSWorkflow是最輕量型的代表，也是一款非常靈活和低級(jí)別定位的工作流引擎的實(shí)現(xiàn)框架，可視化圖標(biāo)的流程在osworkflow 里都可以用代碼實(shí)現(xiàn)；

2、OSWorkflow 有著非常優(yōu)秀的靈活性，它能為應(yīng)用程序開發(fā)者提供集成，也能與現(xiàn)有的代碼和數(shù)據(jù)庫進(jìn)行集成；

3、OSWorkflow基于Action驅(qū)動(dòng)，符合框架開發(fā)人員的操作方式及編程習(xí)慣；

缺點(diǎn)

1、實(shí)現(xiàn)一個(gè)工作流系統(tǒng)非常繁瑣，每一個(gè)流程步驟實(shí)現(xiàn)均需要代碼改變狀態(tài)字段；入門難度較高；

2、組件功能匱乏，復(fù)雜流程項(xiàng)目需要基于其引擎做大量的二次開發(fā)，不適用；

3、配置項(xiàng)和開發(fā)代碼量相對(duì)較多，后期維護(hù)成本較高；

2.3.Enhydra Shark 優(yōu)點(diǎn)

1、工作流體系最為完備和復(fù)雜，秉承“模塊化”的思想，比較容易擴(kuò)展；

2、代碼量較少，易于閱讀、易于改寫、易于維護(hù)；

3、有一個(gè)Jawe來圖形化定義流程，圖形化功能相對(duì)較強(qiáng)，可以編輯活動(dòng)變量，流程邏輯控制屬性.缺點(diǎn)

1、相比其他完全開源的框架，Shark2.0后，很多組件、文檔商業(yè)化，需要付費(fèi)；

2、版本更新慢，代碼也不再按照開源方式來完成，商業(yè)化的定位限制了其發(fā)展。

第3頁 2.4.Activiti5 優(yōu)點(diǎn)

1、Activiti最大的優(yōu)勢(shì)是采用了PVM（流程虛擬機(jī)），支持BPMN2.0規(guī)范及其之外的流程格式；

2、與外部服務(wù)有良好的集成能力擴(kuò)展，通過與Mule的集成加強(qiáng)了其集成能力；

3、繼承了jBpm4的所有優(yōu)點(diǎn)，實(shí)現(xiàn)了流程的可視化以及創(chuàng)新的Activiti Cycle協(xié)作組件；

4、對(duì)流程引擎運(yùn)行期實(shí)例提供管理及監(jiān)控的Web控制臺(tái)。

缺點(diǎn)

1、數(shù)據(jù)持久層采用MyBatis3，沒有遵循JPA規(guī)范；網(wǎng)絡(luò)上反應(yīng)“回退功能”實(shí)現(xiàn)起來比較困難；

2、核心是 BPMN 2.0 的流程引擎，BPMN2規(guī)范發(fā)展的比較慢，語言本身也過于復(fù)雜可讀性差。

3.與統(tǒng)一開發(fā)平臺(tái)集成

3.1.流程定義插件集成

1.JBpm與Activiti都有基于eclipse圖形化插件和基于Web的流程設(shè)計(jì)器，2.OSWorkflow推薦手工編寫 xml 格式的工作流程描述符，有基于Eclipse GEF技術(shù)開發(fā)的osworkflow建模工具；

3.Shark有JAWE作為定義工具，是否可與平臺(tái)IDE集成還需要預(yù)研。

3.2.核心包及jar包集成

1.都屬于輕量級(jí)工作流框架：jBpm.jar 1.06M；activiti-engine-5.9 1.1MB；osworkflow-2.8.0.jar 393KB；

2.Shark核心包大小在6M左右，但是依賴jar包過于龐大，其他三個(gè)框架依賴jar包都不多，但是否與平臺(tái)jar包沖突還需驗(yàn)證；

3.3.部署方式

1.JBpm與Activiti都可以與應(yīng)用項(xiàng)目集成也可以單獨(dú)部署；

2.OSWorkflow不可單獨(dú)部署，一般推薦與spring集成，方便事務(wù)管理及功能擴(kuò)展；

第4頁 3.Shark可集成也可單獨(dú)部署：可以直接作為java庫來使用；也可以單獨(dú)部署，作為CORBA ORB 或 Web 服務(wù)來使用；

3.4.版本選擇與維護(hù)問題

1.JBpm4 積累文檔豐富.網(wǎng)上具有大量的共享技術(shù)資源，也是最穩(wěn)定的版本，但是目前已停止開發(fā)和更新；jBpm5基本上完全拋棄了jBpm4的代碼，所有代碼全部來自原先的Drools Flow，資料和文檔相對(duì)較少；

2.OSWorkflow是opensymphony下的一個(gè)開源項(xiàng)，2.8版本穩(wěn)定，文檔不是很詳細(xì)，有較多網(wǎng)絡(luò)資源，曾是ERP軟件開發(fā)中廣泛應(yīng)用的工作流框架，JBpm的出現(xiàn)帶走了很多用戶，使其發(fā)展乏力；

3.Enhydra Shark2.0后，很多組件、文檔商業(yè)化，需要付費(fèi)，而且版本更新慢，商業(yè)化的定位限制了其發(fā)展；

4.Activiti5是JBoss jBpm架構(gòu)師加入Alfresco后的作品，繼承了jBpm4的所有優(yōu)點(diǎn)，保持開發(fā)更新中，用戶不斷增加，較多用戶推薦，開源社區(qū)活躍，發(fā)展前景看好。

4.總結(jié)

總體來看，四款工作流引擎框架與平臺(tái)集成難度都不大，但所依賴第三方j(luò)ar是否與平臺(tái)沖突還需具體驗(yàn)證；從應(yīng)用項(xiàng)目開發(fā)角度來看，JBpm4、Activiti5友好度較高，難易程度適中容易上手，而OSWorkflow、Shark則顯得較為復(fù)雜；從文檔資料及后期項(xiàng)目維護(hù)角度來看，Activiti5無論從版本升級(jí)，網(wǎng)絡(luò)資料及社區(qū)活躍度來看都更勝一籌，其他三款框架都多少存在一些難度和問題。

第5頁

第三篇：基于WEB的工作流引擎設(shè)計(jì)和實(shí)現(xiàn)

基于WEB的工作流引擎設(shè)計(jì)和實(shí)現(xiàn)

一、引言

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

二、工作流技術(shù)概述

（一）相關(guān)概念

工作流（Workflow）就是工作流程的計(jì)算模型，即將工作流程中的工作如何前后組織在一起的邏輯和規(guī)則，在計(jì)算機(jī)中以恰當(dāng)?shù)哪Ｐ瓦M(jìn)行表示并對(duì)其實(shí)施計(jì)算。工作流引擎（Workflow Engine，WfE）的主要功能是通過計(jì)算機(jī)技術(shù)的支持去定義、執(zhí)行和管理工作流，協(xié)調(diào)工作流執(zhí)行過程中工作之間以及群體成員之間的信息交互。工作流需要依靠工作流引擎來調(diào)度、實(shí)現(xiàn)。

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

工作流引擎是定義、創(chuàng)建、執(zhí)行工作流的軟件組元。作為工作流的核心應(yīng)能提供以下幾個(gè)方面的功能支持：解釋過程定義；創(chuàng)建過程實(shí)例并控制其執(zhí)行；調(diào)度各項(xiàng)活動(dòng)；為用戶工作表添加工作項(xiàng)；通過應(yīng)用程序接口（API）調(diào)用應(yīng)用程序；提供監(jiān)督和管理功能等。

三、工作流引擎的分析及設(shè)計(jì)

（一）工作流引擎的功能結(jié)構(gòu)

工作流引擎需要支持兩種業(yè)務(wù)流程，即確定型工作流和非確定工作流。確定型工作流是指人們可以事先給出運(yùn)行路線的一類業(yè)務(wù)流程；非確定型工作流是指人們事先不能給出運(yùn)行路線的一類業(yè)務(wù)流程。業(yè)務(wù)流程的流向應(yīng)根據(jù)實(shí)際情況而定。工作流引擎的功能結(jié)構(gòu)圖應(yīng)該如圖一所示：

圖1 工作流引擎的功能結(jié)構(gòu)圖

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

引擎控制器是工作流引擎在運(yùn)行時(shí)的控制中心，引擎控制器的控制結(jié)構(gòu)圖如圖二所示：

圖二 引擎控制器的控制結(jié)構(gòu)圖

1．調(diào)度中心。調(diào)度中心接受從外部接口發(fā)送過來有關(guān)流程控制的請(qǐng)求，然后根據(jù)不同的請(qǐng)求類型調(diào)用相應(yīng)的處理模塊完成與本次請(qǐng)求相關(guān)的操作并將結(jié)果返回。由于是在DBMS內(nèi)部實(shí)現(xiàn)工作流引擎的控制模型，因此有關(guān)請(qǐng)求的并發(fā)處理等問題完全可以交給數(shù)據(jù)庫管理系統(tǒng)來完成，也不需要諸如請(qǐng)求隊(duì)列等形式的數(shù)據(jù)結(jié)構(gòu)。

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

3．任務(wù)指派。任務(wù)指派處理只是針對(duì)常規(guī)交互活動(dòng)，通常情況下，在任務(wù)狀態(tài)由“待定”切換到“等待”過程中完成任務(wù)的指派工作，即處于就緒狀態(tài)的任務(wù)在通常情況下都確定了其執(zhí)行者。任務(wù)指派過程首先根據(jù)任務(wù)指派基準(zhǔn)確定可以執(zhí)行此任務(wù)的群體人員，通常情況下這是一個(gè)包含多個(gè)人員的集合；然后根據(jù)任務(wù)指派方法確定由這個(gè)群體中的哪些個(gè)體來執(zhí)行任務(wù)，執(zhí)行任務(wù)的個(gè)體標(biāo)識(shí)記錄在相應(yīng)任務(wù)記錄的字段中。

4．依賴檢查。在工作流引擎中，業(yè)務(wù)規(guī)則可以分解成活動(dòng)的前依賴規(guī)則和活動(dòng)的后轉(zhuǎn)發(fā)規(guī)則。依賴檢查指的是活動(dòng)的前依賴規(guī)則的檢查，調(diào)度中心在將任務(wù)切換到就緒狀態(tài)之前將進(jìn)行相關(guān)的前依賴規(guī)則檢查，只有滿足檢查條件的任務(wù)才可以進(jìn)行狀態(tài)的切換。

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

第一，對(duì)于順序前依賴規(guī)則，從前趨活動(dòng)流轉(zhuǎn)到當(dāng)前活動(dòng)跟其他前趨活動(dòng)沒有關(guān)系，當(dāng)前活動(dòng)的啟動(dòng)沒有其他約束條件，相應(yīng)任務(wù)可以立即由“待定”狀態(tài)轉(zhuǎn)換到“等待”狀態(tài)。

第二，對(duì)于與匯聚前依賴規(guī)則，相應(yīng)記錄要指明所有參與與匯聚的其他前趨活動(dòng)，只有所有相關(guān)的前趨活動(dòng)均到達(dá)各自指定的結(jié)束狀態(tài)，當(dāng)前活動(dòng)方可啟動(dòng)。第三，對(duì)于或匯聚前依賴規(guī)則，前依賴活動(dòng)集為空集，此規(guī)則的檢查將涉及到業(yè)務(wù)活動(dòng)表中的或匯集標(biāo)志，其取值可以是所有相關(guān)的前趨活動(dòng)的結(jié)束標(biāo)記之一或者是一個(gè)特殊的標(biāo)記。如果或匯集標(biāo)志不是一個(gè)特殊標(biāo)記，則將檢查相應(yīng)前趨活動(dòng)的結(jié)束標(biāo)記是否和或匯集標(biāo)志相同，若相同，則啟動(dòng)當(dāng)前活動(dòng)，若不相同，則不作任何處理。如果或匯集標(biāo)志是一個(gè)特殊標(biāo)記，則首先結(jié)束的前趨活動(dòng)將啟動(dòng)當(dāng)前活動(dòng)，后結(jié)束的活動(dòng)將被丟棄。

第四，對(duì)于投票匯聚活動(dòng)，前依賴活動(dòng)集同樣為空集，當(dāng)前活動(dòng)要等到屬于同一批次任務(wù)數(shù)目達(dá)到設(shè)置的要求方可啟動(dòng)。

5．轉(zhuǎn)發(fā)控制。當(dāng)應(yīng)用發(fā)出“結(jié)束任務(wù)”的外部請(qǐng)求時(shí)，該請(qǐng)求將觸發(fā)調(diào)度中心啟動(dòng)“轉(zhuǎn)發(fā)控制”。轉(zhuǎn)發(fā)控制的主要依據(jù)在工作流數(shù)據(jù)模型中定義的后轉(zhuǎn)發(fā)規(guī)則，后轉(zhuǎn)發(fā)規(guī)則定義了當(dāng)前活動(dòng)與其后繼活動(dòng)之間的關(guān)系。

6．啟動(dòng)控制。啟動(dòng)控制負(fù)責(zé)常規(guī)自動(dòng)活動(dòng)的所對(duì)應(yīng)的自動(dòng)執(zhí)行體的啟動(dòng)并對(duì)其活動(dòng)進(jìn)行監(jiān)控。

三、工作流引擎實(shí)現(xiàn)

（一）任務(wù)表結(jié)構(gòu)

確定型任務(wù)表負(fù)責(zé)保存系統(tǒng)中所有確定型流程的任務(wù)實(shí)例待處理記錄及任務(wù)實(shí)例處理的歷史記錄，工作流引擎定期掃描該任務(wù)表，將任務(wù)表中所有待處理的任務(wù)實(shí)例分發(fā)給相應(yīng)流程中的相應(yīng)節(jié)點(diǎn)。

確定型任務(wù)表的結(jié)構(gòu)為：TaskList(TasklnstanceID，TasklD，TaskStep，TaskHandleTime，ProceeID，DstNodelD，lsHandled，CommmitMan)，分別為：TasklnstaneeID：同一個(gè)任務(wù)可以有多個(gè)不同的運(yùn)行實(shí)例。該字段用于區(qū)別多個(gè)不同的運(yùn)行實(shí)例；TasklD：用于區(qū)別不同的任務(wù)；TaskStep：記錄任務(wù)運(yùn)行實(shí)例在流程中的處理步驟；TaskHand]eTime：任務(wù)運(yùn)行實(shí)例在相應(yīng)處理步驟中的處理時(shí)間；Processed：記錄任務(wù)實(shí)例所在流程的ID；DstNodelD：處理任務(wù)運(yùn)行實(shí)例的后續(xù)節(jié)點(diǎn)；IsHandled：任務(wù)實(shí)例在后續(xù)節(jié)點(diǎn)是否已經(jīng)處理；CommitMan：任務(wù)的處理人。

（二）工作流的流向控制

工作流引擎的一個(gè)核心功能就是要決定確定型任務(wù)表中各個(gè)任務(wù)運(yùn)行實(shí)例的后續(xù)處理節(jié)點(diǎn)，使任務(wù)運(yùn)行實(shí)例按照事先定義好的路線流動(dòng)，也就是流程的流向控制。

流向控制算法描述如下：

／*控制流程流向*／

function HowControl(string processid，string nodeid)｛

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

for(int i=0;i

／*后續(xù)節(jié)點(diǎn)同步控制*／

if(查詢后續(xù)節(jié)點(diǎn)i所對(duì)應(yīng)的條件中有無isprecondition為true的條件)對(duì)后續(xù)節(jié)點(diǎn)進(jìn)行同步控制；

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

if(后續(xù)節(jié)點(diǎn)i是子流程)

將子流程的第一個(gè)節(jié)點(diǎn)作為后續(xù)節(jié)點(diǎn)；

向任務(wù)表中加入一條待處理記錄；

}

}

四、結(jié)語

本文介紹了一個(gè)基于Web的工作流引擎的具體實(shí)現(xiàn)，該工作流引擎已經(jīng)在藥業(yè)管理系統(tǒng)中得到了實(shí)際應(yīng)用，基本上可以達(dá)到預(yù)期效果，說明基于Web的工作流引擎設(shè)計(jì)和實(shí)現(xiàn)都具有相對(duì)可行性，可以應(yīng)用在具體的管理系統(tǒng)中。

第四篇：工作流與K2 BPM的實(shí)現(xiàn)

1.結(jié)構(gòu)化過程

這兩個(gè)模式的共同點(diǎn)在于：模式所涉及流程的執(zhí)行路徑是由運(yùn)行時(shí)決定的，而非設(shè)計(jì)時(shí)確定。包括：Arbitrary cycles（強(qiáng)制循環(huán)模式）、Implicit termination（隱式終止模式）。? 11 任意循環(huán)（Arbitrary Cycles）

? 描述：

工作流中的一個(gè)點(diǎn)可以讓一個(gè)或多個(gè)活動(dòng)反復(fù)的執(zhí)行。

? 案例：

“修改提交”后進(jìn)入“經(jīng)理審批”，但未通過，又回到“修改提交”。

? K2實(shí)現(xiàn)：

? 12 隱式終止（Implicit Termination）

? 描述：

在一個(gè)流程中，如果沒有活動(dòng)可執(zhí)行了那么流程就會(huì)終止。換句話說，在工作流中沒有active 狀態(tài)的活動(dòng)了，而且也沒有活動(dòng)會(huì)被激活，這就是隱式終止。（前提：工作流不能處于死鎖狀態(tài)）。

有的工作流引擎不支持。? 案例：

“主管審批”通過后進(jìn)入“經(jīng)理審批”，未通過則無下一個(gè)活動(dòng)。? K2實(shí)現(xiàn)：

如果“主管審批”的輸入為“不同意”，流程將終止。

一般都會(huì)采用顯示終止，因?yàn)殡[式終止可能會(huì)引起不被察覺的錯(cuò)誤，例如意外的輸入可能導(dǎo)致流程的結(jié)束。

? 多實(shí)例過程

“多實(shí)例”是指在流程圖中，一個(gè)活動(dòng)在同一時(shí)刻擁有多個(gè)可運(yùn)行的、處于活動(dòng)狀態(tài)的實(shí)例。

? 13 非同步的多實(shí)例（Multiple Instances Without Synchronization）

? 描述：

在流程中，一個(gè)活動(dòng)可以激活多個(gè)實(shí)例，也就是說可以把一個(gè)活動(dòng)分發(fā)成幾個(gè)控制線程。每個(gè)控制線程之間都是相互獨(dú)立的，并不需要同步它們。

? 案例：在網(wǎng)上訂購書籍，以書為單位，每一本都會(huì)獨(dú)立產(chǎn)生一個(gè)購書實(shí)例，并且每個(gè)實(shí)例之間不需要同步數(shù)據(jù)。? K2實(shí)現(xiàn)：

IPC Event調(diào)用方式需要選擇為Asynchronous。

? 14 在設(shè)計(jì)期間預(yù)先確定的多實(shí)例（Multiple Instances With a Priori Design Time Knowledge）

? 描述：

一個(gè)活動(dòng)可以激活多次產(chǎn)生多個(gè)實(shí)例。而產(chǎn)生的實(shí)例的個(gè)數(shù)在流程設(shè)計(jì)時(shí)就事先知道了。一旦所有的實(shí)例都執(zhí)行完成，就會(huì)激活其他活動(dòng)。? 案例：

有關(guān)某些特定資源的請(qǐng)求需要完成固定幾個(gè)不同的審核流程。? K2實(shí)現(xiàn)

主流程結(jié)構(gòu)為模式2平行拆分 + 模式3同步，IPC Event中調(diào)用方式需要選擇為Synchronous。

? 15 在運(yùn)行期預(yù)先確定的多實(shí)例（Multiple Instances With a Priori Runtime Knowledge）

? 描述：

一個(gè)活動(dòng)可以激活多次產(chǎn)生多個(gè)實(shí)例。而產(chǎn)生的實(shí)例的個(gè)數(shù)是變化的，取決于實(shí)例的特點(diǎn)或者可用資源數(shù)目，但是在流程執(zhí)行過程的某個(gè)時(shí)期，在這個(gè)活動(dòng)的實(shí)例產(chǎn)生以前，要產(chǎn)生的實(shí)例個(gè)數(shù)是能確定的。所有的實(shí)例都運(yùn)行完成后，激活后續(xù)活動(dòng)。? 案例：

處理一個(gè)訂單，訂單中有多本書，要分別檢查每一本都有庫存，所有的書都檢查完成后才開始進(jìn)入送貨。? K2實(shí)現(xiàn)：

主要結(jié)構(gòu)為模式6多路選擇 + 模式7同步合并，IPC Event中調(diào)用方式需要選擇為Synchronous。

? 16 無法在運(yùn)行期預(yù)先確定的多實(shí)例（Multiple Instances With a Priori Runtime Knowledge）

? 描述：

在一個(gè)活動(dòng)能夠被多次激活的這種情況下，在指定情況下的指定活動(dòng)的實(shí)例數(shù)量無論是在設(shè)計(jì)時(shí)或者運(yùn)行時(shí)都不能在活動(dòng)的實(shí)例被創(chuàng)建之前預(yù)先確定。但是，在活動(dòng)被創(chuàng)建之前，在運(yùn)行中的某個(gè)階段，這個(gè)數(shù)量是可以預(yù)知的。一旦所有的實(shí)例都完成了，其它的活動(dòng)應(yīng)該被啟動(dòng)。這個(gè)模式和模式14的區(qū)別在于，在某些實(shí)例運(yùn)行結(jié)束之后，新的實(shí)例仍能被創(chuàng)建。? 案例：

訂購100 臺(tái)電腦，涉及多個(gè)供應(yīng)商，但是每個(gè)供應(yīng)商供應(yīng)多少臺(tái)電腦是不知道的，因此供應(yīng)商的數(shù)量事先也不確定。但是當(dāng)每次供應(yīng)商送貨后，就會(huì)將現(xiàn)在所擁有的電腦數(shù)量和所需的100 臺(tái)進(jìn)行比較，來決定是否要下一個(gè)供應(yīng)商繼續(xù)送貨。? K2實(shí)現(xiàn)：

比較復(fù)雜，可以利用模式11任意循環(huán)實(shí)現(xiàn)。

? 基于狀態(tài)的模式

這三個(gè)模式的共同點(diǎn)是：模式所涉及根據(jù)當(dāng)前運(yùn)行的流程狀態(tài)來改變流程里的執(zhí)行路徑，包括：Deferred choice（延遲選擇模式）、Interleaved parallel routing（交替平行路由模式）、Milestone（里程碑模式）。

? 17 延遲選擇（Deferred Choice）

? 描述：

工作流中的一個(gè)點(diǎn)，有一個(gè)或多個(gè)分支已經(jīng)被選擇。與XOR拆分相比，并沒有明確的選擇，但是，選擇是取決于環(huán)境的。與AND拆分相比，兩者中只有一個(gè)被執(zhí)行。這意味著一旦環(huán)境啟動(dòng)了其中的一個(gè)，另一個(gè)就被取消。要注意，選擇是被延遲到兩個(gè)分支中的一個(gè)真正開始執(zhí)行時(shí)，也就是說，選擇是可以盡可能的推后的。? 案例：

在收到貨物之后，可選擇兩種方法將其送到。選擇取決于相關(guān)資源的可用性。如果資源均不可用，選擇會(huì)被推遲到直到其中一個(gè)資源可用為止。? K2實(shí)現(xiàn)：

“監(jiān)聽資源狀況”的Destination Rules是一個(gè)Robot帳號(hào)，只實(shí)現(xiàn)監(jiān)聽作用。

? 18 交替平行路由（Interleaved Parallel Routing）

? 描述：

一組活動(dòng)以任意的順序執(zhí)行，每個(gè)活動(dòng)都被執(zhí)行，他們的順序是在運(yùn)行時(shí)決定的，并且在任意一個(gè)時(shí)刻都不會(huì)有兩個(gè)活動(dòng)在執(zhí)行。? 案例：

體檢流程中的活動(dòng)有各種常規(guī)檢查和血液檢查，哪個(gè)在先哪個(gè)在后都可以，但是不可能同時(shí)檢查。? K2實(shí)現(xiàn)：

K2并無直接實(shí)現(xiàn)方法，需要編碼，變通解決。

? 19 里程碑（Milestone）

? 描述：

一個(gè)活動(dòng)能否執(zhí)行取決于一個(gè)指定的狀態(tài)。也就是說，只有在到達(dá)一個(gè)特定的未過期的里程碑時(shí)，活動(dòng)才被執(zhí)行。? 案例：

客戶在確定交付的前兩天是可以取消訂單的。? K2實(shí)現(xiàn)：

時(shí)間上的一些狀態(tài)可以在Start Rule 和Activity Escalations中實(shí)現(xiàn)，其他的復(fù)雜邏輯需要編程實(shí)現(xiàn)。

? 取消模式

這兩個(gè)模式的共同點(diǎn)在于：模式所涉及的流程在運(yùn)行時(shí)disables一個(gè)活動(dòng)或者整個(gè)流程，包括：Cancel activity（活動(dòng)取消模式）、Cancel case（實(shí)例取消模式）。? 20 取消活動(dòng)（Cancel Activity）

? 描述：

一個(gè)可執(zhí)行的活動(dòng)被強(qiáng)制失效了，也就是說，一個(gè)正在等待執(zhí)行的活動(dòng)所在線程被移除了。? 案例：

網(wǎng)上購書時(shí)已經(jīng)下了訂單，“支付貨款”活動(dòng)激活，這時(shí)如果取消了訂單，那么相應(yīng)的“支付貨款”活動(dòng)也要取消。? K2實(shí)現(xiàn)：

利用K2 的API實(shí)現(xiàn)。

? 21 取消實(shí)例（Cancel Case）? 描述：

如果一個(gè)活動(dòng)產(chǎn)生了多實(shí)例，那么僅僅撤消這個(gè)活動(dòng)是不行的，要將這個(gè)活動(dòng)的所有后代（實(shí)例）都移除才行。? 案例：

網(wǎng)上購書時(shí)如果取消了購書的活動(dòng)，所有因訂單激活的購書流程實(shí)例都要取消。? K2實(shí)現(xiàn)：

利用K2 的API實(shí)現(xiàn)。

? 其他擴(kuò)展模式

21個(gè)工作流模式并不能囊括所有情況，還有其他的一些擴(kuò)展模式，例如：流程啟動(dòng)、回退、轉(zhuǎn)發(fā)、通知、代理、催辦、回收、任務(wù)批處理、任務(wù)分組處理、流程合并、子流程等等。

第五篇：輕量級(jí)工作流引擎的設(shè)計(jì)與實(shí)現(xiàn)

第一章

引

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

1.2 工作流管理系統(tǒng)的分類及本文的側(cè)重點(diǎn)

根據(jù)工作流過程本身的特點(diǎn)、系統(tǒng)建模的方式、所使用的底層支撐技術(shù)、以及工作流過程的執(zhí)行方式等的不同而對(duì)工作流管理系統(tǒng)進(jìn)行相應(yīng)的分類。

1.2.1 面向文檔的與面向過程的 前者的側(cè)著點(diǎn)在于將電子形式的文件、圖像等在有關(guān)的人員之間進(jìn)行分發(fā)，以便能夠得到不同人的處理與審閱?，F(xiàn)有的文件管理與映像管理系統(tǒng)均屬此類。在面向過程的WFMS中，工作流被描述成一序列執(zhí)行環(huán)節(jié)。與各環(huán)節(jié)相應(yīng)都有待處理的資料對(duì)象。各環(huán)節(jié)的資料對(duì)象可以按不同的方式分發(fā)到其它環(huán)節(jié)中去，如可以將資料對(duì)象的值作為控制條件、或者依此資料對(duì)象組裝成其它的資料對(duì)象等。高端的WFMS一般都屬此類系統(tǒng)。

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

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

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

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

第二章

工作流管理系統(tǒng)參考模型簡(jiǎn)介在闡述工作流引擎之前，我們來了解一下工作流技術(shù)的基本知識(shí)。早在幾年前，為了建立工作流管理系統(tǒng)的相關(guān)標(biāo)準(zhǔn)，國際上成立了一個(gè)稱為“工作流管理聯(lián)盟”（簡(jiǎn)稱WFMC）的國際組織。她提出了有關(guān)工作流管理系統(tǒng)的一些規(guī)范，定義了工作流管理系統(tǒng)的結(jié)構(gòu)及其與應(yīng)用、管理工具和其它工作流管理系統(tǒng)之間的應(yīng)用編程接口，也就是工作流系統(tǒng)參考模型。

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

接口2

接口3

接口4

接口1

接口5

過程定義工具

工作流API與交換格式

工作流執(zhí)行服務(wù)

工作流機(jī)

（工作流引擎）

工作流 管理工具

其它工作流 執(zhí)行服務(wù)

工作流機(jī)

工作流客戶應(yīng)用

工作流機(jī)直接調(diào)用 的應(yīng)用

圖2.1 工作流參考模型

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

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

⑵ 接口2：客戶端函數(shù)接口，這是工作流服務(wù)與客戶應(yīng)用之間的接口，這是最主要的接口規(guī)范，它約定所有客戶方應(yīng)用與工作流服務(wù)之間的功能操作方式。包括通信建立，工作流定義操作（對(duì)過程模型定義操作），過程實(shí)例管理功能，過程狀態(tài)管理功能，任務(wù)項(xiàng)列表/任務(wù)項(xiàng)處理功能，數(shù)據(jù)處理過程，過程監(jiān)控功能，其它的管理功能，應(yīng)用程序激活。

⑶ 接口3：激活應(yīng)用程序接口，這是工作流引擎和直接調(diào)用的應(yīng)用程序之間的接口，包括通信建立，活動(dòng)管理功能，數(shù)據(jù)處理功能。

⑷ 接口4：工作流執(zhí)行服務(wù)之間的互操作接口，這是工作流管理系統(tǒng)之間的互操作接口，包括連接的建立，對(duì)工作流模型和其中對(duì)象的操作，對(duì)過程實(shí)例的控制和狀態(tài)描述，對(duì)活動(dòng)的管理，對(duì)資料進(jìn)行處理。

⑸ 接口5：系統(tǒng)管理與監(jiān)控接口，這是工作流服務(wù)和工作流管理工具之間的接口，包括資源控制，角色管理，用戶管理，過程實(shí)例的管理，狀態(tài)管理，審核管理。

五個(gè)接口以及對(duì)應(yīng)的API函數(shù)囊括了工作流管理系統(tǒng)的全部功能。一個(gè)完整的工作流管理系統(tǒng)就是以工作流引擎為中心，向外部部件（應(yīng)用程序或其它工作流引擎）提供這五個(gè)接口，提供其實(shí)現(xiàn)的所有功能。

第三章

系統(tǒng)分析與設(shè)計(jì)在所有準(zhǔn)備工作完成后，我們就開始進(jìn)行系統(tǒng)設(shè)計(jì)和設(shè)計(jì)，構(gòu)造一個(gè)輕量級(jí)的工作流引擎。輕量級(jí)的工作流引擎并不完全實(shí)現(xiàn)WFMC所提出的工作流模型包含的五個(gè)接口，特別是接口4，在分布式工作流管理系統(tǒng)才具有該接口。既然我們從輕量級(jí)的概念出發(fā)，我們就不再明顯區(qū)分各個(gè)接口的界限以及其所具有的特定的功能，以夠用、靈活和低成本的設(shè)計(jì)原則去設(shè)計(jì)出我們所理解的工作流引擎。我們運(yùn)用了面向?qū)ο蟮姆椒?，首先從眾多的業(yè)務(wù)需求中抽取出工作流模型所包含的對(duì)象，再分析各個(gè)對(duì)象之間的邏輯關(guān)系，然后提出一個(gè)系統(tǒng)結(jié)構(gòu)，再進(jìn)行模塊劃分，數(shù)據(jù)庫設(shè)計(jì)，最終完成類的設(shè)計(jì)。我們當(dāng)中所用到的建模工具就是ROSE UML。

3.1 工作流模型的設(shè)計(jì)

對(duì)工作流模型的設(shè)計(jì)是工作流引擎設(shè)計(jì)的重要組成部分。

3.1.1 工作流模型的對(duì)象

企事業(yè)經(jīng)營過程就是一項(xiàng)項(xiàng)業(yè)務(wù)的實(shí)現(xiàn)過程，我們從一般業(yè)務(wù)入手，并對(duì)這些業(yè)務(wù)進(jìn)行詳細(xì)的分析，研究，其結(jié)果就是得到一般性的業(yè)務(wù)對(duì)象，從而抽象成工作流模型對(duì)象。

3.1.1.1 從一個(gè)簡(jiǎn)單的業(yè)務(wù)實(shí)例看業(yè)務(wù)的需求

目前企事業(yè)的一項(xiàng)基本事務(wù)就是出差管理。它主要是對(duì)企事業(yè)的人員因?yàn)槟撤N工作上的原因需要到別的地方出差進(jìn)行的管理。我們可以列出出差的相關(guān)步驟：

⑴ 申請(qǐng)人需要出差，并且他（她）具有出差的權(quán)利；

⑵ 申請(qǐng)人填寫出差表格，說明因何事出差，出差何處，申請(qǐng)出差金額，何時(shí)回來等等和出差相關(guān)的情況；

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

⑷ 申請(qǐng)人確認(rèn)申請(qǐng)無誤后提交申請(qǐng)，等待申請(qǐng)的結(jié)果；

⑸ 根據(jù)規(guī)定，該申請(qǐng)必須先讓申請(qǐng)人的上一級(jí)審批，那么該申請(qǐng)就會(huì)以一項(xiàng)工作項(xiàng)的形式交給該級(jí)領(lǐng)導(dǎo)處理；

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

⑺

申請(qǐng)人得到申請(qǐng)的結(jié)果，如果審批通過則準(zhǔn)備出差，如果審批不通過則根據(jù)審批結(jié)果對(duì)該申請(qǐng)進(jìn)行修改，重新提交申請(qǐng)； ⑻ 申請(qǐng)事務(wù)結(jié)束。

這是一個(gè)簡(jiǎn)單的業(yè)務(wù)實(shí)例，對(duì)該實(shí)例進(jìn)行分析我們可以得到該業(yè)務(wù)的一些對(duì)象：

⑴ 申請(qǐng)人：他（她）屬于該企事業(yè)的某個(gè)部門的成員，并且具有啟動(dòng)該業(yè)務(wù)的權(quán)利； ⑵ 審批領(lǐng)導(dǎo)：他（她）也屬于該企事業(yè)的某個(gè)部門的成員，并且具有對(duì)該業(yè)務(wù)進(jìn)行處理的權(quán)利；

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

⑸ 申請(qǐng)人已經(jīng)填寫好的出差表格：它是出差表格的實(shí)例化，代表一個(gè)具體的應(yīng)用 ⑹ 審批同意和不同意：它們是對(duì)該業(yè)務(wù)的處理，遵循一定的業(yè)務(wù)規(guī)則 ⑺ 申請(qǐng)：這是一個(gè)過程，不是一個(gè)動(dòng)作，需要時(shí)間和人的活動(dòng)才能完成 ⑻ 審批：這是一個(gè)活動(dòng)，是過程的一部分，并且可以向另外一個(gè)活動(dòng)轉(zhuǎn)化

⑼ 其它應(yīng)用程序：申請(qǐng)人要填寫出差具體說明時(shí)要調(diào)用相應(yīng)的外部應(yīng)用程序編輯該說明并以一定的格式保存下來，審批領(lǐng)導(dǎo)要查看出差具體說明時(shí)也要調(diào)用相應(yīng)的外部應(yīng)用程序打開該說明并以一定的格式顯示出來。

從這些業(yè)務(wù)對(duì)象，再利用工作流技術(shù)，我們可以得到工作流模型的一些基本對(duì)象：

⑴ 用戶：正如申請(qǐng)人，審批領(lǐng)導(dǎo)，他們就是工作流管理系統(tǒng)的用戶，由他們?nèi)ナ褂迷撓到y(tǒng)的各種功能，并且直接參與業(yè)務(wù)活動(dòng)，促使業(yè)務(wù)的完成。

⑵ 角色：有些人可以申請(qǐng)出差，有些人對(duì)出差申請(qǐng)可以審批，這兩種不同的人可以作為兩個(gè)不同的角色。角色是具有某種使用系統(tǒng)特定功能的權(quán)利的一個(gè)人員或多個(gè)人員的組合。⑶ 工作流應(yīng)用資料：出差申請(qǐng)表格，出差具體說明，這些就是對(duì)應(yīng)某個(gè)具體業(yè)務(wù)（這里是出差管理）的相關(guān)資料，根據(jù)這些業(yè)務(wù)資料我們可以對(duì)該業(yè)務(wù)進(jìn)行處理。

⑷ 需激活的應(yīng)用程序：在需要其它應(yīng)用程序提供支持的時(shí)候，會(huì)去激活這些應(yīng)用程序。⑸ 流程：整個(gè)出差申請(qǐng)的過程就是一個(gè)流程，它從整體去描述一個(gè)業(yè)務(wù)。

⑹ 環(huán)節(jié)：又稱活動(dòng)，它反映了業(yè)務(wù)流程的局部情況，通常業(yè)務(wù)流程是由一個(gè)一個(gè)的環(huán)節(jié)組成。

⑺ 流程實(shí)例：將該出差申請(qǐng)這個(gè)業(yè)務(wù)流程實(shí)例化，就得到一個(gè)流程實(shí)例。⑻ 環(huán)節(jié)實(shí)例：將流程的其中一個(gè)環(huán)節(jié)實(shí)例化，就得到一個(gè)環(huán)節(jié)實(shí)例。

⑼ 業(yè)務(wù)規(guī)則：業(yè)務(wù)的開始和結(jié)束需要一定的條件，在處理業(yè)務(wù)的過程中必須按照一定的規(guī)則，這些都是業(yè)務(wù)規(guī)則，只有嚴(yán)格遵循業(yè)務(wù)規(guī)則，業(yè)務(wù)才能完成。

3.1.1.2 工作流對(duì)象的具體分析和說明

通過一個(gè)具體的業(yè)務(wù)我們可以得到工作流模型的一些對(duì)象，那么我們?cè)賹?duì)其他一般性業(yè)務(wù)進(jìn)行分析，研究，我們就會(huì)找到它們的共同點(diǎn)，并歸納出基于這些業(yè)務(wù)的公共的對(duì)象，這些公共的對(duì)象的組合，就是一個(gè)通用的模型，也就是工作流模型，這個(gè)模型能去描述每個(gè)業(yè)務(wù)，是我們追求輕量級(jí)工作流引擎的最終成果。

⑴ 用戶：業(yè)務(wù)的執(zhí)行者和參與者，對(duì)應(yīng)于企事業(yè)的每一個(gè)雇員，是一個(gè)獨(dú)立的、具有一定行為能力和一定技術(shù)能力的人的實(shí)體；

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

⑶ 部門：對(duì)應(yīng)于企事業(yè)的靜態(tài)結(jié)構(gòu)劃分，由企事業(yè)的實(shí)際部門設(shè)置情況來決定，可以是傳統(tǒng)的面向職能的，也可以是現(xiàn)在流行的面向過程與客戶的；

⑷ 職位：以行政責(zé)任為前提，代表了管理上的等級(jí)關(guān)系；

⑸ 工作組：以執(zhí)行某一任務(wù)為目標(biāo)而動(dòng)態(tài)組建的、跨部門劃分的一種組織結(jié)構(gòu)；

⑹ 流程：對(duì)應(yīng)于一個(gè)業(yè)務(wù)過程，表示一個(gè)業(yè)務(wù)由發(fā)起、處理、結(jié)束的一個(gè)過程；

⑺ 流程實(shí)例：對(duì)應(yīng)于一個(gè)業(yè)務(wù)流程具體應(yīng)用，是業(yè)務(wù)流程實(shí)例化的表現(xiàn)形式；

⑻ 環(huán)節(jié)：對(duì)應(yīng)于業(yè)務(wù)流程中一個(gè)單一的業(yè)務(wù)操作，是流程按照業(yè)務(wù)要求的細(xì)化；

⑼ 環(huán)節(jié)實(shí)例：對(duì)應(yīng)于一個(gè)環(huán)節(jié)的具體應(yīng)用，是環(huán)節(jié)實(shí)例化的表現(xiàn)形式；

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

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

●

表格類型：這是以表格的形式保存附件信息，可以用關(guān)系結(jié)構(gòu)來定義附件信息，并保存在數(shù)據(jù)庫中，每一條記錄就是一個(gè)該附件的實(shí)例；

●

文檔類型：只是以文件形式保存附件信息，可以是work文檔，也可以是文本文件，它的實(shí)例化是就是一個(gè)一個(gè)帶有對(duì)應(yīng)某個(gè)業(yè)務(wù)應(yīng)用標(biāo)志的文件，保存在硬盤上 ⑿ 工作流實(shí)例信息：描述一個(gè)工作流模型實(shí)例化的信息，也作為啟動(dòng)一個(gè)工作流的信息，它記錄該業(yè)務(wù)流程隨著時(shí)間和人員的參與處理的不斷變化，直到整個(gè)業(yè)務(wù)的結(jié)束；

⒀ 工作項(xiàng)信息：描述參與某個(gè)業(yè)務(wù)應(yīng)用時(shí)被分配到的一項(xiàng)任務(wù)，這就體現(xiàn)了參與人員和系統(tǒng)交互的典型特征；

⒁ 業(yè)務(wù)規(guī)則：描述業(yè)務(wù)在運(yùn)行的過程中必須要遵守的規(guī)定和原則，也是業(yè)務(wù)活動(dòng)得以向另一個(gè)活動(dòng)推進(jìn)的規(guī)則。我們把它分為四類規(guī)則，分別是： ●

自動(dòng)型：它主要描述一些只給參與人員查看業(yè)務(wù)信息的業(yè)務(wù)規(guī)則，例如通知、公文流轉(zhuǎn)等等業(yè)務(wù)。該類業(yè)務(wù)不需要參與人員去審批或其它人為上的處理，只需要參與人員去查看其中的內(nèi)容就足夠，整個(gè)業(yè)務(wù)流程的完成是全自動(dòng)的?！?/p>

與聚合：業(yè)務(wù)活動(dòng)的完成是需要參與該活動(dòng)的所有人員都進(jìn)行人為處理，其中有一個(gè)人員沒對(duì)其進(jìn)行處理，整個(gè)活動(dòng)只能停在原地，等待所有人員的處理，當(dāng)最后一個(gè)參與人員執(zhí)行了處理工作，它才能完成。●

或聚合：在參與某一業(yè)務(wù)活動(dòng)的人員當(dāng)中只要有一個(gè)對(duì)其進(jìn)行處理，整個(gè)活動(dòng)就可以完成。

●

投票聚合：統(tǒng)計(jì)參與該活動(dòng)的參與人員的處理結(jié)果，當(dāng)滿足一定條件該活動(dòng)才能完成。

⒂ 轉(zhuǎn)換條件：描述流程、活動(dòng)狀態(tài)改變時(shí)需要的條件，用于業(yè)務(wù)運(yùn)行過程中的約束。例如流程的完成必須等待所有活動(dòng)的完成才能完成，活動(dòng)的完成必須按照業(yè)務(wù)規(guī)則去完成等等； ⒃ 需激活的應(yīng)用程序：工作流管理系統(tǒng)需要其它應(yīng)用程序的支持，例如編輯和查看文本文件信息等等；

⒄ 日志信息：描述工作流中所有的狀態(tài)改變、事件和控制流相關(guān)資料的變化，工作流實(shí)例和環(huán)節(jié)實(shí)例的啟動(dòng)、結(jié)束、掛起和激活等等信息都會(huì)記錄下來，以便對(duì)其進(jìn)行管理。3.1.2 對(duì)象之間的邏輯關(guān)系在找出工作流模型的對(duì)象后，我們就開始分析它們之間的業(yè)務(wù)邏輯關(guān)系。

3.1.2.1 對(duì)對(duì)象進(jìn)行分類以及各個(gè)分類中對(duì)象之間的關(guān)系到此為止，我們有必要對(duì)工作流模型對(duì)象進(jìn)行一下分類，根據(jù)工作流對(duì)象對(duì)工作流管理系統(tǒng)所起的作用我們可以分成以下幾類： ⑴ 組織模型

組織模型描述了企事業(yè)的組織機(jī)構(gòu)關(guān)系，包括的對(duì)象有用戶，部門，職位，角色，工作組，它們的關(guān)系可以用下圖表示：

設(shè)置

負(fù)責(zé)

組成 組成 資格

組成 部門

職位

用戶

工作組

角色

圖3.1 組織模型結(jié)構(gòu)

從圖中可以看到它們之間的關(guān)系，用戶是基本的單位，部門是由用戶組成，每個(gè)用戶對(duì)應(yīng)一個(gè)職位，負(fù)責(zé)該職位所要求的職能，用戶憑著某種資格賦予一種角色，工作組也由用戶組成，也可以由角色組成。這幾個(gè)基本的對(duì)象以及其關(guān)系所構(gòu)成的組織模型，已經(jīng)可以滿足輕量級(jí)工作流引擎對(duì)組織模型的需要了。⑵ 工作流定義模型

工作流定義模型描述了工作流模型的定義信息，包括工作流定義主信息，流程定義信息，環(huán)節(jié)定義信息，工作流附件信息，業(yè)務(wù)規(guī)則。它們之間的關(guān)系如下圖：

圖3.2 工作流定義模型結(jié)構(gòu)

包含

包含

包含

包含

遵循

包含

工作流定義

附件信息

主信息

業(yè)務(wù)規(guī)則

環(huán)節(jié)

流程

包含

流程是包含若干環(huán)節(jié)的，而環(huán)節(jié)遵循一定的業(yè)務(wù)規(guī)則，再加上工作流主信息和附件信息，共同構(gòu)成工作流定義模型。⑶ 工作流實(shí)例模型

工作流實(shí)例模型描述了工作流模型實(shí)例化時(shí)的信息，通過這些信息我們可以知道實(shí)例過程中的各種狀態(tài)變化和最終的結(jié)果，因而得到一個(gè)業(yè)務(wù)具體應(yīng)用的情況。它包括流程實(shí)例，環(huán)節(jié)實(shí)例，工作流實(shí)例信息，工作項(xiàng)信息和轉(zhuǎn)換條件，它們之間的關(guān)系如下圖：

記錄

記錄

細(xì)化

細(xì)化

影響

影響

影響

影響

記錄

記錄

轉(zhuǎn)換條件

環(huán)節(jié)實(shí)例信息

流程實(shí)例信息

工作項(xiàng)信息

工作流實(shí)例信息

日志信息

日志信息

細(xì)化

圖3.3 工作流實(shí)例模型結(jié)構(gòu)

轉(zhuǎn)換條件影響工作流實(shí)例，流程實(shí)例，環(huán)節(jié)實(shí)例和工作項(xiàng)的狀態(tài)，并由轉(zhuǎn)換條件去決定它們的狀態(tài)轉(zhuǎn)變，工作流實(shí)例信息à流程實(shí)例信息à環(huán)節(jié)實(shí)例信息à工作項(xiàng)信息，自上而下逐層細(xì)化，不但從全局了解業(yè)務(wù)運(yùn)行情況，而且從局部了解業(yè)務(wù)運(yùn)行的細(xì)節(jié)情況。而它們的狀態(tài)改變都會(huì)記錄在日志中，用以追蹤工作流實(shí)例的運(yùn)行情況。⑷ 外部支持模型

外部支持模型在本文只包括一個(gè)對(duì)象，就是需激活的外部應(yīng)用程序，嚴(yán)格來說這不是工作流模型的一部分，可是提供接口去激活所需的外部應(yīng)用程序?yàn)楣ぷ髁鞴芾硐到y(tǒng)提供支持是工作流模型的功能之一。有了這些外部應(yīng)用程序的支持，我們的工作流管理系統(tǒng)的功能才變得更完善。

3.1.2.2 各個(gè)模型之間的邏輯關(guān)系

不但模型中各個(gè)對(duì)象有一定的邏輯關(guān)系，而且各個(gè)模型之間也有一定的邏輯關(guān)系，如下圖所示：

調(diào)用

依賴

使用

使用角色和工作組

用戶定義

工作流實(shí)例模型

外部支持模型

工作流定義模型

組織模型

圖3.4 模型之間的關(guān)系

組織模型的用戶定義工作流定義模型；工作流定義模型使用組織模型的角色和工作組，用來規(guī)定工作流模型的啟動(dòng)條件和任務(wù)分配條件，因?yàn)楣ぷ髁髂Ｐ偷膯?dòng)和任務(wù)的分配必須由一定的角色或工作組完成；工作流實(shí)例模型依賴工作流定義模型，同時(shí)使用組織模型的所有對(duì)象，并且調(diào)用外部支持模型為其提供支持。3.1.3 工作流實(shí)例，流程實(shí)例，環(huán)節(jié)實(shí)例和工作項(xiàng)的狀態(tài)轉(zhuǎn)換

工作流實(shí)例，流程實(shí)例，環(huán)節(jié)實(shí)例和工作項(xiàng)從不同的層次去描述業(yè)務(wù)運(yùn)行過程的具體情況，不同級(jí)別的用戶可以看到業(yè)務(wù)運(yùn)行的不同方面，創(chuàng)建工作流實(shí)例的用戶可以看到工作流實(shí)例信息以及其狀態(tài)轉(zhuǎn)換，參與該工作流實(shí)例的用戶可以看到工作項(xiàng)信息以及其狀態(tài)的改變，系統(tǒng)管理員可以看到所有信息以及其狀態(tài)的轉(zhuǎn)換。

⑴ 工作流實(shí)例狀態(tài)圖

創(chuàng)建

管理員

管理員

管理員

Running（運(yùn)行）

Completed（結(jié)束）

正常情況

Suspended(掛起)

terminated(終止)

Initial（初始化）

圖3.5 工作流實(shí)例狀態(tài)圖

提交

⑵ 流程實(shí)例狀態(tài)圖

管理員

管理員

管理員

Running（運(yùn)行）

Completed（結(jié)束）

正常情況

Suspended(掛起)

terminated(終止)

圖3.6 流程實(shí)例狀態(tài)圖

⑶ 環(huán)節(jié)實(shí)例狀態(tài)圖

處理中

接受

完成正常處理

沒有完成異常處理

回退處理

提交給下一環(huán)節(jié)

圖3.5 環(huán)節(jié)實(shí)例狀態(tài)圖

⑷ 工作項(xiàng)狀態(tài)轉(zhuǎn)換圖

等待操作

完成 通過

沒有完成 不通過

無操作，超時(shí)

操作下一工作項(xiàng)

回退處理

已查看

初始化

未審批

未查看

圖3.5 工作項(xiàng)狀態(tài)圖

接受

3.1.4 任務(wù)分派任務(wù)分派是工作流引擎的一個(gè)重要功能。當(dāng)環(huán)節(jié)實(shí)例產(chǎn)生時(shí)，就會(huì)以一定的準(zhǔn)則把需要處理的工作當(dāng)作一項(xiàng)任務(wù)項(xiàng)（工作項(xiàng)）分派給參與該環(huán)節(jié)實(shí)例的所有用戶，而這些用戶是同屬一個(gè)角色或者工作組的。我們又把角色和工作組進(jìn)行細(xì)化，可以得到以下準(zhǔn)則： ⑴ 基于部門的：這就是說把任務(wù)分派到某個(gè)部門的所有人員，該部門的所有人員都參與了該項(xiàng)任務(wù)，因而會(huì)為該部門的所有人員都產(chǎn)生一個(gè)工作項(xiàng)；

⑵ 基于職位的：這就是說把任務(wù)分派到某個(gè)職位的所有人員，同屬該職位的所有人員都被分配到一項(xiàng)工作項(xiàng)；

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

⑷ 基于所有人的：這就是說把任務(wù)分派到該企事業(yè)的所有人，該企事業(yè)的所有人都被分配到一項(xiàng)工作項(xiàng)；

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

基于部門的，基于職位的，基于部門職位的和基于所有人的這四種類型，其實(shí)是基于角色的細(xì)化，通過這些準(zhǔn)則的分類，我們盡量做到系統(tǒng)與企事業(yè)有較強(qiáng)的適應(yīng)性，以及使系統(tǒng)在任務(wù)分派時(shí)有較大的靈活性。3.1.5 轉(zhuǎn)換條件的滿足

工作流實(shí)例，流程實(shí)例，環(huán)節(jié)實(shí)例和工作項(xiàng)的狀態(tài)轉(zhuǎn)換有各自特定的條件，分別如下：

⑴ 工作流實(shí)例的轉(zhuǎn)換條件

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

⑵ 流程實(shí)例的轉(zhuǎn)換條件

流程實(shí)例也從整體看業(yè)務(wù)的運(yùn)行過程，流程實(shí)例在工作流實(shí)例初始化時(shí)就開始它的工作。在運(yùn)行過程中，它會(huì)根據(jù)各個(gè)環(huán)節(jié)的完成程度來改變自己的狀態(tài)，當(dāng)所有環(huán)節(jié)實(shí)例都正常完成它就正常結(jié)束；管理員可能要掛起它使它處于掛起狀態(tài)，直到管理員重新激活它使它處于運(yùn)行狀態(tài)或者終止它使它非正常結(jié)束。

⑶ 環(huán)節(jié)實(shí)例的轉(zhuǎn)換條件

環(huán)節(jié)實(shí)例從某個(gè)方面看業(yè)務(wù)的運(yùn)行過程，環(huán)節(jié)實(shí)例在流程實(shí)例運(yùn)行時(shí)就開始它的工作處于處理中狀態(tài)。之后環(huán)節(jié)實(shí)例的狀態(tài)由兩方面決定，一是工作項(xiàng)的處理結(jié)果，一是業(yè)務(wù)規(guī)則的規(guī)定。

●

如果業(yè)務(wù)規(guī)則是自動(dòng)型的，不管工作項(xiàng)的處理結(jié)果怎樣，當(dāng)系統(tǒng)把任務(wù)項(xiàng)分派（給特定用戶）完畢后，該環(huán)節(jié)實(shí)例就正常完成處于正常結(jié)束狀態(tài)；

●

如果業(yè)務(wù)規(guī)則是與聚合的，系統(tǒng)分派完任務(wù)項(xiàng)后，當(dāng)所有參與人員都正常處理完該環(huán)節(jié)各自的工作項(xiàng)后，該環(huán)節(jié)才正常完成處于正常結(jié)束狀態(tài)；在處理過程中，只要有一個(gè)工作項(xiàng)是非正常處理的，該環(huán)節(jié)就非正常完成處于非正常結(jié)束狀態(tài)；在處理過程中，有工作項(xiàng)還未被處理并且沒有一個(gè)工作項(xiàng)被非正常處理，那么環(huán)節(jié)實(shí)例仍然處于處理中狀態(tài)；

●

如果業(yè)務(wù)規(guī)則是或聚合的，系統(tǒng)分派任務(wù)后，只要有一個(gè)工作項(xiàng)是正常處理的，該環(huán)節(jié)實(shí)例就正常完成處于正常結(jié)束狀態(tài)；如果所有同屬該環(huán)節(jié)實(shí)例的工作項(xiàng)都被非正常完成，那么該環(huán)節(jié)實(shí)例就處于非正常結(jié)束狀態(tài)；

●

如果業(yè)務(wù)規(guī)則是投票聚合的，系統(tǒng)分派任務(wù)后，統(tǒng)計(jì)工作項(xiàng)的完成程度，當(dāng)正常完成的工作項(xiàng)數(shù)量達(dá)到一定數(shù)量時(shí)，該環(huán)節(jié)實(shí)例就正常完成處于正常結(jié)束狀態(tài)；當(dāng)正常完成的工作項(xiàng)數(shù)量不達(dá)到規(guī)定的數(shù)量時(shí)，該環(huán)節(jié)就非正常完成處于非正常結(jié)束狀態(tài)；當(dāng)所有工作項(xiàng)還沒處理并且正常完成的工作項(xiàng)還沒達(dá)到規(guī)定數(shù)量時(shí)，該環(huán)節(jié)實(shí)例仍然處于處理中狀態(tài)。

⑷ 工作項(xiàng)的轉(zhuǎn)換條件

工作項(xiàng)從更細(xì)節(jié)的方面看業(yè)務(wù)運(yùn)行過程，工作項(xiàng)的狀態(tài)轉(zhuǎn)換要看參與人員對(duì)各自的工作項(xiàng)的處理情況和業(yè)務(wù)規(guī)則的規(guī)定。我們把與聚合，或聚合和投票聚合這些要人工干預(yù)的規(guī)則統(tǒng)稱為人工型規(guī)則。

●

如果業(yè)務(wù)規(guī)則是自動(dòng)型，同屬該規(guī)則的工作項(xiàng)的狀態(tài)就只有正常處理后的正常結(jié)束狀態(tài)，當(dāng)然如果對(duì)該工作項(xiàng)還沒被處理則處于處理中狀態(tài)，可這不對(duì)環(huán)節(jié)實(shí)例等產(chǎn)生影響；

●

如果業(yè)務(wù)規(guī)則是人工型，就會(huì)有正常處理和非正常處理兩種情況，正常處理該工作項(xiàng)則使到該工作項(xiàng)處于正常結(jié)束狀態(tài)，非正常處理該工作項(xiàng)則使到該工作項(xiàng)處于非正常結(jié)束狀態(tài)。

3.2 系統(tǒng)結(jié)構(gòu)

本著基于輕量級(jí)工作流引擎的原則，我們已經(jīng)對(duì)工作流模型進(jìn)行了詳細(xì)的分析和詳細(xì)的設(shè)計(jì)，在這里我們就提出一個(gè)系統(tǒng)結(jié)構(gòu)，如下圖所示：

工作流定義器

工作流

解析器

實(shí)例調(diào)度中心

任務(wù)管理器

任務(wù)分派器

啟動(dòng)控制器

工作流定義數(shù)據(jù)

工作流實(shí)例 數(shù)據(jù)

日志 數(shù)據(jù)

工作流定義接口

工作流實(shí)例接口

組織定義

數(shù)據(jù)

組織定義接口

組織定義器

狀態(tài)轉(zhuǎn)換器

組織

管理器

圖3.6 工作流引擎系統(tǒng)結(jié)構(gòu)圖

從圖中可以知道，系統(tǒng)提供了三類接口：組織定義接口、工作流定義接口和工作流實(shí)例接口。這三類接口實(shí)現(xiàn)了工作流模型的接口一，接口二，接口三和接口五規(guī)定的主要功能；系統(tǒng)有一個(gè)實(shí)例調(diào)度中心，這是一個(gè)很重要的部件，它控制工作流實(shí)例的運(yùn)行，通過工作流解析器對(duì)該工作流模型進(jìn)行解析其含義，通過任務(wù)分派器按照一定的分派準(zhǔn)則把任務(wù)項(xiàng)分派給參與該工作流實(shí)例的用戶，通過任務(wù)管理器管理各個(gè)任務(wù)項(xiàng)的信息，通過啟動(dòng)控制器控制工作流的啟動(dòng)權(quán)利和啟動(dòng)信息，通過狀態(tài)轉(zhuǎn)換器控制工作流實(shí)例、流程實(shí)例、環(huán)節(jié)實(shí)例和工作項(xiàng)的狀態(tài)轉(zhuǎn)換；組織定義器定義企事業(yè)的組織結(jié)構(gòu)；工作流定義器定義工作流模型信息，并通過組織管理器得到組織定義信息，為工作流模型提供組織支持。各個(gè)部件處理的相關(guān)信息都保存在數(shù)據(jù)庫中。

3.3 系統(tǒng)模塊的劃分

根據(jù)功能實(shí)現(xiàn)的不同我們進(jìn)行模塊的劃分如下：

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

⑵ 部門管理模塊：對(duì)企事業(yè)部門結(jié)構(gòu)信息的管理，包括增加部門信息，刪除部門信息，查詢部門信息等等功能；

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

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

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

⑹ 工作流實(shí)例管理模塊：對(duì)工作流實(shí)例信息的管理，包括啟動(dòng)一個(gè)新的工作流實(shí)例，查詢工作流實(shí)例信息，按照一定的業(yè)務(wù)規(guī)則生成新的環(huán)節(jié)實(shí)例信息，為用戶分派工作項(xiàng)，管理工作項(xiàng)信息，按照一定的轉(zhuǎn)換條件為工作流實(shí)例、環(huán)節(jié)實(shí)例轉(zhuǎn)換狀態(tài)等等功能；

⑺ 系統(tǒng)監(jiān)控模塊：為工作流實(shí)例，環(huán)節(jié)實(shí)例等的狀態(tài)轉(zhuǎn)換信息加入日志，掛起、激活工作流實(shí)例，強(qiáng)制結(jié)束工作流實(shí)例，為遲遲不對(duì)自己的工作項(xiàng)進(jìn)行處理的用戶發(fā)出提醒或警告信息，查看各個(gè)工作流實(shí)例的完成程度等等功能。

功能模塊的劃分，為系統(tǒng)的實(shí)現(xiàn)做好充分的準(zhǔn)備。

3.4 數(shù)據(jù)庫設(shè)計(jì)

基于輕量級(jí)的工作流引擎的特點(diǎn)之一就是把系統(tǒng)相關(guān)的資料，如工作流模型定義信息，工作流實(shí)例信息，組織模型定義信息等等，都以特定的實(shí)體形式保存在關(guān)系型數(shù)據(jù)庫中。

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

靜態(tài)定義工作流主要信息，包括該工作流的標(biāo)識(shí)ID（可以定義為以”WORKFLOW_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自動(dòng)生成的序號(hào)），工作流名稱，工作流描述，工作流類型（工作流的類型有自動(dòng)型，人工型和混合型，自動(dòng)型不需要人工參與，由工組流引擎自動(dòng)執(zhí)行，人工型需要人工參與，混合型包含了自動(dòng)型和人工型），工作流創(chuàng)建日期，工作流創(chuàng)建者ID（即用戶ID），工作流創(chuàng)建人名稱（即用戶名），工作流生命周期（每個(gè)工作流實(shí)例都有它的生命周期期限，在該期限內(nèi)還沒完成它的工作就直接死亡），目前該工作流實(shí)例數(shù)目（記錄當(dāng)前工作流實(shí)例數(shù)目），工作流啟動(dòng)者角色（指明該工作流可以由哪個(gè)角色發(fā)起，屬于該角色的用戶都可以啟動(dòng)該工作流模型對(duì)應(yīng)的實(shí)例）。工作流重要信息還包括兩方面，一是工作流附件，因?yàn)樵诠ぷ髁鬟M(jìn)行過程中，肯定會(huì)帶有一些信息，這些信息對(duì)于出差申請(qǐng)來說就是出差申請(qǐng)表，對(duì)于公文流轉(zhuǎn)來說就是以word文檔形式的公文，對(duì)于通知來說可能就是以文本文檔形式的通知書，等等；一是工作流流程描述，包括若干個(gè)環(huán)節(jié)（activity），這些環(huán)節(jié)有一定的順序，表現(xiàn)工作流順序執(zhí)行的特征。把工作流附件和工作流流程描述從工作流定義分離出來，是基于工作流附件和工作流流程描述對(duì)于不同工作流有不同形式和數(shù)量的原因，有利于工作流附件和工作流流程描述的擴(kuò)展。⑵ 工作流附件信息表（workflowAttachmentTable）

靜態(tài)定義工作流所需要的附件，包括附件ID（可以定義為以”Attachment_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自動(dòng)生成的序號(hào)），工作流ID（標(biāo)識(shí)屬于哪個(gè)工作流），附件類型（表或文件），附件名稱（如果類型是表，則為該表的名稱，如果是word文檔，則為該文檔名稱，如果是文本文檔，則為該文件名稱），其它信息（如果類型為表格，該字段以一定的格式保存該附件表格的所有字段的各種信息，包括字段名稱，字段數(shù)據(jù)類型，數(shù)據(jù)類型長(zhǎng)度，字段描述）。⑶ 工作流流程描述表（workflowProcessTable）

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

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

⑸ 工作流實(shí)例過程描述（workflowInstanceProcessingTable）以環(huán)節(jié)為單位動(dòng)態(tài)描述工作流實(shí)例的處理過程，啟動(dòng)者創(chuàng)建工作流實(shí)例后，提交給工作流引擎后，工作流實(shí)例就根據(jù)工作流定義的流程進(jìn)行運(yùn)轉(zhuǎn)了。包括工作流實(shí)例ID，工作流實(shí)例所對(duì)應(yīng)環(huán)節(jié)（工作流流程就是由一系列的環(huán)節(jié)組成，按照預(yù)定義的流程一個(gè)環(huán)節(jié)過渡到另一個(gè)環(huán)節(jié)），當(dāng)前該環(huán)節(jié)所處狀態(tài)（這標(biāo)識(shí)著該環(huán)節(jié)在處理過程中的狀態(tài)，最終狀態(tài)表示該環(huán)節(jié)的完成狀態(tài)），當(dāng)前操作者（對(duì)應(yīng)的是角色），當(dāng)前狀態(tài)具體描述。⑹ 工作項(xiàng)描述（workItemTable）

動(dòng)態(tài)描述已經(jīng)參與該工作流實(shí)例處理的參與者（對(duì)應(yīng)已處理環(huán)節(jié)的角色的每個(gè)用戶）的工作情況。包括工作項(xiàng)ID（可以定義為以”WorkItem-_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自動(dòng)生成的序號(hào)），工作項(xiàng)名字，工作項(xiàng)描述，工作流實(shí)例ID（該工作項(xiàng)所屬的工作流實(shí)例），該環(huán)節(jié)任務(wù)分派規(guī)則（繼承環(huán)節(jié)的任務(wù)分派規(guī)則，用于判斷該環(huán)節(jié)任務(wù)完成方式），當(dāng)前該工作項(xiàng)所處狀態(tài)（根據(jù)不同的工作流類型有不同的狀態(tài)，根據(jù)這些狀態(tài)可以在參與者接口上顯示不同的工作項(xiàng)列表），執(zhí)行動(dòng)作（記錄執(zhí)行者會(huì)對(duì)該工作項(xiàng)執(zhí)行怎么樣的動(dòng)作，如果是申請(qǐng)事務(wù)則是審批通過或?qū)徟煌ㄟ^），執(zhí)行時(shí)間（記錄該執(zhí)行動(dòng)作的時(shí)間），用戶ID（標(biāo)志該工作項(xiàng)是屬于誰的。⑺

用戶描述（UserTable）

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

描述用戶的工作日志，便于對(duì)各種操作進(jìn)行追蹤。包括日志ID（可以定義為以”Log-_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自動(dòng)生成的序號(hào)）等等，其中有一項(xiàng)是相關(guān)工作項(xiàng)ID，這是當(dāng)參與者對(duì)原始工作項(xiàng)進(jìn)行執(zhí)行操作動(dòng)作時(shí)的工作項(xiàng)。⑼ 角色信息（RoleTable）

描述角色的信息，包括角色I(xiàn)D（可以定義為以”Role__xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自動(dòng)生成的序號(hào)），角色名稱，部門名稱，職位名稱，角色描述。角色由部門和職位組成。

⑽ 部門信息（DepartmentTable）

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

⑾ 職位信息（PositionTable）

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

除了以上這些主要表以外，還有一些我們是在定義工作流模型的時(shí)候才加入數(shù)據(jù)庫的，如對(duì)應(yīng)工作流附件類型為表的表格。為了減少網(wǎng)絡(luò)流量和提高系統(tǒng)的運(yùn)行速度，我們把一些有關(guān)聯(lián)的數(shù)據(jù)庫操作寫成存儲(chǔ)過程：

⑴ 刪除工作流模型存儲(chǔ)過程：刪除一個(gè)工作流模型，必須刪除它的工作流定義主信息，同時(shí)刪除對(duì)應(yīng)的附件信息，附件為表的表格，環(huán)節(jié)信息；

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

3.5 類的設(shè)計(jì)

用面向?qū)ο蟮姆椒ê蚒ML建模工具，再根據(jù)系統(tǒng)結(jié)構(gòu)圖，模塊的劃分和數(shù)據(jù)庫的設(shè)計(jì)，我們把對(duì)象轉(zhuǎn)化成類，進(jìn)行類的設(shè)計(jì)。我們把整個(gè)系統(tǒng)的類分成三部分，一是實(shí)體類，二是業(yè)務(wù)類，三是接口類。

3.5.1 實(shí)體類的設(shè)計(jì)

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

3.5.1.1 數(shù)據(jù)庫訪問類

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

說明：屬性只有一個(gè)connection，它代表數(shù)據(jù)庫的一條連接，類型為Connection，方法有一個(gè)構(gòu)造函數(shù)workflowDAO()和一個(gè)關(guān)閉連接的函數(shù)closeConnection()。WorkflowDAO()實(shí)現(xiàn)從數(shù)據(jù)庫連接池找一個(gè)可用連接并賦值給屬性connection，closeConnection()負(fù)責(zé)把連接放回?cái)?shù)據(jù)庫連接池。

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

說明：構(gòu)造函數(shù)WFDefineMainInfoDAO()調(diào)用父類構(gòu)造函數(shù)，從數(shù)據(jù)庫連接池中找一個(gè)可用的數(shù)據(jù)庫連接（其它數(shù)據(jù)庫訪問類也一樣）。

⑶ 工作流流程信息訪問類：對(duì)應(yīng)工作流流程描述表，該類封裝了對(duì)該表格記錄的各種操作，流程是由若干環(huán)節(jié)組成，就是插入或刪除一條環(huán)節(jié)信息，查詢同屬于一個(gè)流程的環(huán)節(jié)信息等等，類圖如下圖：

說明：findWorkflowFirlstActivityInfo()函數(shù)負(fù)責(zé)找該工作流模型的第一個(gè)環(huán)節(jié)的信息，findWorkflowNextActivityID()負(fù)責(zé)根據(jù)當(dāng)前環(huán)節(jié)ID找下一環(huán)節(jié)的信息。

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

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

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

說明：selectFinishedWorkflowInstanceStartUpInfoVO()負(fù)責(zé)查詢特定用戶啟動(dòng)的并且已經(jīng)完成的工作流信息，selectNotFinishedWorkflowInstanceStartUpInfoVO()負(fù)責(zé)查詢特定用戶啟動(dòng)的并且還沒有完成的工作流信息，updateWFInstFinishedFields()負(fù)責(zé)在工作流實(shí)例結(jié)束時(shí)更新特定的字段信息，updateWFInstProcessingFields()負(fù)責(zé)在工作流實(shí)例運(yùn)行工程中更新特定的字段信息。

⑺ 工作流實(shí)例過程信息訪問類：對(duì)應(yīng)工作流實(shí)例過程信息表，該類封裝了該表格記錄的各種操作，每一條記錄實(shí)際上是一個(gè)環(huán)節(jié)實(shí)例，就是插入、刪除或查詢一條環(huán)節(jié)實(shí)例信息，查詢指定工作流實(shí)例的所有環(huán)節(jié)信息，更新部分信息字段，類圖如下：

說明：SetWFInstProcessingCurrentPerformerNumField()負(fù)責(zé)更新已經(jīng)處理該環(huán)節(jié)實(shí)例對(duì)應(yīng)的工作項(xiàng)的參與該環(huán)節(jié)實(shí)例的用戶數(shù)目，updateWFInstProcessingFields()負(fù)責(zé)在環(huán)節(jié)實(shí)例處理過程中更新特定的字段信息。

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

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

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

說明：selectCountRS()負(fù)責(zé)統(tǒng)計(jì)同屬于一個(gè)角色的用戶數(shù)目。

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

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

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

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

3.5.1.2 值對(duì)象類

值對(duì)象類其實(shí)是一種數(shù)據(jù)結(jié)構(gòu)，用于客戶機(jī)和服務(wù)器之間的數(shù)據(jù)交換，也用于對(duì)象實(shí)例的數(shù)據(jù)傳遞，它有若干屬性，可是很少方法，實(shí)例化后就對(duì)應(yīng)數(shù)據(jù)庫表的一條記錄。

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

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

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

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

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

說明：tableName就是工作流附件類型為表的表格名稱，fieldValue就是對(duì)應(yīng)該表的一條記錄的各個(gè)字段值，用可變長(zhǎng)數(shù)組Vector保存下來。

⑸ 工作流實(shí)例啟動(dòng)信息值對(duì)象類：可以保存工作流實(shí)例啟動(dòng)信息表的一條記錄信息，類圖如下：

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

⑺ 工作項(xiàng)信息值對(duì)象類：可以保存工作項(xiàng)信息表的一條記錄信息，類圖如下：

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

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

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

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

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

⒀ 信息集合值對(duì)象類：可以保存各種信息的一個(gè)集合，當(dāng)需要返回多條記錄信息的時(shí)候可以使用該類，類圖如下：

說明：只有一個(gè)屬性，是一個(gè)可變長(zhǎng)數(shù)組，可以存放不定數(shù)量的記錄信息。3.5.2 業(yè)務(wù)類的設(shè)計(jì)

業(yè)務(wù)類，其實(shí)就是邊界類，它根據(jù)系統(tǒng)的需求按照一定的方式把各個(gè)實(shí)體類聯(lián)系起來，以實(shí)現(xiàn)系統(tǒng)的各種功能。按照實(shí)現(xiàn)功能的不同我們可以分為用戶管理類，角色管理類，部門管理類，職位管理類，工作流模型管理類，工作流實(shí)例管理類，系統(tǒng)監(jiān)控管理類。

⑴ 用戶管理類：負(fù)責(zé)用戶的注冊(cè)，注銷，檢測(cè)合法性，查找用戶信息，類圖如下：

⑵ 角色管理類：負(fù)責(zé)新增加角色，刪除角色，查找角色信息，類圖如下：

⑶ 部門管理類：負(fù)責(zé)新增加部門，刪除部門，查找部門信息，類圖如下：

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

⑸ 工作流模型管理類：負(fù)責(zé)工作流模型的定義，解析，類圖如下：

⑹ 工作流實(shí)例管理類：負(fù)責(zé)工作流實(shí)例的創(chuàng)建，維護(hù)各種實(shí)例的狀態(tài)信息，分派任務(wù)給用戶，用戶處理工作項(xiàng)等等的工作，類圖如下：

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

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

3.5.3 接口類的設(shè)計(jì)

接口類是工作流引擎提供給外部應(yīng)用的類，應(yīng)用系統(tǒng)通過調(diào)用這些類，來實(shí)現(xiàn)一定的應(yīng)用功能。我們?cè)诮涌陬惖脑O(shè)計(jì)上，采取格式統(tǒng)一、隱藏系統(tǒng)復(fù)雜性、功能調(diào)用方便的原則，盡量為外部應(yīng)用系統(tǒng)提供簡(jiǎn)潔、易懂的功能調(diào)用接口。因而我們把這些類都設(shè)計(jì)成只有一個(gè)業(yè)務(wù)類實(shí)例，一個(gè)ToDoWhat()方法的類，并且每一個(gè)業(yè)務(wù)類對(duì)應(yīng)一個(gè)接口類。在這些接口類中，業(yè)務(wù)類實(shí)例作為它的一個(gè)數(shù)據(jù)成員，ToDoWhat()方法有兩個(gè)參數(shù)，toDoCode（工作代碼）和object（數(shù)據(jù)交換對(duì)象），工作代碼表示要調(diào)用的功能的標(biāo)識(shí)，數(shù)據(jù)交換對(duì)象表示功能調(diào)用要處理的數(shù)據(jù)（應(yīng)用數(shù)據(jù)）。從本質(zhì)上來說，就是根據(jù)不同的工作代碼調(diào)用業(yè)務(wù)類實(shí)例的不同方法，對(duì)各種應(yīng)用數(shù)據(jù)進(jìn)行處理。

第四章

系統(tǒng)實(shí)現(xiàn)系統(tǒng)的實(shí)現(xiàn)主要包括關(guān)鍵問題的解決方案和一個(gè)工作流管理應(yīng)用系統(tǒng)的實(shí)踐。首先提出關(guān)鍵問題，然后給出解決方案，最后提出一個(gè)應(yīng)用架構(gòu)，利用J2EE技術(shù)和數(shù)據(jù)庫技術(shù)實(shí)現(xiàn)一個(gè)基于輕量級(jí)工作流引擎的簡(jiǎn)單工作流管理應(yīng)用系統(tǒng)。

4.1 關(guān)鍵問題的解決方案

在實(shí)現(xiàn)工作流引擎的時(shí)候，有一些關(guān)鍵問題，例如啟動(dòng)工作流實(shí)例，推動(dòng)工作流實(shí)例的進(jìn)程，類型為文檔的附件的處理等等，都是要重點(diǎn)解決的。4.1.1 啟動(dòng)工作流實(shí)例

當(dāng)根據(jù)各種業(yè)務(wù)需求創(chuàng)建了對(duì)應(yīng)的工作流模型，根據(jù)結(jié)構(gòu)組織情況創(chuàng)建了組織模型后，用戶就可以創(chuàng)建工作流實(shí)例并啟動(dòng)它。用戶把工作流實(shí)例的信息提交給工作流引擎，那么工作流引擎如何工作呢？工作流引擎其實(shí)做了一系列的工作，其處理過程如下：

⑴ 工作流引擎得到用戶創(chuàng)建的工作流實(shí)例數(shù)據(jù)，記錄在工作流實(shí)例啟動(dòng)信息表中；

⑵ 工作流引擎解析對(duì)應(yīng)該工作流實(shí)例的工作流模型的含義，獲得必要信息提供給工作流實(shí)例使用；

⑶ 工作流引擎根據(jù)這些必要信息找到工作流模型對(duì)應(yīng)流程的第一個(gè)環(huán)節(jié)信息，并生成該工作流實(shí)例的第一個(gè)環(huán)節(jié)實(shí)例，記錄在工作流實(shí)例過程描述表中；

⑷ 工作流引擎根據(jù)任務(wù)分派原則開始把任務(wù)項(xiàng)分派給參與該環(huán)節(jié)實(shí)例的所有用戶；

⑸ 工作流引擎根據(jù)該環(huán)節(jié)定義的參與者角色，找出所有同屬于該角色的所有用戶，為各個(gè)用戶都生成一個(gè)工作項(xiàng)，記錄在工作項(xiàng)信息表中，工作項(xiàng)要繼承該環(huán)節(jié)定義的業(yè)務(wù)規(guī)則，完成任務(wù)的分派；

⑹ 工作流引擎根據(jù)該環(huán)節(jié)定義的業(yè)務(wù)規(guī)則，如果該環(huán)節(jié)是自動(dòng)型的，則為該環(huán)節(jié)的參與用戶分派完任務(wù)后立刻就根據(jù)該環(huán)節(jié)信息去找下一個(gè)環(huán)節(jié)的信息，進(jìn)行下一環(huán)節(jié)實(shí)例的處理；如果該環(huán)節(jié)不是自動(dòng)型的，是需要人工參與處理的，則工作流引擎暫停該工作流實(shí)例的處理工作，等待參與用戶處理的結(jié)果；

⑺ 啟動(dòng)工作流實(shí)例的工作結(jié)束。

4.1.2 推進(jìn)工作流實(shí)例的進(jìn)程

⑴ 如果上一環(huán)節(jié)定義的業(yè)務(wù)規(guī)則是自動(dòng)型的，則立刻根據(jù)當(dāng)前環(huán)節(jié)信息查找下一環(huán)節(jié)；

⑵ 如果上一環(huán)節(jié)定義的業(yè)務(wù)規(guī)則是不是自動(dòng)型的，則等待參與用戶對(duì)各自的工作項(xiàng)進(jìn)行處理，當(dāng)每一個(gè)用戶處理完后，工作流引擎都要判斷該環(huán)節(jié)實(shí)例是否結(jié)束，結(jié)束的條件是業(yè)務(wù)規(guī)則的規(guī)定和用戶的處理結(jié)果。

①

如果業(yè)務(wù)規(guī)則是與聚合，當(dāng)當(dāng)前用戶的處理結(jié)果是非正常處理的話，該環(huán)節(jié)實(shí)例就結(jié)束，并且該工作流實(shí)例也結(jié)束，通知其他還沒處理的用戶該環(huán)節(jié)已經(jīng)結(jié)束，并記錄在相應(yīng)的數(shù)據(jù)庫表中；當(dāng)當(dāng)前用戶的處理結(jié)果是正常處理的話，則再判斷是否所有參與的用戶都處理完畢，如果是則結(jié)束該環(huán)節(jié)，通知其他用戶該環(huán)節(jié)已經(jīng)結(jié)束，并記錄在相應(yīng)的數(shù)據(jù)庫表中，然后查找下一環(huán)節(jié)，如果不是則等待其他還沒處理的用戶的處理結(jié)果。

②

如果業(yè)務(wù)規(guī)則是或聚合，當(dāng)當(dāng)前用戶的處理結(jié)果是正常處理的話，該環(huán)節(jié)的實(shí)例就結(jié)束，并且該工作流實(shí)例也結(jié)束，通知其他參與還沒處理的用戶該環(huán)節(jié)實(shí)例已經(jīng)結(jié)束，記錄在相應(yīng)的數(shù)據(jù)庫表中，然后查找下一環(huán)節(jié)；當(dāng)當(dāng)前用戶的處理結(jié)果是非正常的話，則等待其他還沒處理的用戶的處理結(jié)果。

③

如果業(yè)務(wù)規(guī)則是投票聚合，當(dāng)當(dāng)前用的處理結(jié)果是正常處理的話，則使統(tǒng)計(jì)正常處理結(jié)果的計(jì)數(shù)器加一，然后判斷該統(tǒng)計(jì)數(shù)量是否已經(jīng)達(dá)到規(guī)定的數(shù)量，如果是則結(jié)束該環(huán)節(jié)實(shí)例，并通知其他還沒處理的用戶該環(huán)節(jié)實(shí)例已經(jīng)結(jié)束，記錄在數(shù)據(jù)庫表中，然后查找下一環(huán)節(jié)；當(dāng)當(dāng)前用的處理結(jié)果是非正常處理的話，則不統(tǒng)計(jì)，等待其他還沒處理的用戶的處理結(jié)果。

⑶ 當(dāng)前環(huán)節(jié)實(shí)例結(jié)束后，工作流引擎就找下一環(huán)節(jié)處理，如果沒有下一環(huán)節(jié)，則結(jié)束該工作流實(shí)例，記錄在數(shù)據(jù)庫表中，如果還有環(huán)節(jié)，則同樣生成環(huán)節(jié)實(shí)例，進(jìn)行任務(wù)分派，等待環(huán)節(jié)實(shí)例的結(jié)束。工作流引擎就是這樣推進(jìn)工作流實(shí)例進(jìn)程，從一個(gè)實(shí)例環(huán)節(jié)到下一個(gè)實(shí)例環(huán)節(jié)，直到工作流實(shí)例結(jié)束為止。

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

對(duì)于文檔形式的附件，我們采用上傳文件到服務(wù)器的方法，用戶編輯好文檔后，以規(guī)定的文件名上傳到服務(wù)器中特定的目錄中，當(dāng)用戶要查看該文檔時(shí)，工作流引擎會(huì)根據(jù)該附件文檔對(duì)應(yīng)的信息得到其文件名，用戶根據(jù)該文件名下載到本地中，同時(shí)調(diào)用外部應(yīng)用程序如work2000、記事本打開給用戶瀏覽其內(nèi)容。

4.2 一個(gè)簡(jiǎn)單工作流管理系統(tǒng)的實(shí)現(xiàn)

現(xiàn)在，我們利用J2EE技術(shù)把工作流引擎開發(fā)出來，并基于該引擎做一個(gè)簡(jiǎn)單的應(yīng)用系統(tǒng)，以證明系統(tǒng)設(shè)計(jì)的可行性。我們用Jbuilder9.0做開發(fā)工具，用MS SQLSERVER2000做數(shù)據(jù)庫管理系統(tǒng)。4.2.1 系統(tǒng)應(yīng)用框架

工作流實(shí)例管理器

工作流模型管理器

組織管理器

系統(tǒng)監(jiān)控器

工作流引擎

應(yīng)用服務(wù)器

數(shù)據(jù)庫

Web界面

文檔管理系統(tǒng)

圖4.1 系統(tǒng)應(yīng)用框架

4.2.2 J2EE相關(guān)技術(shù)的應(yīng)用

J2EE為多層Web應(yīng)用系統(tǒng)提供了容器平臺(tái)，用J2EE技術(shù)把工作流管理系統(tǒng)開發(fā)成一個(gè)多層Web應(yīng)用系統(tǒng)，是最合適不過了。

4.2.2.1 J2EE核心模式和類的實(shí)現(xiàn)

模式是特定問題的可重現(xiàn)的解決方案，使用模式有莫大的好處。模式可以權(quán)衡已經(jīng)被證實(shí)的解決方案，為交流提供一個(gè)共同的詞匯，約束解決方案的范圍。J2EE核心模式是在J2EE平臺(tái)上應(yīng)用的模式，它在表示層，業(yè)務(wù)層，集成層都有特定的模式，為基于J2EE平臺(tái)的開發(fā)提供很好的解決方案。對(duì)類的實(shí)現(xiàn)我們采用了J2EE核心模式，主要運(yùn)用的核心模式是業(yè)務(wù)層的ValueObject（值對(duì)象）和集成層的DAO（DataAccessObject，數(shù)據(jù)訪問對(duì)象）。

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

⑵ 數(shù)據(jù)訪問對(duì)象：基于關(guān)系數(shù)據(jù)庫技術(shù)的系統(tǒng)，會(huì)對(duì)數(shù)據(jù)庫進(jìn)行頻繁的訪問，數(shù)據(jù)庫表的眾多，對(duì)某個(gè)表操作的方式的眾多，如果不對(duì)這些表和表的操作方式進(jìn)行必要的歸類，只會(huì)造成模塊聚合度的降低，代碼混亂的后果。我們使用數(shù)據(jù)訪問對(duì)象，來抽象和封裝對(duì)數(shù)據(jù)庫的訪問，所有涉及到數(shù)據(jù)庫訪問的情況都使用數(shù)據(jù)訪問對(duì)象去實(shí)現(xiàn)。工作流對(duì)象的所有數(shù)據(jù)都保存在數(shù)據(jù)庫中，我們?yōu)槊總€(gè)對(duì)象數(shù)據(jù)的數(shù)據(jù)庫操作都封裝在數(shù)據(jù)訪問對(duì)象中，像工作流定義主信息訪問類（WFDefineMainInfoDAO）。4.2.2.2 JavaBean技術(shù)與類的實(shí)現(xiàn)

JavaBean是基于Java技術(shù)的軟件構(gòu)件模型，它是Java語言編寫的可移植的不依賴于平臺(tái)的軟件構(gòu)件模塊。我們把系統(tǒng)所有的類都實(shí)現(xiàn)為一個(gè)一個(gè)的JavaBean，提高類的可重用性，有利于日后的功能擴(kuò)展。另外，JavaBean應(yīng)用到JSP中，可以為JSP應(yīng)用帶來更好的可伸縮性。

4.2.2.3 JBOSS應(yīng)用服務(wù)器和工作流引擎的實(shí)現(xiàn)

應(yīng)用服務(wù)器我們采用JBOSS，這是一個(gè)免費(fèi)的產(chǎn)品，它提供數(shù)據(jù)庫訪問（JDBC）、命名機(jī)制（JNDI）服務(wù)等服務(wù)，支持?jǐn)?shù)據(jù)庫連接池、實(shí)例連接池，這些為我們的工作流引擎的實(shí)現(xiàn)提供了支持，給系統(tǒng)開發(fā)帶來很大的方便。

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

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

MSSQLDS/* 數(shù)據(jù)源名字 */

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

地址，數(shù)據(jù)庫名稱 */

com.microsoft.jdbc.sqlserver.SQLServerDriver /* sqlserver驅(qū)動(dòng) */

workflowUser /* 用戶名稱 */

123456 /* 用戶密碼 */

②

調(diào)用方法（使用JNDI機(jī)制）部分代碼：

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

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

//根據(jù)數(shù)據(jù)源名字查找已經(jīng)配置好的數(shù)據(jù)源

Connection conn = ds.getConnection();

//調(diào)用該方法可以得到對(duì)數(shù)據(jù)庫的一條連接，而這條連接已經(jīng)被JBOSS初始化，實(shí)際上是從數(shù)據(jù)庫連接池中找到一條可用的連接而已，然后通過該連接就可以對(duì)數(shù)據(jù)庫進(jìn)行各種操作，操作完畢后不用顯式關(guān)閉，JBOSS會(huì)自動(dòng)回收該連接，把該連接重新放入連接池中。

⑵ 對(duì)對(duì)象實(shí)例化的支持

當(dāng)系統(tǒng)第一次生成某個(gè)對(duì)象實(shí)例時(shí)，JBOSS就對(duì)該實(shí)例進(jìn)行管理，把該實(shí)例放入實(shí)例池中，并不釋放它，當(dāng)系統(tǒng)再次要生成該實(shí)例時(shí)，不再進(jìn)行該對(duì)象的實(shí)例化，而是JBOSS從實(shí)例池中找到該實(shí)例并提供給系統(tǒng)使用，這明顯提高系統(tǒng)運(yùn)行速度。

⑶ 對(duì)線程的支持

當(dāng)不同的用戶登陸系統(tǒng)，并且對(duì)系統(tǒng)所有功能的使用，JBOSS會(huì)為每個(gè)用戶分配一個(gè)線程去為他們工作，這些線程放入線程池中，JBOSS在運(yùn)行過程中始終對(duì)這個(gè)線程池進(jìn)行管理，提高系統(tǒng)的并發(fā)性能。

4.2.2.4 Jsp/Servlet技術(shù)和系統(tǒng)界面的實(shí)現(xiàn)

JSP技術(shù)可以方便的建立動(dòng)態(tài)Web頁面，提供一個(gè)友好的用戶界面，并且很方便的調(diào)用JavaBean，完成復(fù)雜的業(yè)務(wù)功能；Servlet提供在Web進(jìn)行請(qǐng)求和響應(yīng)服務(wù)的功能，客戶端對(duì)服務(wù)器提供的服務(wù)的所有請(qǐng)求和響應(yīng)都通過Servlet實(shí)現(xiàn)。JSP最終解析為Servlet。

⑴ JSP調(diào)用JavaBean

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

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

?

<%

WFDefineMainInfo wfDefinemaininfo =new WFDefineMainInfo();

? // 填充工作流定義主信息值對(duì)象WFDefineMainInfo 實(shí)例

wfManager.ToDoWhat(0,(Object)wfDefinemaininfo);//調(diào)用接口類的方法，0對(duì)應(yīng)創(chuàng)建工作流主信息的方法代碼

%>

⑵ Servlet請(qǐng)求和響應(yīng)服務(wù) 下面是請(qǐng)求得到表單信息（這些信息就是工作流定義主信息值對(duì)象的內(nèi)容）部分代碼：

<%

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

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

//request就是請(qǐng)求對(duì)象，調(diào)用其方法getParameter()可以得到表單的信息

? //一個(gè)一個(gè)的得到信息

%>

下面是響應(yīng)用戶的部分代碼：

<%

response.sendRedirect(“defineWorkflowModel-mainInfo.jsp”);// response就是響應(yīng)對(duì)象，調(diào)用其方法sendRedirect()向用戶發(fā)送一個(gè)頁面重定向的應(yīng)答。

%>

4.2.3 具體編碼實(shí)現(xiàn)

接下來的工作就是編碼工作，以Jbulider9.0作為開發(fā)工具，以VSS（Microsoft Visual SourceSafe6.0）作為版本控制工具，進(jìn)行代碼編寫，進(jìn)行單元測(cè)試，綜合測(cè)試，最后得到一個(gè)基于輕量級(jí)工作流引擎的簡(jiǎn)單的工作流管理系統(tǒng)。

第五章

系統(tǒng)的不足

本文探討的輕量級(jí)工作流引擎，盡管有很多的優(yōu)點(diǎn)，可是它從夠用、靈活和低成本的設(shè)計(jì)原則出發(fā)，不追求工作流引擎的功能的完備和復(fù)雜，所以存在著一些不足：

⑴ 不支持復(fù)雜業(yè)務(wù)：本文探討的輕量級(jí)工作流引擎是從一般業(yè)務(wù)的需求設(shè)計(jì)工作流模型，我們只實(shí)現(xiàn)了活動(dòng)的單分支，就是組成工作流流程的活動(dòng)是一個(gè)活動(dòng)只有一個(gè)后續(xù)活動(dòng)，而復(fù)雜業(yè)務(wù)可能一個(gè)活動(dòng)后面出現(xiàn)多分支，有多個(gè)后續(xù)活動(dòng)，形成一個(gè)樹型的結(jié)構(gòu)。所以對(duì)復(fù)雜業(yè)務(wù)的不支持是本文探討的工作流引擎的最大的不足。

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

⑶ 不支持提供內(nèi)建（built-in）的應(yīng)用開發(fā)工具，例如是可視化工作流建模工具，F(xiàn)ORM設(shè)計(jì)工具，這些在本文探討的工作流引擎都沒有實(shí)現(xiàn)一定的接口。

⑷ 在定義應(yīng)用數(shù)據(jù)方面不支持所有數(shù)據(jù)類型和完整性維護(hù)，只支持字符型類型和進(jìn)行一些簡(jiǎn)單的數(shù)據(jù)保存工作。

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

⑹ 沒有完善的事務(wù)控制功能。只實(shí)現(xiàn)了一些簡(jiǎn)單的事務(wù)控制，沒有對(duì)復(fù)雜事務(wù)的控制。

第六章

總

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

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

[5] Borland公司著，《Borland Jbuilder實(shí)用技術(shù)手冊(cè)》，電子工業(yè)出版社 [6] 何清法等著，《基于關(guān)系結(jié)構(gòu)的輕量級(jí)工作流引擎》，中國科學(xué)院計(jì)算技術(shù)研究所 [7] Joseph L.Weber著，《Java 2 編程詳解》，電子工業(yè)出版社

本文來自CSDN博客，轉(zhuǎn)載請(qǐng)

標(biāo)

明

出

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

：