"Pending in transaction" vs "Pending after transaction"

Applies to version: 2022.1.x and above; author: Łukasz Maciaszkiewicz

Introduction

The logic behind the execution of actions and the exact moment of their execution are often matters neglected by workflow designers. This often leads to misunderstanding of mechanisms controlling the execution of actions and misconceptions. 

To fill this gap, this article discusses the logic applied to the execution of actions on path in “Pending in transaction” and “Pending after transaction” modes and presents a diagram visualizing operations executed before, during, and after action execution.

Action execution modes

There are three basic modes for executing actions:

• Standard behavior: action is executed precisely where the automation flow was triggered;
• Pending in transaction: the execution of action is postponed until at the end of transaction, after all actions in the automation are executed. If any operation within the transaction fails, the action is not executed either. This rule also applies the other way round: failure of an action executed in this mode prevents execution of the whole transaction;
• Pending after transaction: the execution of an action is postponed. The action is executed after the end of transaction, i.e. after correct execution of all automations. What is important is that a failure to execute an action operating in this mode does not affect the execution of an already completed transaction.

The majority of actions available in WEBCON BPS operates in a standard manner, i.e. an action is executed precisely where it was embedded in automation. Actions that operate differently from the standard mode are presented in the table below, along with information on their mode or modes of action.

Note that “Pending after transaction” mode is available only for “Add a barcode”, “Read a barcode”, and “Run an SDK action”. For the “Add a barcode” action this is the only available execution mode, whereas in the case of the “Read a barcode” action the mode can be enabled by marking the “Execute outside the transaction” checkbox in the lower, left part of the “Configuration” window. For the “Run an SDK action” action the mode “Pending after transaction” is run by writing a code, compiling it, and uploading it to the system.

The logic of execution of actions and operations on path

The following actions are run precisely at the place they were embedded in the automation flow: Menu button, On browser opening, Upon instance deleting, On timeout, On attachment add, and On start (cyclical). In their case the “Pending in transaction” and “Pending after transaction” modes are ignored.

The above-mentioned rule is visualized in the below example. As the automation is triggered by the “Menu button”, all the defined actions are executed in the sequence they were embedded in the automation. The action “Add privileges” is executed after the “Read a barcode” action and before “Generate/Update a Word file” and “Convert Word to PDF”. The information on new privileges granted due to the execution of the afore-mentioned action is available for the action “Convert Word to PDF”.

Moreover, it is worth noting that the possible enabling of “Pending after transaction” mode for the “Read a barcode” action will not result in postponing its execution until after the end of transaction.

The actions executed on “Menu button” in the sequence of their embedding in automation

The “Pending in transaction” and “Pending after transaction” modes are intended to postpone action execution until at and after the end of transaction. The operation of these modes is particularly well visible in the “On path” transition. This is due to its nature as this type of transition involves a number of operations that can potentially change the state of data available in the database. Depending on the moment of triggering an action or automation they can refer to different data values.

What is equally important, the on-path transaction can involve three different automations, i.e. “On exit”, “On path”, and “On entry”.

 The “On path” transaction can involve three different automations

As demonstrated, the actions executed within the “On entry” automation use data whose state could (if they refer to the same form fields the actions in “On exit” and “On path” automations refer to and the values of these form fields have been changed) have been modified by actions executed in the “On exit” and “On path” automations.

However, the situation is different for actions executed in “Pending in transaction” and “Pending after transaction” modes.

For the first mentioned mode, the execution is postponed until at the end of transaction. What is more, for the actions in this mode to be executed, all actions in the transaction must be completed successfully. Postponing execution of actions of this type until at the end of transaction has another effect: actions and operations executed within a transaction can change form field values. If a “Pending in transaction” action refers to changed form fields, their values will be different from those seen by the user when configuring the action.

Setting an action in “Pending after transaction” mode also results in postponing its execution, but here the action is executed after the transaction is completed and it does not form a part of it. This means that contrary to “Pending in transaction” actions, potential failure in executing a “Pending after transaction” action does not affect the transaction and the changes it made. Similarly to the first case, the actions can refer to form field values changed in relation to the moment of triggering the transaction. 

Comparison of the moments of execution of “Send a custom email” (Pending in transaction) and “Read a barcode” (Pending after transaction) actions

Form fields vs. parameters

The potential change of form field values can be addressed by automation parameters. Unlike form fields, the values of parameters do not change in the course of transaction and remain the same as they were at the time of embedding in automation.

Timeout actions

An “On timeout” automation is a specific action trigger. An automation of this sort executes actions after a specific time elapses, e.g. from the moment of entering a step. The time after which an automation of this sort is run can be calculated based on more complex conditions that can also refer to form field values. The whole configuration allowing users to define the time the “On timeout” automation is run is called the “Insert condition”.

At the transition from one step to the other the “On timeout” automation “Insert conditions” are recalculated. As a result, old conditions are deleted and new ones are created in their place. The moment of recalculation of “On timeout” insert conditions is shown on the diagram below. 

Recalculation of “On timeout” action insert conditions

It is worth considering a situation in which the form field values change during “On timeout” automation. If those form fields are also used when executing “On timeout” automation insert conditions, their values will be from before the mentioned change.

An example of application of the action execution logic in practice

In order to understand better the discussed logic controlling the execution of actions in WEBCON BPS, let’s take a look at an example. 

Comparison of the moments of execution of “Send a custom email” (Pending in transaction) and “Read a barcode” (Pending after transaction) actions

Irrespective of the place of embedding actions in automation, the sequence of the executed operations in this case will be the following:

1. despite embedding the “Send a custom email” action as the first in the “On path” automation, its execution is postponed until at the end of transaction. Instead, the first executed action is “Convert Word to PDF”, then follow the operations specified on the diagram below the mentioned action. It is worth adding that although the “Send a custom email” action has not been executed yet, the automation parameters are saved;
2. the “Sign an attachment” action is triggered in the “On entry” automation and then follow all the operations shown on the diagram below this action. Due to the enabled “Pending after transaction” mode, the execution of the “Read a barcode” action is postponed, although it occupies first place on the diagram;
3. the “Send a custom email” action (executed in “Pending in transaction”) is triggered. It is worth noting that it is possible that the values of the form fields the action refers to have been changed in the course of actions and operations executed in the automation flow. Should there be no parameters configured for the action, at this point it uses those potentially changed form field values. A potential failure in execution of an action results in withdrawal of the whole transaction;
4. the transaction is completed and all the changes made by the actions and operations in the course of the transaction are saved in the database;
5. the “Pending after transaction” action is triggered, i.e. “Read a barcode”. Like in the case of “Pending in transaction” mode, if the action refers to form field values potentially changed by actions or operations, it refers to their changed state. Nevertheless, if the action refers to parameters, their value is the same as it was at the time of embedding the action. A potential failure of an action does not result in withdrawal of the whole transaction.