I am just starting developping flow services with webMethods Integration Server 6.1. I read Ray Moser’s Ezine regarding the usage of IS Repository for Data Storage and decided implementing it. This works fine (many thanks to Ray!). However I just wanted to use an additional properties file in order to externally define:
the name of the datastore to create upon server startup
the location of the xml files containing all other integration properties.
I access the name/value stored into this properties file through a java service such as:
String configPath = System.getProperty(“common.utils.config.path”);
However I am not succeeding in loading this file (myfile.properties). Each time when I debug my flow service there are no values returned by the getProperties method (the file does not appear to have been loaded). Here are the different solutions I tried (none worked, of course I restarted IS after each change):
I copied the properties file under a specific location, which I added to the APPENDCLASSES variables of the server.bat file
I copied the properties file under the IS/config directory
I copied the properties file under the IS/packages/<mypackage>/config directory
I copied the properties file under the IS/packages/<mypackage>/code/classes directory
I could not find information regarding this simple matter within the wM documentation.
I could also not find any indication that I am allowed to extend the wM server properties (server.cnf) with my own custom properties (no way to add properties from the Administration tool and this server.cnf seems to be dynamically regenerated upon IS restart using the values set through the web console)
You can find some info on this by downloading and looking at the PSUtilities package from advantage. Look in the properties folder for the PSUtilities package.
In addition, the WmSamples package, which you should already have, contains a sample folder. Look in there, and you will see a propertyFile folder.
I recommend putting the property file in the packages /pub folder to make it easier to transport when moving. Otherwise, you may forget about it during the installation phase.
Putting properties files in the /pub directory is not a particularly good idea from a security standpoint since it exposes the file directly via HTTP. You can lock this down with an .access file.
It is better to put in the package’s config directory and do a
You make a good point. However, I do not expose my Integration Server to the outside world. I lock it down and use RI, or TN to route my data or to facilitate calls.
I also make judicious use of my firewall settings.
I usually put my stuff in the pub directory and modify the index.html to contain the contents.
As a consultant, this is one of the ways that I document the work that I do. I leave it up to the client to move, remove or leave the data.
However, your point is valid for those who do not practice good security.
I can’t recall ever working on an implementation where the IS server was exposed. Most places have multiple firewalls between the DMZ and the IS server.
No worries, when you put files in the /pub directory, they still need to be added to the .access ACL descriptors before they are available to the outside world without logging into an IS session.
But true, /config is much better. Do note however that if you use multiple services (Dev, Test, Acc, Prod) you might want to keep your config files (those with server specific info) in a separate package. Otherwise you will overwrite them each time you migrate a package.
I followed the sample Ray pointed me to and successfully loaded my property files. My mistake came from the fact I was assuming that IS classloader would automatically load any *.properties file present in its classpath. Now I load them manually. I stored it into my /config directory
Ray, out of curiosity, I did not quite understand how to use the server.cnf file. I tried to store an additional property (eg octo.conf.test=mytest) into it: upon IS restart this property had disappeared from the server.cnf file… My guess is that IS stores the values set through the Administration console somewhere else on disk and dynamically regenerates this file at start time. Is that correct?
you can store the default values using ISAdminConsole/Extended Setting page(this will internally stored in server.cnf file)and use the WmSamples service for retrieving the values.
Also you have to restart IS once you have save the values in the extended section.
TO anwswer your question, look in the config directory where server.cnf resides and you will see a backup directory. On startup, IS will store the file there.
If you manually add lines outside of the extended values interface in the admin console, then you have to shutdown IS prior to editing or they will not take.
I do not see any option (such as Add Key or Create Key) on the “Settings > Extended > Show and Hide Keys” page (admin console) that would allow me to create my own properties, I only see there the possibility to set the values for already existing webMethods properties. Sorry if my query was not explicit: what I am trying to achieve here is to define my own properties, not to use webMethods ones.
Actually I have succeeded in that (reusing wM samples), manually loading my properties, from my own package properties file, into static variables so that they can be retrieved by any process without reloading the properties file. However I am curious to learn whether there is any way I can make use of the webMethods properties files (enriching them with my own properties) as this would remove the need for me to manually load my properties files.
Ray,
I did stop IS before modifying server.cnf (adding the “octo.conf.toto=titi” name/value property). Following IS restart, this line appears to have been removed from the server.cnf file! I then tried to first remove the backup/server.cnf file before editing the config/server.cnf: surprisingly, upon IS restart, none of the two server.cnf files contained my property…So I do not understand how you manage to customise this property file, what am I doing wrong here?
I’m Sylvain a Phillp’s colleague.
Well I succeeded, as you suggested, to add a property but only by prefixing it with ‘watt’; e.g. watt.myprop=myValue.
Is that the regular way of doing this? Is there any other issue to set a property with a different prefix (e.g. octo.myProp=myValue)?