Adapter Service Node Signatures
In addition to using the metadata model to create parameters for configuring an adapter service node, you can use the model to define the signatures of that node.
An adapter service node has an input signature and an output signature. An input signature describes the data that the service expects to find in the flow service pipeline at run time. An output signature describes the data that the service expects to add to the pipeline when it has successfully executed.
You can view an adapter service node's signature in the Input/Output tab of the adapter service editor in Designer. Rules for defining signatures appear in the following procedure.
Once the signature is complete, users may include an adapter service node in flow constructs. They can route, map, and transform the input and output of the adapter service as needed in the integration solution.
The following procedure provides a basic model that you can use to implement a metadata signature. If you deviate from this model, it is important to understand that signature resource domains are only invoked as a result of a value applied to a dependent parameter. Having a resource domain lookup simply change the list of possible values in the resource domain does not impact the signature unless the current value is changed.
To create the signature of an adapter service node
1. Create metadata input parameters for the field names, data types, and signature. Each parameter must have a data type of String[].
For example, assume that inputNames, inputTypes, and inputSignature are created as follows:
public void setInputNames(String[] val);
public void setInputTypes(String[] val);
public void setInputSignature(String[] val);
2. Add these parameters to a group in the same order as above.
For example:
templateDescriptor.addGroup("group name", new String []
{ …, "inputNames", "inputTypes", "inputSignature"});
3. You may hide any or all of the parameters. (Hiding all parameters in a field map hides the map table as well.)
For example:
templateDescriptor.setHidden("inputNames");
templateDescriptor.setHidden("inputTypes");
templateDescriptor.setHidden("inputSignature");
4. Create a field map containing the three input parameters. In the createFieldMap method, set the variable argument to false, and set the fillAll argument to true.
For example:
templateDescriptor.creatFieldMap(new String [] {"inputNames",
"inputTypes", "inputSignature"}, false, true);
In some cases, you can include other parameters in this field map, but this can sometimes be problematic, particularly if these parameters are hidden.
5. Create a tuple containing the names and types parameters.
For example:
templateDescriptor.creatTuple(new String [] {"inputNames",
"inputTypes"});
6. In the associated connection class(es), register two resource domains to support name and type lookups.
For example, assume that the resource domains inputNamesLookup, and inputTypesLookup are created as follows.
access.addResourceDomainLookup("inputNamesLookup", this);
access.addResourceDomainLookup("inputTypesLookup", this);
7. Assign the names parameter to the name lookup resource domain, and assign the types parameter to the type lookup resource domain. These assignments must specify the same dependencies because the parameters are in a tuple. If no dependencies are known at this time, specify null.
For example:
templateDescriptor.setResourceDomain("inputNames","inputNamesLookup",null);
templateDescriptor.setResourceDomain("inputTypes","inputTypesLookup",null);
8. Assign the signature parameter to one of the reserved resource domain names provided in WmTemplateDescriptor, specifying the names parameter and the types parameter as dependencies.
For example, INPUT_FIELD_NAMES would be used as follows:
templateDescriptor.setResourcDomain( "inputSignature",
WmTemplateDescriptor.INPUT_FIELD_NAMES, new String[]
{"inputNames", "inputTypes"}););
10. Create an output signature by repeating this procedure, substituting OUTPUT_FIELD_NAMES for INPUT_FIELD_NAMES in step 8.