版權聲明：可以任意轉載，轉載時請務必以超鏈接形式標明文章原始出處和作者信息及本聲明
原文地址:
http://www.onjava.com/pub/a/onjava/2005/07/20/businessprocessmodeling.html
中文地址:
http://www.matrix.org.cn/resource/article/43/43803_Business_Process_Modeling.html
關鍵詞： Business Process Modeling
“以方框與箭頭表現出來的大筆財富……”一個業務分析家站在白色書寫板前，用箭頭連起來的盒子勾畫出一個業務流程圖，并要求軟件開發小組實現它（向莎士比亞道歉）。(編輯注：此處作者引用了一句雙關語: "The boxes and arrows of outrageous fortune ...."，應是源于莎翁之句，譯者譯為“暴虐命運的雪箭霜盒……”但從本段含意來看，編輯認為，最好按字面翻譯，可以體現出作者在英文環境下的雙關韻味）業務流程建模（BMP, Business Process Modeling）——也被稱作業務流程管理(Business Process Management)——此時就可以幫上忙了。BPM是一套設計、執行、管理及監控業務流程的技術和標準。一個業務流程是指為了實現某種業務目的行為（盒子）——每個盒子代表一個人的操作、一個內部系統、或一個合作公司的流程——的流程或一系列動作。
這么多年來業務流程和BPM的范圍已經被擴展。就在幾年前，BMP——那時叫“工作流”(workflow)——用來管理和驅動在公司部門內大型人性化和紙制流程的組件。例如，處理一個申請（保險申請），將掃描的紙制申請表格作為輸入，電子化地從一個索賠受理者的電子郵箱（或者worklist）傳到另一個那里。這相當于模仿各辦公室郵件在辦公桌之間傳遞的傳統動作。現在BM是一種企業集成技術，作為對面向服務系統架構（Service-Oriented Architecture (SOA)）、企業應用集成(Enterprise Application Integration（EAI）)、企業服務總線（Enterprise Service Bus（ESB））的補充。當代的流程成功地處理了復雜系統的交互，其本身作為一種服務依照良好定義的技術契約可以與以他公司的流程交互、交流。例如，零售商處理購買訂單的流程運用Xml消息與基于服務的顧客和倉庫流程交互。
理想的BPM體系結構
我即將出版的一本書《業務流程建模本質》（Essential Business Process Modeling）探究了BMP的概念、設計和標準。當今的BMP相當于一個沼澤，我的書與許多被誤解、被誤用和被過分吹噓的廠商和標準爭論。在對BMP前景的調查中，我的書強調標準高于廠商，因為標準是更好的概念源頭，且使這個主題更清晰。已通過的BMP標準乍眼望去像一盤黑糊糊的字母形花片湯（見表1），但是將其中最好的恰當地組合后，他們會形成一個非常易于理解的體系結構，見圖1。
表 1. BPM 標準
圖1. BPM 體系
在這個體系結構的核心部位是一個執行流程的運行時引擎，其流程的源碼是由基于XML的BPEL語言寫成，BPEL是當今最著名、廣泛應用的BPM標準，及最優秀的BPM執行語言。這些流程是由業務和技術分析家使用支持可視化流程圖語言BPMN——最好的BMP圖形語言——的圖形編輯器設計出來的。此編輯器包括一個導出器，可以從BPMN圖生成BPEL代碼(之后部署到引擎)。(在當前許多Java開發工具中，BPMN到BPEL的流程與UML到Java的流程相類似。)
人和計算機的交互驅動引擎里流程的執行。人這個參與者使用一個圖形化工作列表應用程序瀏覽并執行未執行完畢的手工工作（在流程運行的引擎里）。依附于公司網絡的但在引擎地址空間外的內部IT系統，被儲如web服務，j2EE，或COM的集成技術，通過XML作為選用的消息格式所訪問；用編成語言如java、C#寫出的內部交互可以是更輕便的內嵌代碼片斷。外部交互是典型的基于web服務的通信，由編排控制，例如那些用新興的XML語言——WS-CDL 這個領先的編排語言所創作出的外部交互。雖然編排描述了多個參與者流程交互（在business-to-business電子商務里很典型）的整體、引人注意的視圖，但是編排工具包可以用來生成一個基本的BPMN模型，其可以捕捉某個特定參與者流程所要求的通信，同時這個工具還可以驗證一個給定的流程是否滿足編排的要求。（WS-CDL文獻建議由WS-CDL生成BPEL而不是BPMN。但是在現在的體系結構中，BPMN作為一種設計語言是一個必要的間接層。）
BPM系統管理員里利用一個圖形化的監視控制臺來維護和跟蹤引擎流程的狀態。控制臺使用一種管理語言與引擎銜接。實時引擎將流程狀態持久化到數據庫，控制臺直接與數據庫碰面，而不是用管理語言來溝通。運行時引擎將流程狀態持久化到數據庫，控制臺直接與數據庫碰面而不是使用管理語言來專門執行流程的請求。監控構造也支持業務活動監控（Business Activity Monitoring (BAM)）或者儀表板式的業務監控。
在這個平臺上的開發過程如下：
1.從一個WS-CDL choreography生成一個初始的BPMN模型。如果流程并不是從一個編排衍生而來則越過此步。
2.設計BPMN模型
3.從BPMN模型生成BPEL
4.開發必要的人和系統(內部和外部)的接口
5.部署BPEL代碼和其必要的接口到引擎
6.使用管理和監控接口跟蹤正在運行的流程。
這個體系結構的全貌（由WFMC——眾多BPM標準組織中最成熟的一家——的參考模型激發而成）類似許多集成廠商（如，IBM、BEA,、Oracle、Tibco,、SeeBeyond和Vitria ）所提供的平臺。使這個體系結構特別的地方是其標準的選擇。BPEL、BPMN和 WS-CDL都被包含進來，因為他們分別是執行、設計和編排的最好解決方案，BPM最重要的三個部分。
（如圖2所示未來可能包括新興標準BPQL——用于監控，BPSM和BPDM——用于元模型建模，BPRI——用于運行時接口，BPXL——用于BPEL擴展）。事實上，很多廠商支持或正在實現支持BPEL。但是BPMN的支持非常少（大多數廠商提供各自的方案），WS-CDL的支持幾乎沒有。BPEL并不夠。這個體系很理想化，需要實際的實現。
圖2. 在理想體系中的BPM 標準
讓這個零售流程運行起來
這個體系結構也許還沒有任何實現，但是就零售商處理一個購買訂單為例，我們近似描述這個指定的開發周期并建立一個實際的流程。我們從編排開始。一個零售商流程并不是在孤立的環境中運作，而是須同顧客和倉庫的流程合作來接收、填寫訂單。這個編排可以用下面的文字描述：
1.顧客將向零售商發送訂單。
2.零售商向顧客發送訂單已收的確認
3.零售商將訂單轉發給倉庫并將顧客emai地址也傳過去。倉庫將用這個地址通知用戶什么時候訂單完成。
4.倉庫如接受了訂單，就發送一個肯定的確認給零售商；如拒絕了訂單則發送一個否定的確認。在這個兩種情況里，零售商都將倉庫的返回結果轉發給顧客。
5.假設倉庫接受了顧客的訂單。倉庫當完成了處理并準備發貨的時候，就直接通知給客戶發通知。
WS-CDL的好處就是可以將這些步驟用XML語言形式上編成代碼。開始兩個步驟的文字描述用WS-CDL編成代碼如下：
例子1. WS-CDL 顧客-零售商交互
1 <interaction name="POInteraction" channelVariable="tns:RChannel"
2 operation="handlePO" initiate="true">
3 <participate relationshipType="tns:CRRelationship"
4 fromRole="tns:Consumer" toRole="tns:Retailer"/>
5 <exchange name="POReq" informationType="tns:PO"
action="request">
6 <send variable="cdl:getVariable(poC, tns:Consumer)"/>
7 <receive variable="cdl:getVariable(poR, tns:Retailer)"/>
8 </exchange>
9 <exchange name="PORsp" informationType="tns:POAck"
action="respond">
10 <send variable="cdl:getVariable(poAckR, tns:Retailer)"/>
11 <receive variable="cdl:getVariable(poAckC, tns:Consumer)"/>
12 </exchange>
13 </interaction>
這段代碼描述了兩個交換之間的交互：在第一個(5-8行)里，顧客發送(action="request")
購買訂單(informationType="tns:PO")給零售商，第二個（9-12行）里零售商以訂單確認回應(action="response")顧客(informationType="tns:POAck").
建立零售商流程的第一步是創建一個BPMN圖，以滿足編排中零售商的所需身份。今天，此步驟需要手工完成；當前的WS-CDL工具還沒有一個能生成BPMN(www.pi4ech.com提供了關于一個或兩個當前WS-CDL的實現)。這種手工方案，需要看著編排，遵照角色要求畫一個流程；圖3顯示的BPMN圖，代表零售商在編排中是個參與者。
圖 3：滿足編排的零售商流程（BPMN表示）
這個流程的邏輯很直觀。流程從收到客戶購買訂單（PO）的消息開始（來自客戶的PO）。然后接著發送給客戶一個確認憑據（發送確認憑據給客戶）；將PO轉發給倉庫（發送PO給倉庫）；等待倉庫回應。符號清晰直觀：盒子扮演“活動”的角色，附有信件的圓圈表示等待“事件”，最后以一個空圓圈表示流程的結束點。
圖4. 完全的零售商流程—單擊查看大圖
圖4展示了附加私有步驟（也就是不是為編排而是內部需求所要求的步驟）的流程。這些步驟以斜體表示：“將PO寫入數據庫”，當購買訂單從顧客發出時將其持久化到內部的零售數據庫；“更新PO在數據庫的狀態”，依照倉庫回應狀態（也就是接受會拒絕）更新數據庫記錄；“銷售跟進”是一項人工任務，在其被倉庫拒絕了的情況下，分配給銷售代表去幫助客戶重新提交訂單。（圖中的菱形是異或門(XOR Gateway)。他們被結合起來用的時，形成一個功能類似if語句的代碼結構。在《業務流程建模本質》中有對門(Gateway)的詳細論述。
這些圖是用ITpearl的流程建模器畫出的。ITpearls的流程建模器是Microsoft Visio里一套BPMN模板。流程建模器現在還不是羽翼豐滿的開發工具，僅僅是一個畫圖應用而已。例如它不能生成BPEL代碼，這一步須人工生成。無論如何，這些圖對設計文檔還是有價值的，就像不能生成實際Java或C#代碼的UML畫圖工具一樣仍可以輔助軟件設計師整理應用的對象和組件，所以流程建模器可以協助業務分析家或設計師將流程描述為一個標準的流程表現形式。
事實說明，到BPEL的映射非常直觀：BPMN流程的“事件”(例如，“等待倉庫回應”)是BPEL“接收”(receive)活動(或等待事件發生的活動)；像”發送PO給倉庫”的活動是BPEL的“調用”(invoke)活動（或是調用服務的活動）；條件選擇結構包含的”銷售跟進”是一個BPEL“轉換”活動。整個流程是順序活動圖。例2是相應的BPEL代碼，其中這些由BPMN派生出來的八個步驟每個都有注釋（例如第12行注釋為第一步）。
1 <process name="Retailer"
2 targetNamespace="http://acm.org/samples" suppressJoinFailure="yes"
3 xmlns:tns="http://acm.org/samples"
4 xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
5 xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/
business-process/">
6
7 <!-- some code omitted - ->
8
9 <!-- Mainline process code starts here -->
10 <sequence name="main">
11
12 <!-- Step 1: Consumer sends PO -->
13 <receive name="receiveInput" partnerLink="consumer"
portType="tns:Retailer"
14 createInstance="yes" operation="sendPO" variable="po">
15 <!-- Use the inbound PO message as the basis for
correlation -->
16 <correlations>
17 <correlation set="poset" initiate="yes"/>
18 </correlations>
19 </receive>
20
21 <!-- Step 2: Send receipt ack to consumer -->
22 <invoke name="callbackClient" partnerLink="consumer"
23 portType="tns:RetailerCallback" operation="poReceipt"
24 inputVariable="po"/>
25
26 <!-- Step 3: create PO record in internal database -->
27 <invoke name="writePOToDB" partnerLink="retailerDB"
portType="tns:RetailerDB"
28 operation="createPO" inputVariable="po"/>
29
30 <!-- Step 4: send PO to warehouse -->
31 <invoke name="sendPOToWH" partnerLink="warehouse"
portType="tns:Warehouse"
32 operation="sendPO" inputVariable="po"/>
33
34 <!-- Step 5: wait for warehouse response -->
35 <receive createInstance="no" name="receiveWHResponse"
partnerLink="warehouse"
36 portType="tns:WarehouseCallback" operation="onResult"
37 variable="poResponse">
38 <!-- correlate on identifiers in initial PO -->
39 <correlations>
40 <correlation set="poset" initiate="no"/>
41 </correlations>
42 </receive>
43
44 <!-- Step 6: send warehouse response to consumer -->
45 <invoke name="responseToConsumer" partnerLink="consumer"
46 portType="tns:RetailerCallback"
47 operation="poResult" inputVariable="poResponse"/>
48
49 <!-- Step 7: update PO in internal database -->
50 <invoke name="updateDB" partnerLink="retailerDB"
portType="tns:RetailerDB"
51 operation="updatePO" inputVariable="poResponse"/>
52
53 <!-- Step 8: Special processing if warehouse rejected PO -->
54 <switch name="checkResp">
55 <!-- It's a reject if the "action" field of the
56 warehouse response is "reject" -->
57 <case condition="bpws:getVariableData(
58 "poResponse","payload",
59 "/tns:POMsg/tns:action") = "reject"">
60 <sequence>
61 <!-- Assign a task to a sales rep to
contact the consumer about the
62 rejection. Fire and forget: don't
bother waiting for the result
63 of the task. -->
64 <invoke name="salesFollowup" partnerLink="taskMgr"
65 portType="tns:WorkflowTaskManager"
66 operation="create" inputVariable="task"/>
67 </sequence>
68 </case>
69 <otherwise/>
70 </switch>
71 </sequence>
72 </process>
在BPEL代碼中"partner links"（以XML屬性partnerLink標示，例如13行的partnerLink="consumer"）用來識別流程與誰交互。
consumer，表示客戶流程，用在步驟1，2，6中
warehouse，表示倉庫流程，用在步驟1、5
retailerDB，作為一個零售數據庫的web服務接口，用在步驟3、7
taskMsg，人工作流web服務接口，用在步驟8
這三種流程的交互表現為：consumer與warehouse是外部系統的交互，retailerDB是一個內部系統交互，taskMgr是 人的交互。所有的交互多是基于web服務的。它們的partner都有WSDL來描述其接口。有趣的是，零售流程本身是一個web服務，它的”接收”活動是web服務操作，寫在一個處理負責發布至其他服務的WSDL中。
與BPMN和ws-CDL不同的是，BPEL有很多好的工具，例如Oracle的BPEL Process Manager，在《業務流程建模本質》中它已被用來開發兩個真實的BPEL例子
結論
由業務分析家在白板上畫出的這些粗略流程圖的實現需要一個建造在最好的BPM標準上（
BPEL, BPMN, 和WS-CDL）的體系結構。可惜的是，當今沒有一個這種體系結構的實際廠商實現。但是真如零售流程的例子所示，一個有用地近似實現是可以盛行的。
Mike Havey是幾個主要BPM應用的設計師，BPM和面向流程應用的期刊文章作者。