FilterDescriptor

Filters are the fundamental way in which the Business Data Catalog captures user (or system) input and plumbs it through to the backend API invocation. FilterDescriptors describe where in a complex series of parameters, a filter value should be inserted. This is accomplished by 'tagging' the TypeDEscriptors representing complex parameters of a Method definition to flag where the insertion should happen. It is important to note that the backend must supply the functionality for filtering; the FilterDescriptors merely form a mechanism to surface this to the end user. FilterDescriptor objects are owned (contained) inside Method objects. They are subsequently referred by TypeDescriptor objects

Users may want to retrieve the instances of an entity that match some criteria. For example, a user may want to display the customers whose names begin with "A" or the orders made by a certain customer. The API used to retrieve customers requires that this user input be passed in as the third String parameter in the invocation. The metadata author will create a FilterDescriptor of a Wildcard Type, and then tag the third parameter's root TypeDescriptor with this newly created FilterDescriptor. Many such FilterDescriptors may be associated with a single Method (API).Users then choose the filter they want at run time, specify a value for it, and the Business Data Catalog passes that filter's value to the back-end method, inserting it into the exact location where the backend expects it, which causes it to then returns only the rows the user wants to see.

For example, assume the Finder method for the Customer entity is defined as follows:

SELECT * FROM Customers WHERE CustomerID >= lo

Assume the method has default parameter value of lo = 0. The FilterDescriptor metadata states that if the user overrides the lo value, it can limit the range of instances returned. The user, in this case, the user can provide the lo value and see specific results.

Filtering Patterns

Line-of-business (LOB) systems provide various filtering mechanisms. The Business Data Catalog abstracts common patterns so it can provide users with the same filtering semantics, regardless of the data source. The Business Data Catalog supports the following filters and filtering patterns:

• Wildcard filter   Limits the instances returned to those where field like value, where value may contain the asterisk (*) wildcard character. Users can use this filter type to present more user-friendly filters such as "starts with" and "contains."

• Comparison filter   Limits the instances returned to those where the condition is met. SQL supports it with the WHERE clause.

• Limit filter   Limits the number of instances returned to n. SQL supports it with the SELECT TOP clause. By using a Limit filter, you can prevent long waits, time outs and also prevent users from issuing bad queries that request large amounts of data.

• UserContext   Limits the instances by the current user's context. This filter tells the Business Data Catalog to append the current Microsoft Windows user's domain\username to the method call.

• Username   Limits the instances by a single sign-on (SSO) user name. This filter tells the Business Data Catalog to pass the user name from SSO as part of a parameter to the method call.

• Password   Works with the Username filter. This filter tells the Business Data Catalog to pass the password from SSO as part of a parameter to the method call.

  Note

  The back-end method definition should support the filters. Only then can you, in a context-sensitive manner, use filters to reflect in the front-end application the functionality that is available in the back end. The metadata simply declares which filters a method supports.

• UserProfile    A simple filter type you can specify in the FilterDescriptor definition. To use this filter, declare a filter of the type "UserProfile" and add a System.String property with the name "UserProfilePropertyName", whose value is the name of a user profile property. The Business Data Catalog will look up the current user's profile, read the value of the property with this name, and plumb that through to the back-end invocation.

• SSOTicket   Tells the Business Data Catalog to pass the SSO ticket from SSO as part of a parameter to the method call.

• LastIdSeen   Enables chunking for IDEnumerator enumeration members. For Web services and other non-streaming back-end applications, you should use the LastIdSeen filter in your IDEnumerator member to improve performance, as shown in the following example:

  SELECT TOP 100 Id FROM Customers WHERE Id>=@LastIdSeen
  ORDER BY Id
  

User filters such as Comparison declare which inputs users can override, and system filters such as UserContext and UserProfile allow the Business Data Catalog to securely set values such as user token.

Clients query the metadata repository to determine which filters the system supports and render their user interfaces accordingly.

Example

<FilterDescriptors>
      <FilterDescriptor Type="Wildcard" Name="Name">
         <Properties>
            <Property Name="UsedForDisambiguation" 
               Type="System.Boolean">true</Property>
         </Properties>
      </FilterDescriptor>
   <FilterDescriptor Type="Wildcard" Name="ProductNumber" />
</FilterDescriptors>

Schema

Properties

Following are the properties that the FilterDescriptor object accepts for both database and Web service systems.

See Also

Tasks

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

Concepts

FAQ: Business Data Catalog
Business Data Catalog: Glossary