Ruleflows

Ruleflows are a way of controlling rule execution. They are made of linked tasks that contain the instructions for which rules to execute and in what order. The links between the tasks are called transitions.

A ruleflow specifies how tasks are chained together: how, when, and under what conditions they are executed. When a project contains several ruleflows, one of them is identified as the main ruleflow and can reference other ruleflows through subflow tasks.

You use ruleset parameters to transfer information from one ruleflow task to another and to transfer information between the ruleflow and your application.

Ruleset parameters transfer information between ruleflow tasks, and determine which path to follow through the transitions. For example, you can transfer a status variable, such as isEligible, to determine which task to go to next.
Ruleset parameters transfer information between the ruleflow and the application and the application obtains the results of ruleflow processing through ruleset parameters. For example, after the ruleflow ends, the parameter can return an aggregated report, diagnostics, a set of compliance exceptions, or computed values, such as prices, rates, or taxes.

The following diagram shows the main parts of a ruleflow:

Start node 1
Task 2
Transition 3
End node 4

Start nodes and end nodes

A start node Start node icon and an end node End node icon are graphical markers for the start and end of a ruleflow. Every ruleflow has one start node and at least one end node.

Ruleflow execution begins at the start node and stops at one of the end nodes, along the path defined by the ruleflow.

Tasks

Between the start node and the end node, the ruleflow is made of tasks linked by transitions.

The tasks of a ruleflow contain the instructions for what to execute and in what order:

Rule task

A rule task Rule task icon contains a set of rules to be executed at that point in the ruleflow.

Depending on how the execution properties of a rule task are set, the rules might execute in order, or following a more complex logic.

The execution mode of a rule task determines whether the rules are executed in the order shown (sequential mode), in order with some optimization at compile time (Fastpath mode), or in an order determined by the rule engine (RetePlus mode).
The runtime rule selection filter determines which rules in a given rule task are executed. The rule selection filter is applied at run time and the rule engine evaluates only the rules that pass through the filter. You write a runtime rule selection filter like a condition in an action rule, except that in the filter statement you can use only rules, rule properties, and any ruleset parameters defined for the rule project.

For example, you can write the following runtime rule selection filter:
```
the author of 'the rule' is "Sally"
```
With this filter, the rule engine evaluates only the rules written by Sally.

Action task

An action task Action task icon contains rule action statements to be executed.

Subflow task

A subflow task Subflow task icon references another ruleflow to be executed. The referenced ruleflow can be any other ruleflow in the rule project. You can self-reference a ruleflow, but be careful to avoid infinite loops.

You can specify initial and final actions on subflow tasks.

Transitions

Transitions connect tasks in a ruleflow and define the sequence of the ruleflow from one task to another. Transitions are unidirectional and can have associated conditions.

Transition conditions determine whether a transition is part of the execution flow. You define these conditions in the same way as conditions in an action rule.

For example, with the following condition on the transition between the eligibility and pricing rule tasks, the pricing rule task can be performed only when the customer’s rental agreement is accepted, otherwise the ruleflow ends.

A single transition from one task to another does not require a condition. However, when several transitions originate from a task, you use transition conditions to define under what conditions a specific path is followed in the ruleflow.

An Else transition specifies the path to take when a condition is not met. A task can be followed by several transitions but only one of them can be an Else transition. This means that all transitions except the Else transition must have conditions.

Branches

A branch Branch icon is a node that organizes conditional transitions. For example, a branch for the age of a customer organizes transitions with conditions on a given age range. Several transitions can go to and from a branch. Like transitions created from a task, all transitions created from a branch must have a condition, except the Else transition.

Forks and joins

A fork Fork icon is a node that splits the execution flow into several parallel paths. The transitions created from a fork do not have conditions because all transitions created from the fork are followed.

A join Join icon is a node that combines all the transitions created from a fork when the parallel paths are all completed.

Initial and final actions

You can define initial actions Initial action icon and final actions Final action icon on tasks. Initial actions apply before a task is processed and final actions apply after a task is processed. You define initial and final actions in the same way as you define actions for an action task.

A task execution sequence consists of executing its initial actions, then its body, and then its final actions.

Initial and final actions are not mandatory and you can use them independently of each other.

You can also specify actions to be executed at the start and end nodes. For example, you can define an action on the start node to reset the data used in the ruleflow. Actions defined for an end node also apply to any other end nodes in the ruleflow.