For decision logic modeling it provides a language called FEEL for defining and assembling decision tables, calculations, if/then/else logic, simple data structures. Please see the FEEL reference for more details.

Decision Table

Decision table is a logical expression for decision elements in model. Table contains all (and only) the inputs required to determine the output. Moreover, a complete table contains all possible combinations of input values (all the rules).

A decision table consists of;

• An output label, which can be any text to describe output of the decision table. The result of a decision table must be referenced by decision name, not the output label, in another expression.
• A set of inputs (zero or more). Each input is made of an input expression and a number of input entries.
• A set of outputs (one or more). A single output has no name, only a value. Two or more outputs called output variables. Each output variable is named and all output entries is referred as an output clause.
• A list of rules (one or more) in rows of table.

The decision table shows the rules in a shorthand notation by arranging the entries in table cells. This shorthand notation shows the all inputs in the same order in every rule and therefore has a number of readability and verification advantages.

For example;

read as;

If CustomerCategory = "Business" and OrderSize < 10 then Discount = 0.10

An input expression value satisfies an input entry if the value is equal to the input entry, or belongs to the list of values indicated by the input entry (e.g., a list or a range). If the input entry is ‘-’ (meaning irrelevant), every value of the input expression satisfies the input entry and that particular input is irrelevant in the specified rule.

In general table expressed as;

If input entry is "-" (meaning irrelevant), every value of input expression satisfies the input entry.

If rules overlap, multiple rules can match and a hit policy indicates how to handle the multiple matches.

Input expressions

Input expressions are usually simple FEEL expressions. Order of input expressions is not related to any execution order.

Output expressions

A rule output entry is a also FEEL expression. Output expressions also have default value if no output entry is specified.

Hit Policy

The hit policy specifies the what the result of decision table is in cases of overlapping rules, ie. when more than one rule matches the input data. For clarity, the hit policy is summarized with using single character of policy name.

Single and multiple hit tables

A single hit table may or may not contain overlapping rules but returns the output of only one rule. In case of overlapping rules, the hit policy indicates which of the matching rules to select. 

A multi hit table may return the output of multiple rules or a function of outputs. For example, sum of values.

Single hit policies

• Unique: no overlap possible and rules are disjoint. Only a single rule can be matched. This is default value of hit policy. If given input matches the multiple rules hit policy is incorrect and MultipleHitViolation error is thrown.
• Any: there may be overlap, but all of the matching rules must equal output entry values for each output so any match can be used. If output entries are non-equal, the hit policy is incorrect and result is undefined.
• Priority: multiple rules can match, with different output entries. This policy returns the matching rule with the highest output priority. Priorities are independent from rule sequence.
• First: Multiple (overlapping) rules can match, with different output entries. The first hit by rule order is returned and evaluation halt. First hit tables are not considered good practice because they do not offer a clear overview of the decision logic. 

Multi hit policies

• Output Order: returns the all hits in decreasing output priority order.
• Rule Order: returns the all hits in rule order. Therefore may depend on the sequence of rules.
• Collect: returns the all hits in arbitrary order. An operator can be added to apply simple function to outputs. If no operator specified, result is list of the all output entries.

Collect operators are;

1. 1. 1. Sum (+): sum of all the distinct outputs.
      2. Min (<): smallest value of the all the outputs.
      3. Max (>): largest value of the al the outputs.
      4. Count (#): number of the distinct outputs.

For the Priority and Output Order hit policies, priority is established by considering the from matching input columns order. Columns at left take precedence over columns to the right. For example;

If called with Age=17, Risk Category="HIGH" and Dept Review=true, the following table outputs of all four rules, in the order 2,4,3,1.

Calling Decisions

Decisions can be called as a "decision service" from scripting environment and also can be called from rest service. 

Scripting Environment

To call a decision from scripting calling convention is;

var result = $Decisions.<DecisionName>( inputData );

DecisionName donates the name of decision in graph.

InputData can be a javascript object or xml data. Also combining xml data and JSON objects is supported.

Please note If decision is has one output expression result is direct value of resulting output. If decision has more than one output expression, result is always an javascript object and output expressions are property of resulting object.

Javascript Object Example 

var result = $Decisions.MyDecision({
  Product : 'Candy',
  Units : 30
});

Xml Data Example

var result = $Decisions.MyDecision( $Xml.SelectSingle('Order' );

Please refer to scripting reference for more details and examples.

Rest Service

Please refer to the rest service documentation for more details.

Example Decision Model