使用 WebSphere DataPower 和 WebSphere MQ File Transfer Edition 管理文件传输

WebSphere® DataPower Firmware V4.x 引入了一个新的特定于 WebSphere MQ File Transfer Edition 的协议处理器,该处理器允许在两个产品之间进行更好的集成。Firmware V5.x 引入了扩展的内存支持,因此消除了针对大型文件的一些限制。本文将向您展示如何集成 DataPower 和 WebSphere MQ FTE。

Stefano Zampieri, 解决方案架构师, IBM

Stefano Zampieri 的照片Stefano Zampieri 是一名解决方案架构师和一个 WebSphere 专家,在 J2EE 和 WebSphere 基础产品(比如 WebSphere Application Server 和 WebSphere MQ)方面有超过 12 年的经验。他在 IBM 的不同部门担任过从 IT 专家到 IT 架构师的许多不同职业。Stefano 目前致力于 IBM Software Services for WebSphere 方面的工作。在最近 4 年,他的研究重点主要是 WebSphere DataPower、B2B、SOA 和 Enterprise Application Integration。



Phil J. Bareham, 高级 IT 专家, IBM

Phil Bareham 的照片Phil Bareham 是一名高级 IT 专家,他从 WebSphere MQ FTE 发布第一个版本起就开始接触它。Phil 从事 IT 行业已有 27 年,其中的 17 年一直在为 IBM 效力。在过去几年,Phil 执行过从 CICS 应用程序代码到 WebSphere Application Server 和 WebSphere Process Server 配置的各种角色。在过去 10 年,他主要致力于 WebSphere MQ、WebSphere Message Broker、WebSphere Business Events 和 WebSphere Process Server on Windows, Unix, and z/OS。



2012 年 11 月 19 日

简介

本文将描述如何集成 WebSphere DataPower 和 WebSphere MQ File Transfer Edition (FTE)。在撰写本文时,大多数可用文档已过时,而且这些文档主要关注于 B2B 上下文中的托管文件传输的使用。DataPower firmware V4.x 引入了一个新的特定于 WebSphere MQ FTE 的协议处理器,该处理器允许在两个产品之间进行更好的集成。Firmware V5.x 引入了扩展的内存支持,因此消除了针对大型文件的一些限制。

WebSphere MQ FTE 和 DataPower 是补充性产品,因为前者旨在集中管理安全企业领域内的文件传输,而后者可以充当安全网关,并扩展了连接到不同安全领域 的连接性。图 1 显示了典型的 DataPowe 网络部署,其中 DataPower 位于 DMZ 之中,充当 WebSphere MQ 网络和外部合作伙伴之间的网关。

图 1. DataPower 网络部署
DataPower 网络部署图

B2B Gateway Service 与 Managed File Transfer 中的 Multi-Protocol Gateway

在 Firmware 4.0.0 之前,DataPower 和 WebSphere MQ FTE 之间的集成主要基于共享文件系统。该集成在许多上下文中是足够用的,但不足以利用任何 WebSphere MQ 高级功能,比如事务性和有保证的交付 (assured delivery)。此外,B2B Transaction Viewer 并没有完全与 WebSphere MQ FTE 集成在一起。

目前,FTP 和 SFTP 通常用于传输 B2B 文档。所以,通过 B2B Gateway 来集成 WebSphere MQ FTE 和 DataPower 是最常见的用例。有关的更多信息,请参阅文档 WebSphere DataPower Release 4.0.1 B2B MQFTE

B2B Gateway Service (B2BGW) 仅可用于 “XB*” 模型之上,它支持一些很受欢迎的 B2B 消息协议,比如 EDIINT AS1、AS2、AS3 和 ebMS v2.0。它能够恰当管理文件传输,将此作为 B2B 事务的一部分,并将操作记录到永久性存储器中,将 FTE 元数据与 B2B Transaction Viewer 集成在一起。

B2B Gateway 还提供了通过 “业务合作伙伴” 对象来组织文件路由的能力。此概念是一个抽象概念,允许将业务合作伙伴信息存储到贸易合作伙伴的配置文件中,利用这些信息在双方之间实施贸易合作伙伴协议,并提供合作伙伴身份与一个或多个目标 URL 之间的逻辑链接。

此处的要点是:在此配置中,采用流化 (streaming) 是不可能的,并且文件总是缓存在内存中。即使将某个大型文件分割成许多小文件,并将这些小文件存储在许多 WebSphere MQ 消息中,在处理该文件之间,B2BGW 仍然会在内存中重新构建整个文件。

考虑到 B2BGW 的特征,在设计阶段,有一些关键方面需要考虑:

  • 协议
  • 与 B2BViewer 的集成
  • 文件大小
  • 审计
  • 事务处理率
  • 事务性和错误处理
  • 容量规划以及 B2B 元数据和有效负载的保留期限

协议非常重要,因为如果外部合作伙伴使用了特定于 B2B 的协议(比如 AS/1/2/3 协议),则不存在 B2B 网关服务的替代物。如果与 B2BViewer 的集成是解决方案的一个主要要求, 或者客户想要使用配置文件管理或对 B2BGW Service 独一无二的查看能力,那么也不存在 B2B 网关服务的替代物。

下一个要考虑的关键元素是文件大小。对于非常大的文件而言,Multi-Protocol Gateway (MPGW) 通常是一个不错的选择,因为它支持流化,在默认情况下不会保存消息有效负载。不过,MPGW 无法提供展示事务状态的视图,也无法使用配置文件管理。

上述关键元素带来了另一个考虑因素:审计。如上所述,B2BGW 被设计用于关键 B2B 事务。默认情况下,它们提供了一组丰富的功能,比如事务审计,还为 B2B Transaction Viewer 提供了元信息。

MPGW 是更为简单的一些对象,它们没有提供内置审计功能。任何处理(包括记录和审计)都需要显式配置和一些(通常最少的)XSLT 编码。

除了流化的能力之外,通过支持高事务处理率,MPGW 的简单性和灵活性带来了另一个好处。MPGW 执行的事务通常比 B2BGW 多一些,因为它们不会保留任何元数据或有效负载。

需要考虑的最重要的一个方面是针对事务性和错误处理的需求,这些目前可以依赖于传统的 DataPower-MQ 集成特性,比如工作单元和恢复设置。有关事务性和错误处理更改的具体细节取决于传输的方向(如果 WebSphere MQ 是文件的源或目标) ,这些内容将在本文的后面部分详细讨论。

表 1 总结了在选择 B2B Gateway 或 Multi-Protocol Gateway 以及集成 DataPower 和 WebSphere MQ FTE 时需要考虑的主要元素。

表 1. 选择 B2BGW 与 MPGW
B2BGW(仅适用于缓冲模式)MPGW(缓冲模式)MPGW(流模式)
支持 B2B 协议,比如 EDIINT AS1、AS2、AS3 和 ebMS v2.0.支持 WebSphere MQ FTE 协议的平台,但 B2BGW 不可用(XI* 和 XG*)。高网络延迟
要使用 B2B Transaction Viewer高事务处理率“扩展的内存支持” 不可用,并且文件大小要大于 100 MB。
内置审计或者 “扩展的内存支持” 不可用,并且文件大小要大于 3 GB。
限制
在处理高事务性有效负载(许多小消息)时,BB2GW 可能比 MPGW 慢无 B2B Transaction Viewer无 B2B Transaction Viewer
不支持流化。AS1/2/3 不受支持。AS1/2/3 和 ebMS 均不受支持。
仅在 XB* 上可用需要在处理策略中实现审计复杂的处理策略可能会打破流和有限的审计功能
HA 和 DR 对于 B2BGW 而言要比对于 MPGW 更复杂一些

事务性和消息持久性

WebSphere MQ FTE 使用 WebSphere MQ 基础架构跨企业移动文件。出于性能方面的原因,WebSphere MQ FTE 被设计为使用文件传输数据的非持久性消息来可靠地移动文件。持久性消息传递用于最初的 WebSphere MQ FTE 代理,以便完成代理握手 (agent handshake) ,并在代理之间传输重启消息。在使用 “fteCreateTransfer” 命令将文件移动到某个队列时,默认情况下,消息是持久性的。此时,传输是从 WebSphere MQ FTE 透视图完成的。如果消息不是持久性的,并且 Queue Manager 在完成 FTE 传输之后、启动 DataPower 之前出现故障, 那么文件会从系统中消失,并且不会出现任何显式传输错误。

使用持久性消息对 Queue Manager 调优有重大的影响,如文章 Configuring and tuning WebSphere MQ for performance on Windows and UNIX 中所述,这篇文章特别提到,持久性消息需要针对 Queue Manager 日志进行适当调优。这非常重要,因为在我们的经验中,Queue Manager 上没有充足的日志空间是导致出现错误的最常见原因。

