IBM Cast Iron: проблемы с активностью MQ Put

Я пытаюсь поместить сообщение в очередь Websphere MQ из Orchestration, развернутого в Cast Iron Live. Я использовал безопасный соединитель, так как Orchestation развернута на 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 Cloud, то есть в Cast Iron Live.
  2. MQ работает на месте
  3. Я пытаюсь подключиться к порту 1414.
  4. Иметь безопасный разъем на машине, где установлен MQ.
  5. Версия MQ 8.
  6. В Cast Iron Flow я использую соединитель MQ, предоставляя имя хоста, на котором работает MQ, порт: 1414, имя канала: SYSTEM.DEF.SVRCONN и имя пользователя в качестве mqm. Надоело использовать мой логин на имя пользователя, добавив его в группу mqm. Но это также, кажется, работает.
Источник

1 ответ

Код возврата поучителен:

2538  0x000009ea  MQRC_HOST_NOT_AVAILABLE

Это указывает на то, что Cast Iron пытается связаться с MQ с помощью клиентского соединения и не находит прослушивателя на хосте / порте, который он использует.

Здесь есть несколько возможностей, но недостаточно информации, чтобы сказать, какой это может быть. Я объясню и предоставлю некоторую диагностику, которую вы можете попробовать.

  1. 2538 указывает, что попытка связаться с QMgr не удалась. Это может быть связано, например, с тем, что QMgr не прослушивает настроенный порт (1414) или что прослушиватель MQ не работает.
  2. Код ошибки говорит, что имя очереди - "ноль". Вопрос не определяет, с каким именем очереди настроен соединитель, но предположительно он настроен с некоторым именем очереди. Этот код ошибки предполагает, что Secure Connector на стороне сервера MQ не имеет своей установленной конфигурации.
  3. Чугунные документы советуют соединиться с удостоверением личности в mqm группа, но не упоминайте, что на любой MQ версии 7.1 или выше, это гарантированно потерпит неудачу, если не будут приняты специальные условия для разрешения подключения администратора. Это может быть связано с ошибкой авторизации, а соединитель не сообщает о правильной ошибке.

Если это так просто, как слушатель не работает, это достаточно легко исправить. Просто запустите его и убедитесь, что он на 1414, как и ожидалось.

Затем убедитесь, что Secure Connector имеет конфигурацию, созданную с помощью админ-панели Cast Iron. Вы должны понять, почему код ошибки говорит, что имя очереди является нулевым.

Теперь включите события авторизации и события канала в QMgr и повторите попытку подключения. Разъем на сервере MQ должен подключаться при запуске, и в случае успеха вы можете увидеть это, посмотрев на статус канала MQ. Однако, если это не удастся, вы можете узнать, посмотрев сообщения о событиях или журналы ошибок MQ. Обе из них будут отображать ошибки авторизации и попытки подключения, если подключение прошло слишком далеко.

Причина, по которой я ожидаю сбоев 2035 Authorization Error, заключается в том, что любой QMgr начиная с v7.1 и выше по умолчанию разрешает административное соединение на любом канале. Это настроено в наборе по умолчанию 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 но только для этого канала.

Источник
Другие вопросы по тегам