使用 WebSphere Message Broker 集成具有高度复杂的消息格式的系统

本文使用来自银行系统的一个真实示例,向您展示如何使用 WebSphere Message Broker 数据建模来降低集成高度复杂的消息格式的成本。

Hesham Soultan 博士, IT 架构师,开罗技术开发中心, IBM

Hesham Soultan 博士是埃及开罗技术开发中心的 IT 架构师。他的开发专业知识包括汽车嵌入式软件、机器视觉、机器学习和业务集成。加入 IBM Business Integration 团队后,他从事过 WebSphere DataPower、WebSphere Message Broker 和 WebSphere MQ 方面的工作。



2012 年 10 月 08 日

简介

数据转换和格式转换是业务集成的核心任务。对于数据转换,IBM® WebSphere® Message Broker(以下简称 Message Broker)提供了它自己的 Mapping 节点(对于物理格式转换,使用消息集的数据建模发挥着重要作用),以及不同的消息分析器。

创建消息模型之后,您可以使用它来将 Message Broker 接收的所有请求消息的格式都转换为后端系统所需的另一种物理格式。 反过来,您可以使用消息模型来分析来自后端系统的响应消息,以生成消息的逻辑树,并轻松将其转换回前端系统的格式。Message Broker 广泛使用和支持的主要物理格式是文本、二进制文件和 XML。 文本格式可以是固定长度的、标记/分隔的或仅分隔的格式,而且分隔的元素既可以是有序的,也可以是无序的。本文包含四个部分:

使用消息集减少代码量

有时您需要与一个具有复杂界面的后端系统相集成。在这种情况下,Message Broker 中的消息建模功能可大大加速集成过程,如本文中使用过的示例所示。示例架构如图 1 所示。银行系统要求请求和响应消息的某些函数使用复杂的固定长度文本格式,其他函数使用标记/分隔的无序复杂文本格式。

图 1. 示例架构
图 1. 示例架构

在这样的情况下,您不知道 Message Broker 中消息建模的实力,您需要编写复杂的自定义代码来执行物理格式转换和消息分析。 通过创建消息模型,然后使用 MRM 分析器,您可以灵活地生成或分析任何消息,不管消息有多复杂。此外,使用 MRM 分析器中的可靠代码可提高您的中间件解决方案的总体可靠性。下面的图 2 显示银行系统适配器通过 MQInput 节点从前端接收 XML MQ 消息时的消息流。要根据消息模型将这条消息转换为文本格式,只需编写清单 1 中所示的三行 ESQL 代码来选择消息模型。创建的任何逻辑树(清单中最后两个语句用于创建 MRM 树)都将转换为选定的物理格式。代码与 Message Broker 计算节点 Extract backend Msg 相关。

图 2. 银行系统适配器消息流
图 2. 银行系统适配器消息流

来自后端银行系统的响应由 MQGet 节点读取,然后计算节点 MapToesbXML 由一些简单的 ESQL 代码加以分析。只有一个语句根据消息模型参数来调用 MRM 分析器,如下面的清单 2 中所示。

清单 1. 后端适配器请求生成代码
DECLARE inRef REFERENCE TO InputRoot.XMLNSC.BE_esbXML.Body;

SET OutputRoot.Properties.MessageSet='MRM_Binary_CSV';
SET OutputRoot.Properties.MessageType=FIELDNAME(inRef.*[1]);
SET OutputRoot.Properties.MessageFormat='Text_CSV';
		
-- <<<<Copy the Backend message from the BE_esbXML>>>> 
CREATE LASTCHILD OF OutputRoot DOMAIN ('MRM');  
SET OutputRoot.MRM = inRef.*[1];
清单 2. 后端响应分析代码
CREATE LASTCHILD OF OutputLocalEnvironment DOMAIN('MRM') PARSE(BlobBitstream 	
    SET 'MRM_Binary_CSV'
    TYPE funName
    FORMAT 'Text_CSV');

在使用消息模型之前需要单独对其进行测试,确保它向您提供适当格式的消息。为此,您可以使用如下所示的简单流程:

图 3. 测试消息流的简单流程
图 3. 测试消息流的简单流程

如图所示,该流程有一个 MQInput 节点,其中 Input Message Parsing 属性标签的设置如底部所示。输入节点后面的断点能够让您审查逻辑树,并确保分析是成功的。您可以设置 Compute 节点中的输出属性,如下面的清单 3 所示,获取 XML 格式的输出消息,以便进行审查:

清单 3. 用于转换消息物理格式的简单代码
SET OutputRoot.Properties.MessageSet='MRM_Binary_CSV';
SET OutputRoot.Properties.MessageType='Account_135a_Response';
SET OutputRoot.Properties.MessageFormat='XML';

固定长度的文本消息

