HttpCode

I was asked recently if the BDC search results (when indexed by the search) can be controlled by an access list. The answer is that yes, the Security trimmer is the SharePoint feature to accomplish this. In fact any search result can be trimmed, so if you wanted to index some website that used custom permissions (i.e. a content access account that has full rights to a website) but you didn’t want to show that information to say public users of your site, this same security trimmer functionally can be used.

The important things to note are:

• The security trimmer is attached to a crawl rule
• The security trimmer is a class that implements the ISecurityTrimmer interface, the registration process defines the full assembly name, as such it must be loaded into the GAC.
• After the security trimmer is registered, you will need to recreate the content source and perform a full crawl
• Performance might be an issue, since every search result will be access checked, if your looking for insight on how to approach this refer to this MSDN article

I was having a bit of a play around with CRM 4 and build an application definition file that provides the entities: Account, Contact and Product.

So you can use the BDC web parts to display the contacts in the account like:

You can download the Application Definition File here.

There are a number of options that you can use when you define your connection settings in your BDC ADF file:

The authentication methods are:

RevertToSelf

Simply uses the application pool account (reverts back to this account) to access the database.

   1: <Properties>

   2: <Property Name="AuthenticationMode" Type="System.String">RevertToSelf</Property>

   3: <Property Name="DatabaseAccessProvider" Type="System.String">SqlServer</Property>

   4: <Property Name="RdbConnection Data Source" Type="System.String">servername</Property>

   5: <Property Name="RdbConnection Initial Catalog" Type="System.String">databasename</Property>

   6: <Property Name="RdbConnection Integrated Security" Type="System.String">SSPI</Property>

   7: <Property Name="RdbConnection Pooling" Type="System.String">false</Property>

   8: </Properties>

PassThrough

Passes the credentials of the calling user, this will only work on a single server install or on a farm if Kerberos is enabled.

   1: <Properties>

   2: <Property Name="AuthenticationMode" Type="System.String">PassThrough</Property>

   3: <Property Name="DatabaseAccessProvider" Type="System.String">SqlServer</Property>

   4: <Property Name="RdbConnection Data Source" Type="System.String">servername</Property>

   5: <Property Name="RdbConnection Initial Catalog" Type="System.String">databasename</Property>

   6: <Property Name="RdbConnection Integrated Security" Type="System.String">SSPI</Property>

   7: <Property Name="RdbConnection Pooling" Type="System.String">false</Property>

   8: </Properties>

SQL Authentication

It is still possible to use SQL Server Authentication, the following example uses the RdbConnection properties for this:

   1: <Properties>

   2: <Property Name="AuthenticationMode" Type="Microsoft.Office.Server.ApplicationRegistry.SystemSpecific.Db.DbAuthenticationMode">

   3: RevertToSelf</Property>

   4: <Property Name="DatabaseAccessProvider" Type="Microsoft.Office.Server.ApplicationRegistry.SystemSpecific.Db.DbAccessProvider">

   5: SqlServer</Property>

   6: <Property Name="RdbConnection Data Source" Type="System.String">servername</Property>

   7: <Property Name="RdbConnection Initial Catalog" Type="System.String">databasename</Property> 

   8: <Property Name="RdbConnection Integrated Security" Type="System.String">false</Property>

   9: <Property Name="RdbConnection User ID" Type="System.String">username</Property>

  10: <Property Name="RdbConnection Password" Type="System.String">password</Property>

  11: </Properties>

  12:  

Single Sign On

If your using SSO, this is also supported:

   1: <Properties>

   2: <Property Name="AuthenticationMode" Type="System.String">RdbCredentials</Property>

   3: <Property Name="DatabaseAccessProvider" Type="System.String">SqlServer</Property>

   4: <Property Name="RdbConnection Data Source" Type="System.String">servername</Property>

   5: <Property Name="RdbConnection Initial Catalog" Type="System.String">databasename</Property>

   6: <Property Name="RdbConnection Integrated Security" Type="System.String">false</Property>

   7: <Property Name="RdbConnection Pooling" Type="System.String">true</Property>

   8: <Property Name="SsoApplicationId" Type="System.String">SSO Application you created</Property>

   9: <Property Name="SsoProviderImplementation" Type="System.String">Microsoft.SharePoint.Portal.SingleSignon.SpsSsoProvider,
 Microsoft.SharePoint.Portal.SingleSignon, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c</Property>

  10: </Properties>

The MSDN documentation can be found here.

The BDC isn’t just limited to data located in a database, it’s most powerful feature is its ability to call webservices. I previously posted a brief description of the types of webservices are easily consumed by the BDC.

The key to easily calling webservices from the BDC first starts with an understanding of the types of methods that the BDC supports:

• Finder 
• Specific Finder
• IDEnumerator

If we take the common example of getting customers from a webservice we might can start thinking about the way we create the webservice so that it doesn’t become a painful exercise.

The first method we should think about is something that can return the primary key (or ID) of our data:

So a method like:

GetCustomerIDs  - This will return customer ID’s and will become our IDEnumerator

So the BDC will next need a method that will accept an ID that was returned by our GetCustomerIDs method above.

GetCustomerByID  - This will become a Specific finder method, the naming ‘specific’ really gives the game away, it’s specifically returning data based on an ID.

The final method is a generic finder method that can be used by the Business Data List webpart:

GetCustomers – This becomes a finder method, we can have more of these methods with each one returning a different subset of data as needed.

It’s fairly easy to now create a BDC Application Definition File (ADF) using a tool like BDC Meta-Man. But you also need to remember that the ADF references a .NET assembly. This assembly is the proxy to the webservice, this proxy is the exact same proxy that we get automatically generated for us by Visual Studio when we add a web reference.

So you can create a proxy that will be used by the BDC, you just create a web reference in visual studio and compile that into a signed assembly and make sure the ADF references this assembly correctly.

Once you perform the two steps of creating the ADF and corresponding proxy classes, your well on your way to using the BDC via webservices.

I previously blogged about using the BDC with MOSS user profiles and how to set that whole process up. Well I thought that I might write a little about the BDC application definition file (ADF) that is imported into MOSS and is used by the BDC to generate the meta-data and to ultimately connect to the data source.

An ADF file contains metadata describing entities and methods to populate those entities.

These are the methods that are of interest to us, all have nice relevant names:

IDEnumerator – These methods can perform filtering and can be passed parameters, the idea is that it returns an ID (and a timestamp if possible), as it’s name implies it is used to enumerate all the ID’s (or primary keys). In the context of the profile import, if your key is say, an Active Directory email address, then the IDEnumerator should return the email address field.

Specific Finder – This method accepts an ID and returns just the information related to that ID. You’ll probably create a number of these using different filter descriptors.

Now that you have an idea of what the methods are and how they operate you can design web services that are low friction for the BDC.

You’ll need a web service that returns a list of ID’s (for the IDEnumerator), you’ll need a second webservice that accepts the same ID’s that were returned by the first method, this second method will comprise your Specific Finder methods.

Also don’t create trouble for yourself by building webservices that accept a large number of parameters, you’ll regret it, just keep it simple. The guys that developed the fantastic BDC Meta-Man product also have the same advice.

I’ve provided the SQL create statement and ADF file here.

I’ve put together a screencast that shows how to use your data from an external source such as a SQL Server database and combine it with your user profiles.

The screencast shows how to:

• Import the application definition to setup the BDC application
• Setup a custom import connection of type business data catalog and how to set the key between active directory account and BDC data
• Setting up custom profile property section (the example is cricket statistics)
• Setting up custom profile properties that import data from the BDC data source
• Start a full import
• Perform a search which returns the user and show the new data that is displayed in the users profile page.

A good quality version of the screen cast can be found here (4 mins).

Or the low quality youtube version: