Before migrating your existing Oracle Integration Cloud Service and Oracle Process Cloud Service instances to Oracle Integration on Oracle Cloud Infrastructure, consider the scope and constraints of this migration path. Once migration is complete, Oracle continues to manage your instances.
Integrations Migration Scope
You export Oracle Integration Cloud Service design-time metadata into an archive file to then import into Oracle Integration on Oracle Cloud Infrastructure. The archive file consists of the following design-time metadata.
Integrations, connections, lookups, agent groups, and so on. Note that:
Integrations, connections, or objects in any state (in-progress, activated, and so on) are exported.
All resources such as lookups and connections that are not currently referenced by integrations are exported.
User-defined credentials. Note the following details:
Credentials are exported into
oracle.wsm.securitymaps are imported.
User-defined certificates (not the seeded certificates). Only user-uploaded trusted certificates (whose alias begins with
icsuser_||_) from the following keystores are exported:
All security policies. Existing policies are not overwritten.
Connection passwords stored in the CSF store.
Settings such as database settings, notification settings, and so on.
Recommendations engine details and API Platform connection details.
Note:The Oracle Integration Cloud Service REST APIs are supported in Oracle Integration.
Integrations Migration Restrictions
Understand the following restrictions when migrating Oracle Integration Cloud Service to Oracle Integration on Oracle Cloud Infrastructure.
What is Not Migrated
- Logging settings that you configured in Oracle Integration Cloud Service are not migrated. Reset previously configured logging settings by selecting Settings > Logging on the Oracle Integration Home page. See Configure Settings for Error Logs of Administering Oracle Integration.
- Instance runtime data such as monitoring, tracking, and error details is not migrated.
- Custom adapters and their integrations are not migrated. File a service request to have your custom adapters and their integrations included in Oracle Integration.
- The user interface for space management settings in Oracle Integration is divided into three tabs (Database Space, Nightly Purge, and Auto Purge), whereas there is only a single page for database settings in Oracle Integration Cloud Service. Because of these differences, a best effort is made to migrate database settings. Verify your database settings after migration completes to ensure that they are correct for your environment.
Feature Differences Between Oracle Integration Cloud Service and Oracle Integration on Oracle Cloud Infrastructure
- The Oracle Integration Cloud Service execution agent is not supported.
- You can continue using the Oracle Integration Cloud
Service APIs. However, if you need to use the newer capabilities of the advanced APIs, you must move to the new URLs provided with Oracle Integration. The Oracle Integration Cloud
Service REST APIs relative path is
/icsapis/v2/resource. The Oracle Integration REST APIs relative path is
- All inbound endpoints for Oracle Integration integrations are hosted on SSL servers that can accept requests coming from clients supporting transport layer security (TLS) 1.2. This is true regardless of whether they are SOAP- or REST-enabled and regardless of the adapter used as the trigger connection. Oracle Integration Cloud Service endpoints supported TLS 1.1 and TLS 1.2 for trigger and invoke connections. If you were using TLS 1.1 for trigger connections with Oracle Integration Cloud Service, note that Oracle Integration does not support this version due to security issues. You must configure your client to use TLS 1.2 when invoking Oracle Integration services.
- The Oracle Integration Cloud Service agent installation is not migrated because it is installed on an on-premises host. You must install the newer, lightweight Oracle Integration version of the connectivity agent on your on-premises host.
- If a parent integration calls a child integration, the child integration must be manually activated. This is because the child must be activated after the parent.
- Data of the same name is overwritten. For example, if an integration of the same name and version exists in Oracle Integration, it is overwritten by the integration of the same name and version imported from Oracle Integration Cloud Service.
- After importing a scheduled integration (scheduled is started) from Oracle Integration Cloud Service into Oracle Integration, the integration is imported and the schedule is started automatically. You must manually stop the schedule in Oracle Integration Cloud Service.
- If you modify the default value of the recovery job in Oracle Integration Cloud Service, the migration to Oracle Integration resets the value to the default value.
- Only one export at a time can be started. Subsequent export requests are rejected if one is currently running.
- If an integration uses the on-premises connectivity agent, those integrations have to be manually activated after registering the agents manually.
Processes Migration Scope
Use the Process Import tool to import Oracle Process Cloud Service design-time metadata into Oracle Integration on Oracle Cloud Infrastructure. You can import the following design-time metadata.
Processes Migration Restrictions
Understand the following restrictions when migrating Oracle Process Cloud Service to Oracle Integration on Oracle Cloud Infrastructure.
Forms: Oracle Integration supports web forms only. When you migrate a process application with a basic form, the basic form is imported as a web form. But, the complete transformation from basic to web form occurs when you open the imported form for the first time. The new web form contains business objects, presentations, and layouts identical to the original form. In addition, the migrated form retains its links to human tasks and data associations. However, certain features of basic forms aren't supported or supported differently in web forms. Here's the complete list of limitations of migrating to web forms:
- Rules: Rules defined for controls in basic forms aren't retained upon migration to web forms. You'll need to redefine rules using web form events.
- Image Control: Unlike basic forms, web forms don't support direct image linking. Therefore, an image in a basic form is converted to its Base64 equivalent upon migration.
- Message Control: Different types of messages in basic forms, such as Warning, Info, and so on, are all converted to a single type upon migration. Additionally, rich text content is converted to plain text.
- HTML Text: Inline HTML links in any control's text or label within a basic form are converted to plain links upon migration to web form.
- Checklist Control: The output of a checklist control migrated from a basic form will be a plain string with comma-separated values.
- Section Control: Styling applied to a section control's label or border isn't retained upon migration from basic form to web form. In addition, the layout of sections may slightly vary after migration as web forms don't support horizontal alignment of controls within sections.
- Control Labels: In basic forms, there's a provision to hide control labels, which isn't supported in web forms. Therefore, all hidden labels are shown upon migration.
- Table and Repeatable Section Controls: Generally, table or repeatable section controls contain a certain number of rows by default in the basic form. Upon migration, these rows aren't retained; instead, the User can Add/Remove Rows check box is selected in the migrated web form.
Decisions: Oracle Integration supports decision models (DMN) only. It is recommended that before migrating process applications containing Oracle Business Rules, you recreate rules as decision models. Oracle Business Rules present in imported applications are retained as read only rules in Oracle Integration. The read-only business rules will still function. You can delete them, but you cannot edit them.
Integrations: Guidelines differ depending on the integration type:
- Integrations created using REST and SOAP connectors in Processes continue to work after migration. You can edit them in the Processes component. However, it is a best practice to recreate them in the Integrations feature whenever possible to centralize integrations in Oracle Integration.
- Integrations created in Oracle Integration Cloud Service and called in Processes must be exported from Oracle Integration Cloud Service and imported into Oracle Integration. Process applications that call Oracle Integration Cloud Service integrations cannot be activated.
Users and roles: Oracle Integration uses Oracle Identity Cloud Service (IDCS) for identity management. You must move users and roles from Oracle Process Cloud Service to Oracle Integration.
You can migrate users and role memberships for Oracle Cloud services from traditional cloud accounts to cloud accounts with Oracle Identity Cloud Service. See Migrate from Traditional Cloud Accounts to Cloud Accounts with Identity Cloud Service in Administering Oracle Identity Cloud Service.
- Application user role (swimlane) mapping: Process role mappings are not migrated. You must remap Process user roles (swim lanes) for all process applications after activation. Note that users must be configured in IDCS before administrators can map swimlane roles for them in process applications.
Running Instances: Running instances cannot be moved between environments.
- Running (in flight) process instances and tasks are not migrated to Oracle Cloud Infrastructure.
- Completed process instances and tasks are not migrated to Oracle Cloud Infrastructure.
After importing process applications into Oracle Integration, you must activate them and create new running instances.