WODM v7.

11/23/2016

page 1 of 22

WODM v7.5

1. Why Business Rules?

Traditional business application development

What are the challenges with traditional business
application development?
Business Rules approach and the difference

Advantages of Business Rules Approach

2. IBM/ILOG JRules BRMS, WebSphere Operational Decision
Management (WODM)

Rule Studio/Rule Designer - Java developers

Rule Team Server/Decision Server - Business Users
Decision Validation Services - rule testing
Rule Execution Server - run time platform
Roles and Responsibilities in Rule based development

3. Guidelines to Developing ILOG Business Rules Application

Approach to Business Rules Development and life-cycle

Agile Business Rule Development methodology
Application Architecture
Designing Rule Project Hierarchy
Orchestrating Rule Execution
Authoring Rules
Debugging and Test Rules
Packaging and Deployment
Client application implementation

11/23/2016

page 2 of 22

WODM v7.5

4. Executable Object Model

Two approaches to XOM creation

Execution Object Model (XOM)

The Execution Object Model (XOM) is the model against which rules are
run. It references the application objects and data, and is the base
implementation of the Business Object Model (BOM). The rule project
references the XOM.
1.
2.

The XOM is built from:

Compiled Java classes (Java Execution Object Model)
XML Schema (Dynamic Execution Object Model)

Java XOM

Defining a Java XOM

3.
4.

You can define a Java XOM in the New Rule Project wizard when you
create the project, or later, using the rule project Properties dialog. The
procedure is the same in each case.
To define a Java project using the Properties dialog:
In the Rule Explorer view, select the rule project, then on the Project
menu, click Properties.
In the left pane of the Rule Project Properties dialog, click Java Execution
Object Model.

11/23/2016

page 3 of 22

WODM v7.5

5.
6.
1.
2.
3.

4.

1.
2.

1.
2.
3.

Select the Java project(s) required for the XOM from the list displayed. Use
the Select All button if you want to select them all.
Click OK. The Java XOM is now defined.
To add a JAR file or a class folder:
In the Rule Explorer view, select the rule project, then on the Project
menu, click Properties.
In the left pane of the Rule Project Properties dialog, click Java Execution
Object Model.
Click the Libraries tab. The Libraries page enables you to choose JAR
files and class folders. To add JAR files that have been imported in the
Eclipse workspace, click Add JARs. This opens a dialog that enables you
to browse JAR files in the workspace.To add JAR files that are not in the
workspace, click Add External JARs. This opens a dialog that enables
you to browse the JAR files in your file system.To add class folders, click
Add Class Folder. This opens a dialog that enables you to browse
directories in the workspace. In this same dialog, you can add external
class folders by creating a folder in the workspace that you link to an
external folder in the file system.NoteBy default, the JRE library is already
in the list of libraries. This library is the same as the one used to run
Eclipse and cannot be removed. You can browse the JRE library to see the
JAR files used by this library.
Click OK.
You now need to specify the location of the source to be used to reference
a library.
To set a source location to reference a library:
On the Libraries tab, expand the item you want to set as the source and
select the Source item.
Click Edit. This opens a dialog that enables you to select a ZIP file or a
source folder from the workspace or your file system.
Java XOM entries can be ordered.
To order the entries:
In the left pane of the Rule Project Properties dialog, click Java Execution
Object Model.
Click the Order tab. This page shows a list of all selected Java XOM
entries.
Select one or more entries and use the Up and Down buttons to move
them.
Click OK.

Dynamic XOM

11/23/2016

page 4 of 22

WODM v7.5

Overview: Dynamic Execution Object Model

(XOM)

7.
8.

5.
6.

3.

