DMN is a modeling language and notation for the precise specification of business decisions and business rules using well-defined tabular formats. This popular standard even includes an interchangeable XML format. However, contrary to XML (eXtensible Markup Language), DMN can hardly be called extensible. Today’s DMN allows a user to define complex problem-specific decision modeling constructs using powerful FEEL boxed expressions (that still are being criticized as too close to programming). But DMN doesn’t specify means for building simple domain-specific decision tables that look very natural for business users and hide complex implementation details that actually may require programming.
OpenRules was among the first DMN implementors who from real-world experience knew that easy DMN extensibility is a must feature for domain-specific decision modeling frameworks. So, from the very beginning, OpenRules supports the ability to build custom decision tables. To do it, we decided to explicitly specify column types in the titles of decision tables using such keywords as “Condition” and “Conclusion”. For example, here is a typical DMN decision table in which condition and conclusion columns are specified graphically by colors or borders:
The same table may be presented with explicitly defined column types in the second row like it’s done below in the OpenRules format:
This simple and intuitive format allowed OpenRules along with the standard DMN condition and conclusion columns to introduce custom columns. Here is an example of a specialized decision table used by one of our customers within their special decision modeling environment for spatial decision models:
As you can see, it uses the condition of the custom type “ConditionEntityToCountOfRelatedEntities”. This condition type was specified in the following template:
This template describes the structure of the above custom condition and hides its implementation in the Java method that leverages a standard GIS Java library GeoDatabase. You can read more about this particular implementation here. It is quite easy to similarly create templates for any custom conditions and actions.
What does it take to make DMN extensible? As you can see, not much. However, the ability to explicitly specify column types inside decision tables and to add custom domain-specific types so far still remains a prerogative of OpenRules. For example, there is only one solution (from OpenRules) for the DMCommunity Challenge July-2020. It still may be beneficial for other BR/DM vendors to provide similar implementations giving a lot of flexibility to their users as well.