OPA 24.02 What's New

Welcome to the February 2024 edition of What’s New in OCI Process Automation (OPA). Here, we will cover the most important features being introduced in the 24.02 release to ensure that you are up to date and aware of the latest changes.

This release introduces highly anticipated enhancements to decision and process modeling, connectivity, and end-user personalization. Without further delay, here are the release headlines:   

Support for OAuth Client Credential Flow

With this release, we have introduced support for bearer tokens generated via the OAuth Client Credential flow. This flow is best suited for Machine-to-Machine (M2M) flows where we need to authenticate and authorize an application instead of a user. In practical terms, this means that we now have a dedicated method for handling requests from applications that do not usually carry user context (e.g. Oracle Integration Cloud).  

Tokens generated by the client credential flow are supported when interacting with decision services or process instances.

To use this feature, you need to have an OCI IAM application configured to authenticate a client via the client credentials grant and to generate an appropriately scoped bearer token that has access to your OPA instance. Here, you can either use the default IAM application created for your OPA instance (which you will find in your OCI console under Identify domain > Oracle Cloud Services) or create a new integrated application and configure it appropriately.

Additionally, if you want to use the client credentials flow to initiate a process instance, you need to ensure that your process is configured to accept requests from your IAM application. There are a few ways to achieve this, but the most common one is to add your IAM (external) application to a process role with the USE permission:

Adding an External Application to a role
Above: Adding an IAM External Application to a role with Use permission

 

Once you activate your application, you should use the generated OpenAPI specification to test and run your process.

At runtime, the audit will now reflect that the process was initiated by an external application and show the specific application client ID:  

OPA tracking showing an instance initiated by an external application
Above: A process instance initiated by an External Application

Decision Applications:

  • Create Data Types from JSON

When creating a decision application, you often start by defining data type(s) that will represent the structure of the data with which your decision service will work. These data types will then be referenced through your decision model by input data nodes and rule conditions.

Until this release, data types needed to be defined manually and this was often a time-consuming process for large or more complex data sets.

To alleviate this problem, we are excited to announce that we now support data type creation from JSON documents!

You will find this new feature in Decision Applications under the Types menu, where you will be presented with an option to create the data type from either a JSON sample or schema. Once you go through the wizard, a new data type will be created that matches the structure of the document provided.

If you need to make a change after object creation, you can do that by editing the data type that will bring up the JSON wizard again. This allows you to edit data types as your data model changes, while maintaining existing references.

Note: you can still create data types manually if you need.

Creating a data type from JSON in an OPA Decision
Above: Creating a data type from a sample JSON in a Decision Application

 

  • Search for Decision Rules

If you have a large decision model containing many decision or data input elements, it can often be hard to find a particular node. To address this, we have introduced the ability to search for a specific element in your decision model!

Searching for a decision rule or input data element will now highlight the node in the model and show the input and output information flow related to it. This information flow is especially useful in large decision models where it is hard to see which elements are used as input for a decision rule and where the output of your selected decision is referenced.

Above: the new search functionality in Decision Applications
Above: the new search functionality in Decision Applications

Process Applications:

  • Error Events

Exceptions are often encountered when automating business processes. To help you handle exceptions in OCI Process Automation, we introduced support for error event sub-processes in 23.12. In this release, we are expanding our capabilities to handle errors by adding support for error end and error boundary events.

Error Events can now be used in the following ways:

  • As a start event in an event subprocess activity. (see here for more details)
  • As an end event modeled directly in the process flow.
  • As a boundary event attached to another activity.

Error End

This end event indicates that a certain path in the process has ended with an error. An error end event allows you to throw an error that can be caught by an error event subprocess activity or an error boundary event. Doing so would mean that you can trigger an exception subprocess or a set of activities to react to a specific error. An example of this can be seen below:

Above: an example of using an error end to throw an error, which is caught by an event subprocess activity
Above: an example of using an error end to throw an error, which is caught by an event subprocess activity

 

Error Boundary

An Error Boundary event is attached to another activity, for instance a service task or a subprocess. It catches an error that occurs during the execution of that activity and interrupts the execution of the current process flow. This results in the process now following the path modeled from the error boundary event to handle the specific error. An example of this can be seen below:

