I am invoking ServerAPI.getCurrentPort()in a java service.

I have the same problem, maybe webMethods can reply???

getTransportInfo will record the sender’s email address, or http info or client info depending on the protocol used, ftp, email, or http. If the client is non-existent, that is, the server itself is invoking this service and there was no client invoking a service on the server but rather the scheduler invoked the service, that could be why the port will be -1, because really in this case the server is invoking the service using the scheduler rather than a client invoking the service.
This could be the same rationale for the getCurrentPort service of the serverapi class.

Hi mike.bowman,

Please refer webM API for an answer to your question. Obviously, while scheduling and invoking getCurrentPort, it cannot resolve the port number associated with the excution thread (that of scheduler) and hence, returns -1.

If you have any other questions, please post. Let us know why you need to invoke getCurrentPort from a scheduled service. Maybe there is a better solution approach to your requirements.

Here is the excerpt from the API.

com.wm.app.b2b.server
Class ServerAPI method getCurrentPort

public static int getCurrentPort()

Returns the port number associated with the current thread of execution. The current thread of execution has an associated InvokeState object which encapsulates the information describing every service invocation (for example, the service being invoked, the user invoking the service, inputs to the service, etc). If the InvokeState object associated with the current thread of execution cannot resolve the port number, then -1 is returned.

• Saurabh.

That having been said, what is the best way to distinguish between instances. We run Dev and Test instances on the same box and log errors to the same table. I’ve added the port in to note which system logged the error and have the same problem discussed above, i.e. scheduled tasks show ‘-1’ (as expected).

Is there another, i.e. better, way to indicate the originating system?

Howard Neuwirth-Hirsch
FCS Business Solutions

Can you differentiate the environments via a property file (or simply a property in the extended settings)?

On the extended settings tab, create a property (i.e. watt.tellmemy.environment = “dev”), then run a java service to get the properties (PSUtilities.properties:getSystemProperties or WmSamples.sample.propertyFile:getProperties) to retreive this value. If opposed to the extended settings tab, you can also use a text file to load properties to memory (WmSamples.sample.propertyFile:getProperties), then retreive them the same way as above.

I think this is a more viable solution for determining the environment than checking the port.

Howard Neuwirth-Hirsch,
Brain answered your question perfectly.

Have a java property host.type or environment.type defined to dev/test/prod and while logging, preappend the log message with [System.getProperty(“host.type”)] so that every log message will include where it originated from.

• Saurabh.

There are ways to get the current port information either by using extended setting or by using config files but this potentially seems to be bug related to ServerAPI. You can certainly overcome that also by creating a wrapper service using the Service API to invoke the Java Service which in turn returns ServerAPI.getCurrentPort().

HTH,
Muthu.