3 Working with Facts and Value Sets

This chapter describes the Oracle Business Rules data model element called fact types, which are the objects that rules reason on. It also covers another element called value sets that define groupings of fact property values.

The chapter includes the following sections:

3.1 Introduction to Working with Facts and Value Sets

In Rules Designer, you make business objects and their methods known to Oracle Business Rules using fact types that are part of a data model. A fact type is a type definition in the data model. A fact is an instance of that fact type and is a data structure that rules can operate on.

For example, a fact type is a collection of related properties (business terms), and a fact is therefore a collection of related data bound to the business terms. A customer fact may include not only name, but address, history, credit rating, and so forth.

You can create fact types and value sets before you create rules.

In Rules Designer you can work with the following kinds of facts:

XML Facts: XML Facts are imported from existing sources by specifying XML Schema. You can add aliases to imported XML Facts or use XML Facts with RL Facts to change the data model according to your business needs.

For more information, see Working with XML Facts.
Java Facts: Java Facts are imported from existing sources. You can add aliases to Java Facts or use them with RL Facts to target the data model to business needs. Java Facts are also used to import supporting Java classes for use with the rules or Decision Tables that you create.

For more information, see Working with Java Facts.
RL Facts: RL Facts are the only kind of facts that you can create directly and do not have an external source. All other types of Oracle Business Rules facts are imported. An RL Fact is similar to a relational database row or a JavaBean with properties. An RL Fact contains a set of named, typed properties. Property values can be primitives such as String, another structured fact, or a list. RL Facts are useful for rapid and independent development and testing of decision logic. Input data that will ultimately come from an imported fact type (for example, an XML Schema) can be modeled using RL Facts before the imported schema is available or stable. Intermediate decisions that should not be returned to the application (for example, sub-decisions that categorize a customer as GOOD or BAD). It is usually best to import the fact types that are used for the input and output data of a decision. You can use RL Facts to extend a Java application object model by providing virtual dynamic types.

For more information, see Working with RL Facts.
ADF Business Components Facts: ADF Business Components Facts allow you to use ADF Business Components as Facts in rules and in Decision Tables. By using ADF Business Components Facts you can assert view object graphs representing the business objects upon which rules should be based, and let Oracle Business Rules deal with the complexities of managing the relationships between the various related view objects in the view object graph.

For more information, see Working with ADF Business Components Facts.

You typically use Java fact types and XML fact types to create rules that examine the business objects in a rule-enabled application, or to return results to the application. You use RL Language fact type definitions to create intermediate facts that can trigger other rules in the Rules Engine. ADF Business Components fact types enables you to use ADF Business Components as Facts in rules and in Decision Tables.

In Oracle Business Rules, facts that you can run against the rules are data objects that have been asserted. Each object instance corresponds to a single fact. If an object is re-asserted (whether it has been changed or not), the Rules Engine is updated to reflect the new state of the object. Re-asserting the object does not create a fact. To have multiple facts of a particular fact type, separate object instances must be asserted.

You can create value sets to define a list of values or a range of values of a specified type. After you create a value set, you can associate the value set with a business term of matching type. When a value set is associated with a business term, Oracle Business Rules uses the values or ranges that you define as constraints for the values for the business terms for the business terms in rules that are in the Decision Tables.

For more information, see:

3.2 Working with XML Facts

The XML fact type allows 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 IF/THEN rules and Decision Table rules, 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).

Thus, with Oracle Business Rules if you have an XML document that contains data associated with your application and you have the schema associated with the XML document then you can use Rules Designer to define rules based on elements that you specify from the XML Schema.

Note:

When xsd has primitive or non primitive root elements of simple type, JAXB maps the simple type elements to a JAXBElement and generates only ObjectFactory class. You must create Facts of complex type to be used in business rules.

3.2.1 How to Create XML fact types

Define or obtain an XML Schema.
Use Rules Designer to import the XML Schema into a dictionary.

This step uses the JAXB compiler to generate Java classes from the XML Schema. After you compile the XML Schema, you select the desired elements from the schema to add XML Facts in the data model and import the generated JAXB classes into the data model.

For more information on these steps, see How to Import the XML Schema and Add XML Facts.
Write rules or create Decision Tables based on these XML Facts that you added to the data model.

For more information, see Working with Rules and Creating Decision Tables.

Elements and types defined in the XML Schema can be imported into the data model so that instances of types can be created, asserted, modified, and retracted by rules. Most XML documents describe hierarchical information, where each element contains subelements. It is common for users to want to write individual rules based on multiple elements in this hierarchy, and the hierarchical relationship among the elements.

In Oracle Business Rules the default behavior when you assert a fact is to only assert the single fact instance, and none of the child objects it may reference in the hierarchy of subelements. When you create rules or a Decision Table it is often desirable to assert an entire hierarchy of elements based on a reference to a root element. Oracle Business Rules provides the assertTree action type that allows for a recursive assert for a hierarchy. For more information, see Working with Tree Mode Rules.

3.2.2 How to Import the XML Schema and Add XML Facts

Before you can use the XML Schema definitions in a data model you must import the XML schema. This step generates the JAXB classes and makes the generated classes and packages associated with the XML schema visible in Rules Designer.

To import XML schema and add XML facts:

In Rules Designer, select the Facts navigation tab.
Select the XML Facts tab on the Facts navigation tab, as shown in Figure 3-1.

