You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by John McDonald <mc...@gmail.com> on 2011/03/11 13:58:14 UTC
Bridging from JMS to Websphere
I am attempting to use the Camel JMS component to deliver messages to a Websphere queue. Whilst the message delivery seems fine it is being wrapped in what I understand to be a JMS wrapper which the consuming client isnt expecting. As a result the message is not being processed correctly. I do not control the consumer so I cannot commission any changes to the idiom of access that they are using.
From what I can tell in reading around this is a recognised scenario and that by setting targetClient appropriately I can suppress the creation of the wrapper. The JMS component documentation intimates as much at http://camel.apache.org/jms.html with this entry
.setHeader("CamelJmsDestinationName", constant("queue:///MY_QUEUE?targetClient=1"))
.to("wmq:queue:MY_QUEUE?useMessageIDAsCorrelationID=true");
When I attempt this I get an exception the significant part of which is
Caused by: org.springframework.jms.UncategorizedJmsException: Uncategorized exception occured during JMS processing; nested exception is com.ibm.msg.client.jms.DetailedJMSException: JMSCC0005: The specified value 'queue:BT.CL.AXMONVT1.ONV.AXM_TO_ONV_RES.01?targetClient=1' is not allowed for 'XMSC_DESTINATION_NAME'. The given value is not allowed for the property specified. Change the value to a value that is supported for the property.
Re: Bridging from JMS to Websphere
Posted by Jon Anstey <ja...@gmail.com>.
FYI when I was successfully using that targetClient option mentioned in the
wiki, it was connecting to WMQ with the new OSGi client libs (ex
com.ibm.mq.osgi.directip_7.0.1.1.jar, com.ibm.msg.client.osgi*_7.0.1.1.jar).
Not sure if that makes any different here.
Cheers,
Jon
On Fri, Mar 11, 2011 at 2:05 PM, John McDonald <mc...@gmail.com> wrote:
> Thanks for that Tarun
>
> I would classify my level of Camel expertise to be just about the same -
> perhaps 'enthusiast' too - I'm pretty impressed!
>
> Camel JMS doesnt know about it because its a WMQ feature is something I
> have read on several occasions now and this is consistent with your account
> - which is most useful background.
>
> I also came across a thread at
> http://camel.465427.n5.nabble.com/Camel-2-4-0-Websphere-MQ-NONJMS-Message-td3241328.htmlthat looks as though it addresses the same issue
>
> I am going to pair with a bottle of wine on this problem later - if I get a
> breakthrough I will let you know
>
>
> On 11 Mar 2011, at 17:15, Tarun Ramakrishna wrote:
>
> >> The error is in attempting to set that value but I am unclear why it
> should be.
> > Well..I can explain the reason if not how to solve this problem
> > specifically for the camel jms component. I probably will run into
> > your problem in the future since we have need to post and reply using
> > native messages to Websphere MQ, though we haven't got around to doing
> > this yet.
> >
> > The reason is because legacy Websphere MQ clients cannot understand
> > Websphere MQ JMS compliant messages. The 'native' WMQ message format
> > was invented before the days of the JMS spec, so they needed to add
> > another header called the MQRFH2 header to support JMS compliant
> > messages. (for features like typed message properties, etc).
> > Unfortunately, those legacy applications (usually on mainframes, etc)
> > cannot parse such messages. So, one needs to tell the driver to form
> > WMQ messages without the MQRFH2 header.
> >
> > This is generally done by using
> > MQDestination.setTargetClient(JMSC.MQJMS_CLIENT_NONJMS_MQ). The value
> > of JMS.MQJMS_CLIENT_NONJMS_MQ is 1. Additionally, if you are using the
> > Reply-To header, you also need to call
> > MQConnectionFactory.setTargetClientMatching(true), so that the replies
> > do not construct the RFH2 header.
> >
> > I am just a Camel beginner, but it looks to me as if the camel jms
> > component doesn't know about all this stuff..
> >
> > Best Regards,
> > Tarun
>
>
--
Cheers,
Jon
---------------
FuseSource
Email: jon@fusesource.com
Web: fusesource.com
Twitter: jon_anstey
Blog: http://janstey.blogspot.com
Author of Camel in Action: http://manning.com/ibsen
Re: Bridging from JMS to Websphere
Posted by John McDonald <mc...@gmail.com>.
Thanks for that Tarun
I would classify my level of Camel expertise to be just about the same - perhaps 'enthusiast' too - I'm pretty impressed!
Camel JMS doesnt know about it because its a WMQ feature is something I have read on several occasions now and this is consistent with your account - which is most useful background.
I also came across a thread at http://camel.465427.n5.nabble.com/Camel-2-4-0-Websphere-MQ-NONJMS-Message-td3241328.html that looks as though it addresses the same issue
I am going to pair with a bottle of wine on this problem later - if I get a breakthrough I will let you know
On 11 Mar 2011, at 17:15, Tarun Ramakrishna wrote:
>> The error is in attempting to set that value but I am unclear why it should be.
> Well..I can explain the reason if not how to solve this problem
> specifically for the camel jms component. I probably will run into
> your problem in the future since we have need to post and reply using
> native messages to Websphere MQ, though we haven't got around to doing
> this yet.
>
> The reason is because legacy Websphere MQ clients cannot understand
> Websphere MQ JMS compliant messages. The 'native' WMQ message format
> was invented before the days of the JMS spec, so they needed to add
> another header called the MQRFH2 header to support JMS compliant
> messages. (for features like typed message properties, etc).
> Unfortunately, those legacy applications (usually on mainframes, etc)
> cannot parse such messages. So, one needs to tell the driver to form
> WMQ messages without the MQRFH2 header.
>
> This is generally done by using
> MQDestination.setTargetClient(JMSC.MQJMS_CLIENT_NONJMS_MQ). The value
> of JMS.MQJMS_CLIENT_NONJMS_MQ is 1. Additionally, if you are using the
> Reply-To header, you also need to call
> MQConnectionFactory.setTargetClientMatching(true), so that the replies
> do not construct the RFH2 header.
>
> I am just a Camel beginner, but it looks to me as if the camel jms
> component doesn't know about all this stuff..
>
> Best Regards,
> Tarun
Re: Bridging from JMS to Websphere
Posted by Tarun Ramakrishna <ta...@elankath.com>.
> The error is in attempting to set that value but I am unclear why it should be.
Well..I can explain the reason if not how to solve this problem
specifically for the camel jms component. I probably will run into
your problem in the future since we have need to post and reply using
native messages to Websphere MQ, though we haven't got around to doing
this yet.
The reason is because legacy Websphere MQ clients cannot understand
Websphere MQ JMS compliant messages. The 'native' WMQ message format
was invented before the days of the JMS spec, so they needed to add
another header called the MQRFH2 header to support JMS compliant
messages. (for features like typed message properties, etc).
Unfortunately, those legacy applications (usually on mainframes, etc)
cannot parse such messages. So, one needs to tell the driver to form
WMQ messages without the MQRFH2 header.
This is generally done by using
MQDestination.setTargetClient(JMSC.MQJMS_CLIENT_NONJMS_MQ). The value
of JMS.MQJMS_CLIENT_NONJMS_MQ is 1. Additionally, if you are using the
Reply-To header, you also need to call
MQConnectionFactory.setTargetClientMatching(true), so that the replies
do not construct the RFH2 header.
I am just a Camel beginner, but it looks to me as if the camel jms
component doesn't know about all this stuff..
Best Regards,
Tarun
Re: Bridging from JMS to Websphere
Posted by John McDonald <mc...@gmail.com>.
Thanks Martin
No need to apologise - if my post is unclear thats on me - I appreciate you responding.
The error is in attempting to set that value but I am unclear why it should be. I can post messages to the queue without error without this addition - its just that when I do the raw message has a preamble containing (with some unprintable chars in there)
RFH 3MQSTR <mcd><Msd>jms_text</Msd></mcd>
because of this the client cannot read the message body. I am given to understand that the reason is that this is a wrapper the production of which can be turned off by setting the clientId in this way.
On 11 Mar 2011, at 15:37, waterback wrote:
> Hi John,
>
> well i think i haven't understand all of your post...
>
> But i use sending to Websphere MQ queues from Camel in multiple examples...
> From my experience the following in your definition:
>
> " .setHeader("CamelJmsDestinationName",
> constant("queue:///MY_QUEUE?targetClient=1")) "
>
> is actually not needed, or do you have that for a specific reason?
> But from the Error-Message you posted, this could be caused by that
> header...
>
> So, excuse me if i'm totally wrong...
>
> Cheers,
> Martin
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Bridging-from-JMS-to-Websphere-tp3425020p3425259.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Bridging from JMS to Websphere
Posted by waterback <ma...@innoq.com>.
Hi John,
well i think i haven't understand all of your post...
But i use sending to Websphere MQ queues from Camel in multiple examples...
>From my experience the following in your definition:
" .setHeader("CamelJmsDestinationName",
constant("queue:///MY_QUEUE?targetClient=1")) "
is actually not needed, or do you have that for a specific reason?
But from the Error-Message you posted, this could be caused by that
header...
So, excuse me if i'm totally wrong...
Cheers,
Martin
--
View this message in context: http://camel.465427.n5.nabble.com/Bridging-from-JMS-to-Websphere-tp3425020p3425259.html
Sent from the Camel - Users mailing list archive at Nabble.com.