使用 WebSphere Business Modeler 進行業務建模

周 暉 (zhuish@cn.ibm.com), Websphere 架構師, IBM
陳 宇翔 (chenyux@cn.ibm.com), 資深 Websphere 工程師與行業架構師, IBM

SOA 的概念、產品平臺已經廣為業界所接受，SOA 適用的業務範圍以及可以給業務帶來的益處也廣為宣傳，但是一個專案如何用 SOA 的方法來做業務分析、架構設計到編碼實現、測試上線確是很多客戶所困惑的事情，包括一些應用開發廠商。大家都知道 SOA 的架構設計和傳統的 J2EE 架構設計不一樣，開發過程也不一樣，比如客戶最想知道的一個問題：服務是如何抽取的，什麼樣的顆粒度是合適的。

本系列文章以假定的業務為樣例來回答上述問題，通過一個較為真實的例子帶讀者走一遍 SOA 的開發歷程，也從中深刻體會 SOA 的開發和傳統開發的不同之處，掌握 SOA 開發的基本要領。在這過程中，充分使用 IBM 的 SOA 工具一步一步實施，讓讀者最終可以重現此 SOA 的開發過程。

前言

本系列文章，共分為 4 個部分，本文為第 1 部分，將向您講述業務建模，即如何從一個具體需求開始，使用 IBM 的 SOA 建模工具 WBM(Websphere Business Modeler) 進行業務建模。第 2 個部分是服務建模和架構設計，以業務建模為輸入，通過 RSA(Rational Software Architect)+SOMA-ME(Service Oriented Modeling and Architecture--Modeling Environment)，進行服務識別、確定服務規約，進行架構設計。第 3 部分介紹如何使用 WID(Websphere Integrated Developer) 進行開發，從 WBM 匯入業務建模，生成開發的粗框架，然後具體編碼實現，並進行單元測試和系統測試。第 4 部分，這是一個示例專案用 SOA 方法進行實施，總結實施中的一些經驗。

回頁首

業務需求背景介紹

本文的業務案例是支付平臺的業務，也即支付方通過支付平臺支付費用，如水電煤費之類的費用。支付平臺根據請求到銀行扣款，然後根據一定的規則收取支付平臺費用，最後向收費方核銷費用。

這個業務是個常見而典型的業務。業務流程如下：

圖 1. 業務流程

以下為圖中每個節點的業務功能介紹：

1、使用者登入繳費平臺，選擇一筆費用進行支付，提交請求，觸發支付流程，進入流程節點報文處理，繳費平臺的繳費要求和支付平臺的報文處理之間通過 JMS 繫結。

2、流程進入支付平臺，對進入的報文進行處理，曝光記錄日誌，從支付請求報文中提取資料，把支付相關資訊寫入資料庫。

3、支付平臺將支付請求發往銀行，和銀行之間通過 MQ 通訊，把報文發給指定的 MQ 佇列，非同步等待另外一個 MQ 的銀行報文回覆

4、銀行響應，支付平臺接收銀行回來的報文，通過 MQ 繫結此節點輸入

5、報文處理，支付平臺處理已接收到的回覆報文，如更新銀行支付資訊的資料庫

6.1、對這筆支付進行計費，如果交易成功，則按如下的規則進行計費

計費業務規則：

根據客戶程式碼 PAYER_NO 的值，確定是哪類客戶：包月客戶，按次客戶，按交易量客戶

如果是包月客戶，不計費

如果是按次客戶，計費一次，一次收費 0.5 元

如果是按交易量計費，則交易金額低於 10000，收費 1 元，交易金額大於 10000，收費 2 元，更新計費表，在資料庫中提交交易費用，記錄交易流水。

6.2、支付響應，支付平臺給繳費系統回應是否支付成功。

7、支付核銷，繳費平臺把核銷的報文傳送給收費方做費用核銷。

回頁首

業務資料建模

IBM WebSphere Business Modeler ( 簡稱 WBM) 是一個簡單易用的業務過程建模工具，除了可以對流程建模，還可以對業務規則建模、對業務資料建模，WBM 是非系統設計的資料建模，對於系統設計階段的資料建模，可以用 Rational Data Architect 建模

