PHP SoapClient doesn't load WSDL - web-services

I have this WSDL:
<wsdl:definitions xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="http://sei.esempio.it/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:ns2="http://schemas.xmlsoap.org/soap/http"
xmlns:ns1="http://esempio.it/" name="XServiziService"
targetNamespace="http://sei.esempio.it/">
<wsdl:import location="http://example.lan:8082/XServizi?wsdl=Sei.wsdl"
namespace="http://esempio.it/"> </wsdl:import>
<wsdl:binding name="XServiziServiceSoapBinding" type="ns1:Sei">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="HelloWorldOperation">
<soap:operation soapAction="" style="document"/>
<wsdl:input name="HelloWorldOperation">
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output name="HelloWorldOperationResponse">
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="XServiziService">
<wsdl:port binding="tns:XServiziServiceSoapBinding" name="XServiziPort">
<soap:address location="http://example.lan:8082/XServizi"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
I tried to import with SoapClient in PHP, but I get this error:
SOAP-ERROR: Parsing WSDL: Couldn't load from 'https://example.lan:8083/XServices?wsdl' : failed to load external entity "https://example.lan:8083/XServices?wsdl"
I added also login and pass in SoapClient. I don't know why, with other WSDL, it works.
I can't import with SoapUI either. I get this error:
Error loading [http://example.lan:8082/XServices?wsdl=Sei.wsdl]: org.apache.xmlbeans.XmlException: org.apache.xmlbeans.XmlException: error: does not close tag .
I disabled also the proxy in SoapUI, but it doesn't work.
Any suggestions?

Based on the error messages, the problem is related to the <wsdl:import> inside the WSDL file you posted. Your WSDL is composed of two parts: the one you are diplaying and the one that can be found at the URL http://example.lan:8082/XServizi?wsdl=Sei.wsdl
Your error messages show two different things.
One has a problem with https://example.lan:8083/XServices?wsdl and the other with http://example.lan:8082/XServices?wsdl=Sei.wsdl. I'm not sure how you edited these URLs for privacy when posting this question and why one is on port 8083 and the other on port 8082, but the idea is that all parts of the WSDL need to be accessible:
the URL of the main WSDL needs to be accessible by your tooling;
the URL that the main WSDL imports also needs to be accessible by your tooling;
Only then will your tooling be able to read the WSDL and all its parts and generate a SOAP client.
Note also that some tools choke on WSDLs with imports (see here for details). Not familiar enough with PHP SoapClient though to know if that's the case here.
Since you can't control the service, your options are to somehow make both XMLs available to your tooling.
First make sure the URLs are accessible.
If that's not the case, then somehow get a hold of their content. When you have them, you could save the content of the two URLs in your local PHP server as main.wsdl (this is the WSDL you are showing in your question) and second.xml (this is what's imported). Then in your main.wsdl you change the import location. For example, if you expose the files locally as http://localhost:80/main.wsdl and http://localhost:80/second.xml then in main.wsdl you change the import to look like this:
<wsdl:import location="http://localhost:80/second.xml" namespace="http://esempio.it/"></wsdl:import>
then point the SoapClient or SoapUI to read http://localhost:80/main.wsdl instead.
You could try this on disk and place the files one next to each other in the same folder, then change the import to:
<wsdl:import location="second.xml" namespace="http://esempio.it/"></wsdl:import>
then point the tools to the main.wsdl file on disk. I'm not sure this will work though. Have never tried it. SoapUI might be able to fetch the files from the same folder, the PHP SoapClient I doubt so.
There is also the option of downloading both XML files and combine them into just one WSDL file (basically resolving the import manually) then use just this file for your tooling. You will have to know what you are doing though, in order to obtain a valid and correct WSDL file.
Or finally, you could ask the service provider to give you just one WSDL file you can use instead. There is no point of asking them to change the current WSDL because most likely they have other clients too and fixing this for you might break stuff for somebody else (as mentioned in the link above).
But this is probably just an accessibility issue, so make sure those URLs are accessible from your browser before using them with SOAP tools.

Related

Outlook.com WSDL has no service element

I'm trying to write a client for Outlook.com mail. I've successfully connected and authenticated, and downloaded the WSDL. However, the WSDL has no service element, which the specification requires.
I dutifully checked all the imports per the question "wsdl has no service element" even though they're called messages.xsd and types.xsd, and found no service elements.
This page on Google Code describes the issue.
The service element is missing, presumably so they can distribute a single Services.wsdl that will work on all servers without having to customize it. I'm not sure of the reasoning.
The net effect is that you have to add the element yourself to the end of the file:
...
<wsdl:service name="ExchangeServices">
<wsdl:port name="ExchangeServicePort" binding="tns:ExchangeServiceBinding">
<soap:address location="https://my.exchange.com/EWS/Exchange.asmx"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

