> It's not actually the PHP/zval 'type', it's the the type name
> as it is serialized according to the wsdl rule.
>
> Thus if you have something like:
>
> <message name='EchoRequest'>
> <part name='body' element="tns:SOAPStruct"/> </message>
> <message name='EchoResponse'>
> <part name='return' element="tns:SOAPStruct"/> </message>
> <message name='EchoStringRequest'>
> <part name='body' element="tns:EchoStringType"/>
> <part name='header' element="tns:credentials"/> </message>
> <message name='EchoStringResponse'>
> <part name='return' type='xsd:string'/> </message>
>
> <portType name='EchoStringPortType'>
> <operation name='EchoString'>
> <input message='tns:EchoStringRequest'/>
> <output message='tns:EchoStringResponse'/>
> </operation>
> <operation name='EchoAny'>
> <input message='tns:EchoRequest'/>
> <output message='tns:EchoResponse'/>
> </operation>
> </portType>
>
> That will work fine, but this:
>
> <message name='EchoRequest'>
> <part name='body' element="tns:SOAPStruct"/> </message>
> <message name='EchoResponse'>
> <part name='return' element="tns:SOAPStruct"/> </message>
> <message name='EchoStringRequest'>
> <part name='body' element="tns:EchoStringType"/>
> <part name='header' element="tns:credentials"/> </message>
> <message name='EchoStringResponse'>
> <part name='return' type='xsd:string'/> </message>
>
> <portType name='EchoStringPortType'>
> <operation name='EchoString'>
> <input message='tns:EchoRequest'/>
> <output message='tns:EchoResponse'/>
> </operation>
> <operation name='EchoAny'>
> <input message='tns:EchoRequest'/>
> <output message='tns:EchoResponse'/>
> </operation>
> </portType>
>
> will not (only the first operation, EchoString, will get
> picked up).
> That having been said, your wsdl looks like it conforms with
> this rule.
That's it ! I've modified the type of the input parameters like this :
<types><xsd:schema elementFormDefault="qualified"
targetNamespace="urn:cms">
[...]
<xsd:element name="string1">
</xsd:element>
<xsd:element name="string2">
</xsd:element>
[...]
</xsd:schema>
</types>
<message name="listeRubriquesResponse"><part name="parameters"
element="tns:Rubriques" /></message>
<message name="listeRubriquesRequest"><part name="parameters"
element="tns:string1" /></message>
<message name="listeGroupesResponse"><part name="parameters"
element="tns:Groupes" /></message>
<message name="listeGroupesRequest"><part name="parameters"
element="tns:string2" /></message>
<portType name="cmsserverPortType">
<operation name="getRubriques"><input
message="tns:listeRubriquesRequest"/><output
message="tns:listeRubriquesResponse"/></operation>
<operation name="getGroupes"><input
message="tns:listeGroupesRequest"/><output
message="tns:listeGroupesResponse"/></operation>
</portType>
[...]
And it works now !
Michael> You're right concerning dotnet SOAP clients and RPC/encoded (I
got mixed up with somethng else), but as far as InfoPath is concerned,
it does refuse RPC/encoded responses :
Limitation
Explanation
InfoPath can access only Document/Literal SOAP messages InfoPath
accesses only Web services that are described using
the
Document/Literal style in their WSDL. The WS-I Basic
Profile requires Document/Literal type Web services and prohibits the
use of RPC/Encoded Web services.
See
http://msdn.microsoft.com/office/understanding/infopath/techarticles/def
ault.aspx?pull=/library/en-us/odc_ip2003_ta/html/OfficeInfoPathWebServic
eASPNET.asp#officeinfopathwebserviceaspnet_designconsiderations
Thanks to you both for your explanations.
Guillaume.
--
PHP Soap Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
