Hi all guys,
yes, it’s been quite a lot since i wrote something on this blog. I’ve been quite busy with lots of stuff, business and personal, so i didn’t took the right attention in posting news.
Anyway, here we are.
The topic I am covering today is something that is quite well treated on the internet, so i won’t go deep in details. I thought to provide some hints, and useful tips when you need to set up some BCS and you never did before.
First thing: set up your BCS
As i said, i don’t think it could be of much contribute to write down again all the stuff needed to create a BCS. To be complete, here are some excellent links to get the things right:
- Deploy a BDC Model project to SharePoint Foundation 2010 using Visual Studio 2010
- Walkthrough of creating a SharePoint 2010 external list using Visual Studio 2010 Beta
- Walkthrough of creating association between Sharepoint BDC entities using Visual Studio 2010
IMHO, the third is the most important of these links, because it is explained very well what you have to do when creating a BCS for Sharepoint.
So, you have followed all these links, and now you think you can rule sharepoint BCS uh? Here are some hints that maybe useful when not everything goes as is supposed to go.
What the heck is the Entity, and how is it bound with my data?
From what i have understood until now (and i could be greatly wrong), what is called Entity is nothing more than a proxy used by sharepoint to retrieve your data. For coherence, the entity reflects your business data (also known as Line Of Business data, LOB), but not completely. This is what will be published under sharepoint, and will contain all the relevant information in order to specify your real data’s identifiers (read as: connection to real fields on your “table”), and methods (read as: what sharepoint will call once it needs to interact with your “table”). And, not to forget, this Proxyy, will deal with objects that ARE your LOB system. Therefore, the class you have to set under, let’s say, the Read Item method as return type, is the one you use to get the data (aka: if you’re using Linq2Sql is the actual class you create in the .dbml file).
The real binding, instead, is made in another part. You can get access through the BDC Explorer (that will soon became your best friend). There, you set the real thing.
In the BDC you’ll find again your newly created Entities, and in every single method you’ll create for that particular Entity you can define the data you’re dealing with. TIP: keep as a good practice to create always the specific finder first. Why? Because the specific finder lets you define the data your Entity will deal with, and once you create the other CRUD methods, VS will know how your data is structured.
Do I have to create an Identifier for each property I have in my LOB?
The answer is… depends :-). Vague answer i know, but it really depends on how you need to expose your data. Just keep in mind one thing: for each identifier you create, you have to handle that specific identifier in your search methods.
An example? You have a Customer Entity, with 7 properties. Let’s say you create 7 Identifiers. The signature of the ReadItem method will have to have 7 arguments, one per identifier. Otherwise, if you try to call the method SP will tell you that you can’t call a method that expects 7 identifiers. Therefore, if you need to make queries only by Id, create only ONE identifier.
You have created your BCS, but the Line Of Business object (LOB) doesn’t have the exactly same properties of your BCS Entity
Strange as it might be, all the guys writing down these super tutorials always write this stuff as if you will never use them in real life. Therefore, they put down the perfect case ever, where everything is pure and perfect. Well, my case wasn’t. It was like probably every real life project, where everything is a bit messed up, and is not THAT linear.
So, how do u deal with LOB systems that differ from Entities? You just have to use a wonderful property called LOB Name. This provides the underlying mapping between your entity and the LOB. Assuming you are using an ORM like Linq2Sql, it has to be the property’s name of the class reflecting your sql data.
HELP! I keep updating the code, but on the bloody server I get always the same errors
This is quite easy, indeed… check whether the bloody visual studio didn’t defined a static versioning of your dll… like 188.8.131.52. Be sure it has at least a * in the versioning number. In this way, sharepoint will understand that your assembly has changed at every build, and will replace the whole package.
Ok, how do I check if the methods i am creating are good ones or not, WITHOUT using sharepoint?
Another simple but annoying fact. Even if sharepoint is a great tool, is made for users. Not for developers. At least, it doesn’t give any real feedback in the page if something goes wrong.
So how can you deal with BCS? Fortunately, a nice company have developed a very useful tool: BCS Tester Man. Is extremely simple, ready to use, and throws out the real s#@t that SP doesn’t show when you make some mistake.
You made it. It works, at least while testing. Why the heck I can’t see my list?!?!?!?!
This one made me struggle for a good couple of hours. I really couldn’t understand what was wrong, even if i knew it was something very simple (as it always is). I made the BCS correctly, the mapping was right, the data provider (lob) was right too, with BCS Tester it worked correctly (list retrieval ok, specific ok). But after the deploying the BCS to sharepoint, and creating a list upon it, I had a very strange situation.
I could see the actual insert form, but in the list it showed me the generic error:
“Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Microsoft SharePoint Foundation-compatible HTML editor such as Microsoft SharePoint Designer. If the problem persists, contact your Web server administrator”
And THIS is annoying. If you search in the internet for such an error, you can find almost everything. They all come down to a point, though: permissions. And it is bloody right also in this case. I have noticed basically two cases: the first one, where you didn’t set the right permission level on your BCS (check Central Admin -> Manage Service Application -> Business Connectivity Service -> Set Permissions)… or the one i dealt with: if you work with a third party database you need to grant the right permission level so that the user that will try to access to the database won’t be rejected.
In my case, the connection string used to connect to the database was using windows authentication. Therefore, i had to give read/write permission to the user that executes the application pool of my sharepoint website. After that… ta daaaaa! Match won! ;-)
Well, this is all for now my dear readers. I just dealt with this kind of development, and i felt like useful if there would’ve been out there a post like this. with useful hints that are not very often posted on blogs.
As always, feel free to comment, reply, and all the usual stuff.