Figure 3-1 The XML Facts Tab in Rules Designer

Description of "Figure 3-1 The XML Facts Tab in Rules Designer"
In the XML Facts tab, click Create.... This displays the Create XML Fact dialog.
In the Create XML Fact dialog, in the Source Schemas area, click Add Source Schema... to open the Add Source Schema dialog.
In the Add Source Schema dialog,
- Enter the location of the XML Schema you want to import, or click Browse to locate the XML schema in the Schema Location field. During the import the file is copied into the project.
  
  Note:
  
  Typically, the XML schema (xsd) file is located inside the xsd folder called Schemas, because any XML schema that is created needs to be stored inside the xsd folder under SOA.
- Accept the default path or enter the directory where you want Rules Designer to store the JAXB-generated Java source and class files in the JAXB Classes Directory field.
- Enter a target package name or leave this field empty in the Target Package field. If you leave this field empty the JAXB classes package name is generated from the XML target namespace of the XML schema using the default JAXB XML-to-Java mapping rule or explicitly defined package name using annotations, or "generated" if no namespace or annotation is defined. Using the schema namespace is preferred.
  
  For example, the namespace http://www.oracle.com/as11/rules/demo is mapped to com.oracle.as11.rules.demo.
- Click OK.
  
  Rules Designer processes the schema and compiles the JAXB, so depending on the size of the schema this step may take some time to complete. When this step completes Rules Designer displays the Create XML Fact dialog with the Target Classes area updated to include the JAXB classes.
In the Create XML Fact dialog, in the Target Classes area, select the classes you want to import as XML fact types.
Click OK.

3.2.3 How to Display and Edit XML Facts

To work with an XML Fact, in Rules Designer open the Edit XML Fact dialog.

To display and edit XML facts:

In Rules Designer, select the Facts navigation tab.
Select the XML Facts tab on the Facts navigation tab.
In the XML Facts table, double-click the icon for the XML Fact you want to edit. This displays the Edit XML Fact dialog, as shown in Figure 3-2.

Figure 3-2 Edit XML Fact Dialog

Description of "Figure 3-2 Edit XML Fact Dialog"

The Edit XML Fact dialog includes the fields shown in Table 3-1.

Table 3-1 XML Fact: Edit XML Fact Dialog Fields

Field	Description
Name	Displays the XML Fact name. You cannot change the name of JAXB generated class.
Alias	Enter the XML Fact alias. You can change this value. This defaults to the unqualified name of the class.
Qualifier Pattern	This field is used for verbal rules. If nothing is specified here, then the system uses the global qualifier. If a custom qualifier pattern should be specified for a fact, it has to contain two parts in the pattern: {member}, {fact}. Specify patterns as follows: {fact}'s {member} {member} in {fact} {member} of {fact} (This is the default). For more information about using verbal rules, see Introduction to Verbal Rules and Business Phrases.
Super Class	Displays Java super class associated with this fact.
XML Name	Displays the XML name associated with the XML Fact.
Generated From	Displays the XML schema file that was the source for the XML Fact when it was copied into the business rules data model.
Visible	Select to show the XML Fact in lists in Rules Designer. XML Facts often reference other XML Facts, forming a tree. You should make all the XML fact types visible that contain properties that you reference in rules.
Support XPath Assertion	Select to enable XPath assertion for the fact. This feature is provided for backward compatibility only. Typically, this option is not used.
Description	Enter the XML Fact description.
Attributes area	Select the available constructors, properties, methods, or fields associated with the JAXB class for the XML Fact to display or edit.
Fit Columns to Width	Select this check box to adjust column width.

3.2.4 How to Reload XML Facts with Updated Schema

If an XML schema changes in a project, the schema must be reimported into the Oracle Business Rules dictionary. When you reimport the schema, Oracle Business Rules uses JAXB to recompile all source schemas for every XML fact type and updates the XML fact type definitions with the updated XML schema definitions. You should reimport facts if you changed the schema or classes and you want to use the changed schema or classes at runtime.

Note:

When the XML schema on which an XML fact is based changes, on reimporting the schema, the facts are updated and imported into the base dictionary. When working with facts in a linked dictionary, you need to reload the XML facts for the changed schema from the base dictionary instead of the linked dictionary.

To reimport XML facts:

In Rules Designer, select the Facts navigation tab.
Select the XML Facts tab on the Facts navigation tab.
On the XML Facts page, click Reload Facts Based on Modified Schemas (Excluding Linked Facts) or Reload All Facts (Excluding Linked Facts).

After the reimport operation you need to correct any validation warnings that may be caused by incompatible changes (for example, the updated schema may include a change that removed a property that is referenced by a rule).

3.2.5 What You Need to Know About XML Facts

Keep the following points in mind when you work with XML Facts:

When XML Schema contain a restriction definition, this allows a user to restrict the types that are valid for use in an element. A common use of restriction is to define an enumeration of strings which can be used for an element, as shown in the XML Schema Restriction example below:

```
<xs:simpleType name="status-type">
        <xs:restriction base="xs:string">
            <xs:enumeration value="manual"/>
            <xs:enumeration value="approved"/>
            <xs:enumeration value="rejected"/>
        </xs:restriction>
</xs:simpleType>
```
Oracle JAXB 2.0 maps a restriction to a Java enum type. When you use Rules Designer to import either a Java enum type or an element with an XML restriction, the static final fields representing the enums are available for use in expressions. Additionally, Oracle Business Rules creates a value set for each enum containing all of the enum values and null. For more information on value sets, see Working with Value Sets.
There is a default version of the JAXB binding compiler supplied with Oracle Application Server. You can use a different JAXB binding compiler. However, to use a different JAXB binding compiler you must manually perform the XML schema processing and then import the generated Java packages and classes into the data model as Java Facts.

For more information about JAXB, see

http://java.sun.com/webservices/jaxb/
You should reimport facts if you changed the schema or classes and you want to use the changed schema or classes at runtime. You should correct any validation warnings that may be caused by incompatible changes (for example, removing a property that is referenced by a rule). For more information, see How to Reload XML Facts with Updated Schema.
Most users should not need to use the ObjectFactory or import it. If you do need to import and use the ObjectFactory, then use a different package name for every XML Schema that you import; otherwise the different ObjectFactory classes conflict.
The use of XML schema with elements that have minOccurs="0" and nillable="true" has special handling in JAXB. For more information, see Why do XML Schema with xsd:string Typed Elements Import as Type JAXBElement?.
The default element naming conventions for JAXB can cause XML schema containing the underscore character in XML-schema element names to fail to compile. For more information, see Why Does XML Schema with Underscores Fail JAXB Compilation?.
There are certain restrictions on the types and names of inputs for the Decision Service. For more information, see How Are Decision Service Input Output Element Types Restricted?.
The built-in dictionary includes support for the Java wrappers Integer, Long, Short, Float, Double, BigDecimal, and BigInteger. These types can appear in XML Fact Types.

3.3 Working with Java Facts

In Rules Designer, importing a Java Fact makes the Java classes and their methods become visible to Rules Designer. Rules Designer does not copy the Java code or bytecode into the data model or into the dictionary.

A Java fact type allows selected properties and methods of a Java class to be imported to the Rules Engine so that rules can access, create, modify, and delete instances of the Java class.

Importing a Java fact type allows the Rules Engine to access and use public attributes, public methods, and bean properties defined in a Java class (bean properties are preferable because they can be modified using the modify action).

3.3.1 How to Import Java Classes and Define Java Facts

Before you can use Java Facts in rules and in Decision Tables, you must make the classes and packages that contain the Java Facts available to Rules Designer. To do this you use Rules Designer to specify the classpath that contains the Java classes, and then you import the Java Facts.

Java fact types allow methods with and without side effects to be imported. Side effects refer to expensive operations such as I/O, Database Query or web service and so on. When using Java classes as facts, remember the following about side effects:

Rule and Decision Table conditions do not use methods with side effects.
Actions can use all methods. Though side effects are not recommended, are permissible.

To import and define Java Facts:

In Rules Designer, select the Facts navigation tab.
Select the Java Facts tab on the Facts navigation tab as shown in Figure 3-3.

Figure 3-3 The Java Facts Table in the Facts Navigation Tab

Description of "Figure 3-3 The Java Facts Table in the Facts Navigation Tab"
In the Java Facts tab, click Create... to open the Create Java Fact dialog.
In the Create Java Fact dialog, if the classpath that contains the classes you want to import is not shown in the Classpath area, then click Add to Classpath. This displays the Choose Directory/Jar dialog.

The default Rules Designer classpath includes three packages, java, javax, and org. These packages contain classes that Rules Designer lets you import from the Java runtime library (rt.jar). Rules Designer does not let you remove these classes from the Classes area (and the associated classpaths are not shown in the Classpaths area).
In the Choose Directory/Jar dialog, browse to select the classpath or jar file to add. By default, the output directory for the project is on the import classpath and any Java classes in the project should appear in the Classes importer. If they do not appear, execute the Build action for the project.
Click Open. This adds the classpath or jar file and updates the Classes area.
In the Create Java Fact dialog, in the Classes area select the packages and classes to import.
Click OK. This updates the Java Facts table in the Java Facts tab.

3.3.2 How to Display and Edit Java Facts

To display or edit Java Facts after you import the Java Facts, use the Edit Java Fact dialog.

To display and edit Java facts:

In Rules Designer, click the Facts navigation tab.
Select the Java Facts tab in the Facts navigation tab.
In the Java Facts table, double-click the Java Fact you want to edit. This displays the Edit Java Fact dialog as shown in Figure 3-4.

Figure 3-4 Edit Java Fact Dialog

Description of "Figure 3-4 Edit Java Fact Dialog"

The Edit Java Fact dialog includes the fields shown in Table 3-2.

Table 3-2 Edit Java Fact Dialog Fields

Field	Description
Class	Displays the Java Fact class for the source associated with the Java Fact.
Alias	Enter the Java Fact alias.
Qualifier Pattern	This field is used for verbal rules. If nothing is specified here, then the system uses the global qualifier. If a custom qualifier pattern should be specified for a fact, it has to contain two parts in the pattern: {member}, {fact}. Specify patterns as follows: {fact}'s {member} {member} in {fact} {member} of {fact} (This is the default). For more information about using verbal rules, see Introduction to Verbal Rules and Business Phrases.
Super Class	Displays Java super class associated with this fact.
Visible	Select to show the Java Fact in lists in Rules Designer.
Description	Enter the Java Fact description.
Attributes area	Select the available class properties, constructors, methods, or fields associated with the Java class for the Java Fact act to display or edit.
Properties	Some java objects have fields to help define that object. For example a Calendar has properties for defining the first day of the week, the time zone, and so on.
Fit Columns to Width	Select this check box to adjust column width.
Attribute Description	The Attribute Description is the description of the property.

