i'm using a PHP client for consume a testing web service, I've written my code with the native PHP Soap client and with nusoap library, but get same error.
The response of operation is:
[faultcode] => SOAP-ENV:Server
[faultstring] => Procedure 'xxx' not present
If i use the $client->__getFunctions() it shows correctly the functions, but i don't understand the fault, in many sites recommends disable WSDL caching, but still failing with this changes.
WSDL File used, PHP code for webservice and images folder:
https://drive.google.com/open?id=0BxjxYDI011PdNzBBYlBza1VBY0E
List of functions response (no libraries):
Image name: native.png
Nusoap response (calling function):
Image name: response.png
Additionally i test that with SoapUI but get same response with this status: HTTP/1.1 500 Internal Service Error
I test that client with this webservice with no problems:
http://www.xignite.com/xquotes.asmx?WSDL
Then the code seems to be correct, but...
I need to know if my code has an error, the wsdl definition(i don't any access to server, only this file), or something else, I appreciate any information.
In response.png for your Request, your SOAPAction should point to 'getBankList', not 'http://...' (which points to the service). I'm not sure where you are setting this in the code, but the SOAPAction should point to the wsdl:service name="" value, not the actual running service.
Also, looking at the xignite WSDL, it doesn't have a getBankList function, or in fact the word 'Bank' in it at all. Are you sure you're pointing to the correct WSDL?
HTH, Jim
Related
I have a VERY simple PHP code:
<?php
$soap = new SoapClient('https://rev-int.api.us.fleetmatics.com/Vehicle/SageQuest/VehicleService.svc?wsdl', array());
var_dump($soap);
When I copy that URL into my browser it loads just fine, with no redirects or anything:
$soap = new SoapClient('https://rev-int.api.us.fleetmatics.com/Vehicle/SageQuest/VehicleService.svc?wsdl
But when I execute that PHP script I get the following error after a PHP timeout:
Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing WSDL: Couldn't load from 'http://rev-int.api.us.fleetmatics.com/Vehicle/SageQuest/VehicleService.svc?wsdl=wsdl0' : failed to load external entity "http://rev-int.api.us.fleetmatics.com/Vehicle/SageQuest/VehicleService.svc?wsdl=wsdl0"
Notice the response URL is http://rev-int.api.us.fleetmatics.com/Vehicle/SageQuest/VehicleService.svc?wsdl=wsdl0 which is very similar but not quite accurate. If I search the working WSDL for that given URL I find it at the top:
That said, every URI points to HTTP instead of HTTPS, but if we simply change this in our browser the page loads just fine.
So the question becomes: when we create a PHP SoapClient, can we force all URIs to follow HTTPS regardless of the protocol specified in the WSDL?
The WSDL can stand by itself and contain everything inside, or it can use imports to bring in content from other locations (it usually happens with XSD schemas).
If it imports things, those imports need to be resolved by the client. If they can't be resolved, either because the location is wrong, or the protocol is wrong, or whatever, then the client bails out, because it needs a complete WSDL to understand the service's contract and how to call it, not just the parts it could load.
So you have two options:
Contact the provider of the service and ask them to fix it so all imports can be resolved.
If you can download the WSDL and all the resources it tries to import, by opening in browser and changing the protocol to https, you can save them all locally on disk in the same folder. Assuming you end up with a file named VehicleService.wsdl for the WSDL itself, and VehicleService.xml for the file you got from http://rev-int.api.us.fleetmatics.com/Vehicle/SageQuest/VehicleService.svc?wsdl=wsdl0 somehow, you can then change the WSDL to import this local file with <wsdl:import .... location="VehicleService.xml" /> instead of what it does right now. Then you can feed this local WSDL to your client, and because now everything is in the same folder, it should work.
I have tried all the answers given in the following threads.
[1] Magento SOAP API - PHP Exception thrown for login method call: "looks like we got no XML document"
[2] Magento SOAP API - PHP Exception error “looks like we got no XML document”
I am able to load the WSDL in the browser and the WSDL URL is in this format
http://www.foo.com/api/v2_soap/?wsdl
This is the error am getting in the console:
looks like we got no XML document .
This error is usually related to Magento setting up a SoapServer, and not to your SoapClient call, which in turn means that it's usually a problem of your server not being able to fetch the WSDL. Connect toyour server via ssh and issue the following command (with your URL)
$ curl -i 'http://www.foo.com/api/v2_soap/?wsdl'
This will output the HTTP headers, and the response. My guess is the response isn't valid XML (includes debugging, or whitespace), curl couldn't connect to the server (because your host's networking is wrong) or your WSDL points to other WSDLs that can't be connected to.
Solve that problem, and you'll be good to go.
The API I am supposed to target uses this WSDL(http://www.gotoworkspace.com/us/paas/s3PaaS.wsdl), though when I test it in SoapUI I receive no operations. Oddly enough when I make a request on my own client I get a 303 response telling me to redirect to the following - http://www.gotoworkspace.com/us/paas/PaaSServer.php
Questions:
1. What do you think is going on?
2. What is my endpoint and namespace?
SoapUI is not handling the redirect correctly.
Try using http://www.gotoworkspace.com/us/paas/PaaSServer.php?wsdl for your WSDL instead.
We have the following scenario:
Setup a web service - wsdl and all, supposed to be listening for data sent by the client, receive it, do stuff with it and send a response as 'ok' if everything is okay, and 'false' if something died
Client side runs a script that generates the soap/xml request bit, creates a soap client and sends the request to the wsdl.
Client side gets a result indicating that the data was not processed by the web service - false. And the web service receives no data at all.
I don't have access to the web service - it is someone else's. The generated request body (the whole etc.) is being generated correctly - when I send it through soapUI it works, but not through my php soap client.
I tried using the built-in Soap with the SoapClient, __doRequest, __call (kind of tried everything), but nothing happens - still getting 'false' result. I tried re-writing the NuSoap in order to work with Soap 1.2, but still only a 'false' result for something that returns true.
So, I was wondering if someone can answer me the following questions:
on the server do I need something specially install to get it to work with Soap 1.2 ?
When the client has to send data to the web service's function do I use __doRequest or __call? Or something else?
According to my php.ini the server header_accept values do not have the application/soap+xml that is needed to work with soap 1.2 - could this be the problem, if yes - back to question 1, or how can I add the type to the header_accept?
EDIT:
$client = new SoapClient(
"the_wsdl_url_correct_for_sure.wsdl",
array(
'soap_version' => SOAP_1_2,
'trace' => 1,
)
);
$result = $client->__doRequest(
$the_var_i_use_to_store_the_soap_xml_thingie_that_works_through_soapUI_so_it_is_correct, $location,
$the_function_I_try_to_call,
"1.2"
);
For $location I am the namespace of the action (the function I'm trying to call and send the data from the first parameter to). And for the action/function I tried using just the name of the action as it's defined in the namespace, and using the full path with the "full_namespace/action"
Should I use __doRequest or __call when I'm trying to send the data to the WSDL?
EDIT2:
The request I'm sending is:
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" xmlns:soapenc="http://www.w3.org/2003/05/soap-encoding" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<env:Header/>
<env:Body>
<ns2:FunctionName xmlns:ns2="namespace_of_the_service">
<arg0>
<data1>Some data</data1>
</arg0>
</ns2:FunctionName>
</env:Body>
</env:Envelope>
More about the problems from this can read in my previous post:
PHP Soap Client - sending the wrong headers "soapenv:VersionMismatch"
The way you ask your question(s) here does not work well with Stackoverflow, I leave this here as a comment, not as an answer, just to show you that you don't go much ahead in getting these answerwed:
on the server do I need something specially install to get it to work with Soap 1.2 ?
No, a recent PHP version with the Soap extension is enough.
When the client has to send data to the web service's function do I use __doRequest or __call? Or something else?
That depends on the mode (WSDL or not) and as well on what you want to do. What WSDL is and what WSDL mode is, please read the whole Soap book in the PHP manual from start to end and as well I suggest because the documentation is not perfect you make yourself comfortable with what WSDL is and some third-party WSDL SoapClient examples which both you can find through the internet search engine of your choice. For __doRequest please see the manual what you can do with it. For __call the manual clearly says for what it is for and that it is deprecated and so you're probably looking for __soapCall instead.
According to my php.ini the server header_accept values do not have the application/soap+xml that is needed to work with soap 1.2 - could this be the problem, if yes - back to question 1, or how can I add the type to the header_accept?
That might be according to your php.ini, I mean you can write in there what you want, however according to PHP documentation itself there is no header_accept PHP ini directive. Please double check what is written in the PHP.ini and then double-check with the documentation of that directive inside the PHP manual if or if not it controls what you like to control - or if already set - that it does not set something that might stand in your way.
As far as I know for a SoapClient you don't need to set any PHP ini based header accept directive (even next to that that one actually does not exist!) to get it working. It works with the default configuration, so you don't need to add anything.
Which makes me wonder why you actually ask? What makes you think you would need to add anything to that (by you not further specified) ini setting?
We have a WCF service under an SSL Web Server installed in IIS. The web service was created with .NET 3.5 and WCF 3.0. We can access it with a .NET 3.5 client without problems.
Let's call the URL where the service is published something like:
https://my-server.com/testservice.svc?wsdl
We need to make a proof of concept to check if it's possible to access it with a PHP client. I've tried to use NuSOAP or the standard SoapClient of PHP but in both cases i get an exception. Here is my code:
<?php
$wsdl = 'https://my-server.com/testservice.svc?wsdl';
$client = new SoapClient($wsdl);
?>
It returns me an exception with this message:
Error:sendSms: SoapFault exception: [WSDL] SOAP-ERROR: Parsing Schema: can't import schema from 'https://my-server.com/testservice.svc?wsdl' in C:\localhost\test.php:5 Stack trace: #0 C:\localhost\test.php(5): SoapClient->SoapClient('https://my-serv...') #1 {main} "
Any ideas? What am I doing wrong?
http://weblogs.asp.net/gunnarpeipman/archive/2007/09/17/using-wcf-services-with-php.aspx
I am currently investigating this as well, hopefully this helps you
everything looks correct and it seems like it would work, certainly that is the point of SOAP to be able to make calls from other languages.
Maybe try using NuSoap or PEAR Soap_Client so you can set a break-point or just dump the raw output from the server? If the server is returning an error, that might give you some clues. If the server seems to be outputting valid SOAP response, it maybe could be that your web service has some complex object types for args or return values that causes PHP to choke?
According to this question you must grant access rights to the IIS_IUSERS for the directory 'C:/Windows/Temp'.
Late to the party here, but make sure when you set up the WCF service with AddServiceEndpoint, you are using BasicHttpBinding not WebHttpBinding.