这部分向您展示如何创建可生成或分析银行系统消息的消息模型。示例如下面的清单 4 中所示。三个逗号之前的第一个部分是一个具有固定值的函数 ID。三个逗号与 ^ 字符之间的第二部分是消息标题,其中包含每条消息中都能找到的预定数量的元素。^ 字符之后的第三部分包含函数的业务参数:

清单 4. 用于转换消息物理格式的简单代码
TAM.S.CHA.ACC.822,,,,
CRM 123456789012341234567890123456789012345678901234567890123456789
01234567890123456789012382202012345678901234567890123450123456789012340000^
0015881800240001362371

要创建消息模型,首先将整条消息的复杂类型创建为 Account_822b_Request_t,如图 4 所示:

图 4. Message Broker 消息集中的消息模型
图 4. Message Broker 消息集中的消息模型

如图 5 所示设置这个复杂类型的逻辑和物理属性,从左边的逻辑属性开始,保留其余属性的默认值:

图 5. 消息类型的逻辑和物理属性
消息类型的逻辑和物理属性
图 5. 消息类型的逻辑和物理属性
图 5. 消息类型的逻辑和物理属性

对于消息的第一部分,即函数 ID,创建简单元素 Prefix 并设置其逻辑属性,如下面的图 6 所示,保留其余属性的默认值。函数 ID 文本被设置为固定值。如果消息树中缺少元素,则会将固定值插入到位流中,以便保留消息结构。

图 6. Prefix 元素的逻辑属性
图 6. Prefix 元素的逻辑属性

添加 Prefix 元素之后,添加三个长度为零的虚拟局部元素作为占位符,强制系统在分隔的第四个逗号之后生成生成三个逗号。

对于消息的其他两个部分,创建一个包含消息其他两个部分(消息标题和业务参数)的复杂类型。假设类型名称为 _822b_Req_Body_t,设置该复杂类型的物理属性,如下图 7 所示。 向类型为 _822b_Req_Body_t 的主消息添加一个局部元素(在图 4 中,该元素名为 ReqVariables)。

图 7. 复杂类型 _822b_Req_Body_t 的物理属性
图 7. 复杂类型 _822b_Req_Body_t 的物理属性

消息最后两个部分使用复杂类型的两个元素建模。每个部分都包含一个有序的固定长度元素序列。图 8 显示了其中一个部分的物理属性,即针对业务参数 _822_Request_businessParams_t 的那一部分:

图 8. 复杂类型 _822_Request_businessParams_t 的物理属性
图 8. 复杂类型 _822_Request_businessParams_t 的物理属性

标记/分割的有序或无序文本消息

下面的清单 5 显示了带有无序元素的标记/分隔字符串 (TDS) 格式的银行系统消息之一。消息的一个重要规范是,根据参数值的模式,可能会错过任何标记元素。消息的第一部分(从开始到三个逗号处)表示函数 ID。不过这次它包含一个逗号,将 ID 划分成两个子部分。因此,在消息模型中它由两个元素(而非一个元素)表示,即 Prefix1 和 Prefix2。函数 ID 与消息第二部分之间的两个额外逗号是使用与固定长度消息示例相同的方式进行处理的,即插入虚拟元素:

清单 5. 具有标记/分割的无序元素的消息
FUNDS.TRANSFER,/I/PROCESS,,,
SRC.CHANNEL::=IVR,INT.TIME.STAMP::=00000000000000,MIDDLE.WARE.ID::=
0000000000000000000000021345678900987654321100450635090876523212131167890,MESS.TYPE::=
255,MSG.SUB.TYPE::=01,MSG.QUALIFIER::=0,INT.MSG.NUM::=2134567890098765432110045000
9090876523212131167890,FORCE.POST.FLAG::=0,CUSTOMER.NO::=703154,DEBIT.ACCT.NO::=
1588180024,DEBIT.CURRENCY::=AED,DEBIT.AMOUNT::=10000,CREDIT.ACCT.NO::=
0580079572,CREDIT.CURRENCY::=EGP,EQU.EGP.AMT::=10000,CHARGES.ACCT.NO::=
1588650075,CHARGE.AMT::=GBP10,CHARGE.TYPE::=CORRBKCHG

下图 9 显示了 TDS 示例的消息模型。由于消息标题和业务参数都使用同样的分隔符加以标记和分割,所以它们被封装在 TagValFields 元素的同一复杂类型中:

图 9. Message Broker 消息集中的消息模型
图 9. Message Broker 消息集中的消息模型

下图 10 显示同时包含消息标题和业务参数的复杂类型的逻辑和物理属性。如图所示,对于逻辑属性,将 Composition 设置为 unorderedSet。对于物理属性,将 Data Element Separation 设置为 Tagged Delimited,并选择一个逗号作为 Delimiter(不同元素的分隔符)。然后将 Tag Data Separator 设置为消息示例中所示的三个字符 (::=)。为其余的逻辑和物理参数保留默认设置:

