【问题标题】:IBM Cast Iron: MQ Put activity issuesIBM Cast Iron:MQ Put 活动问题
【发布时间】:2015-10-04 01:38:27
【问题描述】:

我正在尝试从部署在 Cast Iron Live 上的编排将消息放入 Websphere MQ 队列。自从编排部署在 Cast Iron 上以来,我一直使用安全连接器。当我尝试执行流程时,它失败并且消息没有放在 MQ 队列中。以下是错误:

Error while trying to call remote operation execute on Secure Connector for activity
com.approuter.module.mq.activity.MqPut and Secure Connector LocalSecureConnector, 
error is Unable to put message on queue null. MQ returned error code 2538.

Unable to put message on queue null. MQ returned error code 2538.
Fault Name : Mq.Put.OperationActivityId : 163
Message: Unable to put message on queue null. MQ returned error code 2538.
Activity Name:Put MessageFault Time: 2015-07-15T05:40:29.711Z

谁能帮我解决这个问题。如果需要任何进一步的细节,请告诉我。

以下是详细信息:

  1. Cast Iron Flow 部署在 Cast Iron Cloud 上,即 Cast Iron Live
  2. MQ 正在本地运行
  3. 我尝试连接的端口是 1414。
  4. 在安装 MQ 的机器上运行安全连接器。
  5. MQ 版本为 8。
  6. 在 Cast Iron 流程中,我使用 MQ 连接器,通过提供运行 MQ 的主机名、端口:1414、通道名称:SYSTEM.DEF.SVRCONN 和用户名 mqm。厌倦了使用我的登录用户名,将其添加到 mqm 组。但这似乎也不起作用。

【问题讨论】:

  • 这很有帮助,但我们需要更多。例如,“在安装 MQ 的机器上运行安全连接器”是什么意思?这不是 MQ 术语。它是铸铁术语吗?此外,“我尝试连接的端口是 1414”很有帮助,但没有提及是否定义了 MQ 侦听器并在该端口上运行。另外,如果 Cast Iron 部署在外部云中并且 MQ 在内部,您是否知道有一条通过防火墙到达 MQ 的路由?
  • MQ 将在其日志文件中记录连接尝试并作为事件消息。如果登录名是问题所在,您会在 QMgr 上看到 2035 错误。 2538 表明它并没有那么远。但是,如果您确实做到了这一点,默认情况下 v8 QMgr 将不允许任何 SVRCONN 通道上的管理员连接。您必须禁用 CHLAUTH 或定义一个或两个新的 CHLAUTH rukle 才能获得 mqm ID 或 mqm 组中的任何内容以进行连接。同样,问题中没有足够的信息来说明这是否是一个问题。
  • 感谢您的回复罗。安全连接器是铸铁术语。它是一个在运行 MQ 的机器上运行的连接器,并且在 Cast Iron 控制台中设置了相同的配置(非常类似于一种方式的 SSL 握手)。为了让 Cast Iron 云与本地 MQ 进行通信,它需要此安全连接器处于运行状态。它用于有防火墙的情况。在端口 1414 上运行了一个 MQ 侦听器。Cast Iron 流部署在外部的云上,而 MQ 在内部。如果您需要更多详细信息,请告诉我。
  • 我也检查了 MQ 日志。但是日志中没有消息提供有关 MQ 中消息失败的信息。正如你所说,它还没有到达 MQ,因此日志中没有消息。

标签: ibm-mq cast-iron


【解决方案1】:

返回码有指导意义:

2538  0x000009ea  MQRC_HOST_NOT_AVAILABLE

这表明 Cast Iron 正在尝试使用客户端连接与 MQ 联系,但未在其正在使用的主机/端口上找到侦听器。

这里有几种可能性,但没有足够的信息来说明它可能是什么。我将解释并提供一些您可以尝试的诊断方法。

  1. 2538 表示尝试联系 QMgr 失败。例如,这可能是因为 QMgr 未在配置的端口 (1414) 上进行侦听,或者 MQ 侦听器未在运行。
  2. 错误代码显示队列名称为“null”。该问题未指定连接器配置的队列名称,但推测它已配置 some 队列名称。此错误代码表明 MQ 服务器端的安全连接器未安装其配置。
  3. Cast Iron 文档建议使用mqm 组中的 ID 进行连接,但不要提及在任何 MQ 7.1 或更高版本上,除非有特殊规定允许管理员连接,否则此操作肯定会失败。可能是因为授权错误而实际上失败了,并且连接器没有报告正确的错误。

如果它像侦听器不运行一样简单,那很容易修复。只需启动它并确保它按预期在 1414 上。

接下来,确保安全连接器具有使用 Cast Iron 管理面板创建的配置。您需要了解错误代码为什么说队列名称为空。

现在在 QMgr 中启用授权事件和通道事件并尝试再次连接。 MQ 服务器上的连接器应该在启动时连接,如果成功,您可以通过查看 MQ 通道状态来看到这一点。但是,如果不成功,您可以通过查看事件消息或 MQ 错误日志来判断。如果连接已经到达那么远,这两者都会显示授权失败和连接尝试。

我预计 2035 授权错误失败的原因是 v7.1 及更高版本的任何 QMgr 默认情况下允许在任何通道上进行管理连接。这是在默认的CHLAUTH 规则集中配置的。其目的是 MQ 管理员必须通过添加一个或多个新的CHLAUTH 规则来明确提供管理员访问权限。

出于安全原因,SYSTEM.DEF.*SYSTEM.AUTO.* 通道应该永远用于合法连接。最佳实践是定义一个新的SVRCONN,例如名为CAST.IRON.SVRCONN 的一个,然后定义一个CHLAUTH 规则以允许管理连接。

例如:

DEFINE CHL(CAST.IRON.SVRCONN) CHLTYPE(SVRCONN) TRPTYPE(TCP) REPLACE
SET CHLAUTH('CAST.IRON.SVRCONN') TYPE(ADDRESSMAP) +
    ADDRESS('127.0.0.1') +
    USERSRC(MAP) MCAUSER('mqm') +
    ACTION(REPLACE) 
SET CHLAUTH('CAST.IRON.SVRCONN') TYPE(BLOCKUSER) +
    USERLIST('*NOBODY') +
    WARN(NO) ACTION(REPLACE)

第一条语句定义了新通道。

下一个允许来自安全连接器所在的127.0.0.1 的连接。 (假设您将内部安全连接安装在与 MQ 相同的服务器上,是吗?) 理想情况下,连接器将在通道上使用 TLS,而不是 IP 过滤,CHLAUTH 规则将根据证书进行过滤专有名称。该规则几乎没有那么严格,允许本地主机上的任何人通过使用此通道成为 MQ 管理员。

最后一条语句覆盖了默认的 CHLAUTH 规则,该规则会阻止 *MQADMIN,而新规则会阻止 *NOBODY,但仅适用于该频道。

【讨论】:

  • 您好,Rob,感谢您的回复。通过提供更多详细信息,我已经编辑了我的问题。希望这会有所帮助。
  • 期待这方面的一些提示。
  • 仍然没有足够的信息进行诊断,但我提供了收集该信息和其他一些诊断注意事项的步骤。希望对您有所帮助。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2019-08-13
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多