李帥　于守建

1 概述

業(yè)務流程變更（Business Progress Change，BPC）[1]是在業(yè)務流程定義階段或執(zhí)行階段出現(xiàn)，相對于原來的流程定義的更改，其需求有的來自于客戶要求、相關法律變更等外因，有的來自于科技更新、追求效率效益等內因，都是為了使系統(tǒng)適應環(huán)境、優(yōu)化流程、提升效率、提高收益。要在流程定義的時候提前考慮到所有可能的業(yè)務流程是非常困難的，而執(zhí)行過程中變更需要業(yè)務人員與專業(yè)技術人員在前期溝通協(xié)調，制定變更計劃?？紤]到流程局部的修改可能牽扯到整個業(yè)務流程的變量配置，故變更時還需等待流程實例全部執(zhí)行完畢或將運行實例臨時撤銷。由此可見，傳統(tǒng)變更方式不僅耗時耗力，還需企業(yè)承擔變更過程中可能導致的數(shù)據(jù)錯誤、信息丟失等風險。

若業(yè)務流程系統(tǒng)能夠在仍有實例運行時的過程定義根據(jù)變更衍生出新的流程定義，并對過程中實例的情況做出反應和處理的能力，那么稱該系統(tǒng)能夠動態(tài)實現(xiàn)變更自適應。傳統(tǒng)業(yè)務流程模型進行數(shù)據(jù)修改、邏輯變更的難度較大，不利于變更自適應技術的實現(xiàn)，而以數(shù)據(jù)為中心的業(yè)務流程模型將底層數(shù)據(jù)提升至流程工單（Artifact）中，修改數(shù)據(jù)簡單易行。本文基于以數(shù)據(jù)為中心的業(yè)務流程模型，提出動態(tài)修改方法，研究了變更自適應技術，設計并實現(xiàn)了變更自適應業(yè)務流程系統(tǒng)。

與傳統(tǒng)變更方法相比，變更自適應技術不僅能夠判斷變更能否自動化完成；并且能快速響應可自適應的變更而無需等待實例執(zhí)行結束；同時自動適應變更內容，在不修改系統(tǒng)的前提下完成業(yè)務流程的變更。

2 國內外相關研究

目前，國內外的學者從不同角度對業(yè)務流程的變更提出了應對方法。

文獻[2]在Petri網模型中用關系矩陣表示節(jié)點路由，用狀態(tài)標識矩陣描述實例狀態(tài)，通過變更處理算法查找可越過節(jié)點和遷移節(jié)點，從而實現(xiàn)業(yè)務流程的及時變更。為了表達活動之間的依賴關系，文獻[3]提出了控制流檢測表（CFC table），用于存儲業(yè)務流程實例的所有可能變化。當執(zhí)行發(fā)生變化時，生成新的CFC table。隨后文獻[4]通過分析新的CFC table中被修改的行，來增加、修改、刪除規(guī)則以及變遷之間的結構一致性。雖然這種方式使得結構一致性有了保障，但卻因CFC table的頻繁更新造成不必要的開銷。文獻[5]在此基礎上提出了基于業(yè)務流程相似性和數(shù)據(jù)類型相容性的適應更變方法。定義內容類型的相容性，通過操作類型檢測表（Operation Type Checking table，OTC table）記錄內容之間的相容性。內容之間的相容性變化不大，更新頻率更低，于是在一致性的基礎上比文獻[4]縮小了開銷。

然而這些研究基于元模型的業(yè)務流程，對流程數(shù)據(jù)的操作需要較大開發(fā)力度。

3 支持變更自適應的業(yè)務流程模型

本文在以Artifact為中心的業(yè)務流程模型（Arti-Flow）[6]的基礎上，對其進行了添加和擴展，引入了版本信息、流程方向圖等概念，提出了一種以數(shù)據(jù)為中心的業(yè)務流程的變更自適應模型（DBPCA， Data-centric Business Process Change Adaptation），為實現(xiàn)業(yè)務流程的動態(tài)性和自適應性提供了基礎。

3.1 DBPCA模型

