What is triggering?

The queue manager defines certain conditions as constituting trigger events. If triggering is enabled for a queue and a trigger event occurs, the queue manager sends a trigger message to a queue called an initiation queue. The presence of the trigger message on the initiation queue indicates that a trigger event has occurred.

Trigger messages generated by the queue manager are not persistent. This has the effect of reducing logging (thereby improving performance), and minimizing duplicates during restart, so improving restart time.

The program which processes the initiation queue is called a trigger-monitor application, and its function is to read the trigger message and take appropriate action, based on the information contained in the trigger message. Normally this action would be to start some other application to process the queue which caused the trigger message to be generated. From the point of view of the queue manager, there is nothing special about the trigger-monitor application--it is simply another application that reads messages from a queue (the initiation queue).

If triggering is enabled for a queue, you have the option to create a process-definition object associated with it. This object contains information about the application that processes the message which caused the trigger event. If the process definition object is created, the queue manager extracts this information and places it in the trigger message, for use by the trigger-monitor application. The name of the process definition associated with a queue is given by the ProcessName local-queue attribute. Each queue can specify a different process definition, or several queues can share the same process definition.

For all MQSeries or WebSphere MQ Version 5 products, if you want to trigger the start of a channel, you do not need to define a process definition object. The transmission queue definition is used instead.

On MQSeries for VSE/ESA, a trigger event is defined to activate the WebSphere MQ trigger API Handler, that is, the MQ02 CICS Transaction. The trigger API handler executes a CICS LINK to the application program or a CICS START to the application transaction depending on whether you defined a program name or a transaction name in the queue definition. For more information, see MQSeries for VSE/ESA System Management Guide.

Triggering is supported by WebSphere MQ Clients running in the following environments:

Compaq OpenVMS Alpha

OS/2

UNIX systems

Windows systems

An application running in a client environment is the same as one running in a full WebSphere MQ environment, except that you link it with the client libraries. However the trigger monitor and the application to be started must both be in the same environment.

Triggering involves:

Application queue

An application queue is a local queue, which, when it has triggering set on and when the conditions are met, requires that trigger messages are written.

Process Definition

An application queue can have a process definition object associated with it that holds details of the application that will get messages from the application queue. (See WebSphere MQ Application Programming Reference for a list of attributes.)

Remember that if you want a trigger to start a channel, you do not need to define a process definition object.

Transmission queue

You need a transmission queue if you want a trigger to start a channel.

For a transmission queue on AIX, HP-UX, OS/2 Warp, OS/400, Solaris, Compaq Tru64 UNIX, z/OS, or Windows systems, the TriggerData attribute of the transmission queue can specify the name of the channel to be started. This can replace the process definition for triggering channels, but is used only when a process definition is not created.

Trigger event

A trigger event is an event that causes a trigger message to be generated by the queue manager. This is usually a message arriving on an application queue, but it can also occur at other times (see Conditions for a trigger event). WebSphere MQ has a range of options to allow you to control the conditions that cause a trigger event (see Controlling trigger events).

Trigger message

The queue manager creates a trigger message when it recognizes a trigger event (see Conditions for a trigger event). It copies into the trigger message information about the application to be started. This information comes from the application queue and the process definition object associated with the application queue. Trigger messages have a fixed format (see Format of trigger messages).

Initiation queue

An initiation queue is a local queue on which the queue manager puts trigger messages. A queue manager can own more than one initiation queue, and each one is associated with one or more application queues. A shared queue, a local queue accessible by queue managers in a queue-sharing group, can be an initiation queue on WebSphere MQ for z/OS.

Trigger monitor

A trigger monitor is a continuously-running program that serves one or more initiation queues. When a trigger message arrives on an initiation queue, the trigger monitor retrieves the message. The trigger monitor uses the information in the trigger message. It issues a command to start the application that is to retrieve the messages arriving on the application queue, passing it information contained in the trigger message header, which includes the name of the application queue.

On all platforms, a special trigger monitor known as the channel initiator is responsible for starting channels. On z/OS, the channel initiator is usually started manually, or it can be done automatically when a queue manager starts by changing CSQINP2 in the queue manager startup JCL. On other Version 5 platforms, it is automatically started when the queue manager starts or it can be started manually with the runmqchi command.

Note:: You must issue the runmqchi command to start the trigger monitor on MQSeries Version 2 products.

(For more information, see Trigger monitors.)

To understand how triggering works, consider Figure 14, which is an example of trigger type FIRST (MQTT_FIRST).

Figure 14. Flow of application and trigger messages

The figure is a diagram showing a configuration of WebSphere MQ objects and applications, and a sequence of events. The configuration shows: A queue manager managing an application queue and an initiation queue. The application queue has an associated process definition object. Three applications, as follows: Application A which can be on a remote system or local to the queue manager. Application B local to the queue manager. Trigger monitor running local to the queue manager. The sequence of events is described in the text following the figure.

In Figure 14, the sequence of events is:

Application A, which can be either local or remote to the queue manager, puts a message on the application queue. Note that no application has this queue open for input. However, this fact is relevant only to trigger type FIRST and DEPTH.
The queue manager checks to see if the conditions are met under which it has to generate a trigger event. They are, and a trigger event is generated. Information held within the associated process definition object is used when creating the trigger message.
The queue manager creates a trigger message and puts it on the initiation queue associated with this application queue, but only if an application (trigger monitor) has the initiation queue open for input.
The trigger monitor retrieves the trigger message from the initiation queue.
The trigger monitor issues a command to start application B (the server application).
Application B opens the application queue and retrieves the message.

Notes:

If the application queue is open for input, by any program, and has triggering set for FIRST or DEPTH, no trigger event will occur since the queue is already being served.
If the initiation queue is not open for input, the queue manager will not generate any trigger messages, it will wait until an application opens the initiation queue for input.
When using triggering for channels, you are recommended to use trigger type FIRST or DEPTH.

So far, the relationship between the queues within triggering has been only on a one to one basis. Consider Figure 15.

Figure 15. Relationship of queues within triggering

This figure shows a more complex configuration of objects and applications. The configuration is as follows: A queue manager managing Two application queues with associated process definition objects, called application queue 1 and 2 and process definition object 1 and 2. An initiation queue. Two sets of applications which can be remote or local to the queue manager. The applications are identified as Applications A, B, and C; and Apllications X, and Y. A trigger monitor application running local to the queue manager. Two applications started by triggering running local to the queue manager, identified as Applications K, and L.

An application queue has a process definition object associated with it that holds details of the application that will process the message. The queue manager places the information in the trigger message, so only one initiation queue is necessary. The trigger monitor extracts this information from the trigger message and starts the relevant application to deal with the message on each application queue.

Remember that for all MQSeries or WebSphere MQ Version 5 products, if you want to trigger the start of a channel, you do not need to define a process definition object. The transmission queue definition can determine the channel to be triggered.