Using the xServer 2 Java client to access the TEST system

Proper forum for all questions related to xServer INTERNET = the Azure based cloud solution. This forum deals with the architecture topics such as load balancing, available profiles and standard server settings.
Please be aware that questions about core functionality such as routing, mapping, geocoding in general should be placed in the xServers dedicated forum ;-)
Post Reply
Oliver Meyer
Posts: 10
Joined: Mon Aug 07, 2017 8:15 am

Using the xServer 2 Java client to access the TEST system

Post by Oliver Meyer »

We're implementing an application using the Java client for xServer 2.x and wanted to access the test endpoints.

In doing so we came across an important caveat: The WSDL returned by the TEST endpoint sets the service location to "localhost:50000".

When you use the xServer 2.x Java client exactly as suggested in the official documentation, it will work fine as long as you connect to the endpoint of the LIVE version:

Example for xLocate 2.x:

Code: Select all

XLocate client = new XLocate_Service(new URL("https://xserver2-europe-eu.cloud.ptvgroup.com/services/ws/XLocate")).getXlocate();
However, if you use the TEST endpoint (exchange "xserver2-europe-eu" by "xserver2-europe-eu-test"), the client will run into a java.net.ConnectException ("Connection refused").

The reason is that the SOAP client used by the PTV client implementation won't really connect to the endpoint you put here; instead, it will only use that URL to download the WSDL file. Then, it will use URL that is in the "wsdl:service" element in that document.

For the live version, there is no problem since the URL in the WSDL is identical to the URL of the WSDL.

For the test version, however, the URL in the WSDL points to "http://localhost:50000", sending the call back to your own machine, which of course fails, unless you have an instance of xServer running locally.

For proof, open the LIVE endpoint in a browser and scroll all the way down:
https://xserver2-europe-eu.cloud.ptvgro ... ocate?wsdl

At the very end of the document returned, you will find this service definition:

Code: Select all

<wsdl:service xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" name="XLocate">
    <wsdl:port binding="ns28:XLocateSoapBinding" name="xlocate">
      <soap12:address xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" location="https://xserver2-europe-eu.cloud.ptvgroup.com/services/ws/XLocate"/>
    </wsdl:port>
  </wsdl:service>
Now open the TEST endpoint https://xserver2-europe-eu-test.cloud.p ... ocate?wsdl in the browser and scroll down to find the wsdl:service element looking like this:

Code: Select all

<wsdl:service xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" name="XLocate">
    <wsdl:port binding="ns28:XLocateSoapBinding" name="xlocate">
      <soap12:address xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" location="http://localhost:50000/services/ws/XLocate"/>
    </wsdl:port>
  </wsdl:service>
This applies also to all the other services (XDima, XRoute, XTour, ...).

To work around this issue, you will have to set the ENDPOINT_ADDRESS_PROPERTY to the service after you've instantiated the service client:

Code: Select all

XLocate client = new XLocate_Service(new URL("https://xserver2-europe-eu-test.cloud.ptvgroup.com/services/ws/XLocate")).getXlocate();

((BindingProvider) client).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "https://xserver2-europe-eu-test.cloud.ptvgroup.com/services/ws/XLocate");
To the colleagues at PTV:
Is the TEST WSDL supposed to look like that? Would it make sense to change the wsdl:service location in the WSDL to point to the actual service cloud endpoint, instead of localhost?
This would make the above workaround obsolete.

Regards
Oliver
Last edited by Oliver Meyer on Mon Jan 14, 2019 2:50 pm, edited 1 time in total.
User avatar
Bernd Welter
Site Admin
Posts: 2564
Joined: Mon Apr 14, 2014 10:28 am
Contact:

Re: Using the xServer 2 Java client to access the TEST syste

Post by Bernd Welter »

Hello Oliver,

thank you very much for the description and the workaround.
I forwarded the post to DEV/PM and asked my buddies to cross check the workaround but also to evaluate whether our documentation should get an improvement.

Best regards,
Bernd
Bernd Welter
Technical Partner Manager Developer Components
PTV Logistics - Germany

Bernd at... The Forum,LinkedIn, Youtube, StackOverflow
I like the smell of PTV Developer in the morning... :twisted:
Mathias.Heß
Posts: 6
Joined: Fri May 29, 2015 8:53 am

Re: Using the xServer 2 Java client to access the TEST syste

Post by Mathias.Heß »

Hello Oliver,

thank you for the detailed description and sorry for the inconvenience. This is clearly a bug and we are working on a solution. I will post here as soon as the test deployment is fixed.

Regards, Mathias
Mathias.Heß
Posts: 6
Joined: Fri May 29, 2015 8:53 am

Re: Using the xServer 2 Java client to access the TEST syste

Post by Mathias.Heß »

Short update: The source of the problem is that we are using a new version of the azure application gate on the test deplyoment. It brings some useful new features, but apparently also brings some new bugs. Microsoft scheduled the bugfix to go live within the next 2 weeks.

For details: https://github.com/MicrosoftDocs/azure- ... sues/17084

Regards, Mathias
Mathias.Heß
Posts: 6
Joined: Fri May 29, 2015 8:53 am

Re: Using the xServer 2 Java client to access the TEST syste

Post by Mathias.Heß »

The problem should be solved now. The WSDL on the test systems now contains a valid endpoint again.

Regards, Mathias
Post Reply