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:
- 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.
- If there are prechecks that didn't pass, perform the associated tasks to correct the issues as described below.
- 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 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 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 | |
| Instances | |
| B2B for Oracle Integration | |
| Integrations | |
| Adapters | |
| Visual Builder | |
| Process Automation |
Connectivity Agent Prechecks
| Eligibility condition | Typical owner | Blocks upgrade | Tasks to Complete |
|---|---|---|---|
|
Agent Java Version |
Development Operations team | No | 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.
|
|
Agent Connectivity for Oracle Integration 3 - Connectivity agent must be running |
Development Operations team | No | 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 | No | 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:
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. |
|
Unsupported AgentGroup Identifier |
Development Operations team | No | 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 | Blocks upgrade | Tasks to Complete |
|---|---|---|---|
|
Custom Endpoint URL |
Administrator | Yes |
If you use a custom endpoint for your instance and your instance is failing this precheck, expand More details to see what is causing the failure:
If you use a custom endpoint, you'll see no difference in runtime access to your integrations after upgrade. 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 | No | The system-generated 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 instance ID being a numeric value. 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. |
|
Daily Email Limit |
Administrator | No | 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 | Yes | 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. |
B2B for Oracle Integration Prechecks
| Eligibility condition | Typical owner | Blocks upgrade | 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 only 32 days of data retention. 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. |
Integrations Prechecks
| Eligibility condition | Typical owner | Blocks upgrade | Tasks to Complete |
|---|---|---|---|
|
Delayed (Asynchronous) Response |
Development team | Yes | The delayed (asynchronous) response pattern was previously supported in the following adapters:
If you have integrations using delayed (asynchronous) response with one of these adapters, rework them by creating two invoke connections to achieve similar functionality:
Expand More details to see which integrations need review. |
|
Identity Certificates |
Development team | No | 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:
|
|
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:
Expand More details to see the integrations that need review. |
|
Number of Active Integrations |
Development team | Yes | 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 | 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. |
|
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:
Expand More details to see the integrations that can't be automatically converted. Note: You might want to take this opportunity to delete any draft Publish flows. |
|
DT API Basic Auth to OAuth action |
Development team | No | 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. See OAuth Authentication in Oracle Integration. |
|
XSLT function definition |
Development team | Yes | Custom XSL function definitions that were added manually in the mapper aren't supported at this time. You can wait for Oracle to add support for this functionality, or, if you want to proceed with upgrade now, rework or remove the integration.
Expand More details to see the integrations that include custom XSL function definitions. |
Adapters Prechecks
| Eligibility condition | Typical owner | Blocks upgrade | Tasks to Complete |
|---|---|---|---|
|
Custom Adapters |
Development team | Yes | 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 | No | 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 | 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:
Expand More details to see which unsupported adapters you're using. Note that 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. |
|
Unsupported REST Types |
Development team | No | 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.
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:
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 | Blocks upgrade | Tasks to Complete |
|---|---|---|---|
|
VBCS |
Administrator | Yes | 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 Visual Builder Pre-Upgrade Tasks. |
|
VBCS-PWA |
Administrator | Yes | Oracle Integration 3 doesn't yet support Progressive Web Apps (PWAs) created with Visual Builder. To see which apps are blocking upgrade, expand More details.
If you want to proceed with upgrade:
|
Process Automation Prechecks
| Eligibility condition | Typical owner | Blocks upgrade | Tasks to Complete |
|---|---|---|---|
|
Process Automation and Process Action |
Administrator | Yes | 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 choose to ignore those instances and proceed with upgrade. If you choose to do so, all running and completed Process instances will be lost. Select Ignore active instances and proceed with upgrade, and then click Save changes. You will be asked to confirm your choice twice. WARNING: Selecting this option will result in the loss of running (in-progress) and completed process instances. Be careful when selecting this option, especially in a production instance.After selecting this option and re-running the precheck, the Process Automation precheck will show Runtime instances ignored. 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 don't need to perform manual migration if the following is true:
See Migrate Process Applications to a New OCI Process Automation Instance. 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.
|
|
Process Action |
Administrator | Yes | 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. |
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.
- 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.