How to reproduce:

I m using services and soap_server module to create the server:

Call the server like this:
like stated in wsclient_soap:

    try {    	
      $response = $client->__soapCall($operation, $arguments);
      return $response;
    }
    catch (SoapFault $e) {
      throw new WSClientException('Error invoking the SOAP service %name, operation %operation: %error', array('%name' => $this->service->label, '%operation' => $operation, '%error' => $e->getMessage()));
    }

On the server side an empty array of arguments arrives.

When calling the service like this:

    try {    	
      $response = $client->$operation($arguments);
      return $response;
    }
    catch (SoapFault $e) {
      throw new WSClientException('Error invoking the SOAP service %name, operation %operation: %error', array('%name' => $this->service->label, '%operation' => $operation, '%error' => $e->getMessage()));
    }

It works, the arguments are arriving correctly.

I know the operation is valid in both cases, I can mog entry in both functions mapped by services module. However only in the latter case the arguments effectivly arrive. I dont know why this doesnt work but changing it like demonstrated solves the problem.

Maybe as maintainer of this module you have a clue... Thanks in advance.

CommentFileSizeAuthor
__soapcall-not-passing-arguments.patch665 bytesdomidc

Comments

klausi’s picture

klausi
he/him||they/them
Primary language German
Location 🇦🇹 Vienna
commented
Status: Active » Fixed

Those calls are not equal, because the arguments are passed differently. __soapCall() splits up the arguments array into separate parameters, while directly calling the operation method passes the arguments array as is. Looks like your server implements a document/wrapped parameter scheme, which is unfortunately not supported by the PHP SOAP client. You need to wrap the parameters yourself, your operation has only one complex data structure as parameter that contains the actual parameters as properties.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

BarisW’s picture

BarisW commented
Status: Closed (fixed) » Active

Is there a way to add this as a setting on the service definition page? I'm having the same issue and this patch solves my problems as well. If I'm only using one service, is there a reason not to apply this patch?

klausi’s picture

klausi
he/him||they/them
Primary language German
Location 🇦🇹 Vienna
commented

As said in #1: just wrap your parameters in an additional array() and you should be good.

// Old
$result = $service->operation($param1, $param2);
// New
$result = $service->operation(array($param1, $param2));
BarisW’s picture

BarisW commented

Hi klausi,

thanks for your reply. However, your suggestion does not work.
$service->OphalenBouwperioden(array($woningtype))

SOAP-ERROR: Encoding: object has no 'codeWoningtype' property in WSClientSOAPEndpoint->call()

I have to feed it an associative array to fix it:
$service->OphalenBouwperioden(array('codeWoningtype' => $woningtype))

klausi’s picture

klausi
he/him||they/them
Primary language German
Location 🇦🇹 Vienna
commented

Ah, of course. Yes, that is needed for complex parameters.

BarisW’s picture

BarisW commented

What if we check for the version of the SOAP client (or if this server setting has nothing to do with the SOAP version, just add a setting for this in the client settings interface)?

OLD

    try {
      $response = $client->__soapCall($operation, $arguments);
      return $response;
    }

NEW

    try {
      if ($client->_soap_version == 1) {
        $arguments = array($arguments);
      }
      $response = $client->__soapCall($operation, $arguments);
      return $response;
    }

This works for me, not sure if it breaks other clients. The good thing about this is that I can still your your modules interface to define my field settings, instead of having if to define them in code.