Пройдите через QueuManager в JMS API - PullRequest
Новая
       103

Пройдите через QueuManager в JMS API

1 голос
/ 29 февраля 2012

В MQ, если у вас есть экземпляр существующего администратора очередей, скажите queuemanager1, к которому у вашего приложения есть доступ. Вы можете отправить свое сообщение, создав очередь, которая указывает на очередь другого администратора очередей, queuemanager2, через queuemanager1. Это сделано потому, что у приложения, возможно, нет прямого доступа к queuemanager2, но у сервера MQ, на котором размещается queumanager1.

Код выглядит примерно так:

MQQueue destQueue = queuemanager1.accessQueue ("queFromAnotherMngr", CMQC.MQOO_OUTPUT | CMQC.MQOO_FAIL_IF_QUIESCING, "queuemanager2", null, null);

Я выполняю рефакторинг кода для использования адаптера IBM MQ JCA для JBoss AS 6. Поэтому я считаю, что мне нужно придерживаться ванильного API-интерфейса JMS (с помощью поиска InitialContext JNDI, источника и т. Д.), Чтобы мои соединения управлялись JBoss.

Однако я не могу понять, как в обычном JMS разрешить принимающему серверу MQ пересылать мое сообщение в другую очередь другого администратора очередей (queuemanager2).

Из того, что я исследовал до сих пор, есть объект, отправленный в MQ, называемый дескриптором сообщения очереди сообщений (MQMD), и у него есть поле с именами «ReplyToQMgr» и «ReplyToQ». Я думаю, что если я найду способ обновить эти поля с помощью JMS API с помощью adcater JCA, у меня будет свое решение. Какие-нибудь мысли? Идеи? Предложения? Решения? Спасибо!

1 Ответ

1 голос
/ 01 марта 2012

Поля ReplyTo позволяют удаленному приложению отправлять вам сообщения.Они не используются WebSphere MQ при маршрутизации исходного сообщения, но используются для адресации подтверждений и отчетов об ошибках.

Способ, которым вы указываете очередь на удаленном QMgr с помощью поиска JNDI, заключается в определении поля QMNAMEв объекте очереди.См. Свойства классов WebSphere MQ для объектов JMS для получения списка всех свойств, поддерживаемых объектами WebSphere MQ.В верхней таблице не упоминается, что свойство QMNAME очереди не обязательно должно совпадать со свойством QMNAME фабрики соединений.Когда эти свойства различаются, локальный QMgr будет пытаться разрешить путь к целевому QMgr при открытии объекта очереди.Пока он может найти путь (должна существовать очередь передачи или псевдоним QMgr с тем же именем, что и у целевого QMgr), и пока ваше приложение авторизовано в очереди передачи, вы можете идти.

Обратите внимание, что если вы получаете исключение JMS, вы должны запросить наличие и распечатать все найденные связанные исключения.В них будет указан код причины WMQ, который сообщит вам или администратору, связаны ли какие-либо проблемы с разрешением имен, авторизацией или другими проблемами.Пожалуйста, смотрите Исключения в классах WebSphere MQ для JMS , чтобы узнать, как это сделать.Обратите внимание, что это не специфичный для WMQ совет.JMS задает многоуровневую структуру для отчетов об исключениях, а связанное исключение - это то, где сообщаются ошибки конкретного поставщика.Поэтому любое приложение JMS, независимо от того, какой поставщик транспорта используется, должно печатать связанные исключения.

...