Business Processes are everywhere, from simple expense approval workflows to more complicated and organizational unit spanning processes like Order-to-Cash. Starting with Oracle APEX 22.1 we’re on a journey towards delivering a complete solution for Digital Process Automation that is fully integrated into the well known developer experience of Oracle APEX. In our 22.1 release we added the Approvals Component which we further enhanced with the release of 22.2. In this article we first give an overview of its new features in Oracle APEX 22.2 and then offer an outlook on where our journey is taking us next regarding Workflows and Digital Process Automation. 

Oracle APEX 22.2 Approvals Component

In version 22.2 of Oracle APEX we enhanced the Approvals Component in some areas that we’d like to describe in a bit more detail in this blog post. For an introduction of the Approvals Component please see the three earlier blogs on this topic by my colleague Ananya Chatterjee [2], [3], [4]

New Lifecycle States

We enhanced the Approvals Component to support ‘Request for Information’ and ‘Deadlines’ for Tasks, hence there are additional States for the Task Lifecycle in Oracle APEX 22.2 as shown in Figure 1 below. We will give a detailed description of the two new features and how they are related to the new lifecycle states in this blog post.

Request Information

There are many situations where the Approver (for example a manager) of a Task needs additional information from the requester (for example an employee) of the Task in order to Approve or Reject the Task. For example, if an Employee requests to purchase a new Laptop for his work with a certain price, the Manager of the Employee might want to know the age of the old laptop and a justification for the additional accessories along with the laptop request. In Oracle APEX 22.2 Approvals Component this can be achieved by the new ‘Request Information’ operation exposed in the Task Details Page and public API.

Figure 2 shows the Task Detail for a new Laptop request in the Sample Approval app by logged in user ‘JANE’ who is the actual owner of this task. Please note the new button ‘Request Information’ that can be used to assign the task back to the initiator of the request together with some message on what information is needed in order to approve or reject the task.

Once the ‘Request Information’ button is pushed, the Task will be assigned to the Initiator for providing the requested information. Figure 3 shows the ‘My Requests’ Task List from the perspective of the Initiator. Please notice the Task has transitioned to ‘Information Requested’ state, so the Initiator knows that some input is needed in order to make progress with the task.

When the initiator opens the Task, the Task Details page offers the option to submit the required information (see Figure 4). The requested information is available in the Comments region of the Task Detail page for the initiator to know, what kind of info is missing. The initiator can provide some message when submitting it. When the information is submitted, the Task transitions back to ‘Assigned’ state for the Actual Owner that requested the information in the first place (in our example JANE) to Approve or Reject the Task.

Task Actions for events ‘Request Information’ and ‘Submit Information’ can be specified in the Task Definition Actions settings of the Task (under Shared Components  Workflows and Automations  Task Definitions)

Deadline and Expiration Policy

When we introduced the Approvals Component in Oracle APEX 22.1, Developers could specify a Task Due Date based on an Interval specification in the Task Definition of a Task. We enhanced this functionality and added a new ‘Deadline’ region in the Task Definition for a more flexible specification of a Task Deadline and what should happen with a Task, once the Due Date is reached. In Oracle APEX 22.1, nothing happened with the Task once it was overdue (other than highlight the due date in red color in the Unified Task List).

Figure 5 shows the Deadline region in the Task Definition of a Task with the following enhancements compared to Oracle APEX 22.1

• Due On Type
  The Due Date can now be specified by an Interval (only option in 22.1), a SQL Query, a Function Body, an Expression or a (DBMS_SCHEDULER compatible) Scheduler Expression. This is quite powerful as the due date can now depend on some business data stored in a database and retrieved by a SQL query or PL/SQL function.
• Expiration Policy
  The Expiration Policy specifies what to do with a Task, once the Due Date is reached and as such the Task has ‘expired’. The options here are ‘None’, ‘Expire’ and ‘Renew’, see Figure 6

The input field ‘Maximum Renewal Count’ is available for Expiration Policy ‘Renew’, otherwise it can’t be specified. See exact semantics below. 

The semantics behind the Due Date and Expiration Policy is the following