图 10. TDS 复杂类型的逻辑和物理属性
TDS 复杂类型的逻辑和物理属性
图 10. TDS 复杂类型的逻辑和物理属性
图 10. TDS 复杂类型的逻辑和物理属性

在下面的图 11 中,您可以看到构成复杂类型(同时包含消息标题和业务参数)的元素的一个样例元素(IntTimeStamp 元素)的物理属性。这里您可以设置标记和其余物理表示属性。这里的标记是将在消息中出现的元素名称,而非图 9 中所示的元素名称,该名称只会出现在逻辑树中,换言之,出现在 Message Broker 内部。

图 11. 简单元素 IntTimeStamp 的物理属性
图 11. 简单元素 IntTimeStamp 的物理属性

ISO 8583 消息

ISO 8583 是银行和金融服务部门的一个 ISO 标准,它指定用于在设备与发卡机构之间互换信用卡和借记卡信息的一个公共接口。SO 8583 通常用于定义与销售点 (POS) 设备或自动提款机 (ATM) 交换的数据的消息格式。

developerWorks 文章 使用 WebSphere Message Broker 集成 TCP/IP 解释了 ISO 8583 的概念和用途。另一篇 developerWorks 文章 使用 WebSphere Message Broker 集成安全的 ATM 银行系统 介绍了其他细节,包括 64 元素 ISO 8583 消息的扩展,以及用来避免集成问题的一些建议。

使用 ISO 8583 消息的业务集成开发人员或设计人员必须知道消息模型是如何创建的,这样一来他们就可以自己创建或定制一个可重用模型,将它用于特定用途。这一部分将从消息集的角度描述 ISO 8583。

ISO 8583 消息是固定长度的物理文本消息,包含一些二进制十六进制元素。每当您收到一条 ISO 8583 消息时,您必须解释主位图,以便可以使用它来解释其余消息。主位图是一个 8 字符元素。如下图 12 所示,消息模型包含一个名为 PrimaryBitmap 的复杂类型元素,使用它作为第一个元素。如下图 13 所示,这个复杂类型包含 64 整数元素,每个元素都对应于 8 字符位图的一个位元。您的 ESQL 代码必须检查收到的 8 字符元素的每个位元,并填写相应的整数元素。如果您用收到的消息中生成的 64 整数复杂元素来替换二进制位图,那么可以使用图 12 中的消息模型来分析它。

图 12. ISO 8583 消息模型的一部分
图 12. ISO 8583 消息模型的一部分

分析器如何使用模型来解释消息呢?要了解这一过程,首先来看一下模型元素的属性是如何设置的。以 PrimaryAccountnumber 元素为例。使用可变长度的元素(允许用户确定长度),ISO 8583 创建了一个复杂类型元素,其中包含一个长度整数元素,后面紧接着元素本身。PrimaryAccountnumber 元素采用的就是这种模式,即一个长度元素后面紧接所需的元素本身。

图 13. PrimaryBitmap 复杂类型的一部分
图 13. PrimaryBitmap 复杂类型的一部分

图 14 显示了复杂类型元素 PrimaryAccountnumber 的物理属性部分。要关注的属性是 Repeat Reference,选择该属性的值,以指向 PrimaryBitmap 元素的子元素,PrimaryBitmap 元素与所述元素 (PrimaryAccountnumber) 具有相同的索引。由于该元素是消息模型中的第三个元素,它对应于位图(从 Bit0 开始)的 Bit2 元素。当 PrimaryBitmap 元素的 Bit2 子元素有一个非零值时,这一选择使得分析器将消息中的第三个元素分析为 PrimaryAccountnumber 元素。

图 14. ISO 8583 消息元素的物理属性部分
图 14. ISO 8583 消息元素的物理属性部分

要了解分析器如何检测长度值元素(比如 PrimaryAccountnumber 元素)的长度,参见下面的图 15,其中显示了子元素 PrimaryAccountnumber 的重要物理属性。对于属性 Length Reference,可以选择包含长度值的元素名称,即 Length 元素。分析器从固定长度元素 Length 的值中获取 PrimaryAccountnumber 元素的长度。

图 15. 一个可变长度元素的部分物理属性
图 15. 一个可变长度元素的部分物理属性

结束语

本文展示了 WebSphere Message Broker 中的消息建模如何简化集成工作并利用其高效的分析器。本文重点介绍了三个物理消息类型,展示了如何轻松地为这些复杂格式消息样例创建消息模型,这些样例包括固定长度的文本消息、标记/分隔的字符串消息和 ISO 8583 标准消息(固定长度文本消息的一个特例)。

参考资料

学习

获得产品和技术

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=839483
ArticleTitle=使用 WebSphere Message Broker 集成具有高度复杂的消息格式的系统
publish-date=10082012