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.
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.
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.
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.
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.
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.
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.
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.
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.
Click here to proceed to the next article in this series, What you should know when extending SaaS with VBCS – Part 5 Performance tips