You are viewing the documentation for Blueriq 17. Documentation for other versions is available in our documentation directory.
REPEAT flow
You can repeat a subflow (flow in a flow) with a repeat expression. To do this, select the subflow and you will be presented with a box in the right top corner.
A repeat expression is an expression that results in a set of instances. For each instance in the set that results from the repeat expression, the flow is repeated. With each repetition an instance from the set is activated. You can determine the order in which the instances are activated by sorting on the value of an attribute (both ascending and descending). As the repeat expression is evaluated before the flow is repeated, alterations made on that set do not affect the repeat. Provided of course that you do not delete an instance that is used in the repeat. But if you were to add instances of Person in a flow while you are repeating over all instances of Person, the flow will repeat only over the originally existing instances.
Restrictions on repeat flows
The following restrictions on repeating a flow apply:
The flow that is repeated cannot contain pages
The flow that is repeated can only have one commit exit node
These restrictions ensure that a flow is repeated the same way for each instance. You can use a condition node in a repeat flow, as long as the flow ends with one commit exit node.
Repeat flow exit nodes
The expression can result in zero or more instances, when modeling this difference has to be taken into account. In case you attach an event name to the exit node in the subflow, the following exit nodes are possible:
- one with the event name and
- one without (only showing '[commit]')
- optionally one or more exit events of type Rollback
The first exit node will be used in case the expression results in one or more instances. The latter (without event name) is triggered when the expression results in zero instances. Both situations have to be modeled, otherwise you could get unexpected behavior. In case you don't attach an event name to the exit node in the subflow, you only see one exit node with '[commit]' in the flow. In that situation that exit event will always be taken, regardless of the number of results. In case the expression results in zero the subflow will be skipped and it continues with the 'main' flow.
Next to these events, you can also model cancel events, which break the repeat flow. You can have multiple of them, to distinguish between different error cases (e.g. a webservice call failed versus a record already exists in a system). The cancel events respect the transactionality of the flow, so either the profile is saved after the cancel (in a non-transactional flow) or it is roll-backed entirely (in a transactional flow).
Contrary to the repeat expression on a container, a repeat expression on a flow can also be an expression that results in an integer N (e.g. a COUNT
or SIZE
), or simply an integer. This repeats the flow N times, but there are no instances activated.
To illustrate this with an example: the expression ALL Person
repeats the flow for all the instances of Person and activates an instance of Person in each iteration. The expression COUNT(Person)
repeats the flow an equal number of times as well, but does not activate any instances. This means that, provided Person is in scope, if you would ask the value of Person.Name, in the first case you would get all the different names, while in the second case you would get the same name every time.
Repeat over primitive values
It is possible to repeat a flow for all primitive values in e.g. a multivalued attribute. When the expression results in a multivalued result of a primitive type, additional fields become available. Additionally, you can no longer specify a sorting attribute as the primitive value itself is used for determining the sort order.
As the repeat value, you specify a target attribute that is populated with the current iteration value, such that within the repeated flow you may access the current value using that attribute. The data type of the repeat value attribute must be compatible with the primitive type that is being iterated over. Once the repeat flow completes, the previous value of the attribute is restored or cleared if it was unknown before.