DMN Modeling Guide - Version 8.1When a DMN model is created, it already includes one decision requirement diagram ( ) of the same name as the model. Figure 2.3. DMN model with diagram

ACTICO Platform - Modeler

DMN Modeling Guide

Version 8.1.8

ACTICO GmbH

www.actico.com

DMN Modeling Guide: Version 8.1.8

DMN Modeling Guide

Copyright © ACTICO GmbH iii

Table of Contents

1. Introduction ........................................................................................................................ 1

2. Decision Requirements .................................................................................................... 2

2.1. Creating a Decision Model ................................................................................................. 2

2.2. Opening an Existing Decision Model (DMN File) .................................................................. 2

2.3. Decision Requirements Diagrams ...................................................................................... 32.3.1. Adding New Elements to a Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3.2. Adding Existing Elements to a Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3.3. Adding Elements from other DMN Models to a Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3.4. Removing Elements from a Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3.5. Renaming Elements on a Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4. Decisions, Input Data and Information Requirements ........................................................ 72.4.1. Decision Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4.2. Input Data Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.5. Data Types ....................................................................................................................... 9

2.6. Item Definitions .............................................................................................................. 10

2.7. Business Knowledge Models ............................................................................................ 112.7.1. Business Knowledge Model Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.8. Knowledge Sources ......................................................................................................... 132.8.1. Knowledge Source Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.9. Text Annotations ............................................................................................................ 142.9.1. Text Annotation Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.10. Organizational Units ...................................................................................................... 14

3. Decision Logic .................................................................................................................. 17

3.1. Boxed Expressions .......................................................................................................... 19

3.2. Literal Expressions .......................................................................................................... 193.2.1. Literal Expression Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3. Contexts ......................................................................................................................... 213.3.1. Context Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3.2. Context Entry Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.4. Decision Tables ............................................................................................................... 223.4.1. Decision Table Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.4.2. Input Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.4.2.1. Input Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.4.2.2. Input Entry Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.4.3. Output Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.4.3.1. Output Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.4.3.2. Output Entry Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.4.4. Entering Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.4.5. Hit Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

DMN Modeling Guide

Copyright © ACTICO GmbH iv

3.5. Invocations ..................................................................................................................... 273.5.1. Invocation Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.6. Lists ............................................................................................................................... 283.6.1. List Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.7. Relations ........................................................................................................................ 293.7.1. Relation Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.7.2. Relation Column Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.7.3. Relation Row Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.8. Function Definitions ........................................................................................................ 313.8.1. Function Definition Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4. Validation and Problem Reporting .............................................................................. 33

5. Imports and References to other DMN Models ......................................................... 34

5.1. Importing a DMN Model .................................................................................................. 34

5.2. Imported Elements on Decision Requirements Diagrams .................................................. 355.2.1. Unresolved Model Elements on Decision Requirements Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.3. Use of Imported Information Items (Decisions, Input Data, Business Knowledge Models).............................................................................................................................................. 36

5.4. Use of Imported Item Definitions .................................................................................... 36

6. Decision Services ............................................................................................................ 37

7. Executing and Testing .................................................................................................... 39

7.1. Prerequisites ................................................................................................................... 39

7.2. Execution of a Decision Service ....................................................................................... 397.2.1. Automatically generate Services in a Rule Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407.2.2. Manually create a Rules Service for a DMN Decision Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427.2.3. Requested Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447.2.4. Known Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7.3. Execution of a Decision ................................................................................................... 44

7.4. Execution of a Business Knowledge Model ...................................................................... 44

7.5. Testing ........................................................................................................................... 44

7.6. Type Mapping ................................................................................................................. 45

8. Expression Language - FEEL ......................................................................................... 48

8.1. Datatypes ....................................................................................................................... 488.1.1. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488.1.2. Booleans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488.1.3. Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488.1.4. Dates and Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

8.1.4.1. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

DMN Modeling Guide

Copyright © ACTICO GmbH v

8.1.4.2. Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498.1.4.3. Date and Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

8.1.5. Durations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498.1.5.1. Days and Time Duration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498.1.5.2. Years and Month Duration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

8.1.6. Null . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

8.2. Expressions .................................................................................................................... 508.2.1. Qualified Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518.2.2. Arithmetic Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518.2.3. Comparisons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528.2.4. Logical Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528.2.5. If Then Else Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538.2.6. Function Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538.2.7. Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538.2.8. In Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548.2.9. Between Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548.2.10. List Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548.2.11. Context Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558.2.12. Path Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558.2.13. Filter Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568.2.14. Unary Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568.2.15. Some and Every Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578.2.16. For Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578.2.17. Instance Of Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588.2.18. User-Defined Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588.2.19. External Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598.2.20. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

8.3. Operand Types for Expressions ....................................................................................... 61

8.4. Expression Precedence ................................................................................................... 63

8.5. Comments ...................................................................................................................... 64

9. FEEL Function Reference ............................................................................................... 65

9.1. Conversion Functions ...................................................................................................... 65

9.2. Boolean Functions .......................................................................................................... 66

9.3. String Functions .............................................................................................................. 67

9.4. List Functions ................................................................................................................. 67

9.5. Numeric Functions .......................................................................................................... 70

9.6. Sort Function .................................................................................................................. 70

Chapter 1. Introduction

Copyright © ACTICO GmbH 1

Chapter 1. IntroductionACTICO Modeler allows to define decision models using the DMN 1.1 standard (Decision Model and Notation).

The Decision Model and Notation (DMN) is a standard defined by the Object Management Group (OMG). Itdefines a business-friendly notation to describe how decisions are made. It also defines a way to express theactual decision logic used to make decisions. This allows DMN to be used to design and automate decision-making.

DMN consists of several layers:

Decision Requirements DiagramsDecision requirements diagrams (DRD) illustrate business decisions, the information required to makethese decisions and their dependencies. DRDs document how decisions are made and thus present aunique and new way to analyze and optimize decision-making within organizations.

Decision LogicDMN allows to define the actual decision logic of individual decisions by using so-called "boxedexpressions". This includes but is not limited to decision tables.

Expression LanguageThe expressions and conditions of the DMN decision logic are written in an expression language namedFEEL (Friendly Enough Expression Language). It is a business-friendly simple expression languagespecifically tailored for decisioning.

ACTICO Modeler fully supports all three parts of the DMN standard. You can create DMN models with multipledecision requirement diagrams (DRD), describe the decision logic using all boxed expressions defined by DMNand use the full FEEL expression language.

The DMN modeling support in ACTICO Modeler is separate from the classical rule modelingin order to be fully compliant with the standard. However, rule models and DMN models caninteroperate during execution. This interoperability is described in the Chapter 7, Executing andTesting section of this guide.

Chapter 2. Decision Requirements



2.1. Creating a Decision Model

A decision model or "DMN model" in ACTICO Modeler always resides within a DMN project. Thus, the easiestway to start a new DMN model is to create a DMN project.

Select File > New > DMN Project from the menu. Enter the name of the project in the dialog box and click Finish.

Figure 2.1. Create a new DMN project

Afterwards, you will find the DMN project ( ) in the Project Explorer and the DMN Model ( ) inside of it.

Figure 2.2. Created DMN project

You should not have more than one model in a project. If you need more than one model,create another DMN project. This then later allows the models to be changed and deployedindependently from each other.

2.2. Opening an Existing Decision Model (DMN File)

If you already have a DMN model file available, you can easily import this into Modeler, like this:



1. Drag the existing DMN file from e.g. Windows Explorer or your Desktop onto an existing DMN project in theProject Explorer of Modeler. See Creating a Decision Model if you don’t have a DMN project yet.

2. Modeler will ask if it should copy the file. Click OK.

3. Now the existing DMN model is displayed within the DMN project and can be opened.

If the DMN model was created manually or with other modeling tools, it will not display decision requirementsdiagrams. However, you can easily add diagrams to existing models and populate them with existing elements.See the following sections on how that works.

You can drag&drop multiple DMN models into a DMN project like this in one go. Alternativelyto drag&drop you can use the File > Import… dialog and then the File System option from theGeneral category.

2.3. Decision Requirements Diagrams

A decision requirements diagram (DRD) is a business-friendly illustration of decisions and their dependencies.It can be used to describe human or automated decision-making or a mix thereof.

When a DMN model is created, it already includes one decision requirement diagram ( ) of the same nameas the model.

Figure 2.3. DMN model with diagram

You can add additional diagrams by right-clicking the DMN model and selecting New Element > DecisionRequirements Diagram.

Figure 2.4. Create a new diagram

To open a diagram, double-click on it in the Project Explorer.



Figure 2.5. The decision requirements diagram editor

A decision requirements diagram consists of the following elements:

DecisionA decision represents the act of determining an outcome from several inputs, using decision logic.Decisions are represented as rectangles.

Input DataInput data denotes the information needed as input by one or multiple decisions. Input data elements arerepresented as boxes with rounded sides left and right.

Information RequirementInformation requirements between input data and decisions are represented as arrows connecting theelements. The information at the end of the arrow is needed by the element at the tip of the arrow.Information requirements can also be drawn from one decision to another. This means that the result ofone decision is needed for the other decision.

Information requirements cannot be circular. For example, you cannot have a decision A thatneeds the outcome of decision B which again directly or indirectly requires the outcome of A. Ifyou have a cycle in your DRD, the decision making won’t work.

Business Knowledge ModelA business knowledge model represents reusable business logic. Technically, it is a function with optionalparameters (inputs) that can be invoked from decisions or other business knowledge models. Businessknowledge models are represented as rectangles with cut-off corners.



Knowledge RequirementKnowledge requirements are like information requirements, but are used to indicate the invocation of abusiness knowledge model. They are represented as arrows with a dotted line pointing from the businessknowledge to the decision or business knowledge model invoking it.

Knowledge SourceKnowledge sources represent authorities for a decision, for a business knowledge model or for anotherknowledge source. These can e.g. be policies, regulations or people that have an influence on the contentsof the element. Knowledge sources are represented as rectangles with a wavy line at the bottom.

Authority RequirementAuthority requirements are dotted lines with a solid circle at the top. They are drawn between knowledgesources and other elements to indicate that the knowledge source has an influence there, i.e. is an"authority" for it.

Text AnnotationText annotations add additional descriptive information to the DRD. A text annotation can be connectedwith an association to either one or multiple input data elements, decisions, business knowledge modelsor knowledge sources. A text annotation is a rectangle without the right edge.

AssociationAssociations are dotted lines. They connect a text annotation to an input data, decision, businessknowledge model or knowledge source.

A decision requirement diagram often has a tree-like structure with the main decision at the top,broken down into several layers of sub-decisions and the input data used for the sub-decisionsat the bottom. Every so often, it turns out to be more complicated than that and the diagrambecomes more of a network. You can draw the diagram in any way you like to help visualize thedecision-making so that it makes sense to you.

2.3.1. Adding New Elements to a Diagram

To add a new element to a diagram, click on the desired element in the palette, then click on the diagramwhere you want the new element to appear. Finally enter the name for the new element.

This is how you add decisions, input data, business knowledge models, and knowledge sources to the diagramand to the model. All elements of a DMN Model can also be seen in the Project Explorer.

2.3.2. Adding Existing Elements to a Diagram

You can always add existing elements to a diagram that does not yet show them. Simply drag the elementsfrom the model tree in the Project Explorer onto the diagram. You can also select multiple elements in themodel tree and then drag all of them to the diagram.

Alternatively, you can search and then select existing elements from the lower section of the palette and thenadd them to the diagram from there.



Figure 2.6. Searching for existing elements

2.3.3. Adding Elements from other DMN Models to a Diagram

