Context in SharePoint 2010 Business Connectivity Services (or the lack of it)

The problem I see with Business Connectivity Services is the lack of context available when writing your custom code to retrieve and update data. As a result, custom BCS implementations are not very reusable because the lack of configuration options per External List.

Let’s look at an example.

ACME Ltd, an ISV focusing on selling SharePoint products, wants to develop and sell a BCS solution that allows customers to create External Lists based on data that resides in ANOTHER SharePoint site collection. In a nutshell, the External List will contain a “virtual” list item for each site in the target site collection. Now how does the BCS code know where this target site collection is? You could hardcode the url, or you could store the url in the appSettings in the web.config for your web app. These are both solutions that will give you headaches when you need more than one instance of this External List, each using the same BCS code, but retrieving data from different target site collections.

When I created a new Business Data Connectivity Model in Visual Studio 2010 for the first time and I looked at the code that was initially generated (Entity1Service.cs), I was surprised that there seemed to be no way to derive any of the following in code:

SPWeb instance or url of the site that contains the External List we are trying to load data for.

Name (or ID) of the External List we are trying to load data for. This, together with an SPWeb, would allow you to read per-list configuration data from SPList.RootFolder.Properties

Some string containing configuration data that applies to our BCS Entity to External List association. Something similar exists for EventReceivers and Workflow, so why does it not exist for BCS?

9 Responses

I love the new External List functionality. It takes the Business Data column to its expected evolution. I’m sorry you’re having a hard time porting it and making it reusable. When I start actually developing solutions for the External List I’ll be sure to investigate it and make a blog post. Just remember every new feature with Microsoft takes a little time to gain traction and become “solid”. We should be happy they gave us this functionality — I’ve been waiting for it ever since the BDC was introduced. Maybe because creating an External List is so easy once the External Content Type is created, they want us to use Designer to create them. And because I like to write my own features and site definitions and use CAML and API to provision components, I might be a little irked too.

Hi Brian. Don’t get me wrong I do love the new BCS stuff! 🙂 The point of this post is to point out to people that something important seems to be missing, and it would be really cool if Microsoft would agree and decided to change this before the RTM version is released. Obviously if you don’t plan on developing reusable BCS solutions, you won’t be affected by this limitation, so I do see your point.

Agreed, one of the things that I wanted to be able to do was have different data connections for my DEV, UAT and Prod environments. At the moment, I’m using the LobSystemInstance property bag to house the connection strings and then selecting the right one using a pre-processor directive depending on which Build I’ve used in VS.

The only downside is we have to do a different build for each environment, where as I’d like to use the same wsp across UAT and Prod to ensure consistency.

But this doesn’t answer the issue of making it more portable, as you point out, access to a context Web would at least give us access to a property bag at the site level. I’ll be watching any developments on this with interest.. Next SUGUK talk maybe if you find a solution!

I would love to be able to have an event handler on an external list. I have a situation where I need to control which users can actually edit a particular item. The users are authenticated against a custom STS and not AD and will not have access to the back end SQL server. Initially tried to extend a user profile for these user types but the supplemented data is only read only FROM the BCS. Ugh.

Still, your first point was:
“I was surprised that there seemed to be no way to derive any of the following in code:
– SPWeb instance or url of the site that contains the External List we are trying to load data for.”

My point is – how do you know the name of the list in the code? Ideally the code doesn’t care and can work with multiple lists, and the list context (for example it’s name) would be passed in at runtime.