Skip to content

XOR Activity

In an XOR block, the process execution is splitted into alternative paths. At runtime the execution manager decides which path to take based on process data. In an XOR block, only one of the branches that lies between the XOR split and the join node is retrieved. To determine this branch path, the XOR split node must always have a decision activity and a SAR (staff assignment rule) assigned to it. The XOR join node can also be a null node.

The Process Template Editor offers two operations to create an XOR block in a process graph, namely 'Insert XOR Block' and 'Surround with XOR Block'. 'Insert XOR Block' is applicable when the start and end markings follow one another immediately in the control flow. In this case, an XOR block with only one branch is inserted, as shown in the next image. If a node is inserted into this empty branch and the split and join node of the XOR block is marked, then the 'Add Branch' operation is enabled and you can insert another (empty) branch if you wish. If you also add a node to this branch, 'Add Branch' is activated again and you can add another branch, etc.

'Surround with XOR Block' is applicable if only one node is marked or if there are one or more nodes between the start and end markings. In this case, an XOR block with only one branch is also inserted, but the entire previously marked block is now in this branch. Since this branch is not empty, the 'Add Branch' operation is enabled immediately, if the split and join node of the XOR block is marked. Additional branches are then added as described above. To delete the border nodes, you also need to mark the split and join node of the XOR block.

Initialer XOR Block

The XOR predicate template can be inserted in the split node via drag and drop from the 'Activity Repository Browser'. The XOR activity can have any number of (but at least one) input parameters and has at least an internal and an external decision parameter.

Assign XOR Predicate to split node

The internal decision parameter determines internally in the form of a path number (0, 1, 2, ...) which path the execution should continue with. The external decision parameter also makes this value available via output parameter in a data element so that subsequent activities can access it as needed. The paths in an XOR block are default numbered 0, 1, 2, ..., but can also be provided with “corresponding” edge labels when assigning decision-making activities.

The XOR predicate template was designed in such a way that even with complex predicates it can be guaranteed that they are “by design” both non-overlapping and cover the entire (possibly multi-dimensional) input value range. But in the following we will limit ourselves to the use of the XOR predicate template for simple (one-dimensional) predicates using one example.

Example: One-dimensional predicate with constants

Modeled XOR activity with three paths

We have a parameter 'Weight' and want to distinguish the following cases:

  • If the weight is less than 70 kg, we will not take any further action
  • We classify a weight between 70 and 110 kg as “medium”
  • and we classify a weight over 110 kg as “heavy”

Our XOR activity has one input parameter and must be able to choose between three alternative paths.