Teaching How to Provision an Oracle SOA Cloud Service Environment Using REST APIs

We just covered in previous blogs how to provision environments with components such as: Database Cloud Service, Java Cloud Service, SOA Cloud Service (SOA, OSB, SOA & OSB, API Manager), etc. via the various Cloud Services Console web pages.

In this section I am going to demonstrate how to provision the same type of environments, this time a SOA CS environment with SOA and OSB, but this time using REST APIs. REST APIs are very well documented for the vast portfolio of Oracle Cloud Services. For more information refer to http://docs.oracle.com/cloud

Notice that being able to script, version and test the creation of environments via REST APIs, can facilitate the life cycle of not only software, but also environments, which is a crucial aspect in devops.

For more information specifically about the provisioning of SOA CS environment via a REST API, refer to: https://docs.oracle.com/cloud/latest/soacs_gs/SCSAP/op-instances-%7BidentityId%7D-post.html

What you need to know:

• The Provisioning of SOA CS environment is via a POST on /api/v1.1/instances/{identityId} – Where identityId is the name of the identity domain where you are willing to provision your environment.
• The REST API will be accompanied with a JSON payload, which will be referenced from within the API at the moment of invoking the API.
• Using CURL, this is the structure of the REST API to create a SOA instance:

  curl -i -X POST -u [OPC_USERNAME]:[OPC_PASSWORD] -d @config.json -H “Content-Type:application/vnd.com.oracle.oracloud.provisioning.Service+json” -H “X-ID-TENANT-NAME:[IDENTITY_DOMAIN]” https://%5BREGION_PREFIX%5D.oraclecloud.com/paas/service/soa/api/v1.1/instances/%5BIDENTITY_DOMAIN%5D

  Where

  [OPC_USERNAME] = Your OPC account username

  [OPC_PASSWORD] = Your OPC account password

  [IDENTITY_DOMAIN] = Your OPC identity domain where you want to provision the SOA environment.

  [REGION_PREFIX] = jaas for United States region, jcs.emea for EMEA region.

  This is the ending result (update the fields in blue
  accordingly):

• Notice that there is a mention for a “config.json” file. This is the Payload that you need to invoke as part of the REST API call payload which configures the environment depending on your needs. Make sure to modify the values depending on your needs.

Things that you need to be aware from this JSON file:

• Make sure it is located on the same directory from which you are running the curl command. Otherwise modify the path in the curl command.
• If you don’t specify the VMPublicKey for the OTD, by default it will take the same one as for the WebLogic cluster.
• I used a soaosb topology, but if you can create just SOA, OSB or API Manager. These are the available options:
  • osb – Just OSB
  • soa – Just SOA
  • soaosb – SOA and OSB working together
  • apim – API Manager
  • mft – MFT
  • soab2b – SOA and B2B

  Refer to the SOA CS API documentation for more information.

• There are more parameters available to tune things further at the WebLogic level. Refer to the JCS API reference here.
• When running the curl command. If you get an error, you can add a –v
  flag to make it verbose.

• Validate that you get a successful “202 Accepted” response

  

• Now go to the SOA CS Console and validate that the SOA Environment is being provisioned.

Load Balancer Console

Behind the scenes, by default, any JCS or SOACS environment will be a WebLogic cluster, even if there is only one node, in which case it is optional to use a Load Balancer (OTD). However at the moment the cluster contains multiple nodes, automatically the option to use Load Balancer will become mandatory.

At the moment of provisioning a multi-node environment via the web console, only the load balancer “policy” and load balancer “compute shape” can be configured. However at the REST API level the following configurations are available for a Load Balancer:

• Admin User Name – If not specified it defaults to the WebLogic Server admin username
• Admin Password – If not specified it defaults to the WebLogic Server admin password
• Listener Ports Enabled – If not specified it defaults to true
• Listener Port – If not specified it defaults to 8080
• Listener Type – If not specified it defaults to http
• Load Balancing Policy
  
  • Least Connection count
  • Least Response time
  • Round Robin
• Secured Listener Port – If not specified it defaults to 8081
• Admin Port – If not specified it defaults to 8989
• Compute shape
  
  • oc3: 1 OCPU, 7.5 GB memory
  • oc4: 2 OCPUs, 15 GB memory
  • oc5: 4 OCPUs, 30 GB memory
  • oc6: 8 OCPUs, 15 GB memory
• VM Public Key – If not specified it defaults to the one used for WebLogic Managed Servers

Notice that fields are added regularly. In order to see the full and up-to-date list, refer to the JCS/SOACS REST API documentation.

At the moment of provisioning any JCS/SOACS environment with a Load Balancer, Oracle Cloud Compute will fully configure all the network rules required to allow the Load Balancer to be publically available on the “listener port” indicated during provisioning (8080 by default), as well as all the network rules required to allow access to the Load Balancer to all the Managed Servers in the WebLogic Cluster, so that it can starting balancing the load.

After some time it will be fully provisioned and ready to go. Pretty easy, huh?

Author: Carlos Rodriguez Iturria

I am extremely passionate about people, technology and the most effective ways to connect the two by sharing my knowledge and experience. Working collaboratively with customers and partners inspires and excites me, especially when the outcome is noticeable valuable to a business and results in true innovation. I enjoy learning and teaching, as I recognise that this is a critical aspect of remaining at the forefront of technology in the modern era. Over the past 10+ years, I have developed and defined solutions that are reliable, secure and scalable, working closely with a diverse range of stakeholders. I enjoy leading engagements and am very active in the technical communities – both internal and external. I have stood out as a noticeable mentor running technology events across major cities in Australia and New Zealand, including various technology areas such as, Enterprise Integrations, API Management, Cloud Integration, IaaS and PaaS adoption, DevOps, Continuous Integration, Continuous Automation among others. In recent years, I have shaped my role and directed my capabilities towards educating and architecting benefits for customers using Oracle and AWS Cloud technologies. I get especially excited when I am able to position both as a way to exceed my customers’ expectations. I hold a bachelor degree in Computer Science and certifications in Oracle and AWS Solutions Architecture. View all posts by Carlos Rodriguez Iturria