Author |
Message
|
VishnuPrasadS |
Posted: Wed Dec 04, 2013 10:39 am Post subject: Optimal way to use configuratoin information in mb |
|
|
Apprentice
Joined: 22 Feb 2013 Posts: 28 Location: Pune, India
|
I want to find optimal way to use configurational information in mb.
Please share your views.
Let me know if you have any other options
Options:
1. use java Properties class, query values from esql
2. store values from java to esql shared row variable
3. at first entry point store config values to MQRFH2.usr
2.1 how to initialize a shared esql row ?
options :
2.1.1. check if it is initialized for every message to flow
2.1.2. initialize using trigger from TimerNotification node
Issues with above said points
for option 1. Call from esql to java is not performance friendly
for option 2.1.1 Need to check if esql shared variable is populated for every message. If programmer forgets to include this check in any one entry point then it could result in null value access.
for option 2.1.2 Consider Input queues have 100's of messages. Now the execution group is reloaded. Execution Group has multi threaded flows. For first second or so, accessing the shared esql row will result in null value.
for option 3 Copy of all config values to MQRFH2.usr for every message is needed even if only few of them will be used.
Details of above said points are mentioned below.
--------------------------------------------------------
1.
// java static block to load values from file to hashmap
static {
InputStream is = null;
is = new FileInputStream(new File(FILE_NAME));
prop = new Properties();
prop.load(is);
is.close();
}
public static synchronized String getProperty(String key) {
if (key == null)
return null;
return prop.getProperty(key);
}
--esql can access values in java hashmap using this procedure
CREATE PROCEDURE GetPropertyValue ( IN key char) returns char
LANGUAGE JAVA
EXTERNAL NAME "a.b.PropertyLoader.getProperty";
declare value char GetPropertyValue('......');
--------------------------------------------------------
2.1.1
CREATE PROCEDURE PopulateSharedEsqlVariable ( IN esqlRow reference) returns boolean
LANGUAGE JAVA
EXTERNAL NAME "a.b.PropertyLoader.PopulateSharedEsqlVariable";
--
declare sv shared row;
declare loaded shared boolean false;
CREATE FUNCTION LOAD_SHARED_ESQL_VARIABLES()
BEGIN
if loaded is false then
set loaded = PopulateSharedEsqlVariable(sv);
end if;
END;
--
public static synchronized Boolean PopulateSharedEsqlVariable(MbElement esqlRow) {
try {
Set keys = prop.keySet();
for (Object key : keys) {
.....MBElement....Create...(esqlRow, key.toString()).setValue(prop.getProperty(key.toString()));
}
return true;
} catch (MbException e) {
throw new RuntimeException(e);
}
}
}
LOAD_SHARED_ESQL_VARIABLES should be called immediately after all "entry points of flow".
Then acess to configurational values is possible as
declare value char sv.configKey;
--------------------------------------------------------
2.1.2
methods mentioned in 2.1.1 will be used
but LOAD_SHARED_ESQL_VARIABLES() will be called only when the execution group is reloaded or only during bar deployment.
To achieve this a TimerNotification node is connected to a ESQL compute node and this compute node will invoke LOAD_SHARED_ESQL_VARIABLES()
Property of TimerNotificatoin node
Operation mode : Automatic
Timeout Interval : 86400 or any other large value
--------------------------------------------------------
3.
call PopulateSharedEsqlVariable(OutputRoot.MQRFH2.usr.ConfigLoc);
--Then acess to configurational values is possible as
declare value char InputRoot.MQRFH2.usr.ConfigLoc.configKey;
-------------------------------------------------------- |
|
Back to top |
|
 |
Vitor |
Posted: Wed Dec 04, 2013 11:03 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
Why have you discounted promotable & user defined properties, which are the supplied way to provide environment specific information to the flow? _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
VishnuPrasadS |
Posted: Wed Dec 04, 2013 8:09 pm Post subject: |
|
|
Apprentice
Joined: 22 Feb 2013 Posts: 28 Location: Pune, India
|
The options i mentioned in previous post have a specific advantage over user definded property :
For the changes to reflect bar file deployment is not required. Execution group reload is enough.
Example :
if you need to enable/disable logging
Change the max allowed retry count for a particular exception
etc |
|
Back to top |
|
 |
Simbu |
Posted: Wed Dec 04, 2013 9:06 pm Post subject: |
|
|
 Master
Joined: 17 Jun 2011 Posts: 289 Location: Tamil Nadu, India
|
you can change user defined property at runtime and no Execution group reload is required.
Have you considered using Database to store the configuration information and cache it. |
|
Back to top |
|
 |
VishnuPrasadS |
Posted: Wed Dec 04, 2013 10:22 pm Post subject: |
|
|
Apprentice
Joined: 22 Feb 2013 Posts: 28 Location: Pune, India
|
Message flow user defined property can be set at runtime using 'cmp api' or 'WMB explorer'.
This is not acceptable to me because our deployment team prefers to use putty commands for deployment and configuration change. I know this is not a valid reason for not using 'cmp api' or 'WMB explorer'.
We have not used database to store config information until now. This could be a good approach.
I need suggestions from you to figure out an optimal configuration mechanism from the options I have mentioned in my first post.
Option 4 :
Use Message flow user defined property instead of ESQL shared row variable.
Updating the values of UDP will be through options 2.1.1 or 2.1.2 |
|
Back to top |
|
 |
smdavies99 |
Posted: Wed Dec 04, 2013 11:23 pm Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
We hold all our flow specific config data in a table. The flow reads it upon startup and holds it in a share variable (ROW). A timer refreshes it every 24 hours but if we make changes and need them to be used right away, all we need to do is to restart the flow concerned.
At the risk of encountering the wrath of some posters here, we don't generally allow things like Barfile overrides and the use of CMP is frowned upon.
We take the view that the same barfile is to be used in all environments. Then is something does not work then 99% of the time it is down to configuration data. But each site should develop their own standards and procedures.
Do what is best for you. _________________ 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 |
|
 |
Vitor |
Posted: Fri Dec 06, 2013 5:04 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
[quote="VishnuPrasadS"]This is not acceptable to me because our deployment team prefers to use putty commands for deployment and configuration change. [quote]
You can also use mqsiapplybarfileoverrides from a putty command prompt to change these values. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
Esa |
Posted: Fri Dec 06, 2013 6:34 am Post subject: |
|
|
 Grand Master
Joined: 22 May 2008 Posts: 1387 Location: Finland
|
Vitor wrote: |
VishnuPrasadS wrote: |
This is not acceptable to me because our deployment team prefers to use putty commands for deployment and configuration change. |
You can also use mqsiapplybarfileoverrides from a putty command prompt to change these values. |
You can also write a CMP api java program and a script for running it from command line. |
|
Back to top |
|
 |
|