This section covers how to simplify the rule sets and keep them readable by dividing them into smaller blocks. You do this by using inclusions and exit points.
To illustrate this, please find below a rule set that has the ability to do some basic fraud prevention analysis on incoming HTTP requests:
If you were to copy all of the rules into your rule set every time you needed to perform these checks, you would end up with very large unwieldy rule sets. To avoid this problem, Composable Architecture Platform gives you the ability to include (or embed) existing rule sets into new rule sets as if they were just another rule. The following example illustrates this:
The BrowserInfoCheck rule set as part of the Qwerty, AccountMain rule set is behaving just like any other rule. This was done by dragging it from the Rule Sets folder in the editor and onto the editor canvas. The key to making this approach work is to use Rule Set Exit rules in the embedded document. The rule set exit rules in any given rule set determine what chain points will be available for that rule set when it is embedded into another page.
If you look back to the BrowserInfoCheck rule set, you can see the OK, Error and Warning exits.
There are no limitations on the number of rules sets that can be embedded within one another.
Embedded rule sets have many advantages:
Complex rule sets can be built for a given function, keeping the logic central
You can share rule sets between functional areas without the need to copy
You can have experts build rule sets for novice users
If you have rule sets that perform a unique discrete function, it can be advantageous to wrap them up so that they look like a new rule that can be included at the repository level. You can specify the group, name and a set of input and output parameters for that rule. This makes the rule set show up in a specific group and parameters subsequently show up as properties of the included rule set.
To define parameters, go to the rule sets “Rule Info” tab:
Enter your group and name and click on the Add Parameter button to create a new parameter:
The Parameter Name defines the name of the variable used internally by the rule set for this parameter.
The Parameter Label fields determine what is displayed as the property description when the rule is included.
The Parameter Type determines how the parameter is used. There are 3 options:
An input parameter is set when the rule set is called. So, a top level rule set could use the variable “Name” within it and you could define a parameter equally named “Name”. Once a rule set has parameters, it can no longer “see” or access variables outside its own boundaries.
So, at the top level the variable “Name” could contain the value “Smith”, yet a value of “Jones” could be passed to the parameterized rule set (also with the variable “Name”) and the embedded rule set will only see the value “Jones”.
Input parameters to a rule set can be constants (in quotes), a variable or a value from a drop-down list. To make the input parameter a drop-down list, supply a CSV list of values in the Set values field.
An output parameter is set when the process flow exits the rule set at the top level. So, when the embedded rule goes down a chain point or returns from its function, the original set of variables will come back into effect and only variables set against the output parameter will be transferred from the embedded rule set to the top level rule set.
Output parameters can only be variables.
I/O parameters are variables that are read on input and set again on return.
I/O parameters can only be variables
To illustrate how parameter can be used, consider the following parameter definitions against a rule set:
And the following rule set:
The above rule set will simply add to or subtract from a value.
When this rule set is included into another rule set, the following parameters become visible:
The user can now pass any give variable name to this rule set and the included rule set will perform the expected math on it (using its own internal variable names) and return the result in the passed variable.
This approach enables the building of generic rules that are guaranteed to not have a variable name overlap with other rule sets.
You can now go to the repository level and select the individual rule sets that should be exported from that repository:
When another repository includes this particular repository, the only rule set available will be names “Quick Add” and will be found in the “Math” group as specified on the Rule Info tab.
