For more details on this recommendation, see Upgrade FAQs.

1. Create a new OCI Process Automation standalone instance.

   See Provision a Process Automation Instance in Administering Oracle Cloud Infrastructure Process Automation.

   When you create the instance:

   • Select a metering model based on an Execution Pack to leverage free tier pricing during the upgrade.
   • The user that creates the OCI Process Automation standalone instance must be from the same identity domain as the user that created your Oracle Integration Generation 2 instance.
   • You must create the OCI Process Automation standalone instance in the same tenancy, the same region, and, preferably, the same compartment as your Oracle Integration Generation 2 instance.

     If you don't use the same compartment, make sure that the user that creates the OCI Process Automation instance has permissions to manage both the Oracle Integration instance and the OCI Process Automation instance.

     You manage these permissions with IAM policies.

     For Oracle Integration:

     • allow group domain-name/group_name to manage integration-instance in compartment compartment-name
     • allow group domain-name/group_name to manage integration-instance in tenancy

     For example:

     • allow group admin/oci-integration-admins to manage integration-instance in tenancy

     For OCI Process Automation:

     • allow group domain-name/group_name to manage process-automation-instance in compartment compartment-name
     • allow group domain-name/group_name to manage process-automation-instance in tenancy

     For example:

     • allow group admin/oci-integration-admins to manage process-automation-instance in tenancy
2. Grant developers access to OCI Process Automation.

   To ensure your developers can access the newly provisioned OCI Process Automation instance and can work on subsequent tasks, ensure that they're assigned the appropriate IDCS application role to access the instance. See Assign IDCS Application Roles to Groups in an Identity Domain in Administering Oracle Cloud Infrastructure Process Automation.

3. Register a non-production Oracle Integration Generation 2 instance for testing.

   If your process applications are calling existing integrations, register Oracle Integration Generation 2 in the new OCI Process Automation instance. This allows your OCI Process Automation instance to connect and discover your existing integrations.

   Ensure that you use a non-production Oracle Integration Generation 2 instance for service registration in this step. Make sure that registering the selected Oracle Integration Generation 2 instance won't adversely impact any processes in production.

   1. Choose a non-production Oracle Integration Generation 2 instance to register.
   2. In the Oracle Cloud Infrastructure Console, find and take note of the OCID of the selected Oracle Integration Generation 2 instance.
   3. In OCI Process Automation, register the Oracle Integration Generation 2 instance. See Register Services in Using Oracle Cloud Infrastructure Process Automation.
      Note
      
      You may want to create a dedicated ServiceAccount user for this connection.

1. Determine which applications you want to migrate.

   You may want to take this opportunity to get rid of unnecessary applications. Think about whether you want to migrate only those applications that are in your production environment or if you want to also migrate applications that are in test and development.

   If you're going to migrate individual applications, take note of the applications you want to migrate and any dependencies they have.

