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.
Note
FilterDescriptor is a metadata object whereas filters are run-time objects. FilterDescriptor objects describe the filters available on a method.
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."
Note
The Business Data Catalog uses the wildcard character specified in the LobSystem object metadata for filtering purposes.
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.
Important
If a metadata author creates bad metadata that takes a user name as a user-controllable filter and returns sensitive personal data, a user may see another user's data. To avoid this, use UserContextFilter to pass in the user name to the method call.
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
Child | Type | Occurs | Default | Limits / Accepted Values | Description |
---|---|---|---|---|---|
Type |
Attribute (bdc:FilterDescriptorType) |
1..1 |
true |
Limit Comparison Wildcard UserContext Username Password LastId SsoTicket UserProfile |
Specifies the type of filter. |
Properties
Following are the properties that the FilterDescriptor object accepts for both database and Web service systems.
Important
Properties are case-sensitive.
Property | Type | Required | Default Value | Limits/Accepted Values | Comments |
---|---|---|---|---|---|
UsedForDisambiguation |
System.Boolean |
No |
false |
true false |
If true, this filter is used in the business data picker to generate the list of possible matches. |
CaseSensitive |
System.Boolean |
No |
false |
true false |
If true, the Business Data Web Parts and Business Data picker tell the user this filter is case sensitive. |
IsDefault |
System.Boolean |
No |
false |
true false |
If true, this filter is selected by default in the Business Data picker. |
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