I am exploring possibility to fetch constant values from a property file and use those values in further flow.
Can it be possible to fetch the values from a property file through IS services or i need to go for custom java service ?
I can extract the file content through service ‘pub.file:getFile’, but how to extract particular value from output of this service
In general I used to use ResourceBundle in the java class and getString() function does the rest e.g rBundle.getString(“CAN_OPERATION”).
There is also a way to write the values you want into the server.cnf file and then retrieve. I have attached the code that contains a java service. You can specify multiple inputs in the string list and extract multiple outputs. I hope it is simple enough to understand. I have also added a test flow service that extracts the server debug log level and a few other things.
HTH
Ray
Get System Properties from Server.cnf File RayMoserProps.zip (7.4 k)
Regarding RMG’s post: Good way to go. Some of my clients like the idea of maintaining all of the configuration items in one place, hence my prior post on server.cnf file containing configuration settings. It’s really just a props file.
Also, it is VERY handy when moving code from one environment to another.
A few tips:
store database synonyms for oracle or db2 <synonym/owner.tablename)
any custom attributes you may want to have like debugOn/debugOff.
any time contrainsts. we have a thread.sleep service and we store the amount of “sleep” time in the server.cnf.
The major benefit to this is that you can add or subtract and even change information on the fly using the Edit Extended Settings in the admin console.
Pls advice:
1)Is it a good idea to use property file for constants values rather than having so much hard coding in the mapping.
2)Where should I put the property file, I mean under which folder , Can I put it under resources folder of that particular pacakage, Do I need to give fully qualified path or relative path to extract property file ?
For a particular pacakge , whats the default classpath IS server uses
It is a good idea to use property file for constants.
You can put the property file in your own package so that the dependency of that package on other packages is less. you can put it in a any custom folder in your package. you can give the relative path from the IntegrationServer folder, as that is the root folder. so you can give something like ./packages/<your>/resources/propertyfilename
1)yes,i feel creating propertyfile is the best option and get rid of harding coding in the mappings.(ofcourse some maintainence is involved while dev/testing/production moves)
2)In General you can put the property files in packages/particularPackage/config folder and then access it with path (./packages/ParticularPackage/config/sampleproperties.txt) and extract the propertyvalues.
This is the process we are following in our environment.
Another option for maintaining constants/parameters is a repository (see pub.storage package). This will take additional coding and some DSP pages - not a huge undertaking after few pages get done. Sure, it has nothing to do with property file approach.
While I agree with RMG in principle, you are doing yourself a diservice by placing the properties file in a package subdirectory.
The properties file should normally reside someplace in a sub-directory of the root install of Integration Server.
This will enable you to have separate property files per environment and will not overwrite any values that you may have between a dev, qa, staging or production system.
Just think of the issue that is created when a JDBC connection is configured in a “moveable” package rather than in a static config package. Each time you move the package that contains the jdbc configuration, you overwrite the value on the target server.
I guess its another issue, where to store the property file and what to store in a property file. Basically from, BMG and Ray, I think
global property file (server.cnf)
should store enviroment dependant configuration where moving from one platform to another certainly require modification. eg. firewall setting, global debug ON/OFF, database settings.
package property file (customised properties)
should store project and package based configuration where settings should maintain consistant across dev, qa and prod enviroment. eg. mapping constant, database name.
If package dependant property is store in global property file, such as mapping constant, it would not be update easily with package publishing, which might create a post-production update blind spot.
If enviroment dependant property is store in package property file, such as firewall setting, it would overwrite correct firewall setting on that machine, thus a migration blind spot.
By doing so, it makes depolyment easier yet maintain flexibilities. However, it does requirement planning.
You bring up a couple of new points that neither RMG nor I discussed. Some of it comes down to preference I suppose.
I like to use maps to set values since that is what they are designed to do. I almost always if possible insert a map at the top of a flow service and set my values there. It is my coding style.
The argument I get from many of my clients is that they want a way for a system admin to go into Integration Server and make changes at the command line without the need to use the developer. With a map, it is a difficult task. So, in some instances, I see a properties file as appropriate.
It really comes down to the standards and best practices that you set as an organization. Just try to make sure that you are consistent.
I do agree with your style,and even sometimes i used to set the default values in the first map step and do the conditional mapping further where ever it requires.
But, if any problem occurs in the production the support people may feel uncomfortable modifying the maps.
So in my experience using propertyfile is the best option when lot of default values are being used (eg:currency,ids,interfacenames etc…)
Get System Properties from Server.cnf File