The BDC uses ADO.NET, OLEDB, or ODBC drivers to connect to practically all popular databases, and it can also use Web services to connect to business applications that support that method of retrieving data. For example, using the BDC, you can display data from SAP or Siebel applications using Web services.
Before the business data can be used within SharePoint Server 2007, it must be declared. A single XML file details the data connection and data formats, known as metadata, for a data source or business application-that is, the metadata describes the APIs of the data source or business application. Administrators use this XML file, known as the application definition file (ADF), to register the data source in the BDC. Thereafter, SharePoint Server 2007 uses the declared APIs to access data from the data sources or business applications.
The BDC is not the only Microsoft technology with which you use an ADF file. You use an ADF to build a notification application on the SQL Server 2005 Notification Services platform. Each ADF at the moment conforms to a different schema.
The BDC is a shared service-ust as user profiles, My Site, audiences, and Excel Services are-and therefore, it stores the metadata defined in the ADF within a set of SQL Server tables in a Shared Services database. All the tables associated with the BDC are prefixed with the two characters AR, which stand for Application Registry, the initial name for the BDC. After the metadata is imported into SharePoint Server 2007, the LOB data is made immediately available to any Web applications associated with that Shared Services Provider (SSP) by using one of the following features:
Business Data Web Parts, of which there are six included with SharePoint Server 2007.
Business Data in lists and libraries.
Business Data actions. This feature allows you to use the business application user interfaces and forms that you might already use and don't want to rewrite.
Links to business data. Wherever business data is exposed, it is possible to display a link to it.
Business Data search. SharePoint Server 2007 can index LOB systems registered in the BDC, and therefore, users can search from data held in any business application. This makes the search function more powerful without a great deal of work.
Business Data in user profiles. For the very first time, with SharePoint Server 2007, you can now place enterprise data in the user profile store.
Custom code developed by using the administrator or runtime application programming interfaces (APIs). If custom Web Parts are required, developers can develop code against the BDC API instead of a multitude of APIs.
Figure 12-1 shows the high-level interaction between the data sources, metadata, features, and applications.
Figure 12-1: High-level architecture of the Business Data Catalog
Although this book is focused on administrator tasks, it is important you understand the administrative tasks in relationship to the other tasks that need to be completed for a successful solution based on the BDC. In the SDK, a development life cycle is described that involves four roles: a business analyst, metadata author, administrator, and developer. Administrators take over the ADF when a metadata author has finished creating and testing the ADF. They will also be involved with the developer if any applications, Web Parts, or formatting of search results are required. Therefore, administrators will need a high-level understanding of at least the metadata and the BDC APIs.
Writing the metadata is a key activity. Metadata is usually created by a business analyst together with a metadata author, who can be the business analyst, a developer, or database administrator (DBA). Between the two of them, the business analyst and metadata author have knowledge of the business application or database as well as how the data will be used. They do not need to be able to code. After the metadata is defined, a user with administrator rights then imports the metadata into SharePoint Server 2007 at the SSP level.
One purpose of the metadata is to describe how the BDC shared service will obtain the data from the business system-that is, it describes the API. Another purpose of the metadata is to add meaning to the API and data. It describes what can be done with the API and the relationship between the data entities.
The metadata is described in an XML file, called the application definition file (ADF), and looks similar to that shown in Figure 12-2, which illustrates the main metadata object definitions. The administrative Web pages also use some of the same terminology, and therefore, you need to become familiar with them.
Figure 12-2: A sample application definition file
To get started with the BDC, you can find sample ADFs for mini-scenarios that use the Adventure Works SQL sample database in the Office SharePoint Server 2007 SDK. There are also two utilities that will help you create the XML tags for the ADFs, both unsupported. First, there is the SQL database metadata generator available with Codeplex, http://www.codeplex.com/Wiki/View.aspx?ProjectName=DBMetadataGenerator, which will produce a simple ADF. Second, there is the MOSS BDC MetaData Manager, which can be found at www.mossbdcmetadatamanger.com. Although dated, XML files for the pubs SQL sample database, can be found in the "B1TR Definitions" download at: http://www.gotdotnet.com/codegallery/codegallery.aspx?id=. This site also has an active discussion forum.
The ADF contains a hierarchy of XML elements, each containing text or other elements that specify the application settings and structure. The ADF must conform to the standards for well-formed XML, so all element names are case sensitive. The ADF must also conform to the schema described in bdcmetadata.xsd, which is in the Microsoft Office Servers\12.0\Bin folder.
To configure Microsoft Visual Studio 2005 to use the bdcmetadata.xsd for IntelliSense, place a file named, for example, bdschema.xml in the folder %ProgramFiles%\Microsoft Visual Studio 8\XML\Schemas, with the following lines of code:
<SchemaCatalog xmlns="http://schemas.microsoft.com/xsd/catalog"> <Schema href="file:\\C:\Program Files\Microsoft Office Servers\12.0\B in\bdcmetadata.xsd" targetNamespace="http://schemas.microsoft.com/office/2006/03/ BusinessDataCatalog" /> </SchemaCatalog>
The metadata hierarchy can be seen by reviewing the XML tags of the ADF, which defines a single LOB system and consists of an XML root node, LobSystem. Following is a list of the main metadata XML tags: (For a list of all metadata tags, refer to http://msdn2.microsoft.com/en-us/library/ms544699.aspx.)
LOBSystemInstance This object provides authentication and the connection string information.
Entity This is the key object of the metadata. An entity relates to a real-world object, such as an 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 entity. A method is a function that makes calls on the data source to locate an instance or instances of a particular entity. 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 Server 2007 needs to know to call that method and, therefore, can be likened to interface descriptions. For each method, you should create at least two MethodInstance XML tags. A method instance defines the way to call the method plus default values for its parameters. Some systems, such as SAP, have methods that can be called in multiple ways, depending on the parameters passed. A method instance eliminates the need to duplicate the metadata. Using a method instance, you can define a method as a Finder method, which will return one or more instances of an entity, or as a SpecificFinder method, which will return a specific instance of an entity.
If you want the data source to be indexed by SharePoint Server 2007, there must be a method of type IDEnumerator. This method allows the indexer to crawl all instances of the entity that are exposed by the IDEnumerator method. If an incremental crawl of the data source is also required, a LastModifiedDate property must be one of the return fields in the SpecificFinder method. This abstraction provides the ability to create generic business data Web Parts, business data searches, and user profiles; it also adds business data features such as lists and libraries.
Filters These limit the number of entities returned from a method.
Actions These provide a link to the back-end data source 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 LOB application's Web site. Actions are associated with an entity, and therefore, wherever the entity is displayed the action will be visible.
Associations These link related entities within an LOB system. For example, if there are two entities, named Authors and Books, an association should be created to link authors to the books they have written.
The Business Data Catalog (BDC) provides two sets of APIs. Administrators need to have a high-level understanding of when these APIs are used, as that knowledge will help them predict network bandwidth usage. The built-in features of the BDC use the following two APIs:
Administration This API creates, reads, updates, and deletes objects within the metadata. All of the SharePoint Server 2007 built-in features use this API. For example, the BDC Shared Services administration Web pages use this object model to import the ADF, as does the business data picker in any of the business data Web arts. The BDC caches all the metadata objects, so most of the time a call to the Administration API will result in manipulating metadata objects from the cache instead of making round-trips to the Shared Services database. The caching of the metadata provides faster access to metadata. If the BDC sees a change to a metadata object, it clears and then loads the cache.
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.
Runtime This API abstracts the interface between the application solutions and the data sources. Therefore, developers need to understand only one object model to extract data from the business sources. The runtime object model calls the administration object model to find the location and format of the data so that it can call the appropriate provider, which in turn gets the business data. This process causes network traffic between the Web front ends and the business application server. Examples of the built-in features that use this API are business data Web arts, the Retrieve data link, and the refresh icon in the business data column of a list or library.