WMB 培訓教程

1. Message Broker 設計理念和功能概述

Message Broker 是IBM 的應用整合中間件，是IBM WebSphere 業務整合解決方案的重要組成部分之一，用於企業應用整合領域。Message Broker 目前的最新版本是V6.0，它的前身為WebSphere MQ Integrator Borker V5。

Message Broker 就是採用這種設計理念，它首先保證在一個異構的環境中實現信息穩定、可靠的傳輸，屏蔽掉用戶實際中的硬件層、操作系統層、網絡層等相對複雜、煩瑣的界面，為用戶提供一個統一、標準的信息通道，保證用戶的邏輯應用和這些底層平台沒有任何關係，最大限度地提高用戶應用的可移植性、可擴充性和可靠性；最重要的是它提供一個基於Application-Hub 的先進應用整合理念，最大限度地減少應用系統互聯所面臨的複雜性。基於WBI Message Broker 系統的實現維護都相對簡單，保證每一個應用系統的更新和修改都能夠實時地實現，真正體現了應用整合的精髓；同時當新的應用系統出現時能夠簡便的納入到

整個IT 環境當中，與其它的應用系統相互協作，共同為用戶提供服務，是我們實現企業應用互聯和應用整合的最佳實現方案。

由於”Hub&spoke”模式的採用，Message Broker 可以將複雜的網狀結構變為星型結構，大大簡化系統配置；它為各種應用提供一個統一借口，從而大大減少系統間接口的個數；同時，它可以作為一個數據中心，提供各種數據處理服務，如：數據的計算、過濾、數據庫操作等；它可以實現各種不同數據格式之間的轉換，如：自定義格式、傳統數據格式與XML格式之間的轉換，針對不同系統所處理的消息格式各不相同的特點，它提供了專門的消息格式解析器在不同的消息格式之間按照預先定義好的轉換規則進行自動的格式轉換，然後將結果自動路由到目標應用系統。它提供強大的連接性，利用各種適配器，可以與多種應用系統

進行無縫連接，如SAP, Siebel, Notes, SWIFT, People Soft, I2 等。

一．MB
安裝

演示：

創建 ODBC 數據源：選擇 32BIT ORACEL 驅動程序。

創建BORKER:

mqsicreatebroker EDI_BROKER -i db2admin -a db2admin -q EDI_QMGR -n ODBC_EDI -u wmb -p 000000

創建配置文件：

mqsicreateconfigmgr ediCfgMgr -i db2admin -a db2admin -q EDI_QMGR

一些常用命令

停止：mqsistop EDI_BROKER

啟動：mqsistart EDI_BROKER

配置ODBC數據庫用戶秘密：

mqsisetdbparms EDI_BROKER -n EDI_ORACLE -u user -p password

二．節點說明：

觸發和初始化

常用的可以提供這一功能的節點是MQInput節點，對隊列的每個消息流必須以MQInput節點

開始。MQInput節點有一個輸入(input)端，輸出(output)、失敗(failure)和捕獲(catch)三個輸出

端；它使用一個MQGET請求將消息從MQ隊列中取出，然後使用輸出端將消息流引導至下

一個節點；如果出現了錯誤，則將其引導至故障端；第三種端被稱為捕獲端，當消息流中隨

後出現例外情況並且不能得到適當處理以至於接近失效時，這一端將被啟動。如果多個

MQInput節點都在對一個MQ隊列進行讀取操作，有可能會出現與消息先後順序有關的問題。

另外，MqeInput、SCADAInput等也是針對特殊協議的特殊的輸入節點。

檢查和過濾

能夠提供這些功能的基本節點類型是檢查（Check）節點和過濾（Filter）節點。

檢查節點檢查消息中的消息類型規格是否與某些或全部域（domain）、集（set）和類型（type）

所期待的屬性相匹配。通過這一方式，可以對消息的RFH2頭信息和其他標準特性進行評估。

消息流經輸入端，如果檢查是成功的，消息將流經匹配端；否則，它們將被引導至故障端。

過濾節點使用一個SQL表達式作為決策標準，根據內容對輸入的消息進行評估。這種節點可

能使用的端包括輸入（in）端、實（true）端、偽（false）端、未知（unknown）以及故障

端。輸入（in）端、實（true）端、偽（false）端的含義從字面上就可以理解。如果評估的

結果是不確定或未知，則消息會流向未知端。如果在評估過程中出現錯誤（如發生算術溢出），

則消息會被引導至故障端。

消息處理

能夠進行消息處理的基本節點類型是計算（Compute）節點、映射(Mapping)節點、析取

（Extract）節點、ResetContentDescriptor等節點。

