BDC Model Infrastructure
Applies to: SharePoint Server 2010
In this article
What Is Metadata?
BDC Metadata Model
BDC Model Basics
Best Practices
A major design goal for Business Data Connectivity (BDC) service is to enable you to expose data from various external systems such as CRM, ERP, and databases in Microsoft Office 2010 applications and Microsoft SharePoint Server 2010 with minimal coding effort. To achieve this goal, BDC provides homogeneous access to the underlying data sources through a declarative BDC metadata model that provides a consistent and simplified client object model.
In this model, experienced users or developers enter information about the external system into the metadata catalog by using tools such as SharePoint Designer or Visual Studio. Users, business analysts, and application developers then interact with this component indirectly by using the Microsoft Business Connectivity Services (BCS) features and the object model.
This section of the SharePoint 2010 SDK shows the metadata model containment hierarchy, describes the members, and gives examples of the members' use.
What Is Metadata?
Metadata is data about the APIs of the external systems. For each external system, metadata defines the business entities that the application interacts with and the methods that are available in that application. Power users and developers define metadata by using SharePoint Designer or Visual Studio. BDC stores the metadata in the BDC Metadata Store.
Metadata is data about the external system, not the external data itself. External data exists only in the external system (although a cached copy exists in the BCS client cache if external lists taken offline).
BDC Metadata Model
The BDC Metadata Model (BDC model) is the core of BDC. The data structures such as Entity (external content type) and Method that abstract out complex details about an external system are collectively named MetadataObjects, and comprise the BDC model. The BDC model for an external system is essentially an XML file. It is autogenerated when you create an external content type in SharePoint Designer. After you create and upload a model to the BDC Metadata Store on the server that is running SharePoint Server, the external content types defined in the model can be used at any time within SharePoint Server and inside Microsoft Office applications (such as Microsoft Outlook, Microsoft SharePoint Workspace and Microsoft Word) to show external data contextually by using the presentation features of Business Connectivity Services and by custom solutions.
The following diagram shows the hierarchy of the metadata objects.
Figure 1. Hierarchy of metadata objects
.gif "Hierarchy of metadata objects")
You can look at the BDC model at any time by using the Export option in the BDC Application Service page in SharePoint Server Central Administration or by using the Export option for an external content type in SharePoint Designer.
LobSystem
An LOBSystem represents an external service or software system, typically consisting of some business logic operating on data (data could be in a relational store or any other persistent data storage medium). The business logic is represented through a façade of APIs. These APIs define permissible operations and predefined constraints.
In a BDCmodel, typically an LobSystem element contains information about how to connect to a specific Type of external system, the set of Entities (external content types) associated with that same external system, and a definition of how to execute against the external system and wrap returned values from it.
LobSystemInstance
An LobSystemInstance is a specific implementation of a given LobSystem. For example a Web service that describes a specific WSDL is an LobSystem, although the URL at which it is hosted is an instance of that LobSystem. The concept of LobSystemInstance helps in modeling multiple hosting instances of a given LobSystem object.
Entity
An Entity (which represents an external content type) describes the structure of a business entity. Conceptually that structure maps to real-life business objects such as customer, order, and opportunity. An Entity corresponds to an external content type in Business Connectivity Services. A BDC entity type consists of at least one or more methods. Fields (known as TypeDescriptors in the BDC model) of the entity are defined by the set of complex types returned by one or more external system methods. Thus, a BDC entity is made up of a set of methods and at run time, the structure of that entity instance is determined from the returned values from the back-end method or methods. In most cases, an entity type has an identity—a set of scalars whose values uniquely identify the entity instance within a collection of entity instances. Each scalar value that is part of the entity’s identity is referred to as an Identifier. The fields of an entity may be simple or complex types. A SimpleType represents scalar (or atomic) types (for example, integer, string), while a ComplexType represents structured fields (for example, an Address). A ComplexType is composed of zero or more fields, which may be scalar or complex types. At every BDC metadata object level, custom properties are supported; each property is made up of name/value pairs which applications can use to extend the model.
Methods and MethodInstances
Methods in the metadata model are abstract descriptions of back-end APIs. They are non-executable elements, whereas MethodInstances represent executable instances of Methods. BDC takes default values that are defined in the model and appropriate inputs from the application at run time, determines the back-end API based on the Method and MethodInstance, and executes it. MethodInstances are stereotyped to a pre-defined BDC operation like Create, Update, ReadSingle (known as SpecificFinder), ReadMultiple (known as Finder), Delete, and so on. There are 20 stereotypes that BDC defines. All are based on very well-known data mutation patterns used in systems such as databases and Web services. The primary reason that the stereotypes exist is to provide a domain neutral and back-end neutral data access interface that can be used by personas who do not know intricate details about the back-end systems. By using default values and stereotypes, one can make invocation of rich and complex back-end APIs very easy for a typical information worker who does not want to know details about the complex systems.
Associations
Associations in BDC represent relationship between entities (external content types). However, because BDC intends to provide a uniform interface across various kinds of back-end systems, an Association cannot be modeled like a relational database relationship. An Association in BDC points to certain business logic (or an API) on the back-end system that takes a set of entity instances and returns a set of instances of another type of entity. Unlike relational databases, BDC cannot ensure referential integrity because BDC does not control the relationship logic, which is explicitly controlled by the external system.
BDC Model Basics
Explore the following topics in this section to learn the basics of BDC models.
Best Practices
Metadata that is stored in the Metadata Store in Microsoft SharePoint Server 2010 describes the structure of an external system. Metadata is available to everyone to enable discovery and connection to an external system. Because the metadata is meant for general consumption, and can be downloaded from a SharePoint Server and archived on client computers, it is best to limit the amount of information in the metadata. For example, you should avoid the use of inline SQL statements in the metadata for database external systems because they might provide information about the database structure. Instead, it is recommended that the metadata for database external systems uses stored procedures.