MQ Trigger (IBM Websphere MQ)

hi dqmq,

Will this work if I am creating say 10 dynamic queues using the model queue. How does the trigger know when to fire and for which queue? I appriciate your help.

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.




 

Thanks for such an elaborate answer. I thought if I could give you the exact scenario then it might set things straight and you could let me know if the approach we are taking is or is not a right one.

Before I go any further, we are working in windows environment (windows server 2003)

Incoming message scenario:
At any given time MQ could receive close to tens of thousands of messages. Each message is from a unique customer (each customer is identified by unique id). We are planning have multiple local queues to handle the incoming messages. These messages are pushed to the business tier for further processing. This operation is pretty straight forward.

Outgoing message scenario: (This is where we need an answer)
In our solution we automatically connect to our customer to process his request. As I said each customer is identified by their unique id. What we intend to do is to create a dynamic queue for each customer. Part of dynamic queue name will have the customer id. (note; outgoing messages will not be as many as incoming). So as an example, we might create a thousand dynamic queues. Once a message arrives in this dynamic queue we need a trigger that will start a process. This process will get the customer id from the dynamic queue name and connect with the customer to complete the process. Is this an healthy approach? Do you have any suggestion? Let me know if you didn't follow any of this info.

Thanks!

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.




 

Answers to your questions are as follows:

1. Do you intend to use permanent dynamic queues or temporary dynamic queues?
A. Yes we intend to use permanent dynamic queue. We thought of using temporary dynamic queue but messages might come into the queue at different intervals. So this makes us to think about your suggestion of using XMITQ.

2. At what point in the process do you create the dynamic queue?
A. They are created when we want to send out a response to the customer's request. The actual process is asynchronous. First, customer would send a request. This request would have the name of the dynamic queue to be created. Once the request is received the customer is no longer in the picture. The mid-tier process the request (using DB and other services). Once the response is generated, one mid-tier process calls the customer to come and get the response and the other process creates the dynamic queue and posts the response. Customer would come and read the response in the corresponding dynamic queue. (This is the intended solution)

3. Describe briefly what you mean by "automatically connect"?  Is that a scheduled event or is it driven by something else?
A It is driven by a mid-tier component.

4. How much time between automatically connecting to pickup messages and connecting to send back the replies?

A. This depends on the customer. If the customer is busy then the process would wait and retry until the customer is free.

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?

A. There could be multiple requests from a single customer at the same time. But the requests are different between customers.

Hope this gives you a good understanding of the process. We need to do more research on XMITQ. Sounds like a good suggestion. I would appreciate if you could explain XMITQ process in more detail. How different is this than the standard local queue? Will there be 'n' number of XMITQ's each representing a customer?

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.

Customers/Clients use our webservices to send updates and requests. Webservices inturn connect to our local Q Mgr and PUTs message. Updates/requests come in at regular intervals. These requests are then pushed to the middle tier. Here we identify the customer and we intend to create a dynamic queue for that customer and PUT our response on the queue (after the response is generated, this is were the process I mentioned in my previous comment would send a request to the customer (with queue name) to collect the response and also PUTs the response in the dynamic queue created). Once the customer is ready to accept the response for the request, customer connects to the webservice and passes the queue name. Webservice knows which queue to find and gets the response back to the customer. Communication is always going to be through our local Q Mgr.