How to Select Rules to be Executed

Samples > Rule-Based Programming > How to Select Rules to be Executed

How to Select Rules to be Executed

This sample shows how to use strategies to select which rules are evaluated for a given task. Please note the information provided in Using the Samples.

Key Features

This sample shows how to use various strategies for selecting which rules should be evaluated for a given task. This is particularly useful when rules become numerous and specialized.

In JRules, rule selection relies on a selection pipeline that behaves like a series of filters, using rule properties instead of rule conditions.

Static selection

extractor using a query

Runtime selection

ruletask scope
runtime rule selection
match (up) operator
rule overriding

Rule model extension

struct properties
hierarchical properties
queries on extended properties

Importing this Sample

As this sample will install a custom rule model instead of the default one, it is recommended to explore and run it in a separate workspace.

To prepare a new workspace:

Click File > Switch Workspace and specify a new workspace directory. Eclipse will exit and restart automatically with a blank workspace.
Switch to the Rule perspective.

To import the ruleselection sample:

Click File > Import.
In the Import Wizard, select ILOG Rule Studio Samples and Tutorials and click Next
Select the sample: samples > engine > ruleselection.
Click Finish.

The required sample project files are imported and displayed in the Rule Explorer.

If your Eclipse is using the automatic build mode, the project is built with a large number of errors. This is because the project uses an extended model and Rule Studio should be configured for it. You will do this in the next step.

Click Window > Preferences.
In ILOG Rule Studio > RuleModelExtension, set the Extension model to ruleselection-rules/data/ruleselection.brmx, and set the Extension data to ruleselection-rules/data/ruleselection.brdx.
Click OK.
If prompted to restart Eclipse, click Yes.
Click File > Switch Workspace then click OK without changing the workspace location. Eclipse with shut down and immediately restart.

Once Eclipse restarts and the project is rebuilt, the built errors are resolved since the correct extended model is used.

The rule model extension and its attached data file are now recognized by Rule Studio.

Running this Sample

Make sure you are in the Rule perspective before running this sample.

To run the sample:

Click Run > Open Run Dialog.
Select the ruleselection-rules-case1 launch configuration.
Click Run.

The console displays the initial state of the contract, then lists which rules were extracted to the ruleset archive, which rules were selected in each ruletask, and which were finally fired. The final state of the contract is then displayed.

Select and run the ruleselection-rules-case2 and the ruleselection-rules-case3 launch configurations.

The console trace shows that, given a different extractor and a different input parameter, different rules are extracted, selected and fired.

Highlights

The selection strategy is split into two phases:

At build time, rules are extracted from projects to a ruleset archive.
At runtime, rules are selected by ruletask scope, then dynamically selected based on contextual or application data. Rule overriding may then be applied before final rule evaluation is performed.

This sample loads the ruleselection-rules rule project and the ruleselection-xom XOM project. Rules evaluate a contract status based on information about the company featured in the contract, and information about the contract itself.

A first ruletask, called assessment, evaluates a risk level based on the company revenue, a rating of the company, and the amount of the contract.

A second ruletask, called decision, determines the status of the contract (using a set of predefined status values such as ACCEPTED, REFUSED, NEGOCIATE), based on the evaluated risk level and the expected profit from the contract.

The rule model extension located in the data directory of the ruleselection-rules project, enhances the rules in the sample with the following properties:

