| Author |
Message
|
| WMD |
 Posted: Wed Dec 23, 2015 8:07 am Post subject: Same WMB message flow to read from Multiple Input Queues |
 |
|
Novice
Joined: 26 Mar 2013
Posts: 12
|
Friends,
I am looking for a solution/options in Websphere Message Broker v8.x to develop a generic message flow that can read from multiple different Input Queues to perform the function based on SOURCE Queue attribute.
I thought of using ALIAS of multiple source queue pointing to same TARGET queue which MQInput node in the flow can read but am losing the SOURCE queue information which is mandatory for me to apply some business logic based on this field.
I understand that for any new queue introduction, change/update is inevitable. But my thought is avoid the code changes/BAR deployment every instead DB or other configuration change is more generic and flexible.
Kindly share your suggestions on this.
Thanks. |
|
| Back to top |
|
 |
| zpat |
| Posted: Wed Dec 23, 2015 8:22 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
How would you perform new function on a new queue without a code deployment?
You could use a subflow to hold common function.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 23, 2015 8:23 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Why are these messages being differentiated by being delivered to different queues? Why not (for example) work out what function to perform based on message or header content? What drove the use of queues?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| WMD |
| Posted: Wed Dec 23, 2015 9:06 am Post subject: |
|
|
Novice
Joined: 26 Mar 2013
Posts: 12
|
Thanks for your response.
@ zpat:
How would you perform new function on a new queue without a code deployment?
Code change is unavoidable for new function.
But I am trying to avoid the code change/deployment only for the new queue scenario (for already existing function/business logic).
@ Vitor:
Why are these messages being differentiated by being delivered to different queues?
These message are delivered from different systems, partners and applications onto my Gateway layer and they do have their own queue to connect to my Gateway.
Function shall also be performed by Message/Header content but not all application comply to send header and also I dont want to parse the message in my Gateway layer. I want to identify the message type based on the SOURCE queue which is unique across all sub-systems that connect to my Gateway.
Thanks. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 23, 2015 9:32 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| WMD wrote: |
| not all application comply to send header |
Tell me how these applications avoid adding an MQMD to an MQ message.
| WMD wrote: |
| I dont want to parse the message in my Gateway layer. |
Because WMBv8 is so bad at parsing messages? What's wrong with on-demand parsing and/or looking at the MQMD?
| WMD wrote: |
| I want to identify the message type based on the SOURCE queue which is unique across all sub-systems that connect to my Gateway. |
So you don't mind parsing the Properties sub tree?
If you want to achieve this, you need a real local queue with a real MQInput node for each queue. The Source attribute in the message tree refers to the queue the message was read from, not any alias that might have been used to put the message.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| WMD |
| Posted: Wed Dec 23, 2015 9:48 am Post subject: |
|
|
Novice
Joined: 26 Mar 2013
Posts: 12
|
I misunderstood as a custom header message.
Yes, MQMD header is available.
Can you please eloborate which field to use auto-detect the source channel type.
I meant not to parse the payload of the message in the gateway.
Thanks. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 23, 2015 9:57 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| WMD wrote: |
Can you please eloborate which field to use auto-detect the source channel type.
|
There are any number - the PutApplName field is an obvious one. You might also want to want to consider the ApplOriginData as a way of determining the origin of the data.
If your customers can't or won't supply origin data, and the application names are not unique, then consider a flow that reads from their queue, adds the origin data and then puts it to the queue the flow reads from. Anyone who can add origin data just puts through the alias.
| WMD wrote: |
| I meant not to parse the payload of the message in the gateway |
I still don't see why this is a problem.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Dec 23, 2015 10:20 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
So it seems obvious, have multiple input nodes with different queues - one for each unique function.
When function is identical - use the same queue (or create an alias to the same queue).
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| whiting |
| Posted: Wed Dec 23, 2015 10:22 am Post subject: |
|
|
Acolyte
Joined: 26 Mar 2002
Posts: 64
Location: Greenville, SC
|
Is there a reason not to use RFH2 header?
You could use the messagetype field to distinguish messages.
Another option is to use the messagetype field of the MQMD. Use a value greater than 8 (Datagram) to indicate message type/content. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 23, 2015 10:56 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| whiting wrote: |
| Is there a reason not to use RFH2 header? |
If the customers won't set ApplOriginData in the MQMD, they're unlikely to add an RFH2 to the message. If they will add an RFH2 then this is a very good option.
| whiting wrote: |
You could use the messagetype field to distinguish messages.
Another option is to use the messagetype field of the MQMD. Use a value greater than 8 (Datagram) to indicate message type/content. |
I'm really unconvinced that using an unexpected (user) value in the type field is a good idea. Certainly not the first idea I'd explore. ApplOriginData or an RFH2 (which are of course message properties in the new world).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| WMD |
| Posted: Wed Dec 23, 2015 11:08 am Post subject: |
|
|
Novice
Joined: 26 Mar 2013
Posts: 12
|
I agree RFH2 header and Application Identity attributes on MQMD is all feasible to use and solves this purpose BUT the problem is enforcement.
I can't enforce ALL the involved subsystems suggest to set either RFH2 header or MQMD Application Identity properties.
I wish the gateway application that am building to be as much seamless as possible to connecting application.
Because of this reason, I am sticking to SOURCE QUEUE attribute on MQMD which is naturally unique (in this situation for me) to use as an identifier.
Please share your thoughts on this.
Thanks. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 23, 2015 12:15 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| WMD wrote: |
Because of this reason, I am sticking to SOURCE QUEUE attribute on MQMD which is naturally unique (in this situation for me) to use as an identifier.
Please share your thoughts on this. |
Then you need a queue for each customer and an MQInput node for each queue.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Dec 23, 2015 3:03 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Is this just a one way message or is this a request / reply scenario?
You could differentiate by the replyto queue and replyto queuemanager? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
