Business Data Connectivity Models

When you design a SharePoint application around external data, the metadata for your data model is stored and managed by the BDC service application. This is known as a Business Data Connectivity model, or BDC model. You can interactively create a BDC model in SharePoint Designer 2010, or programmatically in Visual Studio 2010 for more complex scenarios. In a BDC model, data entities are represented by external content types. An external content type models an external data entity, such as a database table or view or a Web service method, and defines a set of stereotyped operations on that data entity. In addition to external content types, a BDC model typically includes an external data source definition, connection and security details for the external data source, and associations that describe the relationship between individual data entities. Other BCS components, such as external lists and external data search, enable end users to interact with the external data provided by the BDC model.


A stereotyped operation is a data access method that conforms to a common and well-recognized signature, such as create, retrieve, update, and delete operations.

Creating BDC models for your external data sources offers many benefits. First, the BDC model enables you to centrally maintain all the information you need to interact with an external data source. This ensures that the external data source is accessed consistently by applications across your environment. After creating the BDC model, you can work with the external data in several ways without writing any code. The following are some examples:

  • You can surface the external data through the out-of-the-box Business Data Web Parts.
  • You can interact with the external data through external lists.
  • You can crawl and index the external data for search.

The following illustration shows the basic overall structure of a BDC model.

Conceptual illustration of a BDC model


As you can see, each model defines one or more external systems or services. These are sometimes known as LOB systems (line-of-business systems) for historical reasons, and are represented by LobSystem elements in the BDC model schema. This represents a general view of an external system, its data entities, and its operations. For example, it might represent a particular type of Customer Relationship Management (CRM) system. Within each external system definition, you must define one or more system instances. These represent a specific, individual implementation of the external system, such as a particular installation of a CRM system. The system instance definition defines the connection and authentication information that the BDC service application requires in order to communicate with the external system instance. The other key component of an external system definition is a set of entities, represented by external content types (ECTs). These are described later in this topic.

The metadata that comprises a BDC model is stored as XML. You can import, export, and manually edit BDC models as .bdcm files. For a good introduction to the BDC model schema, see BDC Model Infrastructure on MSDN.

BDC models are stored by the BDC metadata store, a central component of the BDC service application. When a SharePoint client application requests external data, the BDC runtime component on the Web front-end server requests the metadata that defines the BDC model from the BDC metadata store. The BDC runtime then uses the metadata provided to perform data operations directly on the external system. The BDC runtime also caches BDC model metadata on the Web front-end server.

In the case of client computers that use Microsoft Office 2010 to access external systems, the metadata for an application is packaged on the server and deployed with the application for use by the BDC client runtime. The BDC client runtime uses the metadata provided to perform operations directly on the external system instead of going through SharePoint. The BDC client runtime caches both BDC model metadata and the external data itself for offline use. This is illustrated by the following diagram.

Metadata and data access in BDC models


External Content Types

An external content type (ECT) is conceptually similar to a regular SharePoint content type (although unrelated in terms of implementation). Just like a regular content type, an ECT is a collection of metadata that models a data entity. External data sources describe data schemas in different ways. For example, Web services describe their data entities and operations using the Web Service Description Language (WSDL), while relational databases describe their data entities and operations using a database schema. When you create a BDC model in SharePoint Designer, these data definitions are translated into ECTs.


Visual Studio 2010 also provides tooling for defining BDC models for .NET Connectivity Assemblies.

Each ECT definition includes the following components:

  • One or more identifiers that uniquely identify instances of the data entity
  • One or more methods (known as "operations" in SharePoint Designer) that define a particular operation, such as create, read items, update, or delete, on the data entity

The methods are the central component of any ECT, and the BDC service application infers the structure of your data entity from the return types of these methods. The methods that make up an ECT are known as stereotyped operations, because they map the external service methods or database queries to standardized data operations that the BCS user interface components can use to display and manipulate the external data. For example, the BDC model supports stereotyped operations that perform the following actions:

  • Create an item.
  • Retrieve all items.
  • Retrieve an individual item.
  • Update an item.
  • Delete an item.
  • Stream an item.


For more information about stereotyped operations, see Designing a Business Data Connectivity Model on MSDN.

Stereotyped operations offer many advantages, such as enabling SharePoint to crawl and index external data for search and allowing users to manipulate external data through built-in Business Data Web Parts without requiring custom-coded components.

External Lists

External lists are not part of the BDC model, but they are briefly described here because of their close relationship with ECTs. An external list is a BCS component that provides a SharePoint list wrapper for data entities modeled by an ECT. Unlike SharePoint lists and content types, each external list is mapped to a single ECT. The external list enables users to view, sort and filter, create, update, and delete external data entities in the same way that they would work with data in a regular SharePoint list. An ECT must implement Finder and SpecificFinder methods to be exposed as an external list. As a developer, you can also use the SPList object model to programmatically interact with data through the external list (with some restrictions). However, because external lists don't "own" the external data, they cannot receive events when items are added, updated, or deleted. As such, you can't associate workflows or event receivers with external lists. However, logic in workflows and event receivers can access items in external lists.


For more information about using the SPList object model with external lists, see Hybrid Approaches. For more information about Finder and SpecificFinder methods in the BCS, see Stereotyped Operations Supported by BDC on MSDN.

External Data and Search

The SharePoint search service uses ECTs to crawl external data sources for search. To support search crawls, the ECT must include the following types of stereotyped operations:

  • An IdEnumerator method. This type of method returns the identity values for each instance of an ECT entity. You can support incremental indexing by configuring the IdEnumerator method to return a field that represents the last modified date and time, because this enables the search service to establish whether an item has been modified since the last search crawl.
  • A SpecificFinder method. This type of method returns a single entity instance when provided with the unique identifier for that item.