Skip to Content

Understanding the feature – Priority

This blog is about the feature – priority – provided in the BRM and about how it can be used effectively.

Before we continue on to understanding priorities, let us take a brief glance at rules engine – It is the rules engine (runtime engine) which is responsible for implementing / enforcing / executing the business rules. The engine makes use of the RETE Algorithm, one of the most efficient pattern matching algorithms available. (Please refer my prev. blogs to understand how rules (using schemas) can be invoked – Invoking Business Rules – Part 1 and Invoking Business Rules – Part 2)

In BRM one is allowed to control the order of evaluation of rules by making use of features/properties like priorities and mutual exclusions. Here, a priority is nothing but a way to help you in guiding the order of firing of rules.

Another way of defining the same is – Priority is an attribute of a rule that governs the order in which rules are added to the firing queue. The first rule in the Firing Queue is the one with the highest priority. [Firing Queue is the term which is used to indicate a buffer which maintains the rules whose conditions have been satisfied.]

The value, which can be assigned to a rule, can be any integer value. In NWDS rules perspective, you can set the priority in two ways. Either,

  • A set of predefined numbers as the priority have been provided. You can set any one of these predefined numbers as your priority
  • You can explicitly set the priority to any integer value as required.

Priorities are categorized into five standard levels:

Level Integer Value













Let us consider an example to understand this further –  a rules project having three rules

Rule A has 25000 as its priority

Rule B has 50000 as its priority

Rule C has 0 as its priority

The rule with the highest priority (here, Rule B) is invoked first and so on.. i.e, the order in which rules are invoked will be first Rule B; then Rule A; and finally Rule C.


Let us consider a very simple case scenario –  An employee’s bonus depends on  the band in which he is in and the department in which he is in.

  1. If employee is in Band A – bonus given will be 10% of his base salary.
  2. If the department is engineering then, the bonus is increased by 2%

In this scenario we can observe that for the final bonus to be calculated – first the initial bonus has to be set depending on the band of the employee. And then based on which department the employee is in, the bonus is increased by a certain percentage.

As the order of the rules executed needs to be ensured, we make use of the feature priority – assigning the first rule with a priority higher than the one set for the second rule.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.