Writing a Custom Result Set Filter

Write a custom result set filter to define specific application processing logic. Save the compiled Java class file to location that is accessible from Unwired WorkSpace.

In the custom filter, configure attribute properties so that the returned record set can be better consumed by the device client application. Sometimes, a result set returned from a data source requires unique processing; a custom filter can perform that function before the information is downloaded to the client.

Data in the cache is shared by all clients. If you need to identify data in the cache to a specific client, you must define a primary key attribute that identifies the client (such as remote_id or username).

(Required) Create a record set filter class that implements the com.sybase.uep.eis.ResultSetFilter interface.

This interface defines how a custom filter for the data is called.
For example, this code fragment sets the package name and imports the required classes:
```
package com.mycompany.myname;
import java.sql.ResultSet;
import java.util.Map;
```
(Recommended) Implement the com.sybase.uep.eis.ResultSetFilterMetaData interface as well as the com.sybase.uep.eis.ResultSetFilter interface on your filter class.

If you choose not to implement this interface, Unwired Workspace will have to execute a chain of mobile business object operations and filters and fetch real data before you can see the actual output column names and their datatypes. By first implementing these interfaces, the operation does not need to be executed first. Instead, the getMetaData obtains the necessary column or data type information.
This example sets the package name but uses a different combination of classes than in the example for step 1:
```
package com.mycompany.myname;
import java.sql.ResultSetMetaData;
import java.util.Map;
  
```
Call the appropriate method, which depends on the interfaces you implement.

ResultSetFilter filters the data in the first option documented in step 1. Each filter defines a distinct set of arguments. Therefore, use only the arguments with the appropriate filter that defines these arguments in getArguments(), rather than use all filters and data source operations.

The result set passed in contains the grid data, which should be considered read-only—do not use operations that change or transform data.
```
public interface ResultSetFilter {
   ResultSet filter(ResultSet in, Map<String, Object> arguments) throws
     Exception;
   Map <String, Class> getArguments();
}
```
Next, use ResultSetFilterMetaData to format the data from step 1. Use this interface to avoid executing an extraneous data source operation to generate a sample data set.
```
public interface ResultSetFilterMetaData {
   ResultSetMetaData getMetaData(ResultSetMetaData in, Map<String,
      Object> arguments) throws Exception;
}
```
Note: If the filter returns different columns depending on the argument values supplied, the filter may not work reliably. Ensure that any arguments that affect metadata have constant values in the final mobile business object definition, so the schema does not dynamically change.
Implement the class you have created, defining any custom processing logic.
Save the classes to an accessible Unwired WorkSpace location. This allows you to select the class, when you configure result set filters for your mobile business object.
In Unwired WorkSpace, refresh configured MBO attributes, to see the result.

MBO load operations can take parameters on the enterprise information system (EIS) side. These load parameters are defined from Unwired WorkSpace as you create the MBO. For example, defining an MBO as:

SELECT * FROM customer WHERE region = :region

results in a load parameter named ''region''.

As an example, if you want a filter that combines fname and lname into commonName, add MyCommonNameFilter to the MBO. When MyCommonNameFilter.filter() is called, the ''arguments'' input value to this method is a Map<String, Object> that has an entry with the key ''region''. Your filter may or may not care about this parameter (it is the backed database that requires the value of region to execute the query). But your filter may need some other information to work properly, for example the remote user's zipcode. The ResultSetFilter interface includes java.util.Map<java.lang.String,java.lang.Class> getArguments() that you must implement. In order to arrange for the remote user's zipcode (as a String) to be provided to the filter, write some custom code in the body of the getArguments method, for example:

public Map<String, Object> getArguments {
       HashMap<String, Class> myArgs = new HashMap<String, Class>();
       myArgs.put("zipcode", java.lang.String.class);
       return myArgs;
    }

This informs Unwired WorkSpace that the ''zipcode'' parameter is required, and is of type String. Unwired WorkSpace automatically adds the parameter for the load operation, so this MBO now has two (region and zipcode). Your filter gets them both when its filter() method is called, but can ignore region if it wants.