Any practical decision modeling tool allows a user to represent a business glossary that specifies all decision variables and thus is at the heart of any decision model. The DMN standard does not explicitly specify a glossary letting different implementation products to compete. So, the modern digital decisioning systems use different constructs to organize their glossaries. In this post and follow-ups I will describe how OpenRules deals with its most important tables of the type “Glossary” which are always the focal point of any decision modeling process.

OpenRules supports a goal-oriented decision modeling approach where the complete decision model is considered as a glossary surrounded by decision tables that implement the logic of all goals and sub-goals:

For instance, here is the notorious decision model “Vacation Days“:

A typical Glossary may look like below:

The first 3 columns are mandatory and should be specified in the following order:

1. Variable Name: contains business names of decision variables used inside different decision tables and test cases
2. Business Concept: decision variables should be categorized by business concepts (objects) to which they belong
3. Attribute: contains technical names of decision variables used for integration with IT systems. They should be the same as the names the attributes in the corresponding JSON structures or Java classes.

It is a good practice to associate the variables that correspond to goals and sub-goals with the decision tables that define their logic. It can be done using the standard Excel hyperlinks that point to the already existing bookmarks in the proper Excel worksheets (see highlighted variables in the above Glossary). It allows a user to quickly jump from the Glossary to the needed decision table directly from Excel. It also can be done from the decision model diagrams automatically built by OpenRules Explorer.

The table “Glossary” may include many optional columns such as Type, Description, Default Value, Used As, Domain, and more. They could be defined in any order.

The column “Type” specifies the types of each decision variable which correspond to standard Java classes like Integer, Double, Boolean, String, Date or other business concepts. This column should be defined unless the corresponding business concepts are defined in Java classes (present in the project classpath).

The column “Description” contains plain English descriptions of all decision variables.

Other optional columns can be effectively used to control input/output of the decision model – I’ll describe the in a separate post.

Using Formulas Inside Glossary

Some decision variable are used only during the decision model execution and do not have corresponding input/output attributes. Such variables can be determined directly in the Glossary using formulas as snippets of valid Java code. To use formulas in the glossary you may put “:=” in the column “Business Concept” and a snippet of Java in the column “Attribute”.

For instance, let’s consider our standard decision model “Vacation Days” and assume that instead of the input variable “Age” it receives a decision variable “Date of Birth”. Let’s also assume that instead of the variable “Years of Service” it receives a decision variable “Start Date of Service”. We do not want to change our decision tables that deal with these variables. Instead, we may define the variables “Age in Years” and “Years of Service” in the glossary in the following way:

Here we put “:=” in the column “Business Concept” that indicates we can use Java snippets in the column “Attribute” to calculate values of variables “Age in Years” and “Years of Service” based on the “Date of Birth” and “Start Date of Service” correspondingly.

Of course, alternatively we could add these variables to the business concept “Employee” and use decision tables to specify their values. However, the use of Java snippets directly in the Glossary makes the decision model more clean and compact (and sometimes more efficient too).

It’s convenient to use formulas in the Glossary to introduce new concepts. For example, we can add the decision variable “Is Minor” to the same decision model but adding only one line to its glossary:

Using Multiple Glossaries Inside the Same Decision Model

Sometimes, when Glossary is too big to keep in one table, OpenRules customers prefer to split it into multiple Glossary tables giving them different names. For instance, out sample project “InsurancePremium” instead of one big Glossary has 3 tables of the type “Glossary”: glossaryDrive for Driver, glossaryCar for Car, and glossaryClient for Client. We even placed them in different Excel files. OpenRules Decision Manager automatically combines them in one Glossary internally.

The Glossary plays a pivotal role for the decision modeling. However, besides the basic functionality described above, OpenRules Glossary provides additional capabilities needed to modern enterprises when they incorporate decision microservices into their decision-making applications. In the upcoming posts I will describe how to use OpenRules glossaries in the following real-world situations:

• When the same decision service is being invoked from different origination systems with different requirements to its input and output;
• When the same decision service is deployed in different cloud-based environments with different security requirements specified by the modern CI/CD pipelines.