Invoking Workflows within Workflows – APEX 24.2

The workflow component was first introduced in APEX 23.2 and can be integrated into your applications to model and run your business processes. I first reviewed the component in a blog I wrote last year, which you can read here.

New Features

The latest release of APEX 24.2 in January sees some further enhancements, with the following new features highlighted.

• Invoke Workflow Activity
• Copy Workflow Definitions
• Resume Workflows at any activity
• Improved Human Task and Workflow pages

The new feature that stands out to me (and the focus of this blog) is the ability to invoke a workflow from inside another workflow. However, before I delve into this new feature, let's have a quick look at the other improvements mentioned.

Copy Workflow Definitions

It is now possible to copy a workflow from another application. So, if you want to create a new workflow similar to an existing one, you can copy and then amend it as needed (so long as you are copying it from another application).

The most significant benefit this improvement gives is the ability to create template workflows in your master/template applications. These can be set up to follow your agreed standards and include any common features or business processes. They can then be used as templates for each new workflow you add to your applications. When you copy a workflow into your application, any invoked workflows or shared components, such as tasks or email templates used by the workflow, are also copied.

Resume Workflow

Workflow administrators can now suspend a workflow, amend the values of variables and restart at a chosen activity. This enables considerable flexibility and control when dealing with workflow processing failures or human error, as an administrator can correct any issues and restart a workflow and the appropriate activity rather than having to restart it from the beginning.

Improvements to Human Task and Workflow pages

The layout of human tasks and workflow pages has been modernised and improved using template components, enabling simpler customisation.

Invoking Workflows

The introduction of the new Invoke Workflow activity significantly opens up the possibilities and flexibility of workflows. You now have the option to break down large and complex workflows into smaller/simpler workflows, which can pass data between them.

For example, if the workflow has multiple sub-processes, these can be separated into individual workflows and configured to run sequentially, concurrently, or a combination of both. Another benefit of this improvement is reusability. Common processes can be created as separate workflows and invoked as required by your other workflows as often as needed.

Version 1

To test out this new feature, I created a simple application and accompanying workflow for the approval of employee absence requests, with the initial solution using a single workflow. The requirements I set were as follows:

• A simple Interactive report and modal form page to view and enter absence requests.
• Absence entries consist of a date and the absence type, Vacation, Bank Holiday, or TOIL (Time off in Lieu).
• Bank holidays do not require review and can be automatically approved.
• Vacation and TOIL entries must be approved or rejected by the employee's manager.

The first step was to create the human task for the approval of Vacation and TOIL requests. This was a basic task that takes the approver username in as an input and returns the task outcome of either APPROVED or REJECTED.

Next, I used the workflow builder to create the business process as follows.

I created a simple workflow that contained one human process to review Vacation / TOIL requests and two switches, one to check the absence type and the other the result of the approval human task. Regardless of the route taken, an execute code activity will update the absence record from pending to approved or rejected. To simplify my testing, I hardcoded the approver to be a test APEX user account named SMITHJ instead of using the employee's manager. This was so I didn't need to log in as multiple different users to approve the workflows.

The APEX application consisted of an employee absence summary interactive report with links to a modal form to submit a new request and initiate the workflow.

When the create button is pressed, the entry is validated and processed using an automated row processing (DML) process. A workflow process then creates the new absence approval workflow, passing in the ID of the absence detail record.

Lastly, I used the page creation wizard to add the unified task list and workflow console pages and also added an interactive report to detail the absence history.

Testing Version 1

To test the application, I created three absence requests (one of each type) and checked the status of each in the Workflow Console.

As expected, two workflows were pending approval by SMITHJ, and the third has been auto-approved as it was a bank holiday.

I logged into the application as SMITHJ and used the Unified Task List page to review the two pending requests, setting one to approved and the other to rejected.

Once all three workflows had been processed, I checked the absence history to confirm they were all approved/requested as expected.

Version 2

To test the new Invoke Workflow activity, I amended the business process as follows:

• For a TOIL absence request to be approved, the employee must have sufficient unused TOIL days accrued.
• A request to increase the number of TOIL days an employee has must be approved by the TOIL Administrator.
• If there are insufficient TOIL days to cover an absence request, the absence workflow will automatically invoke the TOIL workflow and wait for the response before continuing.
• If the increase in TOIL days request is approved, the absence request workflow can continue otherwise, it must be automatically rejected.

The first step in updating my business process was to create a second workflow and corresponding human task to review the request to increase an employee's accrued TOIL days.

As this workflow is to be called by the Absence Request workflow, I need to pass back the TOIL increase decision. To do this, I added an OUT directional parameter named TOIL_STATUS, which will be set to the value INCREASED if the increase in days is approved. This parameter value is sent back to the parent workflow, where it can be used by a switch activity to determine what to do next.

Next, I modified the Absence Request workflow to check for TOIL-type requests if the employee has accrued sufficient days and if not, invoke the TOIL Increase Approval workflow and then wait for it to complete. Once control passes back to the parent workflow, if the increase is approved the absence approval process can continue, otherwise it is set to rejected automatically.

The new Invoke Workflow activity has the following properties within the Settings section:

• Definition: The workflow being invoked.
• Initiator Item: Optionally used to provide the initiator of the workflow being invoked. If not set, the initiator will be inherited from the parent workflow.
• Details Primary Key Item: Optional used to provide the primary key for the additional details record used by the invoked workflow.
• Workflow ID Item: Optional item to hold the ID of the invoked workflow.
• Wait for Completion: If set to YES (ON), the parent workflow will wait for the invoked workflow to complete before continuing. If set to NO (OFF), the parent workflow will continue immediately without waiting for the invoked workflow to complete.
• Retry Point: This is the point at which the invoked workflow will be retried if faulted.

The Request TOIL Increase is an Invoke Workflow Activity set to "Wait for Completion" and passes back the value of the TOIL_STATUS parameter into a local variable named RETURNED_STATUS. This variable is used by a switch activity to determine if the approval process should continue or end with an automatic rejection. 

Testing Version 2

To test the updated version of the application, I created the following five absence requests to check the main routes through the process.

• Bank Holiday
• Vacation
• TOIL (for an employee with sufficient days)
• TOIL (for an employee with insufficient days) to be approved
• TOIL (for an employee with insufficient days) to be rejected

As expected, the bank holiday request auto approved and completed, while the other four absence requests require approval. The TOIL absence requests for Alexander & Christoper have detected insufficient TOIL accrued and successfully invoked the TOIL Increase workflows and are now in a waiting state.

Looking at the invoked TOIL Increase workflows, I can see they are waiting for approval by the test user TOILADMIN.

I logged into the application as TOILADMIN and used the Unified Task List page to review the two pending requests, setting one to approved and the other to rejected. The TOIL Increase request for Christopher was rejected, which correctly resulted in the parent absence request workflow being rejected as well.

The TOIL Increase request for Alexander was approved, which correctly returned the TOIL_STATUS with a value of INCREASED, which resulted in the parent absence request workflow continuing onto the approval activity for JSMITH.

Summary

The new workflow features added to APEX 24.2 add a new level of flexibility for developers. In particular, the option to copy workflows and to invoke workflows from within workflows are two powerful features that significantly open up the options for what is possible, making APEX workflow a great option for mapping and actioning your business processes.

For more information, check out our Oracle APEX Services, and if you liked this blog, check out our other APEX blogs here.

Contact us today and one of our expert developers will be in touch.