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 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. Usually 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, you 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, you do not need to define a process definition object. The transmission queue definition is used instead.
Triggering is supported by WebSphere MQ clients running in the following environments:
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:
Remember that if you want a trigger to start a channel, you do not need to define a process definition object.
For a transmission queue on AIX(R), HP-UX, i5/OS, Solaris, i5/OS 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.
On all platforms, a special trigger monitor known as the channel initiator is responsible for starting channels. On z/OS(TM), 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 platforms, it is automatically started when the queue manager starts or it can be started manually with the runmqchi command.
(For more information, see Trigger monitors.)
To understand how triggering works, consider Figure 14, which is an example of trigger type FIRST (MQTT_FIRST).
In Figure 14, the sequence of events is:
So far, the relationship between the queues within triggering has been only on a one to one basis. Consider Figure 15.
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, you do not need to define a process definition object. The transmission queue definition can determine the channel to be triggered.
Notices |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
csq0342 |