The Execution Object Model (XOM) is an object model against which rules
are executed. Business rules are written against the Business Object
Model (BOM), then translated into the ILOG Rule Language (IRL) and run
against the XOM. The rule engine evaluates the rules against the
application objects and executes them when appropriate.
In Decision Server, a XOM can be generated from native Java classes or
from dynamic classes, or derived from XML Schema Definitions (XSDs).
The word dynamic means that no native Java object is constructed or
generated. Instead, dynamic XML objects are created to represent the
instances of the dynamic classes.
A XOM generated from native Java classes is known as a Java XOM.
A XOM generated from dynamic classes is known as a Dynamic XOM.
When looking for a XOM class, the rule engine looks first in the dynamic
XOM, then in the Java XOM.
The following diagram shows the mapping between a XOM and Java
classes and dynamic classes.

The XOM is represented by the Java class IlrReflect. Instances of this

class contain all the classes required for executing IRL rules.
The rule engine accesses XML directly. It does this in two stages:
At compile time, the XOM uses an XML driver to read XML schemas.
At run time, the rule engine uses the class IlrReflect to manage the
XOM.
The IlrReflect class provides the following services:
Create a new XOM

11/23/2016

page 5 of 22

WODM v7.5

4.
5.
6.
7.

Add a new Java class to the XOM

Retrieve all dynamic classes
Create a dynamic class in the XOM
Add a new dynamic attribute to a dynamic class
Consequently, rules can run directly on dynamic data without the data
being converted to Java objects.
For native Java classes, the rule engine uses Java type introspection to
apply rules directly to the application objects.
The following diagram shows how the rule engine reads XML schemas
directly, through an XML driver.

You can define a dynamic XOM in the New Rule Project

wizard when you create a new rule project, or add it later
using the Rule Project Properties dialog.Pros & Cons on
Java vs. Dynamic XOMs
Best Practice on XOM design
5. Dynamic XOM

When to use XML binding instead of Java XOM

11/23/2016

page 6 of 22

WODM v7.5

9.

10.

XML data binding is the process of representing the information in an XML

document as an object in computer memory (deserialization). This allows
applications to access the XML data direct from the object, rather than
using the Document Object Model (DOM) to retrieve it from the XML file.
This means that XML binding enables you to integrate XML data into a
business rule application.
In JRules, XML data binding is carried out in two stages:
At compile time, the XML Schema Definition (XSD) is processed using a
schema driver. This generates an Executable Object Model (XOM). The
XOM describes how the XML document and your objects are structured.
The XSD is the data model and the XML document is an instantiation of
this model. See Stage 1: XML schema processing for details.
At runtime, the XML document is processed using an XML data driver, to
create an XML object. See Stage 2: XML document processing for details.
ILOG JRules exercises the Java class IlrXmlDefaultDataDriver,
which implements the IlrXmlDataDriver interface, for both these
drivers

How to use XML/XSD for XOM classes

Using Java XOM and Dynamic XOM together
6. Rule Project and Rule Artifacts

What is a Rule Project

To develop a business rule application with Rule Designer, you create a
rule project that contains rule artifacts, Business Object Model (BOM),
vocabulary, and reference to the Execution Object Model (XOM).

Rule Artifacts and how to use them

Creating modular rule project hierarchy

Hierarchies

11/23/2016

page 7 of 22

WODM v7.5

The structure of the items that are managed in a rule project are defined by
a rule model. You can extend this rule model by adding custom properties
to the rule class or by creating a hierarchy property. A hierarchy defines a
tree of values and the hierarchical relationship between the nodes of the
tree.
Runtime rule selection can use hierarchies as a way of providing a further
filtering mechanism.
The following figure shows an example of a geography hierarchy, where
USA is the root node. A location custom property has been defined for
each rule.

The following table shows the BAL constructs that you can use to write the
runtime rule selection for the geography example:
Location property examples
BAL construct
the location of the rule is

Description
Florida

the location of the rule is under

Florida
the location of the rule is over

Returns true if the location

selected for execution.

Returns true if the location

(included) to the hierarchy leave
Florida and Miami, which captur

Florida Returns true if the location

Florida node (included). In this e
rule 2.

11/23/2016

page 8 of 22

WODM v7.5

Best Practice on Rule Project design

When your rule projects grow larger, you can usually improve Rule
Designer performance by using some Rule Designer build configurations
that are better suited to large projects, limiting the BOM footprint, and
reducing the size of business rule artifacts.

