Welcome to the August edition of What’s New in OCI Process Automation (OPA). Here, we will cover the most important features being introduced in the 24.08 release to ensure that you are up to date with the latest changes.
This release introduces the ability to define and handle business exceptions, control which actions assignees can take on tasks, assign tasks to a previous approver, a new look and feel for our task forms, and more!
Business Exceptions
With this release, we have extended the error handling capabilities of OCI Process Automation to support Business Exceptions.
Business Exceptions are faults that are explicitly modeled by process designers. These exceptions define non-technical errors that could occur during the execution of a process flow.
For example, I could define a business exception to represent the following:
- a leave-of-absence application where the requestor does not have enough leave
- an online ordering application where the item requested is out of stock
- a travel application where the requestor does not have a valid passport
Once a business exception has been defined, it can be thrown (referenced) by process designers to indicate that the process instance has hit an error (via an Error End event). This allows process modelers to catch and handle the error appropriately (with Event Subprocesses or Boundary Events). The use of business exceptions enables designers to create less complicated processes where the main flow follows a “happy path,” with event subprocesses used to handle exception scenarios. The other benefit of using business exceptions is that designers can have greater control in how they handle errors with the ability to create both tailored and common error handling flows.
You will find Business Exceptions depicted with an amber status in the instance audit (indicating a handled exception) and with an alternate variance branch in process analytics.
Human Task: Action Rules
Action Rules provide process designers with the ability to control which system actions assignees can perform on a task. This allows process designers to have greater control over the end user experience. For example, a process designer can disable the reassign system action, which means that task assignees and creators cannot reassign the task to others. This can be important to ensure that predefined approval chains are not bypassed.
Action Rules are set at a task level with the design-time property menu, giving you maximum control over the behavior of this feature. This allows you to apply different rules on each task or only to the tasks where these restrictions are needed. By default, all system actions are enabled.
Finally, it is important to note that Action Rules do not apply to users with Manage permissions because these users are usually process owners and need full access over their processes.
Human Task: Assign to Previous Approver
Assigning a task to a pool of users is a common approval pattern. In this pattern, one user from the pool can claim a task and act upon it. Once the assignee actions the task, it is common for further interaction to occur between the requestor and themselves. In such cases, the task should become sticky and auto assigned to the same approver.
For example, in a home loan application, the initial request may go to a pool of loan specialists once one of these loan specialists claims a task. Further interactions between the requestor and the bank should go to them.
To support such use cases, we have introduced an option to the task properties that enforces task assignment stickiness. To leverage this option, you must have an initial task that is assigned to a pool of users (with a swim lane role). You can then add one or more subsequent tasks to the approver swim lane with this option enabled. This will ensure that successive tasks are assigned to the initial swim lane approver.
Task Form Modernization
We have made some small but important improvements to the layout of our start and task detail forms. Users now experience a full screen view that provides more real estate and focus to their form. Auxiliary features such as comments, attachments, history, and more information are available through a right-hand draw:
When opened, these auxiliary features do not take the end user’s focus away from the form, but instead allow the user to interact with them simultaneously. This allows users to add comments or attachments while maintaining focus on their form.
Bulk API for Design-time Migration
Customers with active runtime instances following our migration path can now move all process artifacts from their Oracle Integration Generation 2 instance to OCI Process Automation in bulk. This is facilitated by a set of new APIs that allow customers to export all Generation 2 process applications to OCI Object Storage, import these applications into OCI Process Automation with a single job, and check on the status of this long running job. This approach has been documented here.
Final Thoughts
We hope that you are as excited about this release of OCI Process Automation as we are. We encourage you to check out the What’s New section of our documentation next for a complete list of changes introduced in this release and the accompanying user guides and documentation.
As always, if you are using OCI Process Automation as part of Oracle Integration 3, you should also check out our 24.08 integration new features blog.