以數(shù)據(jù)為中心的業(yè)務流程模型具有動態(tài)實例與靜態(tài)模式定義分離的特性、數(shù)據(jù)與活動的隔離特性、實例之間的隔離性以及工單的特性。在這些特性的基礎上，DBPCA模型強調了業(yè)務流程中“任務”及“事件”的邏輯關系，引入版本信息、流程方向圖等概念，為業(yè)務流程變更自適應做了鋪墊。

DBPCA模型是分層結構，由頂層的業(yè)務流程模式、底層的數(shù)據(jù)庫模式以及中間的映射模塊三部分組成。業(yè)務流程模式中包含了流程定義部分、規(guī)則約束部分和各類工單，流程的定義和執(zhí)行受規(guī)則約束的規(guī)范，工單為業(yè)務流程提供各類信息。底層的數(shù)據(jù)庫模式類似ER模型。映射模塊為業(yè)務流程和數(shù)據(jù)庫提供通信機制。工單是一個具體的，可識別的，能夠自描述的信息塊，商業(yè)人員可利用其來運行業(yè)務。工單構成了業(yè)務流程產生和存儲的信息塊，是業(yè)務流程中唯一包含的準確信息，其內部數(shù)據(jù)與數(shù)據(jù)庫數(shù)據(jù)通過映射模塊一一對應。

3.2 版本信息

版本信息是工單內關于業(yè)務流程的主要信息的一個相對簡化的數(shù)據(jù)集，其形式化描述可表示為：

V = （V_ID， VD， L）

其中，V_ID是該版本的版本號（唯一）；VD是工單數(shù)據(jù)的子集，僅包含了工單ID和工單現(xiàn)在的狀態(tài)；L是流程中任務及事件的邏輯關系，可抽象為一個有向無環(huán)圖，稱為流程方向圖。

流程實例內的版本信息V包含L以及實例流程狀態(tài)數(shù)據(jù)，取出這部分信息便于查詢和操作動態(tài)改變執(zhí)行順序自適應變更修改，L是由事件集E內的事件，任務集T內的任務以及其相應關系組成的有向無環(huán)圖，用于決定實例執(zhí)行的前進方向。版本信息是決定一個業(yè)務流程實例前進方向的核心內容。圖1通過實例列舉了一個版本信息內L的數(shù)據(jù)表以及對應的流程方向圖。

3.3 約束定義

文章設定了一系列流程定義時必須滿足且運行和變更時必須遵守的規(guī)則，這些規(guī)則稱為約束[7]。為了保證業(yè)務流程按照定義的方向執(zhí)行，以及應對業(yè)務流程變更時系統(tǒng)的穩(wěn)定性和版本決策的正確性，避免死循環(huán)和不確定性運行結果的產生，以下約束是至關重要的。

1）更新約束。業(yè)務流程變更必須滿足更新約束，若本次變更包含以下沖突，則可能破壞運行方向的唯一性，使得業(yè)務流程產生不確定的結果，那么將禁止本次操作的所有更新。

任務事件沖突集：CT ? E×T 表示一個業(yè)務流程中事件響應引發(fā)某任務執(zhí)行。若兩個任務由一個事件引發(fā)或者說一個事件可由兩個任務響應，則表示這兩個任務存在沖突。

任務順序沖突集：CET?Path（T×T）。Path（ti，tj）表示了兩個任務的執(zhí)行順序關系；存在任務執(zhí)行順序關系使得任務ti執(zhí)行后一定要執(zhí)行任務tj（并非立即執(zhí)行）。若Path（ti，tj）∈CET表示ti與tj兩個任務有執(zhí)行順序上的沖突。即：任務ti執(zhí)行后一定有任務tj執(zhí)行，且任務tj執(zhí)行后有ti執(zhí)行，那么這兩個任務順序執(zhí)行路徑存在沖突。

流程方向沖突：業(yè)務流程由begin事件引發(fā)，并由end事件結束。若路徑由begin事件開始，存在路徑到達事件t（非end事件）且該路徑終止于該事件，則存在流程方向沖突。

