+

Search Tips | Advanced Search

Starting IBM MQ applications using triggers

Learn about triggers and how to start IBM MQ applications using triggers.

Some IBM MQ applications that serve queues run continuously, so they are always available to retrieve messages that arrive on the queues. However, you might not want this when the number of messages arriving on the queues is unpredictable. In this case, applications could be consuming system resources even when there are no messages to retrieve.

IBM MQ provides a facility that enables an application to be started automatically when there are messages available to retrieve. This facility is known as triggering.

For information about triggering channels see Triggering channels.


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 reduces logging (resulting in improving performance), and minimizing duplicates during restart, so improving restart time.

The program that 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. Typically this action is to start some other application to process the queue that generated the trigger message. 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, we can create a process-definition object associated with it. This object contains information about the application that processes the message that 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.

If you want to trigger the start of a channel, we do not need to define a process definition object. The transmission queue definition is used instead.

Triggering is supported by IBM MQ clients running on UNIX, Linux , and Windows. An application running in a client environment is the same as one running in a full IBM 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:

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

Figure 1. Flow of application and trigger messages

In Figure 1, the sequence of events is:
  1. Application A, which can be either local or remote to the queue manager, puts a message on the application queue. No application has this queue open for input. However, this fact is relevant only to trigger type FIRST and DEPTH.
  2. 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.
  3. 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.
  4. The trigger monitor retrieves the trigger message from the initiation queue.
  5. The trigger monitor issues a command to start application B (the server application).
  6. Application B opens the application queue and retrieves the message.
Note:
  1. If the application queue is open for input, by any program, and has triggering set for FIRST or DEPTH, no trigger event occurs because the queue is already being served.
  2. If the initiation queue is not open for input, the queue manager does not generate any trigger messages; it waits until an application opens the initiation queue for input.
  3. When using triggering for channels, use trigger type FIRST or DEPTH.
  4. Triggered applications run under the user ID and group of the user who started the trigger monitor, the CICS® user, or the user who started the queue manager.

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

Figure 2. Relationship of queues within triggering

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, if you want to trigger the start of a channel, we do not need to define a process definition object. The transmission queue definition can determine the channel to be triggered.

Use the following links to find out more about starting IBM MQ applications using triggers: