Consuming Web Services with the Business Data Catalog (BDC)

Line-of-business (LOB) systems often contain an organization's most valuable data, but accessing that data can require specialized training. This can make the data accessible to only a few knowledgeable users. One way to make the data more accessible is with the SharePoint platform. You can create SharePoint applications that collect data from LOB systems, merge it, and present it to users as a single view. Users can access this data with SharePoint's familiar user interface (UI). The Partner Portal is an example of such an application. The Business Data Catalog (BDC), which is included in Microsoft Office SharePoint 2007, is a convenient way to integrate data from back-end, LOB server applications. The Partner Portal application shows how to use the BDC with Web services to access LOB data.

BDC Mediated Integration

The BDC mediates between services and consumers. Instead of directly accessing the LOB systems, a SharePoint application uses the BDC to mediate interactions between the systems and the application's Web Parts.

The BDC integrates business data that is available either through Web services or from databases. A feature of the BDC is that you can construct read-only operations with XML. You do not need to write any code. If you need write operations, you can either use custom-coded Web Parts to access the BDC programmatically or InfoPath Forms Services. For an example of a custom Web part that uses the BDC, see Product Catalog. For more information about integrating the BDC with InfoPath Forms Services, see Editing Business Data Using Business Data Catalog Actions and InfoPath Forms Services on MSDN.

The following illustration shows how the Partner Portal uses the mediated integration pattern.

Partner Portal's use of the mediated integration pattern

Because they use the BDC as a mediator, the Web Parts can communicate with the LOB systems without requiring any information about a specific service implementation.

Understanding the BDC Metadata Model

To mediate between the LOB systems and the SharePoint Web Parts, the BDC uses a metadata model that specifies the systems, entities, and operations of the LOB systems that will be exposed through SharePoint. These elements are defined in an application definition file. This file must follow the format of the BdcMetadata.xsd schema file. It is located in the installdirectory:\Program Files\ Microsoft Office Servers\12.0\Bin folder.

To create an application definition file, you should understand the following metadata objects:

• LOBSystem
• LOBSystemInstance
• Entity
• Method
• Association
• Action

For detailed information about these and other metadata objects, see Business Data Catalog: Metadata Model on MSDN.

The Finder and SpecificFinder Methods

Two methods with special significance are the Finder and the SpecificFinder methods. The Finder method returns all instances that represent the business entity and those instances that meet the criteria specified in the filters. The SpecificFinder method is invoked whenever there is a key-based lookup. This means it returns only one instance or row of data. The methods in an entity can be marked as Finder or SpecificFinder. There can be only a single Finder method and SpecificFinder method for each entity, and a single method can act as both a Finder and a SpecificFinder method.

Using the BDC Definition Editor

Defining the metadata model in the application definition file can be time consuming and error prone. The Business Data Catalog Definition Editor, which is provided in the SharePoint Server 2007 SDK, helps you to write this file. It uses a graphical user interface and automatically creates entities and methods from the database metadata and WSDLs. For a demonstration of how to use the editor, see Creating a Web Service Connection by Using the Business Data Catalog Definition Editor.

Use the BDC Definition Editor to create the initial application definition file. Typically, you must then manually edit the file to customize it for your particular scenarios. For information about how to manually write BDC metadata, see Authoring Metadata on MSDN. Some of the situations that require you to manually edit the application definition file include the following:

• You want to change the LOBSystemInstance object properties to provide different connection strings between the development, User Acceptance Test, and production environments.
• You want to create user-friendly names for the LOBSystem, LOBSystemInstance, and Entity objects to help end users understand what these objects represent when they see them on the Central Administration page or in the BDC Web Parts.
• You want to make the queries that are defined for the Finder and SpecificFinder methods more precise.

There are also commercially available tools, such as BDC Meta Man, that eliminate the need to manually edit the files and also allow you to reopen the files in the editor if you have manually edited them.

After you define the services, you can use standard BDC Web Parts to access them without writing any additional code. You can also access the data programmatically.

BDC Security Options

The BDC provides different security options to use when you access back-end systems. These options include the following:

• Trusted subsystem (RevertToSelf). The BDC runtime uses its own service account credentials instead of the current user's credentials to access the back-end service.
• Impersonation and delegation(WindowsCredentials). The Web service uses the Windows identity of the user to access the back-end service.
• Single sign-on (Credentials). The BDC runtime uses the single sign-on infrastructure to map the user's identity to other credentials to access the back-end service.

For more information about authentication with the BDC, see Business Data Catalog Authentication on MSDN. For more information about the trusted subsystem approach, see Trusted Subsystem in the Windows Communication Foundation (WCF) documentation and the white paper, Trusted Subsystem Design, on MSDN. For more information about single sign-on, see Single Sign-on on MSDN. You should consider using the WCF if you require more sophisticated security mechanisms. For more information about integration with the WCF service, see Using WCF Services.

Caching

The Business Data Catalog (BDC) caches the metadata information it uses such as service definitions, operations, and associations. However, in the case of the retrieved back-end data, the BDC Web Parts and the underlying BDC data infrastructure do not provide a built-in caching mechanism. Calls are made to the back-end data source each time the data is accessed. The frequency of these calls may negatively affect an application's overall performance. The only way to provide caching and to use the BDC is to either to implement your own Web Parts or to code your business components. You can do this for frequently accessed or computationally intensive views while relying on the standard Web Parts for the rest of the user interface.

The Partner Portal application uses custom Web Parts in the product catalog to cache navigation, product, and category information. The site navigation menu uses the BusinessDataCatalogSiteMapProvider Web Part. The product details page uses the ProductDetails Web Part and the RelatedParts Web Part.

Cached information is kept in an instance of the ASP.NET System.Web.Caching.Cache class. This is a local in-memory cache, which could be different in different in a Web front end server. Using an in-memory cache is an acceptable technique for information that changes infrequently or at predictable intervals. There is a risk that a user will see outdated information if the back-end data changes before the cached data expires on a server within a farm.

The Contoso.LOB.Services.Client\Repositories\CachedBdcProductCatalogRepository.cs file demonstrates the implementation of the caching mechanism. For more information, see Caching in SharePoint.

Home page on MSDN | Community site