Above: an example of using an error boundary to catch an error for a specific service task
Above: an example of using an error boundary to catch an error for a specific service task

 

The introduction of error boundary and error end events in OCI Process Automation means that you can now have greater control in handling system exceptions in your process model.

  • Terminate End

Terminate End events are used to stop all parallel executions of a process instance. In OPA, one process instance can generate multiple parallel flows (tokens) through the use of parallel or inclusive gateways and non-interrupting timer events.  

A Terminate End event is governed by the scope in which it is used. If used at a process level, it will ensure that all parallel flows are terminated, and the instance will result in a completed state. If used in a subprocess, all parallel executions in that subprocess will come to an end and control will return to the next activity in the parent flow.

From a practical point of view, you can use terminate end when:

  • You have a condition inside a parallel or inclusive gateway that should result in the termination of all flows (tokens).
  • You have a condition after a non-interrupting timer event that should result in the termination of all flows (tokens).
Above: An example of using a Terminate End at a process level
Above: An example of using a Terminate End at a process level

Workspace:

  • Out of Office Support

We are thrilled to introduce support for out-of-office in OCI Process Automation! This feature allows you to define periods of leave during which any tasks assigned to you will be automatically re-assigned to another user or role.

You will find this feature in the OPA workspace under the user menu:

Out of Office menu

OCI Process Automation allows you to enter one or more out-of-office periods. For each of these, you will need to define a start date, end date, and reassign rule, and provide an accompanying comment for context.

Once your leave entry is created, you will be able to edit or delete it as needed. This functionality will allow you to extend, shorten, or cancel a leave period.

The out-of-office section will also list all current or future leave entrees that you have configured, so you can easily see your current and upcoming periods of leave.

Out of office assignment in OPA

During an out-of-office period, any task assigned to you will be automatically reassigned to another user or role (based on the configured rule). Reassigning to a role would mean that the task goes back to a team queue in an unclaimed state, allowing someone else to pick it up.  

Upon opening a reassigned task, the new assignee will see the context you entered when configuring your period of leave: 

Out of office reminder notificationNote: out-of-office reassignment actions are included in the task history for full traceability and audit.

Contextualized OPA Start Forms

This capability allows you to pass data into an OPA start form via URL query parameters. For use cases where OPA forms are embedded in another application, this allows you to load a form with the context of the existing application. Furthermore, you can use the data passed in these parameters in on-load events to make API calls to external systems and fetch additional information.

To help explain how and where this feature can be used, let’s take a look at an example:

  • Oracle HCM Journeys allows you to create External URL-based tasks and pass the context of the journey, task, and person performing the activity to the URL. With this new capability, you can now pass this information to an OPA start form. The OPA form can subsequently fire an on-load event to query an HCM API that retrieves information about the person filling out the form and pre-fill key fields such as their name, department, cost center, and manager:
Above: An example of passing data to a start form via query paraments which are then used to in an on-load event to fetch additional data
Above: Passing data to a start form via query parameters that are then used in an on-load event to fetch additional data

Connecting to OPA from Visual Builder

Oracle Visual Builder lets you visually create and deploy web and progressive web applications.

With the 24.04 release of Visual Builder, you can now integrate your front-end applications with process workflows built in OPA!

To do this, you need to create an Oracle Process Automation backend in Visual Builder that will establish the connection and authentication required to connect to your process instance.  

Creating a backend for OPA in Visual Builder
Above: Creating a backend for OPA in Visual Builder

 

With the backend defined, you can now create a service connection via a dedicated OPA service catalog.

A dedicated Service Catalogue for OPA
Above: A dedicated Service Catalog for OPA

 

This service catalog will allow you to discover and browse through process applications and select a process with which you want to interact.

Process discovery in the OPA Service Catalogue
Above: Process discovery in the OPA Service Catalog

 

Selecting a process from this catalog will bring in endpoint definitions required to get, update, and create process instances. You can now create types from these endpoints that will contain all attributes needed when forming requests or handling responses from OPA. Finally, OCI Process Automation can now be invoked using the call REST action in Visual Builder Action chains.

For more information on this feature, please refer to the Visual Builder documentation.

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.02 integration new features blog.