ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Suggestion on Parameterized value-Flow or DB level or other

Post new topic  Reply to topic
 Suggestion on Parameterized value-Flow or DB level or other « View previous topic :: View next topic » 
Author Message
afroz11031
PostPosted: Tue Aug 26, 2014 9:42 pm    Post subject: Suggestion on Parameterized value-Flow or DB level or other Reply with quote

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
View user's profile Send private message
smdavies99
PostPosted: Tue Aug 26, 2014 10:30 pm    Post subject: Re: Suggestion on Parameterized value-Flow or DB level or ot Reply with quote

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
View user's profile Send private message
vicentius
PostPosted: Wed Aug 27, 2014 1:30 am    Post subject: Reply with quote

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
View user's profile Send private message
smdavies99
PostPosted: Wed Aug 27, 2014 1:48 am    Post subject: Reply with quote

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
View user's profile Send private message
vicentius
PostPosted: Wed Aug 27, 2014 2:15 am    Post subject: Reply with quote

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
View user's profile Send private message
afroz11031
PostPosted: Thu Aug 28, 2014 3:20 am    Post subject: Reply with quote

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
View user's profile Send private message
kash3338
PostPosted: Mon Sep 01, 2014 10:16 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
smdavies99
PostPosted: Mon Sep 01, 2014 11:42 pm    Post subject: Reply with quote

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
View user's profile Send private message
kash3338
PostPosted: Tue Sep 02, 2014 1:58 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
vicentius
PostPosted: Tue Sep 02, 2014 2:38 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Suggestion on Parameterized value-Flow or DB level or other
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.