http:inbound-endpoint host 0.0.0.0 rebind to local ip in pattern:web-service-proxy does not work

Mule Version: 3.4.0 CE
I'm using pattern:web-service-proxy and my inbound-endpoint is set to 0.0.0.0, like this:
config file contains:
http.host=0.0.0.0
http.port=8080
flow
<pattern:web-service-proxy name="adm-core-group-ws-proxy">
<http:inbound-endpoint host="${http.host}" port="${http.port}" path="adm/group/GroupService" />
<http:outbound-endpoint host="${visto.host}" port="${visto.port}" path="visto-system-service/GroupService" />
</pattern:web-service-proxy>
the result of wsdl location
<wsdl:service name="GroupService">
<wsdl:port binding="tns:GroupServiceSoapBinding" name="GroupServicePortTypeImplPort">
<soap:address location="http://0.0.0.0:8080/adm/group/GroupService"/>
</wsdl:port>
If you notice, the host is not replaced with the machine ip, like in other cases.
Is that a known error?
Maybe I can "fixed" it by using the machine host name instead, but is that a good way to solve it? And is it going to work?
Thank you!
I think the issue comes from the fact the remote WSDL contains a bad address:
<soap:address location="http://system/adm/service/group/v1_0_0/GroupService.GroupServicePortType" />
Instead of system it should be the value of ${visto.host}, that way the WSProxy could replace it with the host value from the inbound HTTP request that hits the http:inbound-endpoint.
Can this remote WSDL be fixed? If not, you'll have to download it, fix it by hand then refer to it in the pattern:web-service-proxy as a file-based WSDL.

WebServiceException when accessng webservice using Apache CXF generated classes

