je développe un service web utilisant soap et un fichier wsdl. Le
premier développement a lieu sur WAMP. Le résultat est conforme à mes
attentes. Puis j'ai déplacé mon service sur une plateforme de test sur
debian avec php 5.2.3. Les résultats sont les mêmes. J'ai donc déplacé
le service sur le serveur de production. Surprise ! L'enveloppe SOAP
est modifiée : un espace de nommage a été rajouté :
"xmlns:ns2="http://xml.apache.org/xml-soap" et la syntaxe de retour
n'est pas la même qu'auparavant. Mon client ne récupère pas la même
structure... En plus, l'espace de nommage ajouté ne correspond plus à une page existante
Ayant eu une longue discussion avec l'hébergeur, nous ne sommes pas arrivés à localiser d'où venait précisément le problème.
Il est certain que c'est bien PHP qui renvoie une structure modifiée
mais je n'arrive pas à savoir quel élément n'est pas à jour.
en prod : PHP Version 5.2.3-0.dotdeb.0 build du Jun 4 2007 10:57:08
en test : PHP Version 5.2.3-0.dotdeb.1 build du Jun 1 2007 15:09:44
je bosse régulièrement avec SOAP et je n'ai jamais eu ce problème.
Pour info, j'ai un serveur avec la même version que toi de PHP.
Et un autre avec la version 5.0.4 sur une Debian aussi et Apache2.
Je n'ai jamais observé de modification de mon wsdl...
L'espace de nommage, c'est une chose, mais la structure...c'est bizarre.
Sinon heu, un espace de nommage ne correspond jamais à une page existante. Ou rarement du moins. Ca ne sert pas à ça, c'est une référence, c'est tout. Cela sert à confiner une partie de tes éléments dans cet espace de nom.
Bref, ce n'est pas très grave.
Mais ton problème est bizarre...peux-tu montrer ton wsdl ?
Salut ! merci de t'intéresser à mon problème.
"un espace de nommage ne correspond jamais à une page
existante. Ou rarement du moins." => Ok. Mais c'est dommage, car c'est pratique pour ne pas coder trop mal.
<soap:address location="...monServiceWeb sur https..."/>
</service>
</definitions>
Un client écrit en PHP me renvoie :
* sur le serveur de test (debian, apache 1.3 et PHP 5.2.3) :
object(stdClass)#1 (3) {
["enMaintenance"]=>
bool(false)
["reussite"]=>
object(stdClass)#4 (1) {
["etat"]=>
bool(true)
}
["date"]=>
string(25) "2007-07-06T10:53:56+02:00"
}
* sur le serveur de prod (debian, apache 1.3 et PHP 5.2.3) :
array(3) {
["enMaintenance"]=>
bool(false)
["reussite"]=>
array(1) {
["etat"]=>
bool(true)
}
["date"]=>
string(25) "2007-07-06T10:53:54+02:00"
}
Voici où j'en suis arrivé :
+ php suhosin semble être impliqué dans une majorité de modifications, pour mon cas, mais il ne semble pas être le seul... De plus, c'est un module suffisamment important pour ne pas le désactiver.
Un cas similaire est présenté dans la documentation (mais j'ai mis un peu de temps à le voir) :
http://fr3.php.net/manual/fr/ref.soap.php commentaire de Darryl20-Jul-2005 08:46
résumé :
Quand on utilise un ComplexType dans le schéma WSDL, il faut ajouter une étape optionnelle afin d'obliger PHP SOAP à l'encoder correctement :
* définir une classe PHP comportant les différentes propriétés correspondant au type complexe du WSDL.
<?php
class MyComplexDataType {
public $myProperty1;
public $myProperty2;
}
?>
<complexType name="MyWSDLStructure">
<sequence>
<element name="MyProperty1" type="xsd:integer"/>
<element name="MyProperty2" type="xsd:string"/>
</sequence>
</complexType>
* Ensuite on initialise le serveur SOAP avec la structure :
<?php
$classmap array('MyWSDLStructure'> 'MyComplexDataType');
$server new SoapServer("http://MyServer/MyService.wsdl", array('classmap'> $classmap))
?>
* Enfin, on retourne une instance de la classe. Le serveur SOAP semble encoder correctement.
<?php
public function MySoapCall() {
$o = new MyComplexDataType();
$o->myProperty1 = 1;
$o->myProperty2 = "MyString";
return $o
}
?>
Bon usage !