将IBM WebSphere DataPower SOA设备与WebSphere MQ集成的最佳实践

最新推荐文章于 2023-01-17 11:01:18 发布

cuxiong8996

最新推荐文章于 2023-01-17 11:01:18 发布

阅读量554

点赞数

文章标签：队列数据库 java entity 大数据

原文链接：https://www.ibm.com/developerworks/websphere/library/techarticles/1410_sahoo/1410_sahoo.html

版权

IBM WebSphere DataPower SOA设备（以下称为DataPower）是专用的计算设备，可为许多服务提供集成端点。此类服务包括WebSphere MQ，使用Java™消息服务（JMS）的WebSphere Service Integration Bus，WebSphere Service注册和存储库（WSRR），TIBCO企业消息服务（EMS），轻型目录访问协议（LDAP）以及数据库服务器。这些集成功能旨在为企业提供快速安全的业务解决方案部署。此外，DataPower固件和硬件组件已优化，可使用这些集成服务端点更快地执行业务策略和事务。

DataPower提供了用于开发配置构件的编程模型。这些工件包括控件，例如服务对象，处理策略，规则，操作，客户端协议处理程序和URL打开器，这些控件可使用Web图形用户界面（webGUI）轻松创建业务应用程序。例如，您可以将多协议网关（MPGW）服务配置为通过访问集中式LDAP服务来实施安全策略，或者通过使用使用MQ队列管理器（mq-qm）对象和MQ前端的MPGW服务来处理消息。后端MQ服务器的侧面处理程序（FSH）。这些DataPower对象需要可以提供最佳性能的配置，并提供保护以防止过度使用设备中的CPU，内存和连接等资源。本教程讨论了将DataPower对象与MQ服务器集成以有效处理各种流量模式的最佳实践。

通过MQ队列管理器对象“ mq-qm”和MQ前端处理程序对象提供DataPower中的MQ集成端点。因此，有必要提供这些对象并为这些对象的各种属性提供配置设置，这些设置与与MQ集成产品的最佳实践相一致。

配置DataPower mq-qm对象

mq-qm对象是为MQ提供连接功能的主要组件。它管理连接池的大小和空闲超时。当未建立与后端MQ服务器和同步点流的连接时，它将重试该行为。图1展示了mq-qm对象的各种属性。必需的属性用星号标记，该星号可以提供与MQ服务器的连接。然而，关键的属性，用红色标识，这不应该使用默认设置。如果为这些属性配置了最佳实践建议的值，则它将为设备提供保护并提高性能。您可以将mq-qm对象与多协议网关或Web服务代理服务一起使用来处理MQ通信。

图1. mq-qm对象的配置面板，其中“主要”选项卡用红色突出显示了关键属性

主选项卡提供了几个必填字段，必须提供这些字段才能将mq-qm对象与后端MQ服务器连接。但是，很少有属性需要特别考虑才能配置此mq-qm对象：

