All rules and Decision Tables are created in a ruleset. A ruleset organizes rules and Decision Tables into a unit of execution.

To create a rule set:

Effective date support provides the ability to specify a start date and an end date for a ruleset, a rule or a Decision Table. For a ruleset the effective date defines the date range in which the rules and Decision Tables within the ruleset are effective. For more information on effective dates, see Using Date Facts_ Date Functions_ and Specifying Effective Dates.

To set the effective date for a ruleset:

You can specify an effective start date and or an effective end date for a ruleset, a rule, or a Decision Table. For information on specifying the effective date for a ruleset, see How to Set the Effective Date for a Rule Set.

You can specify an effective start date and or an effective end date for a rule.

To set the effective date for a rule:

As the number of rules in a ruleset increases, it can be difficult to navigate the list of rules. You can instruct Rules Designer to filter the list of rules, to display only rules of interest. For example, you can display only active rules or only rules that have validation warnings.

For more information on creating rules, see Working with Rules.

To use a filter to display matching rules in a ruleset:

1. In Rules Designer, select a ruleset from the Rulesets navigation tab.

2. To show the rule filter settings, next to the ruleset name, click Show Filter Query as Figure 4-3 shows.

   Figure 4-3 Showing or Hiding a Filter Query in a Rule Set

   
   Description of "Figure 4-3 Showing or Hiding a Filter Query in a Rule Set"

3. In the Filter Query field, click <insert test> to insert a default test.

4. Configure the default test.

   In this case, as shown in Figure 4-4, when you click an <operand> you can choose from the rule-specific options shown in Table 4-1.

   Table 4-1 Rule Filter Query Operands

   Operand	Description
   name	Matches against the rule name.
   description	Matches against the rule description.
   priority	Matches against the rule priority. For more information, see How to Set a Priority for a Rule.
   start date	Matches against the rule start date. For more information, see What You Need to Know About Effective Dates.
   end date	Matches against the rule end date. For more information, see What You Need to Know About Effective Dates.
   minutes until start date	Matches against a specified number of minutes until the rule start date. For more information, see What You Need to Know About Effective Dates.
   minutes until end date	Matches against a specified number of minutes until the rule end date. For more information, see What You Need to Know About Effective Dates.
   days until start date	Matches against a specified number of days until the rule start date. For more information, see What You Need to Know About Effective Dates
   days until end date	Matches against a specified number of days until the rule end date. For more information, see What You Need to Know About Effective Dates
   years until start date	Matches against a specified number of years until the rule start date. For more information, see What You Need to Know About Effective Dates
   years until end date	Matches against a specified number of years until the rule end date. For more information, see What You Need to Know About Effective Dates
   is active	Matches against whether the rule is active. For more information, see How to Select the Active Option.
   is valid	Matches against whether the rule has validation warnings. For more information, see Understanding Rule Validation.
   referenced fact types	Matches against one or more fact types.

   Figure 4-4 Filter Query Operands

   
   Description of "Figure 4-4 Filter Query Operands"

   For more information, see How to Define a Test in a Verbal Rule.

5. Select the operator to choose an operator for the comparison. For example, for the name you can select contains from the operand list.

6. Enter a comparison operand for the right-hand-side of the filter test. For example, enter the string Policy.

7. When the filter query is complete you can apply the filter to the rules in the ruleset:

   1. To apply the filter, select the Filter On check box.

      Rules Designer displays only the rules that match the filter query as Figure 4-5 shows.

      Figure 4-5 Enable Filter Query in a Rule Set

      
      Description of "Figure 4-5 Enable Filter Query in a Rule Set"

   2. To disable the filter query, clear the Filter On check box.

      Rules Designer displays all the rules in the ruleset.

   3. To delete the filter query, select it and press Delete or click Clear Filter.

To create a general rule, first add the rule to a ruleset, and then insert tests and actions. Actions are associated with pattern matches. At runtime, when a test in the IF area of a rule matches, the Rules Engine activates the THEN action and prepares to run the actions associated with the rule.

By default, Rules Designer creates rules which fire for each matching fact. Select Advanced Mode to enable other options, such as a rule in which the same fact type matches more than once, or never. For more information on advanced mode and showing advanced settings, see Using Advanced Settings with Rules and Decision Tables.

To add a general rule to a ruleset:

Verbal rules are created and executed in a similar fashion to general rules. However, there are some differences.

To create a verbal rule, first add the rule to a ruleset, and then insert tests and actions. As you define a verbal rule, you add business phrases which can either be automatically derived by the system, or defined by you. You can define business phrases before writing a rule, or after.

Verbal rules do not support Advanced Mode or Tree Mode.

To add a verbal rule to a ruleset:

To create a test in a rule you add conditions for facts. For example, with a sample CustomerOrder fact with an annual spending property, you can add a test to determine if a customer order is associated with a high value of spending, based on the annual spending for the customer. Note that you can use value sets to limit the values for tests and actions in rules. For more information, see Using Value Sets as Constraints for Options Values in Rules.

Figure 4-9 shows this sample rule.

Figure 4-9 Adding a Test to a Rule

Description of "Figure 4-9 Adding a Test to a Rule"

At runtime, when this rule is processed the Rules Engine checks the facts against rule pattern tests that you define to find matching facts. For this sample rule, Rule_1, when a fact matches the Rules Engine modifies the fact and then modifies the value property to "High."

To define tests in rules:

1. In Rules Designer, click + from the Rule Sets tab, add or select the rule you want to use, for example, select Rule_1.

2. The IF area of the rule includes a left-hand-side <operand> and a right-hand-side <operand>, as shown in Figure 4-14.

   Figure 4-10 Rule Test with Left-hand-side operand and Right-hand-side operand

   
   Description of "Figure 4-10 Rule Test with Left-hand-side operand and Right-hand-side operand"

3. In the rule, click <insert test> and choose simple test, for example.

4. In a test, you replace the left-hand-side operand with a value.

   To do this, select the left-hand-side <operand>. This displays a text entry area and a list, as shown in Figure 4-15:

   Figure 4-11 Configuring the Left-hand-side Operand of a Test in a Rule

   
   Description of "Figure 4-11 Configuring the Left-hand-side Operand of a Test in a Rule"

   1. To enter a value use the list to select an item from the value options.

      You can view the options using a single list, by selecting List View, or using a navigator by selecting Tree View.

   2. To enter a literal value, type the value into the text entry area and press Enter.

      The value you enter must agree with the type of the corresponding operand. For example, in the test IF CustomerOrder.annualSpending > <operand>, valid values for <operand> must agree with the type of CustomerOrder field annualSpending.

5. In a test, you replace the operator with the desired logical operator or accept the default (==). To do this, select the default == operator. This displays a field and a list. The list may contain additional operators, depending on the datatype of the left operand. For example, to test strings, if you select a String operand on the left hand side, then additional String operators, such as startsWith and equalsIgnoreCase are available as shown in Figure 4-16.

   Figure 4-12 Configuring String Operators in a Rule

   
   Description of "Figure 4-12 Configuring String Operators in a Rule"

   Similarly, to test a logical condition between the left-hand and right-hand operands, select one of the logical operators: == (equality), != (not equal), > (greater than), >= (greater than or equal to), < (less than), <= (less than or equal to). For more information on the operators, see Oracle Business Rules Built-in Classes and Functions.

6. In a test, you replace the right-hand-side operand with a value.

   Configure the <operand> placeholder as you would for any operand.

   For example, enter >25 into the text entry area and press Enter or Return, as shown in Figure 4-13.

   Figure 4-13 Configuring the Right-hand-side Operand of a Test in a Rule

   
   Description of "Figure 4-13 Configuring the Right-hand-side Operand of a Test in a Rule"

To create a test in a verbal rule you select a derived or user-defined business phrase, or write a new user-defined business phrase, for which you supply details later.

As you enter text in a verbal rule test, the Rules Editor displays a drop down list of related business phrases.

To define tests in verbal rules:

Oracle Business Rules test variables provide a way to shorten lengthy expressions that occur in rule and decision table conditions and actions. The variable and its value can be represented as an inline business term definition. The test variables are also called as inline aliases.

The option to insert test variables appears as a list next to <insert test> in the rules condition section. As part of the definition of rule condition, you can define a variable to represent a complex expression, a mathematical expression, or callouts to functions.

For example you have an XML fact called Song that has an attribute as composer having a function called size. When referring to the attribute, instead of using Song.composer.size() every time, you can just define a variable as the following:

lo = Song.composer.size()

Subsequently, in tests, you can use lo as part of your expressions. The expression can be anything from a simple to a complex expression. For example, in the body of a function, if you click <insert action>, you can see expression as a part of the available options.

Figure 4-17 displays a test variable.

Figure 4-17 Rules Test Variable

Description of "Figure 4-17 Rules Test Variable"

Once you define an inline alias, for subsequent test conditions, the inline alias is available in the list of the operands. The scope of an inline alias is restricted to the subsequent tests in a particular rule, in which the inline alias is defined. In case of a nested test, you can still use the inline alias, because the nested test is a part of the base test where you have defined the alias. This is true even for any test that you define even within the nested test. The scope of the inline alias is not just restricted to the test conditions of the base and its nested test, but also to the actions of that rule. If the inline alias is defined as a part of a nested test condition and not as a part of the main test condition, even then the alias will be available to all the subsequent test conditions and actions within or outside the main nested test.

However, if you define an inline alias inside a not nested test, then the scope of the inline alias is restricted only to the subsequent tests inside the not nested test and not to any tests that are outside the not nested test.

The inline aliases can be used both in If-Then rules as well as Decision Tables. In a Decision Table, in Advanced Mode, you can show or hide patterns as well as enter a pattern by clicking <insert pattern>. After you insert a pattern, you can insert tests. In normal mode, you can show or hide tests as well as enter a test by clicking <insert test>.

To create a range test in a rule, you add conditions for facts. For example, with a sample CustomerOrder fact with an annual spending property, you can add a test to determine if the value of a customer order falls between an upper and lower range.

The following summarizes this sample rule:

IF  
     CustomerOrder.annualSpending between 100 and 2000
THEN
     Modify CustomerOrder.value = "Normal"

At runtime, when this rule is processed the Rules Engine checks the facts against rule pattern tests that you define to find matching facts.

To define range tests in rules:

1. In Rules Designer, select a ruleset from the Rulesets navigation tab.

2. In the View field, select IF/THEN Rules (this is the Rules Designer default).

3. Add or select the rule you want to use, for example, select Rule_1.

4. In Rule_1, in the IF area, select <insert test>.

5. The test in the IF area of a rule includes a left-hand side <operand> and a right-hand-side <operand>.

6. In a range test, you replace the left-hand-side operand with a value.

   To do this, select the left-hand-side <operand>. This displays a text entry area and a list, as shown in Figure 4-18:

   Figure 4-18 Adding a Test Left hand-side Operand to a Rule

   
   Description of "Figure 4-18 Adding a Test Left hand-side Operand to a Rule"

   1. To enter a value, use the list to select an item from the value options.

      You can view the options using a single list, by selecting List View, or using a navigator by selecting Tree View.

   2. To enter a literal value, type the value into the text entry area and press Enter. The value you enter must agree with the type of the corresponding operand.

      For example, in the test IF CustomerOrder.annualSpending > <operand>, valid values for <operand> must agree with the type of CustomerOrder field annualSpending.

7. In a range test, you choose the between operator. To do this, select the default == operator. This displays a text entry area and a list. Select between as shown in Figure 4-19.

   Figure 4-19 Configuring the Operator of a Range Test in a Rule

   
   Description of "Figure 4-19 Configuring the Operator of a Range Test in a Rule"

   This adds two more <operand> placeholders.

8. Configure the <operand> placeholders as you would for any operand.

   For this example, the test is true when the left-most operand (CustomerOrder.annualSpending) is between the values 100 and 2000.

To create a set test in a rule, you add conditions for facts. For example, with a sample CustomerOrder fact with a line item property you can add a test to determine if the line item belongs to an arbitrary set of products.

The following summarizes this sample rule:

IF  
     CustomerOrder.lineItem.sku in 12345, 43255, 76348
THEN
     Modify CustomerOrder.value = "High"

At runtime, when this rule is processed the Rules Engine checks the facts against rule pattern tests that you define to find matching facts.

To define set tests in rules:

1. In Rules Designer, select a ruleset from the Rulesets navigation tab.

2. In the View field, select IF/THEN Rules (this is the Rules Designer default).

3. Add or select the rule you want to use, for example select Rule_1.

4. In Rule_1, in the IF area select <insert test>.

5. The test in the IF area of a rule includes a left-hand side <operand> and a right-hand-side <operand>.

