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.
To see your precheck status or to run the check again, perform the following steps:
In the navigation pane, click Settings, then Upgrade.
You can see when the last precheck completed above the readiness check table.
The readiness check table shows the following information about the status of the precheck 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 More details... to see additional information about the condition failure. To copy the details to the clipboard, click .
If there are prechecks that didn't pass, perform the associated tasks to correct the issues.
To rerun the precheck, click Check again.
It takes about an hour for the precheck to complete.
Note
If Oracle attempted to upgrade your instance, you see the details of that attempt in the Upgrade Summary directly below the readiness check table.
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.
Make sure that your connectivity agents use JDK 17 and PKCS12 KeyStore. Expand More details to see the connectivity agents that need review. To copy the details to the clipboard, click . You can also 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:
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
Yes
Your connectivity agent should be up and running before the upgrade begins. Expand More details to see the connectivity agents that need review. To copy the details to the clipboard, click . You can also 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 aren't reachable 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
Yes
You should update your allowlist settings for your connectivity agents before upgrade. Expand More details to see the connectivity agents that need review. To copy the details to the clipboard, click . You can also 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 Cloud Infrastructure Identity
and Access Management (IAM) 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 aren't reachable 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.
Unsupported AgentGroup Identifier
Development Operations team
Yes
If any of your agent groups have a space in their identifiers, they won't be migrated to Oracle Integration 3. If you still need the agent groups, you'll need to recreate them after upgrade.
Instance Prechecks π
Eligibility condition
Typical owner
Applicable to Government region
Tasks to Complete
Custom Endpoint URL
Administrator
Yes
Depending on how your custom endpoint is configured pre-migration you'll perform different steps and the upgrade process will handle the custom endpoint differently. Expand More details to determine how to proceed with upgrade.
During upgrade, the upgrade process configures your custom endpoint and any alternate custom endpoints in Visual Builder.
If you're not using Visual Builder and you have alternate custom endpoints, delete them from your Oracle Integration Generation 2 instance. Oracle Integration 3 currently doesn't support alternate custom endpoints.
If you're not using Visual Builder and your custom endpoint uses SSL:
To proceed with upgrade, set up a load balancer in front of your Oracle Integration Generation 2 instance and remove the SSL certificate.
During upgrade, the upgrade process configures your custom endpoint in Oracle Integration 3.
After upgrade, runtime access to your integrations will continue to work as it did for Oracle Integration Generation 2. For all other access pointsβsuch as design-time and Process
Automationβyou still access the custom endpoint, but the custom endpoint then redirects to the appropriate URL.
If none of these situations apply and this precheck passed, the upgrade process configures your custom endpoint in Oracle Integration 3, and the custom endpoint will work as described in the previous bullet for the SSL scenario.
Instance ID Action
Administrator
Yes
The system-generated integration instance ID that is displayed on the Instances page and in the activity stream for an integration instance has changed from a numeric value to an alphanumeric value in Oracle Integration 3. The value's data type is unchanged; it remains a string data type. The change to an alphanumeric value may affect any systems that you use that rely on the integration instance ID being a numeric value. For example, if you parse the integration instance ID from a REST API and store the integration instance ID in a database as a number field, you'll need to update the database field.
If you have integrations that use integration instance IDs, the precheck shows a warning. Expand More details to see the integrations that need review. To copy the details to the clipboard, click .
If you need additional time to make the updates required for this change, you can keep the integration instance ID as numeric temporarily (six months post upgrade). See FlowId Conversion Support. Make sure you note which integrations are affected by copying the details as described above.
Note: This precheck just checks for the existence of integrations that use instance IDs, not the accuracy of the instance IDs. The warning will remain after you update your integrations, but doesn't impact your upgrade.
Daily Email Limit
Administrator
Yes
Oracle Integration 3 can send a limit of 10,000 emails in a rolling 24-hour window, as described in Service Limits. If your deployment needs to send more than that, you can instead use your customer tenancy. See Configure Notification Emails.
Custom scopes in IDCS
Administrator
No
Oracle Integration 3 adds a default scope (/ic/api/ , urn:opc:resource:consumer::all) to Oracle Identity Cloud
Service (IDCS) when the instance is created. It doesn't support any other custom scopes added to IDCS. If you have created custom scopes in IDCS, you must remove them.
Other Failures
Varies
Yes
If there are any other issues that will block upgrade that don't have specific prechecks, they'll be included under other failures. Expand More details to see the issues that need action. To copy the details to the clipboard, click .
B2B for Oracle Integration Prechecks
π
Eligibility condition
Typical owner
Applicable to Government region
Tasks to Complete
B2B Retention Period
Administrator
No
Although you don't need to do anything to correct this precheck status, be aware that Oracle Integration 3 Standard and Enterprise editions support 32 days of data retention by default. During upgrade only the most recent 32 days of retained data will be migrated. Expand More details to see how many days of retained data you currently have. To copy the details to the clipboard, click .
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. To copy the details to the clipboard, click .
Identity Certificates
Development team
Yes
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. To copy the details to the clipboard, click .
If you have identity certificates, after the upgrade, you'll need to upload new identity certificates as described in Ensure Connectivity:
Basic Routing Duplicate App Name
Development team
Yes
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. To copy the details to the clipboard, click .
Multiple Read File
Development team
Yes
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. To copy the details to the clipboard, click .
Publish/Subscribe Integrations
Development team
Yes
If your instance includes integrations that publish messages or subscribe to messages from Oracle Integration, be aware that publish/subscribe (or pub/sub) integrations need to be converted to event-driven orchestrations. The integrations will be handled differently depending on their configuration:
Pub/sub integrations that use attachments can't be automatically converted at this time. If you want to proceed with upgrade, you can either remove these integrations or ignore precheck failures. After upgrade, you can recreate them, pushing the attachment into the FTP server or Object Storage in your tenancy and passing the reference to the subscriber flow. See Define Header-Based Subscription Filtering in Using Integrations
in Oracle Integration 3.
All other active pub/sub integrations are automatically converted during upgrade. Pub/sub integrations in a draft state can't be migrated, and will be blank post-upgrade.
If you've mapped data in the subscriber flow, the mappings are converted as accurately as possible. However, after upgrade, you should review the mappings and correct them if necessary.
If you see the error Only Subscribers are present, no Publishers, you have orphan subscribers that must be deleted before upgrade.
Expand More details to see the integrations that can't be automatically converted. To copy the details to the clipboard, click .
Note: You might want to take this opportunity to delete any draft Publish flows.
DT API Basic Auth to OAuth action
Development team
Yes
If your instance includes integrations that access DT (design-time) built-in APIs using a REST connection with basic authentication, you must change them to use OAuth.
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. To copy the details to the clipboard, click .
Oracle Utilities
Adapter
Development team
Yes
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. To copy the details to the clipboard, click . See Using Swagger 2.0 REST catalog with Oracle Utilities Adapter version 24.04.0 or higher.
Unsupported Adapters
Development team
Yes
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
Note: Robotic process automation (RPA) capabilities are available in Oracle Integration 3. See Learn About Robots and Build a Robot in Using Robots in Oracle Integration 3.
Expand More details to see which unsupported adapters you're using. To copy the details to the clipboard, click .
Unsupported REST Types
Development team
Yes
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. To copy the details to the clipboard, click .
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.
Visual Builder Prechecks
π
Eligibility condition
Typical owner
Applicable to Government region
Tasks to Complete
Custom Endpoint URL
Administrator
No
This was also covered in the Instance Prechecks, but is repeated here since it applies to Visual Builder.
If you have a custom endpoint and you're using Visual Builder:
During upgrade, the upgrade process configures your custom endpoint and any alternate custom endpoints in Visual Builder.
VBCS
Administrator
No
If you use Visual Builder with your own Oracle database instance (BYODB), Autonomous Transaction
Processing (ATP) must be up and running during upgrade.
Make sure to complete the additional tasks described in Prepare Visual Builder for the Upgrade in Administering Oracle
Visual Builder in Oracle Integration 3.
Process
Automation Prechecks
π
Eligibility condition
Typical owner
Applicable to Government region
Tasks to Complete
Process
Automation
Administrator
No
There are several differences between Process in Oracle Integration Generation 2 and Process
Automation in Oracle Integration 3. See Process FAQs.
Depending on how you're using Process in Oracle Integration Generation 2, you'll use a different option to upgrade or migrate. See Process Upgrade Options.
Process Action
Administrator
No
If you're using the Process action in any integrations, you'll need to replace or remove the Process action prior to upgrade. Use the method described in the Process upgrade option that applies to your situation.
Process Applications
Administrator
No
If you have Process instances that are not actively used, then you will see this warning precheck.
Your instance will be upgraded without Process Automation. Runtime transactions (completed or in-progress) will be lost. Before the upgrade, export any design time Process applications that you want to retain from Oracle Integration Generation 2. If you don't want to retain them, you don't need to do anything. Expand More details to see additional information.
If you want to retain audit, see this section that describes how you can save runtime data from Oracle Integration Generation 2 Process.
Note
The backup data is retained for a period of six months after upgrade.
During upgrade, Process will not be enabled on Oracle Integration 3 and Process applications will not be migrated.
Post upgrade, you don't need to do anything. But, if you want to use Process, you can enable it and re-import your design time applications.
If you did not export your design time Process applications before the upgrade and if you need them post upgrade, submit a service request (SR) on My Oracle Support.