2）版本約束。每個業(yè)務實例在某一確定時刻能且只能按照其中一個版本所規(guī)定流程執(zhí)行。

3）隔離約束。每個實例的執(zhí)行都是相互獨立的，實例對應的同類工單數(shù)據(jù)相互之間并無直接訪問聯(lián)系。

4 業(yè)務流程變更自適應系統(tǒng)

在上文提出的DBPCA模型的基礎上，本節(jié)則研究擴展了傳統(tǒng)的業(yè)務流程引擎，設計并實現(xiàn)了支持業(yè)務流程變更自適應的管理平臺，同時詳細分析了動態(tài)修改方法與自適應方法的過程與算法。與傳統(tǒng)的以數(shù)據(jù)為中心的業(yè)務流程管理平臺相比，本文研究具有以下特點：

1）任務與事件的邏輯關系為主要的流程控制手段；

2）業(yè)務流程管理與任務執(zhí)行分離；

3）多業(yè)務流程版本共存；

4）支持業(yè)務流程變更自適應；

5）具有動態(tài)實例的查詢功能。

4.1 系統(tǒng)結構及組成

系統(tǒng)采用Spring MVC框架模式實現(xiàn)，在jBPM業(yè)務流程引擎的基礎結構上增加Artifact的構造模塊以及Artifact與底層數(shù)據(jù)庫的映射綁定模塊，將數(shù)據(jù)提升到業(yè)務流程層面，然后添加規(guī)則驗證模塊和自適應模塊，規(guī)則驗證模塊驗證變更的自適應性，自適應模塊實現(xiàn)業(yè)務流程的動態(tài)自適應機制。以數(shù)據(jù)為中心的業(yè)務流程變更自適應系統(tǒng)體系結構圖如圖2所示：

由圖1所示，系統(tǒng)中各重點構成功能實現(xiàn)可做如下論述。

1）表示層。負責系統(tǒng)與用戶的通信。用戶通過用戶管理模塊、表單管理模塊、流程管理模塊、實例管理模塊完成業(yè)務流程內容、變更業(yè)務流程定義。

2）Web服務器。采用Spring MVC模式，該輕量級框架擴展性強，代碼架構清晰，有利于模塊開發(fā)。

3）業(yè)務流程引擎。為業(yè)務流程服務提供運行環(huán)境，是業(yè)務流程系統(tǒng)的核心，負責解釋過程定義、創(chuàng)建和執(zhí)行過程實例、以及和業(yè)務流程應用及客戶進行通信。本文的業(yè)務流程引擎jBPM是開源的可擴展平臺，具有開發(fā)便利、易擴展、可移植等優(yōu)點。

4）自適應模塊。主要工作包括根據(jù)傳入的流程變更信息修改業(yè)務流程的定義、協(xié)調動態(tài)實例。修改業(yè)務流程的定義主要用于協(xié)調變更前后的定義，修整流程定義，為實例自適應提供基礎。動態(tài)實例的協(xié)調主要是協(xié)調受修改影響的運行時實例，保證這些實例在新模型下能夠正確執(zhí)行。這些處于過渡階段的實例根據(jù)決策或按照舊版本繼續(xù)執(zhí)行，或按新版本執(zhí)行，或按調整后的流程路徑進行執(zhí)行。

5）規(guī)則驗證工具。根據(jù)規(guī)則約束驗證業(yè)務流程定義和修改過程中是否有邏輯矛盾的流程，驗證變更是否具有自適應性。自適應模塊和驗證工具可以使用戶靈活地進行業(yè)務流程修改的定義，保證修改的正確性。

6）Artifact模塊。負責Artifact的定義和結構存儲，將實例數(shù)據(jù)保存至工單，減少與數(shù)據(jù)庫的交互，提高了業(yè)務流程的靈活性。

7）映射模塊。負責Artifact模型與數(shù)據(jù)庫模型的映射，是數(shù)據(jù)持久化操作的保障。

8）實例日志。記錄業(yè)務流程中所有的狀態(tài)變化、事件以及和控制流相關的數(shù)據(jù)等信息。

9）版本信息。為了支持業(yè)務流程的動態(tài)靈活改進及實例自適應，在業(yè)務流程定義被長久修改后，還必須存儲修改前的業(yè)務流程定義信息。

4.2 動態(tài)修改方法

實例內的版本信息包含了定義的業(yè)務流程執(zhí)行方向，所以改變版本信息內的任務對應的前驅事件和產生事件，即可更改業(yè)務流程的運行軌跡，實現(xiàn)動態(tài)變更。業(yè)務流程定義的變更可完全通過工單數(shù)據(jù)的修改由任務與事件的邏輯重組實現(xiàn)。

定義1：業(yè)務流程在原定義任務內容和順序的基礎上產生的任何改變都稱為業(yè)務流程的變更。

原子性的變更操作有三種：添加、刪除、替換。任何變更操作都可由這三種原子性操作組合而成，所以本文只詳細討論這三種原子性操作的動態(tài)修改方法。需要注意的是，原子性操作直接影響了任務與事件的順序邏輯關系，故受事件沖突約束和任務沖突約束的直接規(guī)范，在處理原子性操作的時候必須斷開已更改的任務-事件邏輯關系，以滿足任務事件沖突約束。

4.2.1 添加操作

添加原子操作分為兩種情況，一種是在業(yè)務流程的兩個相鄰任務之間添加任務（L->L_1），一種是在業(yè)務流程的最后一個任務后添加任務（L->L_2）。

添加操作的修改過程如圖3所示，首先要判斷待刪除的任務是否為最后一個任務：

（1）若要在任務Ti，Tj之間添加新的任務Tk，按以下三個步驟：

斷開Tj任務與Ti產生事件的順序關系；

Tk的前驅事件f_event為Ti的產生事件，Tk -> f_event = Ti -> e_event；

Tj的前驅事件為Tk的產生事件，Tj -> f_event = Tk -> e_event；

（2）若添加的新任務Tk在流程的最末，則按以下步驟：

將原最后的任務Tn的產生事件設為新的事件Event_n，斷開事件end與原任務Tn的響應關系，Tn -> e_event = Event_n；

在Tn后添加新事件Tk；

Tk的前驅事件f_event為Tn的產生事件，Tk -> f_event = Tn -> e_event；

4.2.2 刪除操作

企業(yè)的業(yè)務流程中的刪除操作極少出現(xiàn)第一個任務就刪除的情況，故在此主要分析中間任務刪除情況（L->L_1）和最后一個任務的刪除情況（L->L_2）。

刪除操作的修改過程如圖4所示，首先要判斷待刪除的任務是否為最后一個任務：

（1）若要刪除的任務Tk不是最后一個任務，Ti、Tj分別為Tk的前驅、后繼任務，則按以下步驟：

將后者Tj的前驅事件設為前者Ti的產生事件Tj -> f_event = Ti -> e_event；

斷開待刪除任務Tk的前驅事件f_event與Tk的關系，保證任務事件沖突約束；

斷開待刪除任務Tk的產生事件與Tj的關系，保證事件沖突約束；

（2）若刪除新任務Tk在流程的最末，Tn為Tk前一個任務，則按以下步驟：

將Tn的產生事件設為end事件，Tn -> e_event = end；

斷開待刪除任務Tk的前驅事件f_event與Tn的關系；

斷開待刪除任務Tk與end事件的關系，保證任務事件沖突約束；

4.2.3 替換操作

原子的替換操作只需將某個任務及其自帶的產生任務替換為另一個新的任務和產生任務，若替換任務在流程末尾，則直接將任務的產生事件設為end事件。新任務取代了原任務的所有邏輯關系，故替換操作只與前驅事件和產生事件有關，而不干擾其他任務。

替換操作的修改過程如圖5所示，版本信息的修改轉換為流程任務的替換操作分為三個步驟：

1）添加任務Tk，將Tk的前驅事件設為被替換任務Ti的前驅事件；

2）將Tk下一任務Tj的前驅事件設為Tk的產生事件，若無下一任務，則將Tk響應事件設為end事件；

3）斷開被替換任務Ti與Tk前驅事件和完成事件的關系，保證事件沖突約束和任務沖突約束。

