[Fedora-suds-list] A couple of questions...

[Joshua J. Kugler]

On Tuesday 13 July 2010, Erik Cederstrand elucidated thus:
> Hello
>
> I'm developing an interface for Microsoft Exchange using the
> SOAP-based EWS webservice. It's been a pretty rough journey until
> now. I've encountered four problems I'd like an opinion on.

I've tried to get EWS working with SOAP, and haven't even gotten as far 
as you have.  How did you get the form POST/NTLM auth working?  Just 
about every time I tried that, it would hang.

As to your questions, I look forward to answers.  I may have one answer, 
if I'm understanding the question correctly, but I'm not 100% sure.

> 1: EWS has a service called FindItem(). This service need an
> attribute in the XML like this:
>
> 	<SOAP-ENV:Header/>
> 	  <ns1:Body>
> 	    <ns2:FindItem Traversal="Shallow">
>
> But I'm unable to supply this attribute using the FindItem()
> constructor. Ticket #21 describes this and contains a patch, but it's
> been open for 2 years. Is anyone willing to commit?

If I'm understanding this correctly, you can specify attributes via a 
notation like:

finditem_object._Traversal = "Shallow"

But I could be way off.

> 2: The same service has a number of optional elements that affect the
> returned response, e.g. a CalendarView element to restrict the start-
> and enddate of the items returned:
>
> 	<SOAP-ENV:Header/>
> 	  <ns1:Body>
> 	    <ns2:FindItem Traversal="Shallow">
> 	      <ns2:CalendarView startdate=... enddate=...>
>
> Suds currently ignores these elements when I supply them to
> FindItem(). Is this intentional, or is there a workaround? I have a
> patch to solve the problem (no bug report created yet).

Most likely related to #1, as startdate and enddate would be specified 
the same way as Traversal.

> 3: The WSDL that Exchange supplies doesn't contain a <wsdl:service>
> element. This probably makes the WSDL invalid. Currently I work
> around this by adding missing parts and storing the file locally, but
> I wondered it is desirable to add support for supplying this
> information using the service, port and location (and possibly a new
> "binding") arguments to Client()?

Yeah, Jeff and I had a discussion about that a while back.  For whatever 
reason Microsoft doesn't have Exchange automatically add the server's 
URL.  So, yes, you can add it to a file locally, or you can hack up 
some code to add it to the file.  With the upcoming Suds plugins, there 
might be an elegant way to do all this.

> 4: Using the XSD from Exchange, Suds generates XML for some elements
> like this:
>
> 	<ns5:Path FieldURI="item:ItemClass"
> xsi:type="ns5:PathToUnindexedFieldType" />
>
> But Exchange rejects it (even though it should be valid XML according
> the the XSD) and needs this instead:
>
> 	<ns5:FieldURI FieldURI="item:ItemClass"/>
>
> (FieldURI has type PathToUnindexedFieldType, and inherits from the
> Path element). I think this is what is called doc-lit format(?). To
> work around this, I have modified the XSD to force the latter to be
> generated by suds. Is there a way to do this without modifying the
> XSD? Would it be difficult to patch Suds to optionally generate the
> latter format?

Count on MS to mess up a standard. :)  I'll have to leave this one for 
Jeff, or someone else much more versed in SOAP.

j


-- 
Joshua Kugler
Part-Time System Admin/Programmer
http://www.eeinternet.com
PGP Key: http://pgp.mit.edu/  ID 0x73B13B6A