Complete Upgrade Prerequisites

You must complete all the prerequisites that apply to your instance. You can complete these steps at any time before upgrade.

After you complete the upgrade prerequisites, you can check your instance's upgrade readiness. In the navigation pane, click Settings, then Upgrade. You can recheck readiness at any time. It takes about an hour for the check to complete. You can see when the last check completed above the readiness check table.

Readiness Check Table

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

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 readiness. Oracle will inform you in the user interface and by email, when your upgrade has been scheduled. See 2. Schedule the Upgrade and Configure Settings.

Summary of Prerequisites

This table summarizes the prerequisite tasks for each area. The details for each task are linked in the table and shown in the next section.

Area	Tasks
Connectivity Agent	Prepare for conversion to OAuth 2.0 Agent Java Version and JKS KeyStore Connectivity agent must be running Update your allowlist settings
Instances	Instance ID change from integer to string
B2B for Oracle Integration	B2B Passwords for Keystore B2B AS2 adapter connections with identity certificates B2B Retention Period
Integrations	Delayed (Asynchronous) Response Failed Instances Identity Certificates VBCS with BYODB Basic Routing Duplicate App Name Number of Active Integrations Multiple Read File Legacy Stage File action in integrations
Adapters	API calls in Visual Builder application Custom Adapter Microsoft adapters Unsupported Adapters Unsupported REST Types - REST Adapter
Process Automation	Process Automation
Insight	Insight

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	In Oracle Integration Generation 2, the connectivity agent uses basic authorization to invoke Oracle Integration endpoints. Oracle Integration 3 instead uses OAuth 2.0 token-based authentication, which is more secure. During the upgrade, your connectivity agents connections are automatically converted from using basic authentication to using OAuth 2.0, so you don't need to manually recreate any connections yourself. 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. And, after upgrade, as a result of the new authentication method, you'll see additional traffic to your firewall. This additional traffic occurs because the connectivity agent must communicate with the server to get new tokens. 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. For any connectivity agent that isn't already using JDK 17, install JDK 17 on the server that hosts the agent. 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. 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` Move the backup file to a different folder. 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` Stop the connectivity agent. Delete the `keystore.jks` file in the following location: `Agent_Install_Location/agenthome/agent/cert` 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.
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 Oracle Integration. Perform the following updates as part of the pre-upgrade tasks as your upgrade window gets closer: Add the URL for IDCS to the allowlist. Add the design-time and runtime URLs 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	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. See Adapting to Instance ID Change when upgrading to Oracle Integration 3.
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.
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 your instance includes connections that use identity certificates, the upgrade eligibility check identifies the names of the identity certificates and the connections that use them. 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: Edit your basic routing integration, delete the target endpoint, and add it again with a different name. 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 readiness check identifies the integration code and version. For each integration, update all stage file actions: Edit the integration. For each stage file action: Edit the stage file action. Click Next at each screen. At the last screen, click Done. 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: Invoke Operations Page in Using the Microsoft Office 365 Calendar Adapter with Oracle Integration 3 Invoke Operations Page in Using the Microsoft Office 365 People Adapter with Oracle Integration 3 Invoke Operations Page in Using the Microsoft Office 365 Outlook Adapter with Oracle Integration 3
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: 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. 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 can upgrade to Oracle Integration 3. Note If you use Process in production, you're not eligible to upgrade at this stage. Continue to use Oracle Integration Generation 2. There are several differences between Processes in Oracle Integration Generation 2 and Process Automation in Oracle Integration 3. See How Upgrade Affects Process Features. Depending on your deployment, you might need to complete some steps to move forward with upgrade. More than one situation might apply to your deployment. If you don't have any Process runtime transactions, you don't need to do anything. If you have Process runtime transactions and you want to remove runtime data to make your instance eligible for upgrade, perform the following steps. WARNING: Do not perform these steps in a production instance. Deactivate all your Process applications. 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 readiness as described above. If you are calling Process from any integrations: You must remove the Process action from the integration in order to pass the upgrade readiness check for Process. After the upgrade, if you need an integration to call Process, you can use the REST adapter to do so. What happens during upgrade: We export your Process applications from Oracle Integration Generation 2. We create an instance of Process Automation and associate it to your Oracle Integration 3 instance. We convert your Process applications to work in Oracle Integration 3. If any of your Process applications use unsupported actions (for example, an Insight activity), we replace those actions with placeholder actions that you must replace or remove after upgrade. See Complete Post-Upgrade Tasks for Process Automation. We import your converted Process applications into Oracle Integration 3.
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.

Oracle Cloud Infrastructure Documentation