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 goodcould 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