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 Multiple Start event and synchronous Process start 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.
Note: this article has changed on 2024-07-12 by adding a 4th option to the Synchronous Process Start - Remedy.
Note: this article has changed on 2024-07-15 by adding the below references.
Specifically for PCS to OPA migration you are also referred to the following:
Multiple Start Events
On OIC 2 you might have created a process that can be started via multiple start events. A use case for this would be a process that can be started by a form as well as a message, both with a slight different interface. For example the request of one might take a bit more data, while for the other that data is defaulted.
In the following sample user registration process, the one flow that is started by a Form first needs to determine a user id before it can store the user data. The other flow that is started by a message (from some other application), already has the id but does not provide some user details. So, the new user is asked by mail to complete those details, the user enters those, after which the data is stored.
The Challenge
Currently OPA does not support having multiple Start Events for the same Process. As far as I know this is on the roadmap, but currently not there.
When the above process is imported in OPA, it will show you an error.
The Remedy
As a matter of fact, a Form Start can also be started via a message. Therefore, there are 2 options:
- Create a separate, new Process in the same application with a Message Start event that exposes an interface that is the same or backward compatible with the exiting one, and then remove that existing one from the Process that is having both Start events. On its turn this new Process can start the other Process with the Form Start event using a Send activity of type "Process call".
- Create a new Process in the same application with a Form Start event that exposes the same or backward compatible interface as the existing one, etc. When the Process is started via the out-of-the-box Webform feature from the out-of-the-box Workspace, this has no impact. In case of a UI implemented with some other technology (like VBCS) that UI application will have to be changed to call the new Form Start interface.
In this case I chose to create a new process with a Message Start and let that call the one with the Form Start. The rationale to keep the Form Start in the main process is to keep it simple, as the only thing I had to do is adding an (optional) user id element to the interface of the Form Start (which did not have before but as it is optional the interface is backward compatible) and then add a condition to the Form Start flow to skip the step for determining the user id.
So, the new Message Start flow looks like this:
And the Form Start looks like this:
Obviously having to call another Message Start process is a breaking change, but is the case anyway as the OPA API is different from the PCS API (see also the previous blog article in this series).
Synchronous Process Start
On OIC 2 you can start a Process in a synchronous way when using it's SOAP webservice (see also previous blog article). A use case for this is that the process instance needs to pass back some information or raise a fault. For example, you might want the instance to do some validation and throw a fault when that fails or otherwise pass back the processId.
In the following example (from a real application) an integration is called to fetch data that is used downstream. If nothing can be found, with the Get Subsidy Failed an error is thrown as a Business Exception that the consumer can catch to handle it. Otherwise, with the Send Response a response is returned with the process instance id.
The Challenge
OPA does not have the option to return a custom response or fault from the process flow. The OPA /process/api/v1/instances API to start an instance returns the instance id, but if the process would fail right after the start, the consumer would not know.
The Remedy
Depending on the options on the consumer side you have one of 4 options:
- Move the logic necessary for the response or to raise a fault, to an Integration instead. In my example, there is already such an Integration, as I always decouple the process from the consumer (to supports that some changes can be made without any impact on the consumer). So, in may case I can check the existence of the business object that with PCS happened at the beginning of the process flow, to the existing Integration.
- The consumer waits for a short while before it uses the OPA /instances/:id API to check if the process runs successfully.
- The process writes the status and optional response to a database and the consumer polls that database.
- The process does a call back of some sort to send the status or response to the consumer.
Next episodes on this topic
- Part 3 Tasks API
- Part 4 Process and tasks properties
- Part 5 Multi-instance Embedded Subprocess, 'now' and Process Correlation
- Part 6 Process Receive, Message Start
- Part 7 Task Assignment to an Individual
Previous episode on this topic:
No comments:
Post a Comment