I am having problems accessing a web service using Apache CXF generated classes (wsdl2java).
Everything was working fine until the web service provider suddenly changed a rule on their firewall and hosed us. What they are saying is they no longer allow http traffic, we have to start using https. The funny thing is, up until now we thought we were using https. This is inherited, legacy code. But we are pretty much using word for word the ssl example on the Apache CXF web site.
Here's a chunk of the wsdl:
...
<wsdl:portType name="GetMessagesSoap">
<wsdl:operation name="GetInfo">
<wsdl:input message="tns:GetInfoSoapIn" />
<wsdl:output message="tns:GetInfoSoapOut" />
</wsdl:operation>
</wsdl:portType>
...
<wsdl:service name="GetMessages">
<wsdl:port name="GetMessagesSoap" binding="tns:GetMessagesSoap">
<soap:address location="http://127.0.0.1/GetMessages.asmx" />
</wsdl:port>
</wsdl:service>
Basically we generate all the Java classes using wsdl2java. Then in our Gateway class we do the following:
private GetMessagesSoap getInstance() {
GetMessages getMessages = new GetMessages(wsdlUrl);
GetMessagesSoap getMessagesSoap = getMessages.getMessagesSoap();
setupTransportLayerSecurity(getMessagesSoap);
}
private void setupTransportLayerSecurity(final Object port) {
HTTPConduit httpConduit =
(HTTPConduit) ClientProxy.getClient(port).getConduit();
TLSClientParameters tlsCP = new TLSClientParameters();
KeyStore keyStore = ...
KeyManager[] myKeyManagers = getKeyManagers(keyStore ...
tlsCP.setKeyManagers(myKeyManagers);
KeyStore trustStore = ...
TrustManager[] myTrustStoreKeyManagers = getTrustManagers(trustStore);
tlsCP.setTrustManagers(myTrustStoreKeyManagers);
tlsCP.setDisableCNCheck(true);
tlsCP.setSecureSocketProtocol("SSL");
httpConduit.setTlsClientParameters(tlsCP);
}
Then we call getInfo(). This is where the error occurs.
public void getInfo() {
GetMessagesSoap getMessagesSoap = getInstance();
InfoResponse response = getMessagesSoap.getInfo()
}
The error we get is rather generic:
javax.xml.ws.WebServiceException: Could not send Message.
The ws provider says it's failing because we're trying to come in using http. All this despite all the fancy SSL stuff we're doing in the setupTransportLayerSecurity() method.
My fundamental doubt in all this is, is that really the reason it's failing? I mean, obviously it started failing when the rule was removed from the firewall. But, what I don't understand is, if the url in the GetMessages service in the wsdl is http, even if I say to use SSL, how in the world is it ever going to use https?
We've put a sniffer on the network and sure enough it's only using http. But ... isn't this normal?? I am by no means a SOAP expert, obviously. Can someone shed some light on this problem?
CXF HttpConduit only uses the TlsClientParameters when the address url is start with https.
Can you change the WSDL file?
If not, you can change service url at the runtime.

How to get the properties read from the property file into the wsdl and the generated stubs

What i am trying to do is to separate configurations of endpoint address and also service versions into something like .properties file or any. Since, the endpoint will be different in various environments, such as UAT and PRODUCTION environments. Also, the service provider controls the service/message version by using naming convension like ABCDEF_10_4, ABCDEF is the name of the service and 10.4 is a release version. We are just a service consumer, so we cannot change anything on the server side.
What I am looking for is the way to make use of something similar to this
<wsdl:operation name="service1">
<soap:operation soapAction="**${endpointurl}/${msgname}**" />
<wsdl:input>
<soap:body use="literal" />
<soap:header use="literal" message="tns:MessageHeader" part="session" />
</wsdl:input>
<wsdl:output>
<soap:body use="literal" />
<soap:header use="literal" message="tns:MessageHeader" part="session" />
</wsdl:output>
</wsdl:operation>
<wsdl:service name="**${servicename}**">
<wsdl:port binding="tns:ServiceBinding" name="ServicePort">
<soap:address location="**${endpointurl}**" />
</wsdl:port>
</wsdl:service>
Where I can specify those values in name:value pair similar to .properties file like
endpointurl=http://xxx.xxx.xxx.xxx:10000
msgname=ABCDEF_10_4
servicename=myService
The problem is that I dont want to change wsdl everytime the service provider releases a new version of their services and also it will be easier for me and my team to manage the version of the services in just one place.
Also, when we deploy our applicaion on UAT/DEV/PROD/TEST environments, we dont need to make any changes in wsdl everytime or have many wsdl files for each environment.
We are using maven cxf codegen plugin to generate client stubs.
Any idea or possible way to do something similar to this?
OK, after digging around google for 3-4 hrs, I found the answer and think that I should contribute to the community.
First, I create a new profile and use maven-resources-plugin filtering to replace ${param} in wsdl from the .properties file and copy the replaced resource to target folder.
Then, in that profile I user cxf-codegen-plugin to generate the webservices clients from the generated wsdl.
That's it :)

HTTPS WSDL soap:address location is not correctly rewritten by web-service-proxy

This problem is present in mule 1.3.2-201212121943
WSDL soap:address location is not correctly rewritten by web-service-proxy with .NET WS
<mule ...>
<https:connector name="HTTP_HTTPS" sendBufferSize="0" receiveBufferSize="0" receiveBacklog="0" clientSoTimeout="10000" serverSoTimeout="10000" doc:name="HTTP\HTTPS">
<https:tls-client path="xyz\keystore.jks" storePassword="mulepassword"/>
</https:connector>
<pattern:web-service-proxy name="xyz-ws-proxy" >
<http:inbound-endpoint address="http://localhost:8081"/>
<https:outbound-endpoint followRedirects="true" address="https://xyz/g2g/BPM#[header:inbound:http.request.path]" connector-ref="HTTP_HTTPS" />
</pattern:web-service-proxy>
</mule>
http://localhost:8081/xyz.asmx?wsdl returns wsdl with
<wsdl:port name="XYZEndpointSoap" binding="tns:XYZEndpointSoap">
<soap:address location="http://xyz/g2g/BPM/xyz.asmx" />
</wsdl:port>
<wsdl:port name="XYZEndpointSoap12" binding="tns:XYZEndpointSoap12">
<soap12:address location="http://xyzg2g/BPM/xyz.asmx" />
</wsdl:port>
With another jax-ws service, this configuration works - there was only one soap:address hmm.
This is .NET WS.
Thank you
PS: I have read google results and closed mule issues but nothing works for this service.
I have checked and pattern:web-service-proxy has no problem rewrite all the addresses of a WSDL that contains both a soap:address and a soap12:address.
The issue could actually be due to the way you get the WSDL: with the HTTP inbound endpoint bound to http://localhost:8081 with no path (something I would advocate against: it's better to have a path), the WSDL is available at http://localhost:8081/?wsdl, not http://localhost:8081/xyz.asmx?wsdl.