The BCS is a service
application, just like Form Services, Access Services, and Excel
Services, and you can create a new BCS application just like other
service applications, using one of the following methods.
Farm Configuration Wizard
When you use the Farm Configuration Wizard to create all service
applications and the BCS application is created at that time, the name
of the database is Bdc_Service_DB_<GUID>, where GUID is a randomly generated number. This database is the location for the external content type (ECT) repository or metadata store.
Manage Service Applications Web page
You can create the BCS application yourself and choose your own
database name by using the SharePoint 2010 Central Administration
website and selecting New in the Create group on the Service Application
tab on the Ribbon.
Windows PowerShell You can also create a BCS application using the cmdlet New-SPBusinessDataCatalogServiceApplication.
After the BCS application is
created, the next step is to define the external systems and data that
can be used on your site and on your dashboards. You may need the
following two types of information to present information from your
external systems.
The base metadata for the data stored in the external system
Localized names, properties, permissions, and custom environment settings
A single XML file, known as the
BDC Model, can describe both sets of information; however, you can
separate these two sets of data into the BDC Model file for the base
metadata and a resource file for the localized names, properties,
permissions, and custom environment settings.
The external data
declared in the BDC Model details the data connection, data formats, and
methods, such as create, read item, read list, update, and delete for
the external system. Administrators use the BDC Model to register the
external system in a SQL Server database. Thereafter, SharePoint 2010
uses the declared APIs to access data from the external systems.
After the BDC Model is
imported into SharePoint 2010, the external data is made available to
any Web applications associated that BCS application. Figure 1 shows the high-level interaction between the external data, ECT repository, features, and applications.
The next few
sections cover the following BCS topics.
1. Business Data Connectivity Layer
The BCS data connectivity layer,
or the BDC, uses connectors to access the external systems. The
built-in connectors allow you to connect to databases, cloud-based
services, Windows Communication Foundation (WCF)
endpoints, Web services, the .NET assembly that gathers data from
multiple sources, and custom external systems that have nonstatic
interfaces that change dynamically. An improvement in this version of
SharePoint is the introduction of batch and bulk operation for
retrieving external data. When multiple documents are retrieved, it is
also possible to retrieve the documents in chunks, which reduces the
number of round trips to retrieve the data.
The BCS database, known as the external content type (ECT) repository or metadata store, stores and secures ECT and related objects defined
in the Model. It does not contain external data; it only contains
information about the external system. All the BCS database SQL Server
tables associated with the BCS are prefixed with the two characters AR,
which stand for Application Registry, the initial name for the BCS. The
metadata store is accessed by the BDC administration and runtime interfaces, which are discussed in more detail in the following sections.
1.1. BDC Administration
This interface creates,
reads, updates, and deletes objects within the metadata store. All of
the SharePoint 2010 built-in features will use this interface. For
example, the BCS administration Web pages use this interface to import
the Model, as does the external data picker in any of the external data
Web Parts. The BDC caches all the ECT information, so most of the time a
call to the administration interface will result in manipulating
objects from the cache instead of making round trips to the ECT
repository. Caching objects provides faster access to the ECT. If the
BDC sees a change to an object, it clears and then loads the cache.
Note:
A timer runs once every
minute on each server to look for any changes to the metadata objects.
If the logic within the timer job sees a change, it clears the cache and
then reloads it. Therefore, after you change metadata, you must wait up
to a minute for changes to propagate to all the servers in the farm.
The changes take effect immediately on the computer on which you make
them.
1.2. BDC Runtime
The BDC runtime abstracts
the interface between the application solutions and the external
systems into the BDC object model. The runtime calls the administration
interfaces to find the location and format of the data so that it can
call the appropriate connector, which in turn gets the external data.
This process causes network traffic between the Web front ends and the
servers that host the BCS application. Examples of the built-in features
that use the BDC runtime are External Lists, External Data Web Parts,
the Retrieve Data link, and the Refresh icon in the External Data Column
of a list or library.
BDC is now available on
Office 2010 client applications as well as SharePoint 2010. The Office
2010 client applications include BCS rich client extensions that provide
user interface elements and a symmetrical BDC runtime to the BDC
runtime that runs on the server. The BDC runtime provides an intuitive,
“stereotypical,” consistent object model, independent of the external
system; therefore, developers need to understand only the BDC object
model to extract data from the external systems whether they are
developing code for the client or the server.
The BDC runtime consists of an
infrastructure component to provide runtime connection management and
shared security services to the external systems. Access to the external
systems is the responsibility of the BDC connectors. The BDC runtime,
whether it is on the client or SharePoint 2010, uses the same
connectors, and therefore, the client does not need to connect back to
SharePoint to access the external data.
The Office 2010 clients
have a SQL Compact Edition client database installed that caches
external data and allows access for both online (connected) and offline
(disconnected or cached connection mode). If amendments are made while
the client is offline, they are stored in the client data cache and
committed to the external system when the client is next online.
Note:
The SQL Server CE database also contains a transient, in-memory optimized copy of the BCD Model.
2. External Content Types
External content types (ECTs) are
a new concept in SharePoint 2010 and are the building blocks of BCS,
similar to the entity object in SharePoint Server 2007. External content
types refer to external data objects and defines the fields, methods,
and the behavior of the data in SharePoint and Office client
applications. Both read and write capability is included, along with
batch and bulk operation support. ECTs are defined in the BDC Model. The data objects defined by the ECTs can be displayed on SharePoint 2010 sites using
Web Parts, External Columns in lists and libraries and in External
Lists, or in Office 2010 applications where ECTs are the framework for
creating Office Business Applications or OBAs.
3. BDC Models and Resource Files
External content types are metadata objects defined in the BDC Model XML file, which usually use the extension .bdcm.
Resource information can be included in the BDC Model file or in a
separate resource XML file, which usually has an extension of .bdcr.
The creation of the base metadata information and the resource
information is an important activity. You can create the base metadata
information using
the External Content Type Designer in SharePoint Designer 2010, Visual
Studio 2010, an XML editor, Notepad, or third-party tools such as bdcmetaman
from Lightning Tools. You can create or configure resource information
after the BDC Model data is imported; for example, you can use the
Central Administration website pages to configure permissions. You can
use Visual Studio 2010 to create a separate file. After you complete the
configuration of the external system, you can export the Model data and
the resource data into separate files using the Central Administration website.
Note:
You can only use SharePoint
Designer 2010 to create a model XML file for SQL Server databases, Web
and WCF services, and .NET connectivity assemblies. For other types of
external systems, you must edit the Model XML file in Visual Studio
2010, an XML editor, or a third-party tool.
The BDC Model is usually
created by a business analyst, a developer, or database administrator
(DBA). Among them, they have the knowledge of the external system or
database as well as how the data will be used. They do not need to be
able to write code, although to import the BDC Model into a BCS
application, they must have Edit permissions at the BCS level, which are
usually assigned to service application administrators of the BCS
application.
One purpose of the Model is to
describe how the BDC runtime will obtain the data from the external
system—that is, it describes the interface. Another purpose of the Model
is to add meaning to the interface and data. It describes what can be
done with the interface and the relationship between the different types
of data. For example, using BCS, you can create, read, update, delete,
and query (CRUDQ) external data in SharePoint and Office client
applications, if the external system supports the operations and is
modeled appropriately in the BDC service.
Note:
Not all Office client
applications can write to the external system, even though the external
system supports the operations and they are correctly modeled in the
BCS. For example, in Word 2010, BCS exposes read-only data in content
controls that map to External Data Columns in a SharePoint document
library, and you can import a BDS Model into Access 2010 to create
read-only tables.
The BDC Model contains a
hierarchy of XML elements, each containing text or other elements that
specify the external system settings and structure. The Model must
conform to the standards for well-formed XML, so all element names are
case sensitive. The Model must also conform to the schema described in
the file Bdcmetadata.xsd. When you have a separate resource file, the
schema definition file is BDCMetadataResource.xsd. Both files are stored
in the TEMPLATE\XML SharePoint installation root folder, which by
default is C:\Program Files\Common Files\Microsoft Shared\Web Server
Extensions\14. The Model looks similar to Figure 2, which illustrates the main metadata object definitions.
The metadata object
hierarchy can be seen by reviewing the XML tags of the Model file, which
defines the data structures, such as Model, LobSystem,
LobSystemInstance, Entity (which represents an external content type),
Method, Parameter, and TypeDescriptor objects, where Lob is the acronym
for line of business, which is another term for external system. Using
these data structures, the Model file describes the external system,
such as the server name, connection string, and authentication method.
Following is a list of the main metadata XML tags. (For a list of all
metadata objects, refer to http://msdn.microsoft.com/en-us/library/ee559369.aspx.)
LobSystem This object represents the external system and is the root note of the Model file.
LOBSystemInstance This object provides authentication and the connection string information.
Entity
This is the key object of the metadata and refers to the ECT. An ECT
relates to information from the external system, such as the author, a
customer, a sales order, or a product. An entity belongs to a single LOB
system and must have a unique name. Entities contain identifiers,
methods, filters, and actions. Each entity should define two properties:
an identifier (which, in database terms, is the primary key) and a
default column. An identifier is used to uniquely identify a particular
instance of an entity. In SQL terms, this is the column designated as
the primary key. Each entity also consists of a number of child XML
element tags. Following is a description of the key components of or
related to entities.
Methods
These are operations related to an ECT, such as Create, Read Item,
Update, Delete, and Read List. If the data source is a database, the
method is a stored procedure or a SQL statement; if the data source is a
Web service, the method is a Web method. The metadata must detail
everything that SharePoint 2010 needs to know to call that method and,
therefore it can be likened to interface descriptions. For each ECT,
there should be a method defined as a Finder method, which will return one or more instances of an entity, such as Read List, or a SpecificFinder method, Read Item, which will return a specific instance of an entity.
Filters These components limit the number of entities returned from a method.
Actions
These can provide a link to the external system and can be used to
provide write-back scenarios—for example, sending an e-mail, opening a
Microsoft Office InfoPath form that writes back to the LOB application using
a writable Web service, or opening a new browser window pointing to the
external system’s website. Actions are associated with an ECT, and
therefore, wherever the ECT is displayed, the action link will be
visible if an action is defined.
Associations
These components link related entities within an external system. For
example, if there are two ECTs named Authors and Books, you should
create an association to link authors to the books they have written.
This enables you to use Web Part connections to create dashboards with
related information.
Access Control List Defines permissions for the Model objects.
