Skip to main content
Skip table of contents

Rule

image-20241001-091339.png

The Rule component allows to depict rules for decisions within a Business Process. The rules to be applied are defined within decision tables (.rule) according to DMN 1.1. The rules can be automatically checked, and the results will be passed to the Business Process for further processing.

DMN is a standard for modeling decisions within Business Processes. The standard DMN also defines the Simple Expression Language (S-FEEL), a formal expression language for defining a decision logic.

DMN 1.1 with S-FEEL is available online under https://www.omg.org/spec/DMN/1.1/.

Properties

Label

Label of the symbol within the process diagram

Creating and Defining Rules

  • Default values of type Integer and Decimal cannot be empty.

  • For the types Integer and Decimal, it is not possible to check if the value is empty.

To better depict rules for decisions in Business Processes, rule modules can be used when modeling Business Processes. These can then be linked to a decision table (.rule) in which the rules are defined.

Combining decision tables

Any number of decision tables can be combined in a Business Process. Output values of one table thus become input values of the following tables. Thus, complex decision trees with corresponding branches can be modeled.

Decision tables (.rule) are created below the Business Process via the context menu New > Rules or via the toolbar 

 > Add rules. After the creation, the decision table is opened in X4 Designer.

No.

Element

Description

1

Toolbar

Functions for editing decision tables, depending on context and selection

2

Header area

Settings for defining input and output, whereby several inputs and outputs are possible.

The following cells are available to define the input and output:

  1. Free text field for the column name

  2. Input or output source

    • Input / Output: Input from the BPMN process respectively output to be passed to the BPMN process

    • Parameter: Selection of a parameter (only available for input)

    • Variable: Value stored in a variable

    • Case State: Selection of a status 

    • Case Feature: Selection of case data

  3. Data type of the input or output  (stringnumberboolean)

  4. Input path as free text field or selection (depending on the input source) respectively name of the output or variable as free text field or selection (depending on output destination)

3

Annotation

Comment field that is not displayed in the output

4

Rules

Rules determining how inputs are to be transformed into outputs.

Rules are defined per line in the decision table, whereby the row order determines the check order. A rule has at least one column for processing the input values (Input) and at least one decision result (Output).

Rules in the decision table are entered in the S-FEEL notation. This allows the decision logic to be described in natural language "business-friendly". As a formal markup language with fixed semantics, grammar and defined rules, it allows at the same time the interpretation and execution of values. S-FEEL can interpret strings, numbers, simple arithmetic operations and simple comparison tests.

Please note:

  • Set strings in quotation marks, e.g. "Head of department".

  • For decimal numbers, use a dot as separator, e.g. 5.1.

  • If the value of a cell within the input column is not relevant for a rule, enter according to S-FEEL a - (minus sign) into the cell.

  • A decision table can contain a fallback rule that always applies. For this purpose, all cells of the input columns of a fallback rule contain a - (minus sign). 
    Whether a fallback rule makes sense and where it should be in the check sequence depends on the hit policy and the use case.

5

Hit policy

Setting regarding the displayed results. It determines how many rules of a decision table can apply and how the results are output.

Rules can be defined in a way that the number and selection of results violates the Hit Policy. In this case, the rules or the hit policy must be corrected depending on the application.

Significance

Possible hit policy violation

U (Unique): Only one rule can match and exactly one result is output.

  • No applicable rule
  • Multiple applicable rules

F (First): One or several rules may apply, but only the first result is output.

(info) Consider the check order!

No applicable rule

A (Any): One or several rules with the same result may apply, but only one result is output.

  • No applicable rule
  • Multiple applicable rules with different results

C (Collect): All applicable results are­ output without a fixed output sequence.

No applicable rule

The finished BPMN process with the decision table can be validated and checked for errors within the X4 Designer and executed on the X4 Server.

Decision tables can lead to three results:

Icon

Description

The Rule component returns one or several results. The intermediate result can be opened.

The Rule component does not return any results. Possible causes:

  • None of the defined rules apply to the input.

  • The rules are incorrect, e.g. spelling error.

  • The hit policy is not suitable.

The Rule component returns an error because the decision table does not conform to S-FEEL. A report with an explanation of the error can be opened.

S-FEEL Expressions for Defining Rules

Operator / Expression

Description

Comparison

10

Checks whether the input value corresponds to the specified value, e.g. 10

  • v:[Variablename]

  • f:[Featurename]

  • p:[Placeholdername]

  • c:[CaseState]

Performs a check based on a variable, feature, custom placeholder, or case state

By pressing the shortcut Ctrl + Space all currently available variables, features, parameters and case states are displayed in a drop-down list.

< 

Checks whether the input value is smaller than the specified value, e.g. < 10

<=

Checks whether the input value is less than or equal to the specified value, e.g. <= 10

> 

Checks whether the input value is greater than the specified value, e.g. > 10

>=

Checks whether the input value is greater than or equal to the specified value, e.g. >= 10

not()

Checks whether the input value is not less than or equal to the specified value, e.g. not(<=10)

Interval

[1..10]

Checks whether the input value is greater than or equal to the start value and less than or equal to the end value.

(1..10]

Checks whether the input value is greater than the start value and less than or equal to the end value.

[1..10)

Checks whether the input value is greater than or equal to the start value and less than the end value.

(1..10)

Checks whether the input value is greater than the start value and less than the end value.

Disjunction

3,5,7

Checks whether the input value is 3,5 or 7.

<2,>10

Checks whether the input value is less than 2 or more than 10.

10,[20..30]

Checks whether the input value is either 10 or between 20 and 30.

"Meier", "Müller, "Weber"

Checks whether the input value is either Meier, Müller or Weber.

An extensive reference to the syntax of the S-FEEL notation can be found in the current specification for DMN 1.1 (Chapter 9) of the Object Management Group under https://www.omg.org/spec/DMN/1.1.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.