How to Configure Websphere MQ Triggering ?

What is Triggering ?

WebSphere MQ provides a feature that enables an application or channel to be started automatically when there are messages available to retrieve from a queue.

How does Triggering Works ?

è A message is put to a queue defined as triggered.

è If a series of conditions are met, the queue manager sends a trigger message to an initiation queue. This is called a trigger event.

è A trigger monitor reads the trigger message and takes the appropriate action based on the contents of the message, which is typically to start a program to process the triggered queue.

è Trigger monitors may be built-in, supplied by a SupportPac, or user written.

Trigger Work Flow Diagram:

TRIGTYPE:

FIRST: A trigger event occurs when the current depth of the triggered queue changes from 0 to 1. Use this type of trigger when the serving program will process all the messages on the queue (i.e. until MQRC_NO_MSG_AVAILABLE). 

EVERY: A trigger event occurs every time a message arrives on the triggered queue. Use this type of trigger when the serving program will only process one message at a time. Note: On i5/OS this value is *ALL.

DEPTH: A trigger event occurs when the number of messages on the triggered queue reaches the value of the TRIGDPTH attribute. Use this type of trigger when the serving program is designed to process a fixed number of messages (i.e. all replies for a certain request). Note: When triggering by depth, triggering is disabled and must be re-enabled by using MQSET or ALTER QLOCAL

Trigger Interval

TriggerInterval or TRIGINT is a time interval specified on the QMGR definition for use by queues defined as TRIGTYPE=FIRST.

Situations may occur when messages are left on the queue. New messages will not cause another trigger message. To help with this situation, a trigger message will be created when the next message is put if TriggerInterval has elapsed since the last trigger message was created for the queue.

z/OS has a “backstop” process to scan queues.

********************Example for Channel Trigger*********************

Define the local queue (QM1) & channel (QM3.TO.QM4):

DEFINE QLOCAL(QM4) TRIGGER INITQ(SYSTEM.CHANNEL.INITQ) PROCESS(P1) USAGE(XMITQ)

Define the application (process P1) to be started:

DEFINE PROCESS(P1) USERDATA(QM3.TO.QM4)

Alternatively, for WebSphere MQ for UNIX, Linux and Windows systems, you can eliminate the need for a process definition by specifying the channel name in the TRIGDATA attribute of the transmission queue.

Define the local queue (QM4). Specify that trigger messages are to be written to the default initiation queue SYSTEM.CHANNEL.INITQ, to trigger the application (process P1) that starts channel (QM3.TO.QM4):

DEFINE QLOCAL(QM4) TRIGGER INITQ(SYSTEM.CHANNEL.INITQ) USAGE(XMITQ) TRIGDATA(QM3.TO.QM4)

***************Example for Application Trigger********************

Trigger process:

define process(ATKPROCESS) APPLTYPE(UNIX) APPLICID(/opt/app_scripts/MQM/testtrigger.sh)

Trigger Service:

define service(ATKSERVICE) STARTCMD(/opt/mqm/bin/runmqtrm) SERVTYPE(SERVER) STARTARG(-m MQ_QMGR -q INIQ)

Initiation Queue:

define ql(INIQ)

Local Queue:

define ql(APP_Q) INITQ(INIQ) TRIGGER TRIGTYPE(DEPTH) TRIGDPTH(25) PROCESS(ATKPROCESS)

Example “testtrigger.sh”: /opt/mqm/bin/runmqsc MQ_QMGR</opt/app_scripts/MQM/Disable_MQ_Q.txt

Diable_MQ_Q.txt contents:

ALTER QLOCAL(‘APP_Q') PUT(DISABLED) ALTER QLOCAL(‘TESTQ1') PUT(DISABLED) ALTER QLOCAL(‘TestQ2') PUT(DISABLED) ALTER QLOCAL(‘TestQ3') PUT(DISABLED)

**********Trigger conditions*************

A trigger message is sent to the initiation queue when all of the following conditions are satisfied:

1. A message is put on a transmission or local queue.

2. The message’s priority is greater than or equal to the TriggerMsgPriority of the queue.

3. The number of messages on queue was previously - Zero for trigger type FIRST - Any number for trigger type EVERY or *ALL - TriggerDepth minus 1 for trigger type DEPTH

4. For trigger type FIRST or DEPTH, no program has the trigger queue open for GETs (Open input count=0).

5. The Get enabled attribute is set to YES on the triggered queue.

6. A Process name is specified and exists, or for transmission queues, TriggerData contains the name of a channel. 

7. An Initiation queue is specified and exists and GETs and PUTs are enabled for the initiation queue. 

8. The trigger monitor has been started and has the initiation queue open for GETs

9. The TriggerControl attribute is set to YES on the triggered queue.

10. The TriggerType attribute is not set to NONE.

11. For Trigger Type FIRST, the queue was not previously empty, but the TriggerInterval set for the QMGR has elapsed.

12. The only application serving the queue issues MQCLOSE and there are still messages on the queue that satisfy Conditions 2 and 6-10.

13. Certain trigger attributes of the triggered queue are changed, such as - NOTRIGGER to TRIGGER - PUT or GET DISABLED to ENABLED or a trigger monitor opens the Initiation queue.

14. MSGDLVSQ is set correctly relative to the priority of the messages and the TriggerMsgPriority setting.