| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Dynamic JMS message selector in JMSInput node |
« View previous topic :: View next topic » |
| Author |
Message
|
| nize |
 Posted: Thu May 06, 2010 11:50 am Post subject: Dynamic JMS message selector in JMSInput node |
 |
|
Voyager
Joined: 02 Sep 2009
Posts: 90
|
Hi,
Is it possible to configure the "JMS message selector" field of a JMSInput node dynamically? In other words: Can I change it without redeploying the flow?
What I really would like is to create a WMB flow which reads from one queue and routes to a number of queues depending on the combinations of parameter values in the MQRFH2.urs header (i.e. the JMS application specific properties header). But I would like to be able to configure these rules dynamically, and totally flexible (i.e. for any SQL logic combining any parameters and any values) by sending SQL statements without needing to redeploy the routing flow.
I have complex (but cool) database implementation of this flexible functionality today, but I would like to make it simpler (and less cool).
Any ideas? |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Sun May 23, 2010 9:19 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Do a JMS to MQ flow. You can then pick up the messages with an MQGET node and look for correlationId as mandated by the flow...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Esa |
| Posted: Mon May 24, 2010 5:36 am Post subject: Re: Dynamic JMS message selector in JMSInput node |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| nize wrote: |
What I really would like is to create a WMB flow which reads from one queue and routes to a number of queues depending on the combinations of parameter values in the MQRFH2.urs header (i.e. the JMS application specific properties header). But I would like to be able to configure these rules dynamically, and totally flexible (i.e. for any SQL logic combining any parameters and any values) by sending SQL statements without needing to redeploy the routing flow.
|
Selectors are used when you have several applications listening to one input queue. The point is that applications only get messages that match their selector and leave other messages to other applications to consume.
Maybe some day in near future Message Broker will support MQ 7 shared browse cursors and message tokens. Then it will be possible to implement that kind of functionality. But with JMS selectors, no. If you study MQ 7 MQI API jan JMS API, you will find out that selectors are applied when the application OPENs the input queue, not when it GETs a message. So that kind of dynamic selector functionality would require MB to close and reopen the input queue after each message. Easy to do in a J2EE application, but not with MB. MB execution groups actually cache open queue handles, so it issues an MQOPEN only when the flows starts. That is one of the techniques that enable MB to outperform application server based approaches.
Yes, there is an API called Configuration Manager Proxy that you could use to start and stop your message flow. But i would strongly discourage you of event trying it. Even if you managed to solve the problems caused by backouts and queue handle cache, you would still always be one step behind after you have changed your filter: the first message after filter change would be read using the previous filter.
But do not worry, what you actually need to implement is a simple router flow that reads messages from the input queue and applies dynamic rules from the database to route messages to various target queues. It is actually a very basic task. You can implement it with compute nodes or java compute nodes. Using routing to labels or an MQOutput node in destination list mode can make your flow even more dynamic. |
|
| Back to top |
|
|
| Esa |
| Posted: Mon May 24, 2010 5:56 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
Sorry, now that I read you post once more I understood that it is actually the database you want to get rid of. You can do it the way fjb_saper suggested, using an MQ queue as a rules repository and reading the configuration messages with MQGET, probably caching the information for some minutes with an ESQL SHARED or a java static variable. Your will have to use MQGET in browse mode and figure out some way to take care of the versioning problem. The old configuration messages will remain first in the queue when you send new ones. A flow that removes old versions from the config queue before adding a new one, for example.
But it still has nothing to do with JMS selectors. |
|
| Back to top |
|
|
| nize |
| Posted: Mon May 24, 2010 10:41 pm Post subject: |
|
|
Voyager
Joined: 02 Sep 2009
Posts: 90
|
Thanks for your posts. I realize that my question was somewhat vague.
What I wanted was to implement a routing function routing based on the application specific properties of the messages (i.e. the MQRFH2.usr parameters). That is easy, but the thing is that I would like it to be completely dynamic and flexible so that I configure a structured data source (such as a DB or something else) with SQL strings such as
par1>value2 AND par5=value9
for each output alternative.
In this way I would be able to use the same WMB flow for all content-based routing without any redeployment.
I have such implementation today, but what I was looking for was to simplify it by just giving the InputNode of the flow a selector (such the condition above) as you would be able to using the JMS API.
Esa, your first reply was interesting! You got my intention.
Ill drop my attempt to simplify the current solution. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
