Guidelines for Specifying Input Parameters

Specify all inputs that a calling program must supply to this service. For example, if a flow service invokes two other services, one that takes a field called AcctNum and another that takes OrderNum, you must define both AcctNum and OrderNum as input parameters for the flow service.

Note:
The purpose of declaring input parameters is to define the inputs that a calling program or client must provide when it invokes this flow service. You do not need to declare inputs that are obtained from within the flow itself. For example, if the input for one service in the flow is derived from the output of another service in the flow, you do not need to declare that field as an input parameter.

When possible, use variable names that match the names used by the services in the flow. Variables with the same name are automatically linked to one another in the pipeline. (Remember that variable names are case sensitive.) If you use the same variable names used by flow’s constituent services, you reduce the amount of manual data mapping that needs to be done. When you specify names that do not match the ones used by the constituent services, you must use the Pipeline view to manually link them to one another.

Avoid using multiple inputs that have the same name. Although Designer permits you to declare multiple input parameters with the same name, the fields may not be processed correctly within the service or by services that invoke this service.

Make sure the variables match the data types of the variables they represent in the flow. For example, if a service in the flow expects a document list called LineItems, define that input variable as a document list. Or, if a service expects a Date object called EmploymentDate, define that input variable as an Object and apply the java.util.Date object constraint to it. For a complete description of the data types supported by Designer, see Data Types.

Declared input variables appear automatically as inputs in the pipeline. When you select the first service or MAP step in the flow, the declared inputs appear under Pipeline In.

Object and Object list variables must be a serializable data type. If it cannot be serialized, the pipeline cannot be exchanged with a remote Integration Server. Further, the class names for the data type must be included in the Integration Server whitelist classes file or a package whitelist classes file for the pipeline to be deserialized at the destination Integration Server. Classes defined by Integration Server are already included in the whitelist class file. This requirement applies to all Object and Object list variables, including those contained in a Document or Document list.

Trigger services have specific input parameter requirements. If you intend to use a service with a webMethods Messaging Trigger or a JMS trigger, make sure the input signature conforms to the requirements for each of those trigger types. For more information about creating webMethods Messaging Trigger, see Creating a webMethods Messaging Trigger . For more information about creating JMS triggers, see Working with JMS Triggers.

Important:
If you edit a cached service by changing the inputs (not the pipeline), you must reset the server cache. If you do not reset it, the old cached input parameters will be used at run time. To reset the service cache from Designer, select the service and then click the Reset button next to Reset Cache in the Properties view. To reset the service cache from Integration Server Administrator, select Service Usage under Server in the Navigation panel. Select the name of the service and an information screen for that service appears. Click Reset Server Cache.