Specifying Configuration Metadata for Adapter Service
The next logical step for implementing an adapter service is to create the metadata that enables the users of the adapter to create adapter service nodes. To do this, you perform the following:
Create metadata parameters appropriate for the function of the adapter service.
Describe presentation for those metadata parameters.
Set the data entry rules for those metadata parameters.
Creating Parameters for Data Entry
The sample implementation includes five metadata parameters that the users of the adapter use for data entry when they create adapter service nodes. Each parameter has:
An accessor method.
A variable to hold the configured values.
A String constant containing the name of the parameter.
A set of resource bundle entries with a localizable parameter name and description. For information about metadata parameters, see
Metadata Model for Connection.
The following table describes the purpose of each of these parameters for data entry:
Parameter | Description |
tableName | Enables the users of the adapter to select a table to update. |
columnNames | Lists the columns in the selected table for updating. The resource domain lookup for this parameter depends on the value in the tableName parameter. |
columnTypes | Contains the default type associated with the columnName. |
overrideTypes | Enables the users of the adapter to type a different data type for the column value. |
repeating | A Boolean flag indicating whether the service is used to update a single row or multiple rows of the table. |
Specifying the Display and Data Entry Attributes of the "Data Entry" Parameters
After creating the parameters, specify the display and data entry attributes by calling various methods of the
WmTemplateDescriptor interface from the service's
fillWmTemplateDescriptor method.
The example code places each data entry parameter into a single group (in display order) referenced by the constant
UPD_SETTINGS_GRP. A constant instead of a string is used to name the group, because the same value is used in the resource bundle to specify a localizable group name.
Placing the Column Names and Column Data Types Parameters in a Field Map
Next, the example places columnNames and the two types parameters in a field map. The use of two data type columns in the fieldMap warrants further discussion. The desired behavior is to:
Automatically update the data type when the column name changes.
Allow the users of the adapter to enter an alternative data type for the given field.
The adapter must convert the data at run time.
To have the type value change with the columnName, the resource domain associated with the parameter must be "complete" (as specified by the setComplete method being set to true). Users are not allowed to type values into fields of a "complete" resource domain. Because of these conflicting constraints, it is necessary to have two parameters with different resource domain associations: one updated by the adapter service editor, and the other by the users of the adapter.
Placing the Column Names and Column Types Parameters in a Tuple
Finally, the columnNames and columnTypes parameters are placed in a tuple. In a tuple, not only are the resource domain lookups performed together, but the adapter service editor maintains a relationship between the parameter settings such that when value[n] is selected from the resource domain value list for columnNames, then value[n] is automatically selected for the corresponding columnTypes value. Alternatively, you can make a resource domain lookup for columnTypes that depends on the corresponding value of columnNames and then determines the appropriate type in the lookup.