| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| How to move messageID to reply message's correlation ID |
« View previous topic :: View next topic » |
| Author |
Message
|
| erk |
 Posted: Fri Feb 09, 2007 9:59 am Post subject: How to move messageID to reply message's correlation ID |
 |
|
Newbie
Joined: 09 Feb 2007
Posts: 2
|
Hello - I have read a number of discussions here about charset conversions between ASCII and EBCDIC, and CCSID and other ways of controlling the conversions. None of those seem to address our issue exactly.
We have an EJB running under WebSpher 5.1.1.11 that listens on an MQ queue and receives mainframe-originated MQ messages. The EJB does work and sends a reply back on the reply-to queue specified in the original message. There's never a problem with the body of the message - it comes over fine, and the reply goes back fine. The problems we have are strictly in the headers.
1. We want to use the original message's JMSMessageID as the reply message's JMSCorrelationID. However, the JMS Message API doesn't offer getJMSMessageIDAsBytes, nor does it offer getByteArrayProperty(), so it seems you HAVE to get the message ID as a String. That implies that you have to know the encoding, which is cp500 / EBCDIC, or you can't populate your String properly to later call setJMSCorrelationIDAsBytes on the reply message before you send it.
Am I way off? I've tried various ways of moving the original message's JMS message ID to the reply's JMSCorrelationID, but the conversion is always bad unless I explicitly convert to and from a String using charset cp500.
2. We also have an issue with targetClient. We were originally getting the reply queue from the original message's replyTo, and sending on that. The problem is that we were inadvertantly sending RFH2 headers our mainframe couldn't handle.
We tried to get them to send ?targetClient=1 in the replyTo queue property, but that ended up not parsing properly in JMS - it was treated as part of the queue name, and failed completely. So now we create a new queue, using the replyTo queue's name property, and appending ?targetClient=1.
Is there an easier way on both of these? We're trying to use very generic JMS code, but the above have forced us to do things that I thought should be configured in the queues. I just don't know enough about the queues to tell the MQ administrators if they've got something set up wrong.
Thanks for anything you can tell me!
- Eric |
|
| Back to top |
|
 |
| elvis_gn |
| Posted: Fri Feb 09, 2007 10:12 am Post subject: Re: How to move messageID to reply message's correlation ID |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi erk,
| erk wrote: |
1. We want to use the original message's JMSMessageID as the reply message's JMSCorrelationID. However, the JMS Message API doesn't offer getJMSMessageIDAsBytes, nor does it offer getByteArrayProperty(), so it seems you HAVE to get the message ID as a String. That implies that you have to know the encoding, which is cp500 / EBCDIC, or you can't populate your String properly to later call setJMSCorrelationIDAsBytes on the reply message before you send it.
Am I way off? I've tried various ways of moving the original message's JMS message ID to the reply's JMSCorrelationID, but the conversion is always bad unless I explicitly convert to and from a String using charset cp500. |
The id's(msgId and correlId) for a jms message are string, then why do you require the conversion ? You would need to convert, if you were using jms at one end and mq on the other....or am I missing something ?
| erk wrote: |
2. We also have an issue with targetClient. We were originally getting the reply queue from the original message's replyTo, and sending on that. The problem is that we were inadvertantly sending RFH2 headers our mainframe couldn't handle.
We tried to get them to send ?targetClient=1 in the replyTo queue property, but that ended up not parsing properly in JMS - it was treated as part of the queue name, and failed completely. So now we create a new queue, using the replyTo queue's name property, and appending ?targetClient=1. |
I did not get your requirement completely on this one, can you explain your flow in a little more detail...mentioning where you have jms, replyToQ etc.
Regards. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Feb 09, 2007 10:17 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Feb 10, 2007 7:26 pm Post subject: Re: How to move messageID to reply message's correlation ID |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| erk wrote: |
Hello - I have read a number of discussions here about charset conversions between ASCII and EBCDIC, and CCSID and other ways of controlling the conversions. None of those seem to address our issue exactly.
We have an EJB running under WebSpher 5.1.1.11 that listens on an MQ queue and receives mainframe-originated MQ messages. The EJB does work and sends a reply back on the reply-to queue specified in the original message. There's never a problem with the body of the message - it comes over fine, and the reply goes back fine. The problems we have are strictly in the headers.
1. We want to use the original message's JMSMessageID as the reply message's JMSCorrelationID. However, the JMS Message API doesn't offer getJMSMessageIDAsBytes, nor does it offer getByteArrayProperty(), so it seems you HAVE to get the message ID as a String. That implies that you have to know the encoding, which is cp500 / EBCDIC, or you can't populate your String properly to later call setJMSCorrelationIDAsBytes on the reply message before you send it.
Am I way off? I've tried various ways of moving the original message's JMS message ID to the reply's JMSCorrelationID, but the conversion is always bad unless I explicitly convert to and from a String using charset cp500. |
Yes you are way off. The JMSMessageId should be a string representation of a byte array in form of ID:00-FF i.e. a hex representation of the byte array. So all you have to do is
outmsg.setCorrelId(inmsg.getMessageId());
The pattern is one of anonymous identifier. And don't worry about translating ever... a byte is still a byte which ever the system...
| erk wrote: |
2. We also have an issue with targetClient. We were originally getting the reply queue from the original message's replyTo, and sending on that. The problem is that we were inadvertantly sending RFH2 headers our mainframe couldn't handle.
We tried to get them to send ?targetClient=1 in the replyTo queue property, but that ended up not parsing properly in JMS - it was treated as part of the queue name, and failed completely. So now we create a new queue, using the replyTo queue's name property, and appending ?targetClient=1.
|
Depending on your version you are doing the right thing...
Check out defining the queues with uri myqname="queue://destqmgr/destq?prop=value&prop2=value2";
session.createQueue(myqname);
However if you move to version 6 of MQ you have an additional property on the QCF. By default qcf.setTargetClientMatching(true);
This should ensure that the reply message gets an RFH only if the request message had one....
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| erk |
| Posted: Mon Feb 12, 2007 6:54 am Post subject: Thanks! |
|
|
Newbie
Joined: 09 Feb 2007
Posts: 2
|
Thanks all - I was under the impression that the bytes had to be left "uninterpreted", and couldn't understand the absence of getJMSMessageIDAsBytes; and I thought I had tested that case, but obviously not. Our code is now working fine.
Thanks again! |
|
| 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
|
|
|
|
