Custom BDC Connector for SharePoint 2010 – Part 1

One of the extension points of SharePoint 2010 is through Business Connectivity Services (BCS). Based on these services you can integrate external data sources into SharePoint lists. What’s more, you can work with these lists like normal, without taking care how the data is pulled out.

BCS provides three out-of-the-box connection types:

  • WCF Service
  • SQL Database
  • .NET Assembly

The first two are quite straightforward. And you have nice support in SharePoint Designer. You can also create your own model linked to a .NET type. In my previous postI wrote about creating such a model. However you can also create your own custom connector. There is confusion about the difference between a .NET assembly connector and a custom one. Basically BCS work with a model definition (*.bdcm files) and an interpreter of that model (.NET type). With .NET assembly connectors, you supply only .NET entities (which provide the necessary properties) and a service (which provide implementation of the desired methods). With custom connectors you have to write your own interpreter of the model definition. So you have the complete power to decide how to use each element, defined in that definition.

A bdcm file is nothing more than a XML file. This makes it possible to create model definitions yourself with a normal text editor. Visual Studio 2010 provides a simple mode builder experience which eases this creation. The good news is that models are made extensible.  Basically you can define your own properties for every element in the tree. Later you can read them in your custom interpretor and do whatever you want. Before writing your own custom connector you should think well if the .NET type one won’t be able to help you. Here is a list of some differences between these two types of connector:

  • .NET Assembly Connector
    • DLL that implements business logic is stored in the BDC store. Therefore, you do not have to place the DLL separately in the global assembly cache on client and server.
    • No administrator privileges are required on the client computer for deployment.
    • Provides a useful approach if business logic can be exposed through static APIs that rarely change.
  • Custom Connector
    • Binaries that implement a custom connector must be placed in the global assembly cache on the client and server.
    • Administrator privileges are required on the client computer to put the assembly in the global assembly cache.
    • Provides a useful approach when back-end interfaces frequently change (are dynamic).

For more differences between those approaches, you can refer to MSDN.

I will create a custom connector which communicates with a RESTful service. I plan to publish my code so I have already created a project in codeplex where to host my code. In my next article I will start with defining my model. I will explain you its structure and content. Later on I will start with code-behind which actually interprets my model.