Hi,
My service will generate a flat file, in the header it has to insert some indicator to know, whether its a Test file or Production file.
Is there any service, that I can find on which server the service is running, If I get that information, I can dynamically set the Indicator, based upon the result from that service.
Thanks
Kris
One approach to consider is the use of a property in the system.cnf file. I’ve used this on previous projects. You can use Administrator to set one. The property can be something like watt.server.Company.envName with values of dev, test, prod or whatever environment names make sense for your installation. Then you can write a Java service to use System.getProperty(“watt.server.Company.envName”) to retrieve the value and make your decision.
You can use the service PSUtilities.misc:getServerInformation in the PSUtilities package. This will return you the serverName and you can perform a branch on this to determine if this is the server of your DEV, TEST, or PROD server and then do what you need to do.
getServerInformation
BRANCH on /serverName
DEV_SERVERNAME SEQUENCE
TEST_SERVERNAME SEQUENCE
PROD_SERVERNAME SEQUENCE
Our server recently received a new subnet and is behind an ipsprayer now. And since this happened, our ServerAPI.getServerName call gives us a new value:
previously: wMDev
now: wMDev-n.server.net
Any idea why this is happening and if it’s possible for us to change that value back to our old value?
Thanks!
Two issues: they’ve changed the name of the server from wMDev to wMDev-n; you’re now getting the fully-qualified name of the server. This is one reason why using getServerName to make branch decisions within services is not a good idea. Server names change and they usually don’t tell you about it. (I should have responded to ylo’s post back in Aug warning about this, but I missed it.)
You should consider using some other mechanism to identify the environment in which your services run. Use a mechanism that you can control, rather than relying on external things that have no idea that your code has a dependency.
As a stop-gap, if you can make changes to your code, you can try to match using a regex:
BRANCH on /serverName
…/^wMDev/: SEQUENCE (serverName starts with wMDev)
Looks like you have a load-balanced environment now!! I think you should get more details on the exact changes done to your environment from your network (LAN/WAN) groups.
Generally, IP addresses will change more frequently than hostnames!! Any change to hostnames should be coordinated between application/network groups. To me it looks like that the information about these changes in your environment didnt trickle down to you.
Obviously a lot depends on how your organization is structured.
IMO, hostnames should not be relied upon if at all possible, especially names returned from the OS/naming resolution–which is what getServerName does.
Rob, please explain more on this? do you mean within application code or configuration loader?
Eventually, you need to use either IP address or hostname. And generally speaking, between the two, you are always better off with the hostnames. Certain dependencies on hostnames, you can never get rid of. For ex, code doing HTTP to wMDev needs to be changed to do HTTP on wMDev-n now
The issue that cjcable faced, was more of change management notification issue between the groups, wherein he wasnt aware of the changes made in his development env; Obviously, his code was somewhat dependent on the hostname [not good], than on configuration [property or hostname based].
As far as your recommendation wrt configuration loader goes, I fully second that and cant stress the importance enough. One should try not to load configuration within application code/startup sequence based on hostnames!!
The only issue I have faced in the past with loading configuration property based, is when the system admins blindly copy directory tree to make quick backup copies on unix for test/dev environments!!
Also, always by default, one should remember to load the “dev” configuration rather than the production env variables. If one is ok with complexity, one can use a mixture of property/hostname based configuration loader.
If I remember correctly, someone wrote an excellent Ezine article on configuration loader for webMethods.
Both.
My point is that one can likely avoid using hostnames and IPs altogether. For example, one can define a property like watt.server.MyStuff.envName and use values like “dev”, “test” or “prod”. (This is just one possible approach.)
Then the code can use these names instead of hostnames or IP addresses and therefore will be immune from changes that sys admins or network admins may make and don’t communicate. It’s rare that a real hostname is actually needed within code. It’s also rare that a hostname be used in a configuration file to control conditional logic–usually the hostnames are only for establishing connections to the right servers.
My point again is that configuration should not be hostname/IP based. Use something else to make conditional choices.