| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| How to use JMS API to send to MQ 7.5 |
« View previous topic :: View next topic » |
| Author |
Message
|
| EricCox |
 Posted: Wed Jul 02, 2014 5:44 am Post subject: How to use JMS API to send to MQ 7.5 |
 |
|
Master
Joined: 08 Apr 2011
Posts: 292
|
To all,
We have a 3rd party developer who is using the JMS API to put messages to our MQ 7.5 Queue Manager and Queue.
What objects, methods and properties does he need to set on the message using the JMS API to put a normal MQ Message to our infrastructure.
I am not familiar with the JMS API and need to give the developer some help sending the message with the right properties so we can consume. Right now he has the MQMD.Format set to RFH2 which I believe indicates it is holding the JMS Header.
We will consume the message which contains XML in a Message Broker 8.0.0.2 Message Flow.
Thanks,
EMC |
|
| Back to top |
|
 |
| zpat |
| Posted: Wed Jul 02, 2014 6:00 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
You want to ensure persistence is set correctly.
To make the message non-JMS (and therefore more portable) you can generate a non-JMS message.
Options to generate standard MQSTR messages from JMS application.
1. Set the output MQ queue name URI (sometimes called destination resource) like this (rather than having just the queue name) - don't code the brackets []
queue:///[THE.MQ.QUEUE.DEFINITION]?targetClient=1
If you also want to control the message code page you can add this (819 = ascii, 1208 = utf8, 37 = US Ebcdic, 285 = uk ebcdic etc)
queue:///[THE.MQ.QUEUE.DEFINITION]?targetClient=1&CCSID=819
The MQ def can be a local or remote queue name as you wish.
You can also code it like this if you don't want to use remote queue definitions and it will directly hit the xmit queue called REMOTEQM
queue://[REMOTEQM]/[THE.REMOTE.MQ.QUEUE]?targetClient=1&CCSID=819
-------------------------- or ---------------------------
2. In the program code - set the target client on the queue object to NON JMS.
q.setTargetClient(JMSC.MQJMS_CLIENT_NONJMS_MQ);
------------------- or ---------------
3. In the JNDI or properties - do the same as option 1 or 2
NB: MQJMS_CLIENT_NONJMS_MQ equates to the value 1
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| EricCox |
| Posted: Wed Jul 02, 2014 6:12 am Post subject: Three Options |
|
|
Master
Joined: 08 Apr 2011
Posts: 292
|
Thanks very much.
I'm familiar with option one. That is how Hermes does it. I'm not familiar with the last two. I think our answer is in the last two.
Thanks,
EMC |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jul 02, 2014 6:18 am Post subject: Re: Three Options |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| EricCox wrote: |
Thanks very much.
I'm familiar with option one. That is how Hermes does it. I'm not familiar with the last two. I think our answer is in the last two.
Thanks,
EMC |
All three of his options are equivalent, other than altering the CCSID.
There's generally no issue in processing a message with an MQRFH2 in a broker flow, and generally no issue with processing messages from JMS in Broker - either using an MQInput node or a JMSInput node.
If you're concerned that your flow won't process the message correctly, use a Trace node to dump the logical message tree created from one the messages sent by this application. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
