Monday, August 8, 2022

#922 - OCI Process Automation in more detail


This post covers OPA Decisions, as well as leveraging List of Values in a Form. It also discusses different form presentations e.g. Order Entry Person has a different form to the Approver. It also highlights some simple tips around OCI Process Automation. I don't like referring to the service as OPA as that means grandfather in German, but forgive me, if I sometimes do so.

You will be happy to know I'm sticking with the simple order approval example from the first OPA post - 

In our simplified world, the business owner has asked me to apply discounts to all orders. The discounting rules are very simple -

1. Orders for iBikes, with an order value less than €10000, get a 15% discount.
2. Orders for iBikes, with an order value greater than €10000, get a 30% discount.

3. Orders for other products, with an order value less than €10000, get a 5% discount.
4. Orders for other products, with an order value greater than €10000, get a 10% discount.

He told me we need to get those iBikes moved asap, they're not all their made out to be.

This can be easily implemented by OPA Decisions -

Creating and Using Decisions

Let's start by considering the input / outputs. For the former I will need - product, unitPrice and quantity.

The latter is any of the following values - 5, 10, 15, 30 - i.e. the discount to be applied.

 I will need Input Data and Decision Table for this simple example -

I have configured the InputOrder as follows - 

Now let's look at the Decision Table - 

Note, one can test the decisions by clicking here -

Looks good!

Now to using this in the Process - 

I drag and drop the following before the Email Approval activity - 

Now to Open Data Association - I just need to map the relevant fields from my Order to to the following -

For the Output - I save the discount to a process variable - 

Let's edit the email to include the discount applied to the email body - 

Activate and Test -


I check my GMAIL - 

Using LOVs / Multiple Form Presentations

These 2 can be addressed together, you will soon see why. Our business owner has told me to ensure CSRs only enter valid products when inputting orders. So this is where the LOV comes into play. She also told me the Approvers should only see the Order data in read only mode. I nod my head intelligently and begin to implement.

Let's begin by revisiting the Form - here all I did was drop the OrderBO onto the page - 

I will do the same with the Product LOV, but first I have to create a BusinessType based on the LOV.

To recap, here are the 2 business objects I already have defined - 

Let's look again at the ProductLOV - 

Now to creating the new business type based on the LOV - 

Now back to the form designer -

ProductLOVType is now available in the palette -

I drop this on to the form - 

Now you could say I have product twice - but this is not the case - one is really just the list - I need to add an action to the list to populate the "proper" product field.

Select On Change

I add an Action

I now set the Product filed to read only - 

Form Preview mode will allow me to test the logic - 

Works fine!

Now we can hide the Product field -

Now to the 2 different presentations - for CSR and Approver.

Here are the properties for the Start activity - 
note the 2 presentations available for the form - 

I have added a new ApprovalPresentation. Starting point for this is Form Designer -


I then edited the ApprovalPresentation presentation - setting all fields to read only.

Let's Activate and Test - I enter a new order - 

I check out the Approver view - 


First of many I hope - need to create a new version of your Process app?

Just click on the chevron icon next to the current version -

Thursday, August 4, 2022

#921 OIC August 2022 Release New Features


All details here

#920 OCI Process Automation now available

 OCI Process Automation is now available at an Oracle Data Center near you! So what is it? Essentially, a standalone process automation engine very similar to what we have in OIC gen 2. The difference here is the standalone -  it ships with 2 environments - one for designing your processes, the other - your Workspace for interacting with processes.

The oracle docs for OCI Process Automation are available here. But, without further ado, let's provision an instance!

Provisioning Process Automation

Note, the Access Token field is populated for you.

Regarding the Metering Model

Users - active process users per hour, as invoker or participant. Probably very interesting for customers buying Process Automation to extend SaaS e.g. HCM, where user based pricing is the norm.  

Execution Pack - An execution pack gives you 10,000 execution activities. An activity is any available element in the Process Automation design palette e.g. start/end events, human task, exclusive gateway etc. Now say your process contains 100 activities, however, for a particular instance flow only 40 of these are actually executed. That means 10,000 - 40, leaving you with 9960 "credits" in your execution pack. 

Now to the design time -

Welcome to the new Process Designer - 

Kicking the Tyres

The designer is very similar to what we have today in OIC Gen2, however, with some important deltas -

  • Standalone Designer - no dependency on OIC
  • Redwood Look and Feel
  • Compelling new features
So let's create a simple process - 


Let's go thru the individual components - 

I start off with Types - the business objects. This is an order approvals demo, so I start by creating my Orders business object.

Business Types are business objects, such as my order definition etc. List of Values can be used for data input - e.g. a LOV attached to a picklist field in my order entry form.

So to the Business Type - 

I add the required fields -

I then create an LOV - 

now let's create the UI - here I need a Form that can be used for Order Entry and Order Approval -

I will drop the Order type onto the form - 

I prettify it somewhat -

I now create the process roles - I will have 2 - the CSR enters the orders, while the MANAGER approves.

I do the same for MANAGER.

Finally, to the process itself - Process Automation supports 2 types of processes - structured and dynamic; for the latter think unstructured, more case management style. 


Note the 2 swimlanes on the left - each of these will be assigned a role.

My business logic is simple - the CSR enters an order and the MANAGER approves it - so I need a Start Event of type Form (data entry).

I need to associate it to the form I created - 

Click on Open Data Association and you will see that a process data object has been automatically created.

This variable will contain the Order data entered.

This is a good time to look at the activities available in the palette - most of these are self explanatory - 


I drop an Approve activity in the MANAGER swimlane - 

I configure the Approve to use the same form - as you can see, I have included the customer name in the title - 

I select Bind to process data

Now it hits me - I need the customer email - no worries - I add it to the Type definition and also to the form - 

So now to the decision gate - what to do if Approved or Rejected. In this simple example, I will just send an approval or rejection mail.

Condition is based on the value of the auto-generated variable - taskOutcomeDataObject.

I configure the approval notify activity as follows - 


I do the same for the rejected path - 

That's it! Version 1 of the process has been completed - let's test it!

We could simply click Test here, but let's open the Workspace first.

The workspace uses the same base url as the designer -

I add my user to both roles - 

I then click on Start Requests and see an icon for my app

I check out my worklist - 
and approve the order - 

I can check out the Audit trail -

Excellent - the Guinness is on the way!
Further posts will go into more depth - for example enterprise connectivity, something I haven't touched in this post. Also leveraging the LOV in the Form , different start events etc. So wath this space or, should I say, blog!