Disabling the automatic build

By default in Eclipse, a build process is launched as soon as a resource
changes in the workspace. As a consequence, as soon as you save a file
in Rule Designer, a build runs. The build is usually incremental and fast, so
there is no particular issue with the fact that it runs regularly. However, if
you make changes that have a global impact on the rule project, such as
modifications on the business object model, the build might have to
recheck a lot of elements. The build can be slow if your project is big.
To toggle the Eclipse automatic build option, select Project > Build
Automatically.
Note
If you disable the Eclipse automatic build, rule refactoring might not always
be activated. In this case you must explicitly ask for a build to refresh the
errors in the Problems view.

Setting up preferences for a faster build

When you have a large rule project, particularly one with many decision
tables and ruleflows, the build can become slower. In Rule Designer you
can define preferences for the rule project build. To access the build
preferences page, select Windows > Preferences and then select Rule
Designer > Build.
When you save a rule project item, Rule Designer automatically generates
IRL code and performs some checks on this code, including rule analysis.
You can choose to disable the rule analysis checks only, or to disable all
checks by clearing the Perform IRL checks during build option. If you
disable these options you will not receive warning and error messages
when saving your rules, but the rule project build will be faster.
You can also disable IRL code generation to make the build even faster.
Note
If you disable these build options, more time is required when you extract a
ruleset archive from the rule project, because the IRL code is generated
and checked at that point.

Limiting the number of business rules in rule

11/23/2016

page 9 of 22

WODM v7.5

packages

11.

12.

Rule Designer is usually more efficient when you work with several small
or medium sized packages, as opposed to a few large packages. The
reasons for this are that:
Rule Designer loads only the required packages. If all your rule artifacts
are stored in a single package, Rule Designer must load all the rule
artifacts when you launch it. If your rules are organized into packages,
Rule Designer loads only the rule artifacts from the required packages
when you launch it.
To resolve the fully qualified name of a rule, Rule Designer navigates
through packages to find the rule. If the tree of packages is well distributed,
Rule Designer accesses the rule faster.NoteA fully qualified name is the
short name of the rule prefixed with its package name.
However, make sure that you do not have too many small packages,
because looking for rule model elements slows down Rule Designer.

Reducing the Business Object Model footprint

7.

8.

When your rule project contains a large business object model, business
rule language-related features are slower. Parsing, checking, Content
Assist, and navigation in business rules and technical rules is slower with
large business object models.
To reduce the BOM footprint:
Reduce the BOM size by removing unused verbalizations, BOM members
and classes.When you define a BOM entry from a XOM, the BOM entry
might include a lot of technical classes and methods that are not actually
used in your rules. Because the size of the BOM has an impact on Rule
Designer performance, it is better to remove all unused business elements
from the BOM.
Split the BOM into several smaller BOMs that can be spread among your
rule projects. See Guidelines for organizing your application into rule
projects.

Limiting the size of decision tables and decision

trees
Decision tables containing more than 3,000 rows, given a reasonable
number of columns, significantly increase editing and build time. Tables
with a lot of columns should have less rows, because the main scalability
factor is the number of cells.
To improve the performance of large decision tables and trees, disable
overlap and gap checking.

11/23/2016

page 10 of 22

WODM v7.5

In Rule Designer, you can significantly improve the usability of large

decision tables and trees by setting up the build to disable IRL generation
and checking.

Limiting the size of RuleApps

8.

When a RuleApp archive is generated, the number and size of its rule
artifacts account for most of the resource consumption.
To reduce the resource usage cost of a business rule application:
Transform each large rule project into several smaller ones.
Keep each rule project as it is, and generate multiple smaller rulesets out
of it. You can use ruleset extractors, one per ruleset, to extract part of the
rule project. Note that in this case, you might have to change the
application that executes the rulesets.

7. Business Object Model

Purpose of BOM

