Working with SharePoint 2010 Web Services
Recently I have been leveraging SharePoint 2010’s Web Services from an external application (not on the Microsoft stack), and ran into a couple items that didn’t seem very well documented for a developer who wasn’t already familiar with the inner details how SharePoint worked (e.g. myself).
The first roadblock that I ran into was trying to figure out how to authenticate with SharePoint and then make subsequent calls with some sort of authentication token. I learned that SharePoint’s login mechanism is setting a Cookie on the response header that contains the authentication token, unlike other APIs that I have worked with. Originally this baffled me a bit, as the HTTP response body only has the name of the Cookie, and the documentation does not really make note that you need to look in the response headers for the Cookie.
Unfortunately, this was coupled with leveraging Salesforce APEX classes via the SharePoint Authentication WSDL. When working with the APEX classes that Salesforce generates via the WSDL, there are two parameters on the class that you instantiate prior to invoking the method, inputHttpHeaders_x and outputHttpHeaders_x, that will not return any values unless you instantiate them (they are maps of the request and response headers) prior to invoking the method. This was pretty frustrating, as I didn’t realize this until digging around through some random documentation led me to it (and seems strangely unintuitive to purposely not set values, but I’m sure there is some good reason for it). This led to a lot of confusion as to where the Cookie was on the response until I discovered this tidbit.
After resolving that, I ran into another problem later when testing out the simplest API call I could find, GetLists.
Apex type not found for element List
Essentially what I discovered is that Salesforce’s parsing of the response is extremely picky, and the classes it generates off the WSDL aren’t always an exact match for the response coming back. If there is any difference in the SOAP XML it will throw this error. What we ended up doing was simply identifying the SOAP envelope and constructing and destructing it ourselves in lieu of trying to debug the generated classes and cryptic errors.
The last issue I had was trying to upload a file via the API, as I kept running into a security related error.
The security validation for this page is invalid. Click Back in your Web browser, refresh the page, and try your operation again
After doing more research than I thought was necessary, I finally happened upon a post that detailed what my issue was. I needed to set a SOAPAction header to the endpoint of the schema’s method I was invoking, in this case http://schemas.microsoft.com/sharepoint/soap/CopyIntoItems. In hindsight, taking a look at the example SOAP request for this method via http://
