gpt4 book ai didi

ibm-mq - IBM 铸铁 : MQ Put activity issues

转载 作者:行者123 更新时间:2023-12-02 06:40:15 24 4
gpt4 key购买 nike

我正在尝试将消息从部署在 Cast Iron Live 上的 Orchestration 放入 Websphere MQ 队列中。自从编排部署在铸铁上以来,我一直使用安全连接器。当我尝试执行流程时,它失败并且消息未放置在 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 流程部署在 Cast Iron Cloud 上,即 Cast Iron Live
  2. MQ 正在本地运行
  3. 我尝试连接的端口是 1414。
  4. 在安装 MQ 的计算机上运行安全连接器。
  5. MQ 版本为 8。
  6. 在 Cast Iron 流程中,我使用 MQ 连接器,指定运行 MQ 的主机名、端口:1414、 channel 名称:SYSTEM.DEF.SVRCONN 以及用户名 mqm。厌倦了使用我的登录用户名,将其添加到 mqm 组。但这似乎也不起作用。

最佳答案

返回代码具有指导意义:

2538  0x000009ea  MQRC_HOST_NOT_AVAILABLE

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

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

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

如果问题很简单,例如监听器未运行,则很容易修复。只需启动它并确保它按预期位于 1414。

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

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

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

出于安全原因,SYSTEM.DEF.*SYSTEM.AUTO.* channel 不应永远用于合法连接。最佳实践是定义一个新的 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)

第一个语句定义新 channel 。

下一个允许来自 127.0.0.1 的连接,这是安全连接器所在的位置。 (大概您在与 MQ 相同的服务器上安装了内部安全连接,是吗?) 理想情况下,连接器将在 channel 上使用 TLS,而不是使用 IP 过滤,而是使用 CHLAUTH 规则基于证书专有名称的过滤器。此规则几乎没有那么选择性,它允许本地主机上的任何人通过使用此 channel 成为 MQ 管理员。

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

关于ibm-mq - IBM 铸铁 : MQ Put activity issues,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/31423196/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com