| Author |
Message
|
| Sam Uppu |
 Posted: Tue Apr 20, 2010 9:42 am Post subject: JMSCorrelId -> MQMD CorrelId in request/ reply model |
 |
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
Hi Guys,
We are using MQ 7 on AIX (source) and z/OS on destination ends.
We have source app(JMS) -> MQ -> destination app(mainframe). The source and destination apps are using MQ in request/ reply model and a synchronous process.
The source app(JMS) is sending in a JMSCorrelId in "string" format. lets say: 3456. This JMSCorrelId should be mapped MQMD CorrelId when the msg arrives onto MQ.
The JMS app should be sending the JMSCorrelId in hex format only or can it also be in string?.
Right now the JMS app is sending in string format and when the reply is received back from mainframe it is receiving in something like this: "ID:" hexadecimal junk value. The destination mainframe app is copying the original CorrelId from request msg and placing it onto the reply msg's CorrelId value. The JMS app team is expecting the original CorrelId value from the request msg.
Please suggest your thoughts.
Thanks. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Apr 20, 2010 9:51 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
After having set the correlid onto the message retrieve it.
If you did it right you will get the "ID:xxxxx" form.
Notice that the value after the "ID:" is the hex display of the bytes.
By the way, you should not be setting the correl Id but let MQ set it for you or go for reply.correlId=request.messageId. (Think anonymous identifier).
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Apr 20, 2010 9:53 am Post subject: Re: JMSCorrelId -> MQMD CorrelId in request/ reply model |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Sam Uppu wrote: |
| The JMS app should be sending the JMSCorrelId in hex format only or can it also be in string?. |
It's only hex. Under the covers it's a byte array.
| Sam Uppu wrote: |
| The JMS app team is expecting the original CorrelId value from the request msg. |
They expect it vain. It's because of this problem WMQ uses a byte array rather than a string. It's possible to get this to work between Unix platforms if luck is on your side, but strings going from z/OS to Unix have a tendancy to turn into junk.
| Sam Uppu wrote: |
| Please suggest your thoughts. |
The app team should a) stop treating this value as a string & b) stop setting it explicitly. Let the queue manager set it (to a hex value) and all will be well. Without further code changes.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Tue Apr 20, 2010 10:17 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| fjb_saper wrote: |
After having set the correlid onto the message retrieve it.
If you did it right you will get the "ID:xxxxx" form.
Notice that the value after the "ID:" is the hex display of the bytes.
By the way, you should not be setting the correl Id but let MQ set it for you or go for reply.correlId=request.messageId. (Think anonymous identifier).
Have fun |
If the JMS app doesn't set the CorrelId value manually and let the MQ generate it, how the JMS app will identify the corresponding reply msg?.
Thanks. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Tue Apr 20, 2010 10:38 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
When I was going thru this thread, I see a note saying:
One approach that many people use is the following...
When they create a message that will serve as a request, they have the Queue Manager set the MsgId to some unique value, and they will leave the CorrelId blank. The application will then put the message to a queue. On the other side, another application will pick up the request, process it, and prepare a reply message. Now, what this application does is create a new message, and again, lets the queue manager provide the MsgId. However, this application will set the CorrelId of the reply message to the MsgId of the request message it just processed. It then puts this new message to the reply queue. The original application, in the meantime, after sending off the request, did an MQGET on the reply queue, and specified to match against CorrelId, but the value it supplied to match against was actually the MsgId of the original request message.
It may be easier to see:
Request Message
---------------
MsgId: 123456789 (some value from the QMgr)
CorrelId : null
Reply Message
-------------
MsgId: 564563233 (some other value from QMgr)
CorrelId: 123456789 (original MsgId)
So the application that made the request will wait for a reply message with a CorrelId of 123456789
Question:
As the source app(JMS app), didn't generate any of the MSgId and/ or CorrelId, it doesn't have any idea of what MQ generated for MsgId and/ or CorrelId values for its request msg. So how come the Source app(JMS), will able to identify the associated/ corresponding reply msg for a particular request?.
Thanks. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Apr 20, 2010 11:01 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Sam Uppu wrote: |
| If the JMS app doesn't set the CorrelId value manually and let the MQ generate it, how the JMS app will identify the corresponding reply msg?. |
Because the generated value is available to the requesting app.
It's a design consideration (based in no small measure on the abilities of the responding app) if the requesting app has WMQ set message id & correl id, or identifies the reply as having the original message id in it's correl id.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Apr 20, 2010 11:03 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Sam Uppu wrote: |
| As the source app(JMS app), didn't generate any of the MSgId and/ or CorrelId, it doesn't have any idea of what MQ generated for MsgId and/ or CorrelId values for its request msg. |
Yes it does. Or it should.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Apr 20, 2010 12:08 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
MsgId, CorrelId, GroupId, are 24 byte fields. They do not contain anything but 24 bytes.
These are bytes only, and should not be treated as a String or hex or anything else.
They are not subject to conversion. Thus, a msgid in the request message sent from Win to z/OS (or any other config of platforms) will arrive exacly as sent - 24 bytes. The replying app need only copy the inbound msgid to the outbound correlid field and put the reply msg to the reply-to-queue.
At the requesting app, the inbound reply msg correlid will exactly match the outbound request message.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Apr 20, 2010 6:26 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Try:
| Code: |
sender.send(requestmessage);
String mystring = requestmessage.getJMSMessageId();
//set up your selector here passing it the mystring in the right place
receiver.setSelector(myselector);
myreply = receiver.receive(long timeoutvalue); |
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