計算節點是可以對消息進行修改的節點，它的用途是對消息進行邏輯運算，在作邏輯運

算時，可以使用ESQL語言對消息進行處理。

映射節點的用途也可以對消息進行修改，它的用途是對消息進行格式轉換或創建新的消

息，它能夠以一種消息類型作為輸入，經過轉換後以另一個不同的消息類型將其輸出，在創

建新消息時可能需要用到輸入消息的內容或者可能的來自外部關係數據庫的數值。要注意的

是，在映射節點中能修改的是消息體的內容以及Environment和ExceptionList的內容，但是不

能修改消息頭的內容，只有Compute節點可以修改消息頭的內容。

析取節點對輸入消息進行選擇、拷貝和修改，創建一個新的輸出消息。

ResetContentDescriptor節點的用途是使用同一消息流內部的另一個解析器類型對消息進行

解釋。這一節點的功能類似於將消息從一個MQOutput節點傳送到一個MQInput節點。

外部數據庫操作

可以執行外部數據庫操作的基本節點類型是數據插入（DataInsert）節點、數據更新

（DataUpdate）節點、數據刪除（DataDelete）節點、數據庫（Database）節點以及數據倉庫（Warehouse）節點。這些節點都專門用來訪問數據庫並對數據庫進行操作的，所有這些節點都擁有以下類型的端：輸入端、輸出端和故障端。所有使用這些節點進行的操作可以作為由MQ協調的全局邏輯單元的一部分，它們也可以作為單獨的事務來處理。要注意的是，

所有這些節點都不能改變流經自己的消息。

數據插入節點可以將一個新行插入到一個特定的數據庫中。消息中所包含的某些信息可以

作為插入內容的一部分，或者消息可以只起到一個觸發器的作用，數據插入節點的順序很可

能是跟在一個過濾節點的後面，插入動作的完成是通過一個內部生成的SQL語句實現的。

數據更新節點可以更新某一特定數據庫中一行或多行的數值，更新操作也是通過一個內部

生成的SQL表達式完成的。

數據刪除節點可以從某一指定數據庫的數據表中刪除一個或多個行，消息在處理過程中不

會被改變。輸入消息中的數據可以被用在ESQL表達式中，以說明將從數據庫中刪除什麼樣

的數據。數據庫節點可以對某一指定的數據庫執行某一數據庫操作，它不會對消息進行改變，消息從節點的輸入端流到輸出端。消息中的數據值可以被包括在執行數據庫操作的SQL表達式之中。由於數據插入（DataInsert）、數據更新（DataUpdate）和數據刪除（DataDelete）節點的功能由數據庫（Database）節點都可以實現，因此，數據庫節點的使用頻率較高。

數據倉庫節點與數據插入節點類似，用於存儲在一個消息數據倉庫中流經代理程序的消

息。消息被存儲在數據倉庫中的目的可以是為了審查，或對消息進行離線處理或批處理，另

一個使用數據倉庫的理由是對流經消息代理程序的數據進行全面的數據挖掘（Data Mining）

或數據分析（Data Analysis）。消息添加到數據倉庫中的數據庫是通過一個SQL插入語句完成的，消息內容的格式可以有很大的不同，我們必須根據消息數據倉庫中消息數據的最終用途對所要求的格式進行評估。可以將消息數據倉庫僅僅作為消息的臨時存儲地點使用，而且數據庫不需要知道消息的內容，在這種情況下，消息可以以BLOB的形式存儲在數據庫中。另一方面，也可以要求數據庫對消息字段中的某些單元進行複雜的處理。在這種情況下，數據庫需要知道消息字段和消息頭中所包含的信息，以對存儲的數據進行處理。決策和路徑選擇具有這一功能的基本節點類型是MQOutput節點、MQReply節點以及Publication節點。

MQOutput節點是Broker內部消息流的終點。在這個節點，消息將會通過一個MQPUT MQI

調用被寫入到一個MQ隊列之中，根據消息中所包含的信息，消息可以被寫入到一個指定的

固定隊列，或被發送到一個應答隊列，還可以指定一個目的隊列的列表。

MQReply節點是MQOutput節點的特殊版本，在消息需要被輸出到在消息頭中Reply字段規

