Oracle® Fusion Middleware Language Reference Guide for Oracle Business Rules 11g Release 1 (11.1.1.5.0) E10227-04 |
|
![]() Previous |
![]() Next |
This chapter contains a detailed and complete reference to the Oracle Business Rules RL Language (RL Language) syntax, semantics, and built-in functions.
Grammar rules define the RL Language. Each grammar rule defines a non-terminal symbol on the left of the ::=
symbol in terms of one or more non-terminal and terminal symbols on the right of the ::=
symbol.
Reserved Words
aggregate, boolean, break, byte, catch, char, class, constant, continue, double, else, exists, extends, fact, factpath, false, final, finally, float, for, function, hide, if, import, include, instanceof, int, long, modify, new, null, property, public, query, return, returns, rule, rulegroup, ruleset, short, supports, synchronized, throw, true, try, while, var
Note: Reserved words in bold apply to the current release. Reserved words that are not shown in bold typeface are planned for a future RL Language release, and include the words: break, continue, and query. |
A ruleset groups a set of definitions. A ruleset is a collection of rules and other definitions that are all intended to be evaluated at the same time. A ruleset may also contain executable actions, may include or contain other rulesets, and may import Java classes and packages.
Format
ruleset ::= named-ruleset | unnamed-ruleset
named-ruleset ::= ruleset ruleset-name { unnamed-ruleset }
unnamed-ruleset ::= ( import | include | named-ruleset | definition | action | fact-class | rulegroup)*
ruleset-name ::= identifier
Usage Notes
A named-ruleset creates or adds definitions to the specified ruleset named ruleset-name.
An unnamed-ruleset adds definitions to the default ruleset named main
.
Rulesets may be nested, that is they may contain or include other rulesets. Nesting does not affect ruleset naming, but it does affect ruleset visibility in a way similar to Java import's affect on package visibility.
You can execute a ruleset using the RL Language command-line, or using the Java RuleSession API.
A named-ruleset ruleset-name must be unique within a RuleSession
.
Examples
Example 2-1 contains two definitions, enterRoom
and sayHello
, and two actions (assert and run).
The rule shown in Example 2-1 will not fire until:
An enterRoom
fact is asserted.
The run function executes, which pushes the rule's containing ruleset, hello
onto the ruleset stack.
Example 2-1 Using a Named Ruleset
ruleset hello { class enterRoom { String who; } rule sayHello { if (fact enterRoom) { println("Hello " + enterRoom.who); } } assert(new enterRoom(who: "Bob")); run("hello"); }
In Example 2-2, if ruleset R2 is nested in ruleset R1, the name R2 must be unique within the rule session. R2 is not named relative to R1. For example, the class C2 defined in R2 is globally named R2.C2, not R1.R2.C2. If R2 is nested in R1, a public class C1 defined in R1 may be referenced in R2 using either the full name R1.C1 or the short name C1 (assuming R2 does not also define C1).
Example 2-2 Using a Nested Ruleset
ruleset R1 { public class C1 { public String s; } C1 apple = new C1(s: "apple"); ruleset R2 { public class C2 { public String s; } C1 c1 = apple; // finds C1 and apple in containing ruleset R1 c1.s = "delicious"; C2 c2 = new C2(s: "pear"); } R2.C2 pear = R2.c2; // finds R2.C2 and R2.c2 because they are fully qualified println(apple.s + " " + pear.s); // prints "delicious pear" pear = c2; // UndefinedException: c2 not in R1 or a containing ruleset }
RL Language is a strongly typed language. Each variable and value has a specified type.
Format
type ::= simple-type [ [ ] ]
simple-type ::= primitive | object-type
primitive ::= boolean | numeric
numeric ::= int | double | float | long | short | byte | char
object-type ::= class-definition-name | Java-class-name
class-definition-name ::= qname
Java-class-name ::= qname
Type Conversion
There are several ways that a value can be converted from one type to another:
Conversion from any type to String
using the String
concatenation operator +
.
Implicitly from context. For example, by adding an int
to a double
first converts the int
to a double
and then adds the 2 doubles
.
Casting between 2 numeric types.
Casting between 2 classes related by inheritance.
Invoking a function or method that performs the conversion. For example, toString
.
Table 2-1 summarizes the implicit conversions for various types. Rows indicate how the type in the From column may be implicitly converted, as shown in the list of types shown in the To column.
Table 2-1 Implicit Type Conversions
From | To |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Note: An Object is an instance of a Java or RL Language class or array. Type conversion is possible only if the classes are related by inheritance (implements or extends). |
Table 2-2 summarizes the allowed cast conversions for various types where a cast can be used to convert a primitive with more bits to a primitive with fewer bits, without throwing an exception.
The type conversions shown in Table 2-2 require an explicit cast operator. For example,
int i = 1; short s = (short)i;
Note: Type conversions such as those shown in Table 2-2 that involve numeric types may lose high order bits, and such conversions involving Objects may throw aRLClassCastExeption . |
Table 2-2 Explicit Type Conversions
From | To |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
When you use a cast to convert a primitive with more bits, to a primitive with fewer bits, the RL Language discards extra, high order, bits without throwing an exception.
For example,
short s = -134; byte b = (byte)s; println("s = " + s + ", b = " + b); prints: s = -134, b = 122
Primitive Types
A primitive type may be any of the following
An int
, which is a 32 bit integer. Literal values are scanned by java.lang.Integer.parseInt
A long
. Literal values are scanned by java.lang.Long.parseLong
A short
. Literal values are scanned by java.lang.Short.parseShort
A byte
. Literal values are scanned by java.lang.Byte.parseByte
A char
.
A double
. Literal values are scanned by java.lang.Double.parseDouble
A float
. Literal values are scanned by java.lang.Float.parseFloat
A boolean
true
or false
Object Types
A java Object
, identified by the qualified name, qname, of its class. For example, java.lang.String
.
An RL Language Object
, identified by the qualified name, qname of its class. For example, ruleset1.Class1
.
String Types
RL Language uses Java strings, where:
Strings are instances of the class java.lang.String
.
A string literal is delimited by double quotes ("string").
Use \" to include the double quote character in a string.
Strings may be concatenated using the +
operator as follows:
If any operand of a +
operator is a String then the remaining operands are converted to String and the operands are concatenated.
An Object is converted to a String using its toString
method.
An instance of an RL Language class is converted to a String using a built-in conversion.
Array Types
Square brackets [
]
denote arrays. An array in RL Language has the same syntax and semantics as a Java 1-dimensional array.
Note: RL Language does not support multi-dimensional arrays. |
RL Language supports both the Java and the XML variant of identifiers and namespace packages. To use the XML variant, the identifier must be enclosed in back quotes.
Format
identifier ::= java-identifier | xml-identifier
java-identifier ::= valid-Java-identifier
xml-identifier ::= `valid-xml-identifier or URI `
Where:
valid-Java-identifier is: a legal Java identifier, for example, JLd_0.
valid-xml-identifier is: a legal XML identifier, for example x-1.
URI is: a legal Uniform Resource Identifier, for example, http://www.oracle.com/rules
Usage Notes
An xml-identifier can contain characters that are illegal Java identifier characters, for example, ':' and '-'. The JAXB specification defines a standard mapping of XML identifiers to Java identifiers, and includes preserving the Java conventions of capitalization. The JAXB specification also defines a standard mapping from the schema target namespace URI to a Java package name, and a mapping from anonymous types to Java static nested classes.
Examples
RL Language supports both the Java and the XML variant of identifiers and namespaces or packages. Enclose an identifier in back quotes to use the XML variant, as shown in Example 2-3.
You can use the back quote notation anywhere an identifier or package name is legal in RL Language. To use the XML variant of identifiers in String
arguments to assertXPath, back quotes are not needed.
Table 2-3 summarizes the RL Language literals. The literals are the same as Java literals.
Table 2-3 RL Language Literals
A literal such as | Can be assigned to variables of these types |
---|---|
An integer in range 0..127 or a |
|
An integer in range 0..65535 or a |
|
An integer in range -128..127 |
|
An integer in range -32768..32767 |
|
An integer |
|
An integer with |
|
A floating point constant |
|
A floating point constant with |
|
A String enclosed in "" |
|
When a definition within a ruleset is executed, it is checked for correctness and then saved for use later in the rule session.
Format
definition ::= variable | rule | rl-class-definition | function
name ::= identifier
qname ::= [ ruleset-or-packagename. ]name
ruleset-or-packagename ::= qname
Usage Notes
Every definition has a unique name within its containing ruleset, and thus a unique qualified name, qname, within the rule session.
Variables defined at the ruleset level are global. Global variables are visible to all expressions contained in the ruleset using the name of the variable and visible to expressions in other rulesets using the variable qname. Functions and public classes may also be referenced from other rulesets using the respective qname.
Java classes and their methods and properties also have qnames.
Example
The qname of the class definition in Example 2-4 is hello.enterRoom
.
Example 2-4 Class Definition Within a Named Ruleset
ruleset hello { class enterRoom { String who; } rule sayHello { if (fact enterRoom) { println("Hello " + enterRoom.who); } } assert(new enterRoom(who: "Bob")); run("hello"); }
Variables are declared as in Java, but initialization is always required.
Format
variable ::= [ final ] ( numeric name = numeric-expression
| boolean name = boolean-expression
| type [ ] name = array-expression | null
| object-type name = object-expression | null )
) ;
Usage Notes
The type of the array initialized with the array-expression must be the same as the type specified for the array elements.
A variable can have a primitive type, a Java class name, or an RL Language class name, and may be an array of elements of the same type.
The type of the object-expression must be the same as the object-type of the variable being declared. A class instance or array may be initialized to null.
Variables may be local or global in scope. The initialization expression is required. Local variables may not be final.
Variables immediately enclosed in a ruleset, that is, in a definition, are global to a rule session in scope. The initialization expression for a final global variable is executed when the global variable is defined.
The initialization expression for a non-final global variable is executed both:
When the global variable is defined.
Each time the reset
function is called.
Global variables declared as final may not be modified after they are initialized.
Global variables referenced in a rule condition (fact-set-condition) must be final.
Examples
Example 2-5 shows that the reset function performs initialization for the non-final global variable i
. Thus, this example prints 0, not 1.
Example 2-5 Non-Final Global Variable Initialization After Reset Function
RL> int i = 0; RL> i++; RL> reset(); RL> println(i);
Be careful when initializing global variables with functions that have side effects. If you do not want the side effects repeated when calling reset, you should declare the variable final
. For example, Example 2-6 prints "once" twice and Example 2-7 prints "once" once.
Example 2-6 Initializing a Global Variable with Side Effects with Reset
RL> clear; RL> function once() returns int { println("once"); return 1; } RL> int i = once(); once RL> reset(); once RL>
Example 2-7 Initializing a Final Global Variable to Avoid Side Effects with Reset
RL> clear; RL> function once() returns int { println("once"); return 1; } RL> final int i = once(); once RL> reset(); RL>
The Oracle Rules Engine matches facts against the fact-set-conditions of all rules in the rule session to build the agenda of rules to execute. A fact set row is a combination of facts that makes the conditions of a rule true. An activation is a fact set row paired with a reference to the action-block of the rule. The agenda is the list of all activations in the rules session. The Oracle Rules Engine matches facts and rules when the state of working memory changes, typically when a fact is asserted or retracted.
The run, runUntilHalt, and step functions execute activations. Activations are removed from the agenda after they are executed, or if the facts referenced in their fact set row are modified or retracted such that they no longer match the rule's condition.
Activations are executed in order of the ruleset stack. You can manage the ruleset stack with the getRulesetStack, clearRulesetStack, pushRuleset, and popRuleset functions.
In order for a rule to fire, three things must occur:
An activation of that rule must be on the agenda.
The containing ruleset must be at the top of the ruleset stack.
You must invoke run, runUntilHalt, or step.
The fact set produced in a fact-set-condition is available to the rule actions. For each row in the fact set, the action-block is activated as follows:
The rule's action-block is scheduled for execution at the specified rule priority.
References from the action-block to the matched facts are bound to the current row.
If a matched fact is retracted before the action-block is executed, the dependent activations are destroyed (removed from the agenda).
Format
rule ::= rule rule-name { property* fact-set-condition action-block }
rule-name ::= name
property ::= priority | autofocus | logical | active
priority ::= priority = numeric-expression
autofocus ::= autofocus = boolean-literal
logical ::= logical = ( boolean-literal | positive-integer-literal )
active ::= active = boolean-literal
effectiveDateForm ::= effectiveDateForm = an int restricted to one of values defined in oracle.rules.rl.Rule: EDFORM_DATE, EDFORM_DATETIME, or EDFORM_TIME
effectiveStartDate ::= effectiveStartDate = expression of type java.util.Calendar
effectiveEndDate ::= effectiveEndDate = expression of type java.util.Calendar
Where:
positive-integer-literal is: an integer literal that is > 0
Usage Notes
The priority property specifies the priority for a rule. Within a set of activations of rules from the same ruleset, activations are executed in priority order (see "Ordering Rule Firing"). When rules have different priorities, the rules with a higher priority are activated before those with a lower priority. The default priority is 0. Within a set of activations of rules of the same priority, the most recently added activations are executed first, but this behavior can be changed (see the getStrategy and setStrategy functions).
A rule with the autofocus property equal to true
automatically pushes its containing ruleset onto the ruleset stack whenever it is activated.
A rule with the logical property makes all facts asserted by the rule's action block dependent on some or all facts matched by the rule's condition. An integer value of n for the logical property makes the dependency on the first n top-level &&
ed fact set expressions in the rule's condition. A boolean value of true
for the logical property makes the dependency on the fact set expression of the condition. Anytime a fact referenced in a row of the fact set changes such that the rule's logical conditions no longer apply, the facts asserted by the activation associated with that fact set row are automatically retracted. A rule with the logical property enabled makes all facts that are asserted by an action block in the rule dependent on facts matched in the rule condition. Anytime a fact referenced in the rule condition changes, such that the rule's conditions no longer apply, the facts asserted by the rule condition are automatically retracted.
The active property defaults to true
.
effectiveStartDate date defaults to null.
effectiveEndDate date default to null.
effectiveDateForm defaults to Rule.EDFORM_DATETIME
Examples
Example 2-8 shows a rule with the inference, Socrates is mortal, which depends on the fact, Socrates is a man.
Example 2-8 Defining and Using Rule allMenAreMortal
RL> clear; RL> class Man {String name;} RL> class Mortal {String name;} RL> Mortal lastMortal = null; RL> rule allMenAreMortal { logical = true; if (fact Man) { assert(lastMortal = new Mortal(name: Man.name)); } } RL> watchAll(); RL> Man socrates = new Man(name: "Socrates"); RL> assert(socrates); ==> f-1 main.Man (name : "Socrates") ==> Activation: main.allMenAreMortal : f-1 RL> run(); Fire 1 main.allMenAreMortal f-1 ==> f-2 main.Mortal (name : "Socrates") <== Focus main, Ruleset stack: {} RL> retract(socrates); <== f-1 main.Man (name : "Socrates") <== f-2 main.Mortal (name : "Socrates") RL> showFacts(); f-0 initial-fact()
Example 2-9 shows that it is possible for the same fact to be asserted by multiple rules, or to be asserted by a top-level ruleset action or function. Such a fact will not be automatically retracted unless all asserters have logical clauses that call for automatic retraction. A fact that is asserted by a top level action or function will never be automatically retracted.
Note that the fact that Socrates is mortal is not retracted, because it was asserted by a top level action that is not dependent on the fact that Socrates is a man.
Example 2-9 Asserting Facts Unconditionally
RL> assert(socrates); ==> f-3 main.Man(name : "Socrates") ==> Activation: main.allMenAreMortal : f-3 RL> run(); Fire 1 main.allMenAreMortal f-3 ==> f-4 main.Mortal(name : "Socrates") <== Focus main, Ruleset stack: {} RL> assert(lastMortal); <=> f-4 main.Mortal(name : "Socrates") RL> retract(socrates); <== f-3 main.Man(name: "Socrates") RL> showFacts(); f-0 initial-fact() f-2 main.Mortal(name: "Socrates")
All referenced classes must be defined with an RL Language class definition or must be on the Java classpath (Java classes must be imported).
Both RL Language classes and Java classes can support xpath using the supports keyword, with a supplied xpath.
Format
rl-class-definition ::= [ public ] [ final ] class name [ extends ] [ supports ] { type-property* }
type-property ::= [ public ] type name [ = expression ] ;
extends ::= extends qname extended-class-name
extended-class-name ::= qname
Usage Notes
The type of the optional initialization expression must be the same as the type of the property or implicitly convertible to that type.
A public class is visible from all rulesets. A non-public class is visible only in the containing ruleset.
A final class cannot be extended.
The extended class must be a defined RL Language class not an imported Java class.
Each property may have an optional initializer. The initializer is evaluated when the class is instantiated by new. If an initial value is also passed to new, the value passed to new overwrites the value computed by the initializer in the class definition.
A public property is visible from all rulesets. A non-public property is visible only within its containing ruleset.
Examples
In RL Language, the type of an property may be the name of the containing class definition (see Example 2-10). RL Language, unlike Java, does not support forward references to class definitions (see Example 2-11).
Example 2-10 Class Definition with Type of Property with Name of Containing Class
class C0 { C0 next; }
Example 2-11 Class Definitions with Forward References are Not Allowed
class C1 { C2 c2; // causes an UndefinedException } class C2 { C1 c1; }
Both RL Language classes and Java classes support xpath.
An xml identifier does not need to be surrounded by back quotes within an xpath.
The built-in assertXPath function supports a simple xpath-like syntax to assert a tree of objects as facts. The nodes in the tree are objects from classes in the same package or ruleset that support xpath. The links between parent and child nodes are instances of the XLink
class. All of the properties in a class that supports xpath may be used in the xpath expression.
Format
xpath ::= first-step next-step*
first-step ::= ( . | /* | [ // ] ( identifier | * ) ) predicate*
predicate ::= [ identifier xrelop literal ]
next-step ::= ( / | // ) ( identifier | * ) predicate*
xrelop ::= eq | lt | gt | le | ge | ne | == | < | > | <= | >= | !=
literal ::= integer-literal | decimal-literal | double-literal | string-literal | true | false | dateTime-literal | date-literal | time-literal
integer-literal ::= [-] d+
d ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
decimal-literal ::= [-] ( . d+ | d+ . d*)
double-literal ::= [-] ( . d+ | d+ [ . d* ] ) ( e | E ) [+ | -] d+
string-literal ::= " char* " | ' char* '
dateTime-literal ::= local-date T time-literal
date-literal ::= local-date [ time-zone ]
time-zone ::= Z | ( + | - ) d d : d d
local-date ::= d d d d - d d - d d
time-literal ::= d d : d d : d d [. d+] [ time-zone ]
Usage Notes
RL Language xpath support was designed to work with classes that conform to the Java XML Binding (JAXB) 1.0 standard. All JAXB elements from the given root to the elements selected by the xpath, inclusive, are asserted. Additional XLink facts are asserted to aid in writing rules about the parent-child relationships among the asserted elements.
If a JAXB element is retracted or re-asserted, using assert, then all of its children, and XLinks, are retracted. Instead of re-asserting, use assertXPath again.
Note that RL Language Xpath is not a proper subset of W3C Xpath 2.0. Note the following differences:
The lt
and <
, gt
and >
, are synonymous in RL Language but different in W3C.
Date literals must use xs:date()
and other constructors in W3C.
Constructors are not supported in RL Language, and literals, other than string literals, must not be quoted in RL Language.
Examples
Table 2-4 shows the xpath selection options for use with the built-in assertXPath function. In the descriptions, select means that the element is asserted as a fact, and the selected property of the XLink whose element property refers to the asserted element is true
. The ancestors of a selected element, up to and including the root element, are always asserted, but not necessarily selected.
Table 2-4 xpath Selection Strings
xpath Select String | Description of Selection |
---|---|
//* |
Select all elements including the root |
.//* |
Select all but the root |
. |
Select only the root |
//foo |
Select all objects that are the value of a property named foo. |
.[x==1]/y |
Select children or attributes of root named y only if the root has a child element or attribute named x and equal to 1 |
Example 2-12 instantiates an RL Language class called Person to build a family tree, as follows:
First Generation Second Generation Third Generation Ida Mary Fred John Rachel Sally Evan
Example 2-12 uses the assertXPath function twice, with two xpaths:
//kids[male==true] //kids[male==false]
Example 2-12 defines two rules:
sibling
: prints all pairs of siblings.
brotherSister
: prints all pairs of brothers and all pairs of sisters.
Example 2-13 shows the output from running Example 2-12.
Example 2-12 Sample Family Tree Rule Using supports xpath
import java.util.*; ruleset xp { public class Person supports xpath { public String name; public boolean male; public List kids; } // Build the Family Tree Person p = new Person(name: "Fred", male: true); List k = new ArrayList(); k.add(p); p = new Person(name: "John", male: true); k.add(p); p = new Person(name: "Mary", male: false, kids: k); Person gramma = new Person(name: "Ida", male: false, kids: new ArrayList()); gramma.kids.add(p); p = new Person(name: "Sally", male: false); k = new ArrayList(); k.add(p); p = new Person(name: "Evan", male: true); k.add(p); p = new Person(name: "Rachel", male: false, kids: k); gramma.kids.add(p); // test for siblings. // Note the test id(p1) < id(p2) halves the Cartesian product p1 X p2. rule sibling { if (fact Person p1 && fact Person p2 && id(p1) < id(p2) && exists(fact XLink(element: p1) x && fact XLink(element: p2, parent: x.parent))) { println(p1.name + " is sibling of " + p2.name); } } // test for brothers and sisters, given the following 2 assertXPath() calls rule brotherSister { if (fact Person p1 && fact Person p2 && id(p1) < id(p2) && exists(fact XLink(element: p1, selected: true) x && fact XLink(element: p2, selected: true, parent: x.parent) y && x.samePath(y))) { println(p1.name + " and " + p2.name + " are " + (p1.male ? "brothers" : "sisters")); } } assertXPath("xp", gramma, "//kids[male==true]"); assertXPath("xp", gramma, "//kids[male==false]"); run("xp"); }
Example 2-13 Output from Run of Family Tree Example
Mary and Rachel are sisters Evan is sibling of Sally Fred and John are brothers Fred is sibling of John Mary is sibling of Rachel
Example 2-14 shows that when you retract an element that was asserted with assertXPath
, all its descendents are retracted as well.
The result is:
f-0 initial-fact()
For a total of 1 fact.
Example 2-15 prints all pairs of ancestors. First, the family tree is asserted. Example 2-16 shows the output of a run of the code from Example 2-15.
Example 2-15 Print Ancestor Pairs with Class Ancestor
assertXPath("xp", xp.gramma, "//*"); class Ancestor { Object element; Object ancestor; } rule parents { if (fact XLink x) { assert(new Ancestor(element: x.element, ancestor: x.parent)); } } rule ancestors { if (fact XLink x && fact Ancestor(ancestor: x.element) a) { assert(new Ancestor(element: a.element, ancestor: x.parent)); } } rule printAncestor { if (fact xp.Person p && fact xp.Person a && fact Ancestor(element: p, ancestor: a) { println(a.name + " is an ancestor of " p.name); } } run();
Example 2-16 Output from Run of Ancestor Example
Mary is an ancestor of John Ida is an ancestor of John Mary is an ancestor of Fred Ida is an ancestor of Fred Ida is an ancestor of Mary Rachel is an ancestor of Evan Ida is an ancestor of Evan Rachel is an ancestor of Sally Ida is an ancestor of Sally Ida is an ancestor of Rachel
A function is similar to a Java static method.
Format
function ::= function name parameters [ returns type ] action-block
parameters ::= ( [ type identifier ( , type identifier )* ] )
Usage Notes
The action-block may invoke the function being defined. However, the action-block may not contain a forward reference to a function that has not already been defined (see Example 2-17 and Example 2-18).
Functions may be overloaded. For example, the built-in println function is overloaded.
Examples
Any Java class can be used as an RL Language fact in a fact context.
A fact context is one of:
The class of a fact-class declaration.
The class of a fact-set-pattern.
The declared class of an argument to the assert function.
The declared class of an argument to the retract function.
The declared class of an element argument to the assertXPath function.
If a class or interface B
implements or extends class or interface A
, and both A
and B
appear in fact contexts, then A
must appear before B
. Failure to follow this rule will result in a FactClassException
.
Fact class definitions are not required when using RL Language classes.
For xpath support, use the supports xpath clause of the RL Language class definition.
Format
fact-class ::= fact class class-name [ supports ] ( fact-class-body | ; )
class-name ::= qname
fact-class-body ::= { [ hidden-properties | properties ]}
hidden-properties ::= hide property * ; | ( hide property ( ( name , )* name | * ) ; )+
properties ::= property * ; | ( property ( ( name , )* name | * ) ; )+
Usage Notes
The fact-class-body is optional in a fact-class declaration. The default fact-class-body is:
{ property *; }
Either the property
or hide property
keywords can be used in a body, but not both.
If hide property
is used with a list of property names, then those property names are hidden and not available for use in RL Language.
If hide property
is used with the wildcard "*", then no properties other than those exposed by a superclass or superinterface are available for use in RL Language.
If property
is used with a list of property names, then those properties are exposed and available for use in RL Language. If property is used with the wildcard *
, then all properties other than those hidden by a superclass or superinterface are available for use in RL Language.
A HiddenPropertyException
will be thrown if a superclass exposes a property that its subclass hides or if a subclass exposes a property that its superclass hides.
Examples
Suppose a Java class Vehicle
has subclasses Car
and Truck
. The rule shown in Example 2-19, matchVehicle
, generates a TypeCheckException
wrapping a FactClassException
because the subclasses are referenced before the superclass. Wrapping is used instead of subclassing for both FactClassException
and MultipleInheritanceException
because in some fact contexts, these exceptions are not thrown until runtime and then are wrapped by a RLRuntimeException
.
Example 2-19 matchVehicle Rule with Subclasses Referenced Before the Superclass
assert(new Car()); // fact context for Car assert(new Truck()); // fact context for Truck rule matchVehicle { if (fact Vehicle v) { // fact context for Vehicle - too late! if (v instanceof Car) { println("car"); } else { println("truck"); } } } // generates a TypeCheckException wrapping a FactClassException
In Example 2-20, the matchVehicle
rule is the first reference to the superclass, so no exception is thrown.
Example 2-20 matchVehicle Rule with References to Superclass First
clear; rule matchVehicle { if (fact Vehicle v) { if (v instanceof Car) { println("car"); } else { println("truck"); } } } assert(new Car()); assert(new Truck()); run(); // prints "truck" then "car"
In Example 2-21, a fact class declaration is the first reference to the superclass, so no exception is thrown.
Example 2-21 matchVehicle Rule with Fact Class Declaration with Reference to Superclass First
clear; fact class Vehicle; assert(new Car()); assert(new Truck()); rule matchVehicle { if (fact Vehicle v) { if (v instanceof Car) { println("car"); } else { println("truck"); } } } run(); // prints "truck" then "car"
Facts do not support multiple inheritance. Consider the Java classes and interfaces shown in Example 2-22.
Example 2-22 Java Classes and Sample Multiple Inheritance
package example; public class Car {} public interface Sporty {} public class SportsCar extends Car implements Sporty {}
Example 2-23 entered at the command-line results in a TypeCheckException
that wraps a MultipleInheritanceException
. Use the getCause
method on the TypeCheckException
to retrieve the wrapped MultipleInheritanceException
exception.
Example 2-23 MultipleInheritance Exception for Facts
import example.*; fact class Sporty; fact class Car; fact class SportsCar; // throws TypeCheckException wrapping a MultipleInheritanceException
Example 2-24 illustrates an exception that occurs at runtime when the Oracle Rules Engine attempts to assert the rx8
object and discovers its true type is SportsCar
, not Object
. To avoid the MultipleInheritanceException
, you must choose whether to use Sporty
or Car
in a fact class context. You cannot use both.
Example 2-24 RLRuntimeException wraps MultipleInheritanceException
import example.*; fact class Sporty; fact class Car; Object rx8 = new SportsCar(); assert(rx8); // throws RLRuntimeException wrapping a MultipleInheritanceException
Example 2-25 FactClassException Possible Cause
oracle.rules.rl.FactClassException: fact class for 'X' should be declared earlier in rule session
Note the fact context rule is:
If X is a subclass or subinterface, of Y, then Y must appear in a fact context before X. A fact context is a fact-class declaration, a rule fact pattern, or the argument of assert, assertXPath, or retract.
In some cases you need to consider the fact context. For example, with an XML schema such as the following:
<schema> <element name=A type=T/> <complexType name=T> <sequence> <element name=B type=T/> </sequence> </complexType> </schema>
JAXB generates:
interface T { List getB(); // List has TImpl objects } interface A extends T; class AImpl implements A extends TImpl; class TImpl implements T;
In an example with the following order of appearance in fact contexts:
fact
class
T
assertXPath
AImpl
assert
TImpl
(performed internally by the assertXPath
implementation)
The, AImpl
precedes TImpl
in the ordering, yet AImpl
extends TImpl
, which would give the exception. The fix for this fact context is to explicitly issue fact class TImpl;
anywhere before Step 2.
An import statement makes it possible to omit the package name qualification when referencing Java classes.
Format
import ::= import ( Java-class-name | Java-package-name.* ) ;
Java-package-name ::= qname
Usage Notes
Import commands can be placed inside a ruleset, implying that the scope of the import is the ruleset where the import is located, but the import actually applies globally. For example, in the following code if the imports were scoped to the rulesets, then the PrintWriter
reference in r2
would not compile.
class X { } ruleset rl { import java.io.*; rule A { if ( fact X ) {
@ PrintWriter pw = null; } } } ruleset r2 { rule B { if ( fact X ) { @ PrintWriter pw = null; } } }
Include the ruleset at the location specified by the URL.
Format
Where:
URL is: A legal Uniform Resource Locator.
Usage Notes
The file:
and http:
schemes are supported.
Example
include file:example.rl;
Expressions in RL Language use familiar Java syntax (with minor variations as noted). For example,
(a + 1) * (b - 2)
Use expressions in a condition or in an action, with some restrictions. Expressions are strongly typed.
Format
expression ::= boolean-expression
| fact-set-expression | object-expression
Boolean expressions, as in Java, may be either true
or false
.
Format
boolean-expression ::= boolean-assignment
| boolean-expression ? boolean-expression : boolean-expression
| boolean-expression || boolean-expression
| boolean-expression && boolean-expression
| numeric-expression equal-op numeric-expression
| object-expression equal-op object-expression
| boolean-expression equal-op boolean-expression
| object-expression instanceof type-name
| numeric-expression relop numeric-expression
| string-expression relop string-expression
boolean-assignment ::= boolean-target-expression = boolean-expression
type-name ::= qname
Usage Notes
For strings, <
is Unicode UCS2 code point order.
For objects,!=
does not test for inequality of object references, but rather is the negation of the equals methods.
Thus, the statement:
if (object1 != object2){}
Is equivalent to the statement:
if (! (object1.equals(object2)){}
RL Language, unlike Java, does not support testing for equality of object references.
Example
Example 2-26 shows use of a boolean expression in RL Language.
Example 2-26 RL Boolean Expression
if ( (true ? "a" < "b" : false) && (1 == 0 || 1.0 > 0) && "x" instanceof Object ) { println("all true"); };
Numeric expressions, as in Java, implicitly convert integer operands to floating point if other operands are floating point. Table 2-1 shows other implicit conversions.
Format
numeric-expression ::= numeric-assignment
| boolean-expression ? numeric-expression : numeric-expression
| numeric-expression( + | - ) numeric-expression
| numeric-expression ( * | / | % ) numeric-expression
| numeric-expression ** numeric-expression
| ( numeric-cast ) numeric-expression
| ( + | - ) numeric-expression
| ( ++ | -- ) numeric-primary-expression
| numeric-primary-expression [ ++ | -- ]
numeric-assignment ::= numeric-target-expression ( = | += | -= | *= | /= | %= ) numeric-expression
numeric-cast ::= numeric
Usage Notes
Table 2-5 shows the precedence order, from highest to lowest, for a numeric-expression.
Table 2-5 Expression Operator Precedence
Symbols | Category | Description |
---|---|---|
|
Post-increment or Post-decrement |
numeric-primary-expression [ ++ | -- ] |
|
Pre-increment or Pre-decrement |
( ++ | -- ) numeric-primary-expression |
- + |
Unary minus or Unary plus |
( + | - ) numeric-expression |
(type) |
Type cast |
( numeric cast ) numeric-expression |
|
Exponentiation |
|
|
Multiply or Divide or Remainder |
numeric-expression ( * | / | % ) numeric-expression |
|
Addition or Subtraction |
numeric-expression( + | - ) numeric-expression |
Conditional |
boolean-expression ? numeric-expression : numeric-expression |
|
= |
Assignment Operators |
numeric-target-expression ( = | += | -= | *= | /= | %= ) numeric-expression |
As in Java, any expression can be converted to a string using the concatenation +
operator. In RL Language, unlike Java, when an array is converted to a string, the array contents are converted to a string, with array elements separated by commas and surrounded with curly braces. When an instance of an RL Language class is converted to a string, the class name appears followed by property value pairs separated by commas and surrounded with parentheses. This RL Language feature is useful for logging, tracing, and debugging.
When +
operator is applied to an operand that is a String
, then all operands are converted to Strings
and the operands are concatenated.
Format
string-expression ::= string-assignment
| boolean-expression ? string-expression : string-expression
| string-expression + expression
| expression + string-expression
|
string-assignment ::= string-target-expression ( = | += ) string-expression
Example
Example 2-27 shows use of a string expression in RL Language. The example prints "1 2.0 true {1,2}"
Example 2-27 RL String Expression
int i = 1; double f = 2.0; boolean b = true; int[] v = new int[]{i, 2}; println(i + " " + f + " " + b + " " + v);
RL Language arrays behave just like Java arrays, but are limited to one dimension. The base type of an array is the type of the members of the array. All members must be of the same type. An array element may contain an array but only if the containing array is of type Object[]
.
Note: RL Language does not directly support multi-dimensional arrays. |
Format
array-expression ::= array-assignment
| boolean-expression ? array-expression : array-expression
| ( array-cast ) ( array-expression | object-expression )
array-assignment ::= array-target-expression = array-expression
array-cast ::= type
Usage Notes
The type of an array-cast must be an array type.
A fact-set-expression matches, filters, and returns facts from working memory. A fact-set-expression is legal only in a rule fact-set-condition. The if
keyword indicates a fact-set-condition; however, a fact-set-condition is different from an if action. A rule's fact-set-condition iterates through all the rows in a fact set that match the fact-set-condition. The if action tests a boolean expression.
Format
fact-set-condition ::= if fact-set-expression
fact-set-expression ::= fact-set-expression || fact-set-expression
| fact-set-expression && fact-set-expression
| fact-set-expression && boolean-expression
| exists fact-set-expression
fact-set-pattern ::= fact [ ( property-pattern ( , property-pattern )* ) ]
[ var ] local-object-variable
local-object-variable ::= identifier
property-pattern ::= property-name : field-pattern
field-pattern ::= var local-property-variable | constraint
local-property-variable ::= identifier
simple-expression ::= string literal
| numeric literal
constraint ::= simple-expression
property-name ::= name
aggregate ::= aggregate fact-set-expression : aggregate-spec ( , aggregate-spec )*
aggregate-spec ::= aggregate-function [ var ] identifier
average ( numeric-expression )
| sum ( numeric-expression )
| minimum ( comparable-expression )
| maximum ( comparable-expression )
| count ()
| collection ( object-expression )
| user-defined ( expression type Tin )
user-defined ::= qname
Usage Notes
A fact-set-expression can limit the facts it returns using either a simple-expression as a constraint in a fact-set-pattern or using a supported operator with the fact-set-expression.
A fact-set-expression may not contain any of the following:
Operator precedence is as in Java. Use parentheses to force desired precedence. For example,
fact person var p && (p.age < 21 || p.age > 65)
Without the parentheses, the p
in p.age
is undefined (see Table 2-5 for more details on operator precedence).
A local-object-variable or local-property-variable is in scope for all expressions following the pattern that are following the pattern and connected with the &&
operator. If the pattern is not contained in an exists
, ||
, or !
expression, the variable is also in scope in the rule's action-block. The &&
'ed expressions may filter the returned facts, so that only the facts surviving the filter are returned.
Fact Set Pattern - Fetch From Working Memory
The most primitive fact-set-expression is the fact-set-pattern that returns some or all facts of the given class that have been asserted into working memory. A fact-set-pattern searches working memory for facts of the given class and with the optional constraint on the property values. The returned fact set contains a row for each matching fact. A local row variable can be defined to refer to each row, or local field variables can be defined to refer to fields within a row. If no local row variable is supplied, the name part of the class qname can be used to refer to each row (see Example 2-31).
Join Operator
The &&
operator defines the cross product or join of two fact-set-expression operands. The left-hand-side of a fact-set-expression &&
operator must be a fact set. The right-hand-side of a join operator is another fact-set-expression. The result of applying the &&
operator to two fact sets is the joined fact set.
Filter Operator
The &&
operator defines a filter operator that rejects facts in its left-hand-side fact-set-expression that do not match the right-hand-side boolean-expression. The left-hand-side of filter must be a fact-set-expression. The right-hand-side of a filter is a boolean-expression.
A filter right-hand-side may include references to variables defined, using the var
keyword, in the left-hand-side.
Union Operator
The ||
operator defines the union of two fact-set-expression operands. When the||
operator is applied to fact-set-expressions, the following is true:
The expression's var
s cannot be referenced outside the containing expression.
The||
returns the concatenation of its input fact sets, but the contents of the produced fact set are not accessible. Thus, ||
is typically used in a !
or exists
expression. Rather than a top-level ||
in a condition, it is usually better to use two or more rules with top-level &&
operators so that var
s defined in the condition can be referenced in the action-block.
Note: In the following construction:if (fact X || fact W) {} If both an |
Empty Operator
The !
operator tests if the fact-set-expression is empty. When the !
is applied to the fact-set-expression, the following is true:
The expression's var
s cannot be referenced outside the containing !
expression.
The !
operator returns a single row if the fact-set-expression is empty, else the !
operator returns an empty fact set.
Exists (Not Empty) Operator
The exists
operator tests if the fact-set-expression is not empty.
When the exists
operator is applied to the fact-set-expression, the following is true:
The expression's var
s cannot be referenced outside the containing exists
expression.
The exists
returns a single row if the expression is not empty, else exists
returns an empty fact set.
Var Keyword
Note that when you use var
, the fact is only visible using the var
defined variable (and not using the original name). Thus, the following example works, assuming action.kind
is defined:
if (fact action) { println(action.kind); }
However, for the following example, after var a
is defined, the action.kind
reference produces a syntax error because you need to use a.kind
after the var a
definition.
if (fact action var a) { println(action.kind); }
Aggregate
Aggregates support the following functions:
Table 2-6 Aggregate Functions
Function | Description |
---|---|
|
Provides the average for matching facts. The result is |
|
Provides the sum for the matching facts. The result is |
|
The result is |
|
Provides the minimum for the matching facts. |
|
Provides the maximum for the matching facts. |
|
The result is |
user defined |
For a user-defined function the result is type Tout. |
RL Language supports the aggregate pattern that applies one or more aggregate functions to a factRowCollection
, and binds the aggregates to pattern variables. The usual SQL set of built-in aggregates is supported, and user-defined aggregates are supported when a user-supplied Java class is supplied.
If an aggregate function uses primitive wrapper types, for example Long, Double, then these will be unboxed such that the bind variable for the result has the appropriate raw primitive type.
If the fact expression in an aggregate is empty, then the rule will not fire. This ensures that if there are no matching facts for the expression, the aggregate function does not return a number that is meaningless in this context. For example, the "sum" of a property of a zero-size set is not meaningful.
For example, print the names of employees who are paid better than average:
if fact Emp emp && aggregate fact Emp(salary: var sal) : average(sal) var avgSal && emp.salary > avgSal { println(emp.name); }
Print the names of employees, who are paid better than the average of employees who make over $100,000:
if fact Emp emp && aggregate fact Emp(salary: var sal) && Emp.salary > 100000 average(sal) var avgSal && emp.salary > avgSal { println(emp.name); }
User-defined aggregates are supported by providing a public class named user-defined
with a public 0-arg constructor that implements:
public interface IncrementalAggregate<Tin, Tout> extends Serializable { public void initialize(); public void add(Tin value); public void remove(Tin value); public Tout getResult(); public boolean isValid(); }
Implementations must support the following invocation sequence:
new (initialize (add|remove)+ isValid getResult)*
isValid
should return true
when the result of the user defined aggregate is valid and false
otherwise.
Examples
Example 2-28 shows the action is placed on the agenda for all Counter
facts with a value of 1.
Example 2-28 Fact Set Expression for Counter.value
class Counter { int id; int value; } rule ex1a { if (fact Counter c && c.value == 1) { println("counter id " + c.id + " is 1"); } }
Example 2-29 shows an equivalent way to express the rule from Example 2-28, using a constraint.
Example 2-29 Using a Fact Set Constraint
rule ex1b { if (fact Counter(value: 1) c) { println("counter id " + c.id + " is 1"); } } assert(new Counter(id: 99, value: 1)); run(); // prints twice, once for each rule
Example 2-30 shows an illegal use of a fact set, because c
is used before it is defined.
Example 2-30 Illegal Use of Fact Set
rule ex2 { if (c.value == 1 && fact Counter c) { println("counter id " + c.id + " is 1"); } }
Example 2-31 shows an action is placed on the agenda for all AttFacts
with the property a2==0
and without a matching, equal first elements, Counter.
Example 2-31 Using a Fact Set with && Operator for Counter Fact
class AttFact {int a1; int a2;} rule ex3 { if (fact AttFact(a2: 0) && ! fact Counter(id: AttFact.a1)) { println(AttFact.a1); } } assert(new AttFact()); // will match because a1=a2=0 assert(new AttFact(a1: 1, a2: 0)); // will not match run(); // rule fires once
Example 2-32 shows the condition, if (fact Ca a && fact Cb(v: a.v) b)
is interpreted as follows:
The fact Ca a
returns a fact set containing a(v: 1), a(v: 2), a(v: 3)
The &&
operator returns a fact set containing the two rows {a(v: 1),b(v: 1)}, {a(v: 2),b(v: 2)}
Example 2-32 Using a Fact Set with && Operator
class Ca {int v;} assert(new Ca(v: 1)); assert(new Ca(v: 2)); assert(new Ca(v: 3)); class Cb {int v;} assert(new Cb(v: 0)); assert(new Cb(v: 1)); assert(new Cb(v: 2)); rule r { if (fact Ca a && fact Cb(v: a.v) b) { println("row: " + a + " " + b); } } run(); // prints 2 rows
Comparable expressions allow objects that implement java.lang.Comparable to be compared using the ==, !=, <, <=, >, and >= operators. This allows dates to be easily compared. Also, BigDecimal
, often used to represent money, can be compared in such expressions.
Format
qname variable of type implementing java.lang.Comparable | member of type implementing java.lang.Comparable
The only expression operators for objects are assignment and cast.
Format
object-expression ::= object-assignment | ( ob-cast ) object-expression | boolean-expression ? object-expression : object-expression
object-assignment ::= object-target-expression = object-primary-expression
ob-cast ::= object-type
Primary expressions include assignment targets such as variables, properties, array elements, class members and other tightly binding expression syntax such as literals, method and function calls, and object and fact construction. The syntax is very similar to Java except where noted.
Format
primary-expression ::= array-primary-expression
| function-call returning array
| method-call* returning 1-dim Java array
| ( array-expression )
simple-type [ numeric-expression integer ]
| numeric [ ] { numeric-expression ( , numeric-expression )* } numeric expression must be implicitly convertible to base
| boolean [ ] { boolean-expression ( , boolean-expression )* }
| object-type [ ] { object-expression ( , object-expression )* }
)
qname variable of type array
| member of type array
| array-primary-expression base type is Object [ numeric-expression int ]
string literal (see "Literals")
| object-primary-expression object is java.lang.String
string-target-expression ::= object-target-expression object is java.lang.String
numeric-primary-expression ::=
numeric literal
| function-call returning numeric
| method-call returning numeric
| array-primary-expression . length
| ( numeric-expression )
qname variable of type numeric
| member of type numeric
| array-primary-expression base type is numeric [ numeric-expression ]
boolean-primary-expression ::=
| function-call returning boolean
| method-call returning boolean
| ( boolean-expression )
boolean-literal ::= true | false
qname variable of type boolean
| member of type boolean
| array-primary-expression base type is boolean [ numeric-expression int ]
new class-definition-name ( [ expression ( , expression )* ] argument list )
| new class-definition-name ( [ property-pattern ( , property-pattern )* ] property-value pairs )
| function-call returning Java object
| method-call returning Java object
qname variable of type object
| member of type Java object
| array-primary-expression base type is object [ numeric-expression int ]
function-call ::= qname function name ( [ expression ( , expression )* ] argument list )
method-call ::= object-primary-expression . identifier method name ( [ expression ( , expression )* ] argument list )
member ::= object-primary-expression . identifier member name
Examples
Example 2-33 shows the RL Language literal syntax (which is the same as Java).
Example 2-33 Use of Literals
String s = "This is a string." int i = 23; double f = 3.14; boolean b = false;
Methods and functions can be overloaded. However, unlike Java, RL Language uses a first fit algorithm to match an actual argument list to the overloaded functions.
Example 2-34 shows an example of example of overloading
Example 2-34 Overloading
function f(int i); function f(Object o); function f(String s); // can never be called f(1); // calls first f f("a"); // calls second f, because "a" is an Object
RL Language classes do not have user-defined constructors. The default constructor initializes properties to their default values. The RL Language new
operator permits specifying some property values (this works for Java bean properties, too).
A Java bean property may have a getter but no setter. Such a property may not be modified.
Example
RL Language, unlike Java, requires action blocks and does not allow a single semicolon terminated action.
Format
action ::= action-block | if | while | for | try | synchronized | return | throw
| assign | incr-decr-expression | primary-action
action-block ::= { ( variable | action )* }
Usage Notes
An action block is any number of local variable declarations and actions. The variables are visible to subsequent variable initialization expressions and actions within the same action block.
In RL Language, unlike in Java, all local variables must be initialized when they are declared. Local variables may not be final.
To exit, you can invoke the System.exit(int) method from within an action.
Example
Using the if else action, if the test is true
, execute the first action block, and if the test is false
, execute the optional else part, which may be another if action or an action block.
RL Language, unlike Java, requires action blocks and does not allow a single semicolon terminated action.
Format
if ::= if if-test action-block [ else if | action-block ]
if-test ::= boolean-expression
Examples
Example 2-37 shows an RL Language if else action block. Example 2-38 shows that an action block is required.
Example 2-37 Sample If Else Action
String s = "b"; if (s=="a") { println("no"); } else if (s=="b") { println("yes");} else { println("no"); }
While the test is true
, execute the action block. A return, throw, or halt may exit the action block.
Format
while ::= while while-test action-block
while-test ::= boolean-expression
Usage Notes
RL Language, unlike Java, requires action blocks and does not allow single semicolon terminated action.
Examples
Example 2-39 prints "bye" twice.
RL Language, like Java, has a for loop. Using the for action block, the for-init portion executes, then while the boolean-expression is true
, first the specified action block is executed then the for-update executes. A return, throw, or halt may exit the action block.
Format
for ::= for ( for-init ; boolean-expression ; for-update ) action-block
for-init ::= variable | for-update
for-update ::= incr-decr-expression | assign | primary-expression
Usage Notes
RL Language does not allow a comma separated list of expressions in the for init
or for update clauses (Java does allow this).
Example
Example 2-41 shows RL Language code that converts an int[]
to a double[]
.
Example 2-41 For Action
int[] is = new int[]{1,2,3}; double[] fs = is; // error! double[] fs = new double[3]; for (int i = 0; i < is.length; ++i) { fs[i] = is[i]; } println(fs);
Execute the first action block. Catch exceptions thrown during executions that match the Throwable
class in a catch clause. For the first match, execute the associated catch action block. Bind the Throwable
class instance to the given identifier and make it available to the catch action block. Whether an exception is thrown in the try action block, execute the finally action block, if given.
Uncaught exceptions are printed as error messages when using the RL Language command-line and are thrown as RLExceptions
when using a RuleSession's executeRuleset
or callFunction
methods. The try
, catch
, and finally
in RL Language is like Java both in syntax and in semantics. There must be at least one catch
or finally
clause.
Format
try ::= try action-block
( catch (class-implementing-throwable identifier ) action-block )*
[ finally action-block ]
class-implementing-throwable ::= qname
Usage Notes
In order to fully understand how to catch exceptions in RL Language, one must understand how the stack frames are nested during rule execution. Rules do not call other rules the way that functions or methods may call functions or methods. Therefore, you cannot use a catch block in one rule's action block to catch exceptions in another rule's action block. Exceptions thrown during rule firing must either be handled by the firing rule's action block, or must be handled by a caller to the run, runUntilHalt, or step functions that caused the rule to fire.
Examples
Example 2-42 shows the try catch and finally actions. The output from running this example is:
exception in invoked Java method this is really bad! but at least it's over!
Example 2-42 Try Catch and Finally Action Blocks
try { throw new Exception("this is really bad!"); } catch (Exception e) { println(e.getMessage()); println(e.getCause().getMessage()); } finally { println("but at least it's over!"); }
Note that RL Language treats the explicitly thrown Exception ("this is really bad!")
as an exception from an invoked Java method, and wraps the Exception
in a JavaException
. The explicitly thrown Exception
is available as the cause of the JavaException
.
As in Java, the synchronized action is useful for synchronizing the actions of multiple threads. The synchronized action block lets you acquire the specified object's lock, then execute the action-block, then release the lock.
Format
synchronized ::= synchronized object-primary-expression action-block
Example
Example 2-43 changes the name of a Person
object, adding old names to the nicknames, and synchronizes so that a concurrent reader of the Java object who is also synchronizing will see a consistent view of the Person
(See Example 2-12 details on the Person
bean).
Example 2-43 Synchronized Action
import example.Person; // this Java bean is defined in example J1 function changeName(Person p, String first, String last) { synchronized(p) { java.util.Set s = p.getNicknames(); s.add(p.getFirstName()); s.add(p.getLastName()); p.setFirstName(first); p.setLastName(last); } assert(p); } Person person = new Person("Elmer", "Fudd", new String[]{"Wabbit Wuver"}); println(person.nicknames.toArray()); changeName(person, "Bugs", "Bunny"); println(person.nicknames.toArray());
Modify updates the named properties using the associated expressions. It also updates the associated shadow fact, if any, and causes rules whose conditions reference the updated properties and evaluate to true
to be activated. Rules whose conditions do not reference the updated properties are not activated.
The object argument to modify must be an object that has already been asserted, then the values of that object are updated and network is updated with the slot-specific semantics. The result is the object and the network are consistent.
Format
modify ::= modify (object-expression , property-update ( , property-update )* )
property-update ::= property-name : expression.
Usage Notes
It is common for a fact to have properties that are set or modified by rules. For example, a customer in an application might have a status of "", "silver", or "gold". The status may be set by rules that examine other properties of customer and related facts (such as past orders). It is also common for these computed properties to be used in further rule conditions. For example, give gold customers a 10% discount. A rule that modifies a fact and reasserts it must be careful to add an extra condition so that it does not reactive itself over and over. For example, if the following rule fires once, it will fire over and over:
if fact Customer c && c.pastYearSpend > 1000 { c.status = "gold"; assert(c); }
You can fix this looping using the following rule definition:
if fact Customer c && c.pastYearSpend > 1000 && c.status != "gold" { c.status = "gold"; assert(c); }
Example 2-44 prevents the loop but does not activate rules that are looking for gold customers
Example 2-44 Example Showing Bad Rules Programming Practice to be Avoided
if fact Customer c && c.pastYearSpend > 1000 { c.status = "gold"; }
Example 2-44 demonstrates bad rules programming practice because it changes the value of the customer object but not the value of the, shadow, customer fact. The modify action lets you modify the object and fact together. Modify also activates rules that test the modified properties but does not activate rules that test non-modified properties.
if fact Customer c && c.pastYearSpend > 1000 { modify(c, status: "gold"); }
This rule does not loop because the tested properties and modified properties are disjoint. This rule can be used in an inference to fire subsequent rules that test for status=="gold".
A second rule that illustrates infinite looping is the rule described as follows:
Give Employees earning at least $50,000 a 5% raise.
if Employee emp && emp.sal > 50000 { modify(emp, sal: sal * 1.05); }
Even using modify, this rule will self-trigger because it is testing the same property (sal
) that it is modifying, and the test is true
after modification. To avoid looping in this case, you could also add a raise
property test, as follows:
if Employee emp && emp.sal > 50000 && !emp.raise { modify(emp, sal: emp.sal * 1.05, raise: true); }
Alternatively, to avoid looping in this case you could also add a fact to handle the raise. For example:
public class RaiseGiven { Employee emp; // or possibly just an employee ID } if Employee emp && emp.sal > 500000 && !RaiseGiven(emp: emp) { modify(emp, sal: sal * 1.05); assert(new RaiseGiven(emp: emp)); }
The return action returns from the action block of a function or a rule.
A return action in a rule pops the ruleset stack, so that execution continues with the activations on the agenda that are from the ruleset that is currently at the top of the ruleset stack.
If rule execution was initiated with either the run or step functions, and a return action pops the last ruleset from the ruleset stack, then control returns to the caller of the run
or step function.
If rule execution was initiated with the runUntilHalt function, then a return action will not pop the last ruleset from the ruleset stack. The last ruleset is popped with runUntilHalt when there are not any activations left. The Oracle Rules Engine then waits for more activations to appear. When they do, it places the last ruleset on the ruleset stack before resuming ruleset firing.
Format
return ::= return [ return-value] ;
return-value ::= expression
If the function has a returns
clause, then the return-value must be specified and it must be of the type specified by the returns
clause.
Usage Notes
A return action in a rule or a function
without a returns
clause must not specify a return-value.
Throw an exception, which must be a Java object that implements java.lang.Throwable
. A thrown exception may be caught by a catch
in a try action block.
Format
throw ::= throw throwable ;
throwable ::= object-primary-expression
An assignment in RL Language, as in Java, is an expression that can appear as an action.
Format
assign ::= assignment-expression ;
assignment-expression ::= boolean-assignment
Example
Example 2-45 shows the use of the RL Language assignment expression. This prints "6 5
".
Increment and decrement in RL Language, as in Java, are expressions that can appear as actions.
Format
incr-decr ::= incr-decr-expression ;
incr-decr-expression ::= ( ++ | -- ) numeric-target-expression | numeric-target-expression ( ++ | -- )
Examples
Example 2-46 shows the use of the RL Language decrement action. This example prints "0
".
A primary action is a primary expression such as a function call, assert, or Java method call executed for its side-effects. For example, the println
function is often used as a primary action.
Format
primary-action ::= primary-expression ;
A rulegroup provides support for decision table overrides. This supports the following decision table features: the ability for one rule to override one or more other rules
Format
rulegroup ::= rulegroup rulegroup-name { rulegroup-property* ( rule | rulegroup )* }
rulegroup-name ::= identifier
rulegroup-property ::= mutex
mutex ::= mutex = boolean-literal ;
Usage Notes
A rulegroup construct is a top level construct in a ruleset. A rulegroup has an optional boolean property:
mutex: The mutex property enables mutual exclusion between rules. The common case is that the rules reside in the same rulegroup that has set mutex to true. In more complex rulegroup hierarchies, two rules mutually exclude each other if their closest common ancestor rulegroup has mutex set to true. When a rules fires, existing activations for rules which it mutually excludes are removed from the agenda preventing them from firing. Theses activations must be directly related as identified by the set of facts that resulted in the activations being placed on the agenda. This leads to the requirement that the conditions of all rules that mutually exclude each other have the same fact clauses specified in the same order. This occurs naturally for decision tables.
Example
Example 2-47 demonstrates the use of rulegroups with the mutex property. Note that r2 and r3 reference the same set of fact types in the same order in the rule condition. This is required within a mutex group. The tests in the patterns can be different. The restriction on the shape of the rule condition in a mutex group extends to its descendent groups. Thus, rules r4 and r5 also must reference the same set of fact types in the same order. Assume that one instance of A and one instance of B have been asserted and that r1, r2, r3, r4 and r5 have activations on the agenda. r3 will fire since it has a higher priority. The activation of r2 will be removed without firing since r2 is in a group with mutex=true. Since group2 is a member of group1, the activations of r4 and r5 will also be removed without firing. Rule r1 will fire. Now, assume that r2, r4, and r5 have activations on the agenda and assume that r4 fires first. The activation for r2 will be remove without firing since any rule in group2 firing mutually excludes both r2 and r3. r5 will fire. It is not mutually excluded since group2 does not have mutex=true.
Example 2-47 Ruleset with Rulegroup with Specified Fact Order of Reference
ruleset set1 { rule r1 { ... } rulegroup group1 { mutex = true; rule r2 { if fact A && fact B ... { ... }} rule r3 { priority = 2; if fact A && fact B ... { ... }} rulegroup group2 { rule r4 { if fact A && fact B ... { ... }} rule r5 { if fact A && fact B ... { ... }} } } }
This section covers the following RL Language built-in functions:
assert, assertTree, assertXPath, clearRule, clearRulesetStack, clearWatchRules, clearWatchActivations, clearWatchFacts, clearWatchFocus, clearWatchCompilations, clearWatchAll, contains, getCurrentDate, getDecisionTrace, getDecisionTraceLevel, getDecisionTraceLimit, getEffectiveDate, getFactsByType, getRulesetStack, getRuleSession, getStrategy, halt, id, object, println, popRuleset, pushRuleset, retract, reset, run, runUntilHalt, setCurrentDate, setDecisionTraceLevel, setDecisionTraceLimit, setEffectiveDate, setRulesetStack, setStrategy, showActivations, showFacts, step, watchRules, watchActivations, watchFacts, watchFocus, watchCompilations
Adds a fact to working memory or updates a fact already in working memory based on the properties of the supplied object obj. If the supplied object obj is a Java instance, then properties are Java bean properties defined by an associated BeanInfo
class or by the existence of getter and setter methods. If obj is an RL Language class instance, then the properties are the fields of the class.
Format
function assert(Object obj);
Usage Notes
The fact in working memory is a shadow of the supplied object obj, and this shadow contains a copy, clone, or reference to each property prop. If prop is a primitive type, then prop is copied to the shadow. If prop implements the Java Cloneable
interface, then a clone, shallow copy, of prop is shadowed. Otherwise, only the reference to prop is shadowed. The more a shadow can copy its object's properties, the better a rule with references to several facts can be optimized.
Note that because ==
and !=
when applied to an Object
in RL Language always invokes the Object
equals method, whether a shadow contains copies, clones, or references is transparent to the RL Language program.
Assert may affect the agenda. Rules whose conditions now return a fact set because of a new fact place activations on the agenda. Activations that test for non-existence of facts, using !
, may be removed from the agenda. Updates to facts may affect the agenda. Activations whose rule conditions no longer match the changed facts are removed from the agenda. Rules whose conditions return a fact set because of the changed facts have activations placed on the agenda.
Assert should be used to update the fact in working memory if any part of the obj's state has been updated that could possibly have an effect on a rule condition, unless the obj is a Java bean that supports registering property change listeners, and all that is changed is the value of a bean property.
Examples
Example 2-48 prints, "Pavi has highest salary 65000.0" and Example 2-49 prints, "dept 10 has no employees!".
Example 2-48 Using Assert Function in the highestSalary Rule
class Emp { String ename; double salary; } rule highestSalary { if (fact Emp hi && !(fact Emp e && e.salary > hi.salary)) { println(hi.ename + " has highest salary " + hi.salary); } } Emp e1 = new Emp(ename: "Pavi", salary: 55000.00); assert(e1); // put in working memory Emp e2 = new Emp(ename: "Fred", salary: 60000.00); assert(e2); // put in working memory e1.salary += 10000.00; // Pavi is now the highest paid assert(e1); // MUST re-assert before allowing rules to fire run();
Example 2-49 Using Assert Function in the emptyDept Rule
import java.util.*; class Dept { int deptno; List emps = new ArrayList(); } rule emptyDept { if (fact Dept d && d.emps.isEmpty()) { println("dept " + d.deptno + " has no employees!"); } } Dept d = new Dept(deptno: 10); d.emps.add(e1); assert(d); // put in working memory with 1 employee d.emps.remove(0); assert(d); // MUST re-assert before allowing rules to fire run();
See Also
assertTree, id, object, retract
The assertTree built-in function asserts object in an object tree as facts.
The assertTree built-in function supports JAXB 2.0.
Format
assertTree(Object root)
assertTree(String spec, Object root)
Usage Notes
There are two assertTree() signatures:
assertTree(Object root) is necessary with SDK2. This format traverses the object graph and asserts objects as directed by internal metadata generated by SDK2.
assertTree(String spec, Object root) is necessary when SDK2 is not involved. Similar to assertXPath, spec is a package specification enhanced to allow the specification of multiple packages separated by a colon. This format asserts objects and traverses the bean properties of an object if the object is in one of the specified packages. Typically, the package specification will be the same one used in establishing the JAXBContext.
The assertTree function does the following:
asserts objects starting with the root and every fact (object with a visible declared fact type) referenced from the root, recursively.
assert JAXBElement instances it encounters, extract the value class object it contains and continue.
See Also
The assertXPath function is deprecated. Use assertTree instead.
Add a tree of facts to working memory using the specified element as the root and an XML xpath-like expression to define the objects in the tree. The pkg is the Java package or RL Language ruleset that contains the classes of objects in the tree. All objects in the tree must be in the same package or ruleset.
In addition to asserting "element" and selected descendants, XLink facts are asserted that link parent and child objects. The classes of all objects in the tree must use the supports xpath (supports) clause of the RL class (rl-class-definition) or fact-class declaration.
Format
function assertXPath(String pkg, Object element, String xpath);
See Also
Clears the named rule from the rule session. Removes all of the rule's activations from the agenda.
Format
function clearRule(String name);
See Also
Format
function clearRulesetStack();
See Also
getRulesetStack, getStrategy, popRuleset, pushRuleset, run, setStrategy
The clearWatch functions stop printing debug information.
Format
function clearWatchRules();
function clearWatchActivations();
function clearWatchFacts();
function clearWatchFocus();
function clearWatchCompilations();
function clearWatchAll();
See Also
watchRules, watchActivations, watchFacts, watchFocus, watchCompilations
The contains()
function is similar to the contains()
method on Java Collection
but with includes the ability to handle the presence of JAXBElement in the collection.
Format
contains(Collection c, Object o) returns boolean
Usage
When contains()
encounters a JAXBElement in the collection c
, it obtains the value class from the JAXBElement and compares it to the Object o
.
See Also
The getCurrentDate function returns the date associated with the CurrentDate fact.
Format
getCurrentDate() returns Calendar
Usage Notes
The effective date and the current date are two orthogonal items. The effective date is used to determine which rules are in affect according to the start and end effective date properties. The CurrentDate fact allows reasoning on a rules engine managed fact representing the "current" date.
Setting the current date does not affect the effective date semantics.
If you want to create rules to reason on the date explicitly in the rules, then use the CurrentDate fact. If you want to assign start and or end effective dates to rules and have the rules in effect determined from a date in the data, then use setEffectiveDate()
.
See Also
setCurrentDate, getEffectiveDate, setEffectiveDate
Returns the current trace and starts a new trace.
Format
getDecisionTrace() returns DecisionTrace
Usage Notes
See Also
getDecisionTraceLevel, getDecisionTraceLevel, watchRules, watchActivations, watchFacts, watchFocus, watchCompilations
Gets the current decision trace level.
Format
getDecisionTraceLevel() returns int
Usage Notes
Supported decision trace levels include the following levels:
Off: decision tracing is disabled. This is defined as RuleSession.DECISION_TRACE_OFF
.
Production: rules fired are shown in trace. This is defined as RuleSession.DECISION_TRACE_PRODUCTION
.
Development: full decision tracing similar in detail to watchAll()
. This is defined as RuleSession.DECISION_TRACE_DEVELOPMENT
.
See Also
getDecisionTrace, getDecisionTraceLimit, watchRules, watchActivations, watchFacts, watchFocus, watchCompilations
Returns the current limit on the number of events in a trace.
Format
getDecisionTraceLimit() returns int
Usage Notes
See Also
getDecisionTrace, getDecisionTraceLevel
The getEffectiveDate function returns the current value of the effective date.
Format
getEffectiveDate() returns Calendar
Usage Notes
The effective date and the current date are two orthogonal items. The effective date is used to determine which rules are in affect according to the start and end effective date properties. The CurrentDate fact allows reasoning on a engine managed fact representing the "current" date. Both may be set explicitly.
Setting the current date does not affect the effective date semantics. Setting the effective date does not affect the CurrentDate fact.
If you want to create rules to reason on the date explicitly in the rules, then use the CurrentDate (setCurrentDate()
). If you want to assign start and or end effective dates to rules and have the rules in effect determined from a date in the data, then use setEffectiveDate()
.
See Also
setEffectiveDate, getCurrentDate, setCurrentDate
Returns a list of all facts in working memory that are instances of a specified class.
Format
function getFactsByType(String className) returns List
See Also
showFacts, watchRules, watchActivations, watchFacts, watchFocus, watchCompilations
Returns the ruleset stack as an array of ruleset names.
Format
function getRulesetStack() returns String[];
Usage Notes
Returns: the ruleset stack as an array of ruleset names.
Entry 0, the top of the stack, is the focus ruleset. The focus ruleset is the ruleset whose activations are fired first by a subsequent run, runUntilHalt, or step function execution.
See Also
clearRulesetStack, getStrategy, popRuleset, pushRuleset, setRulesetStack, setStrategy
Returns a Java RuleSession
object. An RL Language program could use this RuleSession
to dynamically define new classes, rules, functions, or variables.
Format
function getRuleSession() returns RuleSession;
Example
rule learn { if (fact f1 && …) { RuleSession rs = getRuleSession(); rs.executeRuleset("rule newRule { if fact f1 && fact f2 && … { … } }"); } }
See Also
Returns the current strategy. Table 2-7 shows the possible strategy values.
Format
function getStrategy() returns String;
See Also
clearRulesetStack, getRulesetStack, popRuleset, pushRuleset, setStrategy
The halt function halts execution of the currently firing rule, and returns control to the run, runUntilHalt, or step function that caused the halted rule to run. The agenda is left intact, so that a subsequent run, runUntilHalt, or step can be executed to resume rule firings.
The halt function has no effect if it is invoked outside the context of a run, runUntilHalt, or step function.
Format
function halt();
See Also
reset, run, runUntilHalt, step
Return the fact id associated with the object obj. If obj is not associated with a fact, returns -1.
Format
function id(Object obj) returns int;
See Also
Return the object associated with the given fact id. If there is no such fact id, returns null.
Format
function object(int factId) returns Object;
See Also
Print the given value to the RuleSession output writer.
Format
function println(char c);
function println(char[] ca);
function println(int i);
function println(long l);
function println(float f);
function println(double d);
function println(boolean b);
function println(Object obj);
If the stack is empty, popRuleset
throws RLRuntimeException
. If the stack is not empty, popRuleset
pops the focus off the stack and returns it.
All entries are shifted down one position, and the new focus is the new top of stack, entry 0.
Entry 0, the top of the stack, is the focus ruleset. The focus ruleset is the ruleset whose activations are fired first by a subsequent run, runUntilHalt, or step function execution.
Format
function popRuleset() returns String;
Example 2-50 Using popRuleset and Throwing RLRuntimeException
clearRulesetStack(); popRuleset(); // RLRuntimeException
See Also
clearRulesetStack, getRulesetStack, getStrategy, pushRuleset, setStrategy
Push the given ruleset onto the stack and make it the focus. It is an error to push a ruleset that is already the focus (RLIllegalArgumentException
is thrown for this error).
Entry 0, the top of the stack, is the focus ruleset. The focus ruleset is the ruleset whose activations are fired first by a subsequent run, runUntilHalt, or step function execution.
Format
function pushRuleset(String focus);
Examples
Example 2-51 shows the RL Language using the pushRuleset
function. Example 2-52 shows the RL Language using the popRuleset
function.
Example 2-51 Using pushRuleset - Throws RLIllegalArgumentException
clearRulesetStack(); pushRuleset("main"); // focus is "main" pushRuleset("main"); // RLIllegalArgumentException
Example 2-52 Using popRuleset - Throws RLRuntimeException
clearRulesetStack(); popRuleset(); // RLRuntimeException
See Also
clearRulesetStack, getRulesetStack, getStrategy, popRuleset, setStrategy
Remove the fact associated with the object obj from working memory.
Format
function retract(Object obj);
Usage Notes
Retract may affect the agenda. Activations that depend on the retracted fact are removed from the agenda.
Note, rules that have conditions that test for non-existence of facts (using !
) may place new activations on the agenda.
See Also
Clears all facts from working memory, clears all activations from the agenda, and reevaluates non-final global variable initialization expressions.
Format
function reset();
See Also
halt, run, runUntilHalt, step
Fire rule activations on the agenda until:
A rule action calls halt directly or indirectly. For example, when halt is called by a function called by a rule action.
The agenda is empty.
The ruleset stack is empty.
Format
function run() returns int;
function run(String rulesetName) returns int;
Usage Notes
If the argument, rulesetName is supplied, the named ruleset is pushed on the top of the ruleset stack before firing any rules.
If a null rulesetName is supplied, the ruleset stack is not modified before firing rules.
If no rulesetName is supplied and the default main
ruleset is not on the ruleset stack, then the main
ruleset is placed at the bottom of the ruleset stack before firing any rules.
Returns: int
, the number of rules fired.
See Also
halt, reset, runUntilHalt, step
This function fires rule activations until halt is called. Unlike run and step, runUntilHalt does not return when the agenda is empty. Also, runUntilHalt does not pop the bottommost ruleset name from the ruleset stack. Instead, it waits for the agenda to contain activations.
Format
function runUntilHalt() returns int;
Usage Notes
The only way for activations to be added to the agenda while the main RuleSession thread is busy executing runUntilHalt is for a second thread to either:
Modify Java bean facts with PropertyChangeListeners
.
Execute assert or retract
functions.
Rules must be designed carefully when using runUntilHalt. For example, a rule that attempts to find a fact with the minimum value of a property will fire when the first instance of the fact is asserted, and then every time another instance is asserted with a lower valued property.
See Also
The setCurrentDate
function sets the date for reasoning on an engine managed fact representing the "current" date (with the CurrentDate
fact).
Format
setCurrentDate(Calendar newDate)
Usage Notes
The RLIllegalArgumentException
exception is thrown if the newDate argument is null.
If you need to reason on the date explicitly in the rules, then use the CurrentDate
fact. If you want to assign start and end effective dates to rules and have the rules in effect determined from a date in the data, then they should use setEffectiveDate. The setEffectiveDate function does not affect the CurrentDate
fact.
By default the value of the current date is managed implicitly by the rules engine. The value of the CurrentDate
fact is updated to the current system date and (re)asserted internally when a run family of built-in functions is invoked. This is done before any rules fire so that the new current date is evaluated in rule conditions. In the case of runUntilHalt, this update occurs each time there is a transition from 0 rules on the agenda to > 0 rules on the agenda.
After the user invokes the setCurrentDate
function, it becomes the responsibility of the user to update the current date as required. The rules engine no longer manages it implicitly. This remains in effect until the reset function is invoked. After the current date is set explicitly with setCurrentDate
, any invocation of setCurrentDate
function that would result in time going backward, set to an earlier point in time, is an error and an RLIllegalArgumentException
is thrown. After the reset function is invoked, the current date may be set to any value.
See Also
getCurrentDate, getEffectiveDate, setEffectiveDate
Sets the decision trace level to the specified level.
Format
setDecisionTraceLevel(int level)
Usage Notes
Supported decision trace levels include the following levels:
Off: decision tracing is disabled. This is defined as RuleSession.DECISION_TRACE_OFF
.
Production: rules fired are shown in trace. This is defined as RuleSession.DECISION_TRACE_PRODUCTION
.
Development: full decision tracing similar in detail to watchAll()
. This is defined as RuleSession.DECISION_TRACE_DEVELOPMENT
.
See Also
getDecisionTrace, getDecisionTraceLevel, getDecisionTraceLevel, setDecisionTraceLimit, watchRules, watchActivations, watchFacts, watchFocus, watchCompilations
Sets the limit on the number of events in a trace.
Format
setDecisionTraceLimit(int count)
Usage Notes
The default value is 10000.
See Also
getDecisionTrace, getDecisionTraceLevel, getDecisionTraceLevel, setDecisionTraceLevel
The setEffectiveDate function updates the effective date in the rules engine.
By default, the value of the effective date is managed implicitly by the rules engine. In this case, when a run family of built-in functions is invoked the effective date is updated to the current system date. This is done before any rules fire so that the new effective date is applied before rules begin to fire. In the case of runUntilHalt
, this update occurs each time there is a transition from 0 rule activations on the agenda to > 0 rule activations on the agenda.
Format
setEffectiveDate(Calendar newDate)
Usage Notes
Invoking setEffectiveDate is the only way that you can alter the effective date. After the reset function is invoked, the effective date may be set to any value.
The RLIllegalArgumentException
exception is thrown if the newDate argument is null.
After you invoke the setEffectiveDate function, it becomes the responsibility of the application to update the effective date as required. The rules engine no longer manages it implicitly.
This remains in effect until the reset function is invoked.
This is useful for debugging, performing rule evaluation at a "point in time", or other use cases that require application control of the effective date.
See Also
getEffectiveDate, getCurrentDate, setCurrentDate
Sets the ruleset stack to the given array of ruleset names.
Entry 0, the top of the stack, is the focus ruleset, which is the ruleset whose activations will be fired first by a subsequent run, runUntilHalt, or step function execution.
Format
function setRulesetStack(String[] rulesetStack
See Also
clearRulesetStack, getRulesetStack, getStrategy, popRuleset, pushRuleset, setStrategy
Strategy specifies the order in which activations from the same ruleset and with the same priority are executed. Table 2-7 shows the valid strategy values.
Table 2-7 Strategy Values for setStrategy and getStrategy Functions
Strategy | Description |
---|---|
queue |
Activations are fired in order from oldest to newest. |
stack |
Activations are fired in order from newest to oldest. |
Format
function setStrategy(String strategy);
See Also
clearRulesetStack, getRulesetStack, getStrategy, popRuleset, pushRuleset
The show functions print rule session state to the output Writer. State that can be shown is: Activations all activations on the agenda
Format
function showActivations();
See Also
clearWatchRules, clearWatchActivations, clearWatchFacts, clearWatchFocus, clearWatchCompilations, clearWatchAll, showFacts, watchRules, watchActivations, watchFacts, watchFocus, watchCompilations
The show functions print rule session state to the output Writer. State that can be shown is: all facts in working memory.
Format
function showFacts();
See Also
clearWatchRules, clearWatchActivations, clearWatchFacts, clearWatchFocus, clearWatchCompilations, clearWatchAll, showActivations, watchRules, watchActivations, watchFacts, watchFocus, watchCompilations
Fire rule activations on the agenda until:
The specified number of rule activations, numRulesToFire have been fired.
A rule action calls halt directly or indirectly. For example, by a function called by a rule action.
The agenda is empty.
The ruleset stack is empty.
Format
function step(int numRulesToFire) returns int;
function step(int numRulesToFire, String rulesetName) returns int;
Usage Notes
If no ruleset name is supplied and the main
ruleset is not on the ruleset stack, then the main
ruleset is placed at the bottom of the ruleset stack before firing any rules.
If a ruleset named, rulesetName, is supplied, the specified ruleset is pushed on the top of the ruleset stack before firing any rules. If a null ruleset name is supplied, the ruleset stack is not modified before firing rules.
Returns the integer number of rules fired.
See Also
halt, reset, run, runUntilHalt
The watch functions turn on printing of information about important rule session events. The information is printed to the output Writer whenever the events occur. Use a clearWatch function to turn off printing.
Table 2-8 describes the available debugging information.
Table 2-8 Watch Functions Event Descriptions
Debug Watch | Rule Session Event Description |
---|---|
watch |
Rule session event description |
Rules |
Information about rule firings (execution of activations) |
Activations |
Addition or removal of activations from the agenda |
Facts |
Assertion, retraction, or modification of facts in working memory |
Focus |
Pushing or popping of the ruleset stack. The top of the ruleset stack is called the focus ruleset, and all activations on the agenda from the focus ruleset will be fired before the focus is popped and the next ruleset on the stack becomes the focus. |
Compilations |
When a rule's conditions are added to the rete network, information about how the condition parts are shared with existing rules is printed. "=" indicates sharing. The order that rules are defined can affect sharing and thus can affect performance. |
All |
Includes information shown with watch Rules, watch Activations, watch Facts, watch Compilations and watch Focus. |
Format
function watchRules();
function watchActivations();
function watchFacts();
function watchFocus();
function watchCompilations();
function watchAll();
See Also
clearWatchRules, clearWatchActivations, clearWatchFacts, clearWatchFocus, clearWatchCompilations, clearWatchAll, showActivations, showFacts