You can also drag and drop elements from the Project Explorer to the diagram when they live in another DMNmodel. This also adds the elements to the diagram, but they are now references to the original elements,indicated by small grey arrows on their symbols.

If necessary, Modeler will ask you to add an import first. This is because you can only reference elements fromother DMN models when the other model is imported.

2.3.4. Removing Elements from a Diagram

When you want to remove an element from a diagram, you simply select it and press Del or Backspace. Thiswill remove the element from the diagram, but not from the model. You will still find the element (decision,business knowledge model or else) in the model tree in the Project Explorer. And you can re-add it to thediagram again.

If you want to remove an element from the model completely, you can select it on the diagram and pressCtrl+D.

Both options Delete from Diagram and Delete from Model can also be found in the context-menu.

Note however that requirements (i.e. arrows) cannot be removed from only a diagram likedescribed above. When you delete a requirement, it is always removed from the model and thusalso from all other diagrams.



2.3.5. Renaming Elements on a Diagram

To rename an existing element, select it on the diagram or in the Project Explorer and press F2.

Input data, decision and business knowledge model elements have a variable name, which is bydefault the same as the element name. If name and variable name are the same, the renamingoperation will also change the variable name. If the name and variable name are different, therenaming operation will only change the name.

2.4. Decisions, Input Data and Information Requirements

You add a new decision to the diagram (and the model) by selecting the Decision tool ( ) from the paletteand then clicking on the canvas of the diagram where you want to place the decision. Then you enter the nameof the decision and press Enter.

Figure 2.7. A decision on a DRD

Input data is added in a similar fashion. Select the Input Data tool ( ) and click on the canvas, then specifythe name of the input data element.

Figure 2.8. An input data element on a DRD

Decisions and input data names must be unique within a model. They can contain upper- andlowercase letters and digits. They can also include single spaces, dashes (-), plus signs (+),asterisks (*), slashes (/), apostrophes ('), dots (.) and ampersands (&). They must not start with aFEEL language keyword.

In order to illustrate the fact that a specific decision needs an input data element or the result from anotherdecision, you connect the two with an information requirement arrow.

You can do this using the Information Requirement tool ( ) from the palette. Select the tool, then click onthe source element (input data or decision) and hold the mouse button down. You can now move the arrow tipto the target element and then release the mouse button.

Figure 2.9. Information requirement arrow



If you like to change either the source or the target of an existing arrow, you can drag the end or the tip of thearrow to another element.

2.4.1. Decision Properties

Decisions have additional properties besides their names. These properties can be viewed and edited in theProperties view when the decision is selected. Several tabs are used to group properties together.

Figure 2.10. Decision Properties view

NameThis is the name which is also shown on the DRD. If the name and variable name are the same, a renamingoperation will also change the variable name.

QuestionThis is the business question that is answered by the decision. This helps to more precisely communicatethe meaning and scope of a decision to other readers of the DMN model. The question can be any text inany language.

Allowed AnswersThis specifies the allowed answers the decision may give as a result. If this is specified in a precisemanner, then this list can later be used to specify the allowed values for the information item.

VariableThis is the name of the information item that stores the result of the decision. This is the identifier usedin expressions to refer to the result of the decision. By default, this is the same as the name, but can bechanged to something else.

TypeThis is a reference to an item definition or a built-in FEEL data type that describes the type of the result(information item) of the decision.

Decision OwnersThis is a list of the organizational units that own the decision, i.e. are responsible for its definition.Organizational units need to defined first on the DMN model in order to be referenced here.

Decision MakersThis is a list of the organizational units that make the decision, on a regular basis as part of their work.Organizational units need to defined first on the DMN model in order to be referenced here.

LabelThis is a short human-readable description for the decision.

DescriptionThis is the full description for the decision.

2.4.2. Input Data Properties

Input data elements also have additional properties besides their names.

These properties can be viewed and edited in the Properties view when the input data element is selected.Several tabs are used to group properties together.



Figure 2.11. Input Data Properties view


VariableThis is the name of the information item that stores the value of the input data element. This is theidentifier used in expressions to refer to the input data element. By default, this is the same as the name,but can be changed to something else.

TypeThis is a reference to an item definition that describes the type of the input data element or - moreprecisely - of the information item holding the value of the input data element.

LabelThis is a short human-readable description.

DescriptionThis is the full description for the input data element.

2.5. Data Types

Every information item (e.g. input data, decision result, expression result) can have a type specifying the kindof values it can hold. The type is a reference to either a basic data type (from FEEL) or to an item definition (i.e.a custom data type).

The basic data types defined by the FEEL expression language are:

feel:numberA number is a decimal number.

feel:booleanA boolean is a logical value of either true or false.

feel:stringA string is a sequence of characters, or - in other words - some text.

feel:dateA date is a value consisting of a year, month and day.

feel:timeA time is a value consisting of hours, minutes, seconds, optionally including fractions of a second, atimezone or a timezone offset from GMT.

feel:date and timeA date and time value is the combination of a date and a time value. Since spaces are not allowed for typenames, use feel:dateTime for a type reference to this type.

feel:days and time durationA days and time duration is a value specifying a time period in days, hours, minutes, seconds. Since spacesare not allowed for type names, use feel:dayTimeDuration for a type reference to this type.



feel:years and months durationA years and month duration is a value specifying a time period in years and months. Since spaces are notallowed for type names, use feel:yearMonthDuration for a type reference to this type.

Note that DMN allows every information item, decision or expression result to be null.Consequently, the possible values for each of the data types above always include the nullvalue.

2.6. Item Definitions

Item definitions are custom types for information items that you can use in addition to the basic data typesfrom FEEL.

In order to create an item definition, right-click on the DMN model and select the New Element > ItemDefinition menu entry.

Figure 2.12. Create a new Item Definition

When you select the newly created item definition, the Properties view shows its settings.

Item DefinitionThe first column shows the name of the item definition. This name must be unique within the DMN model.

Type RefThis is the type of the item definition. This can be either one of the basic FEEL data types or another itemdefinition. If the item definition has sub-item definitions (see below), then this type is empty.


DescriptionThis is the full description for the item definition.

Allowed ValuesThis is a comma-separated list of allowed values. This is used to express the fact that an information itemwith that item definition shall only hold a value that is listed here. Allowed values can also be conditionslike <10 or in [2..5]. In general, allowed values are FEEL unary tests.

Is CollectionThis specifies if the information item holds just one value (No) or multiple values of the same kind (Yes).



Item definitions can also consist of multiple item components in order to define structured data. Forexample, an item definition Customer can have an item component named Address which can again have itemcomponents like Street, Zip, City etc.

To create an item component, click on the plus ( ) button.

Figure 2.13. Item definitions with item components

Every item component is also an item definition, i.e. it has a name, a type, a description and it can specifyallowed values and whether it is a collection. The name of an item component must be unique within the itemdefinition that contains the item component.

2.7. Business Knowledge Models

You add a business knowledge model to the diagram by selecting the Business Knowledge Model tool ( )from the palette and then clicking on the canvas of the diagram where you want to place the businessknowledge model. Then you enter the name of the business knowledge model and press Enter.

Figure 2.14. A business knowledge model on a DRD

A business knowledge model is some reusable logic that can be called from decisions or other businessknowledge models. This kind of reuse must be shown on the diagram with a knowledge requirement thatpoints from the business knowledge model to the element using it.

Select the Knowledge Requirement tool ( ), then click on the source element (business knowledge model)and hold the mouse button down. You can now move the arrow tip to the target element and then release themouse button.



Figure 2.15. Knowledge requirement arrow

Business knowledge model names must be unique within a model. They can contain upper-and lowercase letters and digits. They can also include single spaces, dashes (-), plus signs (+),asterisks (*), slashes (/), apostrophes ('), dots (.) and ampersands (&). They must not start with aFEEL language keyword.

2.7.1. Business Knowledge Model Properties

When you select a business knowledge model, the Properties view shows its settings.

Figure 2.16. Business Knowledge Model Properties view


VariableFrom the perspective of FEEL, a business knowledge model is a function. This is the name of theinformation item that stores the function of the business knowledge model. It is the name of that functionwhich is used to invoke the business knowledge model. By default, this is the same as the name, but canbe changed to something else.

Return TypeThis is a reference to an item definition or a built-in FEEL data type that describes the type of theinvocation result (information item) of the business knowledge model. (This return type is propagated tothe boxed expression that is the body of the business knowledge model’s function definition.)


DescriptionThis is the full description for the business knowledge model.



2.8. Knowledge Sources

You add a knowledge source to the diagram by selecting the Knowledge Source tool ( ) from the paletteand then clicking on the canvas of the diagram where you want to place the knowledge source. Then you enterthe name of the knowledge source and press Enter.

Figure 2.17. A knowledge source on a DRD

Knowledge sources can be connected to decisions, business knowledge models or other knowledge sources toindicate their "authoritative" influence on it.

Select the Authority Requirement tool ( ), then click on the source element (knowledge source) and holdthe mouse button down. You can now move the arrow tip to the target element and then release the mousebutton.

Figure 2.18. Authority requirement arrows

2.8.1. Knowledge Source Properties

When you select a knowledge source, the Properties view shows its settings.

Figure 2.19. Knowledge Source Properties view

NameThis is the name which is also shown on the DRD.



Location URIThis is an optional URI that is a reference to the knowledge source information.


DescriptionThis is the full description for the knowledge source.

2.9. Text Annotations

To add a text annotation to a DRG, click on the ( ) symbol in the palette. Then click on the DRG node thatshould be connected with the new text annotation.

2.9.1. Text Annotation Properties

When you select the text annotation in the DRG, the Properties view shows its settings.

Figure 2.20. Text Annotation Properties view

TextThe descriptive text of the text annotation that is displayed in the DRG.

Text formatThe text format. Use mime-type format. Default is "text/plain".


DescriptionThis is the full description for the text annotation.

To connect a text annotation with an additional decision, input data, business knowledge model or knowledge

source, click on the ( ) symbol in the palette. Then click on the text association node in the DRG and dragthe association to the target node.

2.10. Organizational Units

A DMN model can define organizational units. They can be used to define the decision owners and decisionmakers for decisions.



Organizational units cannot be nested within other organizational units. Tree structures are notallowed by the DMN standard.

In order to create an organizational unit, right-click on the DMN model and select the New Element >Organizational Unit menu entry.

Figure 2.21. Create a new Organizational Unit

When you select the newly created organizational unit, the Properties view shows its settings.

Figure 2.22. Organizational Unit Properties view

NameThis is the name which is also shown in the settings for a decision.

URIThis is an optional URI that is a reference to a descriptive information about this organizational unit.



Decisions made

List of decisions that are made by this organizational unit. Use the ( ) icon to add a decision or the

( ) icon to remove a selected decision.

Decisions owned

List of decisions that are owned by this organizational unit. Use the ( ) icon to add a decision or the

( ) icon to remove a selected decision.


DescriptionThis is the full description for the organizational unit.

Chapter 3. Decision Logic


Chapter 3. Decision LogicOnce you have defined decisions or business knowledge models on decision requirements diagrams, you canalso specify the actual logic used to make the individual decisions.

The decision logic editor automatically opens when you double-click on a decision or a business knowledgemodel in a decision requirements diagram. Alternatively, you can double-click on such an element in theProject Explorer.

The tab at the top of each editor shows the name and icon of the element whose decision logic is displayed,e.g. here a business knowledge model:

Figure 3.1. Decision logic editor

Every decision logic editor features a palette of so-called "boxed expressions". Their name simply comes fromthe fact that they are all visually represented as rectangles.



Figure 3.2. Palette of boxed expressions

Any such boxed expression can be selected from the palette and then added to the decision logic by clickingon the location where it should be added. A highlight indicates where it will be added or what it will replacebefore you click.

The overall decision logic is created by nesting the boxed expressions into one another.

• List, context, relation, function definition and function invocation can contain other boxed expressions ofany type

• A decision table can only contain literal expressions or unary tests

• A literal expression cannot contain nested boxed expressions

For example, here a decision table is added into a context entry.

Figure 3.3. Context without Decision Table

Figure 3.4. Context with inserted Decision Table

You can always press Ctrl+Z to undo or Ctrl+Y to redo.



Each boxed expression has at least one Properties view that can be used to change the settings for this boxedexpression. Additionally, other nested cells or boxes may have Properties views to change the nested settings.The boxed expression, its cells or nested boxed expressions can be selected with the keyboard or by clickingwith the mouse.

To expand a selection to the parent boxed expression use F8.

3.1. Boxed Expressions

The following table shows the different boxed expressions available.

Literal ExpressionA literal expression is a box containing just one expression. It is the simplest boxed expression and itsresult is simply the result of the expression in the box. Literal expressions are used everywhere. Basically,almost every white box within the other boxed expressions is a literal expression.

ContextA context is displayed as a table with two columns with an optional result box at the bottom. A contextallows to define names for partial or intermediate results. This way, contexts allow your decision logic tobe broken down into smaller steps.

Decision TableA decision table is a tabular representation of multiple rules to make a decision. The rules in a decisiontable are numbered starting from 1. Rules fire based on the values of one or multiple inputs (blue inputcolumns). In its simplest form, the rules (= rows or columns, depending on the orientation) of the decisiontable define different conditions for the inputs and if all of a rule’s conditions are fulfilled, the decisiontable produces the output values specified in one or multiple output columns (red) of that rule. However,depending on the hit policy of the decision table, its behavior may be different from that.

InvocationAn invocation allows to call a business knowledge model or a function, pass parameters and receivethe result. Invocations thus enable the reuse of logic that is available elsewhere in business knowledgemodels or within custom functions. The result of the invocation is the value returned from the businessknowledge model or function.

ListA list is used to represent multiple values, instead of just one. It is simply represented as a vertical list ofboxed expressions which are numbered starting from 1.

RelationA relation is also a list, but every element of the list is a context with the same context entries. The contextentry names are displayed at the top in green. Elements are vertically listed and numbered just like with anormal list. Every row is an element and specifies the values for its context entries in its columns.

Function DefinitionA function definition allows to define your own custom function that can then be invoked later from literalexpressions using FEEL or with an invocation boxed expression. The function definition boxed expressionconsists of two cells: a parameter list in the top cell and the body of the function in the bottom cell.

3.2. Literal Expressions

A literal boxed expression is a box containing just one expression.



Figure 3.5. Literal Expression inside a decision

In order to enter an expression, just double-click into the white box. An in-place editor is opened and you canstart typing.

Figure 3.6. Editor for Literal Expression

The literal expression must be a FEEL expression. The syntax and semantics of the FEEL language are describedin section "Chapter 8, Expression Language - FEEL".

Instead of double-clicking, you can also select the literal expression box with a single-click orby navigating there with the cursor keys and just start typing. That’s especially handy when youhave to type in many values in e.g. a decision table. You don’t have to constantly switch from thekeyboard to the mouse.

In order to enter a FEEL expression over multiple lines, press Alt+Enter to enter a line break.

3.2.1. Literal Expression Properties

When you select a literal expression, the Properties view shows its settings.

Figure 3.7. Literal Expression Properties view



TypeThe type of the result value of the literal expression. This is an item definition or a FEEL data type.


DescriptionThis is the full description for the literal expression.

3.3. Contexts

A context boxed expression is a box with two columns and one or multiple rows. Each row is a context entry.The first column is green and contains the name of a context entry. The second column is white and containsthe boxed expression to calculate the value for the context entry.

Figure 3.8. A context with one empty context entry

You add rows with the buttons at the top of the decision logic editor. The first button adds a rowbefore the currently selected row, while the second button adds it after the currently selected row. Rows are

removed with the button.

Figure 3.9. A context with two context entries

The result of a context is the set of all context entries. However, a context can have an optional result boxacross both columns at the bottom. In that case, the result of the whole context is just the result of that resultbox.

You add the result box with the button.

Figure 3.10. A context with two context entries and a result box

To remove the result box again, select it and click the button.

To rearrange context entries, drag them with the mouse up or down.

3.3.1. Context Properties

To display the Properties view of the context, select a context entry (green) and press F8. This selects thewhole context.



Figure 3.11. Context Properties view

TypeThe type of the context value. This is an item definition or a FEEL data type.


DescriptionThis is the full description for the context.

3.3.2. Context Entry Properties

When you select a context entry (green), the Properties view shows its settings.

Figure 3.12. Context Entry Properties view

NameThe name of the context entry.

TypeThe type of the context entry value. This is an item definition or a FEEL data type.


DescriptionThis is the full description for the context entry.

3.4. Decision Tables

A decision table boxed expression is a table with one or multiple input columns (blue) and one or multipleoutput columns (red).

Every row (white) in the table is a rule.

Each rule defines conditions for the inputs and if all of a rule’s conditions are satisfied, the decision tableproduces the output values specified in the output columns for that rule.



The inputs are checked against optional allowed values (grey). The produced output values are also checkedagainst optional allowed values (grey).

If no rule applies, the decision table can return a default output value.

The hit policy shown in the top left cell determines - among other things - if only one result is returned, or ifmultiple matching rules produce results.

Figure 3.13. Decision Table with orientation "rules as rows"

A decision table defines an orientation of rules which can be either "rules as rows" or "rules as columns". Theorientation only affects the presentation. If "rules as columns" is chosen, input columns (blue) and outputcolumns (red) become rows. And every rule becomes a column (white) in the table. The hit policy is shown inthe bottom left cell.

Figure 3.14. Decision Table with orientation "rules as columns"

The following sections describe the decision table with orientation "rules as rows", which is thedefault orientation. The orientation can be changed in the Properties view of the decision table.

All parts of a decision table are described in more detail in the following sections.

You add input or output columns with the buttons. The first button adds a column to the left of theselected column, while the second button adds it to the right. Input or output columns are deleted with the

button. It is also possible to rearrange the columns by dragging them with your mouse.

You add rules with the buttons. The first button adds a rule before the currently selected row, while

the second button adds it after the currently selected row. Rules are removed with the button. It is alsopossible to rearrange the rules by dragging them with your mouse.



3.4.1. Decision Table Properties

To display the Properties view of the decision table, select the hit policy cell.

Figure 3.15. Decision Table Properties view

TypeThe type of the decision table result value. This is an item definition or a FEEL data type.

OrientationThe display orientation of the decision table, which can be either "rules as rows" or "rules as columns".


DescriptionThis is the full description for the decision table.

3.4.2. Input Columns

When you add a decision table boxed expression, it is either empty or pre-populated with input columns fromincoming information requirements in the DRD.

The top cells of the input columns are input expressions. They define the inputs for the decision table. Each ofthese can be any FEEL expression, but often they are simply the information items in scope.

Below every input expression is a cell that can be used to specify the allowed values for that input. Allowedvalues can be listed separated by comma, but also ranges like [2..10] or conditions like <5 are possiblehere.

Allowed values are specified as a unary test which you can read about in the FEEL section aboutUnary Tests.

It is possible to rearrange the input columns by dragging them with your mouse.

3.4.2.1. Input Properties

An input column (blue) has properties.

TypeThe type of the input. This is an item definition or a FEEL data type.


DescriptionThis is the full description for the input.



3.4.2.2. Input Entry Properties

An input entry is a FEEL unary test and has properties.


DescriptionThis is the full description for the input entry.

3.4.3. Output Columns

The output columns define what data the decision table will return as a result. The top cells of the outputcolumns contain the names of the results.

A decision table needs at least one output column. In this case the result has the type of a single value. Ifa decision table has multiple output columns, its result type is a context with the output column names ascontext entry names. If the hit policy of a decision table allows multiple results, the result is a list of singlevalues (if one output column is defined) or a list of contexts, which is a relation (if multiple output columns aredefined). Note that there are special cases where a decision table produces the result null, e.g. if hit policy"C : Collect" or "C# : Collect (Count)" is used and no rule fires.

If there is only one output column, the name can be left empty. If there are multiple outputs, theresult is a context with the outputs as context entries.

Below every output column name is a cell that can be used to specify the allowed values for that output.Allowed values can be listed separated by comma, but also ranges like [2..10] or conditions like <5 arepossible here.

Allowed values are specified as a unary test which you can read about in the FEEL section aboutUnary Tests.

Some hit policies use the order of allowed values to decide the sort order of the returneddecision table result. The leftmost allowed value has highest precedence. If the decision table hasmultiple output columns, columns to the left take precedence over columns to the right.

It is possible to rearrange the output columns by dragging them with your mouse.

3.4.3.1. Output Properties

An output column (red) has properties.

NameThe name of the output. Can be empty, if there is only one output.

TypeThe type of the output. This is an item definition or a FEEL data type.

Default ValueA default value, when specified, is used as the result if no rule fires. It can be any FEEL expression.


DescriptionThis is the full description for the output.

3.4.3.2. Output Entry Properties

An output entry is a FEEL expression and has properties.



TypeThe type of the output entry. This is an item definition or a FEEL data type.


DescriptionThis is the full description for the output entry.

3.4.4. Entering Rules

To specify a rule, you must

1. enter the conditions (input entries) for when the rule shall fire. An input entry may be a list of unary tests.

2. enter values for the outputs (output entries) returned when the rule fires. An output entry may be a FEELexpression.

The conditions are entered into (white) cells of the input columns (blue). Often, these are simply the values theinputs must have for the rule to fire (i.e. 17, "EUR", false). But it may also be checks if a value is "less than"something (i.e. <10), "lies in" a specific range (i.e. [1..10]) or is contained in a list of values (i.e. listOfIds).If the value of an input is irrelevant for a particular rule, enter a - into the cell. - is inserted as default forinput entries.

A qualified name is a valid unary test. If the value that is assigned to the qualified name is a listof values of a single value, the qualified name can be used as input entry. If the value of the inputexpression is contained in the list of a values or it is equal to the single value, the input matches.

Figure 3.16. Editor for rule cell

You can also list multiple values or checks in one cell, separated by commas. The condition is true if the inputmatches any one of these checks. You can think of the comma as the word 'or'.

To negate the check, the not() function can be used. Pass multiple checks separated by commas to thefunction.

The rule conditions are so-called "unary tests". You can find more info about them in the UnaryTests section. Rule outputs can be any FEEL expression.

Entry - evaluates to false when input is null and no allowed value is specified. In order to forcethe evaluation to return true, null has to be added to the list of allowed values (null, <furtherallowed values>).

To rearrange the rules, simply select the rule and drag it with the mouse.



3.4.5. Hit Policies

The small box at the top left of a decision table shows the hit policy. This defines the exact behavior of thedecision table when it gets executed.

Some hit policies mention circumstances when the decision table "fails". When this happens, the result of thedecision table is null.

Table 3.1. Hit Policies

Hit Policy Behavior

U : Unique Only a single rule can match. If multiple rules match, the decision table fails.

A : Any Multiple rules can match, but they must all produce the same result. This resultis returned. If matching rules produce different results, the decision table fails.

F : First Multiple rules can match. The result of the first matching rule is returned.

P : Priority Multiple rules can match and they can produce different results. Only one resultis returned which is the first to appear in the list of allowed values.

O : Output Order A list of the results of all matching rules is returned, in the order of decreasingpriority. Priority is determined by the list of allowed values.

R : Rule Order A list of the results of all matching rules is returned, in the order of the rules.

C : Collect A list of the results of all matching rules is returned.

C+ : Collect (Sum) The sum of the results of all matching rules is returned.

C< : Collect (Minimum) The minimum of the results of all matching rules is returned.

C> : Collect (Maximum) The maximum of the results of all matching rules is returned.

C# : Collect (Count) The number of matching rules is returned.

To change the hit policy of a decision table, click in the hit policy cell and enter the new hit policyabbreviation. To get a list of all available abbreviations and a short description for the hit policy, pressCtrl+Space.

3.5. Invocations

An invocation boxed expression is used to call a business knowledge model (or any function).

It is displayed with a top cell containing a boxed expression to define the business knowledge model orfunction to be called. This can be a name or any other boxed or FEEL expression that evaluates to a functiondefinition. Below that are two columns specifying the values passed as parameters. This is similar to a contextwith the green column containing the parameter names and the white column containing expressions for theparameter values.

Figure 3.17. Boxed Function Invocation of a business knowledge model or FEEL function

You add parameters with the buttons. The first button adds a parameter before the currently

selected parameter, while the second button adds it after it. Parameters are removed with the button.

To rearrange parameters, drag them with the mouse up or down.



The position of the parameters in a boxed invocation has no effect to the execution.

An invocation is similar to a FEEL function call with named parameters. However, FEEL can callfunctions without parameters, while the boxed invocation always has at least one parameter.

If a parameter of a function definition is not specified, it will be set to null.

3.5.1. Invocation Properties

To display the Properties view of the invocation, select the top cell and press F8 to select the wholeinvocation.

Figure 3.18. Invocation Properties view

TypeThe type of the invocation. This is an item definition or a FEEL data type. Since there is no FEEL data typefor a function, leave this field empty.


DescriptionThis is the full description for the invocation.

3.6. Lists

A list boxed expression has one or multiple entries vertically arranged that are numbered starting from 1. Eachrow contains one element of the list.

Here is a context with one entry named countries whose value is a list of 4 strings.

Figure 3.19. Boxed List inside a context

You add elements to the list with the buttons. The first button adds an element before the currentlyselected row, while the second button adds it after the currently selected element. Elements are removed with

the button.



To rearrange list items, drag them with the mouse up or down.

3.6.1. List Properties

To display the Properties view of the list, select a list item and press F8 to select the whole list.

Figure 3.20. List Properties view

TypeThe type of the list. This is an item definition or a FEEL data type.


DescriptionThis is the full description for the list.

3.7. Relations

A relation boxed expression is a special kind of list where every element is a context with the same contextentries. It is like a table in Excel or in a relational database (hence its name).

The first row is green and contains the names of the context entries. Every other row is a context with valuesfor the context entries.

Here is a context with one entry named customers which contains a relation. It is a list of three entries, eachwith a name, birthday and gender.

Figure 3.21. Boxed Relation inside a context

You add elements to the relation with the buttons. The first button adds an element before thecurrently selected row, while the second button adds it after the currently selected element. Elements are

removed with the button.

To rearrange relation columns, drag them with the mouse to the left or right. To rearrange relation rows, dragthem with the mouse up or down.



3.7.1. Relation Properties

To display the Properties view of the relation, select the empty top level cell or select the column header andpress F8 or select a row and press F8.

Figure 3.22. Relation Properties view

TypeThe type of the relation. This is an item definition or a FEEL data type.


DescriptionThis is the full description for the relation.

3.7.2. Relation Column Properties

Each relation column defines properties, which can be seen by selecting the column header.

Figure 3.23. Relation Column Properties view

NameThe name of the relation column, that is the name of all context entries in this column.

TypeThe type of all context entries in this column. This is an item definition or a FEEL data type.




DescriptionThis is the full description for the relation column.

3.7.3. Relation Row Properties

Each relation row defines properties, which can be seen by selecting the row number. The row properties arethe same as the properties for a boxed list.

Figure 3.24. Relation Row Properties view

TypeThe type of the context. This is an item definition or a FEEL data type.

The types of all rows should be the same.


DescriptionThis is the full description for the relation row.

3.8. Function Definitions

A boxed function definition is used to define your own custom function. It is displayed as two boxes on top ofeach other. The first cell contains the parameter list for the function. The second cell contains the body, i.e. theboxed expression that produces the function result.

Here is a function that calculates an interest amount given a base, a percentage, and a number of years.

Figure 3.25. Boxed Function Definition

You will usually put a function definition into a context, so that the function can be called using the name ofthe context entry, like so:

Figure 3.26. Boxed Function Definition inside a context



A boxed function definition is similar to FEEL User-Defined Functions.

3.8.1. Function Definition Properties

In order to specify the return type of the function and the types and descriptions of the parameters, you needto go to the Properties view. It can be opened by selecting the top cell of the function definition.

Figure 3.27. Function Definition Properties view

Return TypeThis is a reference to an item definition or a built-in FEEL data type that describes the type of theinvocation result of the function. This return type is propagated to the boxed expression that is the bodyof the function definition.

The type of the function definition itself is always a function.

ParametersFor every parameter, you can specify the information item (i.e. the name), the type, a label and adescription.

Chapter 4. Validation and Problem Reporting


Chapter 4. Validation and Problem ReportingDMN models are automatically validated - unless the Validate Modeler Projects Automatically option in theProject menu is turned off.

Validation problems are listed in the Problems view.

Figure 4.1. Problems view

Columns of the Problems view are:

DescriptionDetailed description of the problem including the line number and position of the problem in the text.

ResourceDMN model file name containing the problem.

PathPath to the DMN model in the workspace.

LocationPath to the element in the DMN model.

TypeAlways "ACTICO Modeler DMN Validation Problem". Can be used to filter problems.

Double-clicking a problem in the Problems view navigates to the position in the model where the problemexists.

If a DMN project contains at least one problem, it is marked with an error symbol in the Project Explorer:

Figure 4.2. Problem indicator on a DMN project

Different types of validations are applied to the DMN model.

1. Name validation Name declarations are validated against the FEEL name rules.

2. FEEL expression validation FEEL literal expressions are validated against the syntax of FEEL.

3. FEEL unary tests validation FEEL unary tests are validated against the syntax of FEEL. Note that FEEL unarytests syntax is a subset of the FEEL expression syntax with small enhancements.

In order to get fast feedback while writing FEEL expressions, unary tests and names, invalid parts of theentered text are underlined with a red wavy line.

Figure 4.3. Problem highlighting in editor

Chapter 5. Imports and References to other DMN Models


Chapter 5. Imports and References to other DMN ModelsDMN models can be imported by other DMN models. This allows elements from one model to be referenced inanother model for reuse.

Elements that can be referenced in this fashion are:

• DRD elements (decisions, input data, business knowledge models, knowledge sources)

• Item Definitions

5.1. Importing a DMN Model

To reuse elements from another DMN model, you have to import that DMN model first.

See Opening an Existing Decision Model (DMN File) if you actually want to bring an existing DMNfile into Modeler.

To add an import, select the DMN model ( ) in the Project Explorer. Then go to the Imports tab in theProperties view.

Figure 5.1. DMN model Properties view

Click on to add a new import, then select the model to be imported. Use to remove an existing import.

An import has several properties:

Model NameThe name of the imported DMN model.

NamespaceThe namespace of the imported DMN model.

PrefixThe prefix used within this model to reference elements from the imported model. This is used as theprefix (with a colon) to reference item definitions. And it is used as the prefix (with a dot) to referenceinformation items like decision results, input data and business knowledge models.

By default, Modeler will use a prefix that is equal (or at least similar) to the imported model name. This makesit easier to see where reused elements come from. However, you are free to change the prefix to a differentvalue.

In order to execute a DMN model, you must make sure that any imported DMN model is availableat runtime by adding it as a dependency to ruleproject.vr.



5.2. Imported Elements on Decision Requirements Diagrams

Imported DRD elements can be added to diagrams, either from the Available Elements section of the palette orby dragging them from the Project Explorer directly.

Referenced elements are indicated by a small arrow in the top-left corner.

Figure 5.2. Decision requirements diagram showing referenced elements from another model

Imported elements may not be altered. Thus there are limitations when working with imported elements:

• Creation, modification, and deletion of requirements is not possible if the target of the requirement is animported element.

• Renaming of imported elements is not possible.

• The Properties view of imported elements is read-only.

If you want to do these things anyway, you have to go to the original DMN model where theimported elements come from.

5.2.1. Unresolved Model Elements on Decision Requirements Diagrams

Unresolved model elements may occur in diagrams if an imported DMN model is not present or cannot beloaded.



Figure 5.3. A decision requirements diagram containing unresolved model elements

Unresolved model elements are decorated with an error marker.

When your diagram contains unresolved model elements you can keep on working as usual, but actionsinvolving unresolved elements are restricted. Unresolved model elements may only be moved or deleted fromthe diagram.

5.3. Use of Imported Information Items (Decisions, Input Data, BusinessKnowledge Models)

In order to refer to the value of an imported information item in FEEL, you must specify the prefix defined bythe import, followed by a dot and then the name of the information item.

For example, if a DMN model has a decision named Determine Score (more precisely: the variable of thedecision has that name), and you have imported this DMN model with a prefix scoring, then you can refer tothe result of that decision in FEEL with scoring.Determine Score.

Note that you still need to specify an information requirement arrow from that imported decision in order todo this.

5.4. Use of Imported Item Definitions

In order to use an imported item definition as the type for an information item, use the prefix from the import,followed by a colon and then the name of the item definition.

For example, if a DMN model has an item definition named Account, and you have imported this DMN modelwith a prefix common, then you can refer to this item definition in your model with common:Account.

Chapter 6. Decision Services


Chapter 6. Decision ServicesDecision services are a layer on top of the decision requirements diagrams. They define a technical boundaryfor execution and automation of decisions. Basically, they group one or multiple decisions together to indicatethat these decisions shall be evaluated when the decision service is called.

A decision service in DMN is illustrated as a box with rounded corners with two compartments.

Figure 6.1. Decision Service diagram

• The top compartment contains the decisions whose results shall be included in the result of the decisionservice. These decisions will be evaluated. Often, this is only one decision.

• The bottom compartment contains all the decisions that shall also be evaluated during the execution of thedecision service, but are not contained in the decision service result.

• Any decisions and input data elements outside the decision service box which are decorated with an I areinputs to the decision service. This means that the values need to be provided when calling the decisionservice. Any decisions and input data elements outside the decision service box which are not decoratedwith an I have no effect on the definition of the decision service.

Changes outside of the decision service editor might lead to incorrect inputs to the decisionservice. Using the action Update Decision Service will update and correct the inputs of thedecision service. This action can be called by right-clicking on the decision service in the ProjectExplorer or by right-clicking anywhere in the decision service editor.

Each decision service is a separate diagram. You can add additional services by right-clicking the DMN modeland selecting New Element > Decision Service.

Chapter 6. Decision Services


Figure 6.2. Create a new Decision Service

Initially, the decision service diagram does not have any contents.

You can add existing decisions by dragging them from the Project Explorer. All its required elements (inputdata elements and other decisions) will also be added to the diagram. Finally, you move them to the top orbottom compartment or outside the decision service box, as desired.

Chapter 7. Executing and Testing



7.1. Prerequisites

Ensure all required DMN files are on the project classpath. Per default all DMN files at the top level areautomatically included to the project classpath. DMN files organized in subfolders should be added manuallyvia context menu (Build Path > Configure Build Path…).

7.2. Execution of a Decision Service

ACTICO Modeler allows to call DMN decision services from flow rules in order to execute and test DMN decisionservices.

A special service type "DMN Decision Service" is used for that purpose.

You may want to look at the example models that are included in ACTICO Modeler which illustratethis. Select File > New… > Example, then ACTICO Modeler Example Project and finally select the"Movie Ticket Pricing DMN" and "Movie Ticket Pricing DMN Call" example projects.

The following image shows a DMN project with a DMN model name "Movie Ticket Pricing DMN" and a ruleproject "Movie Ticket Pricing DMN Call". The DMN model will be called from a flow rule in the rule project.

Figure 7.1. DMN project and rule project in the Rule Explorer

In order to call a decision service in a DMN model from a flow rule, you first have to prepare the rule projectand rule model:

1. Make the DMN model visible to the rule model. Double-click the ruleproject.vr in the rule project and addthe DMN project to the dependencies.

2. Select the rule model in the Project Explorer, then activate the DMN Support checkbox on the Extensionsproperties tab. (This will make the "DMN Decision Service" available and add the DMN runtime to theproject dependencies.)



Figure 7.2. Enabled DMN support for a rule project

Now you can either have ACTICO Modeler automatically create Services for DMN decision services for you orcreate them manually.

7.2.1. Automatically generate Services in a Rule Model

Follow these steps to let ACTICO Modeler create services in the rule model for all DMN decision services of aDMN model.

1. Right-click the DMN model and select Generate Services in Rule Model….



Figure 7.3. Generate Services in Rule Model

2. Select the rule model where the services shall be created in and click Finish.



Figure 7.4. Select Rule Model

ACTICO Modeler now automatically creates the Services, Flow Rules and Data Types which enable for DMNdecision services to be called from ACTICO Rules.

If you repeat these steps then the automatically created elements will be refreshed. Manuallycreated tests, test-suites and test results will not be affected.

The mapping from DMN types to rules types is described here.

Output values have to be typed, either with a built-in FEEL data type or an Item Definition. Inputvalues should be typed.

7.2.2. Manually create a Rules Service for a DMN Decision Service

Follow these steps to create a service in the rule project for every DMN decision service you want to call.

1. Right-click the rule model and select New Element > Service. Choose the "DMN Decision Service" type.

2. Select the newly created service and specify the decisionService and the model parameters on theService Settings properties tab. model is the name of the DMN model, and decisionService is the nameof the decision service you want to call.



Figure 7.5. Definition of called DMN model and decision service for a DMN Decision Service Type

3. Now you must add the input and output parameters to the service so that they match the variable namesand types of the input requirements of the decision service and the variable names and types of theoutput decisions of the decision service in the DMN model. Go to the Service Call Parameters propertiestab and add parameters accordingly.

Figure 7.6. Definition of input and output parameters for a DMN Decision Service Type

4. You can now call this service in some flow rule and specify input and output parameters accordingly.During execution, the flow rule will pass input parameters to the DMN decision service. These parametersare mapped to input data elements and input decisions of the decision service, which gets evaluatedusing the DMN engine (runtime). The output decision results of the decision service are mapped to outputparameters.

Figure 7.7. Flow rule with service node executing a DMN model



Figure 7.8. Mapping of input and output data of a service node

7.2.3. Requested Decisions

A DMN decision service may define multiple output decisions. If only a subset of these output decisions areneeded, just specify only the requested output decisions for the "DMN Decision Service".

7.2.4. Known Decisions

DMN allows to specify already known decisions for a DMN decision service. If a result is already known, theknown decision value can be passed to the decision service. Decisions with known values are not evaluated.But the known value is considered during the evaluation of the DMN model.

To specify known decision values, add a service call input parameter with the decision variable name and typeand pass the value using the Call Service element in a Flow Rule.

7.3. Execution of a Decision

The "DMN Decision Service" service type can also be used to execute a single decision. In order to do this, usethe decision variable name for the decisionService parameter.

Add a service call output parameter with the decision variable name and the result type of the decision.

The decision can be part of a decision service, but this is optional.

7.4. Execution of a Business Knowledge Model

The "DMN Decision Service" service type can also be used to execute a single business knowledge model. Inorder to do this, use the business knowledge model variable name for the decisionService parameter.

Add a service call output parameter with the business knowledge model variable name and the result type ofthe boxed expression body of the function definition of the business knowledge model.

Note that the input parameters of the service type are mapped to the function parameters.

7.5. Testing

Tests can be created and performed against a defined rule in a rule project.



Figure 7.9. Rule Tests

7.6. Type Mapping

Rule models and the DMN models define different type systems. Since the "DMN Decision Service" service typeneeds to map between these two type systems, conversions must be done, which are listed below.

Some datatypes cannot be converted without loosing information.

Table 7.1. Rules to DMN type mapping

Rules Type DMN Type Example

null Value

null null null ⇒ null

Basic Types

Float, Integer number 3.5 ⇒ 3.5

Boolean boolean true ⇒ true

String string "Hello from Rules" ⇒ "Hello from Rules"

Date (and String) FEEL date value is not able to hold a time offset. Example: +2 h offset from UTC using2017-10-20 is not used.

Date, String ISO-8601 dateformat

date 2017-10-20 ⇒ date("2017-10-20")

Time (and String) FEEL time value contains time offset of epoch date. Example: +1 h offset from UTC using1970-01-01 as epoch date.

Time, String ISO-8601 timeformat

time 09:10:11.123 ⇒ time("09:10:11.123+01:00")

Timestamp (and String) FEEL date and time value may contain time offset of included date. Nanoseconds arenot convertible. Example: +2 h offset from UTC using 2017-10-20.

Timestamp, String ISO-8601date time format

date andtime

2017-10-20T09:10:11.123 ⇒ date andtime("2017-10-20T09:10:11.123+02:00")

Structures

List, Set list [1,2,3] ⇒ [1,2,3]



Rules Type DMN Type Example

Map relation withcolumns keyand value

a=1, b=2 ⇒ [{key: "a", value: 1}, {key: "b", value: 2}]

JavaBean context a=1, b=2 ⇒ {a:1, b:2}

Any Value

value of type Any (as listed above) convertedvalue (as listedabove)

see examples (as listed above)

A Date, Time or Timestamp value that is passed from a "DMN Decision Service" service typeto DMN and returned from DMN to the calling service as is, will result in the same value. Onlynanoseconds of the second property are lost. Milliseconds are supported.

Table 7.2. DMN to Rules type mapping

DMN Type Rules Type Example

null Value

null null null ⇒ null

Basic Types

number Float 3.5 ⇒ 3.5

boolean Boolean true ⇒ true

string String "Hello from FEEL" ⇒ "Hello from FEEL"

date Time offset of included date is added. Example: +2 h offset from UTC using 2017-10-20.

date Date date("2017-10-20") ⇒ 2017-10-20+02:00

time (local) Time offset may be modified and is applied to Time, since epoch date 1970-01-01 is used forconversion. Nanoseconds are not convertible. Example: +1 h offset from UTC using 1970-01-01.

time Time time("09:10:11") ⇒ 09:10:11+01:00

time (with time offset) Time offset may be modified and is applied to Time, since epoch date 1970-01-01is used for conversion. Nanoseconds are not convertible. Example: +1 h offset from UTC using 1970-01-01,adjusted time value.

time Time time("09:10:11+02:00") ⇒ 08:10:11+01:00

time (with timezone) Time offset of timezone is calculated using current timestamp and may be modified.It is applied to Time, since epoch date 1970-01-01 is used for conversion. Nanoseconds are not convertible.Example: +1 h offset from UTC using 1970-01-01, adjusted time value.

time Time time("09:10:11@Asia/Dhaka") ⇒ 04:10:11+01:00

date and time (local) Time offset of included date is added. Nanoseconds are not convertible. Example: +2 hoffset from UTC using 2017-10-20.

date and time Timestamp date and time("2017-10-20T09:10:11") ⇒2017-10-20T09:10:11+02:00

date and time (with time offset) Time offset may be modified and is applied to Timestamp. Nanoseconds arenot convertible. Example: +2 h offset from UTC using 2017-10-20.

date and time Timestamp date and time("2017-10-20T09:10:11+02:00") ⇒2017-10-20T09:10:11+02:00



DMN Type Rules Type Example

date and time (with timezone) Time offset of timezone is calculated using included date and may bemodified. It is applied to Timestamp. Nanoseconds are not convertible. Example: +2 h offset from UTC using2017-10-20, adjusted time value.

date and time Timestamp date and time("2017-10-20T09:10:11@Asia/Dhaka") ⇒2017-10-20T05:10:11+02:00

Durations

days and time duration,years and months duration

String duration("PT2H") ⇒ "PT2H" duration("P24M") ⇒ "P2Y"

Structures

Item Definition (scalar, IsCollection=false)

JavaBean {a: 1, b: 2} ⇒ a=1, b=2

Item Definition (collection, IsCollection=true)

List [1,2,3] ⇒ [1,2,3]

The conversion of a value of any FEEL type to Rules type Any is not supported. A specific targetRules type must be specified. Any is not allowed here.

Instead of using auto conversion for FEEL types date, time, date and time, days and timeduration and years and months duration, the properties of a single value can be returneddirectly, e.g duration("PT2H").hours. Additionally the built-in function string() can be used toreturn the value as a string.

Chapter 8. Expression Language - FEEL


Chapter 8. Expression Language - FEELFEEL is the Friendly Enough Expression Language. It is used for all expressions entered anywhere in thedecision logic.

Most DMN boxed expressions (context, list, relation, function definition and function invocation)can also be written as a single FEEL expression. But to improve readability, wherever possible it isrecommended to use the DMN boxed expression instead.

8.1. Datatypes

FEEL supports the following datatypes:

• number

• boolean

• string

• date

• time

• date and time

• days and time duration

• years and month duration

Every datatype supports the null value.

Lists and contexts can be used to structure data.

Finally, ranges can be used to describe a range of values.

8.1.1. Numbers

A number is a decimal number (with up to 34 digits of precision). Some examples are

23-766.9910.0006544.243-.45

FEEL does not distinguish between decimal numbers and integers. Also it does not supportscientific notation for powers of 10. Instead, you must write 1.23e4 explicitly like this: 1.23 * 10 ** 4

8.1.2. Booleans

A boolean is a logical value of either true or false.

truefalse

8.1.3. Strings

A string is a sequence of characters, or - in other words - some text. It is written with double quotes. It cancontain unicode characters.



"Honolulu""345""4200 Main St.""##"

String literals cannot contain special characters like new line, tab etc. But a string may still contain thosecharacters if the content was passed to DMN, e.g. due to an input data or external function call.

8.1.4. Dates and Times

8.1.4.1. Date

A date is a value consisting of a year, month and day. There is no literal form of a date value. Month and daysvalues are starting from 1.

It is created with the date(year, month, day) function or with the date(date string) function, e.g. .

date(1970,1,14)date("1970-01-14")

A date value is assignable to a date and time type. It is automatically converted by setting all timefields to zero.

8.1.4.2. Time

A time is a value consisting of hours, minutes, seconds, optionally including fractions of a second, a timezoneor a timezone offset from GMT. There is no literal form of a time value.

It can be created with the time(hours, minutes, seconds, timezone offset) function or with thetime(time string) function.

time(12, 34, 56.789, duration("-PT2H30M")) => 12:34:56.789-02:30time("12:45:00")time("12:45:00@Europe/Paris")time("12:45:00Z") => means: UTC time offset of 0 hourstime("12:45:00+02:00")

8.1.4.3. Date and Time

A date and time value is the combination of a date plus a time value. There is no literal form of a date and timevalue.

It is written with the date and time(date, time) function or the date and time(date and timestring) function.

date and time(date("2017-01-01"), time("23:59:01+02:00"))date and time("2017-12-31T11:22:33.456+01:35")date and time("2017-12-31T11:22:33@Europe/Paris")date and time("2017-12-31T11:22:33Z") => means: UTC time offset of 0 hours

8.1.5. Durations

8.1.5.1. Days and Time Duration

A days and time duration is a value specifying a time period in days, hours, minutes, seconds. There is noliteral form of a days and time duration value.

It can be created with the duration(duration string) function. At least one of days, hours, minutes andseconds must be specified.



duration("P10D") => 10 daysduration("PT120M") => 2 hoursduration("P1DT2H3M4.123456789S") => 1 day + 2 hours + 3 minutes + 4.123456789 seconds

8.1.5.2. Years and Month Duration

A years and month duration is a value specifying a time period in years and months. There is no literal form ofa years and month duration value.

It is written with the duration(duration string) function. At least one of years and months must bespecified.

duration("P1Y2M") => 1 year + 2 monthsduration("P24M") => 2 years

8.1.6. Null

Null is not a datatype, but the null value can be assigned to any type. The null literal can be used within FEELexpressions to express the meaning of "nothing".

["Jeff", null, "John"]

Whenever a FEEL expression can’t be evaluated, due to a syntactical or semantic error, itsevaluation result is null.

1 + "Hello from FEEL" => null

8.2. Expressions

FEEL supports different kinds of expressions:

• Qualified Names

• Arithmetic Expressions

• Comparisons

• Logical Expressions

• If Then Else Expressions

• Function Calls

• Ranges

• In Expressions

• Between Expressions

• List Expressions

• Context Expressions

• Path Expressions

• Filter Expressions

• Unary Tests

• Some and Every Expressions

• For Expressions



• Instance Of Expressions

• User-Defined Functions

• External Functions

• Properties

8.2.1. Qualified Names

In FEEL expressions, you can write a name to refer to an existing value. These can be input data elements,results of other decisions, context entries or else.

Names can contain upper- and lowercase letters and digits. They can also include single spaces,dashes (-), plus signs (+), asterisks (*), slashes (/), apostrophes ('), dots (.) and ampersands (&).They must not start with a FEEL language keyword, but may contain one.

Examples of qualified names:

ScoreThis & ThatRetirement calculation.of last monthRisk-CalculationLoan * Risk

Names can only be used if they are known at the location you write your expression. Here are some rules thatdefine which names are available:

• Information items of input data elements directly connected via an information requirement

• Information items of decisions directly connected via an information requirement

• Variables of business knowledge models directly connected via a knowledge requirement (these arefunctions)

In order to reference an information item that has been imported from another DMN model, youmust specify the prefix from the import, followed by a dot and then the name of the informationitem.

Additional names are declared and become available when you define one of the following:

• a context entry

• a function definition parameter

• a decision table output column with a name, if the decision table has multiple output columns

• a relation column

You’ve already seen examples of this in previous sections and will see more in this chapter.

When a value has multiple components, you can use Path Expressions with a . to refer to aspecific component, e.g.

Person.Address.Street

8.2.2. Arithmetic Expressions

FEEL supports all the basic arithmetic operators for numbers. This includes addition, subtraction,multiplication, division, exponentiation and negation.

-base * (1 + 1/n) ** n - discount

+ can also be used to concatenate strings.



"Hello" + " " + "World"

There is more. + can also be used to add up durations, while - can e.g. also be used to calculate the durationbetween two dates.

The full list of supported operand types for arithmetic operations is listed in Operand Types for Expressions.

Exponentiation is written with **, not ^

Parentheses ( ) can be used to encapsulate a FEEL expression in order to change defaultoperator and expression precedence, or to increase readability of a FEEL expression.

8.2.3. Comparisons

Two values can be compared with the usual comparison operators. Equality is written with just one =,inequality as !=.

a = ba != ba < ba <= ba > ba >= b

Supported operand types for comparisons are listed in Operand Types for Expressions.

8.2.4. Logical Expressions

You can use and and or for logical conjunction and disjunction. not is a function, so it always requiresbrackets.

a and ba or bnot(a)

Here is the full table of the results for and and or, also for cases where a or b are not booleans or null.

Table 8.1. FEEL ternary logic

a b a and b a or b

true true true true

true false false true

true otherwise null true

false true false true

false false false false

false otherwise false null

otherwise true null true

otherwise false false null

otherwise otherwise null null

Supported operand types for logical operations are listed in Operand Types for Expressions.



8.2.5. If Then Else Expressions

In order to check a condition and then return either one thing or the other, you can use the if then elseexpression.

if Account Balance > 0 then "ok" else "we need money"

You can use if then else within expressions, e.g.

34 + (if val < 10 then val else val * 2) / scale

Use if then else only for simple checks and resort to decision tables when things get morecomplicated.

The else part is always evaluated when the condition is not true, especially also if it is null.

8.2.6. Function Calls

You can call a function by specifying an expression that evaluates to a function definition followed by aparameter list in parentheses. Typically this expression is a qualified name. All required function parametersmust be specified.

string length("foo")max([4,9,2,1])Calculate Score(Loan Application, Applicant)

Parameters can also be passed by name followed by a colon. This allows parameters to be passed in any order.E.g., the following two function calls are equivalent.

Calculate Score(application: Loan Application, customer: Applicant)Calculate Score(customer: Applicant, application: Loan Application)

If parameter names are used, parameters can be omitted. They are then set to null.

A business knowledge model is also a function and can also be called using a FEEL function call.

A FEEL function call is similar to the Invocation boxed expression.

FEEL has many built-in functions which are described in the Chapter 9, FEEL Function Reference.

8.2.7. Ranges

A range is an interval with a beginning and an end. They are written in square or round brackets with two dotsbetween the endpoints.

[1..10][2..5)(0..1]

A square bracket on either side means that the corresponding endpoint itself is included in the range, while around bracket means that it isn’t.

Instead of round brackets, you can also use square brackets "pointing outwards".



(2..5) can be written as ]2..5[(2..5] can be written as ]2..5][2..5) can be written as [2..5[

Endpoints can be symbols, i.e. names of information items or names declared inside a FEEL expression.

[from..to]

This way you can also create ranges of dates or times.

8.2.8. In Expressions

The in expression can be used to test if a value lies within a range.

4 in [2..5] => true2 in [2..5] => true2 in (2..5] => false5 in (2..5] => true5 in (2..5) => false

The in expression can also test if a value satisfies a single unary test or a single unary test in a list of unarytests. The list of unary tests can be specified using square brackets or parentheses.

3 in > 1 => true4 in [>10,<5] => true4 in (>10,<5) => true

8.2.9. Between Expressions

A range check can also be written as between … and …, like so

4 between 2 and 5 => true"i" between "a" and "z" => true

between always includes the endpoints, i.e. x between a and b is equivalent to x in [a,b].

8.2.10. List Expressions

Lists in FEEL are written with square brackets. Elements are separated by commas.

[1,2,3]["Peter", "Lisa", "Pepe"]

The empty list is just written as [].

Lists can be nested.

[1, [2, 3], 4, 5, [6, 7, 8]]

Individual elements of a list can be accessed using an index in square brackets.

The first element has the number 1.

list[2] => means: the 2nd element from list["Peter", "Lisa", "Pepe"][1] => "Peter"

Negative indices are used to access elements starting from the end of the list. -1 is the last, -2 is the secondlast, and so on.



["Peter", "Lisa", "Pepe"][-1] => "Pepe"["Peter", "Lisa", "Pepe"][-2] => "Lisa"

Lists in FEEL are similar to the boxed expression List

A list with a single element behaves like the single element. And whenever a list parameter for afunction or expression is required, a single element is automatically converted to a list with thesingle element.

A value that is accessed with position 1 is returned as is:

true[1] => true

8.2.11. Context Expressions

FEEL lets you define structured data, i.e. data that has several named components. Such data is called acontext. A context in FEEL is written within curly braces. Each context entry is a pair of the context entry nameand a value, separated by a colon.

{ name: "Peter", age: 34 }

Contexts can be nested.

{ name: "Peter", age: 34, address: { street: "1433 Main St.", city: "Chicago" }}

The syntax here is similar to JSON, but the context entry names (keys) can be quoted.

{ "name": "Peter" } = { name: "Peter" }

FEEL contexts are similar to boxed Contexts.

8.2.12. Path Expressions

Whenever an information item has components, you use the dot . to access an individual component. Thisis also how you access individual context entries within a context. Also, when a decision produces multipleresults (e.g. with a decision table with multiple output columns), you use the dot to access a specific result.

Customer.AgeScoring Decision.risk score

You can use multiple dots to navigate even deeper into nested structures. For example, here is a context with acontext entry address that is again a context with entries street and city.

{ name: "Peter", age: 34, address: { street: "1433 Main St.", city: "Chicago" }}.address.street => "1433 Main St."



You can have spaces around the dot if you like.

customer . age

A path expression can also be used together with lists of contexts in order to get only the context entries thatare of interest. Lists are preserved.

[{id: 1, name: "John", address: [{street: "Main street 1"}, {street: "Other street 23"}]}, {id: 1, name: "Jeff", address: [{street: "Malibu 13"}, {street: "Block 17"}]}].address.street=> [["Main street 1", "Other street 23"], ["Malibu 13", "Block 17"]]

8.2.13. Filter Expressions

Filter expressions let you find the elements of a collection that satisfy a specific condition. Only the elementssatisfying the condition are returned, or an empty list if none of them do.

The condition is simply put in square brackets behind the collection to be filtered.

[1,2,3,4,5,6,7][item > 4] => [5,6,7]

The special keyword item is used in the condition to refer to the elements of the collection.

If the elements are contexts, the word item can be omitted. For example, if customers each have a contextentry named age, you can simply write

customers[age < 40]

[{id: 1, name: "smith"},{id: 17, name: "smith"}][id=17] => [{id: 17, name: "smith"}]

A single value that is filtered is returned as a list with one element:

3[item > 2] => [3]

8.2.14. Unary Tests

Unary tests are a special kind of expression that just check a condition. Most importantly, they are used asthe conditions for the rules of a decision table, i.e. they can be found in the cells of the input columns (inputentries). They are used also to specify allowed values for item definitions, input columns of decision tables oroutput columns of decision tables. They can be used with the in expression.

They always produce either true or false but are missing the first operand.

>10<100>=2.5"DE" => `=` comparison is used"Germany", "USA", "India", "Singapore" => ìn` expression is used[1..100] => ìn` expression is used(0..15] => ìn` expression is used

To make it easier, you must leave out the operator if it is = or in.

Also, the unary test - is always true. That’s why you can put a dash into decision tables if an input is irrelevantfor a rule.

Unary tests are restricted FEEL expressions. Not all syntactical elements and expressions can beused. A unary test can be - (irrelevant), a range, a simple literal, a qualified name or a comparison



with a simple literal or qualified name using one of <, <=, >= or >. The not() expression can beused and date(), time(), date and time() and duration().

Multiple unary tests can be joined together in a comma separated list. If one of the tests is true then the wholetest is true. Basically, you can read the comma as the word 'OR'.

This allows to list multiple values without putting them into a list. This is the most common form of a unarycheck.

"Germany", "USA", "Singapore" => means: equal to "Germany" OR equal to "USA" OR equal to "Singapore"

Or you can have several checks together like so:

>12, 10, <3, [5..7] => means: greater than 12 OR equal to 10 OR less than 3 OR between 5 and 7

If you want to negate a test, use not and parentheses around the whole test.

not( "Germany", "USA", "India", "Singapore" )not( null )

8.2.15. Some and Every Expressions

If you want to check if elements in a collection satisfy a condition, you can use the some or every expression.The full syntax is

some <item> from <collection> satisfies <condition>

or

every <item> from <collection> satisfies <condition>

This returns either true or false.

To check if there is one customer in the customers collection below the age of 40, you can write

some Customer in Customers satisfies Customer.Age < 40

To check if this is true for all customers, you write

every Customer in Customers satisfies Customer.Age < 40

You can also correlate multiple collections at the same time by repeating the <item> in <collection>part multiple times.

For example, to check if any item in order items is about any of the products in products, you write

some Product in Products, Item in Order Items satisfies Item.Product = Product

However, in this particular case you may want to write this shorter

some Item in Order Items satisfies Item.Product in Products

8.2.16. For Expressions

In order to process all items of a collection, you can use



for <item> in <collection> return <expression>

This takes every element from a collection, assigns it to the item and then calculates the expression. Theresult is a collection with the results of all expressions.

for i in [1,2,3] return i * 2 => [2,4,6]

for is also often used in decisions to call decision logic in a business knowledge model multiple times forevery element of a collection. For example, here Check Delivery shall be the name of a business knowledgemodel to check delivery options for an order position.

for Order Item in Order.Positions return Check Delivery(Order Item)

You can also correlate multiple collections at the same time by repeating the <item> in <collection>part multiple times. This cross-joins the items of all collections and effectively calculates the cartesian productof the collection items.

For example, to do a cross-join of two collections, you write

for retirement age in [50,60,70], person in [{name: "John", age: 51}, {name: "Jeff", age: 63}, {name: "Sarah", age: 25}]return retirement age - person.age=> [-1, -13, 25, 9, -3, 35, 19, 7, 45]

8.2.17. Instance Of Expressions

The instance of operator can be used to check if a value is of a certain type, e.g. if something is a number, avalid date or a year and months duration.

if Value instance of number then Value else 1.0

someDuration instance of year and months duration

Type names of FEEL data types are: boolean, number, string, date, time, date and time, days andtime duration and years and months duration.

It can also be used to check if a context corresponds to a DMN item definition.

{ ssn: "654781", name: "John", addresses: [ { street: "Main street 1" } ]} instance of tMyItemDefinition

employees[ssn="654781"] instance of tPerson

8.2.18. User-Defined Functions

User-defined functions in FEEL are defined with the following syntax:

function(X1,…,Xn) <body>

X1,…,Xn are the parameter names. <body> must be replaced with the function body.

You could define a function and immediately call it, like so:

(function(a,b) a + b)(1,2)

However, in order to be able to call a user-defined function by name, it must be assigned to an informationitem or a context entry. For example:



{ add: function(a,b) a + b }.add(3,5) => 8

User-defined functions should be modeled using a boxed function definition whenever possible.Usually you find them in context entries, so that the context entry name is used as the functionname, like so

Figure 8.1. Boxed Function Definition in a Boxed Context with FEEL invocation in the context result box

8.2.19. External Functions

FEEL also lets you call external Java methods. The Java methods must be public and static.

function(X1,…,Xn) external <mapping-information>

<mapping-information> is a context of the following form:

{ java: {class: <class-name>, method signature: <method-signature>}}

In order to use the max() method of class java.lang.Math a FEEL function can be defined that uses theJava method as it’s implementation. The following example uses a context to give the FEEL function the namejavaMax. It is invoked inside the context entry exampleCall. A path expression is used to return only thevalue of the exampleCall context entry.

{ javaMax: function(a,b) external { java: { class: "java.lang.Math", method signature: "max(double, double)" } }, exampleCall: javaMax(-.5, 8.0)}.exampleCall => 8.0

The parameter mapping from FEEL to Java happens in sequential order. In the above example, thevalue of parameter a is passed to the first double parameter. The value of parameter b is passedto the second double parameter.

The parameter values passed from FEEL to Java are converted to the Java types listed in the context entry"method signature". The result value of the Java method is converted into it’s default FEEL type representation.

Possible type conversion from FEEL to Java and back are listed below.



Table 8.2. FEEL to and from Java type conversions

FEEL Type/Value Java Type/Value Description

null null The null value is transformedbetween the type systems.

boolean boolean, java.lang.Boolean The boolean value true andfalse is transformed between thetype systems.

string java.lang.String, char,java.lang.Character

String values are passed betweenthe type systems. A character is astring with length 1.

number byte, java.lang.Byte,short, java.lang.Short,int, java.lang.Integer,long, java.lang.Long,float, java.lang.Float,double, java.lang.Double,java.math.BigInteger,java.math.BigDecimal

FEEL internally uses BigDecimalas number representation. Due toconversions precision or scale maybe lost.

date java.time.LocalDate Date value without time offset ortime zone information.

time java.time.LocalTime,java.time.OffsetTime

Time value with optional timeoffset or optional timezoneinformation. Since Java has notype to represent a time valuewith a timezone, FEEL uses its ownimplementation for a zoned time.

date and time java.time.LocalDateTime,java.time.OffsetDateTime,java.time.ZonedDateTime

Date and time value with optionaltime offset or optional timezoneinformation.

days and time duration java.time.Duration Duration of days, hours, minutesand seconds.

years and months duration java.time.Period Duration of years and months.

list java.util.List, Java array FEEL list is convertible to a Java listor array, and back.

context java.util.Map FEEL context is convertible to aJava map, and back.

8.2.20. Properties

Some data types provide properties that can be accessed using (.) and the property name on a value of thattype.

time("09:56:10").hour => 9date and time("2018-01-17T11:40:00@Europe/Paris").timezone => "Europe/Paris"

{ssn: "HN456234", birth date: date("1999-08-20")}.birth date.year => 1999

The following table lists the available properties and their result type.



Table 8.3. Properties for FEEL types

Type of value Property name with type Description

date year : number, month : number,day : number

Access the year, month or dayproperty value.

time hour : number, minute : number,second : number, time offset :days and time duration, timezone: string

Access the hour, minute or secondproperty value. time offset andtimezone can also be used, butmay be null.

date and time year : number, month : number,day : number, hour : number,minute : number, second : number,time offset : days and timeduration, timezone : string

Access the year, month, day, hour,minute or second property value.time offset and timezone can alsobe used, but may be null

days and time duration days : number, hours : number,minutes : number, seconds :number

Access the days, hours, minutes orseconds property value.

years and months duration years : number, months : number Access the years and monthsproperty value.

8.3. Operand Types for Expressions

The following table lists the supported operand types for arithmetic and logical FEEL expressions andcomparisons.

Table 8.4. Operand Types for FEEL expressions

Left Operand Operator Right Operand Result Type Description

Comparison expressions: Equality, Less Than and Greater Than

boolean, number,string, date, time,date and time,days and timeduration, years andmonth duration,list, context, range,function

=, != boolean, number,string, date, time,date and time,days and timeduration, years andmonth duration,list, context, range,function

boolean Test if values areequal or not equal.Both operandsmust be of sametype.

number, string,date, time, date andtime, days and timeduration, years andmonth duration

<, > number, string,date, time, date andtime, days and timeduration, years andmonth duration

boolean Test if valuesare less than orgreater than. Bothoperands must beof same type.

number, string,date, time, date andtime, days and timeduration, years andmonth duration

<=, >= number, string,date, time, date andtime, days and timeduration, years andmonth duration

boolean Test if values areless than or equal,or greater thanor equal. Bothoperands must beof same type.

Logical expressions: Disjunction and Conjunction

boolean and, or boolean boolean Logical operationusing FEEL ternarylogic.

String operations: Concatenation



Left Operand Operator Right Operand Result Type Description

string + string string Concatenation ofstrings

Arithmetic with Numbers

number +, -, /, *, ** number number Arithmeticoperation

Arithmetic with Dates, Times, Date and Times and Durations

date, time, date andtime, days and timeduration

- date, time, date andtime, days and timeduration

days and timeduration

Calculates theduration betweentwo values. Bothoperands must beof same type.

years and monthsduration

- years and monthsduration


Subtraction of twodurations.


+ days and timeduration


Addition of twodurations.


+ years and monthsduration


Addition of twodurations.

number *, / days and timeduration


Arithmeticoperation witha days and timeduration.

number *, / years and monthsduration


Arithmeticoperation with ayears and monthsduration.


*, / number days and timeduration

Arithmeticoperation witha days and timeduration.


*, / number years and monthsduration

Arithmeticoperation with ayears and monthduration.


+ time time Adding a durationto a time.


+ date and time date and time Adding a durationto a date and time.


+ date and time date and time Adding a durationto a years andmonths duration.

time +, - days and timeduration

time Adding orsubtracting aduration to or froma time.

date and time +, - days and timeduration or yearsand monthsduration

date and time Adding orsubtracting aduration to or froma date and time.



Examples:

duration("P10M") + date and time("2017-10-20T00:00:00") => date and time("2018-08-20T00:00:00")

{age: 10, name: "John"} = {"name": "John", age: 5 + 5} => true[1,10] = [10,1] => false

(function(a,b) a + b) = (function(a,b) a - b) => false

date and time("2016-02-29T00:00:00Z") - duration("P1Y") => date and time("2015-02-28T00:00:00Z")

If the operand types are not as listed above and therefore unsupported, the result of the FEELexpression is null.

1 + "Hello from FEEL" => nulldate("2017-12-31") + date("2017-01-01") => null

8.4. Expression Precedence

Precedence order for FEEL expresions (from lowest to highest) according to the DMN specification is listedbelow. Expressions that are listed inside the same bullet point have same precedence order.

• For Expression, If Then Else Expression, Some Expression, Every Expression

• Logical Disjunction (or)

• Logical Conjunction (and)

• Comparison (= != < > <= >=)

• Arithmetic addition and subtraction (+ -)

• Arithmetic multiplication and division (* /)

• Arithmetic exponentiation (**)

• Arithmetic negation (-)

• Instance Of Expression

• Path Expression (.)

• Filter Expression, Function Call

• Simple Literal, Unary Test, Name, Expression in parentheses

• List, Function Definition, Context

Multiplication has higher precedence than addition.

2 + 3 * 4 => 14

Comparison has higher precedence than logical conjunction.

true and 4 > 3 => true

Instance of expression has higher precedence than logical conjunction.

true and 3 instance of number

Expressions with same precedence are executed from left to right.



8 / 4 * 2 => 4

Use parentheses to override precedence or to define the boundaries of an expression.

(2 + 3) * 4 => 20(for i in [2,4,6] return i * 2)[2] => 8(function(a,b) [a, b])(1,2) => [1,2](function(k, v) {key: k, value: v})("ssn","AB987") => {key: "ssn", value: "AB987"}

Get all customer ids of customers with a risk greater than 82. If customers is a list of contexts defined as [{id:17, personal risk: 80}, {id: 62, personal risk: 95}] and overall risk is 82 the following FEELexpression results to [62].

(for customer in customers return { customer id: customer.id, risk: (customer.personal risk + overall risk) / 2 })[risk>82].customer id => [62]

8.5. Comments

A FEEL expression or unary test may contain single line or multi line comments.

A single line comment starts with two slashes (//).

// Calculation according to standard formulaLoan + Risk - 0.89 / (1-Score)

A multi line comment starts with a slash and a star (/*). It ends with a star and a slash (*/).

/* This is a multiline comment, with additional information on line 2. */ [{a:1, b:a+1}, {a:2, b:a+1}, {a:3, b:a+1}][b>2].a[1] => 2

Chapter 9. FEEL Function Reference


Chapter 9. FEEL Function ReferenceFEEL has many built-in functions that are listed in the following sections.

• Parameter names can be used for named parameter invocation.

• Optional parameters are marked with a question mark (?).

• Parameter types are specified after a colon (:).

• Parameters with a variable number of values are marked with (…). It is always the last parameter of thefunction.

9.1. Conversion Functions

If a built-in function requires a date and time value, but a date value is passed, the value isautomatically converted into a date and time value (using null time fields).

Table 9.1. FEEL Conversion Functions

Name Description Examples

number(from :string, groupingseparator : string,decimal separator :string)

convert from to a number groupingseparator: space " ", comma ",", period"." or null decimal separator: comma ",",period "." or null grouping separator anddecimal separator shall not be the same.

number("1 000,0", " ", ",") = 1000.0

number("1,000.0", ",", ".") = 1000.0

string(from : any) convert from to a string string(1.1) = "1.1"

string(false) = "false"

string("Hello from FEEL") = ""Hello fromFEEL""

string(date("2017-12-31")) = "2017-12-31"

string(time("09:05:00@Europe/Paris")) ="09:05:00@Europe/Paris"

string(date andtime("2017-10-07T07:00:00+02:00")) ="2017-10-07T07:00:00+02:00"

string(duration("PT120M")) = "PT2H"

string(duration("P1Y2M")) = "P1Y2M"

string([10..25[) = "[10..25["

string([1,2]) = "[1, 2]"

string({id: 1, code: "NONE"}) = "{id: 1, code:"NONE"}"

string(null) = null

date(from : string) convert from to a date date("2012-12-25") – date("2012-12-24") =duration("P1D")

date(from : dateand time)

convert from to a date (set timecomponents to null)

date(date andtime("2012-12-25T11:00:00Z")) =date("2012-12-25")




date(year : number,month : number,day : number)

creates a date from year, month, daycomponent values

date(2012, 12, 25) = date("2012-12-25")

date and time(date: date or date time,time : time)

creates a date time from the given date(ignoring any time component) and thegiven time

date and time (date("2012-12-24”),time(“23:59:00")) = date and time("2012-12-24T23:59:00")

date and time(from: string)

convert from to a date and time date and time("2012-12-24T23:59:00")+ duration("PT1M") = date andtime("2012-12-25T00:00:00")

time(from : string) convert from to time time("23:59:00z") + duration("PT2M") =time("00:01:00z")

time(from : dateand time)

convert from to time (ignoring datecomponents)

time(date andtime("2012-12-25T11:00:00Z")) =time("11:00:00Z")

time(hour :number , minute: number, second: number, offset: days and timeduration)

creates a time from the given componentvalues

time(“23:59:00z") = time(23, 59, 0,duration(“PT0H”))

duration(from :string)

convert from to a days and time or yearsand months duration

date and time("2012-12-24T23:59:00") -date and time("2012-12-22T03:45:00") =duration("P2DT20H14M")

duration("P2Y2M") = duration("P26M")

years and monthsduration(from :date or date andtime, to : date ordate and time)

return years and months durationbetween from and to

years and monthsduration( date("2011-12-22"),date("2013-08-24") ) = duration("P1Y8M")

years and months duration( date andtime("2011-12-22T11:00:00"), date andtime("2013-08-24T09:12:00.123") ) =duration("P1Y8M")

get entries(m :context)

return a list of contexts. For each contextentry in m a context with the contextentries "key" and "value" is created withtheir respective values

get entries({person: "John", age: 34}) =[{key: "person", value: "John"},{key: "age",value: 34}]

get entries({}) = []

9.2. Boolean Functions

Table 9.2. FEEL Boolean Functions


not(negand :boolean)

logical negation not(true) = false

not(false) = true

not(null) = null



9.3. String Functions

Table 9.3. FEEL String Functions


substring(string :string, start position: number, length? :number)

return length (or all) characters in string,starting at start position. First position is1, last position is -1.

substring("foobar",3) = "obar"

substring("foobar",3,3) = "oba"

substring("foobar",-2,1) = "a"

string length(string: string)

return length of string string length("foo") = 3

upper case(string :string)

return uppercased string upper case("aBc4") = "ABC4"

lower case(string :string)

return lowercased string lower case("aBc4") = "abc4"

substringbefore(string :string, match:string)

return substring of string before thematch in string

substring before("foobar", "bar") = "foo"

substring before("foobar", "xyz") = ""

substringafter(string : string,match: string)

return substring of string after the matchin string

substring after("foobar", "ob") = "ar"

substring after("", "a") = ""

replace(input :string, pattern :string, replacement: string, flags? :string)

regular expression pattern matchingand replacement pattern, replacement,flags conform to the syntax specifiedin clause 7.6 of XQuery 1.0 and XPath2.0 Functions and Operators. Valid flagoptions: s (dot all mode), m (multiline), i(case insensitive), x (whitespace removal)

replace("abcd", "(ab)|(a)", "[1=$1][2=$2]") ="[1=ab][2=]cd"

replace("abc","[A-Z]","#","i") = "###"

contains(string: string, match :string)

does the string contain the match? contains("foobar", "of") = false

starts with(string: string, match :string)

does the string start with the match? starts with("foobar", "fo") = true

ends with(string: string, match :string)

does the string end with the match? ends with("foobar", "r") = true

matches(input: string, pattern: string, flags? :string)

does the input match the regexp pattern?pattern, flags conform to the syntaxspecified in clause 7.6 of XQuery 1.0and XPath 2.0 Functions and Operators.Valid flag options: s (dot all mode),m (multiline), i (case insensitive), x(whitespace removal)

matches("foobar", "^fo*b") = true

matches("abc", "[A-Z]*","i") = true

9.4. List Functions

If a built-in function requires a parameter of type list, but a single value is passed, the singlevalue is converted automatically to a list with the single value.

A list with a single element behaves like the single element.



Table 9.4. FEEL List Functions


list contains(list :list, element : any)

does the list contain the element? list contains([1,2,3], 2) = true

list contains([1,[2],3], 2) = true

list contains([1,2,3], 4) = false

list contains(1, 1) = true

count(list : list) return size of list, or 0 if list is empty count([1,2,3]) = 3

count([]) = 0

count([1,[2,3]]) = 2

count([[2]]) = 1

count([[]]) = 1

count(1) = 1

count(null) = 1

min(list : list) min(c1: any,…,cn : any)max(list : list)max(c1 : any,…,cn :any)

return minimum or maximum item fromlist (or from c1,…,cn), or null if list is empty

min([1,2,3]) = 1

min(1,2,3) = 1

max([1,2,3]) = 3

max(1,2,3) = 3

max([]) = null

sum(list : list)sum(n1 : number,…,nn : number)

return sum of numbers, or null if list isempty

sum([1,2,3]) = 6

sum(1,2,3) = 6

sum(1) = 1

sum([]) = null

mean(list : list)mean(n1 : number,…,nn : number)

return arithmetic mean (average) ofnumbers, or null if list is empty

mean([1,2,3]) = 2

mean(1,2,3) = 2

mean(1) = 1

mean([]) = null

all(list) all(b1 :boolean,…,bn :boolean)

return false if any item is false, else trueif empty or all items are true, else null InDMN 1.1 this function is actually calledand(list). It will be renamed to all(list) forDMN 1.2. ACTICO supports both names.

all([false,null,true]) = false

all(true) = all([true]) = true

all([]) = true

all(null) = null

all(0) = null

any(list : list) any(b1: boolean,…,bn :boolean)

return true if any item is true, else falseif empty or all items are false, else nullIn DMN 1.1 this function is actually calledor(list). It will be renamed to any(list) forDMN 1.2. ACTICO supports both names.

any([false,null,true]) = true

any(true) = all([true]) = false

any([]) = false

any(null) = null



Name Description Examplesany(0) = null

sublist(list : list,start position :number, length? :number)

return list of length (or all) elements oflist, starting with list[start position]. Firstposition is 1, last position is -1

sublist([4,5,6], 1, 2) = [4,5]

sublist(5, 1, 1) = [5]

append(list : list,item… : any)

return new list with items appended.items can be null

append([1], 2, 3) = [1,2,3]

append(1, 2, 3) = [1,2,3]

append([1], null) = [1, null]

concatenate(list… :list)

return new list that is a concatenation ofthe arguments

concatenate([1,2],[3]) = [1,2,3]

concatenate([1,2],[]) = [1,2]

concatenate([1,2],null) = [1,2,null]

concatenate([1,2],3) = [1,2,3]

concatenate(1,[2,3]) = [1,2,3]

insert before(list: list, position :number, newItem :any)

return new list with newItem inserted atposition

insert before([1,3],1,2) = [2,1,3]

insert before([1,3],-1,2) = [1,2,3]

insert before(1,1,2) = [2,1]

remove(list : list,position : number)

list with item at position removed remove([1,2,3], 2) = [1,3]

remove([1],-1) = []

remove(1, 1) = []

reverse(list : list) reverse the list reverse([1,2,3]) = [3,2,1]

reverse([]) = []

reverse(null) = [null]

index of(list : list,match : any)

return ascending list of list positionscontaining match

index of([1,2,3,2],2) = [2,4]

index of([1,2,3,[2]],2) = [2,4]

index of([1,2,3],4) = []

index of(1,1) == [1]

union(list… : list) concatenate with duplicate removal union([1,2],[2,3]) = [1,2,3]

union([1,[2]],[2,3]) = [1,[2],3]

union([1,2],[]) = [1,2]

union([1,2],4) = [1,2,4]

union([1,2],null) = [1,2,null]

distinct values(list :list)

duplicate removal distinct values([1,2,3,2,1] = [1,2,3]

distinct values([1, 2, [1]]) = [1, 2]

distinct values([]) = []

distinct values(1) = [1]



Name Description Examplesdistinct values(null) = [null]

flatten(list : list) flatten nested lists flatten([[1,2],[[3]], 4]) = [1,2,3,4]

flatten([]) = []

flatten(1) = [1]

flatten(null) = [null]

9.5. Numeric Functions

Table 9.5. FEEL Numeric Functions


decimal(n : number,scale : number)

return n with given scale scale is in therange [-6111..6176]

decimal(1/3, 2) = .33

decimal(1.5, 0) = 2

decimal(2.5, 0) = 2

floor(n : number) return greatest integer ⇐ n floor(1.5) = 1

floor(-1.5) = -2

ceiling(n : number) return smallest integer >= n ceiling(1.5) = 2

ceiling(-1.5) = -1

9.6. Sort Function

Table 9.6. FEEL Sort Function


sort(list : list,precedes? :function)

sort a list using an ordering functionprecedes, which must be a booleanfunction with 2 arguments. If the listitems are of the same type and the typesupports '<' and '>' comparisons, theprecedes function is optional and the listis sorted in ascending order.

sort(list: [3,1,4,5,2], precedes: function(x,y)x < y) = [1,2,3,4,5]

sort([7,2,4,6]) = [2,4,6,7]

sort(1) = [1]

sort(["Jeff", "Sarah", "George"]) =["George", "Jeff", "Sarah"]

Documents

DMN Modeling Guide - Version 8.1When a DMN model is created, it already includes one decision requirement diagram ( ) of the same name as the model. Figure 2.3. DMN model with diagram