Skip to Content
Technical Articles

SAP Fiori elements Overview Page (OVP) : Performance optimisation

Performance optimisation is always considered a challenging topic. Trust me when I say “it’s not with SAP Fiori elements”. In this blog, I will discuss how you can quickly optimise the performance of your overview page (OVP) applications using some of the best practices. Please have a look at the video which provides an overview of all the performance-oriented best practices for OVP application. In this blog, I’ll try to discuss all these steps in much detail.

Prerequisites

You should be familiar with SAP Fiori elements overview pages and the settings you can use to configure them. Make sure you have been to the previous blog of this blog series.

Tip 1: Count mode

OData model provides defaultCountMode property to decide how $count will be fetched for the line items. This property should not be left empty as this will result in an additional $count call for each GET call. OVP recommend keeping this property set to Inline so that the $count is retrieved with the same GET call.

defaultCountMode as empty defaultCountMode as inline
Additional%20%24count%20for%20each%20GET%20call inline%20%24count

This is how you can change this property in any Fe manifest:

Tip 2: Model Segregation

In general, for OVP apps, I recommend that you batch faster GET calls together with other fast GET calls. Likewise, batch the slower GET calls together. This will render the cards for which data is already fetched without waiting for other cards.

This also gives you an opportunity to define different model properties for different card types. For transactional cards, where we want to show the count information, defaultCountMode should be set to inline. Analytical cards for example, where we don’t want to show the count information in the card reader, should be set to none. $count can be quite expensive especially dealing with analytical entity sets.

You can segregate model even if you have only one service in your OVP application:

Refer the new model in your cards

Please note that the counter information will not be shown in the card header for any type of card if the inline count is none and the $count is not fetched.

Tip 3: addODataSelect

Set the card manifest property “addODataSelect” as true for all relevant cards. This will add the $select parameter to each GET call so that only relevant data is retrieved from the backend. This is a very important step especially while dealing with calculated columns.

addODataSelect as false, no $select addODataSelect as true, $select suffix
inline%20%24count

Here is how you can add this to your OVP manifest:

In case you need any additional data to be fetched, you can always use requestAtleast in combination with addODataSelect.

Tip 4: Use Extensions wisely

Extensions in SAP Fiori elements are a very powerful mechanism. And as they say “with great power comes great responsibility”. My fourth tip is that you should always use extensions responsibly.

Any complex and time-consuming calculation in Fe extensions should be avoided. A very common occurring scenario is application developers trying to fetch the default filter values from the backend via “modifyStartupExtension” extension.  This can easily be achieved via FLP user default values. please read more about FLP user default values in this blog.

Tip 5: Dependency Preloading

My fifth tip is that UI5 dependencies should be marked as lazy: true. They should not be left empty as the default value is false which will make the dependent libraries to be prefetched. This will increase the application rendering time. here is how you can achieve this:

 

Tip 6: SAP UI5 Version upgrade

We at SAP believes that the application’s performance is an integral part of delightful user experience. We dedicate huge effort for continuously improving our framework’s runtime performance. For that reason, my sixth tip is you should always try to run your application with the latest SAP UI5 version.

Tip 7: N/W call failures and console errors

My final tip is that you should try to get rid of all the console errors and network call failures.

Conclusion

I performed all the above mentioned 7 tips on an OVP application and was able to bring down the application start time from 7.7 seconds to 2.4 seconds. Making these changes takes less than 10 minutes and can bring huge performance improvement for your OVP application. Try it yourselves.

I’ll keep updating and adding new tips and tricks as and when they come in future. Happy reading !! 🙂

Feedbacks, questions and comments are most welcome!!

4 Comments
You must be Logged on to comment or reply to a post.