最大邮件大小 ：这定义mq-qm对象将处理的邮件的最大大小（以字节为单位）。此值应等于或小于通道和MQ服务器队列的MaxMsgLength属性。大于此大小的邮件将被拒绝。当队列中的消息大小超过此属性的值时，DataPower将显示2010年的MQ返回码（MQRC_DATA_LENGTH_ERROR）。当服务的请求类型为XML或SOAP时，应将关联的XML Manager的“扫描的XML字节数”属性从默认值4194304字节调整为该属性的值，以成功处理消息。
缓存超时：这指定DataPower设备在连接缓存中保留（保持活动状态）连接的秒数。默认值为空字符串。如果在mq-qm对象中使用默认值，则不会关闭连接。因此，重要的是使用一个大于协商的心跳间隔但小于MQ服务器的“ KeepAlive”间隔的值。如果“ KeepAlive”超时未知，则可以为此属性使用60秒的值。请注意，此属性仅与空闲连接有关。如果正在使用连接，则此值不会影响活动的连接。如果找到第一个MQ事务的“连接”错误并处理了后续事务，则该错误主要与默认高速缓存超时值有关。当不活动的连接达到缓存超时阈值时，DataPower设备将从缓存中删除该连接。如果高速缓存不再包含连接，则DataPower设备将与后端MQ服务器创建新连接。
注意： “缓存超时”属性是为DataPower设备配置超时值的唯一方法。 DataPower设备上的其他配置设置无法使MQ连接超时。
工作单位 ：当设置为“ 1”时，它配置同步点流的使用。默认值设置为零，导致设备获取和放置消息而无需回滚。 MQ操作成功与否。无法传递的消息将被静默丢弃，这使更高级别的协议负责检测和重新传输丢失的数据包。设置为1时，DataPower设备使用同步点流，该流允许对每个MQ消息（而不是整个事务）进行MQ提交和回滚。如果配置了同步点流，则DataPower在完成该消息的放置之前不会从队列中删除该消息。当事务失败并且消息留在队列中时，DataPower会重试该消息的MQPUT，直到达到“退出阈值”。如果自动回退设置为“开”，则失败的消息将路由到配置的回退队列。
注意：如果将工作单位设置为1，则应将自动回退配置为“ on”，并在mq-qm对象中指定其关联的回退阈值和回退队列属性。
自动回退 ：这是必需的组“上”单位-的工作时被设定为1。单选按钮允许（ON）或禁止（关闭）毒的消息的自动退出。有害消息是接收方应用程序不知道如何处理的任何消息。通常，当应用程序回滚消息并将其保留在输入队列中时，回退计数（MQMD.BackoutCount）会增加。随着MQ FSH对象继续重新获取消息，回退计数将增加。当回退计数超过回退阈值时，mq-qm对象会将消息移至回退队列。如果禁用，则毒害消息将保留在GET队列上，并继续由MQ FSH重新处理，直到管理GET队列的队列管理器将其删除或设备重新路由有问题的消息为止。这会在设备中创建循环条件，并可能导致设备的内存和CPU使用率激增。最佳实践是将此属性配置为“ on”，以便应用程序可以为有害消息提供存在路径。
回退阈值 ：这指定每封邮件的最大重试次数。在处理期间，计数从0开始，这说明了消息的初始接收。如果初始尝试失败，则将回退计数设置为1。在一次尝试重新处理消息的尝试失败之后，计数设置为2。因此，此属性的值为1表示两次尝试：初始尝试和一次重新处理。尝试。最佳实践是使用值1。对于更高的错误条件容忍度，该值可以大于1。这会导致性能的下降，因为消息的重新尝试次数增加。
注意：如果MQ FSH配置有大于1的并发MQ连接，则此值应设置为等于并发MQ连接+ 1的数字，以便将回滚消息强制到输入队列。否则，回滚消息将被路由到“回退”队列。如果多个设备正在使用来自MQ服务器中公共输入队列的消息，并且其中一个设备重新装入，则可以通过另一个活动设备的MQ FSH重新处理由于此故障而回滚的消息。
Backout Queue Name ：这定义队列，以包含由于超出了回退阈值中建立的限制而被处理的消息。此队列必须与定义的输入队列由同一MQ服务器管理。回退队列（通常为SYSTEM.DEAD.LETTER.QUEUE）包含无法处理或传递的消息。但是，最佳实践是对此属性使用本地队列。
图2. mq-qm对象的“配置”面板显示了“连接”选项卡上以红色突出显示的关键属性
Total-connection-limit ：这定义了mq-qm对象的连接池大小。默认值为250。对于大量MQ流量，此默认值可能不是在预期响应时间内处理事务的最佳选择。如果MQ事务显示更高的延迟，则可以调整total-connection-limit以使用更多的连接数，从而实现所需的性能目标。应该凭经验验证此调整，以便设备可以将负载维持在稳定状态，后端MQ服务器可以无错误地处理负载。如果负载不高，则应根据负载系数将连接数减少为较小的值。
注意：此属性是唯一可以增加或减小连接池大小的机制。在增加此值的同时，应注意验证是否已配置了后端MQ服务器以容纳所有客户端连接。应该在相应的MQ服务器中检查“ MaxChannel”值，以确保该值大于此MQ服务器的所有DataPower和非DataPower客户端的连接数。
本地地址 ：定义到特定本地接口和端口的出站连接的本地地址。支持的格式为xxxx或xxxx（1414）或仅（1414）告诉TCP绑定到端口1414。对于一定范围的端口，请使用（1414,1420）或xxxx（1414,1420）。如果设置了端口，则范围必须大于允许的连接总数。由于DataPower具有多个网络接口（NIC），并且在为这些接口配置默认路由时可以随机路由流量，因此最佳实践是在此属性中配置网络接口IP地址之一。此配置将mq-qm对象与专用IP绑定在一起，以便MQ消息的路由可以以一致且可预测的方式发生。
注意：当多个网络接口配置了默认路由，并且MQ队列管理器组（mq-qm-group）用作DataPower设备中的MQ流量的故障转移机制时，此方法很有用。
重试间隔 ：这指定尝试重试到远程主机的失败连接之间的时间间隔（以秒为单位）。此设置不会影响通过已建立的连接进行PUT或GET消息的尝试。默认值为1秒。如果使用默认值，则设备将每隔一秒钟主动重试一次，并且会增加CPU和内存使用率。最佳做法是将10或15秒的值用作失败连接的重试间隔。
重试次数 ：这定义重试失败的连接的尝试次数。达到尝试次数后，将使用“长重试间隔”。应当注意，默认值0（零）表示将不使用长重试间隔，并且将使用重试间隔永久重试。最佳实践是将此属性配置为大于零的值。例如，如果配置的值为6，则允许在10秒的间隔内重试6次。完成6次尝试后，如果未建立与后端的连接，则mq-qm对象将退回到Long Retry Interval，并继续重试。该机制通过使用交错方法来帮助减少重试的影响。
长重试间隔 ：配置重试间隔，直到达到重试次数。默认值为1800秒，并且应大于重试间隔。否则，它将无效。配置此属性时，应考虑等待下一次重试与MQ服务器重新连接的秒数。最佳做法是为此属性使用600秒。但是，请考虑其他用例场景，并配置一个小于600秒的适当值。
报告间隔 ：这定义了重试失败的连接时以错误级别报告日志消息的秒数。此设置过滤与MQ日志记录目标相同的错误消息的生成。最佳实践是在大多数使用情况下，为此属性配置一个等于“重试间隔”的值。但是，当您不想在系统日志中显示日志消息时，请考虑为此属性设置一个更高的值。
共享对话此配置可共享一个TCP / IP连接的最大对话数。要启用对话共享，请遵循以下准则：
WebSphere MQ V7.0和更高版本在SVRCONN通道上提供了共享对话（SHARECNV）属性，该属性指定可以共享每个TCP / IP通道实例的最大对话数。可以在DataPower中配置此功能，因为它使用与队列管理器SVRCONN通道的客户端连接。