在调优 Queue Manager 日志时,导致出现错误的另一个原因是:在 B2B 上下文中,通常在某个事务中使用消息。这意味着最终提交仅发生在 DataPower 已经完成到目标系统的文件传输时,这使得事务有可能会悬停一段时间 ,具体时间取决于总文件大小和网络延迟。

最后要注意的是,选择正确的持久性设置对于每个队列而言至关重要,因为,在默认情况下,DataPower 会根据队列设置来设置消息持久性。为了进行更好的控制,可能会通过显式设置处理策略中的 MQ Message Descriptor (MQMD) 标头内的持久性标志来覆盖 DataPower 的默认行为。默认队列持久性对于 WebSphere MQ FTE 并不是很重要,因为设计 WebSphere MQ FTE 是为了优化持久性消息的使用。

配置示例

本文将重点介绍一些典型的用例:

本文将引用下列基本配置:

  • 具有 B2B Gateway 和 Multiprotocol Gateway 的 DataPower XB62
  • 安装了 WMQFTE 来充当内部合作伙伴的 VMware 映像
  • 一个使用 FTP Server 和客户端来充当外部合作伙伴的额外的 VMware 映像

对于此配置,我们将使用普通的协议。在真实的生产环境中,已通过加密技术保护所有的通信。

这个 DataPower 配置极为简单,在讨论用例的时候,我们会重点讨论有关它的一些细节。

WebSphere MQ FTE 配置

在任何 WebSphere MQ FTE 配置中,您都必须拥有:

  • 一个 WebSphere MQ Queue Manager,被指定为 WebSphere MQ FTE Coordination Queue Manager。Coordination Queue Manager 使用 WebSphere MQ 队列来处理文件传输和 WebSphere MQ 发布 / 订阅,以便存储与该配置有关联的 WebSphere MQ FTE Agent 的相关信息。WebSphere MQ FTE Coordination Queue Manager 必须位于 WebSphere MQ V7 或其更高版本上,以便获得所需的发布 / 订阅功能。
  • 一个或多个充当 WebSphere MQ FTE Command Queue Manager 的 WebSphere MQ Queue Manager。Command Queue manager 用于将命令请求传递给 WebSphere MQ FTE。
  • 一个或多个充当 WebSphere MQ FTE Agent Queue Manager 的 WebSphere MQ Queue Manager。Agent Queue Manager 提供了使用 WebSphere MQ 消息来支持代理之间的文件传输所需的 WebSphere MQ 队列。
  • 一个或多个执行文件传输的 WebSphere MQ FTE Agent。每个代理都连接到一个 Agent Queue Manager。一个 Agent Queue Manager 可以支持许多代理。

我们的 WebSphere MQ FTE 配置使用了 WebSphere MQ V7.0.1.8 和 WebSphere MQ FTE V7.0.4.1。所有 WebSphere MQ 和 WebSphere MQ FTE 组件都运行在 Windows® 之上。在发布 WebSphere MQ V7.5 之后,WebSphere MQ FTE 成为了 WebSphere MQ 7.5 的一个可选组件,并被称为 "WebSphere Managed File Transfer"。

我们在 Windows 上使用了一个简单的 WebSphere MQ FTE 配置来测试上面所述的 DataPower to WebSphere MQ FTE 用例。此配置包含一个名为 FTE_QM 的 WebSphere MQ Queue Manager,它实现了上述 Coordination、Command 和 Agent Queue Manager 的角色。这个 FTE_QM 是使用三个主要日志文件和两个从属日志文件的默认循环日志分配来创建的。我们发现,在开始传输大型文件时,必须创建这个 FTE_QM 。在生产配置中,拥有连接到许多不同的代理队列管理器的代理的情况更为普遍。

在 FTE_QM 上,我们将两个 WebSphere MQ 队列定义为 "FTE_TO_B2BGW" 和 "FTE_TO_MPGW"。这些队列被用作在 AGT1_FTE_FROM_FILE 和 AGT3_DP_FTE_QM 之间发起的 File-to-Queue 传输的目标队列。 然后,通过 DataPower 读取放置在这些队列上的消息,以便将它们传输到最终目标。每个队列都有一个恢复队列:对于 FTE_TO_B2B,该队列是 "B2B_BACKOUT",对于 FTE_TO_MPGW,该队列是 "MPGW_BACKOUT"。

