I am developing a Soap client with Suds, and I have a problem. I create the client and just print it to know the available methods:
wsdl_url='http://ws04.iula.upf.edu/soaplab2-axis/typed/services/tokenization.freeling_tokenizer?wsdl'
FL_ws=Client(wsdl_url)
print FL_ws
And my output is (I deleted some parts to ease reading):
Ports (1):
(freeling_tokenizerPort)
Methods (11):
clear(ns2:jobId jobId, )
describe()
getLastEvent(ns2:jobId jobId, )
getResults(ns2:jobId jobId, )
run(ns1:language language, )
runAndWaitFor(ns1:language language, )
Types (22):
ns1:RunAndWaitFor
ns1:appInputs
ns1:appResults
ns2:describeRequest
ns2:jobId
Note that there are many methods that have a missing attribute ate the end, for example: runAndWaitFor(ns1:language language, ). According to the WISDL, this missing attribute is a text, that may be given as direct data or as url:
<xs:complexType name="appInputs">
<xs:sequence>
<xs:choice id="input">
<xs:element name="input_direct_data" type="xs:string"/>
<xs:element name="input_url" type="xs:string"/>
</xs:choice>
<xs:element name="language">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="en"/>
<xs:enumeration value="es"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
Then, I am not sure how to call this method. In Perl, it works fine defining and input structure like this:
# Inputs structure
my $inputs = {
input_direct_data => "$input_direct_data",
language => "$language"
};
So I tried the following:
input = FL_ws.factory.create('ns1:appInputs')
input['input_direct_data']='The house is red.'
input['language']='en'
result=FL_ws.service.runAndWaitFor(input)
print result
But the xml generated by Suds is incorrect:
<ns1:Body>
<ns0:runAndWaitFor>
<language>
<input_direct_data>The house is red.</input_direct_data>
<language>en</language>
</language>
</ns0:runAndWaitFor>
</ns1:Body>
Since it puts input_direct_data under <language>. I found this post with a similar problem with XML, but their solution does not work for me. It seems to me that my problem is related to how Suds deals with the choice input, since it does not seem to accept input_direct_data as a parameter.
The error I got is always:
suds.WebFault: Server raised fault: 'Soaplab not able to process the input request: '
So it seems that the input is not reaching correctly the service…
Any ideas about how to solve this, or how can I figure out how Suds expect this input to be, will be very helpful.
Thank you very much for your help.
I have found a solution:
I was using the “typed” wisdl to create the Client, but, for some reason Suds is not able to get the parameters correctly from it. Then, I learnt that there was another “non-typed” wisdl available for the same service. Using it to create the Suds client, it is able to correctly get the complex parameters for the methods and I succesfully built the client.
The services I am trying to acces have been created with SoapLab. First I though that this issue with different WISDLs was related to how SoapLab creates them, but I am not an expert in SoapLab, only a user of these services, so I really don’t know what’s going on… On the other hand, I was able to create a perl client using the first wisdl, so maybe it is a problem with Suds.