Publish your MQ Event Messages

The developerWorks Connections platform, which hosted the AIM Support Blog, was sunset as of 31st December 2019. The blog post below was something I wrote previously on that platform, and since I consider it to still be useful, I am now hosting a copy here. I have retained the original posting date and comments. View all saved from sunset posts here.

With the introduction of publish/subscribe natively in the queue manager with WebSphere MQ V7, you can now utilize that feature to publish your MQ event messages too. Why would you want to? Well, there may be a number of applications that want to get the information that is emitted by the queue manager in events. One technique is to daisy chain those applications, but a much simpler technique, requiring fewer application changes, maybe even none, is to publish the events instead.

Event Messages

WebSphere MQ emits a number of different event messages if you enable it to do so. These events are written to specially named queues called SYSTEM.ADMIN.<feature-name>.EVENT. You can read more detail about the types of event messages, how to enable them, and to exactly which queues they are written, in IBM Docs at Event Monitoring.

In this post we will look at how to change your queue manager to publish these events.

Event Queues

The important thing to note about event queues is that it is the name that matters. By default on a queue manager, all event queues are defined as local queues. However, you can delete these queues and redefine them, perhaps as a remote queue, so that all events are funnelled to a dedicated event processing queue manager. This ability has been available for many years, and many releases of MQ.

With WebSphere MQ V7 however there is now another way to delete and redefine these event queues, and that is to use an alias queue that is pointing at a topic object.

It is worth noting that any redirection technique, whether remote queues or topics, cannot be employed if the applications reading the event queues have hard-coded the queue name to read from. If the queue was then changed to a remote queue, opening it for MQOO_INPUT_* would not be allowed of course! The same is true of an alias pointing at a topic. So, if you want to employ either of these redirection techniques, first convince the supplier of your event reading application to allow you to configure the queue they read from, after all, such techniques are not new!

Publishing Event Messages

Here are some example commands to show how you can redefine your event queues so that the event messages will be published. We make the assumption that either you have not started using events, or that you have removed all the messages from the existing event queues and have deleted the local queues prior to these steps. These steps only show the QMGR and CHANNEL event queues being redefined, but this could be extended for all events. Note, that the topic string is designed so that an application can be subscribed to all events using a wildcard, or to specific events, as required.

DEFINE TOPIC(ADMIN.QMGR.EVENT) TOPICSTR('Events/QMgr') USEDLQ(NO)

DEFINE TOPIC(ADMIN.CHANNEL.EVENT) TOPICSTR('Events/Channel') USEDLQ(NO)

DEFINE QALIAS(SYSTEM.ADMIN.QMGR.EVENT) TARGTYPE(TOPIC) TARGET(ADMIN.QMGR.EVENT)

DEFINE QALIAS(SYSTEM.ADMIN.CHANNEL.EVENT) TARGTYPE(TOPIC) TARGET(ADMIN.CHANNEL.EVENT)

DEFINE QLOCAL(ADMIN.EVENT)
DEFINE QLOCAL(ADMIN.QMGR.EVENT)

DEFINE SUB(EVENTS.ALL) TOPICSTR('Events/+') PSPROP(NONE) DESTCLAS(PROVIDED) DEST(ADMIN.EVENT)

DEFINE SUB(EVENTS.QMGR) TOPICSTR('Events/QMgr') PSPROP(NONE) DESTCLAS(PROVIDED) DEST(ADMIN.QMGR.EVENT)

Assuming that your event reading application is able to read event messages from any queue, then it will be able to be reconfigured to read from one of the queues defined above as required.

The PSPROP(NONE) configuration on the DEFINE SUB commands is to ensure that none of the message properties added by the publish/subscribe engine, for example MQTopicString, are added to the event message, ensuring that existing applications can continue to work unchanged.

The USEDLQ(NO) configuration on the DEFINE TOPIC commands ensures that if your subscription queues fill up for some reason, e.g. the tool monitoring them stops working, then the DLQ isn’t used as an alternate location to satisfy the local MQPUTs. Event messages should probably be treated as a best-effort in this case. Collecting them should not be at the detriment of the rest of the system.

Additionally, applications can also now subscribe directly using the MQSUB verb to receive as an alternate way instead of using the administrative DEFINE SUB command.

So, now multiple applications are able to consume the information emitted in events by the queue manager.