2. Migrate your applications using one of the following methods:
   • Migrate all applications in bulk
     1. In the Oracle Cloud Infrastructure Console, create an Object Storage bucket. See Creating an Object Storage Bucket.

        The storage bucket URL you'll need in the next step is in the following format:

        https://swiftobjectstorage.region.oraclecloud.com/v1/namespace/bucket

        Where:

        • region is the identifier of your Oracle Cloud Infrastructure (OCI) data center.
        • namespace is the tenancy where you created your bucket.
        • bucket is your bucket name.
     2. Make a POST request to your Oracle Integration Generation 2 instance to export your applications:

        curl -X POST https://Generation2_hostname/ic/api/process/v1/exportArtifactsInternal

        With the following payload:

        {
            "jobId": "enter_a_descriptive_ID",
            "storageInfo": {
                "storageUrl": "Swift_storage_bucket_URL",
                "storageUser": "OCI_Console_user",
                "storagePassword": "OCI_Console_user_password"
            }
        }

        You’ll know the export job is complete when you see the process_status.json file in your bucket. This file contains the status of the job, its completion percentage, and, if failed, the error message. You should also see the following content in your bucket:

        • Process/project folder—contains all your process applications.
        • Process/dmn folder—contains all your decision models.
     3. After the applications have been exported into your bucket, make a POST request to your Oracle Integration 3 instance to migrate your applications:

        curl -X POST https://Integration3_hostname/process/api/v1/oic-migration/jobs/

        With your tenant ID:

        x-tenant-id: tenant_OCID

        And your bucket information:

        {
            "bucketInfo": {
                "region": "region",
                "namespace": "namespace",
                "bucket": "bucket"
            }
        }

        See Security, Authentication and Authorization in REST API for Oracle Cloud Infrastructure Process Automation.

     4. Wait for the migration job to complete. To check the status of the migration job:

        curl http://localhost:8080/process/internal-api/v1/oic-migration/jobs/job_ID

   • Migrate individual applications
     1. Export the Oracle Integration Generation 2 process applications.

        In the Oracle Integration Generation 2 instance that includes the applications you want to migrate, export each application you want to migrate. See Export an Application in Using Processes in Oracle Integration Generation 2.

     2. Import the process applications into OCI Process Automation.

        In OCI Process Automation, import the Oracle Integration Generation 2 process applications. See Import an Application in Using Oracle Cloud Infrastructure Process Automation.

        OCI Process Automation converts the legacy process applications to the latest product version.

3. Review the migration report.

   When the import and conversion is complete, you'll see a migration report showing what was successfully imported, what needs additional work, and any items that couldn't be migrated. This gives you an idea of migration issues that you'll need to handle.

   You can refer back to the original migration report in the main menu. See Import an Application in Using Oracle Cloud Infrastructure Process Automation.

Application Roles have significantly changed in OCI Process Automation. ProcessOwner, AnalyticsViewer, and ProcessReviewer roles are now explicitly defined for each application, enabling you to control their members and permissions.

The following table shows how the Oracle Integration Generation 2 roles map to the OCI Process Automation roles.

The new roles are available after the migration, but you need to add members (users and groups) to them. You'll probably need to reference your Oracle Integration Generation 2 environment to see which members should be assigned to each role.

If OCI Process Automation shares the same identity domain as your existing Oracle Integration Generation 2 instance, existing users and groups should be available for selection.

You can add members either before activation in the Designer or after activation in the Workspace.

• Work with Roles in Designer
• Manage Roles in Workspace

For additional information on OCI Process Automation, see Configure Roles for Process Applications in Using Oracle Cloud Infrastructure Process Automation.

To validate and activate your process applications, perform the following steps:

1. Validate each application and fix any errors and warnings.

   Validate each application from the Designer by clicking and choosing Validate from the menu.

   To resolve validation issues, see How Upgrade Affects Process Features.

2. Activate the application.

   After you've resolved all validation errors, you can activate your application. See Activate Applications in Using Oracle Cloud Infrastructure Process Automation.

• Integrations Calling Process
• Integrations Called by Process
• Visual Builder Applications
• Non-Oracle-Integration Clients
• Verification

Integrations Calling Process

Process APIs and endpoints have changed after the upgrade. As a result, you must update any integrations that use the Process Action to use the REST adapter instead. Perform these steps in your Oracle Integration Generation 2 instance.

1. Create a connection.

   Create a new REST based connection for OCI Process Automation, using the following settings.

   Setting	Value
   Role	Invoke
   Connector Type	REST API Base URL
   Connection URL	Base URL taken from your OCI Process Automation environment. For example: https://process-instance.process.oci.oc-test.com
   Security Policy	OCI Process Automation supports several grant types that map to the following in Oracle Integration: OAuth Client Credentials OAuth Resource Owner Password Credentials OAuth Authorization Code Credentials For more information on OCI Process Automation grant types, see Security, Authentication and Authorization in REST API for Oracle Cloud Infrastructure Process Automation. Regardless of which grant type you choose you'll need to provide the following information: Access Token URL—Also referred to as the Oracle Identity Cloud Service URL. For example: https://idcs-id.oraclecloud.com/oauth2/v1/token Client ID— The identifier you retrieved when you registered the confidential application in Oracle Identity Cloud Service (IDCS), or the identifier of your OCI Process Automation application. You can find the client ID when viewing the confidential application you configured in IDCS, on the Configuration tab, in the General Information section. Client Secret— The client secret issued to the client during the application registration process. Scope— The scope value associated with your OCI Process Automation instance registered in your confidential application. You can find the client ID when viewing the confidential application you configured in IDCS, on the Configuration tab, in the Accessing APIs from Other Applications section, under Allowed Scopes, in the scope that you added. For example: https://process-instance.process.oci.oc-test.com/process Client Authentication—Send client credentials as basic auth in header.

