Show Table of Contents
8.10. Rule Attributes
Table 8.5. Rule Attributes
| Attribute Name | Default Value | Type | Description |
|---|---|---|---|
|
no-loop
|
false
|
Boolean
|
When a rule's consequence modifies a fact it may cause the rule to activate again, causing an infinite loop. Setting no-loop to true will skip the creation of another Activation for the rule with the current set of facts.
|
|
ruleflow-group
|
N/A
|
String
|
Ruleflow is a Drools feature that lets you exercise control over the firing of rules. Rules that are assembled by the same ruleflow-group identifier fire only when their group is active.
|
|
lock-on-active
|
false
|
Boolean
|
Whenever a ruleflow-group becomes active or an agenda-group receives the focus, any rule within that group that has lock-on-active set to true will not be activated any more; irrespective of the origin of the update, the activation of a matching rule is discarded. This is a stronger version of no-loop, because the change could now be caused not only by the rule itself. It's ideal for calculation rules where you have a number of rules that modify a fact and you don't want any rule re-matching and firing again. Only when the ruleflow-group is no longer active or the agenda-group loses the focus those rules with lock-on-active set to true become eligible again for their activations to be placed onto the agenda.
|
|
salience
|
0
|
Integer
|
Each rule has an integer salience attribute which defaults to zero and can be negative or positive. Salience is a form of priority where rules with higher salience values are given higher priority when ordered in the Activation queue.
|
|
agenda-group
|
MAIN
|
String
|
Agenda groups allow the user to partition the Agenda providing more execution control. Only rules in the agenda group that has acquired the focus are allowed to fire.
|
|
auto-focus
|
false
|
Boolean
|
When a rule is activated where the auto-focus value is true and the rule's agenda group does not have focus yet, then it is given focus, allowing the rule to potentially fire.
|
|
activation-group
|
N/A
|
String
|
Rules that belong to the same activation-group, identified by this attribute's string value, will only fire exclusively. In other words, the first rule in an activation-group to fire will cancel the other rules' activations, i.e., stop them from firing.
|
|
dialect
|
As specified by the package
|
String
|
The dialect species the language to be used for any code expressions in the LHS or the RHS code block. Currently two dialects are available, Java and MVEL. While the dialect can be specified at the package level, this attribute allows the package definition to be overridden for a rule.
|
|
date-effective
|
N/A
|
String, containing a date and time definition
|
A rule can only activate if the current date and time is after date-effective attribute.
|
|
date-expires
|
N/A
|
String, containing a date and time definition
|
A rule cannot activate if the current date and time is after the date-expires attribute.
|
|
duration
|
no default value
|
long
|
The duration dictates that the rule will fire after a specified duration, if it is still true.
|
8.10.1. Rule Attribute Example
This is an example for using a rule attribute:
rule "my rule"
salience 42
agenda-group "number-1"
when ...8.10.2. Timer Attribute Example
This is what the
timer attribute looks like:
timer ( int: <initial delay> <repeat interval>? ) timer ( int: 30s ) timer ( int: 30s 5m ) timer ( cron: <cron expression> ) timer ( cron:* 0/15 * * * ? )
8.10.3. Timers
The following timers are available in JBoss BRMS:
- Interval
- Interval (indicated by "int:") timers follow the semantics of
java.util.Timerobjects, with an initial delay and an optional repeat interval. - Cron
- Cron (indicated by "cron:") timers follow standard Unix cron expressions.
A rule controlled by a timer becomes active when it matches, and once for each individual match. Its consequence is executed repeatedly, according to the timer's settings. This stops as soon as the condition doesn't match any more.
Consequences are executed even after control returns from a call to fireUntilHalt. Moreover, the Engine remains reactive to any changes made to the Working Memory. For instance, removing a fact that was involved in triggering the timer rule's execution causes the repeated execution to terminate, or inserting a fact so that some rule matches will cause that rule to fire. But the Engine is not continually active, only after a rule fires, for whatever reason. Thus, reactions to an insertion done asynchronously will not happen until the next execution of a timer-controlled rule.
Disposing a session puts an end to all timer activity.
8.10.4. Cron Timer Example
This is what the Cron timer looks like:
rule "Send SMS every 15 minutes"
timer (cron:* 0/15 * * * ?)
when
$a : Alarm( on == true )
then
channels[ "sms" ].insert( new Sms( $a.mobileNumber, "The alarm is still on" );
end8.10.5. Calendars
Calendars are used to control when rules can fire. JBoss BRMS uses the Quartz calendar.
8.10.6. Quartz Calendar Example
This is what the Quartz calendar looks like:
Calendar weekDayCal = QuartzHelper.quartzCalendarAdapter(org.quartz.Calendar quartzCal)
8.10.7. Registering a Calendar
Procedure 8.8. Task
- Start a StatefulKnowledgeSession.
- Use the following code to register the calendar:
ksession.getCalendars().set( "weekday", weekDayCal );
- If you wish to utilize the calendar and a timer together, use the following code:
rule "weekdays are high priority" calendars "weekday" timer (int:0 1h) when Alarm() then send( "priority high - we have an alarm” ); end rule "weekend are low priority" calendars "weekend" timer (int:0 4h) when Alarm() then send( "priority low - we have an alarm” ); end
8.10.8. Left Hand Side
The Left Hand Side (LHS) is a common name for the conditional part of the rule. It consists of zero or more Conditional Elements. If the LHS is empty, it will be considered as a condition element that is always true and it will be activated once, when a new WorkingMemory session is created.
8.10.9. Conditional Elements
Conditional elements work on one or more patterns. The most common conditional element is
and. It is implicit when you have multiple patterns in the LHS of a rule that is not connected in any way.
8.10.10. Rule Without a Conditional Element Example
This is what a rule without a conditional element looks like:
rule "no CEs"
when
// empty
then
... // actions (executed once)
end
// The above rule is internally rewritten as:
rule "eval(true)"
when
eval( true )
then
... // actions (executed once)
end
Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.