Overview of BCS Advanced Code-Based Solutions

Business Connectivity Services (BCS) provides many out-of-box capabilities that deliver rich, end-to-end solutions. BCS is also a programmable platform, allowing developers to further extend BCS to create customized solutions.

Three types of BCS solutions that can be created are:

1. Simple Solutions (which leverage out-of-box capabilities)
2. Intermediate Declarative Solutions
3. Advanced Code-Based Solutions

For a description of these three types of BCS solutions see Brad Stevenson’s post Types of Solutions.

This post will focus on Advanced Code-Based solutions, which are solutions and extensions coded by developers. They range from rich end-to-end solutions with code components running on the client and on the server, to re-usable BCS components that can be re-used by Power Users for declarative-type solutions.

To begin, let’s look at an important distinguishing factor for these types of solutions: the Object Model (OM) that the developers code against.

Object Model

Developers will code against a particular OM to retrieve and manipulate External Data, either directly from the External System (while connected) or locally from the BCS Rich Client Cache.

There are two significant OMs to consider: the SharePoint OM and the BDC OM. Each display unique advantages and limitations, and as a result are appropriate for use with different types of solutions. The intention of this post is to guide developers to ask the right questions during the planning stages and thus help them to arrive at the best possible design for their solution.

OM Choice – List Parity

External Data can be presented in the form of an External List, which is designed to be analogous to a regular SharePoint List (SPList). Because of this, developers can either code against these SharePoint “External” Lists similar to how they do with regular lists, or they can choose to code against the BDC OM by manipulating the External Content Type directly.

Both the SharePoint OM and the BDC OM have a server component and a client component, and each is described below.

SharePoint OM

External Data can be manipulated through External Lists using the SPList class in the Microsoft.SharePoint namespace of the server-side OM. Developers can also manipulate lists in code from the client, through the corresponding List class counterpart in the client-side OM (known as the CSOM) in the Microsoft.SharePoint.Client and Microsoft.SharePoint.Client.Silverlight namespaces.

BDC OM

The BDC OM is available on both the server and the client in SharePoint Foundation 2010, SharePoint Server 2010 and Office Professional Plus 2010. Operations are performed on the External Content Type, so an External List is not necessary.

For more detail view the Business Connectivity Services Class Library on MSDN.

SharePoint OM versus BDC OM

The following diagram may help to assist you in visualizing the External Data access stack.

 

The BDC OM performs Create, Read, Update and Delete (CRUD) operations through an External Content Type on the External Data, from both the server and the client.

The SPList class sits on top of the BDC OM to perform CRUD operations on an External List from the server.

The CSOM wraps the server-side OM to perform operations from the client.

When developing on the server, there is an option for which entry point in the stack to code against. The recommended option is to code against the SPList class to manipulate External List data. SPList has benefits such as the ability to run in a Partially Trusted Environment, being widely available to developers and works with any code already written to perform list operations against regular SharePoint lists.

However, there are certain limitations displayed by the SPList class pertaining to External Data. When these limitations are encountered, the secondary option is to code against the lower-level APIs of the BDC OM by manipulating the External Content Types directly. These limitations for fields are encountered when the following requirements occur:

• Complex and custom types
• No mapping between .NET type to SPField type exists (e.g. System.Object)
• ID field is of type int64
• Paging or “data chunking” of data
• Bulk operations (e.g. reading 25 instances simultaneously)
• Streaming data from External Systems (e.g. binary large objects aka BLOBs)
• Different back-end views for Create and Update operations
• Invoking a SpecificFinder (Read Item Operation) with non-integer IDs

Types of Solutions

Developers can create client components (where the code runs on the end-user’s client machine), server components (browser-based, where the code runs on the server machine), or end-to-end solutions that span both server and client.

For client components, developers can choose to create a Microsoft Office Add-in or a Microsoft Silverlight Application.

There are several different BCS solution designs available, and depend on some of the following factors:

• Client or server component
• Office Add-in or Silverlight Application
• Online-only solution, or using the BCS Rich Client Cache
• Will the solution be self-contained, or will it leverage metadata and subscriptions that have already been deployed through other solutions
• For Outlook solutions, should you use the Outlook Integrated Runtime Solution Manifest for data cross-synchronization between Outlook and the BCS Rich Client Cache

The following flowchart will assist you to select an appropriate solution design based on these requirements: (Click the image to view it in full resolution.)

 

As you can see, there are several different types of BCS solutions:

• Custom Server Component
• Silverlight Application
• Office Add-in
  • Pre-deployed
  • Self-contained
  • Online-only
• Office Outlook Add-in
  • Self-contained

Further documentation in the SharePoint 2010 Software Development Kit (SDK) will explain each of these design types in detail, but for now here are some key explanations:

Pre-deployed: an Office Add-in can leverage the solutions that have already had metadata and subscriptions deployed to the client of a machine. These types of solutions discover and reflect upon data in the BCS Rich Client Cache.

Online-only: an Office Add-in which accesses data directly from the External System through the BDC OM or by using the client-side OM to go through the server when special circumstances require them to do so (i.e. a corporate firewall blocking direct access to the External System).

Self-contained: an Office Add-in similar to the pre-deployed type, except that is uses a special data-only deployment package (aka Data Solution) to bring the data to the cache.

Summary

In this post we’ve looked in more detail at one of the three types of BCS solutions: the Advanced Code-Based Solution. We mentioned that developers can create re-usable components, client solution components, server solution components, or full end-to-end solutions that span server and client.

Then, we introduced the differences between Object Models and our recommendations for when to use the SharePoint OM and when to use the BDC OM.

Finally, we looked at some important design considerations and the types of solutions that these design characteristics can lead us to. We also brought up some of the different variations of data deployment for Office Add-ins.

Thanks for reading.

- Russell Palmer, Program Manager