Skip to Content
Technical Articles
Author's profile photo Ashish Anand

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!!

Assigned tags

      6 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Mohammed Imran
      Mohammed Imran

      Great tips. Thanks for sharing.. Will try in my projects 🙂

      Author's profile photo Ashish Anand
      Ashish Anand
      Blog Post Author

      I’m glad you found it useful 🙂

      Author's profile photo Setu Saxena
      Setu Saxena

      Great inputs!
      Saves time by almost a factor of 3 times.

      Author's profile photo Ashish Anand
      Ashish Anand
      Blog Post Author

      Thanks a lot  Setu Saxena for the validation 🙂

      Author's profile photo Makbule Merve Gul
      Makbule Merve Gul

      Hello Ashish! Really appreciated for such an informative post!

      I had a question about handling requests with extensive data. For example, what happens if the user tries to fetch 500.000 items of data via 'created date' option in the filters. How will the cards (table & visual) will handle such a request? Is there any property that we can use such as the ones in the worklist tables (growingThreshold)? I would be really appreciated if you can share your thoughts, or refer to some pages.

       

      Best,

      Merve

      Author's profile photo Ashish Anand
      Ashish Anand
      Blog Post Author

      Hi,

      thanks for your question. You can technically fetch 50000 rows for OVP cards there are no technical restrictions as such. But it’s not recommend due to performance and other obvious reasons. OVP cards do not support growing threshold properties.

      hope it hopes 😊

      thanks and regards

      ashish