| Author |
Message
|
| Blomman |
 Posted: Thu Feb 07, 2013 4:38 am Post subject: MQMD.Correlid length restriction |
 |
|
Master
Joined: 31 Oct 2006
Posts: 230
|
Hi!
Ok the field MQMD.Correlid has the restriction of 24bytes (Byte String).
In my scenario messages are being put on MQ from an JMS Bridge Where WMQ is an JMS Provider.
Now the JMSCorrelationId from the sending JMS application has an length that is longer than 24bytes, so the MQMD.Correlid will be "cut off".
So by this the MQMD.Correlid is now not fully unique as an CorrelationId should be.
In my eyes the CorrelationId thats now is stored in MQMD.Correlationid is "defect".
The fully unique and correct CorrelationId is of course stored in MQRFH2.jms.cid.
Can someone please sort out this for me?
For example if an receiving application cant handle jms, cant handle RFH2 etc, how to get the correct correlationid?
//Blomman |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Feb 07, 2013 4:43 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| If you've properly moved to MQ v7 or later, there is no RFH2, there is only message properties |
|
| Back to top |
|
|
| Blomman |
| Posted: Thu Feb 07, 2013 4:54 am Post subject: |
|
|
Master
Joined: 31 Oct 2006
Posts: 230
|
| mqjeff wrote: |
| If you've properly moved to MQ v7 or later, there is no RFH2, there is only message properties |
Really cool and really useful, thx for that info!
Another example then:
If the receiving "App" is a messageflow in WMB and the entry-point is an MQGet Node with the checkbox "Get by correlation ID" checked.
Yeah i know what the easy answer is, redesign your flow etc, etc.
But in the case i cant becuse of this and that.
Any work around?
//Blomman |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Feb 07, 2013 5:16 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I agree.
Message Broker does not support message properties
In general, when using MQGMO.MATCH_CORREL_ID, one is expecting a *response* to a *request* one has sent, such that one has specified the value that should come back.
From Broker, you would be setting OutputRoot.MQMD.CorrelID on the request, and then using that to match the response by using the checkbox on the MQGet node.
So I'm confused about how the other side using a larger field impacts that - you're sending a smaller field and matching the same smaller field on response.
You could otherwise simply not use MQ nodes and use JMS Nodes instead. Even with MQ as the JMS provider, that still gives you full JMS field lengths and lets the MQ jms provider worry about the mapping to the phyical message. |
|
| Back to top |
|
|
| Blomman |
| Posted: Thu Feb 07, 2013 5:58 am Post subject: |
|
|
Master
Joined: 31 Oct 2006
Posts: 230
|
| mqjeff wrote: |
You could otherwise simply not use MQ nodes and use JMS Nodes instead. Even with MQ as the JMS provider, that still gives you full JMS field lengths and lets the MQ jms provider worry about the mapping to the phyical message. |
Yeah probably the way to go, go JMS!
Everything is possible if you have the time and money for your projects.
Just wanted to verify that the field restictions in MQMD is a weakness and you always have to keep that in mind during designs of WMQ and WMB integrations.
Thx for interesting response as always mqjeff!
//Blomman |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Feb 07, 2013 6:08 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I would be uncomfortable using the word 'weakness'.
I would call it a 'design criteria' - something you have to consider if you're playing with things at that level of detail. |
|
| Back to top |
|
|
| Blomman |
| Posted: Thu Feb 07, 2013 8:46 am Post subject: |
|
|
Master
Joined: 31 Oct 2006
Posts: 230
|
| mqjeff wrote: |
I would be uncomfortable using the word 'weakness'.
I would call it a 'design criteria' - something you have to consider if you're playing with things at that level of detail. |
Yep design, i agree..
But sometimes the design and implementation works fine for a long long time.
And everything looked ok during design.
Its really hard to consider all things that will change during time and no design is perfect in that way.
Like an CorrelationId has to be extended..
However looking at the license cost, small things like the limitation of bytes in an basic field whitin the structure of an basic MQ message....
Like buying a Porsche and when you finally gets to the track, finding out that top speed is just 200km/h..
//Blomman |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Feb 07, 2013 10:17 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
Can you specify which JMS implementation has a field greater than 24 char? Think about the implementations that have over 50 bytes for the JMSCorrelationId but still return a String of 24 char for the getJMSCorrelationID call.... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
