Author |
Message
|
GLove |
Posted: Fri Jan 19, 2007 12:26 am Post subject: Correlation ID Hex Conversion Problem |
|
|
Newbie
Joined: 18 Jan 2007 Posts: 3 Location: Belgium
|
Hello,
I have a Windows application that writes messages on MQSeries queues. These messages are then read by an iSeries app on an AS/400 machine (at least, this is what my customer told me).
The customers application puts a message on a queue, with a RequestID in the message body (not in the header). The customer asked us to copy this RequestID in the correlation ID of any replies to their message.
The RequestID in the message body is 24 characters long. In our reply, I put it in the correlationID from the message header. After putting it on the queue, it is translated in hex format in the correlation ID hex, according to standard Windows ASCII charset (ISO-...?). However, when the customer application receives the message and translates our correlation ID hex to a standard 24 character correlation ID, this translation yields a wrong correlation ID.
I think this has something to do with the character set used by the customers application. They want us to translate the correlation ID into hex format using their character set, but I thought that MQSeries was the one to do the translation. Shouldn't our application be unaware of "the other side" (not knowing which machine or operating system or character set is running on the other side of the queue)?
Can anyone please explain this? Or give some good advise? I would like to keep my application clean of all information about the forementioned "other side": just a Windows app putting messages on MQSeries queues.
Thank you in advance,
Gert Willemsens _________________ It's not Murphy who created his law, but it's the people that misunderstood it! |
|
Back to top |
|
 |
Vitor |
Posted: Fri Jan 19, 2007 12:39 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
As has been discussed many, many times on this forum (as the search button will prove) the MsgId and CorrelId are not 24 characters long - they are byte arrays 24 bytes long! Attempts to treat them as character are fraught with problems, not least because of the character set problems you describe.
The reason they're byte arrays is to avoid exactly this problem - bytes are bytes on any platform. If you're setting CorrelId you should use memcpy (or similar) to move it from one field to the other without intervening translation.
You may find it useful to browse through some of the previous discussions concerning this, which may help with any specific issues you have. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
GLove |
Posted: Fri Jan 19, 2007 12:53 am Post subject: |
|
|
Newbie
Joined: 18 Jan 2007 Posts: 3 Location: Belgium
|
Vitor,
Thanks for the quick reply.
I have searched through the forum, but the number of results I get are always to big. Maybe I'm using the wrong keywords?
I'll discuss this with the customer.
Other suggestions are still welcome...
Kind regards,
Gert _________________ It's not Murphy who created his law, but it's the people that misunderstood it! |
|
Back to top |
|
 |
Vitor |
Posted: Fri Jan 19, 2007 1:03 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
GLove wrote: |
I'll discuss this with the customer.
Other suggestions are still welcome...
|
There is only one supported way to handle message & correlation ids, and that's to treat them as the data type they are. They should never be translated, for any reason, on any platform.
If the customer is providing a request id in the body of the message, and the message is a string format converted between platforms then this will not work. If the customer has any MQ knowledge they will understand this, and that it's not the accepted method of doing request / reply using the ids. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
jefflowrey |
Posted: Fri Jan 19, 2007 2:29 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
The customer appears to want a proper request/reply pattern.
GLove's problem is mostly likely in the code that was written to copy the Message ID to the Correlation ID. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
Vitor |
Posted: Fri Jan 19, 2007 2:35 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
jefflowrey wrote: |
GLove's problem is mostly likely in the code that was written to copy the Message ID to the Correlation ID. |
Which should not include the character set conversion referred to surely? _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
jefflowrey |
Posted: Fri Jan 19, 2007 4:18 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Since this is the WBIMB/WMB forum, the code should look exactly like
Code: |
Set OutputRoot.MQMD.CorrelId = InputRoot.MQMD.MsgId |
The Java API and XPath versions left as an exercise. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
GLove |
Posted: Mon Jan 22, 2007 2:14 am Post subject: |
|
|
Newbie
Joined: 18 Jan 2007 Posts: 3 Location: Belgium
|
Vitor, jefflowrey,
I'm trying to convince my customer to do things the proper way. I think I'll have to be a little stuborn on this one, but since MQSeries is made to do all this work, I don't see any reason why we shouldn't use it that way.
Thanks for all the advise!
Gert _________________ It's not Murphy who created his law, but it's the people that misunderstood it! |
|
Back to top |
|
 |
Vitor |
Posted: Mon Jan 22, 2007 2:37 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
GLove wrote: |
I'm trying to convince my customer to do things the proper way. I think I'll have to be a little stuborn on this one, but since MQSeries is made to do all this work, I don't see any reason why we shouldn't use it that way.
|
Point out that as it stands, you're reinventing the wheel. The proposed version of the wheel is not entirely circular, may squeak a bit and will be unsupported by IBM if it falls off the axle.
And you're trying to roll a business along on it.  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
|