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:
- Runs on a non SharePoint installed box.
- 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.
- Batch approach – load up several commands and batch them over the wire when needed.
- Supports both read/write from the client back to SP Server.
- Uses XML and JSON over the wire – small and fast.
- 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:
- Microsoft.BizTalk.KwTpm.StsOmInterop3.exe – for WSSv3
- 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:
- C:\Program Files (x86)\Microsoft BizTalk Server 2010\Business Activity Services\BTSharePointV4AdapterWS
or
- 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:
- 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)
- 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:
- NOT got any newer SharePoint Client API code within in.
- The ability to contact a remote server through the WebService APIs.
- 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…