.net工作流引擎设计(三):WorkFlowEngine工作流引擎设计

a.    工作流引擎只负责处理与流程运转相关事宜，处理过程的解释執行、流轉規則，控制任務管理器。架構在工作流引擎之上的web應用的具體業務處理另外編寫，以保持工作流引擎的獨立性和簡潔性。

b.    通過此設計方案設計的工作流引擎，只負責業務系統流程的流轉，業務系統使用此工作流引擎需要根據業務系統的需要來評估使用性以及考慮業務邏輯的具體實現，不能依靠工作流引擎來實現所有的業務功能。

c.    此階段在業務系統中需要控制表單控件的訪問權限時需要業務系統結合工作流來自行進行控制，在之後的工作流引擎功能擴展第二階段可以設計通過工作流引擎來控制表單中控件的訪問權限。

d.    此階段流程定義採用程式來定義和維護，不使用圖形化的建模工作。在工作流平臺的進一步深入開發的第三階段再進行流程定義工具的開發。

.1工作流定義

根據WFMC的定義，工作流(Workflow)就是自動運作的業務流程部份或整體，表現為參與者對文件、信息或任務按照規程採取行動，并令其在參與者之間傳遞。簡單的說，工作流就是一系列相互銜接、自動進行的業務活動或任務。如果將整個業務流程看作是一條河，其中流過的就是工作流。使用工作流作為業務流程的實現技術首先要求工作流系統能夠反映業務流程的以下幾個問題，即業務流程是什麽(由哪些活動、任務組成，也就是結構上的定義)、怎麼做(活動間的執行條件、規則以及所交互的信息，也就是控制流與信息流的定義)、由誰來做(人或計算機應用程序，也就是組織角色的定義)、做的怎麼樣(通過工作流管理系統對執行流程進行監控)。

工作流參考模型

工作流管理系統功能

通常，工作流管理系統是指運行在一個或多個工作流引擎上用於定義、實現和管理工作流運行的一套軟件系統，它與工作流執行者(人、應用)交互，推進工作流實例的執行，并監控工作流的運行狀態。雖然不同的工作流管理系統具有不同的應用範圍和不同的實施方式，但它們具有很多共同的特性。概括地說，工作流管理系統提供了3種功能。

(1). 建立階段的功能：主要考慮工作流流程和相關活動的定義和建模功能。

(2). 運行階段的控制功能：在一定的運行環境下，執行工作流工程，并完成每個流程中活動的排序和調度功能。

(3). 運行階段的人機交互功能：實現各種活動執行流程中用戶與IT應用工具之間的交互。

.2.2 工作流實現模型

a. 流程定義：

創建計算機可處理的業務流程描述。規定用戶間信息傳輸的一組路由命令。

b. 組織/角色模型：包含了組織結構和組織中角色的信息。這些信息往往與流程定義信息緊密相關。

c. 工作流執行系統和工作流引擎：

工作流執行系統也稱業務流程執行環境，包括一個或多個工作流引擎。工作流引擎是WMS的核心。它功能包括：解釋流程定義；創建流程實例并控制其執行；調度各項活動；為用戶工作表添加工作項；通過應用程序接口(API)調用應用程序；提供監督和管理功能等。

d. 工作流控制數據：

被工作流執行系統和工作流引擎管理的系統數據，如工作流實例的狀態信息、每一活動的狀態信息等。

e. 工作流相關數據：

指與業務流程相關的數據。WFMS使用這些數據確定工作流實例的狀態轉移，例如流程調度決策數據、活動間的傳輸數據等。工作流相關數據既可被工作流引擎使用，也可以被應用程序調用。

f. 工作列表：

流程執行中，當需要用戶的交互時，工作流引擎便將工作項放置到由worklist 管理的工作列表中，通過worklist 實現與用戶的交互。

g. 應用程序和應用數據：應用程序可以直接被WFMS調用或通過應用程序代理被間接調用。通過應用程序調用，WFMS部份或完全自動完成一個活動，或者對業務參與者的工作提供支持。與工作流控制數據和相關數據不同，應用數據對應用程序來講是局部數據，對WFMS的其他部件來說是不可見的。

