Startseite 5 Techblog 5 (Fully) Automating Cloning with E-Business Suite Cloud Manager REST API

(Fully) Automating Cloning with E-Business Suite Cloud Manager REST API

16. Januar 2024

Johannes Michler PROMATIS Horus Oracle


Executive Vice President – Head of Platforms & Development

As you're probably aware, Oracle E-Business Suite Cloud Manager is a great tool to automate the operation of Oracle E-Business Suite.

Cloning requirements

This is especially true for cloning, e.g. creating Production-to-Test (P2T) copies. In the old days, for some of my customers it was a multi-week project to create such a P2T copy. Or alternatively, it resulted in a 50 days+ project to fully automate this with traditional infrastructure.

With Cloud Manager, this procedure got a lot better: With some post-cloning scripts, the process can be easily brought down to 10-15 minutes of "clicking through a wizard". However, in some situations even this is too much work, if you e.g. think of a nightly clone that you would like to have. This would mean that every day you must:

  1. Delete the old nightly instance through cloud manager; eventually even wait for the deleting to complete,
  2. start a P2T clone by going through the (lengthy) wizard.

Back in June 2023 I discussed this with the E-Business Suite Cloud manager Product Management team and they told me, that "under the covers", Cloud manager is "just" doing HTTP REST calls. So, I brought up the development console of my browser and recorded the network traffic during creating/cloning and deleting of environments. And indeed, the HTTP requests are rather simple.

API Calls

For cloning it is:

curl 'https://ebsoci.intern.dns/ebs/environment/clone' \
-H 'Authorization: Bearer XXXX' \
-H 'Content-Type: application/json' \
--data-raw 'SOME_JSON'

For deleting, it is even simpler:

curl 'https://ebsoci.intern.dns/ebs/environment/UPG231297/computeds' \
-X 'DELETE' \
-H 'Authorization: Bearer XXXX'

The above requests have two important variables.

First of all, you need to authenticate yourself in order to send requests to Cloud Manager. The quick'n'dirty way to achieve this is by copying the "Bearer token" from your browser. That has a limited lifetime though (8 hours in my tests), and is thus primarily an option if you want to e.g. create multiple clones at once or don't want to enter all the details over and over again. I'll cover how you can use OAuth2 calls to get a token in another blog post.

Secondly, for cloning, you need to provide the details of the new instance. For me, this SOME_JSON looks as follows:

{
"extensibleTasks": {
"inputs": [
{
"parameters": [
{
"name": "cpudb",
"value": "2"
},
{
"name": "memdb",
"value": "64"
}
],
"taskId": "cpid-001-000-000.tpid00000027"
}
],
"templateId": 20019
},
"source": {
"credentials": {
"environment": {
"appsPassword": "MORE_FANCY",
"tdeWalletPassword": "",
"weblogicPassword": "FANCY"
}
},
"environment": {
"name": "PROD122"
}
},
"target": {
"credentials": {
"environment": {
"appsPassword": "TOP_SECRET",
"databaseAdminPassword": "FAncY-20_24",
"ebsSystemPassword": "secret1234",
"weblogicPassword": "Welcome2Secret"
},
"ssh": {
"appTier": [
],
"dbTier": [
]
}
},
"environment": {
"appTier": {
"middlewareLicenseType": "BYOL",
"startServices": "no",
"storage": {
"fileSystem": {
"mountParams": "rw,bg,hard,timeo=600,nfsvers=3",
"mountTargetId": "ocid1.mounttarget.oc1.eu_frankfurt_1.xxxx"
}
},
"zones": [
{
"fileSystemType": "sfs",
"name": "InternalZone01",
"nodes": [
{
"logicalHostName": "prodebsapp01",
"shape": {
"memoryInGBs": 32,
"name": "VM.Standard.E4.Flex",
"ocpus": 2
}
}
],
"type": "Internal",
"webEntry": {
"domain": "intern.dns",
"host": "upgebsapp",
"port": 4443,
"protocol": "https",
"type": "UserLoadBalancer"
}
},
{
"fileSystemType": "sfs",
"name": "InternalZone02",
"nodes": [
{
"logicalHostName": "prodebsapp02",
"shape": {
"memoryInGBs": 16,
"name": "VM.Standard.E4.Flex",
"ocpus": 1
}
}
],
"type": "Internal",
"webEntry": {
"domain": "portal.customer.de",
"host": "upg",
"port": 443,
"protocol": "https",
"type": "UserLoadBalancer"
}
}
]
},
"dbTier": {
"compute": {
"name": "CDBUPG",
"pdbName": "UPG",
"shape": {
"memoryInGBs": 256,
"name": "VM.Standard.E4.Flex",
"ocpus": 4
}
},
"dbService": {
"database": {
"name": "",
"pdbName": ""
},
"vmDbSystem": {
"licensingType": ""
}
}
},
"name": "UPG231294",
"networkProfile": "OCI_AD1",
"tags": {
"defined": [
{
"key": "",
"namespace": "",
"value": ""
}
],
"freeForm": [
{
"key": "",
"value": ""
}
]
}
}
}
}

I suggest starting by doing the clone manually once, which will give you above JSON. Then adjust the JSON and fill it with variables as appropriate. Especially you'll probably want to modify the "name" during each clone.

Summary

As you can see, the actual call to trigger a clone or also the termination of an environment is rather simple. I've recently used that a lot when I worked on my clone scripts (see other blog post on passwords). In that process, I had to create ~10 clones, and doing so with a simple REST call saved me a lot of work.

The "real use-cases" obviously need to have a permanent way for authentication. I'll cover how IDCS Web Services for OAuth2 can be used for that in a later blog post.

Just a final word: Be aware, if you pass the wrong environment to the DELETE request there will be no "double asking". And you, for sure, don't want to terminate your production environment.