Business Data Catalog: Development Scenarios

This topic describes common development scenarios for using the Business Data Catalog in real-world business situations.

Metadata Authoring

The scenarios in this section show how you author metadata for Business Data Catalog solutions.

Displaying Business Data with the Business Data Catalog

This scenario describes how three roles—business analyst, metadata author, and administrator—transform a business requirement into a business application using the Business Data Catalog.

  • A business analyst defines the business requirements and communicates them to a metadata author.

  • The metadata author takes these business requirements and creates the metadata for the line-of business (LOB) application involved, defining the necessary entities, actions, and associations.

  • The metadata author thoroughly tests the metadata in a test environment by importing the metadata using SharePoint 3.0 Central Administration. The metadata author gives the metadata package, which is in the form of an XML file, to the administrator.

  • The administrator deploys the metadata package on the server and configures security and authentication settings.

  • The business analyst uses Business Data features such as Business Data Web Parts and Business Data columns to display business data on the portal site.

For an example of metadata authoring, see the AdventureWorks SQL Server 2000 Sample.

This scenario describes how you can enable searching of business data that is located outside of Microsoft Office SharePoint Server 2007 in your portal site.

When the metadata author uses the business requirements from the business analyst to create the metadata, the metadata author also defines a FindSpecific method (a SpecificFinder) that returns the details of an entity instance and an IDEnumerator method that returns the list of IDs (unique key) for each entity that should be searchable.

This definition enables indexing of the entities whose IDs the IDEnumerator method returns. If you require incremental crawl, then you must also make sure that one of the return fields in the IdEnumerator for the entity represents the time the entity instance (or row in database terminology) was last updated in the LOB application. You should then set the __BdcLastModifiedTimestamp property of the entity with the name of the TypeDescriptor in the return value of the IDEnumerator that represents the last modified date.

After the metadata author tests the metadata, the administrator deploys it on the server and creates a Business Data Catalog content source to index the business data. Business data becomes available for search after the crawl rules are executed.

To learn how to define IDEnumerators and enable Business Data search, see the AdventureWorks SQL Server 2000 Sample.

Enabling Editing of Business Data from a Portal Site

This scenario describes how to enable editing of business data from a portal site.

Note

Carefully consider whether you need to enable editing of business data from a portal site. The real value of Enterprise Application Integration (EAI) is in reach, composite applications, and portal services. You should use a portal site only as an access point to an LOB application or multiple LOB applications. Replicating the LOB application user interface and business logic may not be a good use of your time, and in such scenarios, you should consider using the LOB application itself. However, you can consider replicating it in scenarios where the LOB application user interface or business logic is poor or when you just want to provide some shortcuts for your portal users to edit common data.

The metadata author and the developer choose from one of the available options for enabling the editing of business data from the portal site. Following are some of the options:

  • Add an action to tie to the native application’s user interface.

  • Add an action to open a Microsoft Office InfoPath form that writes back to the LOB application using writable Web services.

  • Define a writable method in the metadata (a MethodInstance of type GenericInvoker), and invoke the method from a custom Web Part. This is particularly useful if you want to simplify back-end server method calls by making use of default values in the metadata judiciously.

For a simple Business Data Action sample, see the AdventureWorks SQL Server 2000 Sample. More complex samples will be included in future releases of this SDK.

Building Custom Applications

The following scenarios describe how to use the Business Data Catalog to build custom applications.

Writing a Custom Web Part or a Console Application to Display Business Data

You can use the Runtime object model in a Web Part or console application to query the metadata database and display data from a back-end application. Using the Runtime object model, you can invoke methods and display business data on a page.

For samples, see How to: Get Started with Using the Runtime Object Model.

Creating a Tool to Create and Manage Metadata

Business Data Catalog offers an Administration object model that you can use to create, edit, and delete metadata. The main goal of the Administration object model is to enable you to write tools that simplify the creation and administration of metadata.

You can use the Administration object model to create a Windows Form or a Web application for managing metadata.

For an example of using the Administration object model to work with metadata, see How to: Get Started with Using the Administration Object Model.

Mapping to User Profile Properties

Business Data Catalog allows you to bring data from business applications to user profiles. You could, for example, add a spouse's name or your Social Security number from an SAP or Siebel application registered in the Business Data Catalog to the user profiles.

See Also

Tasks

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

Concepts

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