一个名为 "DP_TO_FTE" 的额外队列是为了完成 DataPower 和 FTE 之间的传输而创建的。此队列的默认持久性标记被设置为 “persistent”。

然后,我们在同一个 Windows 机器上创建了三个 WMQ_FTE 代理,如下所示:

  • AGT1_FTE_FROM_FILE:这是源代理,用于完成从 WebSphere MQ FTE 到 DataPower 的传输。此代理用于传输将从 Windows 文件系统传输的源代码。
  • AGT2_FTE_TO_QUEUE_FOR_DP:这是目标代理,用于完成从 WebSphere MQ FTE 到 DataPower 的传输。在进行 File-to-Queue 传输时,从 AGT1_FTE_FROM_FILE 传输的文件被发送到此代理,这导致文件是作为一组 WebSphere MQ 消息到达目标队列。此队列由 DataPower 框监视,当组中包含的所有消息都到达时,DataPower 会处理 DataPower 中定义的最终目标上的传输。在我们的用例中,WebSphere MQ FTE to DataPower 的最终目标是一个 FTP 服务器,运行在来自 WebSphere MQ 和 WebSphere MQ FTE 的单独 Windows 机器之上。要启用 file-to-queue 传输,需要在 AGT3_DP_FTE 的 agent.properties 文件中将属性 enableQueueInputOutput 设置为 "true"。
  • AGT3_DP_TO_FTE:这是从 DataPower 到 WebSphere MQ FTE 的传输的源代理。此文件由 DataPower 读取,随后作为一条 WebSphere MQ 消息发送到某个 WebSphere MQ 队列。该队列由 WebSphere MQ FTE Monitor 进行监视。在消息到达队列时会启动 WebSphere MQ FTE 传输。该代理是这个已触发的传输中的源代理,而 AGT1_FTE_FROM_FILE 是目标代理。

有三个 WebSphere MQ FTE 代理连接到 FTE_QM 代理的 Queue Manager,该连接是使用交叉内存(或绑定)连接来实现的,而不是用 WebSphere MQ 客户端连接来实现的。所有三个代理都被定义为一项 Windows 服务来运行。图 2 显示了 WebSphere MQ FTE 配置,突出显示了代理、队列管理器和队列。

图 2. WebSphere MQ FTE 配置
WebSphere MQ FTE 配置

WebSphere MQ FTE to MPGW 交互也与此类似。不同之处在于,用于出站传输的 WebSphere MQ 队列是 "FTE_TO_MPGW"。

用例 1:使用 B2BGW 完成出站文件传输

B2BGW 路由目前已经有了良好的定义,WebSphere DataPower Release 4.0.1 B2B MQFTE 文档对它进行了描述。

第一步是创建一个内部合作伙伴和一个外部合作伙伴。对于外部合作伙伴,需要添加一个 FTP 目标。对于内部合作伙伴,需要添加一个 WebSphere MQ FTE 目标。

以下是管理部分文件传输的良好实践:在 WebSphere MQ FTE 目标 URL 上启用事务性,并在完成 FTP 目标的传输之后对文件 进行重新命名。

类似地,可以创建一个 WebSphere MQ FTE 前端处理器,以便从内部合作伙伴那里获取文件,还可以创建一个 FTP 服务器 FSH,以接受来自外部合作伙伴的文件。

最后一步是创建一个 B2BGW,通过添加两个前端处理器和两个业务合作伙伴可完成此操作。

WebSphere MQ FTE 文件传输将包含以下标头:

  • DPMQFTESenderID:内部合作伙伴的业务 ID
  • DPMQFTEReceiverID:外部合作伙伴的业务 ID
  • DPMQFTEContentType:消息有效负载的内容类型

清单 1 中给出了一个示例。

清单 1. 包含 DPMMQFTE 标头的 fteCreateTransfer
 fteCreateTransfer -sa AGT1_FTE_FROM_FILE -da AGT2_FTE_TO_QUEUE_FOR_DP -dm FTE_QM 
 -dq FTE_TO_B2BGWGW@FTE_QM -dqp true -qmp true -md DPMQFTESenderId=InternalPartner, 
 DPMQFTEReceiverId=ExternalPartner,DPMQFTEContentType=application/binary -qs 1M 
 -t binary c:\temp\file03.bin