DataPower mq-qm对象中的共享对话（SHARECNV）值的默认设置为零。 MQ SVRCONN通道的相同默认值是10。共享对话值在MQ服务器和DataPower之间协商，并且较低的值生效。但是，在当前版本的DataPower固件中，与MQ服务器协商时，共享对话设置1被视为0。

在DataPower mq-qm对象中，有三种使用情况来配置共享对话：
- 情况1 ：协商的共享对话值为0。通道以类似于WebSphere MQ V6.0的模式运行，并且不使用诸如以下的功能：
  - 管理员停止停顿
  - 心脏跳动
  - 提前阅读
  - 客户端异步消费
  不管MQ SVRCONN设置如何，都可以在DataPower中的mq-qm对象的“共享对话”属性上将值设置为0或1以禁用共享对话。
- 情况2 ：协商的共享对话值为1。通道支持情况1中概述的MQ V7.0和更高功能，但是每个TCP / IP通道实例都有一个对话。
  在DataPower中的mq-qm对象的“共享对话”属性上将值设置为2，在MQ SVRCONN设置上将值设置为1。
- 情况3 ：协商的共享对话值是2或更大。该通道支持MQ V7.0和更高版本的功能，并且每个TCP / IP通道实例都支持两个或多个对话。
  在DataPower中的mq-qm对象的“共享对话”属性和MQ SVRCONN通道上，将值设置为2或更大。
  
  平均而言，与SHARECNV（0）相比，使用SHARECNV（10）时来自客户端应用程序的消息处理要慢15％。请参阅在客户端连接通道上共享对话的性能含义。
专用的XML管理器 ：当多个mq-qm对象使用同一XML管理器（例如，单个应用程序域中的“默认”）时，一个mq-qm对象的配置更改会影响其他mq-qm对象共享的状态相同的XML管理器。最佳实践是对每个mq-qm对象使用专用的XML Manager及其关联的User Agent对象，以便设备可以有效地管理下层对象的状态更改。

配置DataPower MQ前端处理程序对象

MQ前端处理程序（FSH）对象配置为处理来自MQ服务器队列的客户端GET和PUT操作。图3和4以红色突出显示了关键属性，在配置此对象时需要用户考虑。

图3. MQ FSH对象的配置面板，用红色突出显示了关键的常规属性

图4. MQ FSH对象的“配置”面板显示以红色突出显示的“属性”和“标题”的关键属性

MQ FSH根据轮询间隔来轮询输入队列。它允许获取和放置消息到指定的队列。该对象也称为源MQ处理程序，需要考虑配置各种参数。

并发MQ连接数 ：这指定为此MQ FSH分配的并发MQ连接数。关于MQ FSH的行为，名称“并发MQ连接”是一个误称。它表示前端输入队列（GETQ）的活动和未决MQGET的数量。如果输入队列中有许多消息可用，则默认设置1连接可以将更多连接用于活动和挂起的MQGET操作。因此，在大多数使用情况下，此默认值都能很好地工作。如果需要处理更多负载，则可以将此属性的值增加到更大的数字。但是，应该凭经验测试此数字，以确保后端MQ服务器可以处理负载，并且由于后端MQ服务器的延迟，设备不会在其内存中保留许多事务。 MQ FSH处理消息的行为如下所述。
MQ FSH轮询具有MQ连接（以下称为C1）的消息。从GETQ返回消息后，DataPower开始处理消息，这可能涉及MQPUT。如果MQ FSH和后端MQ URL使用不同的mq-qm对象，则需要进行额外的连接。但是，如果前端和后端都使用配置了工作单元的同一mq-qm对象，则连接（C1）将与后端MQ URL共享。

同时，MQ FSH将继续执行MQGET，这些MQGET可能仍处于挂起状态。这将使MQ FSH的并发连接数增加到大于1。在处理所有消息之后，该值将在mq-qm对象中指定的缓存超时到期时变为1。请注意，即使将并发MQ连接设置为1，MQ FSH仍然可以使用至少两个MQ连接（C1用于事务处理，C2用于轮询输入队列）。

在极端情况下，如果事务处理花费的时间超过前端超时，并且GETQ中有许多消息，则MQ FSH可以使用连接池所允许的尽可能多的连接（在mq-qm中配置）对象的总连接限制）来处理这些消息。换句话说，如果请求消息以较低的速率到达GETQ，则MQ FSH将保留较少的已使用连接数。如果请求消息到达的速率更高，则MQ FSH将使用大量连接。

在大多数使用情况下，默认值为1就足够了。将其设置为大于1的值可能会带来一些性能提升，但差异很小。如果需要消息排序，那么它必须使用值1，因为多个MQGET将破坏消息排序。

最佳实践是在大多数情况下使用默认值1。对于高流量情况，可以在MQ FSH配置中为此属性使用2-5个连接值。
轮询间隔 ：这指定当输入队列中没有消息时，MQ FSH等待后续的MQGET操作的秒数。将此值设置为最小值有助于快速检测网络连接问题和队列管理器故障。但是，它增加了网络流量。在大多数情况下，默认值为30秒效果很好。
检索回退设置：此控件控制是否从MQ服务器检索回退设置。启用后，MQ FSH从MQ服务器检索“回退阈值”和“回退队列名称”设置，并将这些值与mq-qm对象的回退值进行比较。重试时，处理程序将使用优先级较高的回退设置。如果MQ服务器不包含回退设置，则该处理程序将使用来自mq-qm对象的现有回退值（为空或已填充）。如果mq-qm对象未定义回退值，则禁用此功能。
禁用后，缺省值不会从MQ服务器检索回退设置。如果mq-qm对象中已经存在这些属性，则处理程序将使用这些值。最佳做法是使用默认值“ off”。如果需要使用此功能，请务必确保为MQ服务器中的队列配置了回退队列名称和回退计数阈值。

注意：当“检索回退设置”的设置为“ on”时，由于每个MQGET操作需要附加的MQ API调用，因此可能导致性能下降。对于大量MQ流量，最佳实践是使用默认值“ off”。当启用工作单元来处理消息ROLLBACK时，将“自动回退”配置为“开”，并在mq-qm对象中提供其关联的回退阈值和回退队列名称。
解析属性：启用后，它解析队列或订阅中传入消息的属性。默认情况下，该属性设置为“关闭”。当MQ消息不包含属性时，最佳做法是禁用此属性。
异步放置 ：这允许将消息异步地放置到队列中，而不必等待队列管理器的响应。在关联的mq-qm对象中配置工作单元时，请勿使用此选项，因为同步点流需要队列管理器的响应来处理消息的回滚和提交操作。最佳实践是在后端MQ服务器环境稳定后才能使用此选项，以提高性能。
排除消息头 ：选择此项后，MQ FSH可以从MQ消息中剥离那些头。如果消息仅包含MQMD标头，则无需选中这些框。如果消息包含其他类型的标头，例如MQRFH2或MQIIH标头，则最佳实践是选择适当的复选框，以便将这些标头排除在有效负载中。但是，此类标头值在DataPower中仍可用于处理规则中的这些标头。
- CICS桥头（MQCIH）
- 死信标题（MQDLH）
- IMS信息标题（MQIIH）
- 规则和格式标题（MQRFH）
- 规则和格式标题（MQRFH2）
- 工作信息标题（MQWIH）

配置DataPower MQ URL打开器

MQ URL打开器用于将消息路由到其目的地。最佳实践是使用多协议网关（MPGW）服务中可用的“构建MQ URL”帮助程序。图5显示了突出显示的字段，这些字段包含用于为后端目标构造有效的MQ URL的值。

图5. MQ Helper为后端构建MQ URL

数据报流量的后端静态MQ URL示例：

dpmq://LNX-DP1/?RequestQueue=QUEUE1 (Without units-of-work)
dpmq://LNX-DP1/?RequestQueue=QUEUE1;Transactional=true (With units-of-work)

用于请求/回复流量的后端静态MQ URL示例：

