163 views

Overview


This article contains examples to clarify how workflow activities are processed in transactions. It provides supplementary information for the product documentation topic Workflow engine operation order.

Dividing the workflow into different transactions


Examples 1 and 1b demonstrate how the workflow divides workflow activities into different transactions. Approval activities – Wait for Condition, Wait for WF Event, Create Task(Wait for completion set to true) – and Timer activities have a similar effect.

Example 1

This is a Default workflow, and the Approval 1 activity has one approver. The engine order is:

  1. Before business rules with order less than 1000
  2. Workflow: Begin > Script 1 > Set Value 1 > If 1 > Notification 1 > start of the Approval 1 [workflow engine stops here]
  3. Before business rules with order greater than 1000
  4. Database operation
  5. After business rules

 

Example 1b

This is a Default workflow, and the Approval 1 activity has no approvers. Therefore, the result of the approval will be skipped. In this example, the approval activity will not stop the workflow execution and the whole workflow will finish in one transaction.

The engine order is:

  1. Before business rules with order less than 1000
  2. Workflow: Begin > finish all the activity > End
  3. Before business rules with order greater than 1000
  4. Database operation
  5. After business rules.

 

 

Timer Activities


These examples show sample workflows with and without Timer activities.

Example 2

This example shows a workflow on sc_req_item without Timer activity.

This example has a typical customization in the Run Script activity, which sets the parent record (sc_request) Requested For field based on requested item variable. The script is as follows:

runThis();
function runThis(){
var reqRec = new GlideRecord("sc_request");
reqRec.addQuery("sys_id", current.request);
reqRec.query();
 
if (reqRec.next()){
reqRec.requested_for = current.variables.v_requestor;
reqRec.update();
}
}

The script updates the parent record and also gets a value from current.variables.v_requestor, which appears to be correct. However, when the parent sc_request is inserted, the workflow on sc_req_item will start right away if the parent request is automatically approved. Therefore, the workflow on sc_req_item will be executed within the same transaction as the sc_request that was inserted. The script in the workflow will cause a double update on sc_request. Also, the value of currents.variable.v_requestor becomes unpredictable.

Example 3

This example has a similar design to Example 2 but has Timer activity before the script. The timer in the workflow divides the workflow into separate transactions, which fixes all the issues in Example 2. The activities executed in the first transaction are:

  1. Begin > Start of the timer (creates the sys_trigger record of the timer.)
  2. When the time in the timer is up, the following will be executed in separate transaction.
  3. Timer (finished) > Set Requested For > Delivery Task 1 (started)

The sc_request update in the script is no longer a problem, and current.variables.v_requestor will have a final value.

 

Article Information

Last Updated:2018-03-07 20:51:48
Published:2018-03-08