How to create an adapter for the TFS Integration Platform - Part X: Reflection on SharePoint

Note: This post is part of a series and you can find the rest of the parts in the series index.

This post is not as technically heavy as most of the series—it’s more of a reflection on what I learned about integrating with SharePoint. This information holds true for any type of work with SharePoint, not just if you’re creating adapters.

What I used

For the WIT adapter, I used the lists.asmx web service, which allows you to work with list items. With the VC adapter, I used both the lists.asmx and copy.asmx web service—and even ended up using some WebDAV methods too.

You may be asking: Why did I use lists.asmx with VC? Because of SharePoint Rule #1"Everything is a list"—even a document library. The copy web service allows for files to be uploaded to SharePoint.

My goal was to use only web services, one of the three ways you can interact with SharePoint (the others being WebDAV and the API). The API is better than web services in every way—faster and more feature-complete—but has a serious limitation: you must run the application using the API on the same server where SharePoint is installed. This makes it useful mainly for tools used by SharePoint admins or web components, like web parts. WebDAV is a standard for talking to web services but is generally regarded as a poorer implementation compared to the web services because it does less.

In the end, I hit a bug with file deletion in the VC adapter when using the web services. After much troublehooting, I gave up and used WebDAV for that function instead.

What I learnt

If I rewrote these adapters, I’d use mostly WebDAV and rely on the lists.asmx web service only for metadata tasks—not for manipulation. That’s because, while WebDAV does less than the web services, it handles all the fundamentals (create, update, delete) faster and more reliably. The lists.asmx web service would still be useful for tasks like:

This approach would let me drop the copy web service entirely, resulting in faster adapters and cleaner code in less time.