- SAP Managed Tags:
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.
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.
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.
This is how you can change this property in any Fe manifest:
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.
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.
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.
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.
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:
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.
My final tip is that you should try to get rid of all the console errors and network call failures.
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!!
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 |
 |  |
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 |
|  |
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!!
6 Comments
