sarat.devin...@gmail.com writes: > My current SOAP request sent via suds.client looks like this: > > <SOAP-ENV:Envelope (some name space URIs)> > <SOAP-ENV:Header /> > <SOAP-ENV:Body> > <ns5:saveModule> > <request xsi:type="ns3:SaveModule"> > <Module xsi:type="ns4:Module"> > <ModuleName xsi:type="ns1:string">Test</ModuleName> > </Module> > </request> > </ns5:saveModule> > </SOAP-ENV:Body> > </SOAP-ENV:Envelope> > > This request fails on my server. If i take the same XML request and massage > it and send it visa SOAPUI, it works fine. What I did was > > <soapenv:Envelope (some name space URIs)> > <soapenv:Header /> > <soapenv:Body> > <saveModule> > <request> > <Module> > <ModuleName>Test</ModuleName> > </Module> > </request> > </saveModule> > </soapenv:Body> > </soapenv:Envelope> > > As you see, I had to change SOAP-ENV to soapenv, modify node ns5:saveModule > to saveModule and also remove attributes such xsi:type to other child nodes
Looks as if you had a bad WSDL description of your service and a server which fails to honor elementary standard elements (of the "XML-namespace" standard, in particular). The XML-namespace standard dictates that the concrete namespace prefixes are (apart from some "xml" prefixes) insignificant; namespace prefixes are use only to refer to namespace uris and only these uris are relevant. Thus, a standard conform XML-namespace application should world with whatever prefix is used as long as they refer to the correct namespace uri. According to the standard, "xsi:type" is used when the underlying schema (in your WSDL) does not statically determine the type. In this case, missing type information is provided by "xsi:type". A standard conform application should not have problems with "xsi:type" attributes. Alternatively, the schema (in the WSDL) can assign types and "suds" will not generate "xsi:type" attribute (at least not in simple cases). > How can I , modify the request in above manner using suds.client. > Documentation suggests to use a plugin with Client using marshalled method. > But I was unsuccessful I cannot answer you concrete question. However, when you are working with a component that does not honor standards (this seems to be the case for your server component), it may not be possible to use (other) components developed against those standards. In your particular case, it might be necessary to generate the SOAP messages yourself - in the peculiar way, your server expects them - rather than use "suds". By the way: when I remember right, then "suds" supports some control over the namespace prefixes used. Apparently, servers not honoring the XML-namespace standard are not so rare. Fortunately, I never needed this feature but I think I have read something about it in the "suds" documentation. -- http://mail.python.org/mailman/listinfo/python-list