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.
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?
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).
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()?
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?
Thanks, Erik
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
Den 13/07/2010 kl. 19.18 skrev 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.
This may be specific to the Exchange server, but the one I'm interfacing uses standard HTTPS auth, but I will need NTLM auth working. Did your efforts involve a suds.transport.https.WindowsHttpAuthenticated() object as the transport argument to Client()?
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.
The problem is, I'm not building a finditem object. I'm supplying the elements contained in a finditem object directly to self.client.service.FindItem(...). Only required elements are recognized by this constructor.
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.
You're misunderstanding. The problem is I need to specify the CalendarView object as an argument in the self.client.service.FindItem(...) constructor to get it as a child of the FindItem element, but it's being ignored by Suds because it's optional according to the XSD. But it matters to my call.
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.
I tried a couple of strategies: 1) appending a service object to the wsdl object in the Client() constuctor, and 2) modifying the raw text when urllib fetches the file. I simply don't grasp the code Suds code involved, so I got nowhere fast with both approaches.
Erik
Den 13/07/2010 kl. 10.27 skrev Erik Cederstrand:
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?
This is now ticket #332.
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?
This one is still nagging me. Any ideas?
Thanks, Erik
-
Erik Cederstrand -
Joshua J. Kugler