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.
You can use the Business Data Catalog to connect to any back-end enterprise application through Web services or databases.
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 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.
The metadata database does not contain business data; it contains metadata about the business application only.
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.
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:
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 Runtime object model allows you to read the metadata objects only from the metadata database. Because it is cached and fast, clients that just need to query the metadata database for metadata information should use the Runtime object model.
The Administration object model is defined in the Microsoft.Office.Server.ApplicationRegistry.Administration namespace in the Microsoft.SharePoint.Portal.dll.
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.
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.
Using the object model, you can turn caching on or off at an individual metadata object level, so rarely used objects need not be cached.
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.