This Knowledge Base article describes how to change when Actions are executed using execution blocks in the Rule Designer.
When Actions are added to a Rule, they are added at the bottom of the Rule statement or definition. Actions can be moved up or down to execute in a different order. You can also change how the Actions are grouped together into execution blocks. Execution blocks can either be sequentially, concurrently, or in a batch. The use of these blocks can affect how the Rule executes and are best used based on the Form’s scenario.
At the front of each Action statement, there is a word that can be changed. This word (then, and, or also) affects how the Action is called:
- Then, means one after another, and executes sequentially:
- The first Action executes, waits for it to complete, and then executes the next one.
- Execution is performed in a synchronous manner.
- And, means concurrently:
- All the Actions start at the same time, wait for all the Actions in the block to finish before going onto the next block. A good example is when using the Load/Initialize Rule Event, all the Get Lists for Views or Drop Down Lists can be populated together instead of waiting on one to finish before continuing to the next.
- Execution is performed in an asynchronous manner.
- Also, means in a batch:
- All the Actions are grouped in a single execution packet, and the runtime executes the packet in a batch on the server.
- Typically used for master or detail list of items, or single save scenarios.
- It is not a true transaction as there is no rollback.
- The K2 Service Object layer supports transactions, but SmartBox, which K2 smartforms is using, does not support transactions. If there is transactional support on the method call on the Service Object, then it is supported by K2 smartforms.
The execution of the Actions in the execution block is affected by the order of those Actions. Therefore, it is important to look closely at the execution blocks as well as the order of the Actions within the block to ensure that the Rule behavior is correct.
Take a scenario where you have a Rule and you want some Actions to execute one after another. When those are complete, you have another set of Actions that you would like to execute concurrently (both for performance reasons and because they aren’t dependent on each other).
When adding Actions, each statement is automatically added in one execution block as shown below:
To split the group, select another statement located in front of the Action.
A new line is added, which describes the execution block:
Actions can be ordered into these execution blocks. Simply change the statement to allocate it to a specific execution block.
As another example, let’s look at a subform. Let’s say we have a Rule for a subform list double click Rule, configured with the following Actions: 1) Transfer Data, and 2) Close the subform. The order of these Actions is very important.
When the subform is double clicked, it should populate a lookup control on the parent View. In this case, it would not be logical to first close the subform and then transfer the data to the lookup control. If the subform is closed first, the View would not have access to the data and would not be able to transfer the data to the lookup control. It would also not make sense to have these Actions happen concurrently, as the close Action could complete first before the data transfer Action, and again, the data would not be available for transfer. It is more logical to first transfer the data to the lookup control, and then close the subform.
It is therefore important to note the order of the Actions in the execution blocks and understand the differences between the execution types to select the correct execution type for the specific execution block.