王 健,董廣智,柳軍飛
(北京師范大學 信息科學與技術學院,北京100875)
為了快速應對市場變化的需求,越來越多的企業已經認識到業務流程的重要性。業務流程管理(business process management,BPM)是一種以規范化構建端到端的卓越的業務流程為中心,以持續提高組織業務績效為目的的系統化方法[1]。BPM通過業務流程建模來提取企業的關鍵業務,并對業務之間的聯系,以及業務與人的聯系進行描述,由流程引擎來對所建立的流程模型進行解析、執行,采取自動或半自動的方式完成整個業務。業務流程建模實現了對企業關鍵業務的抽象描述,是實現業務流程管理的基礎。近年來,針對不同的業務層次很多流程定義語言被提出 來, 例 如 BPMN(business process modeling notation)[2-3],UML 2.0Activity Diagrams[4-5],BPEL(business process execution language)[6-7]。這些語言中都包含對事件的定義,并通過事件來觸發流程的初始化或推進流程實例[8]。事件在流程中是一個寬泛的概念,活動的開始、活動的結束、文檔狀態的變化、消息的到達等都可以是事件。然而這些建模語言中對于事件的劃分都是根據不同的類型,例如BPMN2.0中的事件種類就分為消息、計時器、信號、錯誤等。這樣劃分的不足有:
(1)按類型的劃分使得事件的種類過于繁多,建立的流程模型也會過于復雜;
(2)這些簡單事件不足以描述完整的業務流程,很多復雜事件沒有被描述[9]。
所以本文提出了一種基于復雜事件處理的業務流程建模語言(CE-BPM),將事件按不同的來源分為3層,不僅減少了事件的種類,簡化了業務流程模型,而且支持復雜事件處理,更加完整的描述了業務流程。本文第2節介紹了BPMN的基本元素和復雜事件處理(CEP)的基本原理。在第3節中,提出了事件分層模型,將業務流程中的事件分為0、1、2這3層,并給出了CE-BPM的形式化描述和圖形化表示。第四節通過一個購物網站的流程實例,提出了用BPMN2.0建模時可能遇到的問題,并通過CE-BPM方法,方便的解決了實例中提到的問題。最后,對支持復雜事件處理的業務流程建模進行了總結,并提出了下一步的工作方向。
在眾多現有的流程建模語言中,BPMN 2.0由于既融合了UML的面向對象的設計思想、圖像化設計思想以及Petri網思想,又可以方便的映射到業務流程執行語言(BPEL),已經成為業務流程建模的一個標準[10]。BPMN 2.0中有5個基本的元素類別,包括:流對象(flow objects),數據(data),連接對象(connecting objects),泳道(swim lanes),人工制品(artifacts)。
(1)流對象是業務流程模型中主要的圖形元素,用于定義業務流程的行為。包括3種元素:事件、活動、網關。
(2)數據包括5種元素:數據對象、數據輸入、數據輸出、數據存儲、屬性。
(3)連接對象將流對象連接起來形成一個業務流程的基本結構,包括4種元素:順序流、消息流、關聯、數據關聯。
(4)泳道將活動劃分到不同的可視化類別中來描述不同的參與者的責任與職責,包括兩種元素:池、道。
(5)人工制品用于添加流程備注,便于流程閱讀者理解,預定義了兩種人工信息:組、注釋。
事件是一個很廣泛的概念,通常意義上指有值得注意的事發生了[11]。比如一次金融交易的完成,一個重要時刻的到來等等。事件可以觸發活動的執行,它可以在某個既定狀態下發生,可以在活動執行過程中產生,也可以是因為某些條件被滿足時產生。在業務流程領域內,事件被定義為 “狀態的一次有意義的改變”,比如一個文件的提交,一個故障或錯誤的產生等。
復雜事件處理(complex event processing)技術是20世紀90年代由斯坦福大學的David Luckham提出的,使用模式比對、事件的相互關系、事件間的聚合關系,從事件云(event cloud)中找出有意義的事件[12],如圖1所示。
復雜事件處理技術模擬的是人從現實世界中獲取信息進行判斷推理的思維過程。這些信息包括事物實體的狀態信息,實體之間的作用和動作信息,這里統稱為事件。這些事件組成事件云,我們從事件云中提取事件,并對這些事件過濾,只保留有意義的事件,同時轉化成統一的事件格式,然后通過事件模式匹配將事件與規則庫中的事件模式進行匹配[13],分析事件間的成員關系、時間關系、因果關系以及包含關系等,抽象低層次的事件到高層次的事件,組合局部的事件成整體的事件,然后對這些事件進行匹配,判斷以及推理,用來實現判斷,查找原因,決策和預測的功能。
圖1 復雜事件處理
在BPMN中,對于事件的描述都是按照不同的類型進行分類的,通常一個流程中就包含多種不同的事件[14],這些事件可以是內部事件,也可以是外部事件,比如:消息事件、計時器事件、錯誤事件、取消事件等。在現實業務流程中,一個消息事件可能是基本事件,也可能是由幾個基本事件得到的復雜事件,也可能是由基本事件和復雜事件共同得到的復雜事件。所以,采用事件分層的方法來表達業務流程中的事件更加符合實際要求。下面給出事件分層的依據,如圖2所示。
圖2 事件分層模型
(1)從業務流程中能直接得到的原子事件為0層事件;
(2)通過對0層事件云進行過濾、模式匹配得到的復雜事件為1層事件;
(3)通過對0層和1層復合事件云,或者1層事件云進行過濾、模式匹配得到的復雜事件為2層事件。
根據對BPMN 2.0的描述,可以把BPMN2.0的流程模型表示為一個五元組。
定 義 1 BPMN=(Flows,Connectors,Datas,Swimlanes,Artifacts),其中:
(1)Flows是流對象集合,Flows=(Activities,Gateways,Events),其中 Activities表示活動的集合,Gate-ways表示網關的集合,Events表示事件的集合;
(2)Connectors是連接對象集合;
(3)Datas是數據集合;
(4)Swimlanes是泳道集合;
(5)Artifacts是人工制品集合。
定義2 e表示業務流程中的事件,是一個五元組,e=(type,source,flag,time,attribute),5個基本事件變量分別表示事件類型、事件源、事件標識符、事件時間戳和事件屬性,其中attribute是事件的屬性集合,集合元素是屬性名到屬性值的映射。
BPMN中的事件集合只是對簡單事件的描述,即只包括0層事件,沒有對復雜事件進行描述,表達的流程模型不夠豐富,所以在CE-BPM中加入復雜事件的元素,用一個六元組來表示業務流程。
定義 3 CE-BPM=(CFlows,Connectors,Datas,Swimlanes, Artifacts, Rules ), Connectors、 Datas、Swimlanes、Artifacts與定義1中相同,其中:
(1)Rules是事件規則集;
(2)CFlows是支持復雜事件的流對象,CFlows=(Activities,CGateways,CEvents),其中 CEvents是包含復雜事件的事件集,CGateways是包含復雜事件處理網關的網關集。業務流程中包含很多復雜事件,這些復雜事件都是由若干底層事件的發生而引起的,底層事件在何種情況下產生復雜事件是由事件規則定義的。
定義4 Rules是一個事件規則集,Rules={r|IF r(e01,e02,…,e0m)THEN e,e,e01,e02,…,e0m∈CEvents},其中,r(e01,e02,…,e0m)是事件表達式,由內外兩層組成:
(1)內層是屬性運算,由關鍵字where引出,通常用于對事件的約束,例如e(where attr=v)表示事件e的屬性attr的值為v,其中v是常量。e(where attr>e1.attr)表示事件e的屬性attr的值大于事件e1的屬性attr。
(2)外層是事件運算,事件間的基本操作符如表1所示[15]。
表1 事件運算符
定義5 CEvents是一個事件集,CEvents=Events0∪Events1∪Events2。其中Events0={e01,e02,e03,……,e0m},表示0層事件;Events1={e11,e12,e13,……,e1n},表示1層事件;Events2={e21,e22,e23,……,e2k},表示2層事件。3層事件的關系如下:
(1)Events0是從業務流程中直接得到的原子事件集;
(2)Events1={e|IFr(e01,e02,…,e0m)THEN e,e01,e02,…,e0m∈Events0,r∈Rules,m>0}
(3)Events2={e|IFr(e01,e02,…,e0m,e11,e12,…,e1n)THEN e,e01,e02,…,e0m∈Events0,e11,e12,…,e1n∈Events1,r∈Rules,m≥0,n>0}。
定義6 用CGateways來表示包含復雜事件處理的網關集,CGateways=Gateways∪GC,其中GC表示復雜事件處理網關的集合。GC通過調用CEP引擎來判斷相應的事件規則是否被滿足,根據判斷結果產生相應的事件。
在BPMN2.0的基礎上,引入了復雜事件和復雜事件處理網關兩種新的符號,如表2所示。
?
一個網上購物網站提供免費的退換貨服務,用BPMN2.0來描述其業務流程模型如圖3所示。顧客A首先在購物網站挑選喜歡的商品,然后下訂單,網站接到顧客的訂單后,首先查詢該商品的庫存量,如果庫存不足,觸發補貨流程,并通知顧客無貨,顧客結束購物;如果庫存充足,通知顧客后,顧客付款,網站收到付款后,進行發貨,顧客收到商品后,如果對該商品滿意,則通知網站,雙方交易結束;如果對商品不滿意,則申請退貨,網站收到退貨后,為顧客退款,雙方交易結束。
圖3 BPMN2.0購物網站業務流程模型
考慮這樣一種情況,如果顧客A購買了一件商品T后,網站的庫存量還剩s件,但是A收到商品后,對商品不滿意,申請退貨,而同時顧客B也欲購買商品T,購買數量為s+1,這種情況,如果按照上面的流程,網站就會由于缺貨而失去顧客B。這是任何商家都不愿意看到的,為了挽回更多的顧客,可以有兩種解決方法:
(1)隨時監測退貨情況(m),庫存情況(s),以及顧客訂單數目(n),如果m+s≥n,則通知顧客有貨,交易繼續進行;
(2)隨時監測庫存情況(s)以及商品的日瀏覽量(r),如果r≥σ*s,則發送缺貨通知,進行補貨。
在這兩種方法中,都是通過對一些基本事件的分析,我們進一步得到了新的復雜事件。在(1)中得到的有貨通知和基本事件的有貨通知是不同的,得到的復雜事件有貨是指未來有貨,是一種對未來的推測;同樣,(2)中的缺貨通知是指未來缺貨,也是一種推測。
下面用CE-BPM來描述,如圖4所示,其中 “有貨”是一個2層事件, “未來缺貨”是一個1層事件。“有貨”用e2表示,“未來有貨”和 “未來缺貨”分別用e11和e12表示,“當前有貨”、“當前缺貨”、“下訂單”、“退貨”、“查看庫存”、 “查看商品日瀏覽量”分別用e01、e02、e03、e04、e05、e06表示,其中e03、e04、e05、e06都包含屬性ItemId和Amount,分別表示商品編號和數量。
根據實際業務需求,定義規則集Rules={r1,r2,r3},具體規則定義如下:
(1)IF r1(e11,e01)=e11or e01THENe2,當 “當前有貨”發生或 “未來有貨”發生時,產生復雜事件 “有貨”;
(2)IF r2(e03,e04,e05)=e05and e03(where(e-05.Amount<e03.Amount))and within(1min,e04(where(e04.ItemID=e03.ItemIdand e04.Amount+e05.Amount≥e03.Amount)))THENe11,對同一件商品,如果顧客下訂單時庫存量小于訂單量,在一分鐘之內有顧客退貨,同時庫存量與退貨量之和大于等于訂單量,則產生復雜事件“未來有貨”;
(3)IF r3(e05,e06)=e06and e05(where(e-06.ItemID=e05.ItemID)and(e06.Amount≥ σ * e-05.Amount))THENe12,業務流程每天查詢一次商品日瀏覽量,對同一件商品,如果日瀏覽量大于等于σ倍的庫存量,則產生復雜事件 “未來缺貨”,其中σ根據實際情況設定。復雜事件處理網關通過CEP引擎來實現,該引擎收集流程中的所有事件,與預定義的事件規則進行匹配,得到相應的復雜事件。與BPMN2.0購物網站業務流程模型相比,CE-BPM模型表達的事件更加豐富,能預知業務流程可能發生的機會和風險,符合實際的業務需求,同時根據層次劃分的事件使流程模型更加清晰。
圖4 CE-BPM購物網站業務流程模型
復雜事件處理通過抽象低層次的事件到高層次的事件,組合局部的事件成整體的事件,然后對這些事件進行匹配,判斷以及推理,通常用來實現判斷,查找原因,決策和預測的功能。在業務流程管理中,復雜事件處理能幫助企業更好的實時處理業務,并預測將會出現的機會和風險。支持復雜事件處理的業務流程建模方法,通過對流程中事件的分層表示,完整的表達了現實中的業務流程,使得業務流程能更好的處理實時業務,并能預測即將出現的機會和風險。然而現有的業務流程引擎并沒有很好的支持復雜事件處理,所以下一步的工作將是對基于復雜事件處理的業務流程引擎的研究。
[1]Mathias Weske.Business process management concept language architecture[M].Berlin Heidelberg:Springer-Verlag,2007.
[2]Object Management Group(OMG).Business process model and notation(BPMN)version 2.0 [EB/OL].http://www.omg.org/spec/BPMN/2.0/,January,2011.
[3]Object Management Group(OMG).BPMN 2.0by example[EB/OL].http://www.omg.org/spec/BPMN/2.0/,June,2010.
[4]Russ Miles,Kim Hamilton.Learning UML 2.0.[M].eilly Media Inc,2006.
[5]Russell N,Van Der Aalst W M,Ter Hofstede A,et al.On the suitability of UML 2.0activity diagrams for business process modelling [C].Proceedings 3rd Asia-Pacific Conference on Conceptual Modelling,2006:95-104.
[6]OASIS.Web services business process execution language version 2.0 [EB/OL].http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.html,April,2007.
[7]Matjaz B Juric.WSDL and BPEL extensions for event driven architecture [J].Information and Software Technology,2010:1023-1043.
[8]Dunkel J.Event-driven architecture for decision support in traffic management systems [J].Expert Systems with Applications,doi:10.1016/j.eswa.2010.11.087.
[9]Alistair Barros,Gero Decker,Alexander Grosskopf.Complex events in business processes[G].LNCS 4439:W.Abramowicz(Ed.):BIS 2007:9-40.
[10]QIN Tianbao,From BPMN to BPEL [J].Computer Applications,2006,26(6):266-268(in Chinese).[秦 天 保,從BPMN到可執行業務流程建模 [J].計算機應用,2006,26(6):266-268.]
[11]Luckham D,Schulte R.Event processing glossary-version 1.1[EB/OL]. [2008-08-31].http://www.complexevents.com/2008/08/31/event-processing-glossary-version-11/.
[12]Dan A,Gittler F,Toumani F.Integrating complex events for collaborating and dynamically changing business processes[C].Proceedings of the International Conference on Service-Oriented Computing,2009.
[13]Alexandre de Castro Alves.New event-processing design patterns using CEP [J].BPM Workshops,2010,43:359-368.
[14]Remco M Dijkman,Marlon Dumas,Chun Ouyang.Semantics and analysis of business process models in BPMN [J].Information and Software Technology,2008,50(12):1281-1294.
[15]Paul Dekkers.Complex event processing-CORDYS simplifying business [D].Radboud University Nijmegen,2007:46-50.