Introduction

PCS was Oracle’s first process automation solution for the Oracle cloud and it was released in 2015. Oracle’s Integration Cloud (OIC) is an integrated platform suite that includes PCS and ICS and was released in 2017. OIC is available today on Oracle’s latest generation 2 infrastructure platform and is managed by Oracle. 

The Process component of OIC has lot of new features including dynamic processes, new notification capabilities (form as attachment, etc) in human workflow, improved DMN Modeling and its integrated lifecycle with process, improved web forms and developer capabilities (including better debugging), improved interoperability with integration flows, unified management with OIC integrations, etc. 

Oracle Integration Cloud is, and will continue to be, Oracle’s flagship integration and process automation solution. New features and capabilities will be added to OIC whereas the older ICS and PCS services will only get routine maintenance for patches, etc. For this reason we urge customers to migrate their older ICS and PCS applications to OIC. 
 

PCS to OIC Migration guidelines

This post provides guidance for migrating process assets from PCS to OIC. OIC provides an import tool to help you migrate design time metadata of process applications and decision models. The tool does have some limitations however and does not migrate following discontinued features :

• Basic forms (aka Frevvo forms) – OIC supports a newer form technology known as web forms. The import tool will create an empty web form, which will retain links to human tasks and data associations. A best practice, and our recommendation, is to reimplement these basic forms using web forms.
• Business rules – Business rules are imported in readonly mode, which will continue to run, but cannot be edited. Our recommendation is to reimplement these business rules using DMN.
   

Pre-migration steps

In addition to being aware of the two issues mentioned above, you should perform the following:-

• If a PCS process calls any integrations in ICS, export those integrations from ICS and import them into OIC.
• Migrate all users, groups and roles used in PCS from SIM to IDCS. See https://docs.oracle.com/en/cloud/paas/identity-cloud/uaids/migrate-traditional-cloud-accounts-cloud-accounts-identity-cloud-service.html
  • Role names in traditional account and IDCS are different. The following document provides deails on how to handle the mapping between them.  https://docs.oracle.com/en/cloud/paas/identity-cloud/uaids/map-traditional-cloud-roles-and-app-roles-oracle-identity-cloud-service.html
  • Make sure that names use the exact same case in IDCS as in SIM.
• Single Sign On Setup - If you have any Federated SSO configurations in the PCS environment, this will need to be replicated manually in the OIC environment
• Token-based authentication - If you configured OAuth to work with PCS, this will need to be replicated manually in the OIC environment
• Setup OIC integrations with other required Oracle PaaS Services:
  • CEC - configure CEC settings in the WorkSpace Administration -> Services configuration page
  • Notification service – configure under services on infrastructure tab
• Size OIC with the required message packs. PCS sizing is based on named users, while OIC sizing is based on message packs calculated based on number of concurrent users (1 distinct user = 400 messages). One message pack supports up to 5K messags/hr.
   

Migration

Use the import tool available either from UI ( https://docs.oracle.com/en/cloud/paas/integration-cloud/integration-cloud-auton/import-process-design-time-metadata.html ) or command line ( https://docs.oracle.com/en/cloud/paas/integration-cloud/integration-cloud-auton/import-using-import-command-line-utility-1.html ).

The import tool moves process applications and active decision models for the scope provided (e.g. entire instance, selected space, or individual applications etc).

Alternatively, you can export an application from PCS and import it into OIC. This export/import handles only one application at a time, that is why using the import tool is the recommended approach.
 

Access the import UI tool via OIC Home -> Processes -> Administration

• Run import tool only once for the specified scope. Running it multiple times for same scope can cause unpredictable results.
• Download and review the import logs to check details and look for any errors encountered. 
• Give needed permission to space migrated in OIC by import tool - Space created in OIC will be owned by same user, who owns this space in PCS, and not by user who ran import tool in OIC. So, give permission to needed users in OIC.

Post-migration steps

• Activate all integration flows and DMNs
• Configure purge and archive as per business requirements. Be aware that default purge settings are more aggressive in OIC than in PCS
• Open Process Applications and check/update the following as required:
  • Navigate to Decisions and update the references.
  • Navigate to Integrations and update the references to integration flows in the same OIC instance.
  • Review Integration bindings (urls, credentials, etc) to make sure they are pointing to the right resources. This can also be done via WorkSpace -> Administration -> Manage Credentials
  • If certificates were imported in PCS, they also need to be imported into OIC. If using the REST and SOAP native connector, they may need certificates to work correctly.
• Activate Process Application(s) - This can be done via OIC Console or leveraging the Process REST APIs that allows activating Process Applications
• Once Process Application(s) have been activated, it is necessary to remap the memberships of process roles (swim lanes) we had in PCS into OIC. This can be done from the WorkSpace Administration page and alternative using a custom application using the REST API
   

In-flight and completed instance migration

It is not possible to migrate in-flight and completed instances from PCS to OIC. There are two options.

• Short lived instances:- During a transition period, run PCS and OIC in parallel. New instances should be created in OIC only. Users can go to the PCS workspace to complete existing tasks and use the OIC workspace to create new instances and work on new tasks. During this time, users have to use two workspaces. After all instances on PCS are complete, then users will use OIC only.
• Long lived instances:- 
  • Use “Alter Flow” in PCS to terminate instances.
  • Create new instances with the same payload as in PCS in the OIC environment. Use “Alter Flow” in OIC to move newly created replicas of the PCS instances to the correct activity in the OIC process.
  • Alter flow in PCS and OIC can be invoked programmatically via APIs to automate this.
• In both options, historic information will not be propagated from PCS to OIC. Customer will have to get this from PCS either using REST APIs or exporting data from database tables. 
   

Additional Migration Best Practices

• Even though you can create integrations using REST and SOAP connectors in process applications, our recommendation is that you access all such connections using OIC integration flows. The result is that all integrations are centralized and managed from your OIC integration flows.
• Use new Task List in OIC for end users. This is more lightweight and more performant (developed using Oracle JET). Use the Workspace mainly for advanced users and tracking purposes. 
   

OIC Process Migration Documentation

https://docs.oracle.com/en/cloud/paas/integration-cloud/ics-pcs-migration-to-oci-b/learn-migrating-oracle-cloud-infrastructure.html