You can specify properties on a Service Callout (SCO) 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 Service Callout (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 Service Callout (SCO) must implement a specific Interface and the following methods for the Ruleflow to list the possible Property Names and their respective Values.

Interface:

 com.corticon.services.extensions.ICcPropertyProvider

Static Methods:

 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-down list 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 Text Boxes where names and values can be typed on many lines:



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 drop-down 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.

Add the extension to the Rule Project, and then test it.

In order for the extension to get referenced by a Rules project, and then packaged with a Decision Service, you must Add the compiled Java classes to the Rules Project.

Create and run Ruletests that evaluate the range of possible values that could be presented to the extension. Be sure to include blanks and nulls so that you get complete coverage.