Adapter Development Kit 6.5 | webMethods Adapter Development Kit Documentation | webMethods Adapter Development Kit Installation and User’s Documentation | Adapter Services | Adapter Service Implementation | Implementing Adapter Service Configuration Resource Domains
 
Implementing Adapter Service Configuration Resource Domains
The next step for implementing an adapter service is to:
*Define and implement the resource domains required for the parameters that you established in Specifying Adapter Service Configuration Data.
*Identify the values upon which those resource domains depend.
For each parameter that requires either a resource domain to supply a value or the validation of user-supplied values, you must:
*Call WmTemplateDescriptor.setResourceDomain, passing the name of the parameter, the name of the resource domain, and an array of the names of any parameters on which the resource domain will depend (see lines 86-102 of Code Example 1: WmAdapterService Implementation Class).
*Register the resource domain support in the associated connection class's registerResourceDomain method (see lines 104-117 of Code Example 2: WmManagedConnection Implementation Class Updates).
*Implement code to populate the resource domain values and/or the "check values". This is discussed below.
The first parameter, tableName, is associated with a new resource domain called tableNameRD (line 86 of Code Example 1: WmAdapterService Implementation Class). The list of available tables in this example does not depend on any other parameters, so the dependency list on line 86 is left null. Furthermore, since the list does not change once it is retrieved from the resource, it can be implemented as a complete resource domain during registration (lines 127-130 of Code Example 2: WmManagedConnection Implementation Class Updates). When a ResourceDomainValues object is provided in registerResourceDomain, there is no need to add support for the resource domain in the lookup method.
The resource domains columnNamesRD and columnTypesRD are created to support the columnNames and columnTypes parameters, respectively. The columNamesRD resource domain depends on the value of the tableName parameter, and since columnNames and columnTypes were placed in a tuple, columnTypesRD must also depend on the value of tableName. The lookup implementation for these resource domains (lines 39-57 of Code Example 2: WmManagedConnection Implementation Class Updates) checks for the name of either resource domain and it returns the values for both resource domains in a single response array. (The columnNamesRD resource domain will always be passed as the resource domain name in this lookup. Adding the ‘||' check on line 40 decouples the lookup implementation from the order in which the parameters were placed in the tuple.)
The final resource domain in this section, OverrideTypesRD (associated with the "overrideTypes" parameter on line 91 of Code Example 1: WmAdapterService Implementation Class), is used to validate data entered by adapter users into a Java class that will contain the data at run time. The specifics of the check implementation (lines 16-32 of Code Example 2: WmManagedConnection Implementation Class Updates) are probably unrealistic for a real-world environment, but all the mechanics of doing a check are demonstrated. Remember to set the setCanValidate method to true in the resource domain (line 115 of Code Example 2: WmManagedConnection Implementation Class Updates).