6. In a set test, you replace the left-hand-side operand with a value.

   To do this, select the left-hand-side <operand>. This displays a text entry area and a list as shown in Figure 4-20:

   Figure 4-20 Adding a Test Left-hand-side Operand to a Rule

   
   Description of "Figure 4-20 Adding a Test Left-hand-side Operand to a Rule"

   1. To enter a value use the list to select an item from the value options.

      You can view the options using a single list, by selecting List View, or using a navigator by selecting Tree View.

   2. To enter a literal value, type the value into the text entry area and press Enter.

7. In a set test, you use the in operator. To do this, select the default == operator. This displays a text entry area and a list. Select in as shown in Figure 4-21.

   Figure 4-21 Configuring the Operator of a Set Test in a Rule

   
   Description of "Figure 4-21 Configuring the Operator of a Set Test in a Rule"

   This adds two more <operand> placeholders in a comma separated list and an <insert> placeholder as shown in Figure 4-22.

   Figure 4-22 In Operator in a Set Test

   
   Description of "Figure 4-22 In Operator in a Set Test"

   To add another operand to the list, click <insert>.

   To delete an operand from the list, right-click the operand and select Delete Test Expression.

8. Configure the <operand> placeholders as you would for any operand as shown in Figure 4-23.

   Figure 4-23 Configuring the Operands of a Set Test in a Rule

   
   Description of "Figure 4-23 Configuring the Operands of a Set Test in a Rule"

   The test is true when the value of the left-most operand (CustomerOrder.lineItem.sku) is any of 12345, 43255, or 76348.

To create a rule you insert tests and you insert actions. The actions are associated with pattern matches. When a test in the IF area of a rule matches, the Rules Engine activates the THEN action and prepares to run the actions associated with the rule.

When you add an action, you use one of the forms of actions shown in Table 4-2. For each form shown in Table 4-2 the options that Rules Designer presents are context sensitive, so the lists and the number of items you work with may be different, depending on which action you add and the choices you make while you enter the action. Table 4-2 shows the basic actions; additional actions are available with Advanced Mode. For more information on advanced mode see Using Advanced Settings with Rules and Decision Tables.

To define actions in general rules:

Like general rules, to create a verbal rule you insert tests and actions. Verbal rules tests and actions are composed primarily from business phrases.

To define actions in verbal rules:

A rule loop occurs when the value for a condition is changed by an action. Loops can occur across rules in a single rule, spread over several Decision Tables, or spread over rules and Decision Tables in the same ruleset. You need to avoid creating rule actions that modify fact properties that are used in rule conditions. At runtime, such rules could cause an infinite loop.

In most cases, writing of rules should not require a focus on performance. However, there are tips that can that help you to enhance and maximize rule performance.

For more information on Oracle Business Rules performance tuning, see Oracle Business Rules Performance Tuning in Tuning Performance.

You create business phrases in the Business Phrases Tab. You can also specify a business phrase while writing a verbal rule and then complete its definition later in the Business Phrases tab.

Use the Business Phrases tab to add, modify, and delete business phrases.

To Create a New Business Phrase

Rules Designer performs dictionary validation when you make any change to the dictionary. When Rules Designer displays a warning message, the validation log includes a message that should assist you in locating the dictionary object that caused the validation warning. For example, the following string indicates that the warning originates from the data model object named RLFact_1. In addition, the problem is in the property named test_int:

CarRental/Data Model/RLFact_1/test_int/Expression

Table 4-3 specifies the parts of the dictionary object name specified in a validation message.

For more information, see:

• Understanding Rule Validation

• Understanding Decision Table Validation

• How to Validate a Dictionary

When you click the Validate button Rules Designer displays the validation log. When you first add a rule you see validation warnings similar to those shown in Figure 4-38.

Figure 4-38 Business Rules - Log Validation Messages for a New Rule

Description of "Figure 4-38 Business Rules - Log Validation Messages for a New Rule"

The dictionary object name part of a validation message for a rule includes details that help you to identify the ruleset, the rule, and an area in the rule that is associated with the validation warning. For example, the following dictionary object specification indicates a problem:

OracleRules1/Ruleset_2/Rules_1/Pattern[1]

In validation messages, the dictionary object name for a rule uses indexes that start at 1. Thus, the first pattern is Pattern[1].

In addition to validating rules, you can also test them in Rules Designer as you are designing them. For more information, see Testing Decision Functions Using a Rules Function.

