Complete Upgrade Prerequisites

You must complete all the prerequisites that apply to your instance and your instance must pass the upgrade eligibility check before your instance is ready for upgrade. You can complete these steps at any time.

After you complete the upgrade prerequisites, you can check your instance's upgrade eligibility. In the navigation pane, click Settings, then Upgrade. You can recheck eligibility at any time.

Eligibility Check Table

The eligibility check table shows the following information about status of your instance's upgrade eligibility:

Column Description
Eligibility Condition The condition that must be met to be ready for upgrade. Some conditions include links to associated documentation.
Owner Who is responsible for managing the condition.
Due Date The date by which the condition should be met.
Eligibility Status The status of the condition, including explanations for conditions that haven't been met. Expand the More details... to see additional information about the condition failure.

Oracle periodically checks your instance's upgrade eligibility. When your instance is ready, Oracle will inform you in the interface and by email, so that you can schedule your upgrade. See 2. Schedule the Upgrade and Configure Settings.

Prerequisite Details

Note:

Some of the prerequisites listed here don't have associated checks on the Upgrade page. Make sure you complete all the prerequisites that apply to your instance.
Area Typical owner Eligibility condition Tasks to Complete
Connectivity Agent Development Operations team

Prepare for conversion to OAuth 2.0

During the upgrade, connectivity agents are automatically converted from using basic authentication to using OAuth 2.0 token-based authentication to communicate with Oracle Integration. OAuth 2.0 token-based authentication is more secure, and it makes connectivity agent configuration simpler in Oracle Integration 3 than in Oracle Integration Generation 2.

However, before upgrade you must prepare for this conversion by allowing egress from the agent network to Oracle Integration design-time and runtime, and to the Oracle Identity Cloud Service or the identity domain.

For more information on OAuth 2.0 support in Oracle Integration 3, see When is Basic Authentication Supported in Oracle Integration 3?.

Connectivity Agent Development Operations team

Agent Java Version and JKS KeyStore

Ensure that the connectivity agent uses JDK 17 and PKCS12 KeyStore. The Connectivity Agent Status section shows the status of all the connectivity agents in your instance, indicating whether each agent is using the proper version of JDK and KeyStore and whether it's in use.
  1. For any connectivity agent that isn't already using JDK 17, install JDK 17 on the server that hosts the agent.
  2. For any agent that is still using the JKS KeyStore, convert the KeyStore to PKCS12 KeyStore. You can do the conversion in one of two ways:
    • Automatically, during upgrade: Your JKS KeyStore will automatically be converted to the PKCS12 KeyStore during upgrade.
    • Manually, before upgrade: Alternatively, you can convert the JKS KeyStore to the PKCS12 KeyStore manually, before upgrade, by following the steps below.

    Note:

    Converting the JKS KeyStore to the PKCS12 KeyStore doesn't impact your Oracle Integration Generation 2 connectivity agent, and only takes effect after you have upgraded to Oracle Integration 3.

    Complete the following steps before upgrade if you want to manually convert your JKS KeyStore to the PKCS12 KeyStore. These tasks require you to briefly stop and then restart the connectivity agent, so choose a time when the connectivity agent isn't being used.

    1. On the server that hosts the connectivity agent, create a backup of the keystore.jks file, which is located in the following folder:

      Agent_Install_Location/agenthome/agent/cert

    2. Move the backup file to a different folder.

    3. Convert the JKS KeyStore to the PKCS12 KeyStore by running the following command from the command line:

      keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.p12 -srcstoretype JKS -deststoretype PKCS12 -deststorepass changeit -srcstorepass changeit

    4. Stop the connectivity agent.

    5. Delete the keystore.jks file in the following location:

      Agent_Install_Location/agenthome/agent/cert

    6. Start the connectivity agent.

Connectivity Agent Development Operations team

Connectivity agent must be running

Make sure the connectivity agent is up and running before the upgrade begins. The Connectivity Agent Status section shows the status of all the connectivity agents in your instance, indicating whether each agent is offline (unavailable) and whether it's in use.

Agents that are offline during upgrade or don't meet upgrade requirements won't be upgraded. You'll need to perform post-upgrade steps to regain connectivity.

In Oracle Integration Generation 2, the connectivity agent uses basic authorization to invoke Oracle Integration endpoints. During the upgrade, the connectivity agent is automatically converted from using basic authentication to using OAuth 2.0 token-based authentication to invoke Oracle Integration endpoints. All connections are automatically upgraded to OAuth 2.0, so you don't need to manually recreate any connections yourself.

As a result of the new authentication method, you'll see additional traffic to your firewall after the upgrade. This additional traffic occurs because the connectivity agent must communicate with the server to get new tokens.

Connectivity Agent Development Operations team

Update your allowlist settings

Before upgrade, you must update your allowlist settings to configure connectivity from your connectivity agents to Oracle Identity Cloud Service (IDCS) and the Oracle Integration runtime URL and IP addresses. Perform the following updates:
  • Add the URL for Oracle Identity Cloud Service (IDCS) to the allowlist.
  • Add the runtime URL and IP addresses for Oracle Integration to the allowlist.
  • Set the proxy server's Cache property for the Oracle Integration URLs to refresh as frequently as possible.
Instances Administrator

Custom Endpoint URL

If your instance includes a custom endpoint, the instance can't be upgraded yet.

Wait until Oracle starts upgrades for this capability.

Instances Administrator

Instance ID change from integer to string

The system-generated instance ID that is displayed on the Instances page and in the activity stream for an integration instance has changed from an integer to a string in Oracle Integration 3. This may affect any systems that you use that rely on the instance ID being an integer. For example, if you are parsing the instance ID from a REST API and storing it in a database.

B2B for Oracle Integration Administrator

B2B Passwords for Keystore

Ensure that all passwords for the keystore file are identical, or the upgrade fails.

See 3. Update Allowlists and Complete Pre-Upgrade Tasks.

B2B for Oracle Integration Administrator

B2B AS2 adapter connections with identity certificates

If you have AS2 Adapter connections that use identity certificates, you must complete some pre-upgrade and post-upgrade tasks. See the IDENTITY Certificates.
B2B for Oracle Integration Administrator

B2B Retention Period

Oracle Integration 3 supports only 32 days of data retention. During upgrade only the most recent 32 days of retained data will be migrated.

For integrations, 32 or fewer days of retained data are typically sufficient. However, some organizations that use B2B for Oracle Integration prefer a higher setting so they have access to a longer history of purchase orders, invoices, and other B2B-related transactions and documents. You may be able to request a higher data retention period in the future.

Integrations Development team

Delayed (Asynchronous) Response

The delayed (asynchronous) response pattern isn't available in Oracle Integration 3.

If any of your integrations use a delayed (asynchronous) response pattern, rework them to achieve the delayed response functionality:
  • Create a simple invoke for success callbacks.
  • Create an additional invoke for failure callbacks under the fault handler to catch the correct fault.
Integrations Development Operations team

Failed Instances

Failed integration instances fall into one of the following categories:
  • Recoverable asynchronous instances
  • Non-recoverable synchronous instances

Recoverable asynchronous instances

Resubmit the failed instances and clear the queue. If the resubmission is successful and if Oracle detects no other issues, your instance is ready for upgrade. See Resubmit Failed Messages.

If you have a failed asynchronous instance and choose to upgrade anyway, you can't resubmit the failed instance in Oracle Integration 3--at least not right away. You can't resubmit because runtime data, including errors and all activity stream data, isn't migrated to Oracle Integration 3 as part of the upgrade. However, after the upgrade completes, you can run the integration in Oracle Integration 3, collect error data, and then resubmit.

Non-recoverable synchronous instances

You can't resubmit synchronous integration instances, so they are not recoverable. It's up to you whether to upgrade with non-recoverable synchronous instances.

Note:

If you capture activity stream data in the Oracle Cloud Infrastructure Console, you can still view historical activity for the integration. See Capture the Activity Stream of Integrations in the Oracle Cloud Infrastructure Console.
Integrations Development team

Identity Certificates

Identity certificates establish client identity during two-way SSL communication. Connections that are based on the AS2 Adapter and the REST Adapter can use identity certificates.

If you have identity certificates, perform the following steps:

  • When scheduling the upgrade, you'll need to select Ignore identity certificates during upgrade eligibility check. See 2. Schedule the Upgrade and Configure Settings.
  • After the upgrade: Upload a new identity certificate, test the connections that use the identity certificate so their status changes from Draft to Configured, and activate any integrations that use the connections.

    See 5. Complete Post-Upgrade Tasks.

Integrations Development team

VBCS with BYODB

If your instance uses Visual Builder with your own Oracle database instance, a configuration which isn't currently supported in Oracle Integration 3, revert back to using the embedded database. See the note about reverting your database in Switch to a Different Oracle DB instance in Administering Oracle Visual Builder in Oracle Integration 3.

Integrations Development team

Basic Routing Duplicate App Name

If your instance contains basic routing integrations that have the same source and target endpoint names, perform the following steps:
  1. Edit your basic routing integration, delete the target endpoint, and add it again with a different name.
  2. Save your integration.
Integrations Development team

Number of Active Integrations

An instance can have a maximum of 700 active integrations, as specified in the service limits.

If you have more than 700 active integrations, reduce the number, such as by deactivating or remodeling integrations.

Integrations Development team

Multiple Read File

The Read Multiple File operation was deprecated in Oracle Integration Generation 2.

If you have integrations that include an operation to read multiple files, rework the integrations so that they don't use this pattern. For example, use a listFile operation to list the files, and use a for-each action to read each file individually.

Integrations Development team

Legacy Stage File action in integrations

If your instance includes integrations that have legacy stage file actions from versions prior to Oracle Integration Generation 2, the upgrade eligibility check identifies the integration code and version.

For each integration, update all stage file actions:
  1. Edit the integration.
  2. For each stage file action:
    1. Edit the stage file action.
    2. Click Next at each screen.
    3. At the last screen, click Done.
  3. Save the integration.
Integrations Development team

API calls in Visual Builder application

If you created Visual Builder applications by creating a service connection from the catalog and they call REST APIs other than Integrations REST Endpoints, you must rewrite the applications by creating a service connection from the catalog, and the applications must use Oauth to authenticate.
Adapters Development team

Custom Adapter

If your instance includes integrations that use a custom adapter, the instance can't be upgraded yet.

Wait until Oracle starts upgrades for this capability.

Adapters Development team

Microsoft adapters

Microsoft decommissioned the Microsoft Outlook REST APIs in November 2022. If you use any of the following adapters, you must use the Microsoft Graph REST APIs instead.
  • Microsoft Office 365 Calendar Adapter
  • Microsoft Office 365 People Adapter
  • Microsoft Office 365 Outlook Adapter
See:
Adapters Development team

Unsupported Adapters

If your instance includes an integration that uses one of the following adapters, which aren't supported in Oracle Integration 3, replace the adapters with the REST adapter:
  • Automation Anywhere Adapter
  • Evernote Adapter
  • Oracle Messaging Cloud Service Adapter
  • Oracle Monetization Cloud Adapter
  • Oracle Taleo Business Edition (TBE) Adapter
  • UiPath Robotic Process Automation Adapter
Adapters Development team

Unsupported REST Types - REST Adapter

The following connection types are deprecated and not supported in a REST Adapter connection. Replace these connection types with different connection types. See Configure Connection Properties for Invoke Connections in Using the REST Adapter with Oracle Integration 3.
  • Metadata Catalog URL
  • Swagger Definition URL
  • RAML Definition URL
Developers with a REST API that is described using RAML or the Oracle metadata catalog must take the following action:
  1. Consult your REST service provider and ask for a Swagger definition (if available). Oracle Fusion Applications should have a Swagger option available. This is a guideline for all Oracle Fusion Applications.
  2. If an alternative spec is not available, use the basic template in the REST Adapter by selecting REST API Base URL as the connection URL and defining the target API request using the Adapter Endpoint Configuration Wizard.

Another option is to convert RAML into an OpenAPI specification to use with the REST Adapter connection.

To provide more robust and complete support for the Swagger/OpenAPI specifications, the REST Adapter includes a unified option to specify all OpenAPI specifications in a single field. This option also replaces the option to provide a Swagger definition URL, which is no longer available.

Process Automation Administrator

Process Automation

If you use the Processes capability but aren't using it in production, you have the option to skip process applications during upgrade. This approach is appropriate if you've tried Processes in non-production Oracle Integration Generation 2 environments but don't need or want to retain it in Oracle Integration 3.

Note:

  • If you have process in production, wait until Processes upgrade is supported.
  • Importing process applications created in Oracle Integration Generation 2 into Oracle Integration 3 isn't currently supported.

To skip process applications and move forward with upgrade, you must perform the following steps, which differ depending on your deployment. More than one situation might apply to your deployment.

  • If you don't have any process runtime transactions:

    The option to skip process applications is shown and is available.

    1. If you want to keep your process applications to later be used in Oracle Integration 3, export your process applications.
    2. When scheduling and configuring upgrade, select Upgrade and lose process applications and runtime data.
    3. After upgrade, if you want to leverage process or decision capabilities, you can enable Process Automation with Oracle Integration 3.
  • If you have process runtime transactions:

    The option to skip process applications is shown but is unavailable.

    1. Deactivate all your process applications.
    2. Schedule an archive and purge of process applications to get rid of completed and stale structured process instances. Set Purge Retention (Days) to 0.

      Wait 24 hours, then recheck upgrade eligibility as described above.

    3. While you're waiting to recheck upgrade eligibility, export your process applications to later be used in Oracle Integration 3.

      Note:

      Importing process applications created in Oracle Integration Generation 2 into Oracle Integration 3 isn't currently supported.
    4. After deactivating deployed applications, purging runtime data, and rechecking upgrade eligibility, the option to skip process applications should be available. When scheduling and configuring upgrade, select Upgrade and lose process applications and runtime data.
    5. After upgrade, if you want to leverage process or decision capabilities, you can enable Process Automation with Oracle Integration 3.
  • If you are calling Process from any integrations: You must remove the process action from the integration in order to pass the upgrade eligibility check for Process.

    After the upgrade, if you need an integration to call Process, you can use the REST adapter to do so.

  • If you are calling Process from any Visual Builder applications: You must remove any references to process applications from your Visual Builder applications.
Insight Administrator

Insight

Insight isn't supported in Oracle Integration 3. You can't use Insight in Oracle Integration 3. Use Oracle Cloud Infrastructure Logging Analytics and Process Automation Analytics.