Ruleflows

You can use different ruleflow elements to create your ruleflow in a project, such as start and end nodes, tasks, or transitions. A ruleflow specifies how tasks are chained together: how, when, and under what conditions they are executed.

You use ruleset parameters to 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.

You can also use ruleset parameters to transfer information between the ruleflow and the application. 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

Note: The appearance of ruleflows differs slightly across components. For example, the diagrams in this topic show ruleflows in Rule Designer. In the Business console, there are no icons below the rule task elements.

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.

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. You define the actions of an action task in the same way that you define the actions for business rules, by using BAL. Unlike the actions of business rules, however, action tasks can only use the action phrases associated with ruleset parameters. You can also define actions in IRL.

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.

Note: In transition conditions, variables cannot reference objects in the working memory. They can only reference ruleset parameters.

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.

Whenever multiple transitions come from a choice, the transitions must have Boolean conditions that specify which path to choose during execution. The last remaining empty transition is automatically computed as an Else transition.

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 and final actions 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.

Note: Like action tasks, initial and final actions cannot call methods on objects in the working memory. They can only call the methods of ruleset parameters.

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.