|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
MQGet, configurable input queue |
« View previous topic :: View next topic » |
Author |
Message
|
lancelotlinc |
Posted: Wed Oct 17, 2012 11:17 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
geewee wrote: |
Unfortunately, the product does not support setting queue name runtime. You stated that yourself.
only compile time and deploy time.
No good reason for not allowing this runtime.
Maybe in next release. |
Your understanding of the basic fundamentals of the WMB product are at the beginner stage. Once you gain more experience with the product, your understanding will improve.
MKB gave you the answer: put more than one MQInput node in your flow. Of course, this implies that the data coming into both queues has the same format. _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
 |
geewee |
Posted: Wed Oct 17, 2012 12:45 pm Post subject: |
|
|
Apprentice
Joined: 31 Jul 2012 Posts: 28
|

Last edited by geewee on Thu Oct 18, 2012 1:03 am; edited 2 times in total |
|
Back to top |
|
 |
mqjeff |
Posted: Wed Oct 17, 2012 12:53 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
geewee wrote: |
It would be wonderful to have the input queue name configurable, not set compile time, not set deploy time, but actually read as a configurable property runtime. |
No, not really.
It would lead to a lot of problems, which is why the design team has not enabled this function.
Your specific example quoted above is best handled either with a PATTERN that gets instantiated into MANY flows each with specific queue names configured, or with a *single* flow that reads from *one* queue.
Just because you have flows that write out to "error1" and "error2" doesn't mean that "error1" and "error2" have to be *different* queues. it's very very easy to configure MQ to consider many different names as the same actual local queue.
One big advantage of using *many* flows for this is that you can TRACK the usage of each flow individually. So if you have different CUSTOMERS that are using this, you can CHARGE them individually. |
|
Back to top |
|
 |
geewee |
Posted: Wed Oct 17, 2012 1:04 pm Post subject: |
|
|
Apprentice
Joined: 31 Jul 2012 Posts: 28
|
could you mention just briefly the problems if design team "enabled" this function?
Last edited by geewee on Thu Oct 18, 2012 1:02 am; edited 1 time in total |
|
Back to top |
|
 |
vmcgloin |
Posted: Thu Oct 18, 2012 12:43 am Post subject: |
|
|
Knight
Joined: 04 Apr 2002 Posts: 560 Location: Scotland
|
I don't endorse your design, I'd tackle improving your deployment scripts. They are after all there to deploy what the development team provides.
But... are you still having a problem configuring the MQGET node to read from the queue specified in your database? |
|
Back to top |
|
 |
rekarm01 |
Posted: Thu Oct 18, 2012 1:53 am Post subject: Re: MQGet, configurable input queue |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 1415
|
geewee wrote: |
runtime:
Code: |
SET InputLocalEnvironment.MQ.GET.QueueName = 'myQueue'; |
|
Shouldn't that be OutputLocalEnvironment?
geewee wrote: |
case closed |
Okay...
geewee wrote: |
could you mention just briefly the problems if design team "enabled" this function? |
Real briefly, Input nodes are different from other nodes. |
|
Back to top |
|
 |
|
|
|
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
|
|
|
|