Validating Parameters

During the configuration phase of a task in the user interface, the user provides configuration values. The values dictate how the task runs. When saving or updating a configuration, the Services Framework sends the user entered values to the task for validation first. The task validates the values by ensuring the integrity of the configuration.

The methods for validation depend on the type of parameter that was defined (manual or configuration). Validation examples are shown here:

public abstract boolean validateConfigParameters (Map<String,TaskParm> configParms)
   throws ParameterValidationException;

public abstract UOW validateManualParameters (Map<String,TaskParm> runtimeParms)
   throws ParameterValidationException;

The map, configParms in the example, passed into the methods contained all the parameters defined by the task and the user entered values. The user entered values can be found in the TaskParm object using the getParmValue() method. For example, to validate the manual parameter for category, the validation could do the following:

TaskParm categoryParm = runtimeParms.get(MANUAL_PARM_KEY_CATEGORY);
String userEnteredCategory = categoryParm.getParmValue();
if (userEnteredCategory != null) {
   " do some validation "
}

Note: It is valid to have a parameter with no parameter value. If no parameter value exists, the task uses the default value.

Validating manual parameters works the same way as validating configuration parameters (described in Configuration Parameters) with one additional step. The return type for the validateManualParameters() is a unit of work object. For best results, when validating is being done, the manual parameter values should be recognized as a single unit of work value.

Example 1

In the FTM database, every business day is represented with a numeric ID. The ID is the primary field on which all components process business days.

To run a custom task manually, instead of using the numeric ID, the task provides site, business day, and category fields for the user to enter. During validation of the entered information, the task validates the fields and does a database look up to find the associated business day ID. It is this ID, which uniquely represents the business day fields entered in the user interface, that is converted into a unit of work.

A unit of work represents a unique piece of data or internal Payment Feature Services IDs that represent a transmission, batch, transaction, or so forth. Units of work are what all tasks work against.

If the manual parameters can be represented as a unit of work object, it is recommended for validation to return a unit of work value back to the Services Framework.

Example 2

Part of the manual validation process is to find the database record in the business day table and retrieve its internal ID, if a user entered the following manual values:

Site=0
Business Date=2009-01-28
Category=C

Table 1. Simulated Business Day Table
ID	Date	Category	State
3	2009–01–28	A	Active
4	2009–01–28	C	Active
5	2009–01–28	F	Active

When all fields are validated and the internal ID is found, the validation is successful and a unit of work object is returned to the Services Framework.

return new UOW(UOW.UOW_TYPE_BUSINESS_DAY_ID, businessDayId);