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.
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.
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.
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.
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.
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
For Service Cloud
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.
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.
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.
The creation of a map, which displays “pins”, based on data from the table is easily achieved by using two techniques:
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.