SAP Fiori elements Analytical List Page (ALP) : Performance optimisation

[AshishAnand]

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 Analytical List Page (ALP) 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 ALP 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: Minimalistic Visual Filters and KPI tags

Each visual filter and KPI tags require its own data call to the backend. so having many visual filters and KPI tags can reduce the performance of your ALP application by overloading your backend. This statement might look a bit weird in the way that application developers are being suggested not to use some basic functionalities like visual filter and KPI tags. So let me be very clear here, I'm only suggesting to use it very judiciously and not completely get rid of them.

For example, use a visual filter when if the user can and should filter the data using the visual filter. Do not use visual filters just to display the data in chart format. To visualise the data you can use KPI tag which shows an analytical card on click.

Manier times I have experienced applications to use the same KPI as global and filterable KPI in the same application so that users can still have the both the KPI numbers even after filtering. I'll suggest to avoid this practice and only have filterable KPI for this scenario so that the user can have the filtered and unfiltered values from the same KPI tag.

Tip 2: Avoid visual filter of type donut

Visual filters of type Donut takes more time than other types of visual filters i.e. line or bar, as it needs one extra call for the others section. hence my second tip would be to avoid Visual filters of type Donut wherever possible.

Tip 3: Batch call optimization for Visual Filters

My third tip is to segregate the batch calls for this visual filters. Parallel batch processing should be enabled for the called OData-services. Application developers can batch multiple visual filter calls by giving them groupId. It can be done by providing groupId in the extension method "onBeforeRebindVisualFilterExtension" so that the data fetch calls for the visual filters having the same batch id should be combined within the same batch call. By default, data fetch call for all visual filters goes as one BATCH call. This functionality is very much to performance optimization of your ALP application. 

	onBeforeRebindVisualFilterExtension: function (sEntityType, sDimension, sMeasure, oContext) {

		switch (sDimension) {

		case "Product":

			oContext.groupId = "Group1";

			break;

		case "Currency":

			oContext.groupId = "Group3";

			break;

		case "Product1":

			oContext.groupId = "Group2";

			break;

		default:

			oContext.groupId = "default";

		}

	},

Other Common Tips

Following tips which I have already explained in my other blog performance optimization for OVP application remains valid for ALP applications also:

1. Dependency Preloading


2. UI5 Version upgrade


3. To Use Extensions wisely


4. Avoid N/W call failures and other console error

Kindly refer to the blog here to find out more details on how to perform these steps.

Conclusion

I performed all the above mentioned 7 tips on an ALP application and was able to bring down the application start time from 7.5 seconds to 2.6 seconds. Making these changes takes less than 30 minutes and can bring huge performance improvement for your ALP 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!!