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?
I would be very interested to hear people’s thoughts on this subject.
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.
Brian Bedard
December 14, 2009 at 9:20 pm
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.
Jaap Vossers
December 15, 2009 at 5:32 pm
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!
Paul.
Paul Hunt
October 26, 2010 at 12:55 pm
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.
Michael
February 9, 2011 at 10:16 pm
Japp, did you try
SPWeb web = SPContext.Current.Web;
?
It seems it works for me.
Vincent Guilbaud
August 16, 2012 at 6:32 pm
The context I would like to get hold of would be the specific SPList we are “populating”
jvossers
August 28, 2012 at 4:35 pm
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.”
then, cannot you get your External SPList via:
SPList myList = web.Lists[“MyExtListName”];
Vincent
August 28, 2012 at 4:59 pm
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.
jvossers
August 28, 2012 at 5:22 pm
Sorry for misunderstood.
I thought your article about the lack of context in SP 2010 BDC had 3 points.
“how do you know the name of the list in the code?”
If your function is directly bound to a List, via BDC model, how can you not know it?
Then, after your code has a reference on this List, nothing stop you to call some generic functions, passing it as a parameter.
Vincent
August 28, 2012 at 6:00 pm