Friday, August 16, 2024

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:

 

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:

No comments: