以數據為中心的業務流程變更自適應技術研究

李帥　于守建

1 概述

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

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

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

2 國內外相關研究

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

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

然而這些研究基于元模型的業務流程，對流程數據的操作需要較大開發力度。

3 支持變更自適應的業務流程模型

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

3.1 DBPCA模型

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

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

3.2 版本信息

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

V = （V_ID， VD， L）

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

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

3.3 約束定義

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

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

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

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

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

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

3）隔離約束。每個實例的執行都是相互獨立的，實例對應的同類工單數據相互之間并無直接訪問聯系。

4 業務流程變更自適應系統

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

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

2）業務流程管理與任務執行分離；

3）多業務流程版本共存；

4）支持業務流程變更自適應；

5）具有動態實例的查詢功能。

4.1 系統結構及組成

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

由圖1所示，系統中各重點構成功能實現可做如下論述。

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

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

3）業務流程引擎。為業務流程服務提供運行環境，是業務流程系統的核心，負責解釋過程定義、創建和執行過程實例、以及和業務流程應用及客戶進行通信。本文的業務流程引擎jBPM是開源的可擴展平臺，具有開發便利、易擴展、可移植等優點。

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

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

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

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

8）實例日志。記錄業務流程中所有的狀態變化、事件以及和控制流相關的數據等信息。

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

4.2 動態修改方法

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

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

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

4.2.1 添加操作

添加原子操作分為兩種情況，一種是在業務流程的兩個相鄰任務之間添加任務（L->L_1），一種是在業務流程的最后一個任務后添加任務（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 刪除操作

企業的業務流程中的刪除操作極少出現第一個任務就刪除的情況，故在此主要分析中間任務刪除情況（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模型中，業務流程的管理與任務執行分離，且持久化操作在任務徹底完成后進行，為動態運行時的變更自適應提供了可行性。本節提出了變更自適應，將上節中動態修改方法生成的變更后流程與原流程協調，生成方便實例自適應的流程定義，并給出動態自適應機制實現實例的自適應功能。

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

4.3.1 流程定義自適應

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

根據變更變起點和終點，業務流程方向圖可以分成三部分：

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

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

3）變更起點和終點之間內是變更區域。

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

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

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

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

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

修改產生的新流程定義與原定義合并后的業務流程方向圖如圖7所示，Task_B為變更前驅的第一個任務，滿足情況1），于是添加了新的產生事件Event2_V1，并將原定義的下一個任務Task_C的前驅事件設為Event2_V1，而將新版本的后繼任務Task_D的前驅事件設為Event2。如此，新實例會按照Event2事件為引導執行變更后的業務流程。Task_D屬于情況2），是兩個版本的變更區域內重復的任務，應與Task_B做同樣修改，保證新實例的運行路徑為由Event4引導的變更后路徑。基于此再處理新版本變更區域最后一個任務Task_G，將其產生事件設為Task_E（變更后部的第一個任務）的前驅事件。

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

4.3.2 動態實例自適應

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

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

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

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

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

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

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

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

5 結束語

本文的主要研究內容是以數據為中心的業務流程的變更自適應技術。在對以數據為中心的業務流程模型以及業務流程變更相關技術的研究基礎上，發現了傳統業務流程建模方法處理流程變更的不足。基于以上情況，本文提出了一種以數據為中心的業務流程的變更自適應模型，詳細闡述該模型的架構及組成。提出了動態修改和變更自適應方法，并在jBPM流程引擎基礎上實現了以數據為中心的業務流程變更自適應系統。該系統已在校工會平臺中成功使用，使“九必訪”審核、幫困申請等流程的管理、變更提高了效率。

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

參考文獻

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

[2] 劉清華， 李璐璐， 萬立，等. 工作流的動態變更處理方法[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] 張紅霞， 鄒華， 林榮恒， 等. 基于馬爾科夫決策過程的可適變業務流程建模及分析[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.