| Author |
Message
|
| darrylcook |
 Posted: Wed Jan 09, 2013 4:14 am Post subject: Queue Design - Generic or Process Based |
 |
|
Newbie
Joined: 19 Dec 2006
Posts: 6
|
Hi,
I would appreciate some advice on best practices around queue design. We have an Oracle client that will be posting 3 different types of messages to our customer system (Assets, Jobs, Exceptions). Oracle will PUT the messages to MQ - and a Z/OS (COBOL) application will consume them.
The COBOL program will simply consume the messages and write them to a DB2 holding table, so that they can be processed off in batch later (We do this as we are mainly a DB2 shop and this avoids having to train everyone in MQ).
Question is for MQ best practice:
Would I have 3 seperate queues (one for Assets, one for Jobs, one for Exceptions) - requiring 3 different processes to consume the messages and write to DB2 holding table.
Or would I have a single queue, with a single process consuming the messages and writing to the DB2 holding table.
Thanks for your help. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Jan 09, 2013 4:19 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I would tell the Oracle system that there are three separate queues, and create three separate queue aliases.
Then I would have the mainframe team design the program to use as many queues as they feel appropriate, and use the qaliases to resolve to the correct number.
There may, for example, be so many Asset messages that it makes sense to put it into it's own queue and be processed independently, but jobs and exceptions can share a queue, or etc.
By using QAliases, you have the option of altering the consuming side without altering the producing side at all. |
|
| Back to top |
|
|
| nathanw |
| Posted: Wed Jan 09, 2013 5:08 am Post subject: |
|
|
Knight
Joined: 14 Jul 2004
Posts: 550
|
throughput is an important factor as well as the content of the messages
are they the same structure and only content different or are the messages completely different.
can the cobol application differentiate between message types (if different) etc
the answer i suppose depends on the data itself i suppose
_________________
Who is General Failure and why is he reading my hard drive?
Artificial Intelligence stands no chance against Natural Stupidity.
Only the User Trace Speaks The Truth  |
|
| Back to top |
|
|
| happyj |
| Posted: Wed Jan 09, 2013 5:27 am Post subject: |
|
|
Voyager
Joined: 07 Feb 2005
Posts: 87
|
queues themselves use very few resources and I wouldn't restrict the number that you use unless your design leads to this.
is the data for each of these three types independent or is there a relationship between the data?
does the order that messages are processed matter? |
|
| Back to top |
|
|
| darrylcook |
| Posted: Wed Jan 09, 2013 5:43 am Post subject: |
|
|
Newbie
Joined: 19 Dec 2006
Posts: 6
|
Hi,
Thanks for your responses so far:
The 3 messages are completely independent and will all have different message structures.
I guess there is no real need to have all messages on a queue having the same structure - the COBOL application will differentiate by examining the content of the message string - i.e. first 10 bytes will identify the type of message.
Thanks
Darryl |
|
| Back to top |
|
|
| happyj |
| Posted: Wed Jan 09, 2013 5:51 am Post subject: |
|
|
Voyager
Joined: 07 Feb 2005
Posts: 87
|
it's worth thinking about how easy your design will be to change,
impact for support, monitoring etc
The naming of queues is also important and will help with the above. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jan 09, 2013 7:41 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
The nice thing about multiple queues in this design is that your monitoring tools can then report and alert on the individual queues. It is then much easier to get a granular view on throughput based on message type, if each message type has its own queue.
With seperate message types going to seperate queues, you give yourself more options on how and when to process different messages.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