targetRelease, a 'struct' property defined by a major and a minor version, a patch level, a production level (`Test', 'Beta', 'Production') and a desired deployment date for the rule.
origin, another 'struct' property containing the requestor and the requirement ID that lead to this rule.
industry, a hierarchical property that models the industries to which a rule is applicable, using a predefined breakdown of industry types.
location, a hierarchical property that models the effective location of the rule within a geographical breakdown of the world.
customers, a textual property that identifies, if needed, the companies that this rule is valid for.

Using the default behavior of the product and these properties, rule selection implements the following strategy:

Rules accepted by the extractor are added to the ruleset archive. The extractor uses a query based on the status, targetRelease and effective location of the rule. The generated archive contains only the rules considered as valid for a given application release and a given region of the world. For example, the extractor V1-production-Americas uses the query with the same name, returns only rules for the V1.2 production release, valid worldwide and in the American continent. The other extractor, V2-beta-Europe uses the query with the same name, defined for V2.0 beta version, valid worldwide and in Europe.
In the ruleflow, the rule package is used to map to the ruletask scope: rules in the assessment package and its sub packages go in the assessment ruletask; rules in the decision package go in the decision ruletask. This is enforced when the ruleset archive is loaded by the rule engine.
In each ruletask, a dynamic select retains the rules whose:

effective date range contains the contract effective date
location matches the contract's effective location (meaning that if the contract is effective in the Silicon Valley, all rules defined in Northern California, in the USA, in Northern America, in the Americas and worldwide are selected)
industry matches the company's industry (for a software vendor, the rules defined for the Technology and Software industries are selected)

Rule overriding excludes rules that are already overridden by others. For example, this can be used to retain only a specific rule, instead of a more general one in cases where both are potentially selectable. Of course, in the case where the specific rule was already excluded in a previous step, the general one would be selected.

ruleselection-rules-case1

With the ruleselection-rules-case1 launch configuration, which evaluates a contract with a software company in north California with the V1 production application, only the following rules are retained:

assessment.amount.V1-NorthAmerica-Software
assessment.rating.V1-NorthernCalifornia-Software
assessment.revenue.V1-NorthAmerica-Software-SmallCompany
assessment.revenue.V1-NorthAmerica-Software-MediumCompany
assessment.revenue.V1-NorthAmerica-Software-LargeCompany
V1-decision

And only the following rules are fired:

assessment.revenue.V1-NorthAmerica-Software-LargeCompany
assessment.rating.V1-NorthernCalifornia-Software
assessment.amount.V1-NorthAmerica-Software row #4
decision.V1-decision_4 row #4

V2-* and *-Europe-* rules are not extracted by the query.

Rules such as assessment.rating.V1-NorthAmerica-Services and assessment.rating.V1-BlackList-NorthernCalifornia-Software are in the ruletask scope, but are rejected by the dynamicselect.

Finally, assessment.rating.V1-NorthAmerica-Software is overridden by assessment.rating.V1-USA-Software, which is overridden by assessment.rating.V1-NorthernCalifornia-Software.

ruleselection-rules-case2

With the ruleselection-rules-case2 launch configuration, which evaluates a contract with a French Bank agency in Italy with the V2 beta application, only the following rules are retained:

assessment.amount.V2-Europe-Services
assessment.rating.V2-Europe-Services
assessment.revenue.V2-Europe-Services-AllCompanies
decision.V2-decision

And only the following rules are fired:

assessment.revenue.V2-Europe-Services-AllCompanies
assessment.rating.V2-Europe-Services row #2
assessment.amount.V2-Europe-Services row #5
decision.V2-decision row #4

V1-* and American rules are not extracted by the query.

ruleselection-rules-case3

The ruleselection-rules-case3 launch configuration evaluates a contract with a Software company named Swindle Systems in Northern California with the V1 production application. In this case, the rule assessment.rating.V1-BlackList-NorthernCalifornia-Software is selected during the dynamic selection, and overrides the assessment.rating.V1-NorthernCalifornia-Software rule and all rules that were overridden by the latter.

Notes

It is interesting to notice that rule execution is not only controlled by the engine algorithm reasoning on rule conditions but also enforced by a selection strategy based upon rule properties, prior to actual execution.

The sample has been created with functions in the ruleflow and specific actions in the rules, in order to track and display rules extracted in the archive, selected in a task and fired. An IlrTool implementation could have been used instead of rule actions to display which rule is actually fired.

An IlrAgendaFilter may also be used to filter out rule instances, just before being fired, even when the rule was selected and the rule condition matched.