Authoring and Reviewing Rules

Welcome to ILOG JRules > Getting Started > ILOG JRules Architecture Guidelines > Authoring and Reviewing Rules

Authoring and Reviewing Rules

Rule projects enable you to provide a language to business users that enables them to understand and manipulate business rules easily. At the same time, you need to make sure this language remains unambiguous and executable.

The following graphic shows a rule project containing different types of rule artifact.

Expressing Business Rules

The Business Action Language (BAL) provides a syntax for expressing business rules. The BAL defines a simple if-then syntax (IF some set of conditions are true THEN a set of actions should be taken), and provides constructs for expressing business rule conditions and actions.

With the vocabulary and the BAL, you can create three types of business rule artifact in Rule Studio or Rule Team Server:

Business rules are sentence-like statements expressing a set of conditions followed by the actions to be taken if the conditions are found to be true.
Decision tables represent the decision logic as a table. Each row in a decision table corresponds to a business rule.
Decision trees represent the decision logic graphically. In a decision tree, branches of the tree represent conditions, and the leaves of the tree represent the actions to be taken if the actions are found to be true.

If you want to write more complex business rules that business users will not edit, you can use technical rules. Technical rules do not use the vocabulary; they apply directly to BOM elements. You use IRL to write them. Technical rules can be useful if you want to write rule actions that handle loops or exceptions, or use Java constructs that are not available in the BOM to XOM mapping.

Understanding How Business Rules are Parsed and Executed

The ILOG Rule Language (IRL) is the executable form of the rule artifacts. In the ruleset, all rule artifacts are translated to the ILOG Rule Language. For example, each row of a decision table is generated as a rule in IRL. Each action column corresponds to an IRL action in the corresponding rule.

The BAL is set up to automatically translate to IRL. However if you extend it, you need to make sure you cover this translation for your new constructs.

For example, you write the following business rule using BAL.

The executable form of this business rule is IRL code. You can view this code by clicking the IRL tab in the rule editor.

At runtime, the rule engine parses the ruleset and uses BOM to XOM mapping to access the XOM. The business rule application can then invoke the ruleset, and provide data in the form of Java objects (if a Java XOM was specified), or XML documents (if an XSD XOM was specified), against which the rules execute.

The rule engine makes calls to the XOM Java methods in the course of evaluating and executing the rule. In this example, the rule engine calls the Java method java.util.Collection.add for the BOM method addToMessages because this method has an explicit BOM to XOM mapping defined as this.messages.add(argument), messages being a BOM attribute of type Collection. For the reject BOM method, the rule engine calls the Java method reject directly.