Introducing the Business Data Catalog

Microsoft Office SharePoint Server (MOSS) 2007 provides a service called the Business Data Catalog (BDC). The primary purpose of the BDC is to unlock and expose data held in back-end line of business (LOB) applications so that people, processes, and other information can easily and seamlessly link to that data. As long as someone (typically a developer) has a solid understanding of the data, the BDC can make that data pervasive throughout the MOSS platform. In this article I look at the architecture of the BDC and, by way of an example, reveal its power.

The Business Data Catalog
As its name suggests, the BDC is a catalog of business data. As such, it doesn't physically store business data. Think of a shopping catalog that you've recently viewed. What does it contain? That's right—descriptions of items that you can then physically go retrieve. So the BDC is a metadata-driven connector that describes the data, describes how to connect and retrieve that data, and physically retrieves the data on request. The data remains in the back-end application, with the BDC acting as a read-only conduit to it. It will cache some data and some data is physically copied into SharePoint but you need to find another vehicle if you want to write to the back-end data.

You can use multiple vehicles to access the data described in the BDC. Out-of-the-box, MOSS lets you access the data through Web Parts, columns in lists and libraries, fields in user profiles, and via search results. And, of course, if you do want to write some code, you can harness the BDC for custom purposes as well. But, as we will see, you can do very powerful things without lifting one coding finger. Figure 1 shows the logical architecture of the BDC.

Describing Data: The Application Definition File
I make it sound so simple by saying you don't need to write any code, don't I? Although this is true, you do need to do some groundwork to describe the data, and this will take effort on the part of the business application owner and someone from IT who's knowledgeable about the physical storage of the data and possible access methods. The application owner will describe the purpose of the data and how it's linked to meet a particular business requirement. The IT person will then create an application definition file (ADF), an XML file that describes the data, and load the file into the BDC.

The BDC supports two data access methods—direct calls to most popular databases via ADO.NET, OLE DB, and ODBC drivers or calls to application-specific Web services that can gather and return the desired data. Because of space limitations, I'll tackle the Web services method at a later time. In this article, I use a simple database example that will expose the data shown in the two tables that Figure 2 shows, with the end result being a page shown in a standard MOSS team site, as Figure 3 shows. The business purpose of these tables is to list all the movies an actor has appeared in. An analysis of the data shows that the ActorId column links the two tables for such a purpose, with the Actor table being the parent table and the Movie table being the child.

Forget the BDC for a second and imagine the main coding stages you'd need to go through to achieve such a result. First, you'd need to identify and connect to the database with suitable credentials. Next you'd need to open the tables and run some queries that return various rows and columns (e.g., one to gather the parent item and one to link the parent to its child items). So you'd need to define the relationship between the parent and child and the columns that you want returned. Finally, you'd need to format and display the returned data.

The BDC removes the complexity of this process, and the ADF essentially describes how to perform each of these stages except data formatting and display. That step is performed by BDCaware Web Parts, list columns, user profile properties, and search.

The ADF must be well-formed and adhere to the schema defined at C:\Program Files\Microsoft Office Servers\12.0\Bin\bdcmetadata.xsd on a SharePoint Web front-end server. The schema defines connections, entities, methods, filters, actions, and relationships. Let's look at each of these components and the associated XML code that I used to deliver our example. You can download the entire XML metadata file from Windows IT Pro's Web site. (Go to http:// www.windowsitpro.com, enter 96772 in the InstantDoc ID text box, then click Download the Code.)

Connections
The LOBSystemInstance node in Listing 1, defines authentication and connection information such as which database instance to connect to and which catalog to open. (Note that some lines wrap because of space limitations.) From an authentication point of view, the BDC can access the database as a system account or as the calling user.

The code shows that I've defined an instance called SpiesInstance. It accesses a table called Spies in a SQL Server database called dc2\sqlexpress using the credentials of the calling user. The calling user therefore will need permissions to access the data.

Entities
An entity describes an item in the LOB application. The code in Listing 2, defines two items: an actor and a movie. Each entity contains child nodes that define identifiers, methods, filters, and actions. Think of the identifier as the primary key within a database table. It uniquely identifies a particular instance of an entity, which, in our case, are the primary keys called ActorId and MovieId. (Note some sound advice from a badly scarred human being: The XML is case-sensitive so make sure the names match the database columns.)

The properties node defines some characteristics of the entity. The code in Listing 2 shows that the ActorName and MovieName columns will be the default display value that's returned for the entity. It also associates a default action called View Profile that I discuss later.

   Previous  [1]  2  3  Next