Result Set Filters

A result set filter is a custom Java class an experienced developer writes in order to specifically manipulate the rows or columns of data returned from a read operation for an MBO.

To write a filter, developers must have previous experience with Java programming — particularly with the reference implementations for javax.sql.RowSet, which is used to implement the filter interface and described in the JDBC RowSet Implementations Tutorial.

Note: Result set filters depend on the sup-ds.jar file, located in the com.sybase.uep.tooling.api/lib subdirectory. For example, C:\Sybase\UnwiredPlatform\Unwired_WorkSpace\Eclipse\sybase_workspace\mobile\eclipse\plugins\com.sybase.uep.tooling.api_<version_and_timestamp>\lib.

When a read operation returns data that does not completely suit the business requirements for your MBO, you can write and add a filter to the MBO to customize the data into the form you need. Developers can write a filter to add, delete, or change columns as well as to add and delete rows.

You can chain multiple filters together. Multiple filters are processed in the order they are added, each applying an incremental change to the data. Consequently, Sybase recommends that you always preview the results, taking note that the MBO has a different set of attributes than it would have had directly from the read operation. You can map and use the altered attributes in the same way you would a regular attribute from an unfiltered read operation.

Note: The filter interfaces are defined in terms of java.sql.ResultSet and java.sql.ResultSetMetaData, but these standard JDBC interfaces tend to be read-only implementations. To change data, use a CachedRowSetImpl object instead. This object implements ResultSet but also allows you to modify row data.

Example: a simple SELECT statement filter

Suppose you have an MBO based on this query that returns customer information, and you do not want first name and last name divided between two columns (fname and lname) :

SELECT * FROM sampledb.customer

Instead, write a filter that replaces these columns with a single concatenated "commonName" column.

Note: You could also implement the above example with a more advanced SQL statement with additional computation in the MBO definition:

SELECT id, commonName=fname+' '+lname, address, city, state, zip, phone, company_name FROM customer

Example: two separate data sources filter

Suppose you have customer data in two data sources: basic customer information is in an SAP® repository, and more complete details are contained in another database on your network, for example, SQL Anywhere®. You can use a result set filter to combine the SAP customer data with detailed customer data from the database, so that the MBO displays a complete set of information in a single view. You can accomplish this by:
  1. Creating a filter for the SAP backend and add it to an SAP MBO.
  2. Add a JDBC connection for the SQL Anywhere backend in the filter, then use the SQL Anywhere data to filter the SAP result.
  3. Validate the results are what you expect upon completion. When you synchronize the SAP MBO, you should see data from both SAP backend and SQL Anywhere backend.
Parent topic: Mobile Business Object Mobility Properties
Related tasks
Filtering Result Sets Returned by Attributes
Writing a Custom Result Set Filter
Adding Result Set Filters
Validating Result Set Filter Performance
Previewing Mobile Business Object Attributes
Binding an SAP Data Source to a Mobile Business Object
Binding a Web Service Data Source to a Mobile Business Object
Binding a Database Data Source to a Mobile Business Object