This post is the fourth in a weekly series intended to briefly spotlight those things that you need to know about new features in BizTalk Server 2013.

In the Support for new Adapters section of the new features list for BizTalk Server 2013, you will find a very brief note without much explanation about the SharePoint adapter in BizTalk Server 2013:

BizTalk Server 2013 also provides updates to SharePoint adapter that gives users the option of choosing between using the client-side or server-side object model for connecting to a SharePoint server.

While this is nicely succinct¹ and technically accurate, it really does not do a great job at explaining the implications. In order to uncover that, we actually have to look to the past – all the way to the year 2010.

A Brief History of Recent Time

In BizTalk Server 2010 (or more specifically, all versions including the WSS adapter), when we wanted to allow a BizTalk process to interface with SharePoint, we had to install a special web service that ran on the SharePoint server. This web service was installed by BizTalk and interacted with the server-side object model of SharePoint to provide access to data within SharePoint document libraries.

In a sense, to do a SharePoint integration, we had to cheat. We had to modify the target system to help adjust it to BizTalk – as opposed to leaving that system alone and integrating with it in a purely native way. Now one can easily argue that this is a slight exaggeration (since BizTalk did use an established interface in the form of the server-side object model), however it was still fairly inconvenient to have to install that adapter web service in each SharePoint environment with which I wanted to enable integration.

At around the same time that BizTalk Server 2010 was released, SharePoint 2010 was also released, and sported a brand new method (actually a few brand new methods) for accessing data – specifically the client-side object model. The client-side object model operates through a special service that SharePoint already exposes itself. This service is able to process bulk requests and the interaction with this service can be accomplished using proxy classes implemented in .NET, Silverlight, and JavaScript code – all of which more or less conform to the same naming and patterns for use.

With this client-side object model exposed starting in SharePoint 2010, the BizTalk team was able to take full advantage of it in the 2013 release of BizTalk Server. As a result, we now find this delightful option within the adapter configuration:

Also, without having to install anything specific on the SharePoint server to support communication with BizTalk Server 2013, it opens up the door for the updated WSS adapter to access SharePoint Online with only a few minor tweaks for a different authentication method – and indeed the team made those investments as well:

The Little Things

Sometimes, its the seemingly little things that will make all of the difference. If you’re trying to tackle a SharePoint integration, and you’re on BizTalk Server 2010, consider the move up. Not only will it make you feel good to do things in a pure way that will satisfy those that hold tightly to the enterprise integration dogma, but it will also be less of a headache at installation time.

If you would like to learn more about the enhancements to the SharePoint Adapter, check out one of our upcoming BizTalk Server 2013 Deep Dive classes.

¹ I say “nicely” succinct due to one of my college professors constantly saying of essays written by Freshmen: “Brevity is a virtue”.