Best Practices from Oracle Development's A‑Team

Techniques used to build PaaS4SaaS Mashup using Oracle Application Builder Cloud Service

Angelo Santagata


This blog has been deprecated due to the release of Visual Bullder Cloud Service



Oracle ABCS is Oracles new citizen developer service allowing citizen developers the ability to quickly build applications for the web/mobile web. A common request from SaaS customers is the desire to have both standalone and embeded custom screens for their SaaS solutions. These obviously need to be feature rich, sexy UIs and above all built quickly. Before ABCS was announced, the best answer for this was for the business user to get a developer to build the application using a web framework, e.g. Oracles Java based ADF Framework or, HTML5 frameworks like Oracle Jet or Angular. For complex applications this would be appropriate but for simple applications it is an overkill and clogs up IT/developers time.

This blog article goes through a simple PaaS/SaaS usecase where we explore the architecture, and design principles, used to create a rich user interface using the ABCS Service. Specifically this usecase mashes up data from more than one datasource, namely Oracle Sales Cloud and Service Cloud and additionally integrates with external services like Google maps.


The classic “Customer 360 Use case”

In this use-case, the business user wants to view their customers in three categories. Customers who are considered “Hot”  are those with open opportunities in Sales Cloud. Customers who are considered “Supporting” are ones with open Service cloud tickets and finally the rest are considered “Passive” customers. Additionally the user wants to display the customer locations on map and show a relevant graph of the customers against the open opportunities/incidents.



In addition the user wants to be able to drill into a specific account and see the details of the account, their opportunities in Sales Cloud and the customers related Incidents in Service Cloud.


Once the developer starts to look into implementing the example, a number of initial challenges are uncovered.

Such as:

  • How’s does one query opportunities based on the number of Opportunities they have given we can’t execute “Pre Query Triggers” and secondly based on the number of Service Cloud Incidents they have..

  • How does one query data from Service Cloud?

  • How does one create relationships between master blocks (page 2 –accounts ) and the details (e.g. Opportunities)

  • How does one create that nice looking map with pins from the data!! 

Thank fully the answers are equally simple but may not be obvious to some developers who are not used to working with citizen developer tooling like ABCS. The rest of this blog article will drill into the “How the sample was created” and future articles will dive into some of the specific details like how the Google Maps integration was achieved.


Overall Architecture

AngeloABCS-3 Overall Architecture[/caption]

Different queries – Same page

For the homepage, there are two challenges we need to deal with. Firstly on the main page, we would like to have a single list of Accounts, and Map, and then a pull down which would alter the query, alas this is not possible (yet J), but the easy workaround is to use to a set of side TABS which then point to individual customer types with the relevant chart/table items. The charts/tables/maps can then all query the same data source but with different query parameters. This approach also has the advantage that you can tweak the page based on the type of account you are displaying which is a common pattern.

AngeloABCS-4 Different customer types[/caption]

The second problem is the actual query itself, it is based on data which may not be wholly stored in the Oracle Sales Cloud “Account” object but a function of potentially two objects and perhaps even a remote object.

For example

  • To query the “hot” accounts we need to first query the open opportunities, and then use this to determine which accounts have open opportunities.

  • To query the "supporting accounts" we need to query the open incidents in Service Cloud and then correlate these to the accounts in Oracle Sales Cloud


There are many solutions to this problem but the simplest solution is to de-normalize the data model using Fusion Applications extensibility functionality. For our usecase this means creating some custom fields in the Sales Cloud Account object (numberOfOpenOpty and numberOfOpenIncidents) and populating these fields with the open opportunities/open incidents counts when changes occur in the respective screens.

For Sales Cloud

  • We can create a groovy trigger, which is executed when the opportunity is updated. This groovy script queries all the open opportunities for the account, which was updated, and then updates the account object custom field “numberOfOpenOpty” with the number of open opportunities.

For Service Cloud


Getting Data from Different Data Sources

As you can see in the architecture diagram, we are obtaining data from Sales Cloud and Service Cloud. Alas Service Cloud Clouds REST API does not present data in a format ABCS can easily consume with its declarative mapping. Currently Oracle ABCS only supports the ADFBC REST format (with a supporting describe method).  If you want to consume a custom REST Service as a business object you will need to implement a Business Object Provider, or BOP. This BOP acts as a façade to the REST interface and then presents itself to the developer as a business object at design time. For our application we need to implement a small BOP which provides two methods, one that queries all incidents for an given organization and another that queries the a specific Incident.



BOP Architecture

A good tutorial on building ‘BOPS’ can be found here https://community.oracle.com/community/cloud_computing/platform-as-a-service-paas/oracle-application-builder-cloud-service/blog/2017/03/03/getting-started-with-business-object-provider-bop  , It is also worth knowing that building a BOP requires average to good JavaScript skills and is not something most business users would be able to implement. ABCS engineering are working to create a set of tools which will simplify the consumption of non-ADF REST data sources so this will become easier in the future. The construction of a BOP can also hide any complexities in the REST service itself, for example if the querying of an accounts opportunities requires two separate REST calls then the BOP will hide this complexity, simplifying it to a single  API to the business user.

It is worth noting that if your REST services are complex then you might consider using another service to shape the original service into a more palatable format, specifically one call. Oracle PaaS provides a number of services which could be used, for example Oracle Mobile Cloud Service or Oracle Integration Cloud service both offer excellent API shaping functionality. The PaaS service chosen will depend on the complexity of the shaping and any orchestration required.


Creating Master-Detail Relationships Between Different Business Objects

If you drill down into the account, you reach a screen called “Account Info”. This page details the account information, its related opportunities (from Oracle Sales Cloud) and Incidents (from Oracle Service Cloud). Given this data is not a child element of the Oracle Sales Cloud account you cannot use the “default” drag-n-drop master-detail functionality of ABCS to link the two views. However the solution is just as easy, all you need to do is use the “default query” functionality on the destination table an link it to the master record to the appropriate field. This way when the detail table query is executed it will use data from the master record for its where clause. In our instance, we want the detail to only show “open” opportunities and those belonging to the relevant account.


Displaying The Customers On Map


The creation of a map, which displays “pins”, based on data from the table is easily achieved by using two techniques:

  1. ABCS Provides UI extensibility in the form of “custom components” where we can inject pure JavaScript into a region of our page

  2. ABCS additionally provides a JavaScript API which allows a JavaScript developer the ability to query data for custom components

Using both of these techniques together, you can easily display a map on the screen using data in the table.

ABCS also has the ability to consume Oracle JET Custom Components but as this map component is specific to our single page for this example, we have decided not made it reusable. An awesome evolution of this example app would be to create a reusable custom component and wrap it into a Oracle JET CCA.

Geertjan, one of our Oracle JET Product Manager has written an awesome blog article describing how to build a custom component live in the cloud. In a future blog article, I will dive into the details of building the map component used in this application.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha