In real-world decision models, you may want to write business rules that refer to combinations of two or more individual decision variables called composite decision variables. For example, your business concept “Department” may have a decision variable “Manager” of the type “Employee” which is another business concept with such variables as “Name”, “Salary”, “Gender”, etc.

If you want to compare a salary of an employee with a certain threshold, you may write a condition similar to the one on the left without introducing a new decision variable “Salary of Employee” in the Glossary as it was required in previous releases. Starting with a new OpenRules Release 10.0 the qualifier “of” will automatically recognize that “Salary of Employee” is a composite decision variable.

Let’s consider example “DepartmentsEmployeesLocations” included in the standard OpenRules samples. Here is its Glossary:

As you can see, a Company has multiple Departments, each Department has multiple Employees and only one Manager (also of the type Employee), and each Employee has Name, Age, Salary, etc. and s/he may have residences in multiple Locations. Each Location has a unique Zip Code and address. Here is an example of test data for one Company “ABC” with two departments “Business” and “DevOps”, each of which contains different employees living at multiple locations:

Now let’s see how we could write rules that calculate a total salary of managers of all departments:

We defined a resulting decision variable “Salary of Managers” in the glossary inside business concept “Company” because it belongs to the output of this decision model. However, and intermediate composite decision variable “Salary of Manager of Department” is used only inside the above decision table that iterates over all Departments. Here the qualifier “of” was used twice. Alternatively, instead of “Salary of Manager of Department” we could write “Department :: Manager :: Salary“.

Now let’s say we want to calculate a “Number of High-Paid Employees” for the entire Company and a “Number Of Employees at Selected Zip Code”. It can be done using the following decision tables:

The first table iterates over all Departments and for each Department it iterates over its Employees. The last table additionally iterates over “employee::Locations” (another composite decision variable). Here again the intermediate decision variables “Salary of employee” and “Zip Code of location” don’t have to be explicitly defined in the Glossary.

OpenRules 10.0 also improves the way how element of arrays are shown in the Graphical Debugger while you iterate over them by executing rules in the one by one mode. Here is a snapshot from the Debugger:

In the column “Variable” on the right you can see that the current rule deals with Department that is actually Departments[1] and employee that is Employeess[2] while their current values are shown in the column “Value”. It really helps to understand how complex nested loops actually work.

Thus, newly introduced composite decision variables allows OpenRules customers to naturally express complex business rules defined on interrelated business concepts.