MQ Trigger (IBM Websphere MQ)

It's a little bit of an odd request, but I don't see why it wouldn't work.  Setup the triggering-related parameters on the model queue (that you will open to instantiate the dynamic queue).  I doubt I can remember all of them off the top of my head, but you would certainly need to specify TRIGTYPE, an INITQ, and set TRIGGER ON.  You also need to define an INITQ and start a trigger monitor that listens for messages on the INITQ.

First, I have my docs now, so here's a little more specific:

Define QModel with:
TRIGGER
PROCESS=name of process  
USAGE=NORMAL
TRIGTYPE=FIRST  (99% of applications)
INITQ=name of initq

Define INITQ like any other QLocal
Define PROCESS to describe how to start  triggered application
Start trigger monitor against INITQ

Now, to followup questions:
>Will this work if I am creating say 10 dynamic queues using the model queue.
Yes, there is no limit.

>How does the trigger know when to fire and for which queue?
To get this working you need to COMPLETELY understand the list of trigger conditions that is described in the programmers guide.

When trigger conditions are satisified on a QUEUE, MQ's triggering mechanism places a trigger message in the INITQ that was inherited from the QMODEL definition.  The trigger message contains the name of the triggered QUEUE plus the APPLICID and other information from the PROCESS definition.

The trigger monitor which has a "hot-read" on the INITQ, then wakes up immediately and reads the trigger message.  It uses the information in the trigger message to start the triggered application, passing it the trigger message.

The triggered application can then extract the name of the QUEUE from the trigger message.

A couple words of caution:
A trigger message is associated with a queue, NOT a specific application message.  It means one thing, and one thing only: that trigger conditions for that queue were momentarily satisfied.  That implies: 1) the triggered application must be able to tolerate not finding any messages on the queue 2) the triggered application must process the queue until empty (casually referred to as "draining the queue").

Triggering works great and is pretty much maintenance free if it is used as intended and set up properly.  But trying to contort it into something it was not designed for, while sometimes appealing, is a common pitfall and usually leads to much agony and hatred for triggering itself.  Triggering is not the problem; misuse is.

Eventually, it's more than likely that you will want the trigger monitor and the triggered application to run in background. In other words, without a console or other status display. Therefore, it must have robust error handling and ways to communicate errors when they occur.  Plan for that.

Get triggering working on a permanent queue first, then switch over to dynamic queue.

Get the process working with the trigger monitor and the triggered application running in foreground so you can "see" what is happening.  Switch them into background only after you are comfortable with how everything works.

Apply the KISS prinicple religiously. Increase complexity and sophistication gradually as you are more comfortable with the mechanics of triggering.

Avoid TRIGTYPE=EVERY. Anything that can be done with EVERY can be done better and easier another way.  Remember what a trigger message means:  that trigger conditions for that queue were momentarily satisfied. Why would you care to know that more than once at the same time?

Finally, triggering implementations vary slightly for each platform/environment.  If you have a followup question, please imention the environment you are using.




 

My first reaction is that the dynamic queues and the triggers are additional overhead and unnecessary complexity. I will elaborate further when I have a little more time.  But in the meantime, a couple of questions for you:

1. Do you intend to use permanent dynamic queues or temporary dynamic queues?
2. At what point in the process do you create the dynamic queue?
3. Describe briefly what you mean by "automatically connect"?  Is that a scheduled event or is it driven by something else?
4. How much time between automatically connecting to pickup messages and connecting to send back the replies?
5. Are the tens of thousands of messages related to one another (other than they came from the same customer) or does each one represent a "standalone" request.  I mean do you need to collect multiple messages to process one request or does each message represent a request by itself?

To get messages back you will ordinarily need an XMITQ for each customer.  So, you tell me, what is the point of writing responses to a dynamic queue, then triggering an application to immediately move them to the XMITQ?

The usual method is simply to send the responses back to REPLYTOQUEUE and REPLYTOQMGR which are provided by the originator of the request.  Administratively, either by XMITQ naming convention or by use of qmgr alias, those messages end up in the XMITQ destined for the right customer.  The XMITQ can be triggered so it will automatically startup the channel and begin shipping responses as soon as they appear. NO need for a dynamic queue and no need for a triggered application to process it.




 

Whenever I hear someone planning to use permanent dynamic queues, I get suspicious. Legitimate uses for them are rare.  I also do not like the idea, nor see any good reason for the customer to send the name of the dynamic queue for you to create.   If anything, the customer creates the dynamic queue then sends you the name so you know where to send the reply. It does no good for you to create the dynamic queue on your end because the customer cannot retrieve messages from there.

By "customer", I'm referring to a distributed queing partner.  It occurs to me that before I go off on too much of a rant, that you should clarify what you mean by a "customer".   Do your customers connect locally to your qmgr,  do they have channel connections, or are your customers connecting as MQ Clients?  Does each customer have a unique qmgr or is each customer a different user on the same qmgr?

Any two qmgrs exchange messages over channel pairs.   An XMITQ is the local queue that feeds an outbound channel.  Whenever you put a message to a remote destination, it gets queued locally first in an XMITQ.  Your qmgr MUST have an XMITQ for every adjacent qmgr it connects with.