Performance Tips

In this last blog post we explore one of the most important topics of any project which is performance. It is also worth highlighting that performance is an iterative process where the first data point you must define is the performance goal. Once you have the performance goal defined you can then start to benchmark your performance baseline (ie what its like at this point in time), After this you can proceed to tweak your code, then benchmark the result at each iteration so you can measure how close you are getting to your final performance goal. The rest of this article details some performance tips you can apply to your VBCS application.

Minify, Minify, Minify and Minify

Ensure you minify the project before running in production. With 19.1.x release of VBCS we now have the option to minify not only the VBCS runtime itself but also your code. Minificaiton is process where the JavaScript is “compressed” and anything which isn’t needed is removed. For VBCS the process is fundamentally the following steps.

1. Export application from VBCS

2. Apply minification to VBCS app

3. Import application into VBCS

It is possible to execute these steps manually via various “grunt” tasks documented here (specifically vb_build and vb_publish) but a better way of doing it is to use the associated Developer Cloud Service and set up a CI/CD pipeline. For more information checkout this blog post by the VBCS Product Manager Shay Shmeltzer https://blogs.oracle.com/vbcs/automating-cicd-and-app-optimization-for-visual-builder-apps-with-developer-cloud

Tune the REST calls

Using the browser’s network debugger, check your REST calls and see how much time each one is taking. The biggest contributor to slowness in most VBCS apps are the network calls themselves, minimizing and tuning them will yield the most significant performance improvements.

Always use the SaaS Connector

As VBCS is designed to work closely with Oracle Fusion and it understands the Oracle Fusion REST API, specifically the /describe API call format. As such, if within the Oracle VBCS UI you only query the “PartyNumber and PartyName” fields then VBCS will automatically modify the REST call and add the “fields=” parameter so that the minimum amount of data is returned to VBCS.

In some projects we have seen cases where developers have not used the Fusion Service Catalog, or ADF Describe, methods to define their connections and therefore do not benefit from this inbuilt intelligence. If, for whatever reason, you are unable to use the Fusion Service Catalog and have used the standard REST “Define by Endpoint” then you will need to add the fields= parameters to each, and every, REST call. This corner case often happens if you are using VBCS which is not associated with an Oracle SaaS instance.

Ensure you only query the data you need and do not query any metadata unless you actually need it. If you are using Fusion Services via the service catalog then this is done automagically for you but if (for many reasons) you aren’t using the service catalog then you will need to do this manually.

With Oracle Fusion this can be done by:

1. Reducing the data returned by using the fields parameter in the query,
   e.g.   fields=OptyNumber,Name,Status

2. You can stop the debug/additional information by adding “onlyData=true”

Server-side check that your REST calls aren’t firing off additional queries. For example, within Sales Cloud it is possible to create

E.g.

https://servername.em2.oraclecloud.com/crmRestApi/resources/latest/contacts?onlyData=true&fields=FirstName,LastName&limit=2

returns only

{
    "items": [
        {            "FirstName": "ICS",
            "LastName": "Integration"

        },
        {
            "FirstName": "Angelo",
            "LastName": "Santagata"
        },
        {
            "FirstName": "Emma",
            "LastName": "Thomas"
        }
}

If you are accessing a system which is authenticated using an Oracle Cloud account, or oAuth, then you can improve the performance of REST calls by using a feature called “token relay”. In VBCS all REST calls normally go via a proxy on the VBCS server-side, one of the reasons for this is that it avoids problems with CORS and allows VBCS to control the security. With regards to CORS, modern browsers now enforce the rule that REST calls can only go back to the server from which the HTML5 was actually served from, the origin. CORS solves this by defining a number of additional headers that a REST call can emit which tell the browser that the call can be executed against a different origin(s) to where the HTML5 app was served from.To Proxy or not to proxy

See https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS.

By sending all REST calls via a server-side proxy we nicely side-step this issue and still maintain security as the browser restriction is in place to protect browser apps rather than server-side transmissions.

Sending all requests via the server has its disadvantages though in that the additional network roundtrip can add an delay. The workaround to this problem is to enable the new “token relay” functionality. Here VBCS uses Oracle Cloud Account/oAuth to get a token via the server and then subsequent requests are always executed directly against the SaaS service.

We love CORS, but don’t forget the additional parameters in Fusion

Using Token relay is awesome but don’t forget that now all the requests are being executed on the client side and thus all the servers must support CORs. For Oracle Fusion you need to ensure that the appropriate CORs headers are enabled in Fusion Functional Setup Manager

In release 19 of Oracle Fusion , you can find these settings by going to the Fusion UI, Select the Sales App, navigate to Setup and Maintenance then search for Manage Administrator Profile Values:

Ensure the “CORS_ACCESS_CONTROL_ALLOW_HEADERS” profile value contains the following items:

Access-Control-Allow-Origin, REST-Framework-Version, Upsert-Mode

Documentation link for configuring Fusion for CORs https://docs.oracle.com/en/cloud/saas/engagement/19a/faaps/Configure_for_CORS.htm

Caching data on the client itself using JavaScript

Just like we can cache data on the middle tier we can also cache data on the client using a client side cache. A common piece of data cached on the client are lists, and their values. This pattern usually involves executing a query which gets all the possible values on the start-up of the VBCS app and then storing it client side. At runtime we can replace the “key” of a List item with its “value” (aka Description) without having to go to the server.       

See this video blog entry by Shay Shmeltzer for details on how to accomplish this neat trick: https://blogs.oracle.com/shay/tips-and-tricks-for-list-of-values-in-visual-builder-cloud-service

And of course the documentation here: https://docs.oracle.com/en/cloud/paas/app-builder-cloud/visual-builder-developer/configure-data-cache-and-offline-support.html.

A simpler alternative is to use persistent variables in VBCS, this feature allows you to define variables which persist on the client (session for example) and then use the data when you need it.

Persisted Variable Definition (From the documentation)

The value of a variable can be persisted on the history, for the current session or across session. It is useful by example for an authorization token which value is asked once and kept for the duration of a session such that if the page is refreshed, the token is still available. To store a variable across sessions, use "device" instead of "session".
 

Query your data in stages

The final tip on performance is a mix of good UI design and tactically querying data.

1.  Instead of displaying all data on the main screen, hide some behind tabs.

2.  Prioritise your REST calls to initially query only the data which is actually being displayed on the main screen. Whilst the REST calls are being executed a good tip is to hide the UI using JavaScript and then when the data has been retrieved show the UI, again a simple JavaScript call.

3. Once the main UI is shown you can execute background REST calls to query the remainder of the data needed so that when the user navigates to the tabs the data has already been retrieved.

In the following image, the best approach is to first query the data in the “360” tab, then query the Social,Security and Invoice tabs

Conclusion

This is the final blog post in this series, we hope this collection of blog posts highlights the areas you should be looking at when extending Oracle SaaS with VBCS. We would recommend you explore and peruse VBCS Product Managements blog series here and of course other blog articles written by subject matter experts in the ATeam and PMs blogs..