dpmq://LNX-DP1/?RequestQueue=QUEUE1;ReplyQueue=QUEUE2;SetReplyTo=true (Without units-of-work)
dpmq://LNX-DP1/?RequestQueue=QUEUE1;ReplyQueue=QUEUE2;Transactional=true;Sync=true;SetReplyTo=true (With units-of-work)

静态URL发送消息的语法：

dpmq://mqQueueManagerObject/URI?RequestQueue=requestQueueName;queryParameters

静态URL检索消息的 语法：

dpmq://mqQueueManagerObject/URI?ReplyQueue=replyQueueName;queryParameters

动态URL发送或检索消息的语法：

mq://host:port?QueueManager=queueManager;UserName=userName;Channel=channelName;ChannelTimeout=channelTimeout; 
channelLimit=channelLimit;Size=maxMsgSize; 
MQCSPUserId=MQCSPUserID;MQCSPPassword=MQCSPPassword;queryParameters

要从背面剥离标题，请使用“ ParseHeaders”的MQ URL参数或其别名“ ExcludeHeaders”。它从有效载荷中排除所有标头。

注意：当回复消息包含MQRFH2标头，并且需要从有效负载中除去这些额外的标头以使其成为格式正确的XML有效负载时，在MQ URL中使用“ ParseHeaders”标记非常有用。

要覆盖服务后端超时，请使用MQ URL中的TimeOut=<value in milliseconds>标记。最佳实践是在MQ URL包含“ replyQueue”标记时配置“ TimeOut”。通过在MQ URL中使用此“ TimeOut”参数，后端连接将等待响应消息，直到该超时时间到期为止。如果指定的超时未收到答复，则后端MQ URL返回代码2033，指示在超时期间没有可用的答复消息。

注意：MQ URL“ TimeOut”优先于网关背面超时设置。最佳实践是将此值配置为低于配置的网关服务后端超时值。

有关更多详细信息，请参阅此信息中心主题中的MQ URL语法。

在DataPower中操作MQ标头

DataPower在处理策略中处理MQ头，例如MQ消息描述符（MQMD）和MQ规则格式化头1和2（MQRFH和MQRFH2）。在请求规则中处理请求消息时，网关服务不会更改MQMD。但是，可以使用处理规则中的特定转换（xform或xformbin）操作来操纵MQMD。有两种操作MQ标题的方法：使用标题注入或使用自定义样式表。

使用标题注入方法

当请求和回复消息的MQ头是静态的时，此方法适用于每种消息类型可以添加必要的头，这些头的值在多个请求或回复消息中不会改变。换句话说，为每个请求或答复消息填充相同的MQ头值。

使用网关服务的标头选项卡，以下示例用于填充MQ标头：

添加新的标题注入参数

方向： Back （或Backend MQPUT ）
标题名称 ： MQMD
标头值 ： <MQMD><Format>MQSTR</Format><Persistence>1</Persistence></MQMD>

使用样式表方法

清单1显示了带有值的完整MQMD标头。

清单1.具有值的MQMD标头的示例

<MQMD>
  <StrucId>MD </StrucId>
  <Version>1</Version>
  <Report>0</Report>
  <MsgType>8</MsgType>
  <Expiry>-1</Expiry>
  <Feedback>0</Feedback>
  <Encoding>546</Encoding>
  <CodedCharSetId>819</CodedCharSetId>
  <Format>MQSTR</Format>
  <Priority>0</Priority>
  <Persistence>0</Persistence>
  <MsgId>414d5120454d42444954312020202020d724c84199990002</MsgId>
  <CorrelId>000000000000000000000000000000000000000000000000</CorrelId>
  <BackoutCount>0</BackoutCount>
  <ReplyToQ>ADAPTERTEST.POSTFORMAT02 </ReplyToQ>
 <ReplyToQMgr>EMBDIT2 </ReplyToQMgr>
  <UserIdentifier>MUSR_MQADMIN</UserIdentifier>
  <AccountingToken>
     16010515000000271d19306f0b7216262a1345eb03000000000000000000000b
  </AccountingToken>
 <ApplIdentityData></ApplIdentityData>
  <PutApplType>28</PutApplType>
 <PutApplName>Websphere MQ Client for Java</PutApplName>
  <PutDate>20061005</PutDate>
  <PutTime>18401655</PutTime>
 <ApplOriginData></ApplOriginData>
  <GroupId>000000000000000000000000000000000000000000000000</GroupId>
  <MsgSeqNumber>1</MsgSeqNumber>
 <Offset>0</Offset>
  <MsgFlags>0</MsgFlags>
  <OriginalLength>-1</OriginalLength>
</MQMD>

清单2显示了操作MQMD标头的样式表。

