You write action rules, decision tables, and decision trees using the Business Action language (BAL). BAL translates automatically to IRL, which is the executable form of rule artifacts. To create multiple rules with the same structure, you can create templates.
Developers set up the tools to help business analysts and rule authors write rules.
To write business rules, business users need a language that is natural and understandable to them. However, you must also make sure that this language remains unambiguous and executable.
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 are to be taken) and provides constructs for expressing business rule conditions and actions.
Using the vocabulary and the BAL, you can create three types of business rules:
Action rulesAction 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 tablesDecision tables represent decision logic as a table. Each row in a decision table corresponds to an action rule.
Decision treesDecision trees represent 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 conditions are found to be true.
If you want to write more complex business rules that business users do not edit, you can use technical rules. Technical rules do not use the vocabulary. These rules are written in ILOG® Rule Language (IRL) and apply directly to BOM elements. 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 rulesets, all rule artifacts are translated to IRL. 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 translate to IRL automatically. For example, you write the following action rule using BAL:
if the credit score of 'the borrower' is less than 200 then add "Credit score below 200" to the messages of 'the loan'; reject 'the loan';
The executable form of this action rule is IRL code. You can view this code by clicking the IRL tab in the rule editor. The IRL code of this rule is displayed in the IRL tab.
package eligibility {
rule minimum_credit_score {
property status = "new";
when {
miniloan.Borrower() from borrower;
evaluate (borrower.creditScore < 200);
} then {
loan.addToMessages ("Credit score below 200);
loan.reject();
}
}
}At run time, the rule engine parses the ruleset and uses BOM to XOM mapping to access the XOM. The business rule application then calls the ruleset against the Java objects (if the specified model is a Java XOM) or XML documents (if the specified model is an XSD XOM).
The rule engine calls 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 BOM method reject, the rule engine calls the Java method reject directly.
If you extend the XOM, remember to add the BOM to XOM mapping for the new constructs.
Simplifying rule editing for business users
When you design a rule project in Rule Designer, you must make sure that the management and rule authoring environments that you set up meet the needs of business users. The purpose is to avoid discrepancies between the system architecture and the needs of business users. For example, rule packages can reflect decision points in your application, but not the geography to which the business rules apply. The business rule vocabulary is ultimately implemented as an object model. The constraints involved in developing an object model can result in a verbose vocabulary. For example, you probably have inheritance relationships or utility classes in your model which make no sense to business users. You can hide these implementation-related classes in the business object model.
You can also use action rule templates and decision table templates to guide rule authors to write rules more easily and create many similar rules efficiently. A template is a partly completed action rule or decision table that is used to create a series of rules with the same structure.
If you find that you use templates to manage many rules with shared conditions and actions and you only modify values, consider managing these rules as a decision table.
The following sections describe what you can do to extend and customize your rule project and business object model so that the management and authoring of business rules is made simpler for business users.
Filtering the vocabulary with categories
When you have a large vocabulary, categories let you filter the terms and phrases that are available to you when you edit rules in Rule Designer or Decision Center. When a category is assigned to a business rule, only the vocabulary terms and phrases of that category are visible in the business rule.
Adding custom properties to rule artifacts
To add properties to existing types of rule artifact, you extend the rule model. You can set up BAL and rule model extensions once and then deploy them to both Rule Designer and Decision Center. For example, you can create a property geography to identify the country for which a rule is applicable.
Business users can use custom properties to manage business rules. For example, they can use queries in Decision Center to set up smart views based on a property. With smart views, business users have a different view of the rule project compared to the physical rule package organization that you set up in Rule Designer.