3.3.3 What You Need to Know About Java Facts

When you define Java Facts you need to know the following:

On Windows systems, you can use a backslash (\) or a slash (/) to specify the classpath in the Classpath area. Rules Designer accepts either path separator.
Classes and interfaces that you use in Rules Designer must adhere to the following rules: If you are using a class or interface, only its superclass or one of its implemented interfaces may be made visible.
When you specify the classpath you can specify a JAR file, a ZIP file, or a full path for a directory.
When you specify a directory name for the classpath, the directory specifies the classpath that ends with the directory that contains the "root" package (the first package in the full package name). Thus, if the classpath specifies a directory, Rules Designer looks in that tree for directory names matching the package name structure.

For example, to import a class cool.example.Test1 located in c:\myprj\cool\example\Test1.class, specify the classpath value, c:\myprj.
You should reimport facts if you change the classes. After the reimport operation you may see validation warnings due to class changes. You should correct any validation warnings that may be caused by incompatible changes (for example, removing a property that is referenced by a rule).

3.4 Working with RL Facts

RL Facts are the only kind of facts that you can create directly and that do not have an external source. All other types of Oracle Business Rules facts are imported. An RL Fact is similar to a relational database row or a JavaBean without methods. An RL Fact contains a list of properties of types available in the data model, either RL Fact, Java Fact, or primitive types.

You can use an RL Fact to extend a Java application object model by providing virtual dynamic types.

For example:

R1: if monthly spend = Customer.monthlySpend 
then assert new Temp(three month spend: monthly spend[0] + monthly spend[1] + monthly spend[2])
R2: if Temp.three month spend > 500
then modify Temp(status: GOLD)
R3: if Temp.status == GOLD
then assert new Result(discount: 0.10).

For testing and prototyping with Rules Designer you can create RL Facts and use the RL Facts to write and test rules before you import a schema and switch to XML Facts (you might need to wait for an approved XML schema to be created or to be made available). Switching from RL Facts to corresponding XML Facts involves the following steps:

Delete the RL Facts (this action shows validation warnings in the rules or Decision Tables you created that use these RL Facts).
Import the XML Facts and give the facts and their properties aliases that match the names of the RL Facts and properties you deleted in step 1.
This process should remove the validation warnings if the XML Fact and property aliases and types match those of the RL Facts that you remove.

3.4.1 How to Define RL Facts

You add RL Facts from the Facts navigation tab.

To define RL facts:

In Rules Designer, select the Facts navigation tab.
Select the RL Facts tab in the Facts navigation tab as shown in Figure 3-5.

Figure 3-5 RL Facts Tab in Rules Designer

Description of "Figure 3-5 RL Facts Tab in Rules Designer"
In the RL Facts tab, click Create.
In the RL Facts table, in the Name field, enter the name for the RL Fact or accept the default name.
In the RL Facts table, in the Description field, enter a description or accept the default, no description.

3.4.2 How to Display and Edit RL Facts and Add RL Fact Properties

You add properties to RL Facts using the Edit RL Facts dialog.

To display and edit RL facts and add RL fact properties:

In Rules Designer, select the Facts navigation tab.
In the RL Facts tab, double-click the icon for the RL Fact to display or edit the fact. This displays the Edit RL Fact dialog, as shown in Figure 3-6.

Figure 3-6 Edit RL Fact Dialog

Description of "Figure 3-6 Edit RL Fact Dialog"
To add RL Fact properties, on the Edit RL Fact dialog in the Properties area, click Create.
1. In the Name field, enter the property name.
2. In the Type field, select a type from the list or enter a property type.
3. To associate a value set with the property, from the list in the Value Set field, select a value set.
4. To associate an initial value with the property enter a value in the Initial Value field.
Add additional properties by repeating these steps, as required.
Click OK.

3.4.3 What You Need to Know About RL Facts

When you add properties to RL Facts using the Edit RL Facts dialog, in the Properties area the Initial Value field provides a list of possible values as shown in Figure 3-7.

Figure 3-7 Setting RL Fact Property Initial Value

Description of "Figure 3-7 Setting RL Fact Property Initial Value"

When you are working with some fields in Rules Designer, the initial values list or other lists may be empty. In this case the list is an empty box. Thus, when Rules Designer does not find options to assist you in entering values, you must supply a value directly in the text entry area or click the Expression Builder button to display the expression builder dialog.

3.5 Working with ADF Business Components Facts

ADF Business Components Facts enable you to use ADF Business Components as Facts in rules and in Decision Tables. By using ADF Business Components Facts you can assert view object graphs representing the business objects upon which rules should be based, and let Oracle Business Rules deal with the complexities of managing the relationships between the various related view objects in the view object graph.

For more information, see Working with Oracle Business Rules and ADF Business Components .

3.5.1 How to Import and Define ADF Business Components Facts