清单2.注入MQMD标头的定制样式表方法

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:dp="http://www.datapower.com/extensions"
    extension-element-prefixes="dp"
    exclude-result-prefixes="dp">

  <xsl:output method="xml"/>
  <xsl:template match="/">
    	<xsl:variable name="newMQMDStr">
        		<MQMD>
                        	<Format>MQSTR</Format><Persistence>1</Persistence>
        		</MQMD>
    	</xsl:variable>
    	<xsl:variable name="mqmdStr">
	   <dp:serialize select="$newMQMDStr" omit-xml-decl="yes"/>
    	</xsl:variable>
    	<xsl:message dp:priority="debug">
          <xsl:value-of select="concat('The New MQMD : ', $mqmdStr)"/>
    	</xsl:message>
    	<!-- for request rule -->
    	<dp:set-request-header name="'MQMD'" value="$mqmdStr"/>
    	<!-- for response rule -->
    	<!-- <dp:set-response-header name="'MQMD'" value="$mqmdStr"/> -->
      <!-- adding MQ header when MQ URL open call is usedfor MQPUT-->
      <!--
     	<xsl:variable name="mqHeaders">
     	    <header name="MQMD"><xsl:value-of select="$mqmdStr"/></header>
      </xsl:variable>
      <xsl:variable name="sendmessage">
	    <dp:url-open
	       target="dpmq://DP4/?RequestQueue=QUEUE6"
             http-headers="$mqHeaders"
		 response="responsecode-ignore">
             <xsl:copy-of select="." />
          </dp:url-open>
       </xsl:variable>
	 -->
  </xsl:template>
</xsl:stylesheet>

当标头注入或样式表方法未注入完整的MQMD标头时，DataPower将使用默认值添加缺少的MQMD字段，以构造完整的MQMD。为了填充完整的MQMD标头字段的新值，请创建具有相应标头及其关联值的结构，并使用样式表方法将其注入。

上面的MQ头注入方法不起作用的例外情况很少。在结果操作的目标框中使用MQ URL的情况下，应使用“上下文”变量方法注入MQMD。例如，请求规则需要记录设置了MQMD.Expiry标头的MQ消息。使用结果操作和目标框中配置的MQ URL路由消息。在这种情况下，使用“上下文”变量方法注入相关的MQMD头，如清单3所示。

清单3.注入MQMD标头的上下文变量方法

<xsl:variable name="MQMDStr">                        
    <MQMD>     
       <Expiry>8000</Expiry>
       <Priority>0</Priority>
       <Format>MQSTR</Format>                       
    </MQMD>                                          
</xsl:variable>                                      
<xsl:variable name="MQMDStr2">                       
    <dp:serialize select="$MQMDStr" omit-xml-decl="yes"/>                                         
</xsl:variable>
<dp:set-variable name="'var://context/EVENTS/_extension/header/MQMD'"
	value="$MQMDStr2"/>

确保将Result Action的INPUT上下文设置为“ EVENTS”，将前面的Transform（xform）Action的OUTPUT上下文定义为“ EVENTS”，并使用样式表执行上述代码段。

通用MQ处理流程

处理MQ数据报和请求/答复流量有一些配置要求。对于数据报流量，建议以下最佳实践配置：

使用不带工作单元的MPGW服务的数据报流量 ：MPGW服务配置为仅使用请求规则。无需响应规则，因为数据报流量不会发送任何回复消息。如果应用程序未处理错误处理，则此服务不需要任何错误规则。 MPGW服务的“高级”选项卡下的“进程后端错误”应为“关闭”。请求类型可以是“ XML”，“ SOAP”，“非XML”或“直通”。响应类型设置为“直通”。在处理期间，请求MQMD不会更改，并且后端MQ URL仅指定“ RequestQueue”。
使用具有工作单元的MPGW服务的数据报流量： MPGW服务配置为仅使用请求规则。无需响应规则，因为数据报流量不会发送任何回复消息。如果应用程序要执行错误处理，则此服务可能需要一个错误规则。 MPGW服务的“高级”选项卡下的“进程后端错误”应为“关闭”。请求类型可以是“ XML”，“ SOAP”，“非XML”或“直通”。响应类型设置为“直通”。在处理期间，请求MQMD不会更改，并且后端MQ URL指定“ RequestQueue”以及“ Transactional = true”标记。如果配置了错误规则，则可以通过使用带有包含“ RequestQueue”和“ Sync = true”标记的MQ URL的Result操作或Transform操作将有毒消息路由到备用队列。注意，一旦将消息放入备用队列，MQ服务器必须提交消息。因此，错误规则中使用了“ Sync = true”标记。在mq-qm对象中启用“工作单元”时，应在错误规则中将服务变量“ var：// service / error-ignore”设置为“ 1”，以处理ROLLBACK。

使用具有自定义错误处理的MPGW服务的数据报流量： MPGW服务配置为使用请求，响应和错误规则。它必须使用“ dp：response-header（'x-dp-response-code'）”捕获响应规则中的响应代码，并在“响应代码”与模式“ 2xxx”，其中“ 2xxx”是代表MQ返回码（mqrc）的四位数。 MPGW服务的“高级”选项卡下的“进程后端错误”应为“开”。请求类型可以是“ XML”，“ SOAP”，“非XML”或“直通”。响应类型设置为“非XML”。在处理期间，请求MQMD不会更改，并且后端MQ URL仅指定“ RequestQueue”。

如果在mq-qm对象中启用了工作单位，则应在错误规则中将服务变量“ var：// service / error-ignore”设置为“ 1”以处理ROLLBACK。必须在同一MQ URL中使用附加标记“ Transactional = true”。

清单4显示了捕获响应代码，然后如果MQ业务量的响应代码为“ 2xxx”则执行“ dp：reject”的代码段。

清单4.自定义MQ错误处理

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:dp="http://www.datapower.com/extensions"
  extension-element-prefixes="dp"
  exclude-result-prefixes="dp" version="1.0">

    <xsl:output method="xml"/>
    <xsl:template match="/">
        <xsl:variable name="mqrc" select="dp:response-header('x-dp-response-code')"/>
        <xsl:variable name="ecode" select="dp:variable('var://service/error-code')"/>
        <xsl:variable name="errMsg" select="concat('** The Response Code ** : ', $mqrc, ' and ** Error Code ** :', $ecode )"/>

        <xsl:choose>
            <xsl:when test="(starts-with($mqrc, '2') and (string-length(normalize-space($mqrc))= 4)) or ($ecode != '0x00000000')">
                <xsl:message dp:priority="debug">
                    <xsl:value-of select="$errMsg"/>
                </xsl:message>
                <dp:set-variable name="'var://context/ERROR/err-msg'" value="$errMsg"/>
                <dp:reject override="true"><xsl:value-of select="$errMsg"/></dp:reject>
            </xsl:when>
            <xsl:otherwise>
                <xsl:message dp:priority="debug">
                    <xsl:value-of select="$errMsg"/>
                </xsl:message>
                <dp:accept/>
            </xsl:otherwise>
        </xsl:choose>
  </xsl:template>
</xsl:stylesheet>

使用具有工作单元的MPGW服务进行请求/答复流量： MPGW服务配置为使用请求，响应和错误规则。 It must capture the response code in the Response rule using "dp:response-header('x-dp-response-code')" and execute "dp:reject" to invoke Error rule when "response code" is with a pattern of "2xxx", where "2xxx" is a four digit number representing the MQ return code (mqrc). The "Process Backend Errors" under the Advanced tab of the MPGW service should be "on". The Request and Response Type can be "XML", "SOAP", or "non-XML". During processing, the Request MQMD is not altered and the Backside MQ URL specifies the "RequestQueue", "ReplyQueue", and "setReplyTo=true".
When units-of-work is enabled, additional tags of "Transactional=true;Sync=true" must be specified in the same MQ URL. Note that the "Sync=true" tag is used to commit the request message so that MQ application can consume this message to prepare the reply message for the "ReplyQueue". Without this "Sync=true" tag, the message in the "RequestQueue" will not be visible as it is under the sync point flow. The service variable "var://service/error-ignore" should be set as "1" in Error rule to handle ROLLBACK.

Note: Make sure that the application, which prepares the reply message, injects "Request.MQMD.Msgid in Reply.MQMD.CorrelId". Otherwise, DataPower does not fetch the reply message in its response rule.
Request/Reply traffic using the MPGW service with dynamic routing : When the request MQ message is processed, it contains the MQMD.ReplyToQ and MQMD.ReplyToQMgr values to indicate the destination path for the reply message. The reply message will be routed to the final destination based on the following two scenarios:
- Scenario 1 : If the value of MQMD.ReplyToQMgr is the same as the qmgr name configured in the mq-qm object:
  1. Set DataPower's internal virtual header "ReplyToQ" to an empty string using the stylesheet in the response rule: <dp:set-response-header name="'ReplyToQ'" value="''"/> .
  2. Save MQMD.ReplyToQ to a context variable in the request rule.
  3. Save MQMD.ReplyToQMgr to a context variable in the request rule.
  4. Inject the MQOD headers with these values in the response rule for the front side client.
  5. Make sure that the local MQ queue manager (qmgr) is configured to handle message routing to the remote qmgr based on the MQ Object Descriptor (MQOD).
- Scenario 2 : If the value of MQMD.ReplyToQMgr is different from the qmgr name configured in the mq-qm object:
  1. Set DataPower's internal virtual header "ReplyToQ" to an empty string using the stylesheet in the Response rule: <dp:set-response-header name="'ReplyToQ'" value="''"/> .
  2. Set DataPower's internal virtual header "ReplyToQM" to an empty string using the stylesheet in the Response rule: <dp:set-response-header name="'ReplyToQM'" value="''"/> .
  3. Save MQMD.ReplyToQ to a context variable in the request rule.
  4. Save MQMD.ReplyToQMgr to a context variable in the request rule.
  5. Inject the MQOD headers with these values in the response rule for the front side client.
  6. Make sure that the local MQ queue manager (qmgr) is configured to handle message routing to the remote qmgr based on the MQ Object Descriptor (MQOD).
Listing 5 shows the stylesheet example to save the "ReplyToQ" and "ReplyToQMgr" values in the Request rule and to inject those values in the Response rule using the MQOD structure.

Listing 5. Custom MQ routing with the MQOD header
```
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0" extension-element-prefixes="dp"
exclude-result-prefixes="dp">

  <xsl:output method="xml"/>
  <xsl:template match="/">
  <xsl:variable name="rule-type" select="dp:variable('var://service/transaction-rule-type')"/>
  <xsl:choose>
     
     <xsl:when test="$rule-type = 'request'">
         <xsl:variable name="entries" select="dp:request-header('MQMD')"/>
         <xsl:variable name="header"  select="dp:parse($entries)"/>
         
         <dp:set-variable name="'var://context/MYMQMD/ReplyToQ'"    value=""$header//ReplyToQ"/>
         <dp:set-variable name="'var://context/MYMQMD/ReplyToQMgr'" value=""$header//ReplyToQMgr"/>
         <xsl:message dp:priority="debug">
            <xsl:value-of select="concat ('Request MQMD : ', dp:request-header('MQMD'))"/>
         </xsl:message>
     </xsl:when>
     
     <xsl:when test="$rule-type = 'response'">
         <xsl:variable name="custMQODStr">
             <MQOD>
                <Version>2</Version>
                <ObjectName>
                    <xsl:value-of select="dp:variable('var://context/MYMQMD/ReplyToQ')"/>
                </ObjectName>
                <ObjectQMgrName>
                    <xsl:value-of select="dp:variable('var://context/MYMQMD/ReplyToQMgr')"/>
                </ObjectQMgrName>
             </MQOD>
         </xsl:variable>
         <xsl:variable name="mqodStr">
             <dp:serialize select="$custMQODStr" omit-xml-decl="yes"/>
         </xsl:variable>
         <xsl:message dp:priority="debug">
             <xsl:value-of select="concat('Response MQOD : ', $mqodStr)"/>
         </xsl:message>
         <dp:set-response-header name="'MQOD'" value="$mqodStr"/>
     </xsl:when>
     </xsl:choose>
  </xsl:template>
</xsl:stylesheet>
```
Note: If the backend MQ server is using a cluster, the injection of MQMD.ReplyToQMgr in MQOD is not needed. However, if the work load management feature is enabled, MQMD.ReplyToQMgr should be injected so that the MQ cluster can route the message to an alternate qmgr when the designated remote qmgr is busy.

One-phase COMMIT requirements

When the DataPower mq-qm object is enabled with units-of-work, it supports a one-phase COMMIT. In order to provide a guaranteed message delivery, the following conditions must be met:

The same MQ qmgr must be used in the MQ front side handlers and MQ URL openers.
All processing actions must be synchronous.
The same connection is shared across all MQ operations within a transaction that guarantees a "once-and-only-once" message delivery.
In all other cases, it is a "at-least-once" message delivery. However, there will be no message loss with a traffic pattern of MQ to MQ. It means both the front and back sides use the MQ protocol.
These two scenarios are:
- Scenario 1 : When the same MQ qmgr is used in both the front side handler and back side MQ URL opener, the message from the input queue (GETQ) will be resent if the input connection fails. No duplicates are allowed in the in output queue (PUTQ).
- Scenario 2 : When two separate MQ qmgrs are used in the front side handler and back side MQ URL opener, a message from the input queue (GETQ) will be resent if the input connection fails. Duplicate messages may appear in the output queue (PUTQ). There is no message loss.

结论

Based on best practice configurations, DataPower applications can provide improved performance for MQ message processing. It creates safe guards for overutilization of appliance resources such as CPU, memory, and connections. This tutorial provided configurations to integrate DataPower services with MQ with various traffic patterns that involve the Datagram and Request/Reply traffic. If the applications are configured with these best practices, they can help appliances from reloads if the MQ server is not available during downtime and can reduce connection errors for the backend MQ server.

致谢

Many of our IBM colleagues in the WebSphere DataPower SQA, Development, and Support teams assisted in the preparation of this tutorial. The author would like to extend special thanks to Daniel HT Shih and John Rasmussen for their review of this tutorial.

翻译自: https://www.ibm.com/developerworks/websphere/library/techarticles/1410_sahoo/1410_sahoo.html