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 is 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. It is executed by automatic client (see the staff assignment rule in the next image). The following wizard page opens direct after inserting the XOR activity and is used to configure the activity. To do this, assign the SAR by clicking the corresponding arrow and then go to the next page. On the next page, the XOR decision parameter is displayed as input and output parameter. We don't need change anything and go to the next page Dimensions. This determines which variable the decision is based on. By double-clicking on the Weight variable, it is inserted into the dimension field. In the drop-down box, for this example, let's leave it at the default Constants. Now for each dimension (in this case only one) predicates must be defined. The opening dialog (see next image) with error shows us that the entire input value range is not yet covered. To form the predicates we can use the usual comparison operators (<, ≤, =, ≥, …) and use integer constants as limit values. We specify the predicates as at the beginning given in the example and obtained as a result the next image in which all intervals are covered. On the page Desicion Labels, the predicates are assigned to decision Labels. A decision label can be freely named or have the same name as the predicate(Add Auto). To do this, click Add Auto for each predicate. You can also assign multiple predicates to the same label, then these predicates become a group and linked with XOR. The decision identifier is also used later to appropriately label the edges of the XOR branch. On the next page, you can see a summary of the decision labels and decision statements. In the last step, you can assign the decision identifiers to the edges whereby several identifiers can also assigned to an edge. As with the groups, this then corresponds to an XOR connection of the predicates. We assign here each decision label to its own edge. To do this, use the arrow between the label and edge fields as in the next image.