The 23.02 release of OCI Process Automation (OPA) is just around the corner, and with it we will see the introduction of several new and exciting features. This release had two major themes for us: improving connectivity and end-user usability. In that spirit, it brings the following:
- Support for the OCI Signature Policy in connectors
- Improved and more contextual error messages during design time and workspace interactions
- Enhanced visibility in service task invocations
- Improved experience when using the expression builder
You can find the full list of new features introduced in this release here. In the rest of this blog, I will provide a quick overview of each major feature.
If you are keen to play with any of these features, you don’t need to wait very long as this release of OCI Process Automation (OPA) should be rolled out to all OPA customers by the end of February ’23.
OCI Signature Policy
The OCI Signature Policy allows OPA developers to connect to Oracle Cloud Infrastructure (OCI) services directly from OPA through the existing REST connector. The addition of this policy enables us to natively support a variety of new use cases. Let’s explore some of these here:
OCI Vision
Oracle Cloud Infrastructure (OCI) Vision is an AI service for performing image analysis at scale. This service can classify images into any number of categories to accomplish digital asset management initiatives or to identify issues that need attention. Let’s explore a potential use case for using OCI Vision with OCI Process Automation:
- An Energy utility customer can leverage camera images to take photos of vegetation near their powerlines. When OCI Vision detects vegetation overgrowth, a process application can be triggered that alerts a team of maintenance technicians and assigns a task to their team’s queue. An OCI Process Automation workflow can be used to ensure that all tasks are approved and actioned in a timely manner as well as ensuring that an audit trail of all actions taken is maintained.
OCI Document Understanding
Oracle Cloud Infrastructure Document Understanding is an AI service that enables developers to extract text, tables, and other key data from documents. With OCI Document Understanding, customers can automate tasks that traditionally relied on manual data re-entry. Let’s take a look at a potential use case with OPA:
- An OPA form can be used to allow end-users to upload receipts as part of their Expense Approval process. These receipts can be sent to OCI Document Understanding, which can extract all relevant text and return it to OPA. The process flow can then take this data and use it for internal routing or to create a consolidated expense report. The expense report can be subsequently sent to managers for approval or interfaced to a system of record such as Oracle ERP Cloud. In addition to receipts, OCI Document Understanding supports a number of other out-of-the-box document types such as Invoices, Driver’s License, Passports , Bank Statements, Payslips, etc. The service also allow you to create custom document extraction models too, catering for any industry specific use cases.
OCI Language
Oracle Cloud Infrastructure (OCI) Language is an AI service for performing sophisticated text analysis. With pretrained models and custom model support, developers can process unstructured text and extract insights based on sentiment, named entity recognition, language, and text classification. Once again, let’s explore a use case with OPA:
- Many process applications involve forms where end-users need to enter data. OCI Language can be used in the backend of OPA forms to identify end-user sentiment based on the text they enter in free form text input fields or process comments. A negative sentiment can drive the priority of the process tasks to ensure they are dealt with urgently. Another use case is to use OCI Language to detect Personal Identifiable information (PII) entered into these free form text input fields. Once detected PII data can be masked to ensure compliance with regulations such as GDPR.
OCI Functions
Oracle Cloud Infrastructure (OCI) Functions is a serverless, event-driven service that lets developers build, run, and scale applications without provisioning or managing any infrastructure. OCI Functions provide a great mechanism to extend the capabilities of process automation workflows, as now you can invoke these functions through service tasks in a process flow or via a process web-form.
- Some examples of what you can do with functions today to extend your process are: use them to write/read data from OCI Object Store or Oracle Databases; encrypt/ decrypt data, convert data to different formats, communicate with SOAP based endpoints or to send a notification via SMS or Slack.
OCI Queue
Oracle Cloud Infrastructure (OCI) Queue is a service that enables asynchronous (decoupled) communication between systems. With the addition of the OCI Security Policy, OPA can use OCI Queue as a message broker. Here OPA can be configured to either publish or subscribe to/from a queue as part of a process workflow. This pattern can be useful when application decoupling; reliable message processing or protection against load fluctuations in downstream systems is required.
You will find the OCI Signature Policy when defining the Security configuration for your connector within OPA. Once the OCI Signature Policy is selected, you will need to enter your Tenancy and User OCID, Fingerprint and Private Key:
For more information on how to use the OCI Signature Policy in OPA, check out our documentation here.
Note: See the Appendix of this blog for an example that shows you how to configure OPA to talk to an OCI service (OCI Function)
Usability Improvements
We have made several small but important usability improvements in the OPA Designer and Workspace in 23.02. I want to highlight some of these here:
Workspace Tracking Audit
The runtime Audit UI will now indicate the completion status of each activity through the colour of the line against it. This can now be used to quickly identify which activity step has failed:
We have also exposed more information to help developers troubleshoot service task related issues in OPA. The changes we have made here are:
- Surfaced Path & Query paraments (when used as part of the request)
- Surfaced (non-security related) request headers
- Exposed service task errors against the failed activity in the response body
By providing this information against a failed service task activity, we hope that developers will be able to correlate OPA service requests against calls made via a REST client, to effectively troubleshoot any API invocations. You can see a depiction of this below:
Forms Text Area Component
We have also made a small change in our Forms, allowing you to now resize text area components dynamically. This allows end-users to better see large amounts of text without the need to use scroll controllers:
Summary
The 23.02 release, realizes an important milestone for us in that we can now talk natively with other OCI services. Usability improvements in key areas such as service task execution should greatly help developers troubleshoot issues going forward.
We have much more coming in 23.04, so stay tuned for the next new features blog in this series!
Appendix – Calling an OCI Function from OPA
In this guide I will walk you through the steps required to invoke an OCI service. In this case; an OCI Function. To follow along you should:
- Have an existing OCI tenancy
- Have created and deployed a function (you can use a simple HelloWorld app to get started but if you are new to functions, see this guide)
- The function must accept and return content in application/json format
Step 1: Create the Connector
The first thing that you will need to do is locate the base URL of your OCI Function application. To do so head to the OCI Console and navigate to your desired Functions application. Once there look for the invoke endpoint and retrieve the base URL (up to function OCID):
Next navigate to your OPA instance and create a new REST Connector. Give the connector an appropriate title and description and specify the base URL:
With the base URL defined you will need to add a resource and an operation (one for each function that you will need to trigger in OPA):
In each operation I have created a request and response definition that would mimic the JSON payload that I am expecting OPA to send or receive from the function. In addition to this, notice the function OCID in the endpoint path (this will uniquely identify the function that you want to call. You can also retrieve this value as above, via the OCI Console):
Finally, I will need to define my security policy. This is where I will need to select the OCI Signature Policy and provide my tenancy and user OCID, Fingerprint, Private Key, and Passphrase. You can follow our documentation, which can help you find this information.
Step 2: Call the Function from a Process
With the connection configured you can now call your function from your Structured or Dynamic Process.
To call the function from a process, simply drag a Service Activity on to the canvas and configure it to point to the previously configured connector (service/resource & operation):
Next map your data associations, passing in any input parameters required by your function:
Likewise ensure that you map the output of the function response to objects within your process flow, so that you can use the response data from your function in your OPA flow.
That’s it! Its that simple.
You can also call functions from OPA forms through Events as you would with any other REST service. If you are not familiar with how to do this, see here.