decisionTable

Decision Table

This library enables the creation and conversion of decision tables in Golang programming language. Inspired by the JBOSS Drools or Camunda DMN Suite. Decions table are commonly used or rather visualized as a table in a UI to represent complex decisions in a more human-readable way. The library can be used as a data representation in Golang for such frontend/UI components.

Each table represents a complex system of rules. Such systems describe a decision for which input, which output is to be generated. The library allows:

• The creation of such rules
• Data-type dependent validation of rule expression
• Converting into a rule-engine format (to finally execute rules)

Table Example

Decision Table Builder (Code Example)

table, _ := CreateDecisionTable().
		SetName("Determine Employee").
		SetDefinitionKey("determineEmployee").
		SetNotationStandard(model.GRULE).
		SetHitPolicy(model.Unique).
		AddInputField("TypeOfClaim", "Claim", model.String).
		AddInputField("ExpenditureOfClaim", "Claim", model.Integer).
		AddOutputField("ResponsibleEmployee", "Employee", model.String).
		AddOutputField("FourEyesPrinciple", "Employee", model.Boolean).
		AddRule("R1").
          AddInputEntry(`"Car Accident"`, model.SFEEL).
          AddInputEntry("<1000", model.SFEEL).
          AddOutputEntry(`"Müller"`, model.SFEEL).
          AddOutputEntry("false", model.SFEEL).
		BuildRule().
		AddRule("R2").
          AddInputEntry(`"Car Accident"`, model.SFEEL).
          AddInputEntry("[1000..10000]", model.SFEEL).
          AddOutputEntry(`"Schulz"`, model.SFEEL).
          AddOutputEntry("false", model.SFEEL).
		BuildRule().
          AddRule("R3").
          AddInputEntry("-", model.SFEEL).
          AddInputEntry(">=10000", model.SFEEL).
          AddOutputEntry("-", model.SFEEL).
          AddOutputEntry("true", model.SFEEL).
		BuildRule().
		Build()

We assume that the frontend will represent a decision table as a kind of table. In case, that a user changes something in the frontend table, we assume that the old decision table representation will be dropped and then rebuild from the new (frontend) table (which was manipulated by the user). By doing so, we don't need any "insert function" for rules/inputs/outputs etc and so it keeps the DecisionTable-Builder simple.

Hit Policies and Collect Operators

A decision table consists of several rules, typically represented as rows. When reading such a row we look at certain input values and deduct a certain result represented by output values.

When using the simplest hit policy "unique" (U), such rules do not overlap: only a single rule must match.

Now consider that we build a decision table with overlapping rules. In other words that means more than one rule may match a given set of input values. We then need one of the alternative hit policy indicators to unambiguously understand the decision logic according to which such rules are interpreted.

Single Decision Tables

Such tables either return the output of only one rule or aggregate the output of many rules into one result. The hit policies to be considered are

• Unique: Rules do not overlap. Only a single rule can match.
• First: Rules are evaluated from top to bottom. Rules may overlap, but only the first match counts.
• Priority: Rule outputs are prioritized. Rules may overlap, but only the match with the highest output priority counts.
• Any: Multiple matching rules must not make a difference: all matching rules must lead to the same output.
• Collect: The output of all matching rules is aggregated by means of an operator:
  • Sum: Sums/Add all outputs of the matching rule’s distinct outputs.
  • Minimum: Take the smallest value of all the matching rule’s outputs.
  • Maximum: Take the largest value of all the matching rule’s outputs.
  • Number: Return the number of all the matching rule’s distinct outputs.

Multiple Result DecisionTable

Multiple result tables may return the output of multiple rules. The hit policies for such tables are:

• Collect: All outputs of the matching rules are combined in an arbitrarily ordered list of all the output entries.
  • List: Collect all outputs of all matching rules in a list of output entries
• Rule Order: All outputs of the matching rules are combined in a list of outputs ordered by the sequence of those rules in the decision table.
• Output Order: All outputs of the matching rules are combined in a list of outputs ordered by their (decreasing) output priority.

Examples

Examples can be found here: Camunda Page

Supported Variable Types

The allowed types of input or output variables differs on the selected notation standard of a decision table:

More Details can be found here:

• GRULE
• Decision Model and Notation DMN (OMG)

Supported Entry Languages

The expresion language defined the functions and comparisons of a single rule entry. It depends on the chosen table notations standard. So far we support the SFEEL Standard partially.

SFEEL INPUT EXPRESSIONS

• Simple Friendly Enough Entry Language (SFEEL)

Converter for Standards/Engines

The following converter are supported, so far:

"Gopher Holds The Rules (GRULE)"

// Convert Table Into Grule Rules
converter, _ := conv.CreateTableConverterFactory().GetTableConverter(model.GRULE, model.GRL)
rules, err := table.Convert(converter)