What you should know when extending SaaS with VBCS – Part 4 To middle-tier or not to middle tier

When building a VBCS application you will almost always be connecting to a data source and one question you will almost certainly ask yourself is

” do I need a middle tier to access the data source, SaaS in our case has APIs, or can I, should I go directly?”

The answer to the question depends on many factors:

• Does the SaaS Service expose a REST API?

• Does the REST API meet your needs?

• Does the REST API support data security so that if a user bypassed the webUI no harm would be done?

• Are all your queries to the SaaS Service executed in parallel from the VBCS client?

• Is it OK if users have full access to the SaaS API (from a security/data point of view)?

If you answer “no” to any of the above questions, then you are likely to need a backend middle tier.

We have lots of customers who build applications against Oracle Fusion SaaS directly and it works perfectly. Sales cloud for example provides a very rich REST API, complete with data security based on the logged in user and browsers typically allow 4-8 concurrent web queries, so all is good when building efficient performant user interfaces.

That said many developers, including myself, do like the idea of creating a middle tier for a number of reasons which are detailed here below.

Benefits of a middle tier for HTML5/VBCS Applications

Separations of Concerns

By creating a middle tier, you have the ability to separate a number of concerns between developers. A middle tier here establishes a contract between the WebUI (VBCS) and the middle tier and likewise between the middle tier and the SaaS service.

• What happens if the SaaS API changes? By having a middle tier you can hide the changes from the UI so that the UI itself doesn’t need to be changed or redeployed. This helps developers develop their APIs whilst working with a backend data service which may change.

  • Scenario:  Service X today does not support a REST API but does support a bulk export mechanism, we know REST APIs are on the roadmap but we’re not sure when. By using a Middle Tier we can get the UI(VBCS) to adhere to an interface and the implementation of the interface (the middle tier) can change as the backend service changes.

• Many middle tiers (like API Cloud Service, Oracle Mobile Hub etc) allow the developer to define an API and then provide “mock” data. This is incredibly useful as it allows the web developer to quickly create screens usually before the middle tier developers have had time to build the middle tier API layer. This ultimately accelerates development and allows multiple teams to work concurrently in an agile way.

Aggregating service calls from multiple data sources

If your application has calls which need to go to multiple data sources then doing these calls in a middle tier will usually yield performance benefits. One of the main reasons for this is that the network connectivity between the middle tier and the Fusion SaaS Service is much higher than the corresponding UI to SaaS Service and thus the network latency/speed will be higher and thus more performant. The middle tier can also handle the merging/composing of data, perhaps using caches, and then return a single tuned payload to the VBCS client for it to consume – again reducing the load on the client network/client.

Increasing performance by aggregating REST calls

VBCS applications rely on REST calls to the server to get their data, when you consider a single screen can easily query 5-10 separate REST calls to get its data this means there could be a lot of calls being initiated by the client browser. If your calls are mutually independent (i.e. they can all be called in parallel and don’t rely on each other) then you can execute them all in parallel and wait for the calls to return. For VBCS this is very efficient as you can use the inbuilt parallel flow within action chains to query the data and all is good – up to a point. Most browsers enforce a limit on the number of concurrent REST calls which can be invoked by client side JavaScript, currently this number is between 6-8 for modern browsers, and if you are not careful you easily can reach this limit. When the limit is reached the additional REST calls are then queued up even though you executed the calls in parallel.

If you need to execute more than 6 concurrent REST calls and/or have REST calls which depend on the result of a previous REST call(s) then executing these all from a middle tier server can yield performance improvements.

Scenario: Your user interface needs to place an order. When placing the order, the business logic dictates that you need to validate the stock is available using a live call to a service, determine if the location of the stock is suitable (based on the previous call) and then place the order.

Executing these multiple calls from the client will mean the requests are queued up and waiting for the response for each call. By coding up a server-side middle tier API, which accepts the basic parameters and then executes the calls in the correct order to the SaaS server will likely yield higher performance. The server can then return a single response to the client, e.g. an order id which in turn is more efficent. The additional advantage of this approach is you are likely to create an API endpoint which exposes a specific API mapped closely to the UI needs, instead of exposing a SaaS API which is generic.

Increasing performance by caching data

Another area for performance gains when using middle tiers is by implementing a server- side cache for commonly queried data. This cache can be in situ with the code (a JavaScript object or Java static HashMap) or you could use a different cache layer like Redis or Memcached to cache your data. In this scenario when executing the REST API to get the data, the middle tier can check to see if the data is already in the cache and if not then query the data from the SaaS Service. The code would then put the data in the cache so that any subsequent calls would use the cached data. Querying from the cache will always be much quicker than querying from Oracle Fusion itself.

This technique is very useful for data which doesn’t change often like “value lists” in List of Values and general standing data which doesn’t change much (e.g. Product Names, Descriptions etc.). If you do decide to implement a server-side cache then do take some time to consider how you keep the cache “fresh” and invalidate data which is out of date. Depending on the cache you use will dictate how you manage the cache.

Containing the business logic

It is almost always a best practice not to have any business logic in the UI , and this is especially true for VBCS applications because they are HTML5 applications. By creating a middle tier API for your VBCS application you can push all this business logic into one secure place on the server and only expose an API which can be called by the UI. This pattern adds considerable additional security over exposing generic SaaS APIs to the client. Validation logic is ok on the client side providing the same validation is done in the server.

Example

In your VBCS App a user is able to place an order for a stock item. Depending on the size of the order, the location of the stock will determine if we are to use FedEx or Royal Mail for the delivery of the item. This (rather simplistic) logic could be done on the client side using a VBCS “Action Chain” but a better place to put this logic would be server side in the middle tier. Putting the logic there would allow us to ensure the rules are always adhered to and additionally given the calls may require additional calls to validate the order performance would probably be improved.

Front-Ending the SaaS APIs

Sometimes the SaaS APIs are not created to be exposed to web clients, or the internet at large. This could be for many reasons such as the APIs don’t support data security to the level required in the app or the data is just not formatted in a way which is easy for a web client (e.g. VBCS) to consume. Any response from the calls will likely require some data manipulation code and putting this all into a middle-tier will help here. All the composition, filtering, and merging of data can neatly be done server-side and then transferred to the VBCS client in an optimized format for the client.

Reducing impact of POST return values from Fusion SaaS Services

With Fusion SaaS when you execute a post, or patch, to update a value in the database, fusion will by default respond with the entire object as a response payload. This primarily for you to use it for subsequent processing (like knowing the primary key etc). The issue here is that this network traffic goes back to the client and when scaled up the impact can be large. There is a parameter you can put on the API Call (link) where you can tell the API not to return anything, zippo, zilch, just a 200 (OK) that it worked.. Whilst this works for some use cases (fire-n-forget) it does not work for all.

Again by putting the REST call in a middle-tier you can get the data and then avoid sending all this data back this data to the client by keeping everything server side, again this is where the network is fast and abundant.

Next Steps

Click here to proceed to the next article in this series, What you should know when extending SaaS with VBCS – Part 5 Performance tips