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

This release introduces the ability to import Oracle Integration Generation 2 Process artifacts into OPA! Additionally, it provides admin support for Out of Office, brings even closer integration with Oracle Visual Builder, enhances the ability to use functions from decision tables and brings important enhancements to our Document Understand capabilities.  

Import Oracle Integration Generation 2 Process and Decision Applications

With this release, OCI Process Automation allows you to import process and decision applications created in Oracle Integration Generation 2!

This capability is particularly important to customers that have created applications in Generation 2 and want to bring these applications to their Oracle Integration 3/OPA instance.

To get started, you need to create a new application by selecting the Import application option. The application import feature has now been enhanced to support .exp and .dmn files created in Generation 2:  

Importing Gen2 Applications created in OPA
Above: Importing Gen2 Applications created in OPA

Once imported, a migration report is presented for the application. This report contains three sections: a section that shows the successfully migrated activities, a section that lists items that you need to review and update, and a section that lists all the functionality that could not be migrated:

Migration Report, presented after importing a G2 application

Customers are expected to take action based on this report in the following way:

  • You should first review the Migrated section. However, this is just an FYI, no action is necessary here.
  • In the Review and finalize section you need to go through each item carefully and take any action listed. For example, you need to re-assign role members manually as a post-import task:

Migration Report - Review and Finalise

  • The Couldn’t Migrate section lists issues that usually arise because some functionality that was available in Generation 2 is no longer available in OPA. A good example of this is the use of SOAP connectors or references to the Insight activity. To address these issues, you may need to take various actions. For instance, in the case of SOAP connectors, you need to transition to using REST-based APIs or use integrations in Oracle Integration to perform REST-to-SOAP conversions. 

Migration Report - Couldn't Migrate

The migration report serves as a great initial reference, but it is a point in time snapshot. Once you start fixing issues, you should use the Validate feature to track the remaining issues through to completion. However, if you want to go back and see the original report, you can do so from the application overflow menu:

Viewing the Migration report within an application
Above: Navigating to the Migration report once you are in the context of an application

Out Of Office for Administrators

Out of Office is a capability that allows you to define periods of leave during which any tasks assigned to you are automatically re-assigned to another user or role. We introduced this capability here as part of the 24.02 release.

In 24.04 we have enhanced this further by allowing process administrators to set Out of Office periods on behalf of others!

This is important, because you are not always able to configure an Out of Office rule before going on leave. However, the implication of not setting up this automatic reassignment is that it can lead to costly delays that can impact the business because tasks will simply not get actioned until you return.

To address this, OPA now allows process administrators (users with the ServiceAministrator role) to set Out of Office rules on behalf of others. A new Out of office option is now available for these users, under the Workspace administration menu:

Out of Office for Administrators

Here you can choose the absentee and configure an Out of Office re-assignment rule on their behalf:

A process administrator configuring an Out of Office rule on behalf of a user who is already on leave
Above: A process administrator configuring an Out of Office rule on behalf of a user who is already on leave

While an Out of Office period is active, you now also see a banner message letting you know that that an automatic re-assignment rule is active. This gives you an opportunity to understand why tasks are not being assigned to you and stop the Out of Office rule if you choose to return to work earlier than expected:

Absentees will now see an Out of Office banner message if they log into OPA when an OOO rule is active
Above: Absentees will now see an Out of Office banner message if they log into OPA when an OOO rule is active

For more information on configuring Out of Office rules please see our documentation.

Automatic Service Registration with Visual Builder

In the 24.02 What’s New blog, we introduced the ability to connect to OPA from Oracle Visual Builder (VB). This approach relied on the manual creation of an Oracle Process Automation backend. The creation of this backend is a required prerequisite for you to see the OPA Service Catalog and therefore interact with your process applications from VB.

In this release, we have enhanced this capability further by automatically creating the OPA backend when Visual Builder and OPA are both part of an Oracle Integration 3 Enterprise Edition instance. This feature means that you can directly use the OPA Catalog to browse through and invoke process applications without any prior configuration, saving you time and removing any friction from the existing process.

This capability is available to all new Oracle Integration 3 instances created after the 24.04 release (April ’24). Any instances created prior to 24.04 do not have the OPA backend automatically created. For these instances, you will need to manually create the backend by following the documentation here. 

Customers who provision a new Oracle Integration instance will be able to leverage the automatic OPA backend creation simply be enabling both OPA and VB through the OCI Service Console:

Enabling Visual Builder and OPA from the OCI Console
Above: Enabling Visual Builder and OPA from the OCI Console

The order in which each service is enabled is irrelevant; whether OPA or VB is enabled first really doesn’t matter. Once the two child services are both active, they will find each other and the OPA backend is created in Visual Builder.

The backend creation occurs at a tenant level and you simply see it as “Process Automation Application”:

Pre-created service registration with OPA in Visual Builder
Above: Pre-created service registration with OPA in Visual Builder

You notice from the above image that VB automatically knows the OPA server address.  Opening up the server details, you also notice that the authentication policy used to communicate with OPA is now defaulted to Oracle Cloud Account. This policy aligns to VB best practices when communication with other Oracle Cloud applications and ensures that user identity is passed to OPA.

The Server config details of an OPA Backend in Visual Builder
Above: The Server configuration details of an OPA Backend in Visual Builder

Leverage Built-In Functions in Decision Tables Cells

Built-In functions provide a powerful way to evaluate rule conditions in decision models. They are often used to manipulate strings, convert data between different types, or even work with data in arrays. You can find out more about these functions here.

Built-in functions can be used in various activity types such as decision tables to enforce business logic. Prior to this release, we supported the use of these function in decision table columns, where the field value was evaluated in the same way for all rules. We have enhanced this capability further in this release, by allowing you to use built-in functions in decision table cells! This greatly expands the power of what you can do with decision tables in OCI Process Automation.

Let’s take a look at an example, to illustrate this new capability.

Imagine that we have a decision table that needs to calculate the shipping cost of a parcel given certain input conditions. Here, we need to conditionally apply further checks based on the preferred carrier. For example, if the preferred carrier is DHL, we need to ensure that the destination country is not on the DHL exclusion list. You can now model such use cases with decision tables because you can leverage built-in functions such as contains, starts-with, substring, list-contains, etc in table-level cells:  

Built-in functions used in a decision table
Above: Built-in functions used in a decision table

You can use built-in functions in cells under the input and output columns. However, if used under input conditions, know that they must evaluate to a Boolean value. This is because the rule ultimately needs to evaluate to a true/false condition. 

Document Understanding Enhancements

In this release, we have made some significant enhancements to the Document Understanding capabilities of OPA to enable additional use cases.

Firstly, uploaded documents can now be referenced in subsequent human tasks. This allows an approver to review a previously uploaded document alongside the extracted data. This functionality is important because often managers want to see the original document to ensure validity and compliance.

An approver can now review a previously uploaded document alongside extracted data
Above: An approver can now review a previously uploaded document alongside extracted data

Additionally, this functionality enables use cases where the uploaded document needs to be persisted to a system of record only after an approval has been obtained from a supervisor. To understand this use case a little better; let’s use the following example.

Imagine that an OPA form is used by ride share drivers to update their drivers license information. This form will perform OCR on the uploaded license saving the end user from having to re-enter information manually. Once submitted, the form should be sent to an approver who can review the extracted data and the uploaded image. The approver can reject the request or ask for more information. However, if they approve it; the system is expected to update Oracle HCM with the latest driver’s license information and upload the original image to HCM Document Records. This action should only occur once approval is obtained.

Finally, this functionality allows OPA to play a key role in system-driven Intelligent Document Processing (IDP) use cases. Such use cases are often orchestrated by an integration in Oracle Integration that processes incoming documents from a file server or email inbox. For each received document, the integration usually triggers OCI Document Understand (ODU) to perform document classification and data extraction before using the extracted data to update systems of record.

A classic example of this is invoice processing. A lot of things can go wrong in such a use case, perhaps the invoice was a duplicate, it was missing a key field, the supplier did not exist in ERP, or ODU was simply not able to understand the invoice. In such scenarios, human intervention is required and that is where OPA comes in. With this release, OPA can now handle such exceptions by receiving a document through an OPA Start Form event that can be called through an API. Because this use case deserves a deeper dive, we will explore it further in a separate blog.  

To provide the above functionality, the Document Understanding form control in OPA has been enhanced to support document reference persistence. This optional setting will ensure that uploaded documents can be referenced in subsequent Human Tasks of the process instance.

Designers can now optionally persist a document reference, so the document can later be viewed by other users in the process flow
Above: Designers can now optionally persist a document reference, so the document can later be viewed by other users in the process flow

We have also added a new event action in OPA forms that can be used to perform image analysis. This action is intended to support the system-driven use cases discussed above:

A new event action in OPA Forms that will perform document analysis when triggered
Above: A new event action in OPA Forms that will perform document analysis when triggered

Stop/Start a Process Automation Instance

You can now stop and start an OPA instance. You may choose to do this if you are planning not to use an instance for a period of time or want to limit its ability to service new requests.

For more information, refer to our documentation.

Stopping an OPA instance from the OCI Console
Above: Stopping an OPA instance from the OCI Console

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