| Author |
Message
|
| afroz11031 |
 Posted: Tue Aug 26, 2014 9:42 pm Post subject: Suggestion on Parameterized value-Flow or DB level or other |
 |
|
Apprentice
Joined: 28 Jan 2014
Posts: 36
|
Hi,
I need a suggestion on a scenario where do we need to set the parameterized value E.g.
After invoking a service provider if service provider gives a timeout after getting timeout we are retrying 'n' times to service provider.
1. So if we set 'n' number of retry value on flow level as UDP then re-deployment is required.
2. So if we set 'n' number of retry value on database level then Broker start is required.
3. Other way if we create a java project which reads the config.properties(which has 'n' parameter value) and that java is called in compute node so in this case i believe no re-deploymet and no broker start are required.
Please suggest which approach is good and if other way please let me know.
Your suggestion will be appreciated!.
Cheers |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Tue Aug 26, 2014 10:30 pm Post subject: Re: Suggestion on Parameterized value-Flow or DB level or ot |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Are you intending to invoke your Java code and thus read the .properties file for every message? This is not very performant at all especially when the flow has to process lots of messages a second.
How about putting the values into a table and every so often reading them and updating the data that the flow uses?
You will need to store them in one or more shatred variables AND code into the flow a forced read if the variables are = 0 (or something similar)
Then all it takes for the flow to start using the new data is:-
1) a delay upto that of the frequency of the table reads
OR
2) a flow restart
Naturally it gets a bit more complicated when you have multiple instances of the flow and you have to use ATOMIC updates but I've used this many times and it works.
for example, I have just updated a system with some code that will allow the output data to be varied according to a value stored in the table. When the system that reads this 'extra' data is ready, I can update the the value in the table and restart the flow. If we have problems then it is easy to revert to a known working solution.
Other solutions are available.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| vicentius |
| Posted: Wed Aug 27, 2014 1:30 am Post subject: |
|
|
Apprentice
Joined: 01 Mar 2013
Posts: 28
|
| Add another "thread" in your flow design, handling command data that alters the shared variable used as retry count. Use MQInput or FileInput, for example, to read the new retry value. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Aug 27, 2014 1:48 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| vicentius wrote: |
| Add another "thread" in your flow design, handling command data that alters the shared variable used as retry count. Use MQInput or FileInput, for example, to read the new retry value. |
What happens when there is a broker/EG/Flow restart or the deployment of a new version? Where does the configuration data come from?
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| vicentius |
| Posted: Wed Aug 27, 2014 2:15 am Post subject: |
|
|
Apprentice
Joined: 01 Mar 2013
Posts: 28
|
| A sensible default or any of the three options mentioned by the OP. Having a "command interface" allows for on-the-fly changes without depending on deployment or restart. |
|
| Back to top |
|
|
| afroz11031 |
| Posted: Thu Aug 28, 2014 3:20 am Post subject: |
|
|
Apprentice
Joined: 28 Jan 2014
Posts: 36
|
| vicentius wrote: |
| A sensible default or any of the three options mentioned by the OP. Having a "command interface" allows for on-the-fly changes without depending on deployment or restart. |
First of all thanks for your valuable suggestion, we are going with database level however.
But did not get the point as mentioned ' Having a "command interface" allows for on-the-fly changes'.
Thanks
Afroz |
|
| Back to top |
|
|
| kash3338 |
| Posted: Mon Sep 01, 2014 10:16 pm Post subject: |
|
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
One other option I see is to have the retry value as part of a small XML file and load the XML into a MQ Queue. Do a MQGet (with Browse only option) and you can load/unload the XML with what ever values you need.
The MQGet operation can be done inside your retry sub-flow. This does not need a Flow/EG/Broker restart in any case. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Mon Sep 01, 2014 11:42 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Using Queues as a data store is really frowned upon in this forum.
It is not regarded as 'best practice'.
The DB option is far more flexible and IMHO maintainable.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| kash3338 |
| Posted: Tue Sep 02, 2014 1:58 am Post subject: |
|
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
| smdavies99 wrote: |
Using Queues as a data store is really frowned upon in this forum.
It is not regarded as 'best practice'.
The DB option is far more flexible and IMHO maintainable. |
Totally agree on your points on usage of MQ Queue as a data store. But this seems to be a value to store the retry count. This value does not have any impact on the business data and is purely for a technical purpose.
Since it is just a value which holds the count for number of retries (which being a technical data), MQ Queue should satisfy this requirement rather than having a DB for this purpose.
Imagine a case if the user does not use Database at all in his Integration implementation, just for such cases I guess MQ will help out. |
|
| Back to top |
|
|
| vicentius |
| Posted: Tue Sep 02, 2014 2:38 am Post subject: |
|
|
Apprentice
Joined: 01 Mar 2013
Posts: 28
|
Do not use a queue to store data, no matter the use case. A queue holds data for consumption, not for storage.
Instead of browsing for the value in a queue, MQGet-it from a queue, update the retry count and consume the message. Anytime you need a new value, send another message.
@Afroz:
Whatever input nodes your flows has, add a new MQInput, listening on a command/admin queue. Pass whatever messages come through there to a node where you use the value inside to update the shared variable which holds the current retry count. You can read the initial value either from a database, a configuration file, an UDP - or initialize it with a "best guess" value. Either way, once started, your flow will not require restarts/reloads to update the value, you need only to send command/admin messages in the expected format. Effectively, this creates a "command interface" for your flow. |
|
| Back to top |
|
|
|
|
