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”;

以下文章点击率最高