Business Data Catalog: Architecture

The Business Data Catalog is a Microsoft Office SharePoint Server 2007 shared service. It stores information about business applications that exist outside of Office SharePoint Server 2007 and enables business data features and custom solutions to use that information to display business data on the portal site without additional code.

Business Data Catalog Components

Business Data Catalog comprises a metadata database and an object model that provide a simple, consistent object-oriented programming interface for business logic that lives in the various business applications.

The following figure is a high-level architecture diagram of the Business Data Catalog, showing the interaction between business data sources, the metadata database, and business data features and solutions.

Business Data Catalog high-level architecture

The following figure shows the low-level architecture of the Business Data Catalog, including the interaction between the metadata database and the Runtime and Administration object models.

Business Data Catalog low-level architecture

Metadata Database

Business Data Catalog uses metadata to describe the APIs of business applications. After the foreign API description is registered in the Business Data Catalog, it provides dynamic data access connections to the back-end 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 are used to access data from the AdventureWorks database.

The metadata author defines the metadata for each data source by defining the business entities that applications interact with and the methods available in the business applications. In the AdventureWorks example, you might decide to define the metadata for the following entities: Customer, SalesOrder, and Product. For each entity that you want to make available in the Business Data Catalog, you define metadata for the methods that will be used to fetch the data from the back-end server application.

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 metadata model simplifies use of the metadata by defining semantic metadata such as entities and relationships that add meaning to the API. After the metadata is written, developers who program custom solutions using the Business Data Catalog do not need to understand the back-end API but can use the simplified Business Data Catalog object models instead. For example, the runtime object model provides calls such as System.Entity, Entity.FindFiltered, and Entity.FindAssociated, which make it very intuitive for you to get the back-end data you need. This design makes it easier for both metadata authors and developers to work with line-of-business (LOB) applications that typically have complex APIs.

The Business Data Catalog stores the metadata in the metadata database. Because Office SharePoint Server 2007 implements the Business Data Catalog as a shared service, the metadata database is the SharedServices#DB database in an Office SharePoint Server 2007 deployment. The Shared Services database is relational and is a standard Microsoft SQL Server database. The Shared Services database contains several tables specific to the Business Data Catalog that store the different elements of the metadata model.

For more information, see Business Data Catalog: Metadata Model.

Runtime Object Model

The Runtime object model is designed for use by the Business Data Catalog clients and applications. The Runtime object model has two major functions.

• It offers an intuitive, object-oriented interface that abstracts the underlying data sources. The Runtime object model insulates the client from learning application-specific coding paradigms, and allows clients to access all business applications in a single, simplified way. Because of the Runtime object model, calling a method on an SAP application is very similar to calling a method on Siebel or executing a query in SQL.

  Note

  The Business Data Catalog does not perform the actual method execution or back-end plumbing. It merely delegates the client invocation to the appropriate ADO.NET provider for databases and Web services proxy for Web services.

• It allows you to read the metadata objects from the metadata database and execute the business logic described there. The runtime object model is cached and fast, so clients that just need to query the metadata database for metadata information use the Runtime object model.

The Runtime object model is defined in the following namespaces in the Microsoft.SharePoint.Portal.dll:

• Microsoft.Office.Server.ApplicationRegistry.MetadataModel

• Microsoft.Office.Server.ApplicationRegistry.Runtime

There are two key objects in the Runtime namespace. These are the following.

• IEntityInstance. Conceptually, you can think of an entity instance as a single row of data returned from a backend business application in the Business Data Catalog. The IEntityInstance interface abstracts the underlying data sources and insulates the clients from having to learn application-specific coding paradigms and allows them to access all business data in a single, simplified way. It is because of the IEntityInstance interface that you can work with a row of data from a database in just the same way as working with a complex .NET structure returned by a Web Service.

  An entity instance in the Business Data Catalog has special semantics attached to it. For example, it has the ability to know which field(s) in the row represents the identifier for the entity instance and enables to you 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 is very useful when the backend returns huge amounts of data.

  

Administration Object Model

The Administration object model allows you to create, read, update, and delete metadata objects in the Shared Services database. It has relatively high latency and a delay of up to a minute before the Business Data Catalog updates the cache in all the front-end Web servers and application servers in the deployment. The changes are immediate on the server where you make the change.

Developers and users of the Business Data Catalog administration user interface use the Administration object model to create and edit metadata.

The Administration object model is defined in the Microsoft.Office.Server.ApplicationRegistry.Administration namespace in the Microsoft.SharePoint.Portal.dll.

Infrastructure Component

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

The Infrastructure component is defined in the Microsoft.Office.Server.ApplicationRegistry.Infrastructure namespace in the Microsoft.SharePoint.Portal.dll.

Executing Methods: Flow of Control in a Business Data Solution

To understand how Business Data features and custom solutions use the Business Data Catalog, consider the following scenario. Let’s say you want a Business Data Web Part to display information from an SAP application. To do so, the Web Part must have information about the methods it will invoke and the parameters the backend methods will accept. To get that information, the Web Part uses the Runtime object model to query the metadata database where the Business Data Catalog stores the BAPI information. The Web Part again uses the Runtime object model to invoke the BAPIs and display the data on the page.

The following figure shows the high-level flow of control that occurs when a method is executed.

Flow of control when executing a method

Metadata Caching

To provide better performance, the Business Data Catalog caches all the metadata objects. 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 faster access to metadata objects to the clients that are calling them.

The Business Data Catalog caches the objects when they are first loaded. A timer running on each server looks for any changes to the metadata objects once every minute. If it sees a change to a metadata object, it clears and loads the cache again. 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.

The following figure is a deployment diagram for the Business Data Catalog, and shows how caching works.

Deployment and caching in Business Data Catalog

See Also

Tasks

AdventureWorks SQL Server 2000 Sample
How to: Get Started with Using the Administration Object Model
How to: Get Started with Using the Runtime Object Model

Concepts

Business Data Catalog: Metadata Model
FAQ: Business Data Catalog
Business Data Catalog: Glossary

Other Resources

Business Data Catalog