I am trying to implement an existing webservice with Spyne. I have a function that takes two parameters, for which the WSDL should look like this:
<wsdl:types>
<xs:schema targetNamespace="http://example.com/" elementFormDefault="qualified" >
<s:element name="getData">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="login" type="s:string"/>
<s:element minOccurs="0" maxOccurs="1" name="password" type="s:string"/>
</s:sequence>
</s:complexType>
</s:element>
[...]
My code contains the following decorator for this function:
@rpc(String(min_occurs=0, max_occurs=1, nillable=False),
String(min_occurs=0, max_occurs=1, nillable=False),
_returns=Unicode)
def getData(self, login, password):
return 'data'
Which produces this WSDL:
<wsdl:types>
<xs:schema elementFormDefault="qualified" targetNamespace="http://example.com/">
<xs:complexType name="getData">
<xs:sequence>
<xs:element minOccurs="0" name="login" type="xs:string" />
<xs:element minOccurs="0" name="password" type="xs:string" />
</xs:sequence>
</xs:complexType>
[...]
So instead of an element containing a complexType I just have a bare complexType. This difference causes issues with clients that are compatible with the existing implementation. Is there a way to wrap the complexType in an element using Spyne?
Spyne's wsdl should contain both:
<xs:complexType name="getData"> (...) </xs:complexType>
and
<s:element name="getData" type="tns:getData">
Having complexType inside element is equivalent to having it outside with proper referral like this, so your parser should be able to cope with both forms.
If you don't have any control over the client, as that's often the case in such situations, you have no option but to patch Spyne. If you want to go that route, please join spyne ml (http://lists.spyne.io/listinfo/people) so we can talk.
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments