Rules Browser

 

The Rules Browser screen allows you to add the new rules, view the current rule set and edit/manage the rules. The Rules Browser screen displays the Rules in the currently loaded Rules XML file. Rules are rendered in a natural type language syntax. The Rules display includes the Precondition, Condition, Action, Comments, Rule identifiers and Priorities.

 

Each Rule row displays a Rule ID and a Rule Priority if assigned. Rule IDs are used to refer to the particular rules when you lookup Fact/Atom usage or when a Rule error is encountered. Rule IDs must be unique. Note: if the current rule set is meant to be included into another Rules document at runtime then the Rule IDs must be globally unique within the resulting rule set.

 

New Rules

 

To create a new Rule, click the “Append” or the “Insert” button. You will be asked to enter a new Rule ID. The Rule Edit screen will open allowing you to enter the Rule. Once you apply your changes to that Rule, you will be taken back to the Browse screen where the new Rule will be displayed.

Important: Your new rules or rule changes are not saved until you click the “Save Rules” button!

 

Choose between the Append and Insert depending on the presentation order and the default execution order of your Rules. Unless overwritten by the Priority assignment, Rules are executed in the order they are displayed in the Browse list.

 

Click the “Append” button to add a rule to the end of the list

Click the “Inset” button to insert a new rule at the current location

 

You can always move the rules up and down the list using the Arrow buttons.

 

Editing the Rules

 

To update an existing Rule, click it to highlight the Rule text and then click the “Edit” button. Alternatively you can double click the Rule ID field. The Rule Editor will open allowing you to alter the rule. Editing the Rule implies changing the underlying Rules XML file. To save your XML file changes into the database you must click the “Save Rules” button.

 

 

Deleting the rules

 

In order to delete a rule, highlight it and click the “Delete” button. If this rule is used in the Satisfied Rules List of another rule, you will not be able to delete this rule. Please update the other rule(s) to resolve any dependencies.

 

Adding sections

 

You can insert headers in between the Rules to divide Rules into sections. Sections only apply to the Rules screen and have only visual effect. They are ignored by the BRE. You can enter any section title you want. To insert one, please highlight the Rule above which the title should appear and click the “Make Section” button. The highlighted Rule will become the first rule in the section.

 

To delete a section title, click it and click the “Delete” button.

 

Moving the rules

 

The Rules execution order is determined by their priority and the physical order in the list. You can move the rules across the list and between sections using buttons.

 

Validating the rules

 

Rule validation includes checking the Rule syntax and verifying the Rule entities against the currently open Facts and Atoms.

 

There are two ways to validate the Rules – through the Rule Editor and the Rules Browser screen. When applying changes in the Rule editor, it’s a good idea to always click the “Validate” button to ensure that no placeholders where left unfilled. The Rule Editor however is not checking for rule dependency inconsistencies because other rules still may have to be entered at the time you are editing an individual rule.

 

To ensure the rule dependencies where not corrupted in an offline editing and to resolve conflicts such as dependency loops always click the “Validate” button in the Rules Browser screen. It will run the Validator and display errors if any. Error messages are clickable and will take you to the entity in error. Please note that RuleLab.Net lets you leave an error behind so that you sketch your design without entering the complete expression within every rule. However, it will not let you pass the validation required for deployment. Plus, you will also be getting constant reminders of the pending issues when you load the project.

 

Saving the Rules

 

The “Save Rules” button is your most important button in the RuleLab.Net system. By clicking this button you will write your XML rule file changes into the database. Please click this button often as you are working with the rules.

 

Note that during your Rules Designer online session, the rules are kept in a temporary storage. If you loose your ISP connection or have to reboot your computer before you had a chance to Save the Rules, most of your changes are not lost. Next time you login, the RuleLab.Net will ask you if you want to restore your unsaved Rules document.

 

Undoing Changes

 

If you would like to roll back all the current changes you have made in the Rules Browser and the Rule Editor screens, click the “Undo” button. Your Rules will be restored back to the most recent saved state. Note that you cannot undo changes that have already been saved.

 

Locking the Rules

 

Rules must be locked if you wish to update them. The lock is placed automatically when you save the Rules as long as the current Rules file has not been locked by another user. Rules are automatically unlocked when you log out.

 

If you are browsing the rules with intent to alter them, you should lock the Rules explicitly prior to editing. To lock the Rules file, click the Key icon. The Lock icon will change from the “unlocked” to the “locked” image. To unlock, click the Key icon again.

 

You can always check the status of the Rules lock by clicking Lock icon. Note that the lock is not differentiating between multiple users using the same login ID. However, if the Rules have been locked under a different user ID then an alternative Lock icon will be displayed. You can check who locked the file and ask that user to commit the changes and release the file, or you can unlock it yourself. The system will warn you of the other user lock but will not stop you from unlocking the file and overwriting the other user changes.

 

You can turn file locking off using the Account/Preferences screen. Simply uncheck the corresponding box and re-login into the system.

 

Browsing the Dependencies

 

When entering atoms into a rule you are automatically creating dependencies between atoms. Multiple rules utilizing a set of atoms depend on each other’s output. A combination of atoms and rules yields an implicit dependency structure. RuleLab.Net allows you to browse it as a tree of atoms and rules. Analyzing the dependency tree can help you better understand the flow of your ruleset execution.

 

Atoms set by a rule action depend on atoms in the rule condition. A condition’s atoms in turn depend on atoms set by some other rules or an application. For example, the following 4 rules make the “Amount Due Today” atom depend on “Total Deposit”, “Deposit per Person”, “Number of Guests”, “Package”, and “Purchase Type” atoms:

 

DepositHotelOnly rule:

If Package is HotelOnly

Then set Deposit per Person to 120.00

 

DepositHotelAndCruise rule:

If Package is HotelAndCruise

Then set Deposit per Person to 250.00

 

TotalDeposit rule:

If Deposit per Person is Greater Than 0.00

Then set Total Deposit to Deposit per Person * Number of Guests

 

Advance Reservation rule:

If Purchase Type is Advance Reservation

Then set Amount Due Today to Total Deposit

 

In this example, the “Amount Due Today” atom directly depends on “Purchase Type” and “Total Deposit” which in turn depends on other atoms further down the tree:

 

A rule node parent is an atom set by the rule action. Rule node child nodes are the atoms in the rule input (condition or action source). For example, the “TotalDeposit” rule node parent is the “Total Deposit” atom and its children are the “Deposit per Person” and the “Number of Guests” atoms. Note that the “Number of Guests” atom is only present in the rule’s action source.

 

An atom node parent is a rule containing it in its input. An atom node children are atoms set by another rule.

 

Each node includes a comment indicating the node type. Rule nodes are color coded according to their type. Node types are:

 

A classic example of a circular dependency is updating an atom based on its current value, for example: total = total + fee. A rule with such action will have the “total” atom on both sides – as its parent and a child node. For simplicity the circular dependencies are not expanded. Note that they do not create deadlocks in the rules engine because once fired the rule will not fire again.

 

A circular dependency between rules usually indicates that one of them will not fire until the other fires. It may simply reflect the flow of your ruleset and should not be interpreted as a problem. Also note that the tree builder does not know all the atoms your application is about to populate therefore the rules engine reasoning may not always match the dependency tree logic.

 

You have 2 options for generating the dependency tree: from an atom and from a rule. To display the tree choose the target atom or rule and click the corresponding Display button. If you wish to review a particular rule click its node. The rule text will be displayed in the lower panel. Clicking a rule text atom will switch the tab and take you to that atom definition. To go back to the decision tree click the “Rules” tab.

 

The dependency dialog is activated by the “Dependencies” button of the Rules Browser screen.

To go back to the Rules List click the “Close” button.