在業務建模中，業務資料建模是個比較關鍵的步驟，業務人員做需求分析的時候，把業務流程流經的每個節點的業務資料梳理出來，很形象的來說就是一個業務表單，要做這個業務，需要哪些業務資訊。

本文 WBM 的版本是 V6.1.2。

在 WBM 中建立專案檔案

開啟 WBM，選擇選單 -> 檔案 -> 新建 -> 專案 ->Websphere Business Modeler-> 業務建模專案。輸入專案名稱及預設流程名稱，點選下一步。選擇泳道佈局 -> 點選完成。

建立業務資料項

接下來建立業務資料項。通過 WBM 建立的業務資料模型，稱為業務項。

在專案樹下，點選業務項，右鍵 -> 新建 -> 業務項。如下圖：

圖 2. 支援請求資料項

比如這個業務裡面的支付請求業務項 PAY_REQUESR，業務上會包括：

交易程式碼

交易序列號

請求時間

支付者編號

支付者銀行帳號

支付的業務型別

支付的筆數

支付的總金額

記賬日期

支付的詳單（注，業務上可以一次支付多筆業務，每筆業務有一個詳單）。

分別輸入各個業務項的屬性和型別，每個業務項的屬性均可以輸入屬性描述，便於對資料項業務含義的理解。還可以新增業務項的說明文件。

再分別完成請求回覆的業務項 (PAY_RESPONSE)、計費業務項 (CHARGEBO)、核銷資訊 (HEZHU)、計費項（CHARGEITEMBO）。在實際架構設計中，這些業務項就是資料架構設計的原型，在詳細的資料架構設計中，會針對 IT 的需要增加一些欄位。

WBM 的業務資料建模支援資料型別的巢狀和陣列的定義，如 PAY_REQUEST 中就包含有 PAY_DETAIL 的資料結構陣列。資料項即可以通過 XSD（XML Schema Definition，XML 綱要）匯入。

回頁首

流程建模

這個業務有典型的業務流程，有嚴格的執行順序，雖然主要是自動流程，但也可以引入人工流程做異常處理。

用 WBM 建模，可以把業務模型直接匯入開發環境，這樣一方面可以重用業務模型，不需要重新編排業務流程，另外一方面也消除了 IT 人員重新畫業務流程和業務人員的流程上理解不一致帶來的差異，也即消除了業務模型到 IT 模型的溝壑。

WBM 支援泳道形式的業務流程建模，也支援自由形式的流程建模。考慮到泳道形式的業務流程更易於理解，我們用泳道方式對支付業務建模。

先定義泳道，可以有多種方式劃分泳道，如角色、資源、分類、位置、組織架構單元等。在本示例中，都是自動流程，我們按不同的角色的方式劃分，如按下圖方式定義角色：

根據業務需求定義了 5 個：

計費系統

支付平臺

繳費系統

銀行

收費方

如下圖，在專案樹下，點選資源 -> 右鍵 -> 新建 -> 角色，輸入角色名稱，重複其他 4 個角色的定義。

圖 3. 泳道按角色定義圖

下面定義流程的每個節點，以第一個節點—支付請求為例，從 WBM 的選用板中拖一個任務到繳費系統的泳道，點選屬性，在常規標籤中輸入名稱支付請求。

定義一個業務節點，除了要描述業務實現的功能，還要定義完成此業務所需要的業務項，和完成以後可以提供給下一步的業務項。點選屬性的輸入標籤，點選新增，點選關聯資料右端，彈出型別選擇，選擇業務項 ->PAY_REQEUST，輸出也是 PAY_REQUEST。

如果是人員任務，還要定義組織架構，任務以什麼方式分配到什麼角色或是資源，任務在什麼情況下進入升級處理，如任務沒有人去宣告處理，或是處理時間超時等進入升級，進入升級後的通知操作，以 Email 還是任務項的形式通知什麼人去處理。

圖 4. 編排業務流程

逐個定義業務流程的每個活動項，並用合適的連線連線。

圖 5. 業務流程圖

如上圖，為最終的 WBM 的流程建模。圖中每個節點的輸入輸出都會顯示。