在清单 1 所示的 fteCreateTransfer 命令中,– sa 和 – da 分别是源 (AGT1_FTE_FROM_FILE) 和目标 (AGT2_FTE_TO_QUEUE_FOR_DP) WebSphere MQ FTE 代理。-dm 表示目标 Queue Manager (FTE_QM),而 -dq 表示目标对象名称 (FTE_TO_B2BGW),它还确定了这是一个 File to Queue 传输。"-dqp true" 确定了放入目标队列中的消息将是持久性消息。"-qmp true" 暗示着写入目标队列中的第一条消息将拥有消息属性设置。

后面的值 – md 是传递到 WebSphere MQ FTE 中的名称 - 值对。最后,"-qs 1m" 用于告诉 WebSphere MQ FTE 将该传输拆分成多个来自 WebSphere MQ 消息组的消息。该消息组的最大消息大小为 1MB。我们发现,如果我们没有对大型文件使用 – qs 设置,那么 WebSphere MQ FTE 传输就会失败,错误原因代码为 2030,即 MQRC_MSG_TOO_BIG_FOR_Q。为了防止这种错误,我们调整了 FTE_QM Queue Manager 和 FTE_TO_B2BGW 队列上的最大消息大小设置。这个 MAXMSGL 设置的默认值为 4Mb 。关于更改 WebSphere MQ MAXMSGL 设置和 WebSphere MQ FTE maxInputOutputMessageLength 代理属性的一些信息,可以在 Guidance for setting WebSphere MQ and WebSphere MQ File Transfer Edition properties associated with message size 中找到。

在 DataPower Queue Manager 对象上已经启用了 Unit-Of-Work (UOW),参见图 3。在出现错误时,系统会重新尝试传输,直到到达恢复计数,然后会将文件移动到恢复队列中。鉴于该文件是先在内存中进行装配,然后推入队列中,所以,恢复队列中的消息的大小可能不同于请求队列中的消息 大小,这丝毫不令人感到奇怪。

图 3. DataPower Unit of Work 配置
如何启用 DataPower Unit of Work 配置

最后,值得注意的是,WebSphere MQ FTE 协议处理器中的 GMO 设置是通过 DataPower Queue Manager Object 中的设置进行覆盖的。在启用 UOW 时,会在同步点 (syncpoint) 下使用消息,无需考虑其持久性,反之亦然。

WebSphere MQ FTE 可以有选择地将传输细节记录到数据库中。DataPower B2B Transaction Viewer 可以通过在 B2B Gateway 的高级面板上配置 DataSource 对象来检索和可视化该信息,将此作为文件传输的一部分。

因为 B2BGW 只可以引用记录器 DB,所以通过相同 DataPower 服务 的入站和出站流被记录在同一个记录器中。

用例 2:使用 MPGW(流化) 完成出站文件传输

这可能是最简单的配置。在 DataPower 端,有一个具有动态后端协议处理器和 WebSphere MQ FTE 前端协议处理器的多协议网关。

因为此配置的目标是流化大型文件,所以处理策略通常极为简单,如图 4 所示。

图 4. DataPower 规则的定义
MPGW DataPower 规则的定义

所需的最小处理是设置一个目标。WebSphere MQ FTE 代理可以使用 RFH 标头将元数据传递给 DataPower,DataPower 可以用于设置目标。

清单 2 中所示的示例使用了一个名为 “DPMQFTEDestination” 的自定义标头。MQFTE 使用清单 2 中所示的命令将文件传输到队列中。

清单 2. 使用了 DPMQFTEDestination 标头的 fteCreateTransfer
 fteCreateTransfer -sa AGT1_FTE_FROM_FILE -da AGT2_FTE_TO_QUEUE_FOR_DP  -dm FTE_QM 
 -dq FTE_TO_MPGW@FTE_QM -dqp true -qmp true 
 -md DPMQFTEDestination=ftp://user:password@xx.xx.xx.xx/foo.Part?Rename=Foo.Complete 
 -qs 1M -t binary c:\temp\file01.bin

为了避免理解错误,WebSphere MQ 队列中的消息(即 WebSphere MQ FTE 传输目标)是持久性的。

在流化已分段的 WebSphere MQ FTE 消息时,让消息大小保持相对较小(小于 1MB)是一种明智的做法。

在本示例中,我们将 DPMQFTEDestination 标头设置成了一个 FTP 服务器,可以使用用户 ID “user” 和密码 “password” 来访问它。该 FTP 服务器位于 IP 地址 xx.xx.xx.xx。文件是在使用名称前缀 “foo.part” 的部件中传输的。在完成传输后,该文件是 "Foo.Complete"。