.3工作流模型規範

WFMC的工作流流程語言包括6個基本實體：

工作流定義：反映一個業務流程的目的。

活動：對應業務流程中的任務，主要反映了完成該業務流程需要執行的哪些功能操作。

轉換條件：負責為流程實例提供導航依據，對應于一個業務流程中的業務規則和操作順序。

工作流相關數據：是引擎執行任務推進的依據之一，引擎根據相關數據和轉換條件執行後續活動。

角色：角色或組織實體決定了參與某個活動的人員或組織單元，描述了業務流程中參與的操作人員和組織單位。

應用程序：描述了用於完成業務流程所採用的外部工具或工具。

活動是流程定義的核心部份。一個流程包括若干活動組成；特定的角色參與活動的執行；活動執行流程中使用工作流相關數據，激活特定外部應用程序；流程實例的推進是根據轉換條件和工作流相關數據進行的。

工作流模型元模型實體

控制模型

單一角色、順序流程

一個角色有4個業務活動，(開始、結束也算活動類型之一，但這裡為符合日常習慣，特意避開，下同)：

1. 設計一個流程；
2. 設計6個活動，start類型1個；end類型1個；人工類型4個，都把活動參與者映射給”主管”；
3. 不需要設計流程相關參數
4. 為每個活動設計活動變遷，這樣，活動間的前趨，後續的關係就建立了；
5. 不需要為活動變遷設定變遷條件；

多角色、順序流程

1. 設計一個流程；

2. 設計6個活動，start類型1個；end類型1個；人工類型4個，活動參與者分別映射不同的角色；

        3. 不需要設計流程相關參數；

        4. 為每個活動設計活動變遷；

        5. 不需要為活動變遷設定變遷條件；

類型分支流程

1. 設計一個流程；

2. 設計8個活動，start類型1個；end類型1個；and-split活動1個；and-join活動1個；人工類型4個，活動參與者分別映射給不同的角色；

        3. 不需要設計流程相關參數；

        4. 為每個活動設計活動變遷；

        5. 不需要為活動變遷設定變遷條件；

        在and-join路由活動中，應該會出現某個參與者等待的情況，活動4的執行必須等待and-join的完成；而and-join的完成，需要活動2和活動3都為”完成狀態”。

.4 or 類型分支流程

1. 設計一個流程；

2. 設計8個活動，start類型1個；end類型1個；and-split活動1個；and-join活動1個；人工類型4個，活動參與者分別映射給不同的角色；

3. 設計流程相關參數do_man:string類型；操作符號為=;標示必須相等，才能執行後續任務；

4. 為每個活動設計活動變遷；

5. 不需要為活動變遷設定變遷條件；

在or-split路由活動中， 系統根據用戶的輸入來決定後續活動的路徑。該路由活動狀態由”not_start”->”running”；如果決定了後續活動；設置該路由活動狀態為”完成”，同時把後續活動狀態的”not_start”->”waiting”。

該流程包括了1個and發散和1個or發散。在實現上，or發散可以模擬出循環的效果。

1.      設計一個流程；

2.      4個參與者

3.      1個開始活動；1個end活動；3個路由活動；6個人工活動；

4.      1個流程相關變量is_ok:string類型；等於操作符；

5.      1個條件變遷；

在and-split活動后，同時啟動開發2，開發3活動；到了and-join活動，系統會在這裡等待，直到兩個活動都執行完畢。完畢后啟動開發4；在or-split出，系統等待用戶輸入，根據用戶的輸入來決定後續的活動，是完成該開發流程還是繼續迭代。

就是前面順序、and類型、or類型節點的組合。

在上一章里，我们谈到了工作流的控制模式，控制模式强调的是对业务流程进行建模，业务流程的目标是实现一个商业目标或者管理目标，业务流程的执行往往由一系列的任务所构成，控制模式建模的实质在于合理调配这些任务，以期以最少的成本达到最大的收益。本章将介绍工作流的资源模式，如果说控制模式更为宏观，强调的是业务流程里各个任务的合理调配的话，那么资源模式则深入细节，将要讨论单个具体任务的执行情况。提到任务的执行，那么谁能执行这些任务呢。答案很直接，是人。不管是在公司企业还是政府里，人都是最重要的资源，除去人之外，还有其他的非人力资源，例如机器、设备、计算机等。探讨这些资源如何执行业务流程中的具体任务，如何调配这些资源即构成了本章的内容，即资源模式。

