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 a technically heavy, like the most of the series, but more a reflection on what I learnt about integrating to SharePoint. This information will hold true for any type of work with SharePoint, not just if you are creating adapters.

What I used

For the WIT adapter I used on the lists.asmx web service, which allows you to work with list items. While with the VC adapter I used both the lists.asmx and copy.asmx web service and I ended up using some WebDav methods too. You may be asking why I needed 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 just web services, which are one of the three ways you can interact with SharePoint the other two being WebDav and the API. The API is better than web services in every aspect (it is faster and more feature complete) but has a serious limitation, you MUST run the application using the API on the same server as SharePoint is install on. It makes it really only useful for tools used by SharePoint admins or web components, like web parts. WebDav is a standard for talking to web services and is generally regarded as a poorer implementation compared to the web services because it does much less.

In the end I had a bug with file deletion in the VC adapter when using the web services. After much fighting, I gave up and used WebDav for that one function.

What I learnt

If I rewrote these adapters I would use mostly WebDav and only use the lists.asmx web service for meta information tasks rather than manipulation. This is because while the WebDav implementation does less, it does all the fundamentals (create, update, delete) and it does it faster and more reliable way than the list and copy web services. The lists.asmx web service would be used only for getting item ID’s, lists of items, files and folders and maybe renaming since WebDav can’t rename. This would allow me to drop the copy web service would give me faster adapters and cleaner code in less time.

I'm looking for a solution that's the inverse of yours: I have a set of work items that I'd like to copy to a SharePoint list. In particular, these are "migration" work items, and we'd like them to be copied to a SharePoint calendar list.

Unfortunately, I've been asked to make this a "no code" solution. I'm hoping to be able to make this a "somebody else's code" solution, but first I have to find "somebody else".

Thanks,
John Saunders

The TFS Integration Platform SharePoint adapters are two way adapters, so they could be used to write from TFS (or another system) to SharePoint. Nothing I can think of that would prevent them working with calendars either. Another option you may want to investigate is the SharePoint Holiday Loader I wrote: http://shl.codeplex.com/

[...] from Robert MacLean (part 1, part 2, part 3, part 4, part 5, part 6, part 7, part 8, part 9, part 10, Appendix A, and Appendix B) – This epic series of posts will probably become the must-have [...]

[...] How to create an adapter for the TFS Integration Platform - Part X: Reflection on SharePoint | SADev sadev.co.za/content/how-create-adapter-tfs-integration-platform-part-x-reflection-sharepoint – view page – cached 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 a technically heavy, like the most of the series, but more a reflection on what I learnt about integrating to SharePoint. This information will hold true for any type of work with SharePoint, not just if you are creating adapters. What I used For the WIT adapter I used on the... Read moreNote: This post is part of a series and you can find the rest of the parts in the series index. This post is not a technically heavy, like the most of the series, but more a reflection on what I learnt about integrating to SharePoint. This information will hold true for any type of work with SharePoint, not just if you are creating adapters. What I used For the WIT adapter I used on the lists.asmx web service, which allows you to work with list items. While with the VC adapter I used both the lists.asmx and copy.asmx web service and I ended up using some WebDav methods too. You may be asking why I needed 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 just web services, which are one of the three ways you can interact with SharePoint the other two being WebDav and the API. The API is better than web services in every aspect (it is faster and more feature complete) but has a serious limitation, you MUST run the application using the API on the same server as SharePoint is install on. It makes it really only useful for tools used by SharePoint admins or web components, like web parts. WebDav is a standard for talking to web services and is generally regarded as a poorer implementation compared to the web services because it does much less. In the end I had a bug with file deletion in the VC adapter when using the web services. After much fighting, I gave up and used WebDav for that one function. What I learnt If I rewrote these adapters I would use mostly WebDav and only use the lists.asmx web service for meta information tasks rather than manipulation. This is because while the WebDav implementation does less, it does all the fundamentals (create, update, delete) and it does it faster and more reliable way than the list and copy web services. The lists.asmx web service would be used only for getting item ID’s, lists of items, files and folders and maybe renaming since WebDav can’t rename. This would allow me to drop the copy web service would give me faster adapters and cleaner code in less time., How to create an adapter for the TFS Integration Platform - Part X: Reflection on SharePoint View page Tweets about this link Topsy.Data.Twitter.User['sharepointsa'] = {"photo":"http://a3.twimg.com/profile_images/295434947/iwlogo_normal.jpg","url":"http://twitter.com/sharepointsa","nick":"sharepointsa"}; sharepointsa: “Blog: How to create an adapter for the TFS Integration Platform - Part X: Reflection on SharePoint: Note: This pos... http://bit.ly/crKEHd ” 16 minutes ago retweet Topsy.Data.Twitter.User['rmaclean'] = {"photo":"http://a3.twimg.com/profile_images/414282781/IMG_A224_normal.png","url":"http://twitter.com/rmaclean","nick":"rmaclean"}; rmaclean: “How to create an adapter for the TFS Integration Platform - Part X: Reflection on SharePoint http://goo.gl/fb/gioen ” 2 hours ago retweet Filter tweets [...]

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Post new comment

The content of this field is kept private and will not be shown publicly. If you have a Gravatar account associated with the e-mail address you provide, it will be used to display your avatar.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.
  • Syntax highlight code surrounded by the <pre class="brush: lang">...</pre> tags, where lang is one of the following language brushes: as3, applescript, bash, csharp, coldfusion, cpp, css, delphi, diff, erlang, groovy, jscript, java, javafx, perl, php, plain, powershell, python, ruby, sass, scala, sql, vb, xml.

More information about formatting options