| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Converting InputRoot.MQMD.CorrelId to Integer |
« View previous topic :: View next topic » |
| Author |
Message
|
| rahulk01 |
 Posted: Thu Mar 26, 2020 4:32 am Post subject: Converting InputRoot.MQMD.CorrelId to Integer |
 |
|
Apprentice
Joined: 26 Dec 2019
Posts: 35
|
Hi,
I have a requirement where I have to convert the incoming CorrelId into Integer, which needs to be used to correlate a request.
Using statements like
Declare nCorrelId INTEGER (InputRoot.MQMD.CorrelID AS INTEGER) doesn't work.
I am assuming the correlid to be in the blob format so was expecting CAST to work. Any info would be greatly appreciated.
Rahul |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Mar 26, 2020 4:45 am Post subject: Re: Converting InputRoot.MQMD.CorrelId to Integer |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| rahulk01 wrote: |
Hi,
I have a requirement where I have to convert the incoming CorrelId into Integer, which needs to be used to correlate a request |
Why would you need to convert it? It's intended in it's current form to correlate with a request; the clue is in the name.
Both the message and correlation id are hexbinary, and can't be represented as integers
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Mar 26, 2020 4:58 am Post subject: Re: Converting InputRoot.MQMD.CorrelId to Integer |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| rahulk01 wrote: |
Hi,
I have a requirement where I have to convert the incoming CorrelId into Integer, which needs to be used to correlate a request.
Using statements like
Declare nCorrelId INTEGER (InputRoot.MQMD.CorrelID AS INTEGER) doesn't work.
I am assuming the correlid to be in the blob format so was expecting CAST to work. Any info would be greatly appreciated.
Rahul |
As Vitor said... Good luck with it as it is a 24 byte binary value! The question would be how is it set in the first place? And may be you should read it back right after you set it to get the correct 24 byte value... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Mar 26, 2020 5:32 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
|
| Back to top |
|
|
| rahulk01 |
| Posted: Thu Mar 26, 2020 5:37 am Post subject: |
|
|
Apprentice
Joined: 26 Dec 2019
Posts: 35
|
Thanks for all the help.
I tried the below code and it works now.
DECLARE id INTEGER CAST(CAST(SUBSTRING(CAST(InputRoot.MQMD.CorrelId as CHAR) FROM 35 for 16) AS BLOB) AS INTEGER);
Actually I am working on a framework (FTM) where correlation with the response happen at a DB field level, and while sending out the request a transmission id (an integer) is generated and stored in the db column and the same is converted into a msgId and sent out in the request. So when the response comes the correlId needs to be converted to Integer so it can be correlated against an existing integer. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Mar 26, 2020 5:51 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
If the requesting app explicitly sets the the value of the MsgId field, then the responding app need only copy the inbound MsgId to the outbound CorrelId of the reply msg. No conversion at requesting or responding Apps will be needed.
_________________
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 |
|
|
| Vitor |
| Posted: Thu Mar 26, 2020 7:09 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| rahulk01 wrote: |
| Actually I am working on a framework (FTM) where correlation with the response happen at a DB field level, and while sending out the request a transmission id (an integer) is generated and stored in the db column and the same is converted into a msgId and sent out in the request. So when the response comes the correlId needs to be converted to Integer so it can be correlated against an existing integer. |
Ok, so not only is this reinventing the wheel, it's vey much anti-pattern. Using the message id & correlation id fields for non-MQ data is not a good idea. As you've discovered, you need to do a fair amount of dancing to get it to work. There's also the risk that your framework will hiccup and generate a duplicate message id; the queue manager will love that.
If you have a separate piece of data that you need to include with your messages, there are a number of options within the MQMD or, better still, add it as a message property / RFH2 construct.
Don't mess with the system generated fields.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Mar 26, 2020 7:13 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| rahulk01 wrote: |
| Actually I am working on a framework (FTM) where correlation with the response happen at a DB field level, and while sending out the request a transmission id (an integer) is generated and stored in the db column and the same is converted into a msgId and sent out in the request. So when the response comes the correlId needs to be converted to Integer so it can be correlated against an existing integer. |
Ok, I keep reading this and I still can't get it to make sense.
Isn't an integer too small to be an id? Especially with a high volume framework? It's going to roll over in a very short period of time and the most sensible use case for what you're describing is a long term audit store.
Second, but connected, why not have the database correlate on the MQ correlation id? That will fit in a DB column just as well as an integer and saves you work.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Mar 26, 2020 9:44 am Post subject: Re: Converting InputRoot.MQMD.CorrelId to Integer |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| rahulk01 wrote: |
| I am assuming the correlid to be in the blob format |
No. MsgId, CorrelId, GroupId fields are mq data type BYTE24. BYTE24 is 24 bytes of 8-bits each. 8x24=192bits.
From https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_8.0.0/com.ibm.mq.ref.dev.doc/q097550_.htm
| Quote: |
This is a byte string that is used to distinguish one message from another. Generally, no two messages should have the same message identifier, although this is not disallowed by the queue manager. The message identifier is a permanent property of the message, and persists across restarts of the queue manager. Because the message identifier is a byte string and not a character string, the message identifier is not converted between character sets when the message flows from one queue manager to another.
For the MQPUT and MQPUT1 calls, if MQMI_NONE or MQPMO_NEW_MSG_ID is specified by the application, the queue manager generates a unique message identifier 1 when the message is put, and places it in the message descriptor sent with the message. The queue manager also returns this message identifier in the message descriptor belonging to the sending application. The application can use this value to record information about particular messages, and to respond to queries from other parts of the application. |
In the usual request-reply model, the requesting app specifies that the qmgr is to generate a unique MsgId for this message. The replying app merely copies the inbound MsgId to the outbound CorrelId field of the reply (or report) message.
You could, I suppose, view the BYTE24 192 bits wide field as one binary field, and generate your own unique MsgId/CorrelId fields, but to what purpose?
_________________
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 |
|
|
| gbaddeley |
| Posted: Thu Mar 26, 2020 2:13 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| rahulk01 wrote: |
Thanks for all the help.
I tried the below code and it works now.
DECLARE id INTEGER CAST(CAST(SUBSTRING(CAST(InputRoot.MQMD.CorrelId as CHAR) FROM 35 for 16) AS BLOB) AS INTEGER);
Actually I am working on a framework (FTM) where correlation with the response happen at a DB field level, and while sending out the request a transmission id (an integer) is generated and stored in the db column and the same is converted into a msgId and sent out in the request. So when the response comes the correlId needs to be converted to Integer so it can be correlated against an existing integer. |
In principle, this will work.
CorrelId and MsgId are 24 bytes, so if you are only using some of those bytes for correlating request/reply messages, you must ensure that the rest of the bytes are set to a constant value, such as binary zeroes or a fixed literal. If you don't do this, and random garbage creeps into these bytes, it will break MQ's get-by-correlid feature.
You mentioned using an integer stored in a DB column as the correlator. Be aware that this must not wrap around in the medium-long term. I suggest that you use a long integer (64 bits) rather than normal integer (32 bits).
_________________
Glenn |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Mar 26, 2020 2:58 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| rahulk01 wrote: |
| Actually I am working on a framework (FTM) where correlation with the response happen at a DB field level, |
Ok, so state data is captured to a DB.
| rahulk01 wrote: |
| and while sending out the request a transmission id (an integer) is generated and stored in the db column |
Good so far. The app generates an integer to be used as the MsgId.
| rahulk01 wrote: |
| and the same is converted into a msgId and sent out in the request. |
What do you mean here by " ... is converted into a msgid"? The integer simply needs to be copied to the MsgId field, not converted.
| rahulk01 wrote: |
| So when the response comes the correlId needs to be converted to Integer so it can be correlated against an existing integer. |
You have two choices for MsgId at MQPUT: 1) you let the qmgr generate a unique MsgId; or 2) You create your own MsgId.
So, if you set the MsgId field to an integer, the responding app need only copy the MsgId of the inbound request message to the CorrelId field of the outbound reply message.
As my distinguished colleague mentioned, if you choose to create your own MsgId, you are responsible for ensuring that the entire BYTE24 field is unique for your application.
The number 2,147,483,647 is the maximum positive value for a 4 byte (32-bit) signed binary integer in computing. Is that enough discrete MsgId's for you?
Have I misunderstood this?
_________________
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 |
|
|
| timber |
| Posted: Fri Mar 27, 2020 6:45 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
Why is your current approach better than Vitor's suggestion?:
| Quote: |
| If you have a separate piece of data that you need to include with your messages, there are a number of options within the MQMD or, better still, add it as a message property / RFH2 construct |
That seems far simpler and safer to me. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Mar 27, 2020 8:39 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Why the requirement for an integer? DBs can handle all kinds of data types.
_________________
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 |
|
|
|
|
|
| |
|
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
|
|
|
|