DataPower 样式表中的路由操作使用了此标头来设置实际目标,如清单 3 所示。

清单 3. 用于 MPGW 路由的 DataPower XML 样式表
 <?xml version="1.0" encoding="UTF-8"?> 
 <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
	 version="1.0" xmlns:dp="http://www.datapower.com/extensions"
	 extension-element-prefixes="dp" exclude-result-prefixes="dp"> 
	 <xsl:template match="/"> 
		 <!-- Get the MQRFH2 headers --> 
		 <xsl:variable name="MQRFH2" select="dp:request-header('MQRFH2')" /> 
		 <!-- Parse the MQRFH2 headers to XML format --> 
		 <xsl:variable name="parsedMQRFH2" select="dp:parse($MQRFH2)" /> 

		 <!-- log MQRFH2 --> 
		 <xsl:message dp:priority="debug"> 
			 <xsl:copy-of select="$parsedMQRFH2" /> 
		 </xsl:message> 
		
		 <!-- extract destination URL --> 
		 <xsl:variable name="finalDestination"
		 select="$parsedMQRFH2//DPMQFTEDestination"></xsl:variable> 

		 <!-- set destination --> 
		 <dp:set-variable name="'var://service/routing-url'"
		 value="$finalDestination" /> 
	 </xsl:template> 
 </xsl:stylesheet>

对于 MPGW 设置,请求类型为 NON-XML,响应被设置为 “Pass-Thru”,启用了流控制,请求和响应都被流化,如图 5 所示。

图 5. 用于流的 DataPower 配置
用于流的 DataPower 配置

如上所述,DataPower Firmware V5.x 引入了扩展的内存支持,这极大地减少了对流化的需求。不过,对于非常大的文件(超过 1GB),流化可能仍然是最佳选择。您需要考虑的是,在缓冲模式下,从 FTE 到 DataPower 和从 DataPower 到 FTP Server 这两种传输 有着严格的顺序。但是,在流化模式下,两种文件传输大多数情况下是并行发生的,这减少了总体延迟时间。

最终,此服务 没有 与 B2BViewer 集成在一起。

用例 3:使用 B2BGW 完成入站文件传输

DataPower 配置与 用例 1 中描述的相同。

此时,路由(不容易 partnerID 的识别)遵从常用的 B2BGW 模式。对于通用的二进制文件,需要定制 b2b 路由样式表。在我们的示例中,我们将根据源 IP 来确定外部合作伙伴,根据目标目录来确定内部合作伙伴。

内部合作伙伴目标是一个 WebSphere MQ FTE URL。请注意,DataPower 包含在消息中,最终目标包含在 WebSphere MQ FTE 网络中,典型的 WebSphere MQ FTE 目标与清单 4 类似。

清单 4. 使用 DataPower MQ Q-Manager 对象时的 mqfte 后端 URL
 dpmqfte://FTE-QM/?RequestQueue=DP_TO_FTE&DestAgent= 
 AGT3_DP_TO_FTE&DestQM=FTE_QM&DestFile=dummyPath&Transactional=true

所需的 URL 参数包括:

  • DestAgent:WebSphere MQ FTE 网络中的目标代理,负责接收消息。
  • DestQM:目标对象管理器,源代理会将消息发送给它。
  • DestFile:文件的名称,目标代理在该文件中存储了一个已接收的消息。

对于此用例,我们创建了第三个 WebSphere MQ FTE 代理,名为 "AGT3_DP_TO_FTE",并再次将它作为一个 Windows 服务运行,在 agent.properties 文件中将属性设置为 "enableQueueInputOutput=true",以便启用 Queue-to-File 传输。WebSphere MQ FTE 需要监视 DataPower 用来将内容写入其中的目标 WebSphere MQ Queue,并触发一个 WebSphere MQ FTE 传输来处理该文件。为此,我们使用清单 5 中所示的 fteCreateMonitor 命令创建了一个 WebSphere MQ FTE 监视器。

清单 5. 用例 3 的 fteCreateMonitor 命令
 FteCreateMonitor.cmd -ma  AGT3_DP_TO_FTE   -mq DP_TO_FTE -mn XB62_Monitor 
 -mt D:\Products\WMQFTE\Datapower\Stefano\XB62_Monitor.xml -pi 10 -pu seconds 
 -tr completeGroups