You use the BOM to make business rule editing user-friendly by providing
tools to set up a natural language vocabulary. With this vocabulary, policy
managers can describe their business logic in a business rule language.
A BOM contains the classes and methods that rule artifacts act on. As an
object model, the BOM is very similar to a Java object model. It consists of
classes grouped into packages. Each class has a set of attributes,
methods and, possibly, other nested classes.
BOM-to-XOM mapping defines the correspondence between the BOM and
the Execution Object Model (XOM) used at runtime.

11/23/2016

page 11 of 22

WODM v7.5

Dissecting a BOM
Navigation and Action Phrases

13.

14.
15.

You can define several navigation or action phrases for a BOM element, so
that rule authors can use different wordings while using the same method
or attribute.
To add a phrase to a method:
In the Member Verbalization section of the BOM Editor, click either Create
a navigation phrase or Create an action phrase. The phrase appears in
the list of phrases. A warning might appear because the new phrase is
defined with the default verbalization. If you already have the default
verbalization for an existing phrase, there is a conflict because you should
not define the same verbalization twice in the vocabulary.
Click the phrase to expand it, and then in the Template field edit the
verbalization.
Save the BOM.
You can now use the phrase in your business rules.

Customizing and extending BOM

Categories, Domains

Categories
A category is an identifier that you can assign to business rules and certain

11/23/2016

page 12 of 22

WODM v7.5

16.
17.

business elements (classes and members) in order to filter which business

rules can use which business elements. A rule can use a business element
if the rule category filter specifies at least one of the categories assigned to
the business element. Only business elements that a rule can see appear
in the rule editor drop-down list. You can assign one or more categories to
Business Object Model (BOM) classes and members, or to a business rule
category filter.
By default, all business rules, classes and members belong to the
predefined category any. All rules can see the any category, whatever the
category filter in use. The default, therefore, is that all classes and
members can be used in all business rules.
Note
System BOM elements have no category, so are hidden from any business
rule regardless of which rule category filter the rule uses.
Before you can use a category, you must define it at rule project level. If
you define a category in a project that is referenced by another project, the
category is usable in both projects.
There is no inheritance between classes and members, but you can assign
the same category to all members of the same class.
For information on using categories, see:
Defining and assigning categories
Defining a category filter
Category usage summary
If a business element has the
category...

And the business rule category filter

is...

In th
is...

any

any

visib

any

another category

visib

another category

any

visib

category1 and category2

category1

visib

category1 and category2

category2

visib

category1 and category2

category1 and category2

visib

category1 and category2

category3 and category4

hidd

Example
In your Business Object Model, you have a Car class with a category
vehicle. You also have a rule project that contains a business rule

11/23/2016

page 13 of 22

WODM v7.5

CarRentalRule, which has vehicle in its category filter. From

CarRentalRule, you can see all the classes that have the category
vehicle, as well as all classes that have the any category.
CarRentalRule can therefore see the Car class.
If you then define a category sales and assign it to a class Customer,
you will not see the Customer class in the rule editor drop-down list for the
rule CarRentalRule. If you still decide to use the Customer class in the
business rule, it will be reported as a warning.

Similarly, if the Car class has a member with a category other than
vehicle, you cannot use this member in the conditions and actions for
CarRentalRule, even though you can define a variable of the Car type
in the definition2s part of the rule.

Domains
A domain places a restriction on type elements in the BOM. You can set a
domain on classes, attribute types, method return types, and arguments.
The main domains include:
Static domains, comprising Literals, Static references, Bounded,
Collection, and Other domain types.
Dynamic domains, with values stored in an Excel file or set by the
execution of Java code.
Enumerated domains, comprising Literals, Static references, and
Dynamic domain types.
Complex domains, comprising Bounded, Collection, and Other
domain types.
Note
Not all kinds of BOM domain are enforced in BAL rules or other business
rules. Business rules use only enumerated domains (literal, static

11/23/2016

page 14 of 22

WODM v7.5

9.
10.
11.

reference, or dynamic). A semantic check is performed to check that the

business rule does not use a value outside its domain, and the Intellirule
Editor suggests values from the enumerated domains. However, the
semantic check performed at the business rule level is primitive and does
not detect complex patterns of incorrect usage that involves operators
other than is or isnot. Other kinds of domain, such as bounded
domains, are not enforced at business rule level.
You can use domains when working with business rules:
Editing business rules: Code completion in the Intellirule Editor uses
enumerated domains to propose valid settings.
Checking business rules: You use enumerated domains to report errors
and warnings that help you to validate the values you specify.
Analyzing rules: You use all domain types in the BOM to check the
consistency of business rule semantics.
If the XOM has a set of public, static, and final attributes typed to
the declaring class, they are automatically considered as an enumeration
of static references of the class in the BOM.
If the XOM has members of array type, they are automatically considered
as a collection of the class in the BOM.

Bounded
A bounded domain specifies an interval between two bounding values,
such as [0,120].
In the Rule Designer BOM editor, when defining a bounded domain on an
integer attribute, you can specify the * (asterisk) character as the lower or
upper bound of the domain. When you specify *, the bound value is
replaced in the corresponding .bom file by -2147483648 for the lower
bound, or 2147483647 for the upper bound. These values correspond to
Integer.MIN_VALUE and Integer.MAX_VALUE, respectively.
Note
Bounded domains are not enforced at business rule level.

Collection
A collection domain specifies the cardinality and the type of collection
elements, for example, 0,*classCustomer.
If you have members of type java.util.Collection, set a collection
domain on these members for them to be automatically considered as a
collection in business rules. You can also create, add, and remove
methods for the items in the collection domain using the BOM Editor.
For more information, refer to Collections.

11/23/2016

page 15 of 22

WODM v7.5

Dynamic

9.
10.

You can populate a domain in the BOM dynamically from a data source,
and then synchronize the data source and the domain.
A dynamic domain is an enumerated domain with values from an Excel file
or set by the execution of Java code.
You define a dynamic domain in the BOM editor:
To create dynamic domains with values extracted from an Excel file, see
Creating dynamic domains from Excel .
To create dynamic domains with values extracted from other data sources,
see Creating dynamic domains.
Note
You can create a dynamic domain only on a BOM class.

Literals
A domain set as an enumeration of literals specifies a list of values, for
example, {1,2,3}.

Static references

4.
5.

A domain set as an enumeration of static references specifies a list of

references to constants, for example, {staticGroupA,static
GroupB,staticGroupC}.
You can define attribute types and method return types and arguments as
follows:
If you have an attribute of type A, you can define a domain of static
references on it using the static attributes of the class A (classic Java
enumeration pattern).
If you have an attribute of a primitive type, you can define a literal domain
on it.

Other
The other domain types were introduced to support most domains coming
from the XML binding. In an XML schema, you can define pattern domains
(even for numbers) and simultaneously an enumeration. You can also
define pattern domains or intersection of domains in the business object
model.
You can define other types of domains using the syntax of regular
expressions. For example, you can define a pattern for Strings as follows:
"a*n"
You can define an intersection of domains as follows:
({1, 3, 5, 7, 9}, [0,6])

11/23/2016

page 16 of 22

WODM v7.5

Note
Other domains are not enforced at business rule level.

Mapping BOM to XOM

Best Practices on BOM
8. Rule Authoring

Basics of authoring rules

You can express a business policy using:
Action rules
o Business users and developers use action rules to manage
business policy statements independently from the logic of
enterprise applications.
o Action rules express policy statements in a predefined
business vocabulary that can be interpreted by a computer.
Action rules have the following basic structure:
definitions
if
then
else
Decision tables and decision trees
o Decision tables are composed of rows and columns. As shown
in the following table, each row corresponds to a single rule
, with the columns defining the conditions
and actions
of the rules. The top row
of the table contains the
column header, where you give the names of the different
columns.
o

o You can add new rows to a decision table and fill in its cells to

11/23/2016

page 17 of 22

WODM v7.5

create new rules. When the rules are executed, if the

conditions of a given row are met, the actions in that row are
performed. You can also add preconditions that apply to all the
rules, see Preconditions.
o See Columns for more information about how you manage
condition and action columns, and Rows and cells to learn
how you fill in rows and cells in decision tables.
o Decision tables also make it easy to see whether you have
any overlap or gaps in your rules.

Decision trees
Decision trees provide an alternative and more convenient way of viewing
and managing large sets of business rules, especially when these rules
are not symmetric.
Large sets of nonsymmetric rules may be easier to understand using
decision trees, where the path from the first condition to the end of the
actions along any branch corresponds to one rule.

Looking at the following figure, you can see that decision trees are easy to
use once you understand that:
A condition is declared in its diamond-shaped node
.
The possible values for the condition are represented by
branches
.
The actions are declared at the end of each branch
.
Technical rules
Technical rules are written using the ILOG Rule Language (IRL). IRL is a
Java-like rule language that can be executed directly by the rule engine.
A technical rule is made of a condition part and an action part.
The condition part, which begins with the keyword when,

11/23/2016

page 18 of 22

WODM v7.5

binds variables to objects and attribute values, and

specifies tests on attribute values. This provides a filtering
mechanism for objects.Examples of ILR condition
keywords are:
1 collect
2 evaluate
3 exists
4 from
5 in
6 instanceof
7 not
8 where

The action part, which begins with the keyword then,

specifies the actions to be carried out if the rule is
executed. It includes an optional second part which begins
with the keyword else, that applies only if the last
evaluated statement in the condition part is false.Examples
of ILR action keywords are:
9 break
10 catch
11 continue
12 foreach
13 modify
14 retract
15 try
16 update
17 throw
while

BAL
You use constructs to build rules. You use operators to perform arithmetic
operations, associate or negate conditions, and compare expressions. You
use literals to declare values as being of a particular type. You use
punctuation to structure rules, avoid ambiguity, and provide clarity.

Low level rule authoring in IRL

11/23/2016

page 19 of 22

WODM v7.5

Best Practices in rule authoring

9. Orchestration - Ruleflow and Execution

What is a Ruleflow and why is it needed?

How to create rule flow
Functions and Ruleset variables

Functions
A function can be created in a rule project in order to share code
procedures across more than one element of a ruleset. A function is
expressed in ILOG Rule Language (IRL) and its code is evaluated when
the ruleset executes.
A function can be called either from the action part of a rule, from another
function, or from an action task of a ruleflow.
You can add as many functions to the rule project as you like. The code
that you write in a function in Rule Designer is mapped to the IRL
function keyword.
Functions can be used to set up the working memory when testing ruleset
execution.
The function is composed of a header and a statement part.
The header contains the function return type and its signature. A function
signature consists of the function name and an argument list. This list can
be either empty or composed of pairs: the argument type and name,
separated by commas.
function returnType functionName (argumentList)
{
code
}
The statement part can contain any action statements, just as in the action
part of a rule, plus a return statement.
You use return to exit from the current function. The flow of control
returns to the statement that follows the original function call. The return
statement has two forms: one that returns a value and one that does not.
To return a value, simply put the value (or an expression that calculates the
value) after the return keyword:
return ++count;

11/23/2016

page 20 of 22

WODM v7.5

The data type of the value returned by return must match the type of the
functions declared return value. When a function is declared void, use the
form of return that does not return a value:
return;

A ruleset variable defines a value of a specified type and verbalization. You

can use ruleset variables in all the business rules you add to a rule project.

Defining a ruleset variable

To define a ruleset variable:
In the Variable Set editor, click Add.Default values for a new ruleset
variable are displayed in a table row.

Specify the name, type and (optionally) the initial value of the ruleset
variable.
If you do not want the ruleset variable to be visible from business
rules, delete the default verbalization from the Verbalization column.
Otherwise, modify the verbalization.
The ruleset variable is now defined and you can start using it in business
rules.

How to customize run time rule selection

Best Practices on Rule Orchestration

11/23/2016

page 21 of 22

WODM v7.5

11/23/2016

page 22 of 22