When an ADF Business Components view object is imported, an ADF Business Components fact type is created which has a property corresponding to each attribute of the view object.

To add ADF Business Components facts:

Click the Facts navigation tab and select the ADF-BC Facts tab. This displays the ADF-BC Facts table, as shown in Figure 3-8.

Figure 3-8 ADF Business Components Facts Tab

Description of "Figure 3-8 ADF Business Components Facts Tab"
Click Create.... This opens the Create ADF-BC Fact dialog.
In the Connection field, from the list, select the connection which your ADF Business Components objects use. The Search Classpath area shows a list of classpaths. For more information, see What You Need to Know About ADF Business Components Fact Classpaths.
In the View Definition field, select the name of the view object to import.
Click OK. This displays the Facts navigation tab. Note that the imported fact includes a validation warning. For information on how to remove this validation warning, see What You Need to Know About ADF Business Components Circular References.

3.5.2 What You Need to Know About ADF Business Components Fact Classpaths

In the classpath list shown in the Search Classpath area in the Create ADF Business Components Fact dialog one of the listed classpaths allows you to see the view object definitions available in your project. In this dialog you only need to click Add to Classpath when you need to use a classpath that is not available to your project (this case should be very rare).

3.5.3 What You Need to Know About ADF Business Components Circular References

ADF Business Components Facts can include a circular reference. When this warning is shown in the Business Rule validation log you need to manually resolve the circular reference. To do this you must clear the Visible check box for one of the properties that is involved in the circular reference.

3.5.4 What You Need to Know About ADF Business Components Facts

Each ADF Business Components fact type contains a property named ViewRowImpl that references the oracle.jbo.Row instance that the fact instance represents and a property named key_values which points to an oracle.rules.sdk2.decisionpoint.KeyChain object that may be used to retrieve the set of key-values for this row and its parent rows.

When working with ADF Business Components Facts you should know the following:

Relationships between view object definitions are determined by introspection of attributes on the View Definition, specifically, those attributes which are View Link Accessors.

The ADF Business Components fact type importer correctly determines which relationships are 1-to-1 and which are 1-to-many, and generates definitions in the dictionary accordingly. For 1-to-many relationships the type of the property generated is a List, which contains facts of the indicated type at runtime.
It is not possible to use ADF Business Components fact types which have cyclic type dependencies. These cycles must be broken by the clearing the Visible check box for at least one property involved in the cycle.
ADF Business Components fact types are not Java fact types and do not allow invoking methods on any explicitly created implementation classes for the view object.

If you need to call such methods then add the view object implementation to the dictionary as a Java fact type instead of as an ADF Business Components fact type. In this case, all getters and setters and other methods become available but the trade-off is that related view objects become inaccessible and, should related view object access be required, these relationships must be explicitly managed.
Internally, ADF Business Components fact types are instances of RL fact types.

Thus, you cannot assert ADF Business Components view object instances directly to a Rule Session, but must instead use the helper methods provided in the MetadataHelper and ADFBCFactTypeHelper classes. For more information, see Oracle Fusion Middleware Java API Reference for Oracle Business Rules.

3.6 Working with Value Sets

You can create a value set to define a list of values or a list of value ranges to limit the acceptable set of values for a fact or a property of a fact in Oracle Business Rules. You can define a value set as a Global Value Set that allows reuse, where a value set is named and stored in the data model, or as a Local Value Set that is specified when you define a Decision Table and only applies to one condition expression.

For more information on using a local value set, see How to Add Condition Rows to a Decision Table.

You can use value sets for the following:

You can associate fact type properties with value sets. This allows you to limit the acceptable set of values for a property of a fact. For more information, see How to Associate a Value Set with a Fact Property.
A value set defines a list of values or value ranges for some primitive value (number, string, date, boolean, or enumeration). A value set may be associated with a fact type property in order to provide a fixed set of choices for the value of that property, for example, male or female. A value set must be associated with a decision table condition to provide a fixed set of choices for the value of the condition's expression. These choices (values or value ranges) are entered into the condition cells of the decision table.

The value set values or ranges determine, for each condition expression in a Decision Table, that it has two or more possibilities. Using a value set, each possibility in a condition expression is divided into values or ranges where a cell specifies one value or range from the value set (or possibly multiple values or ranges per cell). For example, if a value set is defined for colors, then the values or ranges could include a list of strings: "blue", "red", and "orange". A value set that includes integers could have three ranges could have three ranges, less than 1, 1 to 10, and greater than 10. For more information, see How to Add Condition Rows to a Decision Table.
You can associate globals, functions, and function arguments with value sets. Associating a value set with a global allows for design-time validation that an assigned value is limited to the values specified in the value set. Associating a value set with a function argument validates that the function is only called with values in the value set. Using value sets in this manner allows Rules Designer to report validation warnings for global values and function arguments that are assigned or passed a constant argument value that is not allowed. Associating a value set with a function automatically sets a Decision Table condition row to use that value set when the function is used as the expression for that condition row. Only constant expression values are validated. To ensure that global initial expression values and function parameter expression values are validated against the associated value set, check the 'constant' check box associated with the expression. No runtime checks are applied based on the globals or function arguments associated with value sets. For more information, see How to Associate a Value Set with Functions or Function Arguments.
In addition to design-time validation you can use an LOV value set to provide options that are displayed in lists when entering expressions in IF/THEN rule tests and actions. For more information, see How to Use Value Sets to Provide Options for Test Expressions.