2. Test your connection to ensure it's configured correctly.
3. Update your integrations.

   For each integration that uses the Process Action:

   1. Create a new version or clone your integration.
   2. Replace the Process Action with the REST Connector configured above, using the following settings.

      Setting	Value
      Relative URI	To initiate a new process instance use the following URI: /process/api/v1/instances To call any other OCI Process Automation API, see REST API for Oracle Cloud Infrastructure Process Automation.
      Endpoint Action	POST
      Request Payload	Retrieve this from the OpenAPI specification. You can find the specification under the API section of the OCI Process Automation activation panel. This specification provides the definition of the payload needed to call your process.
      Data Mapping	Map the following: A parameter that uniquely identifies the process You can get the process Key from the title of the OpenAPI specification (see above) Data objects These are process specific and contain the actual data payload used to initiate the process.

   3. Activate your integrations.
   4. Test your integrations and ensure that a new process instance is created in OCI Process Automation.

Integrations Called by Process

OCI Process Automation supports REST based communication only via Service Registration. This means that connectivity to SOAP based integrations will no longer be possible.

If you have integrations that use a SOAP trigger and these are called by processes in Oracle Integration Generation 2, you will need to take additional steps to present a REST based interface to OCI Process Automation. This may mean that you need to do one of the following:

• Create REST-based wrapper integrations.

  or

• Change the existing trigger from SOAP to REST.

Additionally, for service registration to work as expected, ensure that your REST trigger utilizes the OAuth 2.0 or Basic Authentication Security policy.

Visual Builder Applications

Process API endpoints change after the upgrade. As a result, you must update any Visual Builder applications that interact with them, replacing any deprecated integration patterns. See Work with Business Processes in Building Responsive Applications with Visual Builder Studio.

To do this you may need to evaluate current process usage. Look through each of your Visual Builder applications and determine if they're making calls to process APIs via Action Chains, Direct Calls, or using embeddable process components (also referred to as CCA).

If your applications are calling Process endpoints, perform the following steps:

1. Connect to OCI Process Automation.

   Create a backend connection to OCI Process Automation. This backend will be used to establish a connection to the new OCI Process Automation instance. See Connect to Oracle Process Automation APIs in Building Responsive Applications with Visual Builder Studio.

2. Create a new version of your applications.

   Oracle recommends, creating a new version of your Visual Builder applications to implement required changes. See How to Create Versions of an Application in Developing Applications with Oracle Visual Builder.