4.3 變更自適應方法

在DBPCA模型中，業(yè)務流程的管理與任務執(zhí)行分離，且持久化操作在任務徹底完成后進行，為動態(tài)運行時的變更自適應提供了可行性。本節(jié)提出了變更自適應，將上節(jié)中動態(tài)修改方法生成的變更后流程與原流程協(xié)調，生成方便實例自適應的流程定義，并給出動態(tài)自適應機制實現(xiàn)實例的自適應功能。

用戶接口接收到用戶的變更信息時，會先反饋給引擎調用“中斷”處理機制保存當前數(shù)據(jù)，然后對變更后的業(yè)務流程進行邏輯分析，判斷此次變更是否能夠自適應。若不滿足更新約束，系統(tǒng)將會禁止本次所有更新；若滿足約束，則系統(tǒng)進行流程定義自適應，自適應過程完畢后會發(fā)送一個內部事件到引擎，繼續(xù)動態(tài)實例自適應和新實例的執(zhí)行。

4.3.1 流程定義自適應

圖6展示了變更前流程及目標流程的簡化方向圖，變更起點是兩個方向圖第一個不同的任務，變更終點是兩個方向圖逆序第一個不同的任務。

根據(jù)變更變起點和終點，業(yè)務流程方向圖可以分成三部分：

1）位于變更起點之前的部分為變更前部；

2）位于變更終點之后的部分為變更后部；

3）變更起點和終點之間內是變更區(qū)域。

前兩種情況1）、2）所做修改為：

為原任務添加新的產生事件Event_Vn（n=1，2，..，表示版本號）；

將原任務的后繼任務的驅動事件更改為Event_Vn；

將變更后流程內同任務的后繼任務的驅動事件更改為原任務產生事件Event。

最后處理情況3），變更后部的第一個任務僅需添加新的前驅事件，并設為新版本變更區(qū)域最后一個任務的產生事件。變更自適應后業(yè)務流程方向圖如圖7所示。

修改產生的新流程定義與原定義合并后的業(yè)務流程方向圖如圖7所示，Task_B為變更前驅的第一個任務，滿足情況1），于是添加了新的產生事件Event2_V1，并將原定義的下一個任務Task_C的前驅事件設為Event2_V1，而將新版本的后繼任務Task_D的前驅事件設為Event2。如此，新實例會按照Event2事件為引導執(zhí)行變更后的業(yè)務流程。Task_D屬于情況2），是兩個版本的變更區(qū)域內重復的任務，應與Task_B做同樣修改，保證新實例的運行路徑為由Event4引導的變更后路徑?；诖嗽偬幚硇掳姹咀兏鼌^(qū)域最后一個任務Task_G，將其產生事件設為Task_E（變更后部的第一個任務）的前驅事件。

產生事件和驅動事件的變換可使新產生實例以新流程版本為默認前進方向執(zhí)行。而將變更前后的業(yè)務流程的非變更區(qū)域合并，為后續(xù)業(yè)務流程實例任務的版本選擇工作提供了方便。

4.3.2 動態(tài)實例自適應

由于變更后的流程在變更前部的最后任務添加了一個產生事件，并替換了原產生事件的邏輯關系，由原產生事件承載新的任務邏輯關系，故不需改變實例的產生事件便可按照新流程執(zhí)行。由于當前實例已執(zhí)行的最近任務可能屬于方向圖中三個部分的任一個，相應地，研究即將動態(tài)實例的自適應處理也分三種情況。

1）若已執(zhí)行的最后一個任務在變更前部，則按照新定義的業(yè)務流程執(zhí)行。

2）若已執(zhí)行的最后一個任務在變更后部，由于變更后部的任務流程不受變更影響，故不做修改，扔按照原業(yè)務步驟執(zhí)行。

3）若實例已經執(zhí)行到了變更區(qū)域內的任務，如圖8所示，該實例會根據(jù)實例日志及設定的回退路徑回退到變更區(qū)域開始的地方，再按照新的流程定義重新執(zhí)行。

由于業(yè)務流程中任務的回退受約束規(guī)則以及某些任務不可逆的限制，目前只能由技術人員專門在指定的任務處寫入代碼建立退回的轉移路徑，并不能夠靈活實現(xiàn)任務的任意退回。

在實例自適應的過程中，難免出現(xiàn)異常。異常可能使實例執(zhí)行結果錯誤甚至導致實例的信息丟失。異常情況分為可預見異常與不可預見異常兩種類型。

1）可預見異常。在實例自適應過程中，對執(zhí)行到變更區(qū)域內的實例需要根據(jù)日志數(shù)據(jù)回退。而某些任務是無法回退的，例如向用戶發(fā)送郵件。對于無法回退的任務在處理回退自適應時就會產生異常，這類異常是可以預見的。對可預見異常，技術人員可利用代碼獲取異常實例的相關信息，存入異常實例列表供業(yè)務人員人工處理。

2）不可預見異常。對于不可預見的異常，為了防止其導致流程癱瘓，采取了設置時間閾值和重呼次數(shù)的方法。每個任務會設置一個時間閾值，若超過這個時間閾值仍未響應；則該任務的前置事件重新調用，發(fā)出請求再次執(zhí)行該任務。若請求的次數(shù)超過了設置的重呼次數(shù)，則該實例發(fā)送給用戶接口，交由人工操作解決。

5 結束語

本文的主要研究內容是以數(shù)據(jù)為中心的業(yè)務流程的變更自適應技術。在對以數(shù)據(jù)為中心的業(yè)務流程模型以及業(yè)務流程變更相關技術的研究基礎上，發(fā)現(xiàn)了傳統(tǒng)業(yè)務流程建模方法處理流程變更的不足?；谝陨锨闆r，本文提出了一種以數(shù)據(jù)為中心的業(yè)務流程的變更自適應模型，詳細闡述該模型的架構及組成。提出了動態(tài)修改和變更自適應方法，并在jBPM流程引擎基礎上實現(xiàn)了以數(shù)據(jù)為中心的業(yè)務流程變更自適應系統(tǒng)。該系統(tǒng)已在校工會平臺中成功使用，使“九必訪”審核、幫困申請等流程的管理、變更提高了效率。

然而，本文還存在不足之處需要進一步改進，例如：模型中各約束規(guī)則是保障業(yè)務流程正確運行的關鍵，需進一步地研究完善約束集及約束間的沖突；本文系統(tǒng)目前并不能夠靈活實現(xiàn)任務的任意退回，將完善的回退機制引入，會有效提高易用性。

參考文獻

[1] 張靜樂， 楊揚， 曾明，等. 支持異常處理的柔性業(yè)務流程可信賴性分析[J]. 計算機科學， 2010， 37（4）：41-44.

[2] 劉清華， 李璐璐， 萬立，等. 工作流的動態(tài)變更處理方法[J]. 計算機輔助設計與圖形學學報， 2011， 23（2）：331-338.

[3] ZHANG S， WANG B. The research on decision approach of data dependence in dynamic workflow system[C]//Parallel and Distributed Computing， Applications and Technologies， 2005. PDCAT 2005. Sixth International Conference on. Dalian： IEEE， 2005： 1027-1029.

[4] MEJIA B J F， FALCARIN P， MORISIO M， et al. Dynamic context-aware business process： a rule-based approach supported by pattern identification[C]//Proceedings of the 2010 ACM Symposium on Applied Computing. Sierre： ACM， 2010： 470-474.

[5] 張紅霞， 鄒華， 林榮恒， 等. 基于馬爾科夫決策過程的可適變業(yè)務流程建模及分析[J]. 電子與信息學報， 2013， 35（7）： 1760-1765.

[6] XU W， SU J， YAN Z， et al. An artifact-centric approach to dynamic modification of workflow execution[M]//Robert Meersman. On the Move to Meaningful Internet Systems： OTM 2011. Berlin Heidelberg：Springer ， 2011： 256-273.

[7] SUN Y， SU J. Conformance for DecSerFlow constraints[J]. Lecture Notes in Computer Science， 2014， 8831：139-153.