There are three forms for value sets:

LOV: Defined by a list of values (see How to Define a List of Values Global Value Set).
Range: Defined by a list of value ranges, defined by the range endpoints (see How to Define a List of Ranges Global Value Set).
Enum: Defined by a list of enumerated types that is imported from either of:
- XML types (see How to Define an Enumerated Type (Enum) Value Set from XML Types).
- Java facts (see How to Define an Enumerated Type (Enum) Value Set from Java Types).

3.6.1 How to Define a List of Values Global Value Set

A list of values value set lets you specify the type and the list of values or ranges for the value set. For more information, see What You Need to Know About List of Values Value Sets.

To define a list of values (LOV) global value set:

From Rules Designer select the Value Sets navigation tab.
From the list next to the Create Value Set icon, select Value Set, as shown in Figure 3-9.

Figure 3-9 Adding a List of Values Global Value Set

Description of "Figure 3-9 Adding a List of Values Global Value Set"
Click the Edit button for the value set to display the Edit Value Set dialog.
In the Edit Value Set dialog, enter the name in the Name column.
Ensure that the value set name is not the same as any fact aliases. This will cause a validation error similar to the following:
```
RUL-05006: The fact type "Rating" has the same alias as an unrelated value set.
```
In the Datatype column, select a data type from list.
Enter a Description.
Click the Edit button to add a value, as shown in Figure 3-10.

Figure 3-10 Edit Value Set Dialog

Description of "Figure 3-10 Edit Value Set Dialog"
For each value that you add, do the following:
- In the Value field, enter a value. Note that for String type values in an LOV value, you can select the entire string with three clicks. This allows you to enter the string. Rules Designer adds the same alias without quotation marks.
  
  You can change the order of values in the list of Value set by editing the Value set dialog for a value set. Click the Move up or Move Down button to change the order.
- In the Alias field, enter an alias.
  
  For more information on specifying aliases, see How to Define a List of Ranges Global Value Set.
- In the Allowed in Actions field, select this if the value is an allowable value.
  
  For more information on the Allowed in Actions field and the Include Disallowed Values in Tests field, see What You Need to Know About the Value Set Allowed in Actions Option.
- In the Description field, enter a description.
Add additional values by clicking the Create button as needed for the value set.
On the Edit Value Set window, click OK.

You can control rule ordering in a Decision Table by changing the relative position of the values or ranges in an LOV value set associated with a condition expression in a Decision Table.

3.6.2 How to Define a List of Ranges Global Value Set

A list of ranges value set lets you specify the type and the endpoints for values or ranges in the value set. For more information, see What You Need to Know About Range Value Sets.

To define a list of ranges (range) global value set:

From Rules Designer select the Value Sets navigation tab.
From the list next to the Create Value Set button, select Range Value Set.
Double-click in the Data Type field. This displays the Edit Value Set dialog, enter the values set name in the Name field.
In the Data Type field, from the list, select the appropriate data type for the value set.
Click the Create repeatedly to add the number of values or ranges that you need in the value set.
In these steps you add three values. You start with the default values. After changing the defaults, they should have the following values:
- greater than 1000
- between 500 and 1000, inclusive
- less than 500
Rules Designer added the values with the default values of 50 and 0 and a negative Infinity (-Infinity) value.
Starting at the first or top value, in the Endpoint field, double-click the default value and enter the top value endpoint, and press Enter.

In this example, enter 1000 for the first value.
In the Included Endpoint field, select the check box as appropriate to include or exclude the value endpoint.

In this example, you can leave this check box checked to include the value endpoint.
In the Allowed in Actions field select the check box as appropriate to include the value in the value set allowable values.

For more information on the Allowed in Actions field and the Include Disallowed Values in Tests field, see What You Need to Know About the Value Set Allowed in Actions Option.
Optionally, in the Alias field double-click the default value and enter the desired value alias, and press Enter.

The alias appears in Decision Tables that use this value set. Use an alias to give a more meaningful name to the value than the default value (the range-based Range value).

Note that most names and aliases in Oracle Business Rules allow only letters, numbers, embedded single spaces, and the characters $, _, ', ., -, /, and :. However, value aliases allow additional characters, such as [0..1]. If an alias contains such additional characters, then you cannot refer to the value by the alias in the action cells in a Decision Table. In these cases, you can use the value name, which is also known as the value.

The Range field is read-only: it clearly identifies the actual range associated with the value regardless of the Alias value. For more information, see What You Need to Know About Range Value Sets).
Moving down the list of values, for each subsequent vale, repeat from Step 6. For the second value, enter the endpoint value 500.
In the Edit Value Set dialog, click OK.

3.6.3 How to Define an Enumerated Type (Enum) Value Set from XML Types

When you import an XML schema, if the XSD contains enumeration values Rules Designer automatically creates an enumerated type value set for each enumeration. Although enumerated type value sets are read-only, you can change the order of values.

For more information, see What You Need to Know About XML Facts.

To define an enumerated type (enum) value set from XML types:

Obtain an XSD with the desired enumerations.

The following example shows the order.xsd schema file which contains the enumeration Status.

