Pear::soap

[felix]

Hi,

Has anyone here tried to use the PEAR::SOAP library to send zimbra the soap requests? I almost have it working, however i am having trouble with the authToken, which I can retrieve without problem. However, to then use the token it seems I must create a

<header><context><authToken>...</authToken></context><header>

header, and I can't figure out how to create this nested structure using the PEAR::SOAP function (SOAP_Header('authToken','',$ret["authToken"])

Anyone managed to get this working? or do I have to modify the PEAR library itself? Thanks!

-Felix

[KevinH]

Did you get this working? I saw your post on a different thread.

[felix]

Hi Kevin,

I did actually get this working, and have the PEAR::SOAP module working nicely; happily I can probably answer any questions that anyone has regarding using this module with zimbra.

One of the largest problems I had however was with the parsing of the xml response; it seems that all the open source php SOAP packages are not designed in any way to handle responses with attributes in them. In fact, PEAR::SOAP was nearly useless at this, returning only a mysterious array with only values in it with no clue as to what they mean ([0]=TRUE, [1]=5, [2]=200) In order to handle this I ended up making a modification to the module to parse the response using a different method (not too happy about this though).

Just curious - the way that zimbra returns responses using mainly attributes, is this outside the usual way people expect SOAP responses?

[mlodick]

felix,

I ran into the same problem with Pear::SOAP that you did, in that the responses were basically useless. I upgraded PHP to PHP5, and I'm trying to use the new PHP SOAP extention, with limited success.

Does anyone have any working examples using the new PHP5 extention?

-Mike

[KevinH]

Originally Posted by felix

Just curious - the way that zimbra returns responses using mainly attributes, is this outside the usual way people expect SOAP responses?

We use attributes to save space/size of the responses rather than <attr>value</attr> we just have attr=value, not much but it adds up. IMHO this is a pretty bad bug in the PHP handling of SOAP responses if it can't repersent the attrs in a meaningful way.

[ljm]

The discussion above isn't so much about bugs in the PHP handling of SOAP responses. It's more about the conversion of the SOAP response into an associative array.

By way of example, with a SOAP response like this:
<account>
<givenName>John</givenName>
<sn>Smith</sn>
</account>
the array that PHP's soap libraries return is:
[account] => Array (
[givenName] => John
[sn] => Smith
)
So the client can reference $account['givenName'] and $account['sn'].

But zimbra's SOAP responses are more often like this:
<account>
<a n="givenName">John</a>
<a n="sn">Smith</a>
</account>
which get returned as an array like this:
[account] => Array (
[a] => Array (
[15] => John
[39] => Smith
)
)
Here, $account[15] and $account[39] aren't so useful - the numbers are arbitrary.

Both PEAR::SOAP and PHP5's soap extension convert the soap xml response into an associative array based on element names.

Because the zimbra api often uses attributes to distinguish elements, the arrays returned by these libraries aren't so useful.

It means that clients must parse and query the SOAP response xml and lose the convenience of the associative array.

I guess if the design tradeoff is network latency vs programmer convenience it's easy to pick a winner!

[KevinH]

I'd say $account[15] should be $account[givenName] I can't see a reason why those opaque numbers would make it very easy to use this library.

[ljm]

$account[15] isn't very useful at all! It's what you get from SearchAccountsResponse (for example).

Sorry for not expressing the above clearly - it might be easier with a code sample.

The only (small) point here is about idiom. In those parts of the zimbra api where attributes are used extensively, programmers should expect to use xpath or SimpleXML on the soap responses.

<?php //PHP5

$soap_response_style_a = <<<XML
<account>
<givenName>John</givenName>
<sn>Smith</sn>
</account>
XML;

$soap_response_style_b = <<<XML
<account>
<a n="givenName">John</a>
<a n="sn">Smith</a>
</account>
XML;

$xml_a = simplexml_load_string($soap_response_style_a);
$xml_b = simplexml_load_string($soap_response_style_b);

print "With style 'a', the associative array returned by SoapClient->__soapCall():\n";
print "See: http://au.php.net/manual/en/function.soap-soapclient-soapcall.php\n";
print "looks a bit like this (useful):\n";
print_r($xml_a);

print "With style 'b', (used in zimbra's <SearchAccountsResponse>)\n";
print "The associative array returned by SoapClient->__soapCall()\n";
print "looks a bit like this (useless):\n";
print_r($xml_b);
?>

This script will display:

With style 'a', the associative array returned by SoapClient->__soapCall():
See: http://au.php.net/manual/en/function...t-soapcall.php
looks a bit like this (useful):
SimpleXMLElement Object
(
[givenName] => John
[sn] => Smith
)
With style 'b', (used in zimbra's <SearchAccountsResponse>)
The associative array returned by SoapClient->__soapCall()
looks a bit like this (useless):
SimpleXMLElement Object
(
[a] => Array
(
[0] => John
[1] => Smith
)
)

[mlodick]

It seems to just be an issue with php, both PEAR::Soap and php5's soap extention.

My work around, for php5:
1. Create the SoapClient object with 'trace' => true as an argument
2. Call the soap function and discard the result.
3. Use the __getLastResponse() method to get the raw soap response
4. Do a string replace, replacing 'soap:' with something else (I use 'soap_', but YMMV) because the colon (':') will break the next step
5. Use the SimpleXML class to turn the response into an object which can be handled easily.

I'm assuming that this is a pretty big flaw in PHP's SOAP support, unless for some reason they don't think you should have attributes in the SOAP response - in which case, I suppose it's a feature.

Mike Lodick

[KevinH]

Anybody file a bug with the PHP folks on this?