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 add to and partly correct the previous one where I talked about the correlation challenge. I also discuss challenges with the interface of the Message Start. 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:
Process Receive Interface
Last time I discussed how correlation of inter-process calls with a Send-Receive combination only works when you use a separate, simple type argument to correlate on.
As it turns out, for a Send-Receive combination the Receive does not support exposing an interface based on a (complex) Business Type at all. So, what I missed the previous time is that with a complex type argument the mapping failed completely as none of the request elements were mapped. The following explains the challenge in detail as well as the remedy.
In in the following example, I have a
simple PCS process with a complex Business Type.
The following first (parent) process has a Send - Receive combination which is calling the second (child) process that has a Message Start and which does a call back to the first by means of a Send activity.
In PCS this all works just fine.
The Challenge
I can import and activate the process in OPA without getting a validation error. Already knowing that correlation only works when I have a simple type id in the payload, I already fixed that. However, when I run the process the mapping of the Receive fails "silently" meaning I don’t get a runtime error, but instead of mapping the approvedPerson input argument back to the person data object, it has mapped what appears to be (part of) the JSON schema of the input argument. This is what I literally get back from the mapping:
{number=false, boolean=false, null=false, string=false, array=false, dataFormatName=application/json, nodeType=OBJECT, value=false, object=true}
For most processes this probably makes it fail in the next step as the business object got corrupted, but you only find out runtime.
The Remedy
The remedy basically is the same as for the correlation challenge: use root-level, simple types. Meaning, that you must create an interface where each data element to pass on, is at the root-level:
And (obviously) you must map each element individually in both the Send back to the child process as well as in the Receive of the parent:
Message Start Interface
All PCS Structured Processes I have designed with a Message Start use a complex Business Type. Main reason being that for PCS this can make the input mapping easier, as it supports mapping of the parent element only, which makes it simple and prevents the need to cater for empty elements.
I also normalize the data structure. For example, instead of having a flattened data structure with top-level elements name, streetName, houseNumber, postalCode and city, I have an interface with at top-level name and address, and then streetName, etc. as child elements of the address element based on a separate Address Business Type. This does not only help to better understand the structure and usage of the interface, but also makes it more resilient to change.
For example, to add a correspondence address, I can easily reuse the Address Business Type to add a correspondenceAddress next to address (instead of having to work around it by adding correspondenceStreetName, etc.
The Challenge
Currently, OPA only supports a Message Start with either simple type, root-level arguments or based on a complex Business Type of 1 level deep. So, in the example mentioned before I still must use top-level elements for streetName, and all the others including the array.
The following shows the interface of a dummy application I created in PCS and then migrated to OPA to verify that indeed the results I had with a real-live migrated application was caused by this.
First, I tried with a more complex type having a sub-element based on a SubType Business Type of 2 elements, and another sub-element that is an array of a Project Business Type with 1 element.
When I try to start an instance of this process using this request:
{
"params": {
"applicationName": "SMPMessageStartComplexRequest",
"processName": "SMPMessageStartComplexRequest"
},
"dataObject": {
"complexTypeIn": {
"name": "john",
"subType": {
"approve": "yes",
"reject": "no"
},
"projects": [
{
"projectNumber": "1"
},
{
"projectNumber": "2"
}
]
}
}
}
The result is an empty mapping:
The Remedy
The challenge can be remedied by flattening the request so that the approve and reject elements are at the same level as name as is the list with projects.
When I start an instance of this, using the request:
{
"params": {
"applicationName": "SMPMessageStartComplexRequest",
"processName": "SMPMessageStartSimpleRequest"
},
"dataObject": {
"nameIn" : "John",
"simpleTypeIn": {
"approve": "yes",
"reject": "no"
},
"projectsIn": [
{
"projectNumber": "1"
},
{
"projectNumber": "2"
}
]
}
}
The result is as I would expect it to be:
Of course, internally I can map the individual input arguments to a data objects that is based on the complex Business Type.
Next articles on the subject:
Previous articles on the subject:
No comments:
Post a Comment