Check Upgrade Readiness and Correct Precheck Issues

Oracle periodically performs some prechecks to determine your upgrade readiness so that your upgrade runs smoothly. If the prechecks don't pass, you may need to perform tasks to correct the issues.

After you correct any precheck issues, configure your upgrade settings.

View Your Precheck Status

To see your precheck status or to run the check again, perform the following steps:

1. In the navigation pane, click Settings, then Upgrade.

   The readiness check table shows the status of the precheck items. The precheck items are described below.

   You can see when the last precheck completed above the readiness check table.

2. If there are prechecks that didn't pass, perform the associated tasks to correct the issues as described below.
3. To rerun the precheck, click Check again.

   It takes about an hour for the precheck to complete.

Readiness Check Table

The readiness check table shows the following information about the status of the precehck items.

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.

Summary of Prechecks

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

Area	Tasks
Connectivity Agent	Agent Java Version Agent Connectivity for Oracle Integration 3 - Connectivity agent must be running Agent Connectivity for Oracle Integration 3 - Update your allowlist settings
Instances	Custom Endpoint URL Instance ID Action
B2B for Oracle Integration	B2B Retention Period
Integrations	Delayed (Asynchronous) Response Identity Certificates Basic Routing Duplicate App Name Number of Active Integrations Multiple Read File Publish/Subscribe Integrations
Adapters	Custom Adapters Oracle Utilities Adapter Unsupported Adapters Unsupported REST Types
Process Automation	Process Automation
Insight	Insight

Connectivity Agent Prechecks

Eligibility condition	Typical owner	Tasks to Complete
Agent Java Version	Development Operations team	Make sure that your connectivity agents use JDK 17 and PKCS12 KeyStore. Expand More details to see the connectivity agents that need review, or view the Connectivity Agent Status section to see the status of all the connectivity agents in your instance. 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: 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. If you want to manually convert your JKS KeyStore to the PKCS12 KeyStore, complete the following steps before upgrade. 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.
Agent Connectivity for Oracle Integration 3 - Connectivity agent must be running	Development Operations team	Make sure the connectivity agent is up and running before the upgrade begins. Expand More details to see the connectivity agents that need review, or view the Agent Status column in the Connectivity Agent Status section to see the status of all the connectivity agents in your instance, indicating whether each agent is offline (unavailable). Agents that are offline during upgrade or don't meet upgrade requirements won't be upgraded, in which case you'll need to perform post-upgrade steps to regain connectivity.
Agent Connectivity for Oracle Integration 3 - Update your allowlist settings	Development Operations team	Before upgrade, you must update your allowlist settings for your connectivity agents. Expand More details to see the connectivity agents that need review, or view the Allowlist status column in the Connectivity Agent Status section to see the status of all the connectivity agents in your instance, indicating whether the allowlist has been updated appropriately. As your upgrade window approaches, perform the following pre-upgrade tasks: Add the IP address for Oracle Identity Cloud Service (IDCS) to the allowlist. Add the design-time and runtime 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. Agents that are offline during upgrade or don't meet upgrade requirements won't be upgraded, in which case you'll need to perform post-upgrade steps to regain connectivity.

Instance Prechecks

Eligibility condition	Typical owner	Tasks to Complete
Custom Endpoint URL	Administrator	If your instance includes a custom endpoint, you'll see a warning in the precheck. You can safely ignore this warning. If you use a custom endpoint after upgrade, you'll see no difference in runtime access to your integrations. For all other access points—design-time, Visual Builder, Process Automation—you still access the custom endpoint, but the custom endpoint then redirects to the appropriate URL.
Instance ID Action	Administrator	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 parse the instance ID from a REST API and store the instance ID in a database as a number field, you'll need to update the database field. If you have integrations that use instance IDs, the precheck shows a warning. Expand More details to see the integrations that need review. Then update your systems and processes as required. See Adapting to Instance ID Change when upgrading to Oracle Integration 3.

B2B for Oracle Integration Prechecks

Eligibility condition	Typical owner	Tasks to Complete
B2B Retention Period	Administrator	Although you don't need to do anything to correct this precheck status, be aware that 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. Expand More details to see how many days of retained data you currently have.

Integrations Prechecks

Eligibility condition	Typical owner	Tasks to Complete
Delayed (Asynchronous) Response	Development team	The delayed (asynchronous) response pattern was previously supported in the following adapters: Oracle CX Sales and B2B Service Adapter Oracle ERP Cloud Adapter Oracle HCM Cloud Adapter Oracle Field Service Cloud Adapter Salesforce Adapter ServiceNow Adapter If you have integrations using delayed (asynchronous) response with one of these adapters, rework them by creating two invoke connections to achieve similar functionality: Create a simple invoke for success callbacks. Create an additional invoke for failure callbacks under the fault handler to catch the correct fault. Expand More details to see which integrations need review.
Identity Certificates	Development team	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. Expand More details to see the names of the identity certificates and the connections that use them. If you have identity certificates, perform the following steps after the upgrade as described in Complete Post-Upgrade Tasks: Upload new identity certificates. Test the connections that use the identity certificates so their status changes from Draft to Configured. Activate any integrations that use the connections.
Basic Routing Duplicate App Name	Development team	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, deleting the target endpoint, and adding it again with a different name. Save your integration. Expand More details to see the integrations that need review.
Number of Active Integrations	Development team	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 by deactivating or remodeling integrations.
Multiple Read File	Development team	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. Expand More details to see the integrations that need review.
Publish/Subscribe Integrations	Development team	If your instance includes integrations that publish messages or subscribe to messages from Oracle Integration, be aware that the upgrade will automatically convert every Publish/Subscribe integration to event-driven orchestration. Expand More details to see the integrations that will be converted.

Adapters Prechecks

Eligibility condition	Typical owner	Tasks to Complete
Custom Adapters	Development team	If your instance includes integrations that use a custom adapter, the instance can't be upgraded yet. Wait until Oracle starts upgrades for this feature. Expand More details to see the custom adapters you're using.
Oracle Utilities Adapter	Development team	Swagger 2.0 is no longer supported in the Oracle Utilities Adapter. If there is any existing integration using the Swagger 2.0 REST catalog, runtime won't be impacted. However, if you try to edit the design-time connection, retest the connection, refresh the metadata, refresh the artifacts, or reactivate, the integration fails. You must update the catalog to use the OpenAPI 3.x definition. Expand More details to see the integrations that need review. See Using Swagger 2.0 REST catalog with Oracle Utilities Adapter version 24.04.0 or higher.
Unsupported Adapters	Development team	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 Expand More details to see which unsupported adapters you're using.
Unsupported REST Types	Development team	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 Expand More details to see which unsupported REST types you're using. 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 Prechecks

Eligibility condition	Typical owner	Tasks to Complete
Process Automation	Administrator	There are several differences between Process in Oracle Integration Generation 2 and Process Automation in Oracle Integration 3. See How Upgrade Affects Process Features. Depending on how you're using Process in Oracle Integration Generation 2, you may need to complete some steps to move forward with upgrade. More than one situation may apply to your deployment. You have no Process runtime instances If you don't have any Process runtime instances, you don't need to do anything. You have Process runtime instances, but you don't need them If you have Process runtime instances, but you don't need them, you can remove the runtime data to pass the upgrade precheck and be able to move forward with upgrade. 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. You have Process runtime instances and you're actively using Process in production If you're actively using Process in a Oracle Integration Generation 2 production environment, Oracle can't automatically migrate you to Process Automation during the upgrade to Oracle Integration 3. You'll have to perform the migration manually. Perform manual migration if the following are true: You're using structured or dynamic processes in production. You have active process instances (usually long-running) which can't be completed prior to upgrade. You need to continue to serve new process application requests without any disruption. You don't need to perform manual migration if the following is true: You have short-lived process instances that can all be completed on Oracle Integration Generation 2 prior to upgrade. You leverage an external persistence layer to store the state of process instances. You are using decision only applications. Your process usage is in a pre-production state. See Migrate Actively Used Process Applications to Oracle Integration 3. You're calling Process from some of your integrations If you're calling Process from any integrations, you must remove the Process action from the integration to pass the upgrade precheck and be able to move forward with upgrade. If you need an integration to call Process, you can use the REST adapter to do so. Expand More details to see the integrations that call Process. What happens during Oracle-run upgrade These steps apply only if Oracle is automatically migrating you to Process Automation during the upgrade to Oracle Integration 3. They don't apply if you're performing a manual migration of Process. Oracle exports your Process applications from Oracle Integration Generation 2. Oracle creates an instance of Process Automation and associate it to your Oracle Integration 3 instance. Oracle converts 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. Oracle imports your converted Process applications into Oracle Integration 3.

Insight Prechecks

Eligibility condition	Typical owner	Tasks to Complete
Insight	Administrator	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.

Correct an Instance with Failed Readiness Checks

If your upgrade was scheduled and your instance is no longer ready for upgrade, address the findings so that your upgrade completes successfully.

1. In Oracle Integration, open the Upgrade page using one of the following steps:
   • In the navigation pane, click Settings, then Upgrade.
   • Click Announcements , and then click the link in the notification.
   The Upgrade page appears.

   

2. Review the conditions that didn't pass, and take the appropriate action. See Check Upgrade Readiness and Correct Precheck Issues for steps to take.
3. After addressing all issues, check the instance again.
   1. Click Check again.
      It takes about an hour for the check to complete. You can see when the last check completed above the readiness check table.
   2. Continue making corrections until the check passes.
      If you aren't sure how to correct an issue, enter a service request (SR) on My Oracle Support.