Understanding the Rules Engine
This section discusses:
Rules Engine components.
A high level description of the Rules Engine.
Rules Engine Manager and Entity Registry.
The Rules Engine provides:
a non-programmer user interface to create complex business rules.
a secure way to retrieve data from the system in a logical manner, perform calculations and evaluations, and update data.
a way to use the Entity Registry, a familiar logical hierarchy, to retrieve data from the system; for example, the curriculum structure of the Academic Item Registry (AIR) or the results structure of the Academic Progress Tracker (APT).
System Variables and Functions for creating Rules.
a compiler (Rule Builder) that compiles and readies Rules for execution.
a means to manage changes to Rules over time and a large number of Rules using versioning.
There are three components used to manage the Rules Engine feature:
Rules Engine Manager
The Rules Engine Manager is the interface for creating institution business rules. The Rules Engine Manager can be deployed for two Rule building Skill Levels, Expert and Developer, each with its own set of Rules-building capabilities. The Rules Engine Manager uses the Entity Registry by allowing users to build Rules using a familiar logical hierarchy; for example, the curriculum structure.
Note: Oracle plans to introduce additional Skill Levels in future releases.
Rules Engine
The Rules Engine builds (compiles) and executes the user-created business rules.
Rules Engine Categories.
Rules Engine Categories are used to restrict access to pre-defined and secured areas of application functionality including access to Rules in other Rules Engine Categories and what types of Rules can be created: Triggers, Functions or Rules.
This diagram shows Rules Function functionality:
Image: Rules Engine Business Process (Generic)
Rules Engine Business Process (Generic)
This section discusses the relationship between the Rules Engine and the Entity Registry.
Entity Registry
When building Rules you need access to the data in your system. For Query Manager and Equation Engine, data access is based on granting the user access to specific records in the system.
However, data access for the Rules Engine is controlled through the Entity Registry. An Entity is an object that provides access (view, create, update) to data in a record. The properties on the Entity represent the fields in the actual records.
By design, an Entity is the primary point of access to the underlying records. This avoids potential inconsistencies of having the same logic in multiple places and helps in making relevant code reusable and maintenance easier. This becomes relevant when the same data is accessed or updated in multiple ways: a user-interface, web services, or the Rules Engine.
Entity relationships are represented in a tree-like hierarchy, making the underlying data structure logical for functional users to understand. When building a Rule that needs to access specific system data, you first choose which Base Entity you want to with.
For more information about Entity Registry:
See Setting Up Entity Registry.
Note: Although the Rules Engine can be used with any Entity Registry delivered with the system, it is the Entity Registries created for data records from the Program Enrollment Academic Item Registry (AIR) and Academic Progress Tracker (APT) features that are optimized for Rules Engine use.
These Entities are used throughout this document as examples of how Entity-based data can be used in the Rules Engine.
For more information about AIR and APT, see:
Here is a example that shows part of the APT Entity Registry Hierarchy:
Image: Academic Progress Tracker Program of Study Entity Registry Hierarchy example
This example illustrates the fields and controls on the Academic Progress Tracker Program of Study Entity Registry Hierarchy example. You can find definitions for the fields and controls later on this page.
Here is an example that shows the entities APT Year, APT Study Period, and APT Semester. The properties of APT Semester are expanded and shown:
Image: Academic Progress Tracker Program, other children of the APT Program of Study example
This example illustrates the fields and controls on the Academic Progress Tracker Program, other children of the APT Program of Study example. You can find definitions for the fields and controls later on this page.
In the example above, the APT Year, APT Study Period, and APT Semester entities have been generated from non-system Academic Item Types Year, Study Period, and Semester. AIR and APT structures are unique in that they can be specified using institution specific objects. The Entity Registry reflects this.
The hierarchical relationships between Program of Study, APT year and APT semester are reflected in the APT hierarchy tree and are very similar to how the Curriculum structure reflects in a student's APT:
Image: Example of the Academic Progress Tracker Tree
This example illustrates the fields and controls on the Example of the Academic Progress Tracker Tree. You can find definitions for the fields and controls later on this page.
The results from the student’s APT are reflected in a similar fashion in the Entity Registry Structure:
Image: Academic Progress Tracker Course Entity Registry Hierarchy example
This example illustrates the fields and controls on the Academic Progress Tracker Course Entity Registry Hierarchy example. You can find definitions for the fields and controls later on this page.
Image: Example of Academic Item Attempt
This example illustrates the fields and controls on the Example of Academic Item Attempt. You can find definitions for the fields and controls later on this page.
Entity Properties
Table fields are represented as properties in the Entity Registry. The Rules Engine uses properties to retrieve or update information.
Image: Example of Entity Properties for Academic Item Attempt
This example illustrates the fields and controls on the Example of Entity Properties for Academic Item Attempt. You can find definitions for the fields and controls later on this page.
Entity Profiles
Entity Profiles are used to grant or restrict access to specific Entities and/or Entity properties. For example, you want to allow a specific user to create Rules which retrieve information from APT like the Grade Result Value for a Course, but do not want to allow the ability for this same Rule to retrieve any administrative notes that have been added by the supervisor. Through setup of specific Entity Profiles, you can restrict access to the property that represents the Result Notes.
Security for access to specific Entities via the Rules Engine Manager is enforced by associating specific Entity Profiles with Rules Engine Entity Categories.
This section discusses Rules Engine major features.
Rules Engine Categories
Rules Engine security is enforced through the set up of Rules Engine Categories. A Rules Engine Category is user-defined and tied to one or more Roles and/or specific Users. Rules Engine Category security determines which Entities can be accessed by these Roles and Users and what types of Rules can be created. There are three types of Rules: Triggers, Functions, and Rules. For example, specific Rules Engine Categories may allow the creation of Triggers but not of Rules or Functions. Also, Rules Engine Categories can be set up to use other Rules Engine Categories.
Rule Groups
A Rule Group is a template which can be used to create new Rules that share the same functional purpose. A Rule Group provides a predefined set of input and output parameters for a Rule or Function and an option to predefine a Base Entity. Whenever a Rule is created using the predefined Rule Group, all the Input and Output variables are populated using the Rule Group Template options. By using the same parameters, all Rules created in the same Rule Group can be used the same way. This is beneficial when, for example, you need multiple Rules to be called from a user interface, and you need all of those Rules all to provide similar feedback; like a message that can be displayed on screen. You may also want to dictate that the Input for all of these Rules needs to be the same, namely confined to the information available on the user interface. A Rule Group can subsequently be used to dynamically call all Rules associated with that Rule Group.
Creation of Rule Groups is optional.
Rule Creation
You can use the Rules Engine Manager component to Create, Build, Test, and Version a Rule, and determine if a Rule is used by other Rules.
Creating
You can identify and select a functional application area from which to retrieve data by selecting an Entity and, in the case of a Rule, defining the Criteria which need to be used to select specific data. Use Statements to act upon the selected entity by creating evaluative statements, performing calculations, calling other Rules and Functions, and updating and inserting data in the system.
Building
Once a Rule is created, you must build (compile) it before testing and using it. The Build action compiles the created Rule and converts it into executable code, which means the Rule is ready to perform evaluation and calculation tasks.
Testing
After Rules have been created and built, you can test them with the Rules Engine Tester. The Tester allows users to define and save one or more Test Profiles with test specific data so that multiple scenarios can be tested for the same Rule.
Versioning
The Rules Engine Manager allows the user to create new versions of a Rule and administer one or more version codes and/or code and comments whenever a new version of a Rule is created.
Cross Referencing
The Cross Reference page lists all Functions and Rules which reference the Rule in context.
Calling Rules and Creating Triggers
After Rules have been created, built, tested, and activated, they are ready to use. To use a Rule as part of a functional business process, it needs to be associated with and called from that process. For example, you can set up a Trigger and use the code created by the Trigger to call Rules from a user interface; keeping in mind that the Trigger-generated code may need some adjustment to work for the specific purpose for which you need it.
Note: The determination of where you want to use Rules and how to make them available must be discussed with the technical team that supports Campus Solutions at your school.
Rules can be called and executed from the following application functionality:
Rules Engine Manager Tester
Rules Engine Batch Processing Component
Application Component (for example, a user interface)
See Constructing Rules, “Defining Rule Triggers.”