Сообщение в Websphere MQ не получает ответа (Fuse ESB 7.1)

Я отправляю «RequestSnapshot» в очередь Websphere-MQ, которая определена поставщиком как «S» (синхронная), поэтому я ожидаю получить ответ через шаблон интеграции Apache Camel inOut, работающий в Fuse ESB.

from("direct:" + SEND_SUBSCRIPTION)
        .routeId(getFinalRouteName(SEND_SUBSCRIPTION))
        .log("Sending Request Snapshot request to webspheremq")
        .bean(CreateSnapshotRequest.class)
        .marshal(myDataFormat)
        .convertBodyTo(String.class)
        .inOut("webspheremq:queue:SNAPSHOT_REQUESTS.HT")   // **1** works, but no Reply!!
        .log("RequestSnapshot response: ${body}")          // doesnt reach this line

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

Проблема в том, что я не получаю ответа, выполнение останавливается на строке с пометкой **1** - и через 20 секунд я получаю тайм-аут.

org.apache.camel.ExchangeTimedOutException: The OUT message was not received
within: 20000 millis due reply message with correlationID:
Camel-ID-XYZ012-54037-1385986757895-0-3 not received.

Обычно через код Java это делается по-другому, но здесь мы используем Fuse ESB, и механизм inOut должен отправить сообщение и получить ответ о том, что называется DYNAMIC REPLY-TO QUEUE.

Мое понимание очереди «ответить на» несколько ограничено, я просто понимаю, что Fuse ESB должен прослушивать ответ на каком-то временном mq, но это должно работать прозрачно через inOut.

Вот мой компонент конфигурации от blueprint.xml:

<bean id="webspheremq" class="org.apache.camel.component.jms.JmsComponent">
    <property name="connectionFactory">
        <bean class="com.ibm.mq.jms.MQConnectionFactory">
            <property name="transportType" value="1"/>
            <property name="hostName" value="1.2.3.4"/>
            <property name="port" value="1417"/>
            <property name="channel" value="SOME.CHANNEL"/>
            <property name="temporaryModel" value="SOME_MODEL_QUEUE"/>
            <property name="CCSID" value="789"/>
            <property name="queueManager" value="SOMEGATE"/>
            <property name="brokerSubQueue" value="SYSTEM.JMS.ND.MACHINE.USER.*"/>
            <property name="brokerControlQueue" value="SOME_SUBSCRIPTION.HT"/>
            <property name="brokerQueueManager" value="SOMEHUB"/>
            <property name="tempQPrefix" value="MACHINE.USER.*"/>
        </bean>
    </property>
</bean>

Другой вопрос, на мой взгляд, это порты брандмауэра, мы попросили открыть 1417 и 1499, но кажется, что открыт только 1417. Плюс я не знаю, открыты ли порты брандмауэра в обратную сторону, от WebsphereMQ обратно ко мне.

Буду очень признателен, если кто-нибудь сможет дать какой-нибудь совет!

Редактировать 1:

Я попробовал replyTo=queue:XYZ предложение Клауса, и результат был таким:

2013-12-03 14:38:04,636 | WARN  | eplyManager[FOO] | entQueueMessageListenerContainer
| ?                                   ? | 153 - org.springframework.jms - 
3.0.7.RELEASE |     Setup of JMS message listener invoker failed for destination 'FOO'
- trying to recover. Cause: MQJMS2008: failed to open MQ queue ; nested exception is 
com.ibm.mq.MQException: MQJE001: Completion Code 2, Reason 2085

java ibm-mq jms apache-camel fuseesb
person vikingsteve    schedule 02.12.2013    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Вы также можете использовать именованные очереди ответов. Возможно, это лучше работает с WMQ. Таким образом, в uri конечной точки Camel вы просто устанавливаете answerTo=queue:foobar, чтобы использовать очередь с именем foobar в качестве очереди ответов.

Это установит заголовок JMSReplyTo как foobar в качестве имени очереди, поэтому «другая сторона» будет использовать его для очереди ответов вместо временного имени очереди.

См. документацию Camel JMS для получения более подробной информации о запросе/ответе через JMS, поскольку существует множество параметров, которые вы можете настроить и настроить: http://camel.apache.org/jms

Кроме того, в прошлом WMQ не связывал длинные идентификаторы корреляции, и для параметра useMessageIDAsCorrelationID можно было установить значение true, чтобы использовать идентификатор сообщения, созданный WMQ для сообщения запроса. В противном случае Camel генерирует длинный случайный идентификатор.

person Claus Ibsen    schedule 02.12.2013
comment
Спасибо, Клаус, я попробую это, когда вернусь завтра в офис. - person vikingsteve; 02.12.2013
comment
Я пробовал replyTo=queue:FOO разными способами (например, с префиксом, похожим на мой tempQName), и он не смог настроить очередь (см. редактирование), у меня было MQException. Потом с useMessageIDAsCorrelationID результат был тот же - таймаут через 20000 миллис. Любые другие предложения? - person vikingsteve; 03.12.2013
comment
Окончательным решением этой проблемы было настроить uri очереди с deliveryPersistent=1 и useMessageIDAsCorrelationID=true. - person vikingsteve; 30.04.2014
comment
И что касается идентификаторов корреляции, WMQ имеет странный метод отправки обратно строки, начинающейся с ID: и содержащей коды символов Ascii первых 24 символов отправленного вами идентификатора корреляции. Если вы сначала выполните это преобразование самостоятельно (как я полагаю, useMessageIDAsCorrelationID делает для вас), то вы получите тот же идентификатор корреляции обратно (как и предполагалось). - person vikingsteve; 30.04.2014