定的MQ隊列中時，可以使用MQReply節點。發佈（Publication）節點也可以作為消息流的終點，用於將消息發送給已定義了發佈和訂閱（Publish and Subscribe）服務的訂閱者。流經發佈節點的消息是發佈/訂閱消息流的一部分，發佈節點將根據主題和內容判斷消息是否與訂閱者的要求相匹配，並將匹配的消息直接發送給本地的訂閱者，或將消息引導至其他的代理程序，這些代理程序再進行同樣的匹配處理。錯誤處理和跟蹤擁有這一功能的基本節點類型有三種，分別是Throw節點、Trace節點和TryCatch節點。Throw節點只有一個輸入端，在消息流的內部用於處理例外情況。這些例外情況可能是早些時候TryCatch節點在消息流中捕獲的，或者可能會引起該特定消息的處理中斷和相關事務處理活動的重新運行。Throw節點可用於將例外情況（根據消息的內容進行判斷）丟棄，防止消息流的下游出現更多的失效。

TryCatch節點的用途是防止下游節點出現的對消息或事務處理過程的例外終止處理，當例

外返回到作為消息流根節點的MQInput節點時，這種情況是有可能發生的。消息通過輸入端

被接收，通過Try端被不加改變的轉發出去。如果例外被TryCatch節點捕獲，那麼它將通過

catch端（如果已被連接）被傳播出去，隨後就可以對例外進行錯誤處理。

如果消息流中發生的例外沒有被其他節點（如TryCatch節點）捕獲，那麼它將會被MQInput

節點捕獲，因為該節點是這一線程的發起者，該節點的catch端將會把這一消息傳播出去。

Trace節點用於幫助消息流的調試。它擁有一個輸入端和一個輸出端，輸出端將輸入消息不

加修改地發送出去，Trace節點會將一個跟蹤記錄寫入某一指定的地點，通過跟蹤記錄我們

可以分析一個消息在消息流內走過的路徑。我們可以使用多種選項確定跟蹤格式，例如可以

選擇某個操作系統文件，MB的錯誤日誌等作為輸出對象。其他類型的消息處理節點除了上述我們常用的節點類型之外，MB還缺省提供其他一些類型的消息處理節點，如：

MQeInput節點和MQeOutput節點，用於用MQ Everyplace產品輸入/輸出的節點；SCADAInput

節點和SCADAOutput節點，用於使用一種專門的協議SCADA協議輸入/輸出的節點；

HTTPInput節點、HTTPReply節點和HTTPRequest節點，用於Web Service支持的節點；

AggregateControl節點、AggregateReply節點和AggregateRequest節點，用於輸入/輸出消息的

聚合處理等。

第三方或插入消息處理節點以上描述的節點都是隨MB缺省提供的，用戶可以根據自己的特殊需求，開發客戶化的消息處理節點，來加強消息代理程序內部消息流的處理。這些節點的設計必須與MB的消息流框架（Message flow Framework）的要求相匹配，這樣才能夠將新的節點加入到MB Workbench之中，這種節點可能是以C語言寫成的，並以Windows動態連接庫或UNIX共享庫的形式分佈在系統中。

三：ESQL 說明：

在MB 中，消息流的開發使用的是ESQL 語言。大家對SQL 語言一定都不陌生，它是

用來操作數據庫的標準開發語言，而ESQL 是對SQL V3 的擴展，除了用於數據庫的操作之

外，它還可以操作消息數據，包括Generic XML 和MRM 格式的消息。如果大家熟悉SQL

語言，那麼使用ESQL 開發MB 中的消息流就會變得十分簡單。

在ESQL 中提供的函數種類主要有：用於字符串操作的函數，如：LENGTH，LTRIM,

RTRIM, LOWER, POSITION, SUBSTRING, UPPER 等；用於數字操作的函數，如：ABS,

FLOOR, MOD, SQRT, ROUND, TRUNCATE 等；用於時間和日期操作的函數，如：

CURRENT_DATE，CURRENT_TIME，CURRENT_TIMESTAMP 等；用於字段操作的函數，

如：CARDINALITY, FIELDNAME, FIELDTYPE 等；其他一些重要的函數，如：CAST 函數

用於不同數據格式之間的轉換，CASE，PASSTHRU 等。

下面是一段ESQL 示例：

SET OutputRoot = InputRoot;

SET OutputRoot.XML.Message.Admin.Manager[] = (SELECT E.FIRSTNME, E.LASTNME

FROM Database.EMPLOYEE AS E WHRER E.JOB=’MANAGER’ AND

E.WORKDEPT=InputBody.Message.Admin.Dept);

PASSTHRU 語句

PASSTHRU(‘SELECT R.* FROM Schema1.Table1 AS R WHERE R.Name = ? OR R.Name = ? ORDER BY Name’
TO Database.DSN1
VALUES (‘Name1’, ‘Name4’));

聲明外部存儲過程

CREATE PROCEDURE GET_ID_SEQ(OUT ID INTEGER)

LANGUAGE DATABASE

EXTERNAL NAME “GET_ID_SEQ”;

以下文章點擊率最高