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 exactly which queues they are written in the Information Center in 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 funneled 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')
DEFINE TOPIC(ADMIN.CHANNEL.EVENT) TOPICSTR('Events/Channel')

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.

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.

 

Tags:  publish publish/subscribe mq websphere wmq events