Using Templates to Create Domain-Specific Decision Tables

While DMN-like decision tables are powerful enough to represent business logic for many practical problems, in real-world our customers frequently define new types of decision tables that are specific for their business domains. For example, years ago OpenRules was chosen for a large project that in particular dealt with spatial business rules. Their customers,, suppliers, and operations vary by region, and distance between then affected their decisions. They already used a Geospatial Information System (GIS) in order to explore spatial relationships that leveraged the industry standard Java Topology Suite (JTS) with a powerful Java API.

However, they wanted their business (!) users to natively define and maintain complex spatial rules without becoming experts in specific Java API. This 2014 presentation describes how OpenRules helped this customer to create a Spatial Decision Table template allowing stakeholders with no GIS training to use plain English in familiar Decision Model spreadsheets to define spatially aware business rules without any additional software.

OpenRules always supported a very powerful rules templatization mechanism for creation of custom domain-specific decision tables of virtually any complexity. It naturally connects graphical rules with underlying Java packages. This month we advanced this mechanism by introducing the new table type “Template” that allows our customers to easily add domain-specific conditions and columns to the standard DMN-like decision tables. In this post I will demonstrate these new facilities using the spatial business rules presented in the DMCommunity Challenge July-2020.

Business analysts of our customer came up with the following format of the decision table they wanted their users to use while they specify different spatial relationships between various geographical entities:

As you can guess, this multi-hit decision table can check various conditions that may positively (+) or negatively (-) affect the Spacial Significance Score. This is the standard OpenRules multi-hit decision tables defined by the keyword “DecisionTableMultiHit” in the top-left corner. It uses the standard column “Conclusion” and a special (domain-specific!)  column “ConditionEntityToEntity” that is not a part of the standard OpenRules. To support this type of conditions, we added a new table’s type “Template“:

After the keyword “Template” the first row contains the name of the column that will be used as a condition or as a conclusion/action inside the table created based on this template.
The second row contain a snippet of Java code that implements this column. This particular template simply call the static method “conditionEntityToEntity” of the Java class “GeoDatabase”:

GeoDatabase.conditionEntityToEntity (decision,mainEntityType, relationship, relatedEntityType, oper, value)

where parameters “mainEntityType”, “relationship”, “relatedEntityType”, “oper”, and “value” are described in the 3rd row, while the parameter “decision” is the default parameter available in any standard OpenRules decision table. It’s a responsibility of the Java class GeoDatabase for any two entities to check if they satisfied the conditions of the above rules. How it’s done is hidden from a user who writes such rules, but this user may freely use almost “natural language” expressions like “HRR+5” (meaning within 5 mi within this HHR entity) or “HRR Is Among 25 Closest To a Hospital”.

Another type of spatial decision tables dealt with the business rules that specify the Spacial Significance Score based on the number (count) of entities related to the main entity:

For example, the rule #3 checks if there is at least 1 Hospital within 5 mi from the Airport. To support this new type “ConditionEntityToCountOfRelatedEntities” of conditions, we needed to create the following template:

Like in the previous template, it invokes the GeoDatabase’s method “conditionEntityToCountOfRelatedEntities” hidden from users that create such decision tables.

To include these templates in our standard decision project called “SpatialRules”, we created the Environment table that looks as follows:

It contains an include-statement that refers to the file “DecsionTableSpatialTemplates.xls” with the above two template tables. To access the Java class GeoDatabase that we developed as a part of the the Java package “com.openrules.spatial”, this table contains an “import.java” statement that refers to “com.openrules.spatial.*”.

The Java package “com.openrules.spatial” was created using the latest version of the open source GIS system that was downloaded automatically from the Maven repository based on the following dependencies added to the “pom.xml”:

You will find all implementation details in the project “SpatialRules” included in the OpenRules Decision Manager v. 8.2.1.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.