回頁首

業務規則建模

在業務中，計費是按照規則計費的。有 2 個規則，一個是客戶分類規則，另一個是計費規則。WBM 可以對業務規則進行建模，和 WID(Websphere Integration Developer) 的規則建模類似。WBM 可以先建一個規則模板，然後再模板上再例項化為業務規則，也可以直接建立業務規則。通過模板的方式建規則，是個很好的規則重用方式。

對於第一個規則：客戶分類，是按照 PAY_REQUEST 中的業務屬性支付者編號 PAYER_NO 來劃分的，如果 PAYER_NO 小於 10000 就是包月客戶，也即不對每次交易計費。如果 PAYER_NO 大於等於 10000 且小於 20000 就是按次客戶，一次支付計費 0.5 元，也即不對每次交易計費。如果 PAYER_NO 大於 20000 就是按交易金額計費的，交易金額低於 10000，收費 1 元，交易金額大於 10000，收費 2 元。

一個業務規則建模分為 2 部分，一是條件定義 If，二是 then 的操作。如下圖為條件定義，通過 AND/OR 可以定義多個條件組合，條件定義多是輸入變數的一些判斷。

從選用板中拖一個業務規則任務到計費系統的泳道中，屬性 -> 常規 -> 名稱中輸入確定客戶型別，在屬性 -> 輸入中選擇兩個輸入：CHARGEITEMBO,PAY_REQUEST。輸出中選擇 CHARGEBO 和 CHARGEITEMBO。在業務規則標籤中新增規則，輸入名詞確定客戶型別，點選新增規則，點選規則條件右端，彈出規則條件對話方塊如下：

圖 6. 規則定義，確定客戶型別的條件

點選新增，也即新增一個條件，在第一項下選擇建模工件，然後選擇輸入的屬性 PAYER_NO，運算子選擇小於等於，第二項選擇數字，然後輸入 10000。

確定以後點選規則操作的右端，彈出規則操作對話方塊，如下圖為 then 的操作定義，主要是對輸出的業務屬性的賦值，詳細資訊中選擇 Type，值規範中選擇特定值，輸入“按月計費”。

圖 7. 規則定義，確定客戶型別的結果

這樣就形成了客戶型別的第一個規則。

針對每個業務規則，WBM 會生成很容易讀懂的指令碼，如下圖是確定客戶型別的第二個規則。

圖 8. 規則定義，生成的可理解的規則語言

類似的，再設定計費的業務規則。通過條件判斷，給輸出的 CHARGEITEMBO 的 Fee 賦值。

回頁首

模型匯出

完成了業務建模以後，要匯出業務模型，並將之匯入 WID，以生成專案檔案和專案框架。

在 WBM 中點選專案右鍵，選擇匯出，進入下圖介面：

圖 9. 匯出 Modeler 的業務模型

選擇 Websphere Integration Developer（開發工具）。

點選下一步，選擇匯出檔案存放目錄。進入下一步的匯出設定：

圖 10. 按模組和庫的方式匯出業務模型

注意：一般按推薦選項，然後把實施模組名稱和庫名詞修改為英文，為了開發方便起見，流程的節點名字，流程業務項都最好用英文，這樣最終生成的 WID 就都是英文變數，否則在 WID 中的中文變數、專案名會帶來一些開發的麻煩。

然後點選完成，就可以生成 WID 的匯入專案，一般是專案名稱 + 生成日期時間的 zip 交換檔案。

至此，我們完成了業務建模的工作，包括業務資料 ( 業務表單 ) 的建模、流程建模和規則建模，並把業務建模的成果匯入開發環境，形成了粗的開發框架。

小結

對一個具體的業務例子，我們應用業務建模的方法，通過 WBM 對此業務例子進行了業務建模。業務建模使得業務人員把需求以一種比較標準的方式移交給 IT 開發人員，消除了從業務需求和 IT 實現之間的歧義。這個業務建模是未來服務識別的一個重要輸入，也可以匯入開發環境，生成開發框架，是 SOA 架構設計的重要一環。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14789789/viewspace-610877/，如需轉載，請註明出處，否則將追究法律責任。