3. Action Chains

   If your application is using action chains to start a process or take action on a task, you'll need to replace each of these with a REST-based Service Connection. Repeat these steps for each process action chain task.

   Triggering a Process

   Replace the Start Process action chain with a Catalog based Service Connection.

   1. Navigate to Oracle Integration Generation 2 and take note of the process you're calling. You can determine this either from the action chain process step or from the processes tab in the application menu on the left.
   2. Create a Catalog-based Service Connection to your process in the new version of your Visual Builder application. See Create a Service Connection from an OCI Process Automation Catalog in Building Responsive Applications with Visual Builder Studio. Ensure that you select the same process you were referencing before.
      Note
      
      Your process should already be activated.
   3. Create a Type based on the endpoint of the above process. See Create a Type from an Endpoint in Developing Applications with Oracle Visual Builder.
   4. Create a Variable based on the above type. See Create Variables in Developing Applications with Oracle Visual Builder.
   5. Navigate to your action chains and perform the following actions:
      1. Drag an Assign Variable Action above your current Start Process Action.
      2. Map the data fields and input parameters required to invoke your process. For an example, see Integrate Oracle Process Automation with Visual Builder.
      3. Drag the Call REST Action above your current Start Process Action.
      4. Configure the Call REST Action by selecting the POST/Instances endpoint.
      5. Map the above Variable to the request body of the REST Action.
      6. Delete the legacy Start Process Acton.
   6. Test the call, and ensure that your process is being called successfully in OCI Process Automation.

   GET Process Instance

   Replace the Get Process Instance action chain with a Catalog-based Service Connection.

   If you created a Catalog-based Service Connection to your process by following the steps above, you'll notice that Get Process Instance endpoint is now available in your service connection.

   Replace the legacy Get Process Instance Process Action with a Call REST Action that is configured with the above endpoint, and re-map the instanceID field.

   Note
   
   The response payload values here have changed.

   Other Process Actions

   Perform the following steps for all other Process Actions such as Perform Task and Get Task:

   1. Navigate to Oracle Integration Generation 2 and take note of the Process Actions you're using.
   2. Replace these Actions with endpoint-based Service Connections.

      The following table maps each of these actions to the corresponding OCI Process Automation API.

      Visual Builder Action	OCI Process Automation REST API	Description
      Perform Task	POST /process/api/v1/tasks/{id}/complete	Approval actions such as Approve, Reject, and so on.
      Perform Task	PUT /process/api/v1/tasks/{id}	Update the Task Priority, Payload, Title, and such.
      Perform Task	PUT /process/api/v1/tasks/{id}/payload	Update the Task Payload.
      Perform Task	POST /process/api/v1/tasks/{id}/claim	Claim a task.
      Perform Task	POST /process/api/v1/tasks/{id}/release	Release a task.
      Perform Task	POST /process/api/v1/tasks/{id}/request-for-info	Request for information on a task.
      Perform Task	POST /process/api/v1/tasks/{id}/submit-info	Submit the requested information for a task.
      Perform Task	POST /process/api/v1/tasks/{id}/reassign	Reassign a task.
      Get Task Collection	GET /process/api/v1/tasks
      Get Task	GET /process/api/v1/tasks/{id}
      Get Deployed Process Collection	GET /process/api/v1/instances
      Get Process Instance Collection	POST /process/api/v1/instances

4. Direct Calls

   Process APIs and endpoints change after the upgrade. As a result, you must update any direct service connections. See REST API for Oracle Cloud Infrastructure Process Automation.

5. CCA Components

   If you're using Oracle Integration Generation 2 Process CCA components, you must replace them with their equivalent OCI Process Automation component.

   Component Name	Oracle Integration Generation 2 CCA	OCI Process Automation Equivalent
   Task List	oj-pcs-task-list	oj-opac-task-list
   Task Detail	oj-pcs-task-detail	oj-opac-task-detail
   App List	oj-pcs-app-list	oj-opac-applist
   Start Form	oj-pcs-start-form	oj-opac-start-form
   DP List	oj-pcs-dplist	oj-opac-instance-list (Displays both Structured Process and Dynamic process)
   Visualization	oj-pcs-visualization	oj-opac-analytics (Cannot save visualizations)

Non-Oracle-Integration Clients

If you're calling process applications from outside Oracle Integration (for example, your own custom application), you need to update the REST endpoints and auth policies used to call the newly configured OCI Process Automation instance. For more information on the new API endpoints and supported auth policies, see REST API for Oracle Cloud Infrastructure Process Automation.

Verification

Perform a System Integration Test to validate your work.

Test the connectivity to the new process environment. This test should focus on validating the following interaction patterns based on your usage:

• OCI Process Automation - Processes to Oracle Integration Generation 2 - Integrations
• Oracle Integration Generation 2 - Integrations to OCI Process Automation - Processes
• Visual Builder - Applications to OCI Process Automation - Processes