Detecting host Name or IP in flow service

, ,
1

I am developing a general purpose error notification routine.
The email address and the mailhost ip will be different between Dev and prod. Is there a way to detect which server I’m running on within a flow service or does anyone have a Java service that will do this.

Thanks.

Chris

2

Can I suggest that you use configuration files? It might make your deployment simpler and easier to maintain.

However, here is a simple, hard-coded version that does employ configuration files.

  1. Create a server variable named watt.server.environment and assign it the value of “dev” or “prd”, depending on your environment. []Create a Java service that invokes System.getProperty(“watt.server.environment”) and returns the string variable. This variable is your environment (i.e. “dev”, “prd”) []BRANCH on the returned string to assign an email address and mailhost IP.

As noted above, this approach is using hard-coding variables. If you can use configuration files to store the email address and mailhost IP, you will be building a more flexible solution.

3

Dan,

Thanks for the speedy reply.
I haven’t used config files. Which manual do I research in?
Thanks.

Chris

4

And if you want to get the name of the configured mailhost and the email address you can create a java service that reads the values of the properties :

watt.server.smtpServer
watt.server.serviceMail

5

And if all that you want is to get the name of the IS server then you can use the service

wm.server.admin:getServerHost

6

Nice pick up, Rupinder! Funny how I missed the obvious play on that one.

Regarding environment-independent configuration files, Chris – I will write a webMethods Ezine article about the process and will include sample code for download. Our November ezine line-up is already full, so expect to see it in the December issue.

7

Dan,

I’ll look forward to the ezine article but in the meantime is there a wm doc that I can read on the properties of the configuration files and how to use them.

Chris

8

Rupinder,

I do not have wm.server.admin:getServerHost in my system.
I’m running IS 4.6.
I have searched all the packages.

Chris

9

Hi, Chris. I am not sure if there is any manual discussing configuration files. The IS Developer Guide talks a little bit about using server.cnf for managing properties, but that solution can be limiting.

You should be okay with Rupinder’s solution(s). In effect, using the Settings > Extended feature of the Administrator is the same as setting the variables in server.cnf but with more control – your webMethods administrators can change the properties at any time for any environment.

10

Chris,
why don’t you use watt.server.port property combined with InetAddress.getLocalHost().getHostAddress()
to determine “dev” or “prd” and then accordingly set the mailhost and email params.

Additionally, you can use combination of System.getProperty and Extended settings to set the env-specific params.
or use set of java property files. options are limitless.

HTH,
Saurabh.

11

Is there some property setting, that would put the timestamp in the server.log file.
The setting watt.server.dateStampFmt seems to affect only the error.log file.

12

The wm.server.admin:getServerHost service is there, it’s just hidden inside the WmRoot package.

To make the WmRoot package browsable in Developer, go to Adminstrator and select Settings > Extended > Edit Extended Settings. Add “watt.server.ns.hideWmRoot=False” to the extended settings and select “Save Changes”.

Refresh your Developer and you will be able to browse the WmRoot package for wm.server.admin:getServerHost.

13

Dan,

You’re a life saver!
How would one know about this? Is this buried somewhere in the endless number of pdf files?

Thanks again to all.

Chris

14

Happy to share.

No, that tip is not documented anywhere except for on these Discussion Forums.

I think we need to add a new feature to the webMethods User Community – “Things Every Developer Needs To Know (But Didn’t Know To Ask)”.

15

The reason wmroot is hidden, and the flag isn’t documented, is that wm doesn’t want you using/messing with anything in there. It’s unlikely that any services would change but be aware that doing anything with wmroot in your services is unsupported and could be broken by future releases.

16

We use a slightly diffent method.
A Java Service is called from flow and hostName is populated. We then Branch on hostName
// pipeline
String hostName = “unknown”;

hostName = ServerAPI.getServerName();

// pipeline
IDataHashCursor pipelineCursor = pipeline.getHashCursor();
pipelineCursor.last();
pipelineCursor.insertAfter( “hostName”, hostName );
pipelineCursor.destroy();

17

For situations where we have values that change per environment and which can’t be obtained via webMethods services, we use a resource bundle which is located in one of our packages. This bundle is modified during our automated builds depending on the environment. So our flow service loads a value via this bundle and it is configured correctly beforehand.

I think the extended properties idea is interesting as well.

18

Hi Will,
can you explain this resource bundle usuage ??

Sounds like you have different resource bundles for different env’s. How do you edit these resource bundles - manually or did you write a utility for it??

And, how does the build scripts know which bundle to pick for a particular env?

Additional details will help us understand this concept of using resource bundles instead of java property files?? What are the other benefits of it?

Thanks in advance,
Saurabh.

19

Hi Saurabh,

We used a resource bundle to handle the possibility that we may have locale-specific values in the bundle (like error messages in different languages perhaps). If you are just storing server configurations a property file will work fine. In both cases you would have something like this:

my.property=@envSpecificProperty@

When the build script runs it replaces @envSpecificProperty@ with the proper value. We just use one bundle, but this bundle is altered during the build script run. We could run our build script at a command line that goes something like this:

bld --ENV=qa

So within the shell script, it knows which environment it is building. The environment specific values are in this shell script. Although we use the same bundle, this bundle will be in a different location since we have multiple instances of IS installed - so the directory structure has this environment in it like - /opt/wm/qa or /opt/wm/rc. Here’s an example of what the script is doing.

elif [[ $ENV = qa ]]; then
envSpecificProperty=“qa.myhost.com”

You can use ant to do this as well as do the search and replacing of the bundle. The script could load the values for the different environments from one file containing values for all environments.

As I describe this I’m starting to think that the extended property settings would be much easier! Since you have to store the values you want somewhere, why not within the server instance itself! One argument could be to have all the values in one location instead of having to go to each server to make changes.

20

Dan,

I noticed when I tried to add a custom property to this file that I don’t see the entry. Instead there’s a line like:
watt.server.extendedSettingsList=do.hub.url;

This could be confusing for administrator’s - any idea how this works, where the value is stored, etc?

Thanks