In a short series of articles, I will discussed some challenges you may face when upgrading Oracle Integration Gen2 (OIC 2) Process (PCS) to Gen3 (OIC 3) Oracle Process Automation (OPA) applications. These provide 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.
When you have implemented a somewhat more complex Process application in OIC 2, you are likely in the situation where you need to take some action before you can do an in-place upgrade or migrate to OPA. An in-place upgrade means that Oracle upgrades the OIC 2 instance to OIC 3 without you having to do anything other than perhaps reactivate your application. When that is not possible (and there are a few situations where that will be the case) you must fall back to a migration scenario, where you instantiate an OIC 3 instance, export the applications from OIC 2, import them into OPA, refactor a bit and then bring them live on OIC 3. For practically all Process applications that I have worked on, migration with refactoring is the only option at the moment.
I will go through several cases, explain the challenge and provide you my view on how to address it. For now this only concerns Structured and not Dynamic Processes.
Starting a Process Instance as a Webservice
PCS exposes SOAP webservices that you can use to start an instance of a Process application. You can find the WSDL's for that by going to Processes > Process Applications > Activate > find the application you want to call > from the hamburger menu choose Web Services. The Exposed tab shows al WSDL's. In the past I have used that for all cases where the Process application was started via an integration and for testing from SoapUI.
The challenge
OPA does not support a SOAP interface. Instead, you have to call a new REST API.
The Remedy
Unfortunately you cannot prepare this on OIC 2, as there the alternative for the SOAP service would be to use the POST of the /ic/api/process/v1/processes REST API, which is not supported by OPA. For OPA you must use a POST on the /process/api/v1/instances API, which has an interface that is not backward compatible with that of OIC 2. You therefore cannot mitigate by changing the endpoint only. Instead you will have to refactor the invoke from the integration, which implies you cannot do an in-place upgrade.
Consuming SOAP Integrations
With PCS you can use an Integration with a SOAP interface via "Use an integration".
The challenge
OPA cannot use any Integration with a SOAP interface and as far as I know never will.
The Remedy
This can be prepared on OIC 2 by replacing the Integration's SOAP interface by a REST interface (consider creating a new integration using the same identifier but other major version number), or by implementing an "adapter" Integration with a REST interface which then calls the Integration with the SOAP interface.
