XOG Connectivity Query

[CMCN1982]

I have a developer who is having connectivity issues while connecting XOG using command prompt.

He gets a XOG Invoke Failed Message when trying to connect.

 

 

Can anyone suggest how I go about resolving this connection issue? Thanks.

[navzjoshi00]

First, can you compare the entries in the properties file for the person who is receiving the error against the one who is not ?

 

NJ

[navzjoshi00]

Is this ondemand / on-premise ?

 

NJ

[navzjoshi00]

Also, check this -

 

https://communities.ca.com/message/241701574#241701574

 

NJ

[navzjoshi00]

In case you are SSO, check this as well -

 

https://communities.ca.com/message/241716118#241716118

 

NJ

[CMCN1982]

Hi NJ.

 

We are on premise. But other users do not have any difficulty using command prompt to XOG.

We don't have SSO enabled.

[navzjoshi00]

Were you able to compare the properties file ?

 

NJ

[CMCN1982]

"can you compare the entries in the properties file for the person who is receiving the error against the one who is not ?"

 

which properties file do you refer to? The properties.xml file would be the same for both users.

[navzjoshi00]

The one under CA\Clarity\CA Clarity PPM XOG\bin

 

NJ

[Suman Pramanik]

Hi Colin,

 

Can you please let me know if you used the compatible xog client version and how long it took before it got timed out.

 

Regards

Suman Pramanik

[Deactivated User]

I find that in a case like that the XOG ouptput may contain more clear reason in plain English.

What is your output?

[Deactivated User]

One way to check whether it is related to the user account or to the set up is to try to do XOG with somebody else's credentials and that particular workstation.

[CMCN1982]

Hi guys,

 

yes he is definitely using the correct compatible version. I believe it may be java related, or something to do with the configuration of his Java home variable.

I am going to compare the config of a working XOG connection with the one that isn't working as NJ suggests first.

 

By properties file do you mean the config in the xog.bat file located here:

C:\Program Files\CA\Clarity\XOG\bin 

[Nathan Arp]

I think what everyone is talking about is your properties.xml file in your Clarity install directory on your server.

[CMCN1982]

But the properties.xml file is the same for each user. So if it's not working for 1 user then I would expect it not to be working for any users.

[Anon Anon]

Yes you are correct.

NJ was probably talking about the so called test.properties in the bin folder.

[Deactivated User]

Yes for both of you that is why I suggested using the credentials of another user. that would test if the "whatever you call it.properties" file is correct.

 

On the otherhand if you are still in v13.1 you could use the XOG GUI client.

[Nathan Arp]

Quick question on this: Is this an ssl-enabled environment? If so, you're trying to login just with HTTP, not HTTPS.

 

Try this - instead of invoking XOG as a shell, try just running a simple XOG...

 

1. from command line,navigate to your XOG bin folder.

2.  Run the following:  xog -servername <host> -portnumber 8080 -sslenabled true -username <adminuser> -password <password> -input ../xml/prj_projects_read.xml -output ../out.xml

 

You can use any XOG, but make it simple so it should return quickly. 

[Nick Darlington]

xog -sslenabled true

 

Using this shortened version of the command line, you can still use the 'interactive XOG client' features but your login call will then perform SSL processing when you connect via the 'login username/password@yourserver:port' command (don't forget to include the port number even if it's defaulted to 443).

 

In this case as the login was port 8080 explicitly and so I would normally suspect this was an http Clarity implementation not a https one.. but its possible.

 

The only other suggestions I'd have at this time are:

 

1. If you go in a browser to http://yourserver:8080/niku/wsdl/Object/Projects and scroll to the bottom, does the soap:address location value have the same information that is being used?  If not, why not?

 

2. Do commands like nslookup and ping and tracert with the hostname being used in the login command return the correct responses without error or timeout?

 

3. How long is it before the connection time out exception occurs?

[CMCN1982]

Thanks guys - we will look into the suggestions posted and update with our findings.

[CMCN1982]

Ok so I asked another user to use his credentials at the problem workstation and it didn't work either.

 

We have ruled out Java as a possibility also.

 

The environment is SSL enabled - should we be using https: in the URL at login?

[Deactivated User]

My properties file is

 

# --- server host name you want to test against

servername=<just the server fully qualified omain name>

 

#default port number for ssl 443

portnumber=443

 

#set to true if running against a SSL enabled server

sslenabled=true

 

#set to true if running against a SSL enabled server in FIPS 140-2 mode

fipsenabled=false

 

input =../Input/licenses_cleaned_out.xml

output=../Output/licenses_cleaned_write_rslt.xml

username=..

 

So my answer is no, you do not need that

 

If the other user can't xog either

try entering all the parameters in the properties file on the command line, may be that will give more details on the cause.

[Nick Darlington]

Presumably if the developer uses his credentials at the other user's machine it works.

 

Regarding https, since you say the environment is enabled for this, then it does look from the screenshot as though the -ssl enabled parameter hasn't been used:

 

Example without using ssl/https mode XOG client:

C:\Clarity\xog1330\bin>xog

-----------------------------------------------------------
Clarity XML Open Gateway ( version: 13.3.0.285 )
-----------------------------------------------------------

...

> verbose
Verbose output is now on.
> login admin/admin@nowhere:8080
Login: admin@nowhere:8080
URL: http://nowhere:8080/niku/xog

(Note: The saving seems to cause some interesting things to happen with the appearance of the URLs in the post, so here is a screenshot of that part too:

)

 

 

Example with using ssl/https mode XOG client (note the differences in http/https url and also the first two lines output when running the command):

 

C:\Clarity\xog1330\bin>xog -sslenabled true

Using https
Configuring context for  TLS
-----------------------------------------------------------
Clarity XML Open Gateway ( version: 13.3.0.285 )
-----------------------------------------------------------

...

> verbose
Verbose output is now on.
> login admin/admin@nowhere:8080
Login: admin@nowhere:8080
URL: https://nowhere:8080/niku/xog

(Note: The saving seems to cause some interesting things to happen with the appearance of the URLs in the post, so here is a screenshot of that part too:

)

 

 

If that doesn't make any difference, then I would still be curious as to the results of the 3 items I referred to previously (from both the working and non-working machines for item #2).  As that might not be information and results you'd be comfortable providing here on the forum (contains machine names, ip addresses, network routes) then perhaps you could provide them on the issue that was opened.

 

However for an https enabled Clarity environment you should make sure the URL in the XOG client shows https as a result of using the correct startup parameters first.

[UrujHW]

Thanks Nick, your comment helped me a lot!

 

Uruj