BPM介紹

        業務流程建模（BPM, 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 是一個不完整的規則，其中有許多不同的形式、表示法和資源。另一種常用的技術是定義表示概念性流程流的事件驅動流程鏈，正如 Barker 和 Longman 所定義的。這第二種技術使用了不同於 UML 的表示法。

      此外，還有許多專用方法（如 BPM 技術）可能被諮詢公司和企業資源規劃（Enterprise Resource Planning，ERP）套裝軟體廠商視為具有競爭優勢。ARIS Implementation Platform 就是這樣的產品的一個例子。其他的方法包括：Line of Visibility Enterprise Modeling (LOVEM) 和 IBM 的組件業務建模（Component Business Modeling，CBM）戰略。

      最近的趨勢是定義表示可執行流模型（如用於 Web 服務的業務流程執行語言（Business Process Execution Language for Web Services，BPEL））的標準方法。BPEL 將流程的範圍從分析擴展到實現。這樣的可執行模型引發了一系列的新問題，其中包括：

·哪些方面應該用 BPEL 描述，哪些方面應該用 WSDL 描述？流程模型和傳統的編程模型之間的區別在什麼地方？
·如何將非功能性要求和服務品質特徵這樣的方面加入模型之中？
·同更傳統的編碼（例如在 J2EE 中）相比，在 BPEL 引擎的編程語言擴展中執行多少邏輯？
·如何評定可執行流程模型的品質，其應用的最佳實踐是什麼？
·什麼工作角色進行 BPEL 流管理；是業務專家（分析人員），還是開發角色（軟體架構師）？

      必須利用所有現有的 BPM 方法作為 SOAD 的起點；然而，必須使用流程模型中用於驅動候選服務和它們的操作的附加技術來對其加以補充。此外，SOAD 中的流程建模必須與設計層用況建模保持同步，並且必須給出與 BPEL 有關的問題的答案。

 

理想的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。這種手工方案，需要看著編排，遵照角色要求畫一個流程；圖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）的體系結構。可惜的是，當今沒有一個這種體系結構的實際廠商實現。但是真如零售流程的例子所示，一個有用地近似實現是可以盛行的。

 

原文地址:
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