CICD - Using CSM Rest API's for Sandbox Migration

June 3, 2020 | 4 minute read
Mithun Devkate
Principal Solution Architect
Text Size 100%:

Overview

Oracle SaaS Sandbox migration has some limitations for API functionality. This blog is going to cover the steps to use CICD approach for the Full/CSM and Delta (latest changes) unified Sandbox migration. After following the instructions from this blog user can easily use API's to do unified sandbox migration.

 

Before you begin

There are few pre-requisites before doing sandbox migration from source pod to destination pod.

  • The source and target environments are of the same release, with the same standard and one-off patches applied to both environments.
  • All Page Composer configurations made in sandboxes are complete and published.
  • All configurations and extensions made using the Structure page, the Manage Standard Lookups task, and Security Console, are complete.
  • To move content created using Oracle Business Intelligence Enterprise Edition, set the Business Intelligence in Configuration Set Migration Disabled profile option to No in source and target environments. You can find this profile option in the Manage Administrator Profile Values task in the Setup and Maintenance work area.
  • Contact your security administrator for details.
  • You have the following privileges to access the Migration page:
    • Manage Outgoing Configuration Set
    • Manage Incoming Configuration Set
  • You never make changes in the target or production environment while applying configurations.

 

What is sandbox migration ??

Classic Migration

Here's what you do in a classic migration:

  • You always need to migrate all configurations in the source environment.
  • You have to manually download the configuration set from the source environment, and manually upload it into the target.
  • You can't preview configurations in the target environment before applying them.

Unified Migration

Here's what you can do in a unified migration:

  • You can register the target environment in the source environment.
  • You have the option to migrate only new changes if both environments are synchronized.
  • Your migration set is automatically sent to the target environment for import, if the target is registered and available.
  • Your migration set is imported into a sandbox instance before it's applied to the target environment. You can preview your configurations in this sandbox instance before applying them to the mainline.

 

 

Steps to Achieve unified sandbox migration using API's

Register the Target Environment

  • In your source environment, open the Manage Configuration Set Migration Target Security Policy task in the Setup and Maintenance work area.
  • Enter the URL of your target environment. Use the full URL, including host and protocol information.
  • Enter your user name and password.
  • Click Save and Close.

Verify the Target Environment

  • In the source environment, click Navigator > Configuration > Migration.
  • Click the Environment Info infotile.
  • Verify that the page displays the same URL as the target instance.

 

Rest API's Operations

Note : The content type used in the Rest APIs is application/json.

Things to be performed on Source Pod.

1.Get Delta migration set - only the latest changes will be moved from source to destination pod in this migration.

         

 

2. Get list of optional modules - currently few modules not possible to migrate using CSM API's.

 

3. Get details about migration mode - it can be full/csm or delta

 

4. Create Customization set using Post Action -   For now only the mandatory modules are included and optional modules are excluded in the export. 

  • Mandatory Modules :
  • Application artifacts
  • Analytics
  • Industry solution installations and upgrades to environments that may have been previously modified are for internal use only
  • CRM common components
  • Optional Modules :
  • BI,EMT,ES,ESS,FOD,SOA,SVC

 

5. You can check the status of running job using get status action.

 

Things to be performed on Target Pod.

1. Activates Import job using csSetId, which is result of Export operation from previous step.

 

2. Apply customizations into mainline start and asynchronously publish csm sandbox

 

3. Get Status of job - Provides status of the Import, Apply and Restore operations.

 

4. Similarly you can abort the import activity using abort action and restore it using restore action.

 

Limitations 

Currently API's have some limitations for migrating few modules. As of now these modules can't migrated using rest API's BI,EMT,ES,ESS,FOD,SOA,SVC

 

Conclusion

By using above steps user can easily migrate the sandboxes between two pods. One can automate the migration steps using any programming / scripting language such as Python , Go , Java.

 

Some useful links 

1. Sandbox details and migration methods :-  https://docs.oracle.com/en/cloud/saas/applications-common/19d/oaext/index.html

2. Rest API's documentation :- https://restfulapi.net/

 

 

 

 

 

 

Mithun Devkate

Principal Solution Architect

I am Principal Solution Architect in A-Team SaaS team. We are specialize in OCI SaaS Extension. Mainly focusing on OCI infra , PaaS , SaaS.


Previous Post

Confusion Around the number of IDCS Instances

Mike Muller | 2 min read

Next Post


Semantic/RDF “Properties”?

Michael J. Sullivan | 3 min read