Today I decided to crack open the BTS 2010 SharePoint WS Adapter to see if it takes advantage of the great new interfaces exposed by SharePoint 2010, specifically Microsoft.SharePoint.Client.dll and Microsoft.SharePoint.Client.Runtime.dll.

At a glance, the benefits of this new Client APIs are:

1. Runs on a non SharePoint installed box.
2. Lightweight and flexible – only get back what you ask for. As opposed to the classic SP Server API that populates the SPWeb collection (for e.g.) only if you just want the title field and not 10MBs worth of other data.
3. Batch approach – load up several commands and batch them over the wire when needed.
4. Supports both read/write from the client back to SP Server.
5. Uses XML and JSON over the wire – small and fast.
6. We can’t do *everything* we can on the Server Side – e.g. Service Application management, i.e. kicking off a search index crawl.

A little piccy of what’s going on:

Some classic piece of code to achieve document library reading:

            

              
               1
              static
              
              
              void
               Main(
              string
              []
args) 
               2
               { 
               3
               ClientContext
ctx 
              =
              
              
              new
               ClientContext(
              "
              http://intranet
              "
              ); 
               4
               Web
web 
              =
               ctx.Web; 
               5
               List
docs 
              =
               web.Lists.GetByTitle(
              "
              Shared
Documents
              "
              ); 
               6
               ListItemCollection
items 
              =
               docs.GetItems(CamlQuery.CreateAllItemsQuery()); 
               7
               ctx.Load
              <
              Web
              >
              (web); 
               8
               ctx.Load(docs); 
               9
               ctx.Load(items); 
              10
               ctx.ExecuteQuery(); 
              11
               Console.WriteLine(
              "
              The
list has {0} items.
              "
              ,
docs.ItemCount); 
              12
              
              
              foreach
               (ListItem
item 
              in
               items) 
              13
               { 
              14
               Console.WriteLine(
              "
              Item:{0}
              "
              ,
item[
              "
              Title
              "
              ]); 
              15
               } 
              16
              
              
              //
              delete
an item. 
              17
              
              
              //
              items[1].Update(); 
              18
              
              
              //
              items[1].DeleteObject(); 
              19
              
              
              //
              ctx.Load(items); 
              20
              
              
              //
              ctx.ExecuteQuery();
              
              
              21
              
              
               Console.ReadLine(); 
              22
               }
            
          

Note: Line 10 is where all the magic happens – if you imagine, we load up the client OM classes and the props etc. are all ‘blank’ until we do an ExecuteQuery() which then populates what we ask for.

The above sample is pretty simple showing how to connect to a document library on a ‘remote’ server (security allowing – I didn’t add a ctx.Credentials=… line in the above, but all possible).

So let’s move on a crack open the BTS 2010 SharePoint WS Adapter…

Just before we go there I’d like to point out that the Microsoft.SharePoint.dll (aka Server API) has the ability to connect to remote servers, although the code needs to be executed on a machine that has a local SharePoint install.

e.g.

SPSite site = new SPSite(“http://remoteserver.acme.com”);

SPWeb web = site.OpenWeb();

…

What I am trying to avoid with the BTS SharePoint adapter is the need to have the ‘BTS Web Service’ component installed on remote Farms. Just complicates the issue far too much with the SharePoint admins.

The BTS 2010 Story

I setup and installed the BTS SharePoint WS Adapter through the Configuration.exe tool successfully.

Essentially this tools runs a ‘web site check’ to make sure SharePoint is successfully setup and installed.

To make this happen, the configuration tool runs either:

1. Microsoft.BizTalk.KwTpm.StsOmInterop3.exe – for WSSv3
2. Microsoft.BizTalk.KwTpm.StsOmInterop4.exe – for WSSv4

to determine the site as follows:

Note: The URL and note the URL in the BTS Configuration above. Here I’ve already configured the adapter and I’m just showing the commands that the configurator runs behind the scenes.

Once configuration is complete you will see a new virtual directory added  to your selected site e.g. http://intranet.

As shown in IIS Manager.

Depending on the SharePoint version this virtual directory will map to:

1. C:\Program Files (x86)\Microsoft BizTalk Server 2010\Business Activity Services\BTSharePointV4AdapterWS
   or
2. C:\Program Files (x86)\Microsoft BizTalk Server 2010\Business Activity Services\BTSharePointV3AdapterWS (previous bts2009 adapter)

A Basic BTS/SharePoint picture

Essentially the BTS SharePoint Adapter consists of 2 parts:

1. A BTS Adapter that talks to the BTS SharePoint WS. This is a ‘classic’ adapter and does not talk the newer WCF framework (which does have advantages and disadvantages)
2. A BTS SharePoint WS – this does all the work against the SharePoint library and talks local SharePoint APIs.

Let’s look closer at the BTSharePointV4AdapterWS folder

- this folder, or addition needs to be available locally to whichever SharePoint site you are calling through the OOTB BTS SharePoint adapter, even though the SharePoint APIs support remote Servers.

- the bin folder has the Microsoft.BizTalk.KwTpm.WssV4Adapter.WebService.dll which is 78kb.

I wanted to find out whether this DLL used the new SharePoint Client APIs when meant having a peek at the ‘references’ of this DLL in IL.

Dissassembling Microsoft.BizTalk.KwTpm.WssV4Adapter.WebService.dll

Using .NET Reflector I was able to get this picture…

NOTE: on this list there is Microsoft.SharePoint, but not Microsoft.SharePoint.Client.dll
(this is not looking good…could be late bound, but… I doubt it)

Digging into the actual WssAdapter class we get the following of note:

The GetDocuments(string, string, string, Int32, DocExtOfficeIntegration)… is a key method.

The APIs show that the 1st parameter is a siteUrl (and following the implementation code through) which has the potential to point to another SharePoint server to make the connection (in the RequestInfo class if you’re going to dig yourself :))
Note: the PREVIOUS version, BTS2009 has the same Interface/Method signature and it requires the BTS SharePoint Adapter WS to be deployed on the remote SharePoint Server, even though the signature looks as though it will support the remote server.

So in conclusion the BTS SharePoint Adapter WebService has:

1. NOT got any newer SharePoint Client API code within in.
2. The ability to contact a remote server through the WebService APIs.
3. But depends on whether the BTS Adapter will pass the ‘remote’ URL to the ‘local’ WS, or will the Adapter try to contact the remote SharePoint Server directly looking for a WS there???

I’m thinking it’s the latter…

A little more to unravel the SharePoint mystery…

As far as I know there’s some good news and bad news…

Good news: the existing BizTalk SharePoint Adapter *should* work with SharePoint 2010 – you will however need to add ‘<rebinding>’ section to the existing adapters web.config *if* the SharePoint 2010 is installed locally to the BizTalk Server.

The ‘rebinding’ tells your local .NET app that even though you want V12.0.0.0 of the SharePoint APIs, V14.0.0.0 assemblies will give it to you.

Bad News: there’s no new BTS Adapter on the Horizon for this – AFAIK.

------

With SharePoint 2010 we now have the capability to involve many tighter technologies such as:

1) event notification, rather than polling for the adapter.

2) LINQ and ADO.NET Entities to query the Data.

3) SharePoint Client WCF Service – Client.svc . This is a lightweight and fast interface, where we can batch up requests, send them over the wire and get back just what we ask for.

4) Lists.ASMX web service (+ the others) for backward compatibility.

When I get some time…:D, I’m keen to develop a .NET LOB WCF Adapter.