Notes On SharePoint Business Connectivity Services

The past 2 weeks I had an opportunity to develop a solution with SharePoint 2010’s Business Connectivity Services. I found working with SharePoint BCS to be a delicate process, with a few things not behaving entirely as expected. Here’s a few quick notes to help clarify some of the things that confused me most about BCS:

1.

For each BCS Entity’s Identifier, its Specific Finder must have an equivalent In Parameter. In other words, for example, if you have 2 Identifiers, then your Specific Finder method must have 2 corresponding input arguments.

2.

All the other methods have a dependency on the Entity’s Specific Finder. If you change the fields, or their Type Descriptors, of Specific Finder’s return parameter object, then you have to update the update and create methods accordingly. The principle is explained in the Implementing an Updater article on MSDN: “If there are multiple specific finders, the Updater view should be equal to, or a subset of, at least one SpecificFinder view.” I know it refers to “multiple specific finders”, but it found it to work the same whether there’s one or more specific finders.

3.

Your permissions are removed from the BCS Service Application (in Central Admin), and you get the “Access denied by Business Data Connectivity.”, when you deploy a new BCS model, after changing the methods, Type Descriptors or any other part of the model. This didn’t always seem like it happened consistently. At times, it seemed like it was removing the permission at random, even when I just updated the code of my entities or services.

4.

Make sure you activate SharePoint Server Enterprise Site Collection features for your Web Application.

5.

Whenever I modified a Creator method, and refreshed the page, I started getting strange errors on the list page, and had to recreate the List to fix it.

 

 


Deploying SharePoint Features To A Multiple Server Farm

I recently deployed some features, mainly web parts, to a client’s load balanced SharePoint farm. The features were created with the Visual Studio 2008 extensions for Windows SharePoint Services. When using features created with VSeWSS they work fine on a simple, non-load balanced, single server farm.

However when I tried to run the setup file produced by VSeWSS I got an error like “the feature is not available on the farm”. The reason is related to the following sentence from the stsadm installfeature operation’s help documentation: “Farm-scoped features are also automatically activated during this [installfeature] stage. Other features might still need to be activated.”

Now, if you open the feature.xml file, created by VSeWSS and look at the Feature element, you’ll see it has the following attribute: Scope=”Site” .

This means that the feature is defined at the Site level, and that it needs to be installed and then activated on a multiple server farm configuration. The standard VSeWSS setup.bat only takes care of activating the feature: “%SPAdminTool%” -o activatefeature -id 87f20850-ad52-4785-a680-195942270020 -url %TargetSiteUrl% . Whoops, that will indeed cause some problems.

Solution

First install the feature before activating it. There is one little gotcha here. Stsadm’s installfeature operation does not provide an option to specify the feature’s GUID. It only supports filename or name, and as you can expect VSeWSS only uses features’ GUIDs. So we have to modify setup.bat to use the file name, instead of the GUID and add the installfeature command for each feature:

“%SPAdminTool%” -o installfeature -filename WebPartFeature\feature.xml
“%SPAdminTool%” -o activatefeature -name WebPartFeature -url %TargetSiteUrl%

Cool, problem solved! If you don’t know this before hand, it can take a while to figure out.

Visual Studio 2008 extensions for Windows SharePoint Services


Content Managment With SharePoint And Kentico

Since I’ve joined Intervate Cape Town, I’ve been assigned to three projects. Two are Microsoft Office SharePoint Server 2007 (MOSS) solutions, and a small web site based on the Kentico Content Management System (CMS). It’s been a while since I worked with MOSS, so I had to relearn a lot of things. The one MOSS solution was an extranet application, that used Windows (Active Directory) and Forms Based Authentication (FBA). Initially I was a bit confused at how SharePoint handles FBA, and to make matters worse there are some overlapping terms between FBA and the rest of SharePoint’s security model.

Here’s briefly what I learned:

  • Permissions assigned to SharePoint groups and users are referred to as roles in the SharePoint Object Model (SOM).
  • FBA, which is just standard ASP .NET Forms authentication, also has roles. These roles correspond with SharePoint Security’s concept of a group, and has nothing to do with SharePoint permissions.
  • SharePoint handles users and roles coming from ASP .NET Membership the same way as those coming from Windows AD. ASP .NET’s Membership becomes just another credential store to SharePoint. You add an ASP .NET user/role in the same manner as you’d add a Windows AD user/group to a SharePoint user/group. When you search for users/groups you’ll notice that those coming from ASP .NET Membership are prefixed with AspNetSqlRoleProvider:, or aspnetsqlmembershipprovider: for ASP .NET roles, and users respectively.
  • It’s best to deploy SharePoint customizations using a SharePoint solution file (.wsp). But where’s a good guide to explain how this works? Well, luckily we have good blogs like the The Bonobo Journal to explain it in layman’s terms.
  • Make sure you understand the do’s and don’ts of writing optimal code for SharePoint’s Object Model. Andreas Grabner from InfoQ did an excellent post on this subject.

The other project I got assigned to was done in Kentico. Yes, I had the same confused expression when I heard about it. Turns out Kentico is a really neat .NET CMS that doesn’t get in your way. It’s jam packed with features, and has every standard web technology, like blogs and wikis, out of the box (and they are all really well implemented). What I really appreciate about Kentico is that it’s got a really well designed and simple architecture, based on standard ASP .NET components. When you extend Kentico with custom code you literally open the Kentico Visual Studio solution and start creating ASP web pages (modules), and user controls (web parts). To debug something you just run the solution, and debug it as you’d do with any normal .NET web app. This enables developers to use a familiar development and deployment process.

Kentico arranges it’s web sites as a hierarchy of nodes. Each node has a document type (with its own table in the database), a form/data view, and a page/UI view. To retrieve any document is a straightforward matter:


CMS.TreeEngine.TreeProvider tree = new CMS.TreeEngine.TreeProvider();

treeNode = tree.SelectSingleDocument(CMSContext.CurrentDocument.DocumentID);         

var nodeSet = tree.SelectNodes(CMSContext.CurrentSiteName, treeNode.NodeAliasPath + "/%", treeNode.DocumentCulture, true, "cms.file");

The above code finds the node of the current document shown to the user, and then retrieves all its child nodes. This kind of simplicity is found throughout Kentico, from the application itself, right down to the database. It also provides multiple extension points. You can use the application itself to create new document types, and plug your own code in without using Visual Studio. Your other options are to write your own web parts, and modules in Visual Studio. And lastly if you really wanted to, you can directly query the database. Corresponding directly with the database should not be your first choice, but Kentico provides a database API that assists you in this regard.

The deployment process is also as easy as it gets. To install Kentico you can either use the setup file, or just copy your solution over and connect it to the database. From there on you just export your sites, and import them again on the target server. And yes, Kentico even exports/imports any custom classes that you might have added to it’s Visual Studio solution.

And if you think Kentico is only for small web sites, think again. There’s support for load balancing and server farms. Definitely give Kentico’s free version a try next time your client doesn’t demand SharePoint.


SharePoint 2007 Administration Toolkit

The Microsoft SharePoint Administration Toolkit contains functionality to help administrate and manage Office SharePoint Server 2007 and Windows SharePoint Services version 3.0.

This toolkit contains two new functions – the ability to perform bulk operations (Move, Lock, and Delete) on site collections and a Stsadm operation to update alert emails after a Web application has changed URLs.

Get it here.