Best Practices from Oracle Development's A‑Team

Extending Oracle Fusion SaaS - Best Practices

Angelo Santagata

Extending Oracle Fusion SaaS - Best Practices


Like any software product there are many ways to perform a task ,many techniques which can be used and best practices gleamed from experience of implementing extensions to SaaS systems. This section discusses some of the best practices we have observed and also some antipatterns which one should avoid at all costs.

Learn SaaS Functional Areas – Don't Be a Technology Bigot

The Extending SaaS with OCI skillset is quite unique, you need to be someone who knows OCI technology BUT also you need to understand the functional area that you are working with. For many years I mistakenly thought I didn't need to know the functional side of things but I eventually learned that you DO need to be familiar with SOME functional "know-how" to get the best out of the APIs.  At the same time you do not need , or many cases want, to be a someone who knows the functional area of a Fusion pillar to a high level, its best to leave that to the experts.  Our advice here is that the developers all go on a "overview" course, spend some time tinkering with the pillar so that they know what they are dealing with and how to interpret the results correctly. 

An old example I like to give is that in the old days if you created an account in Sales Cloud you would find that when you went to the opportunity screen in Sale Cloud you were not able to create an opportunity against it. When this happened to me it took a long time to work it out, well a friend of mine explained it to me. In short you can only create opportunities against customer accounts, whereas in Sales Cloud I would notice the account I had created was marked as a prospect account. This is because the account did not have a "bill to" address. As soon as we add a bill to address the account is automatically upgraded to be a full blown customer account and thus opportunities can be created against it. This functionality is no longer true in Fusion, we now allow you to create opportunities against prospect accounts but it serves the purpose of reminding us "techies" that we need to know some functional knowledge to understand how the system works

Don't Forget Security

When building extensions in any technology its very easy to forget about security, or very commonly think about it later. 

At the very start make sure you consider the following security 


  • Does your extension need SSO? If it is a user interface then almost certainly you want to have SSO configured so that when the user goes from Fusion SaaS to your extension then SSO is enabled and they don't need to log in again.
    • If you are using Visual Builder Service then you could be forgiven to think it is all taken care of for you - well yes and no. Yes it is taken care of for you, if your VBS instance is associated to an IDCS instance which in turn is federated with Oracle Fusion but if the IDCS instance is not federated with Fusion then you will need to manually set up the federation. Also worth noting that an IDCS instance can only be federated with one Fusion instance at a time. If you need to federate your VBS IDCS instance with Fusion applications then see this blog /doc { PLACEHOLDER URL] post
    • if you are using Oracle APEX then it is also possible to get SSO working with Oracle Fusion, however it needs to be configured manually, see this blog post TEMPORARY URL for more info
    • If you are building a custom HTML5 app then the way you get SSO working depends on the technology you are using.

Protecting your API resources with the same authentication as Oracle Fusion

  • If you are producing an  API layer you probably want to protect it with the same authentication as Fusion Apps. For example from within VBS you want to call a middle tier, e.g. Oracle Cloud Functions, pass in a valid Fusion authentication token and then call fusion with that token.  That can be done but you need to make sure everything is setup. E.g. IDCS needs to be federated with Oracle Fusions identity stack and you will almost certainly want to create a custom OAuth application for this api. Often customers simply ignore this and hard code a username/password in the middle tier and then call the middle tier with another username/password combo. This is a poor security design and is strongly recommended against. If you want to learn how to protect an API endpoint with Fusion credentials then refer this blog article by my colleague Ulrich Janke where he explains how to set it all up

Everyone Loves a Cache 

We have often seen the case where a client , be it a UI or a middle tier, regularly needs to lookup data. For example a Swedish customer of ours created a UI which allowed users to "pick" products from a list of products, which in turn had a dependant list of products/options. One approach we had was to call Fusion everytime we needed to get the dependant list , this wasn't fast. The approach we went with was to create a function server side which returned 2000 rows of data (name/value) and then store them locally. When we needed to list the dependant options for a particular value it was super quick. Worth noting that we did not query 2000 rows of data directly from SaaS but stored a copy of this data in a server side Oracle Database as this was quicker and this data changed very infrequently.

The above example demonstrated how you can use two caches, one client side (data stored in the browser) and one server side ( an Oracle DB ).

NO SQL Please! and I mean NO SQL and not Not Only SQL

A common practice amongst developers is to query the Oracle Fusion database tables using BIP+SQL and then return the data to clients (It's  a SOAP call). We do not recommend this approach , it's fraught with issues and is not scaleable .

The recommended approaches are :

  • Query the REST Services directly
  • If your query cannot be achieved via REST, because the query is too complex or the data is not available via REST, then use a local database to store a regularly updated snapshot/copy of the data and run your queries against this database. The database would be kept in sync using the pillar's extraction tooling (e.g. HCM Extracts, BICC , BIP , CX Export etc)
    • Your client can also query the database using the middle tier (JDBC etc) or if you are using the Oracle database you can query the data in the data using REST by leveraging a Oracle REST Data Services 
  • If you are using a pillar which includes the use of Application Composer then it is possible to create groovy functions in AppComposer and call these from REST  Services. This approach means we can call the function, pass in parameter(s) and then query all the data in groovy (server side) , perhaps merge data from multiple queries and then return the entire dataset as a single REST payload. This blog from Tim Bennett payload demonstrates you can batch insert data using Oracle App Composer custom actions, the same technique can be used to query multiple sets of data from multiple business objects.

Be Frugal With Extensions

Be frugal with extensions.  Don't extend unless the targeted business requirements are absolutely needed and impossible to modify to be more in line with what is supported by SaaS OOTB.  Not only can a SaaS extension be time-consuming and expensive to design, develop, and deploy initially; there are also ongoing maintenance costs over time.  We are not saying that SaaS extensions should be avoided completely, but make sure that upfront costs and ongoing costs are justified by return on investment.

Additional OCI Components Come With Complexity Cost brought in to support a SaaS extension adds complexity

Every additional OCI component brought in to support a SaaS extension adds complexity to the SaaS application. If analysis justifies the investment of building a SaaS extension then all attempts should be made to limit the extension footprint, bringing in only as many components as are necessary to get the job done. If possible lean towards serverless components , like Cloud Functions, where possible. The Serverless components infrastructure is managed by Oracle and will significantly reduce the cost of the SaaS extensions. 

Real-time vs. Batch. 

Some business requirements require real-time data movement and data updates.  This tends to make extensions more difficult to implement.  Use batch data movement apis where possible as these will yield the  best stability and performance.

Don't Forget Error Handling

Do not forget error handling, systems metrics monitoring, and recovery.  Adding components will make error handling and extension monitoring more complex. When writing the code, extensions always consider failure for each operation.  Most developers will handle error conditions when, for example, a service call fails and produce an error, however we often see very little consideration for the out of the ordinary errors.


When thinking of error handling we usually ask the following questions and test ourselves that the solution we've built caters for this

For example (and not exhaustively) 

  • If the service call fails, will it retry?
  • What happens when the destination service comes back alive, will it crash again under the backlog load?
  • If a service fails, do we need to "undo" a previous service call?
  • If a service fails, will operations know before the customer does?
  • If a service fails will the data still be in a consistent state? 
  • What happens if a service is being patched? are they all patched at the same time?
  • Will the system experience downtime at anypoint? Will that affect any of the systems?

Next Steps 

As a team we have written, and still writing!, a number of articles where we cover many of the "Extending Oracle Fusion SaaS with OCI" topics. If you want to learn more navigate to the Extending SaaS with OCI Series post and checkout the other articles we have written. Do let us know if you have any other topics you would like us to cover do let us know!


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