<?xml version="1.0" ?>
<schema attributeFormDefault="qualified" elementFormDefault="qualified"
        targetNamespace="http://example.com/ns/customerorder"
        xmlns:tns="http://example.com/ns/customerorder"
        xmlns="http://www.w3.org/2001/XMLSchema">
  <element name="CustomerOrder">
    <complexType>
      <sequence>
        <element name="name" type="string" />
        <element name="creditScore" type="int" />
        <element name="annualSpending" type="double" />
        <element name="value" type="string" />
        <element name="order" type="double" />
      </sequence>
    </complexType>
  </element>
  <element name="OrderApproval">
    <complexType>
      <sequence>
        <element name="status" type="tns:Status"/>
      </sequence>
    </complexType>
  </element>
  <simpleType name="Status">
    <restriction base="string">
        <enumeration value="manual"/>
        <enumeration value="approved"/>
        <enumeration value="rejected"/>
    </restriction>
  </simpleType>
</schema>

Open a dictionary in Rules Designer and create XML facts using the specified schema that contains the enumeration. For more information, see Working with XML Facts.
Click the Value Sets navigation tab and select the Enum value to see the value set. Notice that the imported Status enumeration values are imported as values with the XSD-specified values.

You can change the order of values in an Enumerated Value set by editing the Value set dialog for a value set. Click the Move up or Move Down button to change the order.

You can control rule ordering in a Decision Table by changing the relative position of the values in an enum value set associated with a condition expression in a Decision Table.

3.6.4 How to Define an Enumerated Type (Enum) Value Set from Java Types

When you import a Java enum, Rules Designer automatically creates an enumerated type value set for each Java enum. Although enumerated type value sets are read-only, you can change the order of values.

To define an enumerated type (enum) valueset from Java facts:

Create or obtain the Java class with the desired enumerations.
The following code example shows the RejectPurchaseItem.java class which contains enumeration OrderSize.
```
package com.example;
```
```
public class Class1
```
```
{
```
```
    public enum OrderSize { SMALL, MEDIUM, LARGE };
```
```
    public Class1()
```
```
    {
    }
}
```
In Rules Designer open a dictionary and create a Java Fact using the Java class. For more information, see Working with Java Facts.
In Rules Designer click the Value Sets navigation tab and select the Enum value set.

You can change the order of values or ranges in an enumerated type valueset by editing the Value set dialog for a value set. Click the Move up or Move Down button to change the order.

You can control rule ordering in a Decision Table by changing the relative position of the values or ranges in an enum value set associated with a condition expression in a Decision Table.

3.6.5 What You Need to Know About List of Values Value Sets

In a Decision Table, the order of the values in a value set associated with a condition expression determines the order of the condition cells, and thus the order of the rules. You can control rule ordering in a Decision Table by changing the relative position of the values in a list of values value set associated with a condition expression; however, you cannot reorder ranges.

Figure 3-11 shows a value set definition in Rules Designer for a value set named colors using a list of values.

Figure 3-11 Value Set Definition Using List of Values

Description of "Figure 3-11 Value Set Definition Using List of Values"

As shown in Figure 3-11, by default with a List of Values value set there is a value otherwise included with the list of values (LOV). This value, otherwise, is distinct from all other values and matches all values of the type that have no other value or range. Thus, with otherwise in the list of values a condition expression that uses the value set can handle every value and provides a match for every value of the specified type, where a match is either a defined value or the otherwise value. The otherwise value cannot be removed from an LOV value set but it can be excluded by clearing the Allowed in Actions check box (when otherwise is excluded an attempt to assign any value that is not in the list of values in the value set causes a validation warning).

Table 3-3 shows the value set values that Rules Designer supports for LOV value sets.

Table 3-3 Supported Types for LOV Value Sets

Type	Description
Java primitive types	This includes `int`, `double`, `boolean`, `char`, `byte`, `short`, `long`, and `float`
`String`	Contains `String` types
`Time, DateTime, and Date`	Contains `Time, DateTime, and Date` types in the current locale

Note

You are not required to specify an LOV value set when you use a boolean type in a Decision Table. For boolean types, Oracle Business Rules provides built-in values or ranges for the possible values (true and false).

3.6.6 What You Need to Know About Range Value Sets

When you add a value or range to a List of Ranges value set, the value is calculated based on the currently selected value and the next highest value. When you change the endpoint value the value is automatically sorted in the value set; thus, it does not matter where a new range is added. However, it is possible for Rules Designer to not have values between the current value set endpoint value and the endpoint value. In this case, Rules Designer shows a validation warning of the following form:

RUL-05849: Valueset has duplicate bucket value "4999"

To correct this problem you must modify value endpoints to remove the duplicate value.

Table 3-4 shows the types Rules Designer supports for Range values.

Table 3-4 Supported Types for Range Values

Type	Description
Selected primitive types	This includes: `int`, `double`, `short`, `long`, and `float`
`Time, DateTime, and Date`	Contains `Time, DateTime, and Date` types in the current locale

Note the following conventions for the Range field:

Logical operator: specifies a range with respect to positive or negative infinity. For example, ">=25" means "from 25 to positive infinity" and "<18" means from negative infinity up to but not including 18.
Square bracket "[": specifies a range that includes this end point value. For example, "[18..25)" means "from 18 up to but not including 25".
Round bracket ")": specifies a range that excludes this end point value. For example, "(18..25]" means "over 18, not including 18, up to and including 25".