When you click the Validate button Rules Designer displays the validation log. When you first add a Decision Table you see validation warnings similar to those shown for a new rule, as in Figure 4-38.

Figure 4-39 Business Rules - Log Validation Messages for a New Decision Table

Description of "Figure 4-39 Business Rules - Log Validation Messages for a New Decision Table"

The dictionary object name part of a validation message for a Decision Table includes details that help you to identify the area of the Decision Table that is associated with the validation warning. For example, the following dictionary object specification indicates a problem in the first action row, and the first action cell of the Decision Table:

OR1/Ruleset_1/DecisionTable_1/Action[1]/Action Cell[1]

In validation messages the dictionary object name for a Decision Table object uses indexes that start at 1. For example, to indicate the first condition cell in the first row in the Conditions area, the message is as follows:

OracleRules1/Ruleset_1/DecisionTable_2/Condition[1]/Condition Cell[1]

This specification indicates the condition cell for the rule with the label R1 in the first row of the Conditions area in a Decision Table.

Rules Designer performs dictionary validation when you make any change to the dictionary.

To validate a dictionary:

In Rules Designer, next to each rule name and Decision Table name, the show or hide advanced settings button lets you show and hide advanced settings.

To show and hide advanced settings in a rule or decision table:

1. Select the ruleset where you want to show advanced settings.

2. In the View field, from the list, select either IF/THEN Rules or select a Decision Table.

3. 1. To show the advanced settings, next to the rule name click Show Advanced Settings, as shown in Figure 4-41 (there is a highlighted button shown next to the rule name).

      Figure 4-41 Show or Hide Advance Settings

      
      Description of "Figure 4-41 Show or Hide Advance Settings"

   2. To hide the advanced settings, next to the rule name click Hide Advanced Settings.

Select Advanced Mode to use Rule or Decision Table features that provide additional pattern matching options and additional actions. For more information, see Working with Advanced Mode Rules.

To select the advanced mode option:

Figure 4-42 and Figure 4-43 are examples of a rule displayed in Advanced versus Simple Mode.

The same forms look different in Advanced Mode and Simple Mode due to the presence and absence of "Patterns."

Figure 4-42 Advanced Mode Checked

Description of "Figure 4-42 Advanced Mode Checked"

Figure 4-43 shows the same rule with Advanced Mode cleared:

Figure 4-43 Advanced Mode Cleared

Description of "Figure 4-43 Advanced Mode Cleared"

Oracle Business Rules includes the ability to specify that a rule or a Decision Table is active or inactive. The active option is set independent of the effective dates and may be set without changing or removing previously specified effective dates. When Rule Active is cleared, Rules Designer does not validate the rule.

To select the active option:

A ruleset or Decision Table with the Logical option selected specifies that rules in the generated RL Language use the logical property. The logical property allows you to enable or disable logical dependence between the facts that trigger a rule and the facts asserted by a rule.

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. For more information, see Rule Definitions in the Rules Language Reference forOracle Business Process Management.

Using the ruleset and Decision Table Logical option you can enable or disable the logical property for the generated RL Language associated with the rules in the ruleset or the Decision Table. By default, the Logical option is not selected.

To select the logical option:

You can set the priority for a rule or a Decision Table. You can select from a predefined named priority list as shown in Table 4-4, or enter a positive or negative integer to specify your own priority level. Higher priority rules run before lower priority rules, within a ruleset. The default priority is medium (with the integer value 0).

To set a priority for a rule:

1. Select the rule or Decision Table where you want to set the priority.

2. Click the Show Advanced Settings button next to the rule or Decision Table name (see How to Show and Hide Advanced Settings in a Rule or Decision Table).

3. In the Priority field, specify the priority value:

   1. To specify a named priority, select a named priority from the Priority list.

   2. To specify an integer priority, click in the Priority field and enter a positive or negative integer value and press Enter.

You can specify effective dates for a ruleset, a rule, or a Decision Table.

To specify effective dates:

For more information on using effective dates, see Using Date Facts_ Date Functions_ and Specifying Effective Dates and How to Set the Effective Date for a Rule Set.

The advanced mode pattern matching options specify when a rule should fire. Table 4-5 shows the available options.

To use advanced mode pattern matching options:

The matched fact name field, pattern binding variable, in a rule or a Decision Table lets you test multiple instances of the same type in a single rule. The matched fact name lets you enter a temporary name for the matched fact to use in a test. For example, the rules shown in Figure 4-49 show the use of pattern binding variables in a rule that applies a discount on a shoe item when an order includes at least one "matching" hat item.

Figure 4-49 Rule Using a Pattern Binding Variable

Description of "Figure 4-49 Rule Using a Pattern Binding Variable"

For example, you can create the rule, as shown in Figure 4-50 to find duplicate items in a customer order. This example shows the use of matched in a rule.

Figure 4-50 Rule to Find Duplicate Items in an Order

Description of "Figure 4-50 Rule to Find Duplicate Items in an Order"

To use advanced mode matched fact naming:

Note in Figure 4-52 that the test checking:

RL.get fact ID(Order$LineItem1) > RL.get fact ID(Order$LineItem2)

Prevents a single instance of an Order$LineItem from matching both patterns that match the Order$LineItem fact type. The ">" is required so that the rule does not fire for different permutations of different instances. For more information, see How Do I Correctly Express a Self-Join?.

When you create a rule with Advanced Mode, Rules Designer presents a list with the available actions shown in Table 4-6. For each form shown in Table 4-6, the options that Rules Designer presents are context sensitive. Thus, the lists and the number of items you see when you work with the action types are context sensitive, depending on which action you add and the choices you make while you enter the action.

To use advanced mode action forms:

When you create a rule with Advanced Mode, Rules Designer supports the pattern matching aggregate option. When you write rule conditions that are based not only on one fact, but on many facts, you can use an aggregate. You use aggregate functions when the conditions have a view spanning multiple facts.

To use advanced mode aggregates:

There are some special cases to keep in mind when you work with Advanced Mode rules, including the following:

• When you work with aggregates, in actions, you do not see pattern variables. The pattern variables are only shown for action lists when you use (foreach...) patterns. Thus, you cannot see pattern variables in aggregate, "there is a case", or "there is no case patterns".

• After you select Advanced Mode the Advanced Mode stays selected and inactive (gray), as long as your rule uses advanced options such as advanced pattern matching. To clear Advanced Mode you must remove or undo the advanced mode features (sometimes it is easier to start over by creating a non-advanced mode rule and then delete the advanced mode rule).

In addition to the original four tests (shown first in Table 4-8) there are new forms:

Figure 4-60 is an example where "there is a case where" form is used:

Figure 4-60 Extended Test Example 1

Description of "Figure 4-60 Extended Test Example 1"

Figure 4-61 is an example where "there is no case where" form is used:

Figure 4-61 Extended Test Example 2

Description of "Figure 4-61 Extended Test Example 2"

For information about how to build complex rules, see Working with Rules.

Example 4-1 shows part of the XML for an instance of the PO schema. To use tree mode rules you can create a rule that tests one or more business terms and if the tests pass, one or more business terms are added or changed. Oracle Business Rules has special support to enable error-free authoring of rules on fact trees like the sample PO instance.

For example, consider creating a rule for an instance of the PO schema that states:

IF the time between the order date and the date for availability of an item is more than 30 days
THEN cancel the item

The following procedure creates the PO rule to cancel non 30-day availability items.

IF the time between the order date and the date for availability of an item is more than 30 days
THEN cancel the item

To create simple tree mode rules:

Note that in the modify statement, PO/destination/item refers to the particular item instance member.

The following procedure creates a free shipping rule that can be summarized as:

IF the total cost of "free shipping eligible" items to a given destination is greater than $40
THEN shipping of those items is free

To create advanced tree mode rules:

When you select Tree Mode and select a root fact type, the options lists show all available fact types (not just the children of the root fact type). This allows you to view all available fact types as well as the children of the root fact type. There is no option to limit the option list to only show the children of the selected root fact type.

You can use the current date fact in a rule or a Decision Table.

To use the CurrentDate fact:

By default, the Oracle Business Rules Engine implicitly manages the clock associated with the CurrentDate fact and the effective date, setting each to the value of the system date. Using the RL Language functions setCurrentDate() and setEffectiveDate() you can explicitly set the current date and the effective date. For more information, see Built-in Functions in Rules Language Reference for Oracle Business Process Management.

An effective start date is defined as the first point in time at which a rule, Decision Table, or ruleset may actively participate in rule evaluations and fire. Thus, if a rule is effective it may fire if its condition is satisfied and if the rule is not effective, it does not fire whether the condition is satisfied or not.