在此命令中,– ma 表示监视代理的名称,被设置为 "AGT3_DP_FTE_QM"。我们为此用例创建的代理被用作是已触发的传输的源代理。DP_TO_FTE 的 – mq 值是将要监视的 WebSphere MQ Queue 的名称,它是从 DataPower 进行的传输的目标。

– mn 是将要创建的监视器的名称,在此用例中,该监视器为 "XB62_Monitor"。– pu 被设置为 seconds,然后 10 的 – pi 值设置了轮询间隔秒数。completeGroups 的 – tr 值指定:仅在整组 WebSphere MQ 消息都到达监控队列之后,才能对 – mt 值中定义的 WebSphere MQ FTE 传输命令进行初始化。WebSphereMQ FTE 传输命令(已在消息组完整时提交)是在通过 – mt 参数指定的监视器任务定义文件中定义的。在我们的场景中,这是一个 XML 文件,包含清单 6 中所示的内容。

清单 6. FTE 监视器任务定义 XML
 <?xml version="1.0" encoding="UTF-8"?> 
 <request version="5.00" 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
 xsi:noNamespaceSchemaLocation="FileTransfer.xsd"> 
  <managedTransfer> 
    <originator> 
      <hostName>xxx.xxx.xxx.xxx</hostName> 
      <userID>fteuser</userID> 
    </originator> 
    <sourceAgent QMgr="FTE_QM" agent="AGT3_DP_FTE_QM"/> 
    <destinationAgent QMgr="${DPMQFTEDestinationQM}" agent="${DPMQFTEDestinationAgent}"/> 
    <transferSet> 
      <item checksumMethod="MD5" mode="binary"> 
        <source disposition="delete" recursive="false" type="queue"> 
          <queue>DP_TO_FTE</queue> 
        </source> 
        <destination exist="overwrite" type="file"> 
          <file>d:\temp\FromXB62\${DPMQFTEDestinationFile}</file> 
        </destination> 
      </item> 
    </transferSet> 
  </managedTransfer> 
 </request>

此文件是使用 fteCreateTransfer 命令上的 – gt 选项创建的。使用 – gt 选项创建此文件是确保格式正确的最简单方法。 然 后 ,您可以根据需要修改已生成的任务定义,尤其是变量替换。

在上面所示的任务定义中,sourceAgent 定义了源 WebSphere MQ FTE 代理。这与用于传输的 Queue Manager 有关,该传输会在来自 DataPower 的 一组消息到达之后进行初始化。在本例中,这些代理分别是 AGT3_DP_TO_FTE 和 FTE_QM。destinationAgent 定义了目标代理的名称,并且该代理是用于传输的 Queue Manager。在上述示例中,Queue Manager 被设置为 “${DPMQFTEDestinationQM}”,代理被设置为 “${DPMQFTEDestinationAgent}”。在运行的时候,可以使用通过 DataPower 设置的变量 DPMQFTEDestinationQM 和 DPMQFTEDestinationAgent 的值来代替这些值。

最后, 目标文件的名称是在 “file” XML 标志中定义的。此时,路径被硬编码为 “d:\temp\FromXB6\”,但文件名称本身是通过变量 DPMQFTEDestinationFile 设置的。

需要重点注意的是,在默认情况下,DataPower 使用默认队列持久性来存放消息。所以,需要小心设置它们。

持久性消息要求对 Queue Manager 日志进行小心调整,但它可以将您从 Queue Manager 崩溃中拯救出来。另一方面,非持久性消息表现得更好一些,但文件可能会莫名其妙地消失。

用例 4:使用 MPGW(流化)实现入站文件传输

此场景中的 WebSphere MQ FTE 配置与前一场景中的配置完全相同。

主要差别在于:DataPower 路由不再基于 Business Partner ID,而是基于处理策略中的一些逻辑。

此配置支持针对传入文件的流化,非常适合大型文件传输。

结束语

本文描述了集成 DataPower 和 WebSphere MQ FTE 时在 B2BGW 与 MPGW 之间进行选择的一个明确标准。还提供了工作配置的一些简单示例。

致谢

作者非常感谢 Richard KinardAdrian Preston 对本文所做的贡献和评审。

参考资料

学习

获得产品和技术

讨论

条评论

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=846257
ArticleTitle=使用 WebSphere DataPower 和 WebSphere MQ File Transfer Edition 管理文件传输
publish-date=11192012