Заголовок сообщения IBM Mq

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

Я отправляю файл xml в виде сообщения, но когда приложение читает сообщение, оно получает заголовок сообщения, например

<mcd><Msd>jms_text</Msd></mcd>  \0\0\0l<jms><Dst>queue:///TEST</Dst><Tms>1281475843707</Tms><Cid></Cid><Dlv>1</Dlv></jms>

я не хочу, чтобы этот заголовок сообщения присутствовал, и мой код для отправки этого сообщения выглядит следующим образом:

Properties props = new Properties();
    props.setProperty("java.naming.factory.initial",this.initialFactory);
    props.setProperty("java.naming.provider.url", url);

    Context context = new InitialContext(props);

    QueueConnectionFactory qcf = (QueueConnectionFactory) context.lookup(this.context);
    qConn = qcf.createQueueConnection();
    queue = (Queue)context.lookup(name);
    qSession = qConn.createQueueSession(false, QueueSession.AUTO_ACKNOWLEDGE);
    qConn.start();
            QueueSender send = qSession.createSender(queue);
     String text = "My xml file";
     TextMessage tm = qSession.createTextMessage(text);
     send.send(tm);
     send.close();

Как мне этого избежать?


head ibm-mq
person Anand Sunderraman    schedule 16.08.2010    source источник

Ответы (2)


arrow_upward
9
arrow_downward

Похоже, вы отправляете сообщение jms в пункт назначения, отличный от jms. Как сообщение потребляется в пункте назначения? Ожидается ли собственное сообщение MQ? Получатель не понимает заголовок MQRFH2, в котором хранятся свойства заголовка JMS.

Вы должны либо настроить пункт назначения для понимания jms, либо вы можете сделать что-то вроде следующего, чтобы сообщить mq jms, что ваш получатель не является клиентом jms.

((com.ibm.mq.jms.MQQueue) queue).setTargetClient(JMSC.MQJMS_CLIENT_NONJMS_MQ);
person gregwhitaker    schedule 16.08.2010
comment
эй, спасибо, чувак, это работает, я только что попробовал твое исправление. теперь я должен понять, что это значит - person Anand Sunderraman; 19.08.2010
comment
Что ж, поскольку вы использовали обходной путь в коде, а не устанавливали управляемый объект, это означает, что любые другие приложения или модули, отправляющие сообщения JMS в этот пункт назначения, также будут иметь ту же проблему. Установите его в администрируемых объектах (файл .bindings, LDAP или что-то еще), и он будет исправлен без кода и во всех приложениях, использующих этот управляемый объект. - person T.Rob; 20.08.2010
comment
@T.Rob - я согласен с тем, что он должен настроить администрируемый объект для правильного получения сообщений jms, но из его вопроса видно, что он не контролирует конечную точку. - person gregwhitaker; 20.08.2010
comment
@gwhitake Интересно, мы говорим о разных вещах? Администрируемый объект, о котором я говорю, — это файл .bindings, LDAP или управляется локальным сервером веб-приложений, в зависимости от того, как работает его приложение. Таким образом, даже если у него нет контроля над конечной точкой, кто-то сгенерировал управляемый объект фабрики соединений WMQ, который извлекает его приложение. Если этот человек устанавливает targclient, то любой код, использующий этот управляемый объект, работает без изменений. - person T.Rob; 20.08.2010
comment
Конечно, приложение может даже не использовать JNDI для получения CF, и в этом случае все это неприменимо, и единственным ответом является модификация кода. Но если есть управляемый объект, то есть возможность правильно поступить не только с targclient, но и с FAILIFQUIESCE и полдюжиной других свойств, важных во время выполнения. Масштабируемая стратегия заключается не в том, чтобы делать это в коде, где каждое приложение должно знать о различиях, правильно кодировать, а затем перекодировать после обновления до версии 7, а в том, чтобы делать это в управляемых объектах, где это используется во многих приложениях. - person T.Rob; 20.08.2010

arrow_upward
5
arrow_downward

Просмотрите свойства объектов JMS как указано в документации. В администрируемом объекте есть свойство TARGCLIENT, которое должно быть установлено на «MQ». Хотя у вас может не быть контроля над администрируемым объектом, ответственность за правильную настройку этого свойства лежит на лице, которое администрирует управляемые объекты. Если пункт назначения не понимает заголовки RFH2 (которые WMQ v6 использует для хранения свойств JMS), то во всех приложениях WMQ JMS, которые отправляют сообщения в этот пункт назначения, должно быть установлено это свойство.

Между прочим, тот факт, что у вас возникла эта проблема, как правило, указывает на то, что приложение, потребляющее сообщения, все еще находится в версии 6. Имейте в виду, что версия 6.0 WMQ устарела в сентябре 2011 года. Если вы сейчас переключитесь на версию 7 как на стороне QMgr, так и на стороне клиента, вы можете управлять этим с помощью простых настроек в самой очереди. Устаревшее приложение будет понимать сообщения независимо от того, прикреплен ли к ним RFH2, а клиентское приложение будет видеть ответы как сообщения JMS независимо от того, добавляет ли унаследованное приложение заголовки RFH2. Перейдите на версию 7 сейчас, избавьте себя от множества проблем при разработке этого приложения, а также избегайте необходимости перехода на версию 7 в следующем году.

Клиент WMQ v7 доступен для загрузки здесь

Обновление: окончание срока службы WMQ V6 перенесено на сентябрь 2012 года.

person T.Rob    schedule 16.08.2010