I' ve a problem with Soap (I'm using it for the first time!).
I'm trying to solve a problem with SOAP, used to communicate between my site and another.
In SoapServer (on my site) I have a function called say_hello() that takes no argument and returns simply "hello", if I call it from a SoapClient, also with an argument, it works well.
The problem appears if the argument passed is "SELECT everythingyouwanthere FROM otherthingifyouwant". I don't know why but it returns "PHP Fatal error: Uncaught SoapFault exception: [HTTP] Not Found" (404 error).
This started to happen suddenly (or, at least, I don't know the causes). On the server PrestaShop is installed.
Thanks in advance!
P.S. Sorry for my bad english!
try to pass the argument through an array.
Instead of
...
$client = new SoapClient(WSDL);
$client->say_hello("SELECT everythingyouwanthere FROM otherthingifyouwant");
...
try
...
$client = new SoapClient(WSDL);
$client->say_hello(array("parameter_name" => "SELECT everythingyouwanthere FROM otherthingifyouwant"));
...
Related
When using the described in the Google Contacts API example simple.php, and the Google API PHP Client from GitHub, version 1.0.4-beta, I get the following error:
Fatal error: Call to undefined method Google_IO_Curl::authenticatedRequest()
However, when I change this line...
$val = $client_svc_contacts->getIo()->authenticatedRequest($req);
...to...
$val = $client_svc_contacts->getAuth()->authenticatedRequest($req);
...then it starts working again.
I am using version 1.0.4-beta unmodified except for the addition of the following line at the top of Client.php:
set_include_path(str_replace('/Google','',dirname(__FILE__)));
I recognize that simple.php was written for version 0.6, not v1+, but is the example just out of date compared to the version on GitHub? Or is there something wrong with my implementation?
Found a migration guide that had the answer ...
A new home for authenticatedRequest
The authenticatedRequest method has been moved from the io classes to
the auth classes.
So it appears that replacing getIo() with getAuth() was the correct course of action.
I am using a Zend_Soap_Client to call a web service. I am getting an exception from the error which I suspect is down to me not sending something along with the request:
Fatal error: Uncaught SoapFault exception: [Sender] SOAP-ERROR:
Encoding: object hasn't 'V24Flag' propert
Because it throws an exception I want to try view what is the actual request being sent, however because of the exception, I can not use Zend_Soap_Client->getLastRequest() to get the request (it returns null). Looking at the Zend_Soap_Client->getLastRequest() its a thin wrapper for soapClient->__soapCall() which I'm not sure how to dig deeper from.
Your problem is actually slightly different to what you think it is. The reason Zend_Soap_Client::getLastRequest() returns NULL for you is that no request was ever made: the error is being thrown at the stage where the request internally is being compared against the WSDL you are using. So the method is perfectly correct to return NULL.
As to how to form the parameter for your SOAP call so this error isn't thrown, I can't be of much greater help right now (I expect it depends partly on the services you are integrating with), but there's a userland answer on the php.net page for SoapClient::__soapCall() which may point you in a fruitful direction. Essentially, some people seem to have got somewhere by doing a deep conversion of an array structure into stdClass objects. That doesn't seem to be the whole story (it isn't for the issue I'm currently investigating), and indeed this may be down to a bug in PHP, but I hope it helps you towards an answer.
How about
try {
$client = new Zend_Soap_CLient();
$client->doSomething($params);
} catch(SoapFault $f) {
echo $f->getTraceAsString();
}
Btw. Zend_Soap_Client->getLastRequest() wraps SoapClient::__getLastRequest();
try
{
$client = new \SoapClient($wsdlUrl, array(
'cache_wsdl' => 0, 'exceptions' => true, 'trace' => true));
$client->getPage($parameter);
}
catch(\Exception $e)
{
die("exception");
}
Okay this is what executes the SOAP request. $wsdlUrl holds the WSDLs URL and $parameter keeps an XML document.
And everything works like a charm!
Now I just add few more nodes to the XML document in $parameter and I get a fatal error.
This is not so weird necessarily, but what is weired is the combination of following three observations:
1) exceptions is set to true .... but no Exception is thrown / this was b/c I forgot to place a backslash before Exception in the catch statement.
2) instead an error is logged:
PHP Fatal error: SoapClient::SoapClient():
'uri' option is required in nonWSDL mode in /var/w[...]
3) but the WSDL url is provided and of course valid, as all works again just fine after skipping the adding of the new nodes. they don't affect the wsdl parameter.
Okay, I tracked down the source of the problem. There is no satisfying answer really to that question but few things to learn! :)
The important thing is that the request has been sent and processed by the SOAP server.
But the server responds with an error.
So, obviously, even though a fatal error regarding no wsdl and no connection parameter is triggered doesn't mean no request has been sent - which is very counter logical in my opinion b/c if no wsdl is provided and no connection params as well, then how could the request be executed?
EDIT
There is another bug in the code. I forgot to place a backslash before Exception! Without it's not referring to the Exception class.
Then an exception is thrown and caught.
I am trying to make a service call to a php function from flex, through Zend AMF. Most of the functions get called fine, but for one particular function, it throws the following exception:
InvocationTargetException:There was an
error while invoking the operation.
Check your operation inputs or server
code and try invoking the operation
again.
Reason: Fatal error: Call to a member
function getInvokeArguments() on a
non-object in
D:\wamp\www\ZendFramework\library\Zend\Amf\Server.php
on line 328
I am not able to debug through this - has anyone faced any issue like this before, or have any ideas how this can be debugged?
At a quick glance through ZFW's source, this appears to be a bug on their framework.
// There is no check if $this->_table[$qualifiedName] is an object, implements an interface, extends a class, only if it's set (the key exists).
$info = $this->_table[$qualifiedName];
$argv = $info->getInvokeArguments(); // Here's when you get the error.
Source: http://framework.zend.com/code/filedetails.php?repname=Zend+Framework&path=/trunk/library/Zend/Amf/Server.php
I looked in their bug tracker and haven't found anything related to this, perhaps you should open a new issue?
Additionally, you can debug the problem by grabbing the message that Flex is sending to the PHP client and making a test case out of it.
We finally realized that this was a problem in the flex project setup - don't know exactly what it was, but once we deleted and created the project again, things started working fine!
I'm trying to call a function via a SOAP webservice. The following code is run:
$return_soap = $this->soap->__soapCall($soap_function, $params);
I have also tryed:
$return_soap = call_user_func_array(array($this->soap,$soap_function),$params);
The headers are good, and i'm sending the following parameters:
$params = array('customer_info'=>array_values( 'name'=>'Stephen de Tester',
'i_parent'=>12695,
'iso_4217'=>'EU',
'i_customer_type'=>1,
'opening_balance'=>'10.00',
'i_customer_class'=>1));
i have tryed it without array_values and a bunch of other combinations. I always get the following message:
( [error] => SOAP-ERROR: Encoding: object hasn't 'customer_info' property )
However if i try a webservice call without parameters it all seems to work perfectly...
Could you guys help me in the right direction?
Could you supply the url to the WSDL file for the service? I'm not quite sure from the error but it's either saying that you haven't supplied a customer_info property or that you've supplied a customer_info property on a method that doesn't accept that property. Either way a peek at the WSDL should help make it clearer.