Adapter Development Kit 9.12 | webMethods Adapter Development Kit Documentation | webMethods Adapter Development Kit Installation and User’s Documentation | Overview | Development Time Tasks and Support | Define Metadata
 
Define Metadata
Connection factories, adapter service templates, polling notification templates, and listener notification templates all support a metadata interface. Metadata that you create in your adapter implementation primarily supports design time activities. It describes parameters that the users of the adapter use to create namespace nodes for connections, adapter services, and notifications, and describes the data passed to and from adapter services and notification nodes.
When a user of the adapter creates a namespace node, the server interrogates the adapter for metadata to describe the parameter values supported by the node. The node stores the parameter values selected or entered by the user. These parameters are used to configure the appropriate implementation class when it is instantiated at run time.
Metadata parameter values are derived from the adapter's resource domain. A resource domain defines the domain of valid values for metadata parameters, based on rules and/or data that are specific to the adapter resource. A resource domain can have a name, a set of resource domain values, properties that affect the behavior of the resource domain, and associations with metadata parameters.
A resource domain can be either fixed or dynamic. A fixed resource domain displays default values that you provide for the resource domain parameters. With a dynamic resource domain, you use a method that enables the adapter to look up values for the parameters.
You can use resource domain values to constrain the values of parameters, to enable dynamic validation of user supplied data, and to disable parameters, based on specific sets of values in other parameters. A common use of resource domain values is to create a dropdown list of values for a parameter.
With both fixed and dynamic resource domains, you can allow the users of the adapter to enter their own values. In addition, you can enable the adapter to validate these values using callbacks known as adapter check values.
With adapter services and polling notifications, resource domain values can interact with the Adapter Service Editor and the Adapter Notification Editor. As values in one parameter change, callbacks are made to the adapter to update resource domain values. In addition, the adapter can retrieve resource domain values directly from the adapter resource.
A parameter may contain a single value or an array of values. Parameters that hold arrays of values are called sequence parameters. The user interface for configuring connections does not allow you to populate more than the first element of a sequence parameter.
The metadata model provides the ability to:
*Define groups of parameters that appear on different pages in the user interface.
*Define resource domain lookups that return dropdown lists of possible values for a parameter. Resource domain lookups may return values established at development time and/or retrieved at design time from the resource with which the adapter communicates.
*Establish sophisticated relationships between parameters using field maps, tuples, and resource domain dependencies.
*Field maps are used to place sequence parameters in a grid-style table with each sequence parameter forming a column in the table.
*Tuples are used in conjunction with field maps. When a set of parameters is placed in a tuple, resource domain lookups for those parameters are always made together. This is commonly used when columns are closely related, for example when column 1 contains field names, and column 2 contains data types for those fields.
*Resource domain dependencies indicate that the values to be returned in a resource domain lookup are dependent on the value of one or more other parameters. Whenever the value of one parameter changes, if a second parameter's lookup is dependent on the value of the first, the lookup for the second parameter is performed again, with the new value of the first parameter being passed in as an argument to the lookup.
*Define signatures that define the data that should be passed to, or received from, the node when the service or notification is executed (by calling the execute method of the implementation class).
*Make interactive calls into the adapter to validate the data entered by the user.
*Define tree structures to facilitate input of parameter values or to create logical groupings of the fields in a signature.
Metadata is discussed in more detail throughout this document, in the chapters about connections, adapter services, and notifications.