Specifying properties on a service callout instance
You can specify properties on a Service Callout that can be set per instance . That means that a SCO that retrieves data from a web service could use multiple instances of it in a Ruleflow where each instance has different parameters. The nature of the parameters is unrestricted; they are simple name/value pairs that a SCO can interpret as needed.
Overview of SCO parameters
When a SCO is added to a Ruleflow canvas, its Properties (View) > Runtime Properties let you set name/value parameter pairs on this SCO instance. These name/value pairs will be passed to the SCO when the SCO is executed. For example:
To enable this functionality, the SCO's method must need to accept a java.util.Properties object in its method signature:
public static void processCreditReport(ICcDataObjectManager aDataObjectManager, Properties apropServiceCalloutProperties)
If the method does not accept a Properties object (as is the case for SCO's created before 5.6.1), the original method will still be called, providing both backward compatibility as well as an alternative approach to using parameters in SCOs.
public static void processCreditReport(ICcDataObjectManager aDataObjectManager)
If the SCO has implemented both methods, the method with the Properties object will be called during execution. If this method does not exist, then the alternative applies.
Selecting the Runtime Properties for a SCO
Defined Property Names and Values
Often you will want to constrain the Property Names and their respective Values to ensure that only valid combinations are selected by the user from a drop-down list box. The SCO must implement a specific Interface and the following methods for the Ruleflow to list the possible Property Names and their respective Values.
public List<String> getPropertyNameOptions()throws Exception;
public List<String> getProperyValueOptions(String astrPropertyName)throws Exception;
Example:
The user drops down the list and then chooses a property name:
The Ruleflow calls back to the SCO to get the possible Values for that Property name, and then lists the values in a drop-downlist where the user selects the value:
Note: This technique does not allow additional name/value pairs to be entered.
No defined Property Names and Values
Undefined Property Names and Values occur when:
The SCO does not implement the ICcPropertyProvider interface
The interface and methods are implemented, but the methods return a null or empty list
Under these conditions, the Property Name and Property Value cells in the Properties (View) > Runtime Properties are TextBoxes where a can type names and values on as many lines as they want:
There are no values defined for a free-form property name so a value must be typed in:
Note: Property Name and Value lists work independently - While getPropertyNameOptions() might return a List<String> with values so that the cell on the current Property line offers a dropdown list, the selected property might find that its getPropertyValueOptions(..) returns a null or empty list. In that case, the Value cell is provided as a text box for your free-form entry. However, each property name and value pair must have non-blank entries to complete valid service callout runtime properties.
The SCO does not implement the ICcPropertyProvider interface
