Service Consumer builder inputsAdded by IBM on June 28, 2011 | Version 1 (Original)
|This topic describes the inputs for the Service Consumer builder.
This topic describes the inputs for the Service Consumer builder.
- Lookup Table Options
- Performance Options
- Context Variables
- Mapping Parameters
Table 1. General inputs
|Name||Required. Enter a name for this builder call. The WebSphere® Portlet Factory Designer displays this name in the builder call list.|
This input is used as the local name of service. If this input is blank or if the Add All Provider Operations input is enabled, the target method name is used.
|Provider Model||Required. Select a provider model that contains a Service Definition builder to use. |
|Add All Provider Operations||Set to add all the exposed operations from the provider model and make them available to the consumer. |
Note: If this input is clear, you must select individual operations using the Operations input.
|Operations ||This input is available if the Add All Provider Operations input is clear. Use this input to select or exclude operations from the provider model.|
|Enable Operation||Click in the text box under Operation and set this option for each listed operation that should be available for this consumer model. The value true appears in the Enabled column. |
Clear this option to exclude the related operation. The value false appears in the Enabled column.
|Description||Read-only area to display information about the operation. |
|Override Inputs||Enable to override one or more input values for any of the service operations. |
Note: You must set override values in the Overridden Inputs input.
|Overridden Inputs||This input table is available when Override Inputs is enabled. Use this input table to set override values for service operation inputs. Input values you set here automatically populate the specified input variable before the service operation is invoked. |
Note: Values passed to the <buildername><target operation name>WithArgs method take priority over these overridden inputs.
|Rich Data Definition File||Optionally select a rich data definition (RDD) XML file. This file is applied to all of the schemas picked up from the provider model. |
This input allows you to avoid adding a separate Rich Data Definition builder to your model. Use this input to specify an existing XML-based rich data definition file to apply to the Service Consumer schemas.
Using this input is equivalent to adding one or more Rich Data Definition builders to the model, and applying them to the schemas related to the service operations.
Lookup Table Options
Use the inputs in this group to control the creation of lookup tables defined in the related Service Definition builder.
Table 2. Lookup Table Options inputs
|Create Lookup Tables||Set this input to create lookup tables defined in the Service Definition builder metadata. |
|Refresh Interval (secs)||Specify in seconds the amount of time to retain in the cache the data used for the lookup tables. Leave the input blank to disable caching. |
This input is available if the Create Lookup Tables input is set.
|Associate Lookup Tables||Set this input to associate the lookup tables with the fields in the service operation variables. |
This input is available if the Create Lookup Tables input is set.
Table 3. Performance Options inputs
|Use Request-Scoped Input Variables||Set this input to allow the values of the input variables to be discarded at the end of each request. The data is automatically reloaded in subsequent requests as necessary. This setting lets you limit use of session memory. The Enable Caching input is made available so that variables can be fetched from cache to save processing time to retrieve them from the backend. |
If this input is clear, input variables are kept in session memory.
|Use Request-Scoped Result Variables||Set this input to allow the values of the result variables to be discarded at the end of each request. The data is automatically reloaded in subsequent requests as necessary. This setting lets you limit use of session memory. The Enable Caching input is made available so that variables can be fetched from cache to save processing time to retrieve them from the backend. |
If this input is clear, result variables are kept in session memory.
|Enable Caching||Set this input to enable caching of variable data. If data is not cached, it is kept only for a single request and reloaded when needed on subsequent requests. |
If caching is enabled, cache hits, misses, and data refetch operations are logged in server statistics.
|Cache Size||Specify the maximum number of entries to keep in the cache. If you leave this input blank, the value of the following property is used. |
Table 4. Context Variables inputs
|Context Variable Values||Context variables are variables in a service model, published by operations using an ID (allowing common/shared types.) A service consumer model looks for these published context variables, and allows values to be set for them. |
Select an operation, and then provide a context variable ID and value.
Note: You can use context variables if the provider model defines context variables in its Service Operation builder, and you want to supply alternate values for those variables. Assigning values here provides a way for the consumer model to pass information to the provider model without exposing extra parameters to the operation.
Table 5. Mapping Parameters inputs
|Mapping Parameters||Use this input to control the behavior of the service mapping registry. |
For example, in a service mapping registry file you may have defined a role parameter that is used to select the service to use. You can use the mapping parameters to set the role value from data in your model or from a profiled value. Example:
<!-- Use a mapping parameter named "role" to
select implementation for a given service. -->
<IfParameterEquals name="role" value="manager">
<UseService name="Service1_manager" />
Table 6. Advanced inputs
|Inherit Explicit Profile||Set this input to have the service provider model generated using the current profiles in the consumer model. The profiles used to generate the consumer model are passed through to the service provider model. |
This input is used only if the Profile Name input is not specified.
|Profile Name||Specify an optional profile name to apply to the model selected in the Provider Model input. This is useful if the provider model is profiled, and you want to override the default profile selection by specifying another profile. |
You specify this value as <profile set name>:<profile name>. To specify more than one profile, use a comma (,) separator.
Parent topic: Service Consumer builder