• There is a background job ORACLE_APEX_TASKS_EXPIRE running in Oracle APEX that checks the Tasks due date and expiration policy every hour.
• If a Task due date has passed (in which case, we say the Task has expired) we execute any defined ‘Expire’ Task Actions for the Task and then apply the Task Expiration Policy.
• For the ‘None’ Task Expiration Policy nothing happens with the Task (this is the 22.1 behavior). The Task remains in ‘Assigned’ or ‘Unassigned’ state patiently waiting for a Potential Owner to Approve or Reject it
• When the policy is set to ‘Expire’ and the task due date is reached, the Task transitions to state ‘Expired’ and disappears from the User Task List. Expired Tasks can be ‘renewed’ by Business Administrators though.
• In the case where the task due date is reached and the policy is set to ‘Renew’, we transition the Task to state ‘Expired’ and create a new Task. The new Task is created using the same Task Definition of the expired Task. The Task Parameter values of the expired Task are carried over to the newly created Task. All other settings are re-calculated from the corresponding Task Definition. This includes the Task Participants and Due Date. The newly created Task is ‘linked’ to the expired Task so that a user can get the full history and comments from the chain of tasks. A Task with expiration policy ‘Renew’ is renewed up to its Maximum Renewal Count after which the Task (the last in the chain of renewals) transitions to ‘Expired’ state. As the renewal count and maximum renewal count are available as Substitution Strings, the values can be incorporated into the logic for assigning the Task Potential Owners and Business Administrators.
• Expired Tasks can be renewed by Business Administrators from the Unified Task List and the Human Task – Manage page plugin was enhanced to support this.

The job ORACLE_APEX_TASKS_EXPIRE can be triggered via public API APEX_APPROVAL.HANDLE_TASK_DEADLINES. This is convenient for developers to test Task Expiration policies without waiting for the background job to kick in every hour.

Task Actions

With the release of Oracle APEX 22.2, new Task Actions have been added. Table 1 provides an overview of the newly added actions.

Table 1: New Oracle APEX 22.2 Task Actions

Task Substitution Strings and Bind Variables

Table 2 gives an overview of the new Task Substitution Strings introduced with 22.2 release of Oracle APEX

Table 2: New Task Substitution Strings in Oracle APEX 22.2

Copy of Task Definition

We added functionality for a Developer to create a new Task Definition based on a copy from an already existing Task Definition. This is convenient for similar kind of Tasks where certain settings (like Participants, Parameters, Actions etc.) of a Task Definition might be reused. For this we added a ‘Copy’ button under Task Definitions (see Figure 7)

When the Developer clicks on the ‘Copy’ button, a dialog as in Figure 8 appears

It is worth noting that Task Definitions can be copied from other APEX Applications in the same Workspace as well. When copying a Task Definition, the Task Detail URL is not copied over.

API’s

Table lists the new API’s introduced in package APEX_APPROVAL with Oracle APEX 22.2

Table 3: New APEX_APPROVAL API’s in 22.2

Unified Task List and Task Details, how are things coming together

Figure 9 gives an overview of the relationships between Unified Task Lists (for My Tasks, Initiated by Me and Admin Tasks), Task Detail Pages and Task Definitions

• Unified Task Lists can be created one or more times in any APEX Application. Unified Task Lists always show ALL Tasks for the logged in user and type of Unified Task List (My Tasks, Initiated by Me, Admin Tasks).
   
• There is a relationship between a Task Definition and a Task Details page, many Task Definitions have their own Task Details page associated but that is not mandatory. Task Detail pages can be created from the Task Definition editor. If a Task Details page should be reused, then the URL of it can be manually copy and pasted from one Task Definition into the appropriate (other) Task Definition.
   
• If Unified Task Lists and Task Detail Pages are spread across APEX Applications, Workspace Session Sharing must be configured in the Authentication Scheme of all involved apps. This is to enable access to Task Detail pages from Unified Task Lists in different APEX Applications.
   

This will enable complete freedom for the Application Developer in which APEX Application(s) to create the Unified Task List(s).

Task Management

We received many questions and comments on what is happening with existing Tasks (Task Instances to be more precise) in cases where Task Metadata is deleted from the APEX Application and/or Workspace. Here’s the behavior as of Oracle APEX 22.2 Patchset 1 (on-prem) and Oracle APEX 22.2 Patchset 2 (Cloud)
 

• Task Definition of an APEX Application is deleted
  If a Task Definition of an APEX Application is deleted from the Application, The Task Instances created from this Task Definition remain in the Database but are no longer visible in the Unified Task List. This behavior might change in future releases of Oracle APEX.
   
• APEX Application is deleted from APEX Workspace
  When an APEX Application is deleted from a Workspace, all the Tasks created from a Task Definition of this application are also deleted.
   
• APEX Application is re-imported from export file with same Application ID
  Let’s say you have an application running in Production with a certain Application ID (e.g. 100) and there are Tasks created by this Application. Now if you make changes to this Application in a Development Environment and export this Application for import into Production, then if you chose to overwrite the existing Application in Production with the same App ID, all Tasks Instances created earlier by this same Application will be preserved in Production. 
   
• Task Archival and Purge
  There is a job ORACLE_APEX_TASKS_PURGE running every hour that checks for completed, canceled, expired and errored tasks, Completed Tasks are archived and purged after a configurable Retention Period (default 7 days, maximum 30 days) whereas errored, expired and canceled tasks are purged right away. The Retention Period can be configured as part of the APEX Instance Settings.

APEX Workflow

With the release of Oracle APEX 22.1 we started a journey towards a full Digital Process Automation solution including a full Workflow Designer, Runtime and Management built natively into Oracle APEX. Before we highlight some of the core principles of APEX Workflow it is worthwhile mentioning that with Flows for APEX [6], there already exists a comprehensive Workflow solution based on the OMG BPMN 2.0 standard [5]. Flows for APEX is an Open-Source product with Oracle being actively involved in the development and continuous improvement. As an example of Oracle’s commitment to Flows for APEX, the latest version (22.2) of Flows for APEX is fully integrated with the Approvals Component; the BPMN 2.0 User Task has the option to create tasks using the Oracle APEX Approvals Component.
 

APEX Workflow on the other hand will NOT be based on BPMN 2.0 as BPMN 2.0 is quite comprehensive with many modeling elements and typically requires some BPM practice training for the customer.  With APEX Workflow our goal is to offer a simple and intuitive to use Process Automation solution built around the following core principles
 

• Simplicity
  At the beginning, APEX Workflow will come with only a few modeling elements. We will gradually enhance the functionality based on customer feedback but keep it simple and intuitive to use without significant training required.
   
• Extensibility
  APEX Workflow will be extensible from the first day. Process Type Plugins will be used for the implementation of Workflow Activities. Among the native plugins coming with Oracle APEX (for example Send Email, Invoke API, Execute Code etc.), Developers are free to create their own Process Type Plugins for consumption as Activities in the Workflow.
   
• Integrated
  APEX Workflow is fully integrated in the APEX environment; the Workflow Designer developer experience is very similar to Page Designer.
   
• Dynamic
  The execution semantics of APEX Workflow is not limited to support sequence flow-based semantics only (like BPMN 2.0). Going forward, APEX Workflow will support more dynamic workflows that are event and data condition based. In fact, many Workflows in the area of Health Care, Insurances, Complex Financial Products etc. are not structured and pre-scribed but assume a knowledge worker to make decisions on which activities to execute to achieve a certain business outcome.
   
• Intelligent
  Machine Learning in the Database will be used for predictions regarding the execution of Workflows. Examples are the prediction of SLA violations, Anomaly Detection in the Data or the next best action to perform in a Workflow.
   

We started working on this already, stay tuned for updates in this area in future blog posts. I’d like to thank my co-workers Ananya Chatterjee and Ottmar Gobrecht for reviewing and Steve Muench and my manager Marc Sewtz for valuable input on this blog post.

References

[1] Oracle APEX 22.2 App Builder User’s Guide, Managing Approvals, https://docs.oracle.com/en/database/oracle/apex/22.2/htmdb/managing-approvals.html#GUID-9CA34E4A-72EB-483D-AC02-F335020ADA43
 

[2] Ananya Chatterjee (2022): Introducing Approvals Component in Oracle APEX, https://blogs.oracle.com/apex/post/introducing-approvals-component-in-oracle-apex
 

[3] Ananya Chatterjee (2022): APEX Approvals Component Continued – Do More with Less, https://blogs.oracle.com/apex/post/apex-approvals-component-continued—do-more-with-less
 

[4] Ananya Chatterjee (2022): Implementing Multi-Approvals in Oracle APEX 22.1, https://blogs.oracle.com/apex/post/implementing-multi-approvals-in-oracle-apex-221
 

[5] OMG Business Process Model and Notation 2.0, https://www.omg.org/spec/BPMN/2.0/
 

[6] Flows for APEX, https://flowsforapex.org/