Introduction and Background

APEX 23.2 introduced Workflow as a native component specifically aimed at modeling and executing business processes. When a workflow encountered an error at a given activity, it went into the Faulted state. At this point, an Administrator or Owner of the workflow could retry the workflow. Retrying the workflow would resume its execution from the faulted activity. This is how most business process modeling and execution offerings (including those that follow BPMN 2.0 standard) work. Check out this blog which talks about how faulted workflows can be retried in APEX, prior to 24.2.

However, in real life use-cases, this kind of fault mitigation is quite restrictive.

One of the most requested capabilities of any Process Automation solution is to keep an existing Workflow instance running regardless of any issue that might occur during the lifetime of a Business Process including

  • Human Error
    Human Error can occur if a user enters some wrong data into a form and this data is then be used to branch in the Workflow (User enters amount of 100 instead of 1000 and later in the Workflow is a switch activity based on the amount) or if a potential owner of a human task accidentally approves a task but later decides to reject it for some reason or vice versa.
     
  • Error in Automated Task(s)
    The Workflow executes business logic with Execute Code  or Invoke API  activities. There might be errors in the implementation of this business logic which either results in an exception or sends the Workflow to an undesired path because the business logic returned some wrong values.

It is crucial for customers to have some control over running Workflows to fix issues in the workflow resulting from human- or business logic errors. Users prefer not to restart a workflow due to some error in the existing one as this means prior work needs to be redone; people involved in the workflow need to get involved again which can be costly and time consuming.

With APEX 24.2, an administrator of a Workflow can suspend the workflow and resume it at an arbitrary Activity within the Workflow. This makes the workflow more resilient and allows arbitrary re-routing of faulted/suspended workflows. The workflow can now be routed through a completely different set of paths rather than remain on its original course. 

Prerequisite

This blog assumes that the reader is well versed with the concept and terminology of APEX Workflow.

For users new to APEX Workflow, the following blogs introducing the concept of an APEX Workflow would be a helpful pre-read before proceeding with this blog:

Simplify Business Process Management using APEX Workflow

Multi-Level Expense Approval Using APEX Workflow

APEX Workflow Lifecycle

Example

The figure below shows the model of a simple Order Requisition Workflow in the Workflow Designer.

Order Requisition Workflow model

The workflow implements the following logic:

  • If the requisition amount is less than or equal to 1000 then it is auto approved and an Order is created.
  • Otherwise an approval task is created for the requisition and the order is created only after the requisition is approved.
  • After the order is created, it is sent for approval.
  • The Order status is updated based on the outcome of the Approve Order task.

Requisition ID, Item and Item Amount are input parameters to the workflow.

Running the Requisition Order application

The example below shows a table of Items, and a new requisition being submitted for Macbook Pro with amount as 2500 USD.

Submit Requisition

 

The submission triggers a new workflow. Since the item value is greater than 1000 USD, it is not auto-approved and a human task is created for approval of the requisition.

 

Requisition Workflow details

 

Requisition Approval Workflow In Progress

 

Say, at this point, the application user realizes this requisition is actually eligible for auto-approval because there was a verbal approval already received prior to the submission of the workflow. Prior to 24.2, the only way to auto-approve would have been to terminate the current workflow, and change the item amount or change the business logic for just this one requisition, and submit a new workflow. With the current enhancement,  the administrator of the Workflow can login to the Workflow Console, and open the details page to suspend the workflow.

The Administrator then updates the workflow variable Amount to 900 and saves the value. 

 

Update variable

 

Before clicking the Resume button, the administrator sets Update Requisition Status in Review as the activity from where the workflow should be resumed.

Select activity to Resume from

 

Once Resume is clicked, the Workflow is rerouted based on the updated Item amount and this time takes the auto-approval route.

 

Workflow rerouted

Note the Workflow activities and the Audit diagram. which shows that the Approve Requisition human task activity was terminated and the subsequent activities on its path were skipped.

 

Approve Requisition task terminated

 

Customizing the generated workflow details page

 

Let’s look at how the generated Workflow Details page can be customized  to select an arbitrary Activity and resume the workflow from there.

In the Buttons Region of the generated Workflow Details page, a new page item of type Select List, is added. This will be used to select the specific activity from where the workflow will be resumed.

The query to retrieve the Activity name and Static ID in a given workflow is as follows

select wa.name as name,
       wa.static_id as value
  from apex_appl_workflow_activities wa,
       apex_appl_workflow_versions   wv,
       apex_workflows                wf$
 where wf$.workflow_id = :P8_WORKFLOW_ID
   and wf$.workflow_version_id  = wv.version_id
   and wv.version_id   = wa.version_id
   and wv.workflow_static_id = wa.workflow_static_id

 

Activities LOV

 

The Page Process – Resume now has a new property: Activity Static ID Item. This is set to the page item that contains the Static ID of the selected workflow activity.

Static ID in Resume page process

Note: Similar to the Resume Page process, the API apex_workflow.resume is also modified to accept the static ID of the specific activity as an optional parameter.
 

begin

    apex_workflow.resume(

         p_instance_id          => 1234,

         p_activity_static_id   => 'UPDATE_REQUISITION_FOR_REVIEW')

When no static ID is provided, the Resume API works as in previous releases, i.e., the workflow resumes at the activity where it was waiting, at the time of suspension.

 

Conclusion

The above example shows how easy it is to design an application where a submitted workflow can be rerouted by the Workflow administrator. This post demonstrated resuming the workflow from an upstream activity, however, it is also possible to resume from a downstream activity (an activity that appears later in the workflow), using the same approach. 

You can also read about the other significant workflow enhancements in release 24.2 in this blog.