3.6.7 What You Need to Know About the Value Set Allowed in Actions Option

When you define values or ranges in a value set you might define some ranges or values corresponding to non-permissible values. For example, in a value set for driver ages you would typically not allow a value that contains values less than 0. Thus, when a fact with driver data includes an age property associated with a driver ages value set, then you should not be able to create or modify a fact that has the age property set to a value such as -1. In a value set you select Allowed in Actions for valid values and clear this option for invalid values.

The value set option Include Disallowed Values in Tests allows you to include all the values, whether Allowed in Actions is selected or not, in Decision Table conditions and in rule tests. By including all values or ranges you can explicitly test for illegal values. Using the option Include Disallowed Values in Tests you can handle two possible cases:

The input data for the Oracle Business Rules Engine is clean and does not contain invalid data (such as a negative age). In this case, you should clear the Include Disallowed Values in Tests. Note: the reason you do not want to make age < 0 an Allowed in Actions is this provides design time validation warnings if you try to create an action that uses an invalid value, such as the following: modify(driver, age: -1)). For more information, see Using Value Sets as Constraints for Options Values in Rules.
You want to consider excluded values in rule tests and in Decision Tables. In this case, you should select Include Disallowed Values in Tests. This is useful when the input data for the Oracle Business Rules Engine may not be clean and may contain invalid data (for example an invalid negative age). A Decision Table that provides actions for all value sets could include cases for excluded values and provide an appropriate action, such as asserting an error fact. To handle this you could either select the Allowed in Actions field for every value in the value set, or, leave the Allowed in Actions field configured as is and select the Include Disallowed Values in Tests field. Using the Include Disallowed Values in Tests field is not only convenient, you do not need to reconfigure every value, it also preserves the configuration of Allowed in Actions so that you can easily reuse this value set to handle the first case (when you clear Include Disallowed Values in Tests).

3.6.8 What You Need to Know About Values

When you enter a value in a value set, the value you supply must be valid for the type specified for the value set. If the value you enter is not valid for the value set type, Rules Designer makes the value you supply a string by adding quotation marks. Adding quotation marks is the only way to make a legal literal when the user provided data is not appropriate for the specified type. For example, if you add an int type LOV value set, and then supply a value 2.2, Rules Designer shows a warning such as the following:

RUL-05833: Invalid characters "2.2" in value

To fix this problem either enter a valid value for the value, for example in this case the value 2, or change the type of the value set.

For an additional example, when you enter a value for a value, for example if you enter a value with value set with data type short and add a value with the value 999999, Rules Designer assigns this the value "999999". The maximum value for a short is 32767. In this case you see a warning related to the value, similar to the previous example, because a String is not a valid value for a value set with data type short. The solution to this is to enter appropriate values for all values (in this example, enter a value less than or equal to 32767).

3.7 Associating a Value Set with Business Terms

After you define a global value set, you can associate parts of the data model with the global value set (if their types are compatible). In this way, condition cells in the Conditions area can automatically be assigned a value set when you define a Decision Table. Also, when a value set is associated with a business term, Oracle Business Rules uses the values or ranges that you define as constraints for the values for expressions for the business terms in rules.

You can associate the following four kinds of business terms with a value set:

Fact Property
Function Result
Function Argument
Global Value

3.7.1 How to Associate a Value Set with a Fact Property

To prepare for creating Decision Tables, you can associate a global value set with fact properties in the data model.

To associate a value set with a fact property:

From Rules Designer, select the Facts navigation tab.
Select the fact type to edit and click the Edit button. This displays the appropriate Edit Fact dialog for the fact type you select.
In the Properties table, under Value Set, select the cell for the appropriate fact property and from the list select the value set you want to associate with the property. For example, see Figure 3-12.

Figure 3-12 Defining a Value Set for a Property

Description of "Figure 3-12 Defining a Value Set for a Property"
On the Edit Fact page, click OK.

3.7.2 How to Associate a Value Set with Functions or Function Arguments

To prepare for creating Decision Tables you can associate a global value set with functions in the data model.

To associate a value set with a function return value:

From Rules Designer, select the Functions tab.
Select the function to edit. This shows the function arguments and the function body for the specified function.
In the Functions table, under Value Set, select the cell and from the list select the value set you want to use. For example, see Figure 3-13.

Figure 3-13 Defining a Value Set for a Function Return Value

Description of "Figure 3-13 Defining a Value Set for a Function Return Value"

3.7.2.1 How to Associate a Value Set with a Function Argument

To associate a value set with a Function argument:

From Rules Designer, select the Functions navigation tab.
Select the function to edit. This shows the function arguments and the function body for the specified function.
In the Functions table, in the Arguments area select the appropriate argument.
For the specified argument, under Value Set, select the cell and from the list select the value set you want to use.

3.7.3 How to Associate a Value Set with a Global Value

To prepare for creating Decision Tables, you can associate a global value set with global values in the data model.

To associate a value set with a global value:

From Rules Designer, select the Globals navigation tab.
Select the global value to edit.
In the Globals table, under Value Set, select the cell for the appropriate global value, and from the list, select the value set that you want to associate with the global value. For example, see Figure 3-14.

Figure 3-14 Defining a Value Set for a Global Value

Description of "Figure 3-14 Defining a Value Set for a Global Value"