An effective end date is the first moment in time at which the rule, Decision Table, or ruleset no longer actively participates in rule evaluations (not effective means the rule does not fire).

The effective start and end date can be set on a Decision Table, but these dates cannot be set individually for the rules within a Decision Table.

Rules and Decision Tables also include the Rule Active option. This option is set independent of the effective dates and makes dates effective without changing or removing the specified effective date. For more information on using the Rule Active option, see How to Select the Active Option.

The precedence of the effective date, when it is defined for both a ruleset and for the rules or Decision Tables within a ruleset, is as follows (with the top precedence being 1):

1. If the ruleset Rule Active option is cleared, then RL Language is not generated for that entity.

2. If one or both of the effective date properties are selected for a ruleset, then those effective start dates and effective end dates define the range of effective dates allowable for rules or Decision Tables that are defined within the ruleset (that is, if in the ruleset the From check box, the To check box, or both check boxes are selected in the Set Effective Date dialog).

   Thus, the effective dates specified for rules or Decision Tables within a ruleset must not violate the boundaries established by the ruleset that contains the rules or Decision Tables. For example, a rule may not have an effective end date that is later than the effective end date specified for a ruleset.

3. If any individual rule or Decision Table has Rule Active cleared, then RL Language is not generated for that rule or Decision Table.

4. If the Set Effective Date dialog for a ruleset includes Time selected or this option is selected on a rule or a Decision Table in the ruleset, then all instances of rules or Decision Tables in the ruleset must have Time selected when effective dates are specified. In this case, if Both or Date is selected then Rules Designer shows a validation warning:

   RUL-05742: Calendar form incompatibility detected with forms Time and DateTime.
   If the calendar form is set to Time on a rule set or any of the rules or
   decision tables within that ruleset then the calendar form for that entire
   rule set is restricted to Time.

You can use the Duration, JavaDate, and XMLDate, OracleDate, and OracleDuration extension methods in a rule or a Decision Table. For more information, see Oracle Business Rules Built-in Classes and Functions.

To use a Duration method:

XML fact types allow XML Schema types, elements, and attributes to be used when writing rules. Elements and types defined in XML Schema can be imported into the data model and can then be used to create rules and Decision Tables, just as with Java fact types and RL Fact types. The mapping between the XML Schema definition and the XML Fact types uses the Java Architecture for XML Binding (JAXB). By default, Oracle Business Rules uses the JAXB 2.0 shipped with the Oracle Application Server. JAXB as defined in JSR-222 provides a mapping between the types, names, and conventions in an XML Schema definition and the available types, allowed names and conventions in Java. For example, an element named order-id and of type xsd:integer is mapped to a Java Bean property named orderID of type BigInteger (and xsd:int type maps to Java int).

You can use expressions in Oracle Business Rules. Expressions allow arithmetic using the operators *, +, /, %, and other supported operators on primitive numerics, for example double, int, and the numeric types Integer, Long, Short, Float, Double BigDecimal, and BigInteger that are available in the built-in dictionary.

Expressions allow casting between any two numeric types, for example, (short)((BigInteger)1 + (Long)2). The following code example shows a few additional sample expressions in actions with types and casting.

assign new double db = 3.3
assign new BigDecimal bd = 3.3  // no cast required
assign db = bd // no cast required
assign bd = (BigDecimal)db // cast is required 

The expression processor uses the XPath/Xquery rules for type promotion (XML Path Language (XPath) 2.0). For example, BigDecimal is promoted to float/double; type promotion going the other direction requires a cast, except for literals such as 3.3.

You can use a list of ranges value set as a constraint for any business term other than a function result.

For more information on using a list of values value set as a constraint, see How to Use a List of Values Value Set as a Constraint for a Fact Property.

To use a List of Ranges value set as a constraint for a fact property:

Now, if you define a rule with a test that uses the fact property you will receive a validation warning when a value is out of range. For example if you define a rule with an expression with the value -10, Rules Designer will show a validation warning.

You can use a list of values value set as a constraint for a fact property.

For more information on using a list of ranges value set as a constraint, see How to Use a List of Ranges Value Set as a Constraint for a Business Term.

To use a List of Values value set as a constraint for a fact property:

You can use LOV value sets to provide options for expressions and actions.

To use value sets to provide options for rule expressions and actions: