Oracle Integration Gen2 PCS to Gen3 OPA Upgrade: Part 5

In a series of articles, I discuss some challenges you may face when upgrading Oracle Integration Gen2 (OIC 2) Process (PCS) to Gen3 (OIC 3) Oracle Process Automation (OPA) applications. In this episode I discuss 3 challenges that can make your application fail “silently” on OPA, concerning multi-instance Embedded Subprocess, using ‘now’ and process correlation. The previous article can be found here.

Disclaimer: The below provides a snapshot at the time of writing. Things may have changed by the time you read it. It is also important to mention that this does not necessarily represent the view of Oracle.

For PCS to OPA migration you are also referred to the following:

• How Upgrade Affects Process Features
• Complete Post-Upgrade Tasks for Process Automation

 

The bad news of the following issues is that these can make your process application fail “silently” after upgrade or migration to OPA. The good news is that there is an opportunity to prepare this in PCS already so that you potentially can upgrade to OPA instead of having to migrate with a potential time window of having to run PCS and OPA side-by-side.

The Multi-Instance Embedded Subprocess Challenge

When some logic needs to happen in parallel or sequential, you can use a multi-instance Embedded Subprocess. In the following PCS process, I receive some order, then in parallel check for each line if 10 or more items have been ordered, and if so apply a discount. The Check for Discount is the multi-instance Embedded Subprocess that executes the same logic for each line. After that there is Human Task to review and approve the order.

In the following picture you can see how I was able to successfully execute this process in PCS (for 3 different order lines, not shown but trust me on that).

I then imported that Process application in OPA, validated and activated it:

The Challenge

Running the same process in OPA fails silently, meaning that it executes the logic for the 3 lines, but then “hangs” in the merge and never continues to the Human Task:

Consequently, when you have a process application that uses a multi-instance Embedded Subprocess you must test it properly before you conclude that migration was successful.

You may wonder why I execute this logic in parallel, especially when you realize that in reality the multi-instance execution is not really parallel, nor do I have a specific need of what the semantics of “parallel” add “serial” (like still apply a discount in one thread even when another thread fails). So, let’s try to change it to sequential processing. For an order with just 1 line this works:

 

But with 2 or more order lines sequentially also fails. The only good thing about the change from parallel to sequential is that this time it does not fail silently as now you get an error:

 

The core of the issue is that for the Embedded Subprocess I used the same variable for output as I used for input. That is only logical, so I did not do anything wrong, but it does not work (bug to be filed shortly): 

 

The Remedy

Knowing this, the solution is relatively simple, being to create a new variable of the same type and use that instead for the output:

 

 

 

 

The only extra thing I now must do, is to merge back that extra variable to the original one like I have done in this new process design:

 

 

When I execute it now, it continues to the Human Task again:

 

 

And trust me (again), I have checked that the discount is applied for each eligible line.

 

The Current Date (‘now’) Challenge

Another challenge you may encounter, is when you use the ‘now’ expression in some data mapping. ‘now’ stands for current date and time and in PCS this result in an ISO formatted date-time:

 

The Challenge

The same sample application imports, validates and activates in OPA successfully, but the result is very different. Instead of an ISO-formatted date you get a Linux formatted date: 

This can break your application as most (and certainly all I know) expect dates and dateTime values to have ISO format. Consequently, design-time all looks good but runtime you probably get a 400 Bad Request from the back-end application you sent the date to. 

 

The Remedy

You can fix this by creating a process variable of type DateTime, map ‘now’ to it and then map that casted to string to the target element (many thanks to my colleague Rashmi Halsnad who provided me with the solution!).

In the following I have a DateTime variable with name dateTimeBO which I map to the target dataObject.todayTweaked element:

 

In the following example you can see this to have the ISO format (green box):

The Process Correlation Challenge

Last topic of this article concerns process instance correlation. In this example I have a simple process that starts with a payload including a person’s id and name. This starts another process instance passing on the same information via a Send activity and then waits in a Receive for the response. The Send and Receive are correlated on the person.id. As you can tell from the process tracking, this works in PCS.

The Challenge

When imported into OPA the application does not validate. Details not shown but the issue is that mappings regarding the correlation became invalid as it referenced to non-existing elements:

 

So, I corrected that by using the person.id (again). That made it validate and activate:

But when running it “silently fails” as the called process instance (SMP Message Start) completed but the main process never continues. No error can be seen:

The root cause is that correlation based on data from a Business Type is not supported (yet, ER filed). Have to use a simple type element

The Remedy

Knowing the root cause, I could fix this by adding an extra, simple type element to the request of the Send, as well as the Receive and correlate on that instead.

So, this is how the Send now looks like:

 

And this is the Receive:

 

I also must change the correlation to use these elements instead of the person.id:

And viola, it works again:

 

Next articles on the subject:

• Part 6 Process Receive, Message Start
• Part 7 Task Assignment to an Individual
  

 

Previous articles on the subject:

• Part 1 Starting a Process Instance as a Webservice & Consuming SOAP Integrations
• Part 2 Multiple Start Events  & Synchronous Process Start
• Part 3 /tasks API challenges
• Part 4 Process Instance and Task Properties

 

Oracle Integration Gen2 PCS to Gen3 OPA Upgrade: Part 4

 In a series of articles, I will discuss some challenges you may face when upgrading Oracle Integration Gen2 (OIC 2) Process (PCS) to Gen3 (OIC 3) Oracle Process Automation (OPA) applications. In this episode I discuss the process instance and task  properties challenges. The previous article can be found here. 

Disclaimer: The below provides a snapshot at the time of writing. Things may have changed by the time you read it. It is also important to mention that this does not necessarily represent the view of Oracle.

For PCS to OPA migration you are also referred to the following:

• How Upgrade Affects Process Features
• Complete Post-Upgrade Tasks for Process Automation

 

In PCS there are a couple of commonly used properties for which you will have to make some adjustments in Oracle Process Automation (OPA) to get a similar result. For a process’s Start event the most common instance properties are:

• instanceNumber : often used to persist as a reference to a running instance in some back-end application or database for use cases like programmatic instance abortion.
• title : often used to fill out with some business key to support easy identification or search of instances in Workspace or programmatic search and check on duplicate or for abortion of a set of related instances.

The following example shows the PCS Workspace Processes tab with the instances having a customized task-title:

For a human task the most commonly used properties are:

• On task creation
• execData.title or Title property : often filled out with some task-specific title and business key combination to support easy identification or search of tasks in Workspace.
• execData.shortSummary or Task Summary property : used to fill out with extra data (adding to what already is in the title) for advanced searches and/or with some key-value notation to populate custom columns in a custom task list.
• execData.dueDate or Due Date property : used to notify users that a task should be done before a specific date and time.
• expiryDate property : used to expire a task after a certain date and time has passed
• priority : typically used to notifiy users about high priority tasks.
• execData.identificationKey : used to fill out with a pre-determined unique id which is first persisted in some back-end application or database to support task handling using the /tasks API (for which the taskNumber cannot be used as that is only known to the process instance after the task has been completed).

• On task completion (all often used to persist in a database for auditing reasons): 
• execData.systemAttributes.taskNumber
• execData.systemAttributes.updatedBy.displayName
• execData.systemAttributes.updatedBy.id
• execData.systemAttributes.updatedDate

See the following PCS Workspace My Tasks example with tasks having a customized title (green box) short summary (blue box), a priority (purple circle) and due date-time (red box)he task expiry is not visible in the task list:

For task creation, using execData elements often is preferred over using the task properties, as these elements can be mapped from any available process data object while the corresponding property's expression editor only has access to the task payload. But functionally it has the same result.

When upgrading/migrating an integration where the task properties like title, (short) summary, priority level, expiry, and due date are used, these are upgraded as expected. However, where you used execData elements instead, importing the PCS application into OPA results into a few validation errors.

For the process instance elements you may run into one or more of the following validation errors:

 

And for the task input mapping you may have a couple of validation errors similar to this:

And for the output mapping something like this:

 

Almost all these challenges can be remedied as described hereafter.
 

Process Instance Properties

The following table shows which OPA elements/properties that correspond with those of PCS.

PCS	Sample expression	OPA	Sample expression
Start event execData.title element	title + " for " + formArg.person.name	Start event > Instance > Title property (*)	"Update Summary for " + formArg.person.name
instanceNumber predefined variable		process.instanceId (**)

(*) Currently instance title property is only support for Form Start and not for Message Start.

(**) Note: the shorter PCS integer has now been replaced with the OPA, much longer string. When this is persisted somewhere, a modification might be necessary there as well.

 

Human Task Input Mapping

The following table shows which OPA elements/properties correspond with those of PCS.

PCS	Sample expression	OPA	Sample expression
input.taskExec.identificationKey element	"update-" + person.id	Not supported, consider using Start event > Instance > Business key	person.id
input.taskExec.title element	"Review " + person.name	Human Task Properties > End User Display > Title	Copy/paste expression
input.taskExec.shortSummary element	"Approve " + person.name + " with id " + person.id	Human Task Properties > End User Display > Summary	Copy/paste expression
input.taskExec.dueDate element	‘now’ + ‘1d'	Human Task Properties > End User Display > Due on	1d

 

Human Task Output Mapping

And the following table shows which OPA taskExec output elements correrspond with those of PCS.

PCS	OPA
output.taskExec.systemAttributes.taskNumber	output.taskExec.taskId
output.taskExec.systemAttributes.updatedBy.displayName	Not supported yet (*)
execData.systemAttributes.updatedBy.displayName	output.taskExec.approver

(*) Expected to be addressed in the August Release.

 

Result

When I now run this application, the process instances in Tracking look like this:

 

I used the instance’s person.id field as business key, which is visible in the instance list (green box).

Strange enough, the customized title is not visible in that view when the instance it is still running, nor can you search on it. However, when the instance is completed, it is visible and searchable (red box).

The instance id is not visible in the Tracking list view, but it is in the instance’s details (green box), and you can also search on it. Funny enough, the instance title is also visible in the details even when it is still running (blue box):

 

 The task list now looks like this:

You can see the priority indication (red box), the customized task title (green box), the instance-specific (and not task-specific) business key (purple box) and the due date (orange box). The expiry is only visible in the task detail's More Information tab:

 

The summary not visible anywhere but you can search on it (at least when using the API).

 

Next articles on the subject:

• Part 5 Multi-instance Embedded Subprocess, 'now' and Process Correlation
• Part 6 Process Receive, Message Start
• Part 7 Task Assignment to an Individual
   

Previous articles on the subject:

• Part 1 Starting a Process Instance as a Webservice & Consuming SOAP Integrations
• Part 2 Multiple Start Events  & Synchronous Process Start
• Part 3 /tasks API challenges