KB001432

Introduction

Changes have been made to the execution types of the Rule Designer in K2 smartforms 1.0.5. This Knowledge Base article describes how to change when actions are executed using execution blocks in the Rule Designer with K2 smartforms 1.0.5 and greater.

Definitions

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. These execution blocks can be moved up or down to ensure that the rule behavior is as expected. Execution blocks can either be sequentially, concurrently, in a batch or asynchronously. The use of these blocks can affect how the rule executes and are best used based on the View or Form’s scenario.

At the front of each action statement, there is a word that can be changed. This word (then, and, also or asynchronous) 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.
  • All actions in one execution block will complete before the next execution block will start executing the actions within that block.
  • Execution is performed in a synchronous manner.
  
  Execution time: 26 seconds before next execution block is started
• And, means concurrently:
  • All the actions start at the same time, wait for all the actions in the execution block to finish before going onto the next execution 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 a parallel asynchronous manner with a delay until all actions have been completed before continuing with the next execution block.
  
  Execution time: 8 seconds before next execution block is started
• 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 as it causes bigger packets to be handled to and from the server
  • 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.
  
  Execution time: depends on the server’s process time for the entire batch before next execution block is started
• Asynchronously:
  • All the actions start at the same time, when the first action completes the second execution block starts.
  • Execution is performed in an asynchronous manner. This is useful for non-dependent actions.
  
  Execution time: 5 seconds before next execution block is started

The execution of the actions within the execution block is affected by the order of those actions. Therefore, it is important to look closely at the execution block as well as the order of the actions within the execution block to ensure that the rule behavior is correct.

Examples

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 asynchronous (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, 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 asynchronous, 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.