You control trigger events using some of the attributes that define your application queue. You can enable and disable triggering, and you can select the number or priority of the messages that count toward a trigger event. There is a full description of these attributes in WebSphere MQ Application Programming Reference.
The relevant attributes are:
| EVERY | A trigger event occurs every time a message arrives on the application queue. Use this type of trigger if you want a serving program to process only one message, then end. | ||
| FIRST | A trigger event occurs only when the number of messages on the application queue changes from zero to one. Use this type of trigger if you want a serving program to start when the first message arrives on a queue, continue until there are no more messages to process, then end. Also see Special case of trigger type FIRST. | ||
| DEPTH | A trigger event occurs only when the number of messages on the
application queue reaches the value of the TriggerDepth
attribute. A typical use of this type of triggering is for starting a
program when all the replies to a set of requests are received.
The action of disabling triggering is not under syncpoint control, so triggering cannot be reenabled simply by backing out a unit of work. If a program backs out a put request that caused a trigger event, or if the program abends, you must reenable triggering by using the MQSET call or the ALTER QLOCAL command. |
The conditions that must be satisfied for a queue manager to create a trigger message are described in Conditions for a trigger event.
Consider an application that generates requests for motor insurance. The application might send request messages to a number of insurance companies, specifying the same reply-to queue each time. It could set a trigger of type EVERY on this reply-to queue so that each time a reply arrives, the reply could trigger an instance of the server to process the reply.
Consider an organization with a number of branch offices that each transmit details of the day's business to the head office. They all do this at the same time, at the end of the working day, and at the head office there is an application that processes the details from all the branch offices. The first message to arrive at the head office could cause a trigger event which starts this application. This application would continue processing until there are no more messages on its queue.
Consider a travel agency application that creates a single request to confirm a flight reservation, to confirm a reservation for a hotel room, to rent a car, and to order some travelers' checks. The application could separate these items into four request messages, sending each to a separate destination. It could set a trigger of type DEPTH on its reply-to queue (with the depth set to the value 4), so that it is restarted only when all four replies have arrived.
If another message (possibly from a different request) arrives on the reply-to queue before the last of the four replies, the requesting application is triggered early. To avoid this, when DEPTH triggering is being used to collect multiple replies to a request, you should always use a new reply-to queue for each request.
With trigger type FIRST, if there is already a message on the application queue when another message arrives, the queue manager does not usually create another trigger message. However, the application serving the queue might not actually open the queue (for example, the application might end, possibly because of a system problem). If an incorrect application name has been put into the process definition object, the application serving the queue will not pick up any of the messages. In these situations, if another message arrives on the application queue, there is no server running to process this message (and any other messages on the queue).
To deal with this, the queue manager creates another trigger message if another message arrives on the application queue, but only if a predefined time interval has elapsed since the queue manager created the last trigger message for that queue. This time interval is defined in the queue manager attribute TriggerInterval. Its default value is 999 999 999 milliseconds.
You should consider the following points when deciding on a value for the trigger interval to be used in your application: