Skip navigation

Overview

Let us consider that an enterprise is using Oracle Sales Cloud to manage business critical information about its customer accounts and prospects. A Sales Manager has scheduled a visit to a customer and as part of his travel want to visit other nearby customers also.

Oracle Sales Cloud does not have an OOTB capability to locate nearby accounts but this capability can be built in Oracle PaaS as a:

  • Custom Java EE application embedded as a sub-tab into Sales Cloud UI
  • Deployed on Oracle Cloud Services: Java Cloud Service SaaS Extension
  • Enables Sales Representatives to query and locate other nearby accounts


PaaS-SaaS_1.png








 


Figure : Extending Sales Cloud using JCS-SX


Solution Approach

 

When the logged-in user clicks on the embedded sub tab in Sales Cloud, the java application receives the selected account’s context parameters (account id, account latitude, and account longitude) from Oracle Sales Cloud along with a authorization token( JWT, please refer to this blog for more details) in the URL. This short screen cast provides a brief functional and technical overview of this solution.


The java application builds a view criterion and calls Oracle Sales Cloud’s Account Service by passing JWT for authorization. The response would include all accounts (based on logged-in user) that are located within a specific radius of the currently selected account. Please refer to this sample on oracle cloud developer portal for detailed explanation about this extension capability.


The views expressed in this post are my own and do not necessarily reflect the views of Oracle.

Overview

An enterprise is using Oracle Sales Cloud to manage information about its customers and prospects. It has developed a custom web application to be used by its sales representatives to maintain a log of company-branded merchandise given away to customers, as part of standard sales process. The customer information needed to log the merchandise is accessed from Sales Cloud.

 

Using this application a sales representative is able to enter the value of merchandise, issued for a specific customer. During the process of logging merchandise, the sales representative will only be able to see accounts accessible to him/her. This short screen cast provides a brief functional and technical overview of this solution.

 

PaaS-SaaS_2.png

Figure : Secured access to Sales Cloud data

 

Solution Approach

A sales representative tries to log merchandise using the bespoke java application and starts typing an account name, accounts accessible by the logged in user will be suggested to the user. These suggestions are fetched by calling a web service provided by Sales Cloud. The pre-configured security and trust between PaaS (JCS-SX) and SaaS (Sales Cloud) enables bespoke applications to make secured web service calls and access Sales Cloud data without any additional security setup. 


Please refer to this blog for more details on securing web service interactions between Oracle Sales Cloud and JCS-SX. This ensures that the user logged into the bespoke application can only view the accounts accessible to him. Please refer to this sample on oracle cloud developer portal for detailed explanation about this capability.


The views expressed in this post are my own and do not necessarily reflect the views of Oracle.

Overview

An enterprise wants to assign a Credit Health Score to every account/opportunity. This score ranges from 1 to 10 and is calculated based on a complex logic involving data from several internal and external systems. The enterprise has built a bespoke web application developed and maintained by a development team within the enterprise that

  • Exposes the Credit health score calculation logic as a web service and is deployed in JCS-SX
  • Is deployed on Oracle Cloud Services: Java Cloud Service SaaS Extension
  • Is used to calculate the credit health score of every account/opportunity

  This short screen cast provides a brief functional and technical overview of this solution.

PaaS-SaaS_3.png

Figure 3: Integrate SaaS applications with external systems


Solution Approach

 

A sales manager logs into Oracle Sales Cloud to view the details of an account. When the user selects an account, on the default account view page, he finds a new custom field called “Credit Health Score”. The value of this custom field is fetched by invoking the Credit Health Score web service deployed in JCS-SX. Please refer to this sample application on oracle cloud developer portal for more detailed explanation about building this extension.

 

The pre-configured security and trust between PaaS (JCS-SX) and SaaS (Sales Cloud) enables Sales Cloud to make secure web service call to the bespoke application deployed in JCS-SX without any additional security setup. Please refer to this blog for more details on securing web service interactions between Oracle Sales Cloud and JCS-SX.


The views expressed in this post are my own and do not necessarily reflect the views of Oracle.

Overview

 

An enterprise is using Oracle Sales Cloud to manage information about its customers and prospects. The enterprise needs to manage the feedback received from its dealers and has built a custom web application for this purpose. This application has two user roles:

  1. ‘Dealer’ who creates his feedback using the custom web application
  2. ‘Dealer Manager’ who uses Oracle Sales Cloud and wants to check the feedback received from all dealers.

  This short screen cast discusses briefly about the functional and technical overview of this scenario.


PaaS-SaaS_4.png

Figure : Custom web application linking out to Sales Cloud


Solution Approach

 

The custom web application is deployed on JCS-SX and embedded into Sales Cloud as an external link (“Dealer Feedback” menu link) which enables the dealer manager to view and act upon the feedback received from the dealers. This sample on oracle cloud developer portal provides a detailed explanation about this capability.


Though the embedded application is protected on JCS-SX, when the dealer manager accesses the “Dealer Feedback” menu link, he/she does not need to authenticate again. This is because of the pre-established security and trust between JCS-SX and Sales cloud which enables users to single sign on.


The views expressed in this post are my own and do not necessarily reflect the views of Oracle.

Overview

 

An enterprise is using Oracle Sales Cloud to manage information about leads and opportunities. The enterprise has built a custom web application to capture and maintain certain pieces of information pertaining to the sales leads.  Users accessing this application are given limited access to Oracle Sales Cloud for updating lead information and do not have access to other Oracle Sales Cloud system functions. This application is deployed on JCS-SX and links out to Oracle Sales Cloud to work on sales leads.


A brief functional and technical overview of this scenario is discussed in this short screen cast.

 

PaaS-SaaS_5.png

Figure: Custom web application linking out to Sales Cloud

 

Solution Approach

 

A user logs into the custom web application and creates a new lead record and by clicking on a button in the web UI, the user will be taken to Oracle Sales Cloud where he/she can further work with the lead information.  This sample on oracle cloud developer portal provides a detailed explanation on building this extension.


Slimmed-down subsets of Oracle Sales Cloud features are made visible to the logged in user limiting the access to only specific Sales Cloud functions. This is because the user is assigned a custom role in Sales Cloud restricting his access to only leads and opportunity related functions.


The views expressed in this post are my own and do not necessarily reflect the views of Oracle.

Overview


An enterprise is using Oracle Sales Cloud to manage information about leads and opportunities. The sales representatives of an enterprise would want to know if there are any pending / long-standing service requests from customers before meeting them for additional sales opportunities. Additionally, the representatives would also like to be current on the latest news about their accounts such as leadership changes, recent announcements, or anything that may impact their selling ability.

 

The enterprise has built a bespoke web application which is deployed in JCS-SX that lists all open service requests related to a specific customer. This short screen cast discusses briefly about the functional and technical overview of this scenario.

 

PaaS-SaaS_6.png

Figure: Embed extended UI within Sales Cloud UI


Solution Approach

 

When the user selects an account in Sales Cloud UI, in the account widget a new sub-tab linked to the web application which is deployed in JCS-SX is displayed.  Upon clicking this tab, the sales representative will be able to view all the pending/open service requests for the selected customer along with recent changes/announcements relevant to the customer. This sample on oracle cloud developer portal provides a detailed explanation on this solution.


Though the embedded application is protected on JCS-SX, when the sales representative navigates to this sub-tab, he/she does not need to authenticate. This is because security and trust is pre configured enabling users to single sign on to JCS-SX and Sales cloud. Since the sales representative is already signed into Sales Cloud, the embedded page is directly displayed.


The views expressed in this post are my own and do not necessarily reflect the views of Oracle.

Overview

 

An enterprise is using Oracle Sales Cloud to manage information about sales opportunities and revenue estimates. The enterprise has built a custom web application to graphically compare the revenue estimate of a selected opportunity against all other opportunities for that quarter both from an actual dollar amount and a dollar amount adjusted by win probabilities. This application is deployed in JCS-SX and is embedded into Sales Cloud.


A brief functional and technical description of this scenario is presented in this short screen cast.

 

PaaS-SaaS_7.png

Figure : REST web service call to access Sales Cloud data

 

Solution Approach


A sales administrator logs into Oracle Sales Cloud to view the information pertaining to a sales opportunity. When the user selects the opportunity, in the default view, he finds a new sub-tab on the left pane. When clicked on this new sub-tab, the custom web application deployed in JCS-SX is displayed providing an integrated user experience. Upon clicking this tab, a set of two pie charts are displayed comparing the selected opportunity's revenue (both actual and adjusted by win probability) to the quarter's opportunity totals.


The web application deployed in JCS-SX makes a REST web service call to the Sales cloud using super user credentials configured in JCS-SX and retrieve opportunity details. The web application then uses this information to generate the pie charts.


The views expressed in this post are my own and do not necessarily reflect the views of Oracle.

PaaS for SaaS

 

Oracle PaaS enables customers and partners to extend their Oracle SaaS applications and provide custom functionality addressing specific business needs in the following three key areas:

  • Integrating SaaS applications with external systems
  • Analyzing data from SaaS and other systems
  • Extending SaaS applications with custom functionality

 

PaaS-SaaS.png

Figure 1: Unified Cloud Platform to Enrich SaaS

 

In this series of blog posts, let us look at following scenarios where Oracle PaaS (Java Cloud Service-SaaS eXtension in specific) can enable customizing and extending SaaS applications (Sales cloud in specific):

 

  1. Extending Sales Cloud with a bespoke java web application deployed in JCS-SX                                                 (Screen cast)
  2. Securing access to Oracle Sales Cloud data when accessed from bespoke java application                              (Screen cast)
  3. Integrating SaaS applications with external systems                                                                                                  (Screen cast)
  4. SSO based authentication to JCS - SaaS Extension Application                                                                                (Screen cast) 
  5. Custom web application linking out to Sales Cloud                                                                                                    (Screen cast)
  6. Build UI extensions to Sales Cloud using JCS-SX                                                                                                          (Screen cast)
  7. Accessing Sales Cloud data using REST web services                                                                                                  (Screen cast)

 

The views expressed in this post are my own and do not necessarily reflect the views of Oracle.

In this post, we’ll look at why Connector APIs are required in spite of having the option to implement external service integration using Custom APIs directly. In the process, we’ll discover some useful features of Oracle Mobile Cloud Service

 

 

Custom & Connector APIs

 

In addition to the core Platform APIs, Oracle Mobile Cloud Service provides Custom APIs. At a high level, using Custom APIs is a two-step process

 

  • Declarative interface design: defining the service contract
  • Concrete implementation: server side business logic to satisfy the interfaces

 

Custom API implementations can be built using using Node.js. It makes it possible to implement almost any server side business logic, including integration with heterogeneous external services.

 

Oracle MCS also supports Connector APIs. Here are some of its important characteristics

 

  • They provide a layer of abstraction when it comes to integrating with heterogeneous systems and platforms on the cloud as well as on-premises
  • Form a bridge between the Custom API and the target system
  • Cannot be accessed by mobile clients directly i.e. they Connector API endpoints are designed to be invoked by Custom APIs only

 

 

custom-and-conn-apis.PNG

                                        Custom & Connector APIs: the big picture

 

 

Let’s look at some of the most compelling features of Oracle MCS Connector APIs

 

Ease of Security configuration

 

Imagine you have a REST web service which can be accessed by providing service account credentials using HTTP Basic (over SSL of course). Here are some of things which you would have to think about if you plan on integrating with this REST service directly using the Custom API

 

  • Come up with a secured way of storing & managing the service account security credentials
  • Revamp your implementation if the security requirements of the target service changes (e.g. from HTTP Basic to OAuth)
  • Dive into an enhancement development cycle when you are required to integrate with multiple services, each having different security constraints

 

Thanks to the Connector API, you can bank on the following capabilities

 

Support for heterogeneous security policies

 

Different flavors of the Connector API support different policies. These are quite extensive in nature and are best referred from the official product documentation for the latest information in terms of the precise security policy applicable for your use case

 

Declarative & flexible security configuration

 

Oracle MCS allows UI based security configuration for external services which you want to integrate with. You can do so by visiting the ‘Security’ navigation link in the Connector API wizard page. Here is a pointer from the official documentation

 

selecting-security-policy.PNG

 

                                Enforcing HTTP Basic over SSL policy for a REST Connector

 

Secure & centralized management of credentials/certificates

 

Credentials for the external service can be configured in a secure manner, using a simple storage mechanism based on a unique identifier (referred to as the csf-key). You can choose to create a new CSF key or select an existing one. Behind the scenes, this leverages the Credential Store Framework in OPSS

 

csf-key.PNG

 

                                             Creating a new CSF key to store credentials

 

You can referthis section from the product documentation for more details on how to work with CSF Keys and Certificates

 

Logging & diagnostics

 

Oracle MCS provides rich logging capabilities by default – both for Custom as well as Connector APIs. There is no extra ‘logging’ code which you would to write (although you are free to add application specific logs within Custom API implementations). Listed below are examples of the few of the which come bundled with Connector APIs

 

Troubleshooting Connector API issues

 

This can prove invaluable when things do not work as expected e.g. the below screenshot depicts a scenario where the invocation failed due to an issue in the Connector API integration layer

 

log-1.PNG

 

                                        Troubleshooting a Connector API issue

 

 

Follow this link to the product documentation to get started. Please note that one can also debug Custom APIs in a similar fashion. Oracle MCS provides the stack traces of your custom Node.js code in case of exceptional scenarios.

 

Request tracking

 

Each request to a Mobile Backend in Oracle MCS is assigned a unique identifier which is ‘attached’ to all the components involved in the request e.g. you can track the entire flow, starting with the API call from your mobile app to a custom API associated with a Mobile Backend, all the way to Connector API and the end target system

 

log-2.PNG

 

                                   Inbound call to the Custom API (in Mobile Backend)

 

 

log-3.PNG

 

                                        Call from the Custom API to the Connector API

 

 

log-4.PNG

 

                                   Outbound call from the Connector API to the external system

 

 

 

For more on logging and diagnostic features, refer the Oracle Mobile Cloud Service documentation

 

 

Ease of testing

 

Typically, there are several components involved in the process of creating a full-fledged mobile-ready API using Oracle MCS. In such a scenario, it’s very important for these components to be testable in isolation. The Connector API provides you the capability to test it out before wiring it to the Custom API

 

For example, let’s look at a REST Connector API

 

test-1.PNG

                                             Configuring a REST Connector API

 

 

test-2.PNG

 

                                                                 Testing a HTTP GET request

 

 

test-3.PNG

 

                                                                                               Complete URL for the remote REST endpoint

 

 

test-4.PNG

 

                                                                                                              Endpoint invocation result

 

 

For detailed insight on testing your REST Connector API, please visit this link from the official documentation

 

 

Beauty of SOAP connector APIs

 

There are a couple of interesting options available exclusively while working with the SOAP Connector APIs

 

SOAP to REST for free

 

Here is the basic premise of SOAP Connector APIs

 

  • Oracle MCS consumes a SOAP WSDL (provided by the user)
  • WSDL port operations are auto-magically converted to REST endpoints (for the Custom APIs to invoke)

 

 

soap-1.PNG

 

                                                       WSDL port operations

 

soap-2.PNG

 

                                                  SOAP operation to REST endpoint

 

 

 

Note: You’re free to use custom names for the default endpoint name which MCS auto-generates, as well as the default operation names in the WSDL

 

Bi-directional transformations between XML & JSON

 

MCS takes care of the following

 

  • Transformation of inbound calls (from mobile apps to custom API to SOAP Connector, all the way to SOAP target) from JSON to XML
  • Conversion of  XML response (outbound calls) from SOAP target to JSON (for consumption by the Custom API and followed by  the mobile app)

 

You can also continue to use XML as your payload format by tweaking some of the request parameters For further details, refer the official product documentation

 

Declarative enforcement of other policies

HTTP Rules

 

These are specific to REST Connector APIs and are nothing but one or more HTTP parameters (Header or Query) provided at design time (static configuration) e.g. this is perfect for storing API keys which will be automatically added to your HTTP request. You can choose to apply them at a Resource or HTTP method level

 

rules.PNG

 

                                                                Configuring Rules

 

 

Timeouts

 

This facility is common to REST and SOAP Connector APIs and is used for static configuration of connectivity SLA. Think about a scenario where the external service is unavailable. You definitely do not want your connection request to hang or stall indefinitely since it can hamper the performance of your mobile app and create bottlenecks.

 

timeouts.PNG

 

                                                       Configuring connectivity SLAs

 

 

Conclusion

 

I hope this gives you a starting point to explore Connector APIs further. As always, the choice can often depend on your specific use case, but more often than not, you stand to gain a lot by leveraging the Oracle Mobile Cloud Service Connector APIs.

 

 

The views expressed in this post are my own and do not necessarily reflect the views of Oracle.

 

Overview

 

REST services are everywhere, and almost every button click is a GET or a POST somewhere. It is not a new feature that the Oracle Database can consume REST services in PL/SQL and you could find this on many blogs.

 

Also not new is the fact that you could access the Oracle Public Cloud using REST services. There is a very good documentation on this here:

https://docs.oracle.com/cloud/latest/

And here comes the question, if you could manage the cloud from within the cloud using REST services. So let’s put the two on two together and create an Oracle Cloud Inception.

Just like following a recipe, the prerequisites would be:

· Oracle Public Cloud credentials:

o identity domain

o username

o password

· Oracle Database Cloud Service activated

https://blogs.oracle.com/OracleCloud4Developers/resource/Cloud_Json/pic_1.jpg

 

 

· SSh connection and tunnel to the cloud instance.

· Sql Developer connection to the pluggable database.

 

 

The plan for this exercise is:

 

1. Get the Certificate chain that authorizes https://dbcs.emea.oraclecloud.com/

2. Create a wallet to import the certificates.

3. Create a PL/SQL procedure to call Rest services

4. Let the fun begin

 

 

Get the Certificate chain

 

 

On the first part, open Firefox and go to https://dbcs.emea.oraclecloud.com/

Click on the small little lock at the beginning of the URL:

https://blogs.oracle.com/OracleCloud4Developers/resource/Cloud_Json/pic_3.jpg

 

 

This should show information about the site and about the authority that certificates it. Click on More Information button:

https://blogs.oracle.com/OracleCloud4Developers/resource/Cloud_Json/pic_4.jpg

 

 

This opens the Security page on the Firefox Options. Click on View Certificate:

https://blogs.oracle.com/OracleCloud4Developers/resource/Cloud_Json/pic_5.jpg

 

 

You can see the public key of the dbcs.emea.oraclecloud.com. Click on Details tab to see the certificate chain:

https://blogs.oracle.com/OracleCloud4Developers/resource/Cloud_Json/pic_6.jpg

 

 

Observe that VeriSign is the root certificate authority that authorizes Symantec and this on forward authorizes emea.oraclecloud.com.

https://blogs.oracle.com/OracleCloud4Developers/resource/Cloud_Json/pic_7.jpg

Export the Symantec certificate chain and chose Save as type: X.509 Certificate with chain (PEM)(*.crt,*.pem). Also chose a location and a file name suitable for you.

 

 

 

Create a wallet and import the certificate

 

 

To import the above certificate connect to the Database Cloud Instance using a ssh client like putty.

 

First, create a wallet directory.

 

[oracle@Db12c ~]$ mkdir wallet

 

 

Create a wallet using the orapki tool:

[oracle@Db12c ~]$ orapki wallet create -wallet /home/oracle/wallet -pwd Welcome#1
Oracle PKI Tool : Version 12.1.0.2
Copyright (c) 2004, 2014, Oracle and/or its affiliates. All rights reserved.

[oracle@Db12c ~]$


 

Copy the SymantecClass3SecureServerCA-G4.crt file saved earlier in the wallet location: /home/oracle/wallet.

 

After that you should add the certificates using the same orapki tool. Issue the following:

 

 

orapki wallet add -wallet /home/oracle/wallet -trusted_cert -cert SymantecClass3SecureServerCA-G4.crt -pwd Welcome#1

 

 

Now you have the wallet location: /home/oracle/wallet to use in a pl/sql procedure.

 

Create a PL/SQL procedure to call Rest services.

 

Open the Sql Developer and connect to a pluggable database from the Oracle Database Cloud Service. To verify the network Access Control List (ACL) for the current user, which in our case is SYS run the following query.

 

SELECT * FROM dba_network_acls;

 

 

You can see that SYS is the ACL_OWNER for the NETWORK_ACL so you could use SYS as the procedure owner.

In case you want to use another user you should give him privileges to the above ACL or create a new ACL. To give a user privileges on the network ACL run the following:

 

BEGIN
DBMS_NETWORK_ACL_ADMIN.add_privilege (
acl => 'NETWORK_ACL_FD9ACFECC55448A9E043B6A9E80AFB6F', --the ACL name
principal => 'CLOUD_ADMIN', --The database user name
is_grant => true,
privilege => 'resolve',
position => NULL,
start_date => NULL,
end_date => NULL);

COMMIT;
END;

BEGIN
DBMS_NETWORK_ACL_ADMIN.add_privilege (
acl => 'NETWORK_ACL_FD9ACFECC55448A9E043B6A9E80AFB6F', --the ACL name
principal => 'CLOUD_ADMIN', --The database user name
is_grant => true,
privilege => 'connect',
position => NULL,
start_date => NULL,
end_date => NULL);

COMMIT;
END;


 

The procedure below calls the REST endpoint with GET, POST and PUT methods and displays the results. The procedure takes the following parameters:

· p_identitydomain – The identity domain

· p_instancename -- The cloud instance name

· p_method default 'GET' --The method called, by default is GET

· p_content – The content for a POST or PUT method

· p_user –The username for Oracle Public Cloud connection

· p_pass –The password for Oracle Public Cloud connection

 

The end point URL used is:https://dbcs.emea.oraclecloud.com/paas/service/dbcs/api/v1.1/instances/'||p_identitydomain||'/'||p_instancename; It has the Identity Domain and Instance Name concatenated at the end.

 

create or replace procedure database_service_call
( p_identitydomain in varchar2,
p_instancename in varchar2,
p_method in varchar2 default 'GET',
p_content in varchar2 default null,
p_user in varchar2,
p_pass in varchar2,
) is
req utl_http.req;
res utl_http.resp;
v_url varchar2(4000) := 'https://dbcs.emea.oraclecloud.com/paas/service/dbcs/api/v1.1/instances/'||p_identitydomain||'/'||p_instancename;
v_buffer varchar2(4000);


begin

--Setting the wallet that we created earlier
UTL_HTTP.set_wallet('file:/home/oracle/wallet', 'Welcome#1');

--Sending the request
req := utl_http.begin_request(v_url, p_method);
UTL_HTTP.set_authentication(req, p_user, p_pass);
utl_http.set_header(req, 'content-type', 'application/json');
utl_http.set_header(req, 'Content-Length', length(p_content));
utl_http.set_header(req, 'X-ID-TENANT-NAME', p_identitydomain);


utl_http.write_text(req, p_content);
res := utl_http.get_response(req);

DBMS_OUTPUT.PUT_LINE('HTTP response status code: ' || res.status_code);

--Display the response
begin
loop
utl_http.read_line(res, v_buffer);
dbms_output.put_line(v_buffer);
end loop;
utl_http.end_response(res);
exception
when utl_http.end_of_body
then
utl_http.end_response(res);
end;
end database_service_call;
--The list of endpoints and methods could be found here:
http://docs.oracle.com/cloud/latest/dbcs_dbaas/CSDBR/toc.htm
--To call it run the following pl/sql block:

SET serveroutput on

begin
database_service_call(p_identitydomain=> 'myIdentityDomain',
p_instancename=> 'Db12c' ,
p_method =>'GET',
p_content => null,
p_user =>'cloud.admin',
p_pass => 'My_pass#1'
);
end;


 

 

The first output is that the procedure ran successfully. Then the second line gives us the 200 code which is 200 OK which means that the request was successfully completed. A 200 status is returned for a successful GET or POST method.

 

The entire response printed is a JSON like this:

{
"service_name": "Db12c",
"version": "12.1.0.2",
"status": "Running",
"description": "Test Db12c",
"identity_domain": "myIdentityDomain",
"creation_time": "Tue May 17 8:46:9 UTC 2016",
"last_modified_time": "Tue May 17 8:46:9 UTC 2016",
"service_uri": "https:\/\/dbcs.emea.oraclecloud.com:443\/paas\/service\/dbcs\/api\/v1.1\/instances\/myIdentityDomain\/Db12c",
"num_nodes": 1,
"level": "PAAS",
"edition": "EE",
"shape": "oc4",
"failover_database": false,
"rac_database": false,
"sid": "ORCL",
"pdbName": "PDB1",
"listenerPort": 1521,
"em_url": "https:\/\/140.86.2.XXX:5500\/em",
"connect_descriptor": "Db12c:1521\/PDB1.myIdentityDomain.oraclecloud.internal",
"connect_descriptor_with_public_ip": "140.86.2.XXX:1521\/PDB1.myIdentityDomain.oraclecloud.internal",
"apex_url": "https:\/\/140.86.2.XXX\/apex\/pdb1\/",
"dbaasmonitor_url": "https:\/\/140.86.2.XXX\/dbaas_monitor",
"charset": "AL32UTF8",
"ncharset": "AL16UTF16",
"compute_site_name": "EM002_Z12",
}


 

Let the fun begin

 

One of the features of the Oracle Database is that it can store a JSON object in a single column and has the ability to parse it and to show the results in a query. So let’s think how these two could be used and create a report with the status of the instance in time.

The fun part is that you can control the Oracle Database Cloud Service instance from within the instance. In other words you could give more RAM and CPU to the instance from within the instance.

You could try this procedure call:

 

SET serveroutput on

begin
database_service_call(p_identitydomain=> 'myIdentityDomain',
p_instancename=> 'Db12c' ,
p_method =>'PUT',
p_content => '{ "shape" : "oc5" }',
p_user =>'cloud.admin',
p_pass => 'My_pass#1'
);
End;


 

The views expressed in this post are my own and do not necessarily reflect the views of Oracle.