In 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 a challenge you may face with task assignment to an individual (instead of the default role assignment) when migrating from Oracle OIC 2 Process (PCS) to OIC 3 Oracle Process Automation (OPA). 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.
In the following example I have 2 Human Tasks, of which 1 is assigned based on the swimlane, and the other by assigning it to a specific person:
The first task has assignment set to “Any member of current swimlane role”:
And the other has it set to some task payload element, which is TaskAssignmentForm.processRequest.id:
When running this process, in Workspace you can see the first being assigned to the process-specific role, which is SMP Task Assignment.ProcessOwner. The “(R)” at the end confirms the assignment is role-based:
The second task is assigned to me directly:
The Challenge
I can import, validate and activate the process without issues. Looking at the properties all looks good for the first task:
And the second one:
When running the process, the first task is assigned to the swimlane role, as it was for PCS:
However, the second one runs into an error
The message points out that the element with name input_taskAssignmentForm cannot be resolved.
On closer inspection of the design-time task assignment you can see it has been migrated to use input.TaskAssignmentForm.processRequest.id, which as such looks OK as it basically is the same element as it was for PCS:
However, the issue is that on assignment this element is not initiated yet. So, practically speaking this is a kind-of NullPointerException.
The Remedy
The resolution is quite simple, I should use an expression pointing to an element of the process payload itself instead, which in my case is called taskAssignmentFormDataObject:
When I now run the process, also the second task is assigned properly:
Note: in PCS you don’t have access to the process payload in the task assignment expression editor. So, there is no way I could have prevented this issue in PCS already.
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
- Part 5 Multi-instance Embedded Subprocess, Current Date ('now'), Process Correlation
- Part 6 Receive and Message Start Interface
No comments:
Post a Comment