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.
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
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
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 ).
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 :
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.
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.
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.
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)
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!