Cloning OIC Classic Gen 1 to OIC Gen 2

Unlike Managed File Transfer Cloud Service (MFTCS) and SOA Cloud Service (SOACS), which are essentially platforms originally designed for on premise operation but now operate in the cloud, Oracle Integration Cloud was designed and built as a Cloud-based platform from the outset. Although the early Generation 1 (Gen1) OIC had more limited functionality and fewer features in the past due to its infancy, being an intrinsically OCI cloud-based platform it does have other certain advantages. As OIC developers will happily note, the speed of cloning artefacts within OIC instances (such as lookups, connections and integrations) has always been an amazingly easy task. We will also find out too that cloning whole OIC instances, for example between Generation 1 and Generation 2 (Gen2) OIC platforms, has been made easy too.

Figure 1 – OIC High Level Migration Steps

As the high level steps in Figure 1 show, the migration of OIC artefacts is remarkably short, and way more manageable and efficient than it is for MFTCS and SOACS.

The basic steps start with running a REST API against the Gen1 OIC instance which creates a zipped ‘Instance Archive’ file, which is stored in the Gen1 Storage Classic bucket on the OCI infrastructure.

Using Postman or cURL, run the ‘/ic/api/common/v1/exportServiceInstanceArchive‘ REST API. The basic syntax, as listed in Oracle documentation, is:

curl -k -v -H "Content-Type: application/json" -X POST -d '
{"storageInfo":{"storageUrl":" https://swiftobjectstorage.us-region-1.oraclecloud.com/v1/
paasdevoic/cloneRepo","storageUser":"myemail@company.com",
"storagePassword":"generated_token"}}' -u GEN1_OIC_admin:password
https://host/ic/api/common/v1/exportServiceInstanceArchive

When the REST call is submitted, you’ll get a JSON payload back, for example….

{
	"jobId": "435277",
	"location": "https://swiftobjectstorage.us-region-1.oraclecloud.com/v1/paasdevoic/cloneRepo",
	"status": "NOT_STARTED"
}

The NOT_STARTED status is good. It means that your API call was good, and the export job is spinning up. You can check the status of the export job by using the ‘jobId’ and another REST API call:

curl -k -v  -X GET -u GEN1_OIC_admin:password https://host/ic/api/common/v1/exportServiceInstanceArchive/435277

When you run the above REST API you will get a response back like this.

jobId	"435277"
jobType	"EXPORT"
archiveName	"Local_Suite_Instance-435277.zip"
includeSecurityArtifacts	true
overallStatus	"COMPLETED"
startTime	"Fri Jan 22 10:14:13 GMT 2021"
endTime	"Fri Jan 22 10:27:52 GMT 2021"
components	
0	
name	"Process"
status	"COMPLETED"
percentage	100
1	
name	"Integration"
status	"COMPLETED"
percentage	100

It will tell you what percentage of the export is completed, up until both Processes (Process Applications) and Integration exports show 100 percent completed.

Yes, this export file will contain BOTH integrations and process application artefacts.

The amount of time is takes to generate the ‘Import Archive’ file will depend on factors such as:

  • how many integration artefacts you have, including certificates, lookups, connections and integrations
  • how many process applications you have, associated forms and underlying artefacts
Figute 2 – Swift Object Storage Configuration in Gen 2

As the Gen2 OIC Import/Export is unable to use a Gen1 Storage Classic bucket as a storage endpoint, if you are moving from a Gen 1 to a Gen 2 OCI platform then your administrator should download the ‘Instance Archive’ file to a local machine, and then upload the file to the Gen2 Swift Object Storage container (bucket). The ‘Import Archive’ file needs to be in a Gen2 Swift Object Storage for upload.

Figure 3 – Instance Archive File Imported to Gen2 Swift Object Storage Container

As a one off task in OIC, the ‘Instance Storage’ credentials will be set to connect the Gen2 Swift Object Storage.

Figure 4 – Gen2 OIC Instance Storage configuration

Once the Instance Storage connection has been configured in the Gen1 OIC instance it can be used to locate and use the ‘Instance Archive’ file.

Figure 5 – Using the Import Screen

The OIC Import tool gives the user a few option regarding the import, ranging from:

  • Import Only
    • Include security artefacts (these are security policies, credentials for connections, certificates and if there are Process Applications the application role memberships)
  • Import, and Activate
  • Import, Activate and Start Schedules

The option of ‘Import Only, including security artefacts’ will be selected the majority of the time. As this is a complete clone of the source environment (including connection URLs, credentials and SFTP target details) you almost certainly will be required to update them following post import. This is both a good, and a bad feature. Good because you can import all your connection strings and at least have something tangible to update. Bad because the import process will try and test every one of your connections as they are imported. Therefore, like doing a normal connection configuration and test in OIC, a failed connection may take a while to timeout. The bottom line is that checking the ‘including security artefacts’ box will mean that the import process can take a few hours to complete if you have lots of connections that you don’t expect to test successfully during the import.

Figure 6 – Running the OIC Import Job

The import job will take some time depending on a few factors which include most significantly if an endpoint exists or not. The Import job creates and tests connection details as it goes. Each failed connection test attempt may take a few minutes to time-out behind the scenes, so this is why an import to a brand new OIC instance may take a while.

Figure 7 – Completed OIC Import Job

You can see that our test import took over 2 hours to finish. Once the import job is completed a log file containing details for the Process Application import, and a JSON file containing details for the Integrations import are available on the Swift Object Storage container.

Figure 8 – Post OIC Import files on the Swift Object Storage

The ‘ErrorLog.json’ file (for the Integration import) will tell the user of any connections or integrations it has skipped as they have already been added, together with information regarding any problems with certificates, WSDLs, credentials and unreachable URLs.

The ‘ErrorLog.json’ file really helps you at it details the majority of the post import tasks you will need to investigate and fix including the updating of the Connection details that have been configured but were not tested successfully during the import process. Once the connection details have been updated and made active, the OIC Integrations can be made active and scheduled too according your business process requirements.

On the whole I’m impressed with this Export/Import process. It obviously only covers ‘design-time’ metadata and doesn’t cover in-flight (runtime) processes, Insight or OIC File Storage setup, but compared to the arduous task needed to ‘clone’ MFT and SOA this is a very welcome change.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s