4.   工作流管理系統的設計

.1總體設計

.2工作流系統用例圖

.3流程狀態轉變圖

a. 初始(inactive)：一個流程實例已經生成，但該流程實例并沒有滿足開始執行的條件；

b. 運行中(running)：一個或多個活動已經開始執行(已經生成一個工作項并分配給了合適的活動實例)；

c. 掛起(suspended)：該流程實例正在運行，但出於靜止狀態，除非有一個”重啟”的命令使該流程實例回到準備運行狀態，否則所有的活動都不會執行；

d. 結束(completed)：該流程實例滿足結束的條件，工作流管理系統將執行流程實例結束后的操作；

e. 終止(terminated)：該流程實例在正常結束前被迫終止；

流程在設計中，不涉及到狀態，就是說保存在模型庫中的流程表，不需要設置狀態欄位。

a.       一旦流程被實例化，該流程的狀態被設置為”初始(inactive)”,并保存在數據庫中。

b.      如果用戶此時進入自己的工作列別，啟動了第一個活動實例，狀態由”初始(inactive)->運行中(running)”。

c.       可以在monitor中把流程實例的狀態設置從”運行中(running)->掛起(suspended)”，那與該流程實例相關聯的活動實例都要設置為”掛起(suspended)”,活動實例并被設置為不能使用，直到流程實例的狀態被恢復成”運行中(running)”。

d.      可以在monitor中把流程實例的狀態強迫設置從”運行中(running)->終止(terminated)”，那與該流程實例相關聯的活動實例都要作不可恢復的刪除；流程實例不刪除(保存在數據庫中)，但設置”終止(terminated)”狀態。

e.       流程實例下所有的活動實例運行完畢，判斷is_end_act()為true,設置流程實例的狀態為：”運行中(running)->結束(completed)”。流程實例不刪除(保存在數據庫中)，但設置”結束(completed)”狀態。

.4活動狀態轉變圖

a.       在流程實例啟動時，設置流程實例狀態為”初始(inactive)”，與之相關的所有活動實例的狀態都設置為”沒有啟動(not_started)”。

b.      找到流程實例第一個活動(start)類型，并把第一個活動設置為”完成(completed)”，找到下一個活動實例，設置為”就緒等待(waiting)”。

c.       用戶登錄自己任務管理器，得到屬於自己的”waiting”任務，選擇任務處置，完成后點接受，該活動實例狀態從”waiting”直接越過”running”->”完成(completed)”。

d.      可以monitor頁面設置某個活動掛起，或終止，則應該活動實例不再出現在用戶的任務列表上。掛起為可恢復流程，而終止為不可逆流程。

e.       當前活動實例為”and_jion類型”，而標識位屬于路徑沒有全部到達時，把當前活動實例設置為”pending”；當標誌位為全部到達時，狀態由”pending”直接越過”running”,到達”completed”。

流程和活動狀態轉變及相互影響圖

.6流程初始化流程圖

.7活動執行流程圖

5.   與業務流程的結合

.1整合方法

通常工作流系统在设计之初，都会明确的区分流程数据和业务数据。工作流引擎只关心流程数据，为实现工作流的流转，会为工作流引擎设计一套工作流的表结构，来辅助流程引擎的实现。

业务数据是千变万化的，为实现各自的业务，会设计一系列业务表。业务表，工作流系统是不关心的。 但是工作流数据和业务数据又是交互的关联的。为了将业务数据和流程数据关联起来，会有一个关联表，将流程实例和业务数据关联。

.2參與者執行流程

1. 流程设计者

2. 普通用户

3. 流程监控者

.3執行流程概述

1. 工作流管理人員設計工作流流程模型，并保存到模型庫中；

2. 該工作流流程模型被調用，被工作流引擎解釋執行；

3. 引擎根據流程模型中定義的規則，調用某個活動；

4. 該活動是一個人工活動，比如是<<員工出差申請單>>，該頁面已經製作完畢，上面有相應的欄位需要員工填寫，并提交。該頁面的邏輯處理自行處理，對於引擎來說，它只需要url地址和附件的參數。該頁面的url存儲在活動表中的”業務地址”欄位中，附加的參數存儲在活動表中的該活動的業務附加變量中。整個業務名稱由”業務邏輯名稱”來表示。需要人工完成該活動時，由工作流引擎把與活動綁定的頁面地址分配給某個用戶，用戶直接點擊該url，就可以出現該頁面，用戶可以在上面作相應的處理，處理完畢，通知工作流引擎；

5. 與該活動綁定的頁面地址由工作流引擎發到任務管理器，在頁面地址后附加需要的參數，工作流引擎希望通過url來傳遞變量；

6. 通過組織模型來確定該活動具體有哪個用來執行，并經過訪問控制模塊的檢查和過濾，最後發到特定人員的任務列表中；

7. 用戶操作完畢后，通知工作流引擎，該活動完成，工作流引擎根據流程模型執行後續的活動；

流程設計者操作業務模型

a. 創建參與者：具體參與者可點”選擇用戶”，進入用戶選擇頁面。

b. 創建流程

c. 創建相關數據(如果沒有，就不需要創建，直接到創建活動的步驟)：相關數據是在活動變遷條件中用到。

d. 創建活動：創建完活動，才能創建活動變遷和變遷條件。其中變遷條件的變量來自相關數據中的設定。

e.創建活動變遷，以及變遷條件

a.       啟動流程

b. 業務處理

流程監控者操作業務模型

表单的权限控管

在工作流系統中，經常會有對表單訪問權限的要求，比如在不同的站別有的是可以修改，有的是只讀，有的是只能訪問其中的欄位。本設計方案可以通過流程環節的權限控制和表單的權限控制來達到不同環節表單的訪問權限。

方法：通過程式來維護每個流程以及各個環節對應業務表單的訪問權限。

UIS系統中已經實現設定不同角色對表單的訪問權限，如下：

在此基礎上，再綁定流程和活動節點即可。業務系統表單中根據從工作流系統傳遞來的流程和活動的編號即可判斷對應的訪問權限。

流程的版本控制

在工作流系統中，流程的版本控制非常重要，所以本方案中也有流程的版本控制。在流程的定義中有流程版本信息，在維護流程信息時候，會隨著流程信息的修改產生新版的流程，多個版本的流程中只能有一個處於生效狀態，用戶可以自主選擇使用哪個版本的流程作為當前運行的流程。

異常處理

發生異常時可以通過人工和自動兩種方式來處理異常，在定義活動節點的時候指定在此處發生異常后，應該採取什麽樣的方式來處理異常。人工方式處理下，如果發生異常，系統會通知此節點的負責人處理發生的異常，之後再恢復流程繼續執行。自動處理包括忽略和定義發生特定的異常對應的處理方法。

的设计

工作流引擎的“本职工作”就是按照流程定义的流转逻辑驱动流程实例一个环节一个环节地往下执行。正是由于工作流引擎的工作很“简单”，所以工作流子系统和业务子系统才存在着很多的接口，做好了这些接口的话，工作流引擎才展现其扩展性。如果工作流引擎把很多事情包办了，我觉得它反而没有什么价值了。

虽然说工作流引擎的职责用一句话就说清楚了，但是它的实现并不是很简单。引擎本身

需要完成如下工作。

a.    流程的定義

b.    正確的流轉算法

c.    流程實例各種中間狀態的轉化和持久化

d.    流轉條件的解析

e.    流程版本的管理

f.      流程權限的分配

g.    創建流轉過程中需要用到的service

h.    流程引擎對外的API

總體結構

最后

以上就是真实曲奇为你收集整理的.net工作流引擎设计(三):WorkFlowEngine工作流引擎设计的全部内容，希望文章能够帮你解决.net工作流引擎设计(三):WorkFlowEngine工作流引擎设计所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。