| Author |
Message
|
| Y75 |
 Posted: Tue Aug 27, 2013 12:20 pm Post subject: Multiple type messages on same queue |
 |
|
Apprentice
Joined: 29 Jul 2013
Posts: 32
|
I have multiple (undetermined) type of messages arriving on a queue. What is the best way to recognize a message without looking at its contents?
I can use a message property. Is MsgType or Format fields in MQMD good candidates? What is usually used for this type of requirement?
I am new to MQ. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Aug 27, 2013 12:25 pm Post subject: Re: Multiple type messages on same queue |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Y75 wrote: |
| I have multiple (undetermined) type of messages arriving on a queue. What is the best way to recognize a message without looking at its contents? |
You've posted this in a message broker section. If this is because you're using message broker, what's the problem with looking at the contents? If you're not, do you want this moved to a WMQ section to prevent further confusion?
| Y75 wrote: |
| I can use a message property. Is MsgType or Format fields in MQMD good candidates? What is usually used for this type of requirement? |
Message properties are usually used for this. MsgType and Format are not only not good candiates for this (as they can be used internally by the WMQ software) they're not message properties but fields in the MQMD header.
Also - local queues are cheap. If you really have distinct messages as opposed to messages which are just sub-classes of each other, seriously consider having them sent to separate, dedicated queues and working out message type from the queue that they're on. Much easier & cleaner.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Aug 27, 2013 12:43 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
In the old days, people would use the NameValueData part of an MQRFH2 header to set the MRM 'fab four' properties : domain, set, type and format. These days, I guess the same thing could be achieved using MQ message properties.
But I agree with Vitor : queues are cheap. Do you really need to do this?
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too. |
|
| Back to top |
|
|
| Y75 |
| Posted: Tue Aug 27, 2013 12:44 pm Post subject: |
|
|
Apprentice
Joined: 29 Jul 2013
Posts: 32
|
Thanks for the reply!
I am using Message broker.
There is no problem in looking at message contents from feasibility point of view, just the nature of product I am building prevents me from doing so and also, I want to avoid parsing.
I agree using separate queue's is a much cleaner solution and seemingly a best practice ,datatype channel pattern, but one MQInput node can't listen to multiple queue's. I can't have a mutiple MQInput nodes as there can be lots of types of messages. If I could have multiple queue I can control queue depth and other properties based on type of message. Wish I could do that. |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Aug 27, 2013 1:48 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| I can't have a mutiple MQInput nodes as there can be lots of types of messages |
The usual solutions to this are:
- have lots of separate flows
- allow some flows to have multiple input nodes
- keep the number of flows to a reasonable number by creating flexible models that can parse N different variants of a data format.
I guess you probably thought of those solutions already, but hopefully this will provoke you into revealing why you need a single, generic gateway flow.
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Aug 28, 2013 1:49 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Y75 wrote: |
Thanks for the reply!
I am using Message broker.
There is no problem in looking at message contents from feasibility point of view, just the nature of product I am building prevents me from doing so and also, I want to avoid parsing.
I agree using separate queue's is a much cleaner solution and seemingly a best practice ,datatype channel pattern, but one MQInput node can't listen to multiple queue's. I can't have a mutiple MQInput nodes as there can be lots of types of messages. If I could have multiple queue I can control queue depth and other properties based on type of message. Wish I could do that. |
The question is, what can you do to ensure the sending applications always do "the right thing" to specify the type of message? If the answer is "nothing", then you have to assume you have to parse the message at least a little bit. If you can do "something", then the easiest thing to do is have the sending application use different queues.
The second question is, what do you do with the message once you figure out what "type" of message it is?
Do you immediately turn around and post it to a separate queue?
Or do you see if you have existing logic to handle it, and then process it in the same or slightly different thread?
Again, this may lead you to using more than one queue. |
|
| Back to top |
|
|
| Y75 |
| Posted: Wed Aug 28, 2013 8:35 am Post subject: |
|
|
Apprentice
Joined: 29 Jul 2013
Posts: 32
|
While building this solution, I am assuming I can control sending applications to post message to different queue's and also ask them to set properties i wish. Its more about how my gateway like flow can handle different undetermined queue's.
I am guessing when solution gets customized and deployed at client site, they may want to have different queue's for different messages or some combination of what kimbert suggests.
| Code: |
The usual solutions to this are:
- have lots of separate flows
- allow some flows to have multiple input nodes
- keep the number of flows to a reasonable number by creating flexible models that can parse N different variants of a data format.
|
Probably I should built all of my flow as subflow and let clients put in input nodes in a new message flow that includes my subflow if they desire. I can ship the solution with one message flow with one input node. Haven't thought this through yet.
| Code: |
The second question is, what do you do with the message once you figure out what "type" of message it is?
|
I read "processing profile" for a function and figure out what systems to call and what transformations to run and call them. That's all I can tell. [/code] |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 28, 2013 8:50 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Y75 wrote: |
| While building this solution, I am assuming I can control sending applications to post message to different queue's and also ask them to set properties i wish. |
The abilty to control application developers is a heck of an assumption... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
