The rule definition toolbar is available at the top of the rule definition section and can be used to order and manage rules. The execution of the actions within the execution block is affected by the order and execution type of those actions. Therefore, it is important to look closely at the execution blocks as well as the order of the actions within the execution block to ensure that the rule behavior is correct.

Comments

Comments can be added on the following levels and will be indicated with a speech bubble on the right of the canvas when applied:

• Event
• Condition
• Action

Clicking on an existing speech bubble or creating one from the toolbar or popup menu will open a dialog box to add comments. When hovering over a speech bubble containing a comment, a tooltip is displayed with the comment for ease of use. Comments can only be edited on the level at which it was created, for example if a comment was added on a rule on View level, the comment can only be edited on View level. This means that comments cannot be applied to inherit actions, however, comments that were added on parent level will be visible on inherited actions.

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 one after another, concurrently, asynchronously or in a batch. The use of these blocks can affect how the Rule executes and are best used based on the View or Form’s scenario.

Rules and their execution types should be seen in context of a more holistic solution. Rules and Actions provides the ability to construct a logical path for the user, for example validate the Form, prompt for confirmation before saving, perform a save, show a message, or navigate to another Form. Some of these Actions can happen concurrently, whilst others should wait before continuing with the rest of the Actions. The Execution blocks can therefore be used for more complicated executions and not just method executions.

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.

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.

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 transactions are not available in SmartBox, which K2 smartforms is using. If there is transactional support on the method call on the Service Object, then it is supported by K2 smartforms.
• In a batch is only applicable and advisable to execution Actions for example Execute a SmartObject, in specific scenarios like the single save concept or Editable Lists where you need to save all the (multiple) instances of the data at once.

Asynchronous - Means asynchronously:

• All the actions start at the same time and execution continues to the next execution block.
• Execution is performed in an asynchronous manner. This is useful for non-dependent actions.
• Listing controls such as Picker, Drop-Down List, Check Box List, Radio Button List and List Display now support loading their list values without needing a spinner blocking the entire View or Form from being accessed. These controls contain their own spinner/ modalizers to indicate that they have not fully loaded yet. The controls will store the value they are set to and return it correctly (if requested via an action) even before they are finished loading allowing the rest of runtime to continue execution.

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.  

The settings option allows the user to provide a name and description for the rule. Rule names should be unique per context, for example per View, per Form, per Form state and per View on a Form. If a rule name is not specified, the name will default to the event used in the rule. The description will show as a tooltip when hovering over the rule in the rule grid.