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

背景

工作流產(chǎn)品眾多，而它們之間又缺乏統(tǒng)一的標(biāo)準(zhǔn)，使得不同的產(chǎn)品之間很難實現(xiàn)協(xié)同工作。為了解決這一問題，工作流管理聯(lián)盟（WFMC）于1993 年成立，并提出了工作流參考模型，制定了五個標(biāo)準(zhǔn)接口。

其中有一個接口是過程定義接口。幾乎每個工作流產(chǎn)品都有自己的過程定義語言（也稱為工作流語言），可以從四個方面（控制流、數(shù)據(jù)流、資源、操作）來研究流程，工作流模式（Work Flow Pattern）只是涉及到其中的控制流部分?？刂屏鳎╟ontrol flow）描述了活動在不同結(jié)構(gòu)中的執(zhí)行順序。控制流對我們有效認(rèn)識、理解工作流規(guī)范具有很大幫助。工作流規(guī)范需要不斷地擴(kuò)展，以便滿足新的需求，因此有必要對控制流進(jìn)行基礎(chǔ)的認(rèn)識和分析。1.模式總述

工作流模式系統(tǒng)化地表述了基本的和復(fù)雜的結(jié)構(gòu)。模式（pattern）是從具體形式中抽象出來的。面向?qū)ο蟮脑O(shè)計模式，規(guī)定了不依賴于具體的實現(xiàn)技術(shù)，同時也不依賴于所在領(lǐng)域的基本需求。

Carl Adam Petri基于Petri網(wǎng)原理提出的21個工作流模式，用于工作流過程建模和分析。這些模式，僅限于靜態(tài)控制流，而不考慮資源分配、實例控制、異常處理和事務(wù)管理。

支持工作流模式

過程種類

順序（Sequence）

基礎(chǔ)控制過程

（Basic Control Patterns）

并行分支（Parallel Split）同步（Synchronization）排他選擇（Exclusive Choice）簡單合并（Simple Merge）多路選擇（Multiple Choice）

高級分支和同步過程

多路合并（Multiple Merge）

（Advanced Branching and 同步合并（Synchronizing Merge）Synchronization Patterns）鑒別器（Discriminator）

M中N鑒別（N out of M）

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

（Structural Patterns）多實例過程

（Patterns Involving Multiple Instances）

任意循環(huán)（Arbitrary Cycles）隱式終止（Implicit Termination）非同步多實例（MI-without Sync）在設(shè)計期間預(yù)先確定的多實例（MI with a Priori Design Time Knowledge）

在運行期預(yù)先確定的多實例（MI with a Priori Runtime Knowledge）

無法在運行期預(yù)先確定的多實例（MI without a Priori Runtime Knowledge）

過程狀態(tài)

（State-based patterns）過程取消

（Cancellation Patterns）

1.K2 Blackpearl

K2 Blackpearl 是SourceCode公司基于.NET WF構(gòu)建的流程開發(fā)平臺的核心產(chǎn)品。代碼可支持生成WF代碼，流程設(shè)計環(huán)境使用WPF構(gòu)建，并完全嵌入到VS 2005中，與微軟產(chǎn)品緊密結(jié)合。

K2 blackpearl 包括業(yè)務(wù)流程管理與工作流性能。可以通過建立應(yīng)用來管理業(yè)務(wù)流程并使其自動化，或者集業(yè)務(wù)流程、人員、服務(wù)、信息和系統(tǒng)于單一的應(yīng)用，從而幫助推動業(yè)務(wù)發(fā)展。

1.基礎(chǔ)控制過程

這五個模式的共同點在于：模式所涉及流程的執(zhí)行路徑是在設(shè)計時即可確定的，不需運行時的信息。包括：Sequence（順序模式）、Parallel split（并行分支模式）、Synchronization（同步模式）、Exclusive choice（排他選擇）、Simple merge（簡單合并模式）。順序（Sequence）

?

延期選擇（Deferred Choice）

交叉并行路由(Interleaved Parallel Routing）里程碑（Milestone）取消任務(wù)（Cancel Activity）取消流程（Cancel Case）

描述：

工作流中的各個活動在同一個進(jìn)程中按順序依次執(zhí)行。

? 案例：

“用戶付款”后才能進(jìn)行“發(fā)送貨物”。

? K2實現(xiàn)： 平行拆分（Parallel Split）

?

描述：

工作流中從一個線程中的一個點拆分為在多個線程中平行執(zhí)行的多個活動。這些平行的活動之間沒有關(guān)聯(lián)，執(zhí)行沒有順序關(guān)系。

? 案例：

“用戶付款”后激活了“發(fā)送貨物”以及“通知用戶”的執(zhí)行。

? K2實現(xiàn)：

同步（Synchronization）

?

描述： 在流程中的某個點，多個并行的子流程或者活動，合并成一個流程。流程必須等待所有的分支都執(zhí)行完以后，才能激活后續(xù)活動，這就是“同步”之意。

模式3一般與模式2配合使用。

? 案例：

“發(fā)送貨物”以及“通知用戶”兩個并行活動執(zhí)行完畢后，激活“存檔”活動。

? K2實現(xiàn)：

每個分支維護(hù)自己的完成標(biāo)記，所有Line Rules都設(shè)置成：所有分支均完成。排他選擇（Exclusive Choice）

?

描述：當(dāng)一個活動完成以后，可以有多個分支進(jìn)行選擇，但是只能選擇其中的一個分支，即多選一。

? 案例：“下完訂單”后，可以選擇“銀行卡付款”或者“郵局匯款”，只要選擇一種方式即可。

? K2實現(xiàn) ： 兩個Line Rules的邏輯是互斥的。

簡單合并（Single Merge）

?

描述：

有兩個或多個可選擇的分支，在某一點處合并成一個分支，但并不是同步合并（與模式2的區(qū)別）。與模式4也有點相似，都是“多選一”，但模式4是分散，而模式5 是合并。一般采用“先進(jìn)先出”原則，但是后續(xù)活動只產(chǎn)生一次（如果后續(xù)活動執(zhí)行多次產(chǎn)生多實例，就是模式8）。

模式5一般與模式4配合使用。

? 案例：

無論在何種方式的“付款”之后，進(jìn)行“發(fā)送貨物”。

? K2實現(xiàn)： 每個分支維護(hù)自己的完成標(biāo)記，所有Line Rules都設(shè)置成：有且僅有本分支完成。

1.高級分支與同步模式 多路選則（Multi-choice）

? 描述：

當(dāng)一個活動完成以后，有多個分支進(jìn)行選擇，可以選擇其中的一個或者多個分支，即“多選多”（模式4 選擇是“多選一”模式）。選擇的多個分支可能存在并行執(zhí)行的情況。模式6可以認(rèn)為是模式4的擴(kuò)展。

? 案例

“發(fā)起會簽”之后，可以多種選則會簽方式，但至少要選擇一種。

? K2實現(xiàn)

3個Line Rules的邏輯是獨立的。

同步合并（Synchronize Merge）

? 描述： 在流程中的某個聚合點，多個分支路徑合并成一個路徑。在聚合點，流程會等待所有的分支到來，才能激活后續(xù)的活動。這個模式可以選擇分支路徑，如果只選擇一個分支，實現(xiàn)的功能類似于模式5 簡單聚合模式；如果選擇兩個及以上的分支，實現(xiàn)的功能類似于模式 3 同步模式。

模式7可以認(rèn)為是模式5的擴(kuò)展。模式7一般與模式6配合使用。

? 案例：

要等待所有需要會簽的活動都結(jié)束才進(jìn)入“會簽結(jié)束”，忽略不需要會簽的活動。

? K2實現(xiàn)

每個激活的分支都維護(hù)自己的完成標(biāo)記，Line Rules都設(shè)置為：所有激活的分支均完成。多路合并（Multi-merge）

? 描述：

在流程中多個分支（可能是模式6 多重選擇的一個或多個分支；也可能是模式2 并行中的多個分支），在合并時每個分支執(zhí)行完都會激活后面的活動。與模式5 簡單合并的區(qū)別在于：簡單合并的分支只有一個可執(zhí)行并且后續(xù)活動只激活一次；而多路合并是多個分支可執(zhí)行，后續(xù)活動激活多次。有的工作流引擎不支持。

? 案例：

報銷過程中假如分為住宿費、交通費、飛機(jī)票特殊報銷，每種類型都需要進(jìn)行審批。如果飛機(jī)票的審批比較嚴(yán)格，拖得較久，可能就需要其他的費用先審批通過進(jìn)入下一環(huán)節(jié)。

? K2實現(xiàn)：

無需添加任何的Line Rules。

鑒別器（Discriminator）

? 描述：

在流程中的某個聚合點，等待所有的分支（可能是并行分支，也可能是多重選l 擇分支）中的第一個分支執(zhí)行到達(dá)后，就立刻激活后續(xù)活動。

? 案例：

M個“會簽”活動中只要一個會簽完成就立即進(jìn)入“會簽結(jié)束”。

? K2實現(xiàn)：

“會簽”節(jié)點的Destination Rules 為Create M Slots，Line Rules的邏輯為at least 1 of slots。M中N鑒別模式（N out of M）

? 描述：

在流程中的某個聚合點，等待所有的M 個分支(可能是并行分支，也可能是多多選分支）中的前N 個分支執(zhí)行到達(dá)后，就立刻激活后續(xù)活動。與模式9的區(qū)別在于模式10有N路同步的概念。

? 案例：

M個“會簽”活動中只要N個會簽完成就立即進(jìn)入“會簽結(jié)束”。

? K2實現(xiàn)：

“會簽”節(jié)點的Destination Rules 為Create M Slots，Line Rules的邏輯為at least N of slots。

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

第一章

引

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

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

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

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

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

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

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

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

第二章

工作流管理系統(tǒng)參考模型簡介在闡述工作流引擎之前，我們來了解一下工作流技術(shù)的基本知識。早在幾年前，為了建立工作流管理系統(tǒng)的相關(guān)標(biāo)準(zhǔn)，國際上成立了一個稱為“工作流管理聯(liá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ù)與工作流建模之間的接口，該接口提供的功能包括通信建立，工作流模型操作和工作流模型對象操作。

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

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

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

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

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

第三章

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

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

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

3.1.1 工作流模型的對象

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

3.1.1.1 從一個簡單的業(yè)務(wù)實例看業(yè)務(wù)的需求

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

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

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

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

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

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

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

⑺

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1.1.2 工作流對象的具體分析和說明

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

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

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

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

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

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

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

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

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

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

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

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

●

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

●

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

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

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

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

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

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

●

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

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

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

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

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

設(shè)置

負(fù)責(zé)

組成 組成 資格

組成 部門

職位

用戶

工作組

角色

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

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

工作流定義模型描述了工作流模型的定義信息，包括工作流定義主信息，流程定義信息，環(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)成工作流定義模型。⑶ 工作流實例模型

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

記錄

記錄

細(xì)化

細(xì)化

影響

影響

影響

影響

記錄

記錄

轉(zhuǎn)換條件

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

流程實例信息

工作項信息

工作流實例信息

日志信息

日志信息

細(xì)化

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

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

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

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

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

調(diào)用

依賴

使用

使用角色和工作組

用戶定義

工作流實例模型

外部支持模型

工作流定義模型

組織模型

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

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

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

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

創(chuàng)建

管理員

管理員

管理員

Running（運行）

Completed（結(jié)束）

正常情況

Suspended(掛起)

terminated(終止)

Initial（初始化）

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

提交

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

管理員

管理員

管理員

Running（運行）

Completed（結(jié)束）

正常情況

Suspended(掛起)

terminated(終止)

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

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

處理中

接受

完成正常處理

沒有完成異常處理

回退處理

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

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

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

等待操作

完成 通過

沒有完成 不通過

無操作，超時

操作下一工作項

回退處理

已查看

初始化

未審批

未查看

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

接受

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

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

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

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

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

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

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

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

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

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

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

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

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

●

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

●

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

●

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

●

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

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

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

●

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

●

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

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

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

工作流定義器

工作流

解析器

實例調(diào)度中心

任務(wù)管理器

任務(wù)分派器

啟動控制器

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

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

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

工作流定義接口

工作流實例接口

組織定義

數(shù)據(jù)

組織定義接口

組織定義器

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

組織

管理器

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

用戶描述（UserTable）

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

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

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

⑽ 部門信息（DepartmentTable）

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

⑾ 職位信息（PositionTable）

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

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

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

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

3.5 類的設(shè)計

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

3.5.1 實體類的設(shè)計

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.5.1.2 值對象類

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

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

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

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

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

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

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

⑸ 工作流實例啟動信息值對象類：可以保存工作流實例啟動信息表的一條記錄信息，類圖如下：

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

⑺ 工作項信息值對象類：可以保存工作項信息表的一條記錄信息，類圖如下：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.5.3 接口類的設(shè)計

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

第四章

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

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

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

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

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

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

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

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

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

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

⑺ 啟動工作流實例的工作結(jié)束。

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

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

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

①

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

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

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

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

4.2 一個簡單工作流管理系統(tǒng)的實現(xiàn)

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

工作流實例管理器

工作流模型管理器

組織管理器

系統(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)提供了容器平臺，用J2EE技術(shù)把工作流管理系統(tǒng)開發(fā)成一個多層Web應(yīng)用系統(tǒng)，是最合適不過了。

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

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

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

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

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

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

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

⑴ 對數(shù)據(jù)庫訪問的支持：JBOSS通過對特定數(shù)據(jù)庫管理系統(tǒng)的配置（XML文件），并實例化對數(shù)據(jù)庫的若干連接，放進(jìn)數(shù)據(jù)庫連接池中，提供給系統(tǒng)使用。在JBOSS運行過程中，對這些數(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ū)動 */

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

⑵ 對對象實例化的支持

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

⑶ 對線程的支持

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

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

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

⑴ JSP調(diào)用JavaBean

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

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

?

<%

WFDefineMainInfo wfDefinemaininfo =new WFDefineMainInfo();

? // 填充工作流定義主信息值對象WFDefineMainInfo 實例

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

%>

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

<%

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

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

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

? //一個一個的得到信息

%>

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

<%

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

%>

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

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

第五章

系統(tǒng)的不足

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

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

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

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

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

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

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

第六章

總

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

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

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

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

標(biāo)

明

出

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

：

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

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

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

? 描述：

工作流中的一個點可以讓一個或多個活動反復(fù)的執(zhí)行。

? 案例：

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

? K2實現(xiàn)：

? 12 隱式終止（Implicit Termination）

? 描述：

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

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

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

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

一般都會采用顯示終止，因為隱式終止可能會引起不被察覺的錯誤，例如意外的輸入可能導(dǎo)致流程的結(jié)束。

? 多實例過程

“多實例”是指在流程圖中，一個活動在同一時刻擁有多個可運行的、處于活動狀態(tài)的實例。

? 13 非同步的多實例（Multiple Instances Without Synchronization）

? 描述：

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

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

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

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

? 描述：

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

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

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

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

? 描述：

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

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

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

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

? 描述：

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

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

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

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

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

? 17 延遲選擇（Deferred Choice）

? 描述：

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

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

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

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

? 描述：

一組活動以任意的順序執(zhí)行，每個活動都被執(zhí)行，他們的順序是在運行時決定的，并且在任意一個時刻都不會有兩個活動在執(zhí)行。? 案例：

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

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

? 19 里程碑（Milestone）

? 描述：

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

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

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

? 取消模式

這兩個模式的共同點在于：模式所涉及的流程在運行時disables一個活動或者整個流程，包括：Cancel activity（活動取消模式）、Cancel case（實例取消模式）。? 20 取消活動（Cancel Activity）

? 描述：

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

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

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

? 21 取消實例（Cancel Case）? 描述：

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

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

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

? 其他擴(kuò)展模式

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

第四篇：工作流與信息流

工作流與信息流

工作流（Workflow）就是“業(yè)務(wù)過程的部分或整體在計算機(jī)應(yīng)用環(huán)境下的自動化”，它主要解決的是“使在多個參與者之間按照某種預(yù)定義的規(guī)則傳遞文檔、信息或任務(wù)的過程自動進(jìn)行，從而實現(xiàn)某個預(yù)期的業(yè)務(wù)目標(biāo)，或者促使此目標(biāo)的實現(xiàn)”。

簡單地說，工作流就是一系列相互銜接、自動進(jìn)行的業(yè)務(wù)活動或任務(wù)。一個工作流包括一組任務(wù)（或活動）及它們的相互順序關(guān)系，還包括流程及任務(wù)（或活動）的啟動和終止條件，以及對每個任務(wù)（或活動）的描述。

工作流在大多數(shù)的實際應(yīng)用中的情況可以這樣來簡單地描述：在網(wǎng)絡(luò)、服務(wù)器和多臺計算機(jī)客戶端的硬件平臺上，業(yè)務(wù)過程按照預(yù)先設(shè)定的規(guī)則并借助應(yīng)用程序和人對相關(guān)數(shù)據(jù)的處理而完成。例如，在日常辦公中，當(dāng)撰寫好某份報告之后，可能需要將其提交給領(lǐng)導(dǎo)進(jìn)行審閱或批示；審批意見可能需要匯集并提交給另外一個人，以便對報告進(jìn)行進(jìn)一步的修改。這樣，可能會形成同一篇文檔在多個人之間的順序或同時傳遞。對于這樣的情況，我們可以使用工作流技術(shù)來控制和管理文檔在各個計算機(jī)之間自動傳遞，而非手工傳遞。這就可以稱之為工作流。

類似的關(guān)于文檔的自動化處理只是工作流技術(shù)的一種簡單應(yīng)用。事實上，工作流技術(shù)在現(xiàn)實生活中能夠完成更多更復(fù)雜的任務(wù)。如企業(yè)（或機(jī)構(gòu)）內(nèi)部的各種數(shù)據(jù)或信息的自動處理，多種業(yè)務(wù)流程的整合，企業(yè)（或機(jī)構(gòu)）之間的數(shù)據(jù)交換，借助Internet技術(shù)實現(xiàn)跨地域的數(shù)據(jù)傳輸和處理等等。

一、工作流發(fā)展

工作流技術(shù)起源于二十世紀(jì)七十年代中期辦公自動化領(lǐng)域的研究，由于當(dāng)時計算機(jī)尚未普及，網(wǎng)絡(luò)技術(shù)水平還很低以及理論基礎(chǔ)匱乏，這項新技術(shù)并未取得成功。1983年至1985年間，在圖像處理領(lǐng)域和電子郵件領(lǐng)域出現(xiàn)了早期的含有工作流特征的商用系統(tǒng)。

進(jìn)入九十年代以后，隨著個人計算機(jī)、網(wǎng)絡(luò)技術(shù)的普及和推廣，以及信息化建設(shè)的日益完善，使得工作流技術(shù)的研究與開發(fā)進(jìn)入了一個新的熱潮。1993年8月,第一個工作流技術(shù)標(biāo)準(zhǔn)化的工業(yè)組織——工作流管理聯(lián)盟（Workflow Management Coalition，簡稱WFMC，下同）成立。1994年，工作流管理聯(lián)盟發(fā)布了用于工作流管理系統(tǒng)之間互操作的工作流參考模型，并相繼制定了一系列工業(yè)標(biāo)準(zhǔn)。與此同時，關(guān)于工作流技術(shù)的學(xué)術(shù)研究也十分活躍，許多原型系統(tǒng)在實驗室里開發(fā)出來。進(jìn)入二十一世紀(jì)以來，工作流技術(shù)已被越來越多的人認(rèn)可，與之相關(guān)的標(biāo)準(zhǔn)規(guī)范、工作流引擎及商業(yè)產(chǎn)品不勝枚舉。人們在開發(fā)推廣工作流產(chǎn)品的同時，更加注重工作流的理論研究，以推動該項技術(shù)走向成熟。

二、工作流的特點

1，圖形化、可視化設(shè)計流程圖

2，支持各種復(fù)雜流程

3，組織結(jié)構(gòu)級處理者指定功能

4，B/S結(jié)構(gòu)，純?yōu)g覽器應(yīng)用

5，強大的安全性特色

6，表單功能強大，擴(kuò)展便捷

7，靈活的外出、超時管理策略

8，處理過程可跟蹤、管理

9，豐富的統(tǒng)計、查詢、報表功能

10，與MAIL系統(tǒng)集成三、工作流的優(yōu)點

企業(yè)實施工作流管理所帶來的好處是非常明顯的，這包括提高企業(yè)運營效率、改善企業(yè)資源利用、提高企業(yè)運作的靈活性和適應(yīng)性、提高工作效率、集中精力處理核心業(yè)務(wù)、跟蹤業(yè)務(wù)處理過程、量化考核業(yè)務(wù)處理的效率、減少浪費、增加利潤、充分發(fā)揮現(xiàn)有計算機(jī)網(wǎng)絡(luò)資源的作用。實施工作流將達(dá)到縮短企業(yè)運營周期、改善企業(yè)內(nèi)（外）部流程、優(yōu)化并合理利用資源、減少人為差錯和延誤，提高勞動生產(chǎn)率等目的。

總結(jié)實施工作流帶來的好處，可以歸納為以下幾點：

1，要處理的事項已自動傳遞到個人電腦上

2，不再需要對員工進(jìn)行流程的培訓(xùn)，平滑實現(xiàn)流程變更

3，員工只需將精力集中在處理自己關(guān)心的數(shù)據(jù)上

4，隨時得到歷史數(shù)據(jù)

5，隨時生成處理效率報表

6，達(dá)到無紙化辦公的目標(biāo)

7，完全支持移動辦公，使作業(yè)同步化

8，科學(xué)管理更進(jìn)一層，辦公效率明顯提高

9，企業(yè)的核心競爭力將有提升

10，通過流程自動化與數(shù)據(jù)庫集成，以及各類表單統(tǒng)計查詢功能，提高決策能力

信息流 information flow

信息流是在空間和時間上向同一方向運動中的一組信息，它有共同的信息源和信息接收者，即是由一個分支機(jī)構(gòu)（信息源）向另一個分支機(jī)構(gòu)（地址）傳遞的全部信息的集合。各個信息流組成了企業(yè)的信息網(wǎng)，稱之為企業(yè)的神經(jīng)系統(tǒng)。信息流暢與否，決定著企業(yè)生產(chǎn)經(jīng)營活動是否能正常運行。

信息流是企業(yè)發(fā)展的脈絡(luò)

評價企業(yè)成功與否，一個簡易的辦法是看其物流、工作流和信息流“三流”的情況，其中，信息流的質(zhì)量、速度和覆蓋范圍，尤其可以“映照”企業(yè)的生產(chǎn)、管理和決策等各方面的“成色”。企業(yè)的“生命活動”最終都將以信息流的“高級形式”展現(xiàn)……

評價企業(yè)成功與否，一個簡易的辦法是看其物流、工作流和信息流“三流”的情況，其中，信息流的質(zhì)量、速度和覆蓋范圍，尤其可以“映照”企業(yè)的生產(chǎn)、管理和決策等各方面的“成色”。因為物流、工作流在企業(yè)的“生命活動”中無不最終以信息流的“高級形式”展現(xiàn)，就象生物體的所有活動都是基于神經(jīng)系統(tǒng)傳遞的生物電信號一樣。因此，深入認(rèn)識“信息流”，將掀開企業(yè)發(fā)展的新視角。

如同流動的資金帶來價值一樣，當(dāng)信息不受限制的從一個地點流動到另一地點，幫助企業(yè)實時獲取信息，并促使企業(yè)創(chuàng)造出真正的經(jīng)濟(jì)效益時，才具有最高的價值和意義。其關(guān)鍵,是打造閉環(huán)的信息流。不僅要打破企業(yè)內(nèi)部各種信息孤島，實現(xiàn)數(shù)據(jù)的收集整合、加工分析、信息的傳遞應(yīng)用，以及信息數(shù)據(jù)的再加工、應(yīng)用的反復(fù)“循環(huán)”，還要將企業(yè)內(nèi)部的信息流與企業(yè)外部上下游用戶的需求信息結(jié)合起來，形成“內(nèi)外融合”的閉環(huán)的“大信息流”。這樣認(rèn)識信息流，可以幫助用戶“打開眼界”，審視IT建設(shè)中局部與整體統(tǒng)一規(guī)劃和發(fā)展的問題，即通過集成實現(xiàn)不同層面的信息流同時，也要為建立企業(yè)間高效的信息流打好基礎(chǔ)。

此外，建立全面的信息流也是實現(xiàn)業(yè)界提出的“按需應(yīng)用IT資源”理想的基礎(chǔ)。信息流具有速度、質(zhì)量等特征，反映著企業(yè)的IT基礎(chǔ)水平。信息流速度慢，企業(yè)無法及時獲取所需信息。而系統(tǒng)數(shù)據(jù)不完整或得到不一致數(shù)據(jù)，又將嚴(yán)重影響信息流的質(zhì)量，進(jìn)而影響業(yè)務(wù)系統(tǒng)的成敗。只有高質(zhì)量的信息數(shù)據(jù)不受任何限制平穩(wěn)地流向所需位置，才能最終實現(xiàn)按需應(yīng)用的理想。這對企業(yè)各層系統(tǒng)的無縫集成提出了更高的要求。為此，建立豐富的實施信息流的技術(shù)方案體系，包括數(shù)據(jù)層集成、應(yīng)用層集成、垂直業(yè)務(wù)處理層集成、發(fā)布層集成以及通用建模和開發(fā)工具的應(yīng)用?！靶畔⒘鳌笔瞧髽I(yè)發(fā)展的基本脈絡(luò)。

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

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

2002-10-30 13:15

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

引言

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

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

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

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

集成方案的確定

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

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

同時提供OA和ERP解決方案的供應(yīng)商，其產(chǎn)品在設(shè)計階段就考慮到了兩個系統(tǒng)的集成。但是目前這樣的方案往往是供應(yīng)商出于市場份額的考慮而提供的，由于開發(fā)規(guī)模、成本和周期的限制，所提供的ERP－OA一體化方案的功能往往比較簡單，不能滿足企業(yè)個性化的需求。而且，ERP系統(tǒng)在企業(yè)內(nèi)運行一段時間后，更換新的系統(tǒng)，會面臨新舊系統(tǒng)間數(shù)據(jù)移植的巨大工作量、用戶不愿意舍棄熟悉的界面和高昂的費用等困難。所以這個方案只能被未實施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ù)庫，存儲定期從ERP系統(tǒng)中按照字段映射過來的靜態(tài)數(shù)據(jù)，作為OA系統(tǒng)組織和資源定義的依據(jù)。OA系統(tǒng)中的表單鑒審后可以通過ERP系統(tǒng)的Interface table寫入ERP系統(tǒng)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.ERP系統(tǒng)將保存成功的單據(jù)編號和單據(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ù)此將工作流表單和附件傳送到下一個執(zhí)行者。

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

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

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

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

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

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

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

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

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

2．采購流程。采購申請、審核、采購申請匯總、分單驗收、入庫流程；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

對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)一，因為在ERP系統(tǒng)中用戶名和角色、權(quán)限是對應(yīng)的。但口令不能統(tǒng)一，登錄ERP系統(tǒng)時，系統(tǒng)仍然會提示用戶輸入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客戶端軟件。

兩個服務(wù)器通過TCP/IP協(xié)議連接。在Workflow Server上安裝InterSoft公司編制的共享軟件NetTerm 4.3.0簡體中文版，可以在10個以上的操作系統(tǒng)上運行，對遠(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對應(yīng)的地址和內(nèi)容。

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

應(yīng)用情況

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