This is part of a series of small blog posts which will cover some of the smaller, perhaps less likely to be noticed, features of IBM MQ. Read other posts in this series.
A question that comes in fairly regularly on MQ fora is about the message ID and the correlation ID in a message delivered to a subscriber.
Message ID
The message ID in a message delivered to a subscriber is unique to that message, so that every message in the system is uniquely identified. That is, even if there are several subscribers that each receive a copy of the same published message, the message ID in each copy will be different.
Correlation ID
The way the correlation ID works can follow one of two patterns. Either the correlation ID is the subscriber's unique correlation ID for every message, or the correlation ID is the one set by the publishing application. The pattern which is in effect is controlled by the creator of the subscription.
Subscriber's Correlation ID
This pattern is the default behaviour. When a subscription is created it is assigned a unique correlation ID which is then placed into each message delivered to that subscriber. This can be useful if several subscribing applications are sharing the same queue as they can each do an MQGET by CorrelId to retrieve their own messages.
An application can discover what the correlation ID assigned to it is by using the MQSD.SubCorrelId field on output from an MQSUB call.
MQSUB(hConn,
&SubDesc,
&hSub,
&hObj,
&CompCode,
&Reason);
if (CompCode == MQCC_OK)
{
memcpy(MsgDesc.CorrelId, SubDesc.SubCorrelId, MQ_CORREL_ID_LENGTH);
gmo.MatchOptions = MQMO_MATCH_CORREL_ID;
:
MQGET(hConn,
hObj,
&MsgDesc,
&gmo,
...
You can also see the correlation ID assigned to a subscription using the DISPLAY SUB command, and inspecting the DESTCORL attribute.
SUBID(414D51204D5147312020202020202020AF9C6E5A20002303) SUB(ApplePrices)
TOPICSTR(Price/Fruit/Apples) TOPICOBJ( ) DISTYPE(RESOLVED)
DEST(APPLE.FRUIT.Q) DESTQMGR(MQG1) PUBAPPID( ) SELECTOR( )
SELTYPE(NONE) USERDATA( )
PUBACCT(1601051500000083E2174C2DDA25A59C18E568EE03000000000000000000000B)
DESTCORL(414D51204D5147312020202020202020AF9C6E5A20002303) DESTCLAS(PROVIDED)
DURABLE(NO) EXPIRY(UNLIMITED) PSPROP(MSGPROP) PUBPRTY(ASPUB)
REQONLY(NO) SUBSCOPE(ALL) SUBLEVEL(1) SUBTYPE(API)
VARUSER(FIXED) WSCHEMA(TOPIC) SUBUSER(morag) CRDATE(2018-01-29)
CRTIME(17:04:13) ALTDATE(2018-01-29) ALTTIME(17:04:13)
Publisher's Correlation ID
Alternatively a subscription can request that it gets to see the correlation ID set by the publisher. In order to do this it must zero out it's subscription correlation ID. Here's how you'd do that in an application.
MQSD SubDesc = {MQSD_DEFAULT};
SubDesc.ObjectString.VSPtr = “Price/Fruit/Apples”;
SubDesc.ObjectString.VSLength = MQVS_NULL_TERMINATED;
SubDesc.Options = MQSO_CREATE
| MQSO_SET_CORREL_ID;
memcpy(SubDesc.SubCorrelId, MQCI_NONE, MQ_CORREL_ID_LENGTH);
MQSUB(hConn,
...
And here's how you would do that with an administratively defined subscription:-
DEFINE SUB('ApplePrices') +
TOPICSTR('Price/Fruit/Apples') +
DEST(APPLE.PRICE.Q) +
DESTCORL(0)
Now if you need to correlate between publishing and subscribing applications you know how to get hold of that ID.
Morag Hughson is an MQ expert. She spent 18 years in the MQ Devt organisation before taking on her current job writing MQ Technical education courses with
MQGem. She also blogs for
MQGem. You can connect with her here on IMWUC or on
Twitter and
LinkedIn.