Condividi tramite

BDC Architecture

  • Articolo

Applies to: SharePoint Server 2010

In this article
BDC Model and BDC Metadata Store
Runtime Object Model
Administration Object Model
Infrastructure Component
BDC Connectors and the Connector Framework
Secure Store Service and SharePoint Security Infrastructure
Metadata Caching

Business Data Connectivity (BDC) service succeeds the Business Data Catalog that was provided in Microsoft Office SharePoint Server 2007; in this release, BDC is provided through Microsoft SharePoint Foundation 2010. BDC enables you to declaratively model external systems so that you can surface external data in SharePoint 2010 (and in Microsoft Office applications through Business Connectivity Services Rich Client Extensions). BDC connects SharePoint sites and your external systems by enabling you to bring key data from various external systems into SharePoint lists via the new external lists feature and external data columns, Web Parts, search, user profiles, and custom applications.

BDC is implemented as a shared service in Microsoft SharePoint Foundation 2010 and can be enabled by the Central Administrator. The core function of the BDC is to provide connectivity to the following kinds of external systems:

  • Databases

  • Windows Communication Foundation (WCF) endpoints

  • .NET Connectivity assemblies

  • Custom data sources (BDC provides a framework into which developers can plug in connectors for new external system types to enable access to them via the BDC)

A major design goal for BDC is to enable you to access data from various external systems declaratively, with minimal coding effort. To achieve this goal, BDC provides homogeneous access to the underlying data sources with a Metadata Model that provides a consistent and simplified client object model.

Microsoft Business Connectivity Services (BCS) provides tooling support in both Microsoft SharePoint Designer and Microsoft Visual Studio. Experienced users who have a skill set that is equivalent to that of a database developer can create external content types by describing the API of business applications by using the External Content Type Designer in SharePoint Designer. After the user saves the external content type in SharePoint Designer, the data in the external system is immediately available to his or her SharePoint sites via the other Business Connectivity Services features in SharePoint 2010 and the BDC object model.

BDC is composed of a BDC Metadata Store and an object model that provide a simple, consistent object-oriented programming interface for business logic that resides in the various business applications.

Figure 1 shows a high-level view of BDC architecture.

Figure 1. High-level view of BDC architecture

High-level view of BDC

Figure 2 shows the lower-level architecture of BDC.

Figure 2. Low-level view of BDC architecture

Low-level architecture of BDC

BDC Model and BDC Metadata Store

BDC uses metadata to describe the APIs of external applications. After the API description of an external application is registered in BDC, BDC provides dynamic data access connections to the external data without the need for additional code. For example, to display data from the AdventureWorks database in your SharePoint lists and Web Parts, you define the metadata for the SQL queries that access data from the AdventureWorks database.

An experienced user or developer defines the metadata for each data source by defining the business entities that business applications interact with and the methods that are available in the applications. In the AdventureWorks example, you might want to define the metadata for the following entities: Customer, SalesOrder, and Product. For each entity that you want to make available in BDC, you define metadata for the methods that will be used to fetch the data from the external system.

The Metadata Model abstracts the underlying physical sources and provides a consistent and simple model for metadata authors working with different kinds of business applications.

The BDC Model defines semantic metadata, such as external content types and associations, that add meaning to the API. After writing the metadata, developers who program custom solutions by using BDC do not have to understand the back-end API but can use the simplified BDC object models instead. For example, the BDC Runtime object model provides calls such as System.Entity, Entity.FindFiltered, and Entity.FindAssociated, which make it very easy to get the back-end data that you need. This design makes it easier for both metadata authors and developers to work with external systems that typically have complex APIs.

BDC models are stored in a relational database and loaded or materialized into memory before they can be interpreted by the BDC runtime. The set of database tables and stored procedures for holding, reading, and modifying the BDC Model form the BDC Metadata Store component. This component exists only on server deployments of Business Connectivity Services. The Administration object model should be used to edit the elements of a BDC model instead of editing the database directly. You should NEVER edit the database. On the client, this component is replaced by a transient, in-memory deserialization of the BDC Model in a Microsoft SQL Server 2005 Compact Edition database.

Note

The BDC Metadata Store does not contain external data. It contains only metadata about the external system.

For more information, see BDC Model Infrastructure.

Runtime Object Model

As shown in the previous low level diagram, the BDC public interface has two sets of APIs. The Runtime object model and the Administration object model.

The Runtime object model is designed for use by BDC clients and applications. It has two major functions, as follows:

  • To provide an intuitive, object-oriented interface that abstracts the underlying data sources. The Runtime object model insulates the client applications from learning back-end specific coding paradigms, and enables clients to access all external systems through a single uniform interface. Because of the Runtime object model, calling a method on an SAP application resembles calling a method on a Siebel application, or executing a query on Microsoft SQL Server. By using the Runtime object model, applications can read, write, and update back-end data.

    Note

    BDC does not perform the actual method execution. It only delegates the client invocation to the appropriate ADO.NET provider for databases, Web services proxy for Web services, and .NET Framework assembly for .NET Framework assemblies.

  • To enable reading (only) the metadata objects from the metadata database and execution of the business logic described there. The Runtime object model uses cached metadata in memory and therefore, it is fast. Clients that only have to query the metadata database for metadata information use the Runtime object model.

The Runtime namespace has two key objects:

  • IEntityInstance. Conceptually, an entity instance is a single row of data returned from a back-end business application in BDC. The IEntityInstance interface abstracts the underlying data sources and insulates the clients from having to learn application-specific coding paradigms. It enables them to access all business data in a single, simplified way. By using the IEntityInstance interface, you can work with a row of data from a database in just the same way as working with a complex .NET Framework structure returned by a Web service.

    An entity instance in BDC has special semantics attached to it. For example, it has the ability to know which field or fields in the row represent the identifier for the entity instance and enables you to call methods such as GetAssociated, GetIdentifierValues, and Execute on that entity instance.

  • IEntityInstanceEnumerator. Enumerators can be used to read the data in the collection. But they cannot be used to modify the underlying collection. IEntityInstanceEnumerator supports streaming and is therefore very useful when the back-end application returns great amounts of data.

Administration Object Model

You can use the Administration object model to create, read, update, and delete metadata objects in the BDC Metadata Store. It provides full-fledged metadata validation at publishing time and maintains referential integrity across the store. It uses an in-memory metadata caching for performance. Therefore it has relatively high latency and a delay of up to a minute before BDC updates the cache in all the front-end Web servers and application servers in the deployment. This component exists on the server deployments of Business Connectivity Services. A client-version of the Administration object model exists on the client.

Infrastructure Component

The Infrastructure component is defined in the Microsoft.BusinessData.Infrastructure namespace in the Microsoft.SharePoint.dll.

As shown previously in the low-level architecture diagram of BDC, the Runtime object model relies on the Infrastructure component to create and manage connections to the physical data source. The Infrastructure component provides run-time connection management and shared security services for BDC clients.

BDC Connectors and the Connector Framework

Business Connectivity Services offers connectors to all of the data source types it supports. In addition, it provides extensibility via a provider model. ISVs and partners can develop BDC connectors for the back-end types not supported natively by BDC.

Secure Store Service and SharePoint Security Infrastructure

BDC provides authentication to back-end systems via integrated authentication or single sign on (SSO) in Office SharePoint Server 2007. In SharePoint Server 2010, it also supports claims or token-based authentication. SSO is replaced by Secure Store which is also pluggable. Therefore, if any third party does not intend to use SharePoint Secure Store but instead use custom or any other ISVs SSO, BDC fully supports it.

Metadata Caching

To provide better performance, BDC caches all the metadata objects. In this way, it materializes all metadata objects from the cache and provides them to the Runtime object model at one time, instead of making round trips to the metadata database for each method call. Metadata caching provides clients faster access to the metadata objects they are calling.

Note

Using the object model, you can turn caching on or off at an individual metadata object level. As a result, you do not have to cache objects that are rarely used.

BDC caches the objects when they first load. A timer running on each server looks for any changes to the metadata objects one time each minute. If it sees a change to a metadata object, it clears the cache and then reloads it. As a result, after you change metadata, you must wait up to a minute for changes to propagate to all the servers in the farm. The changes are immediate on the server where you make the change.