Speed of execution, performance, these are often terms that we want to associate with an application when we create it. In this article, I will present some good practices to remember in order to improve the performance of your application in Lumira Designer.
Not very familiar with Lumira Designer yet? You can read the article by Guillaume Goffaux "Senior SAP BI Consultant at Bilink" entitled "Lumira Designer - Some key aspects":
https://www.bilinksolutions.com/blog-data-visualisation/lumira-designer-quelques-aspects-cles/
Although Lumira is an excellent tool for creating dashboards, poor use of its components or poor management of its data sources are factors that reduce the speed of your application. However, before delving into the technical details, you should take the time to analyse what is really required.
I) Scenario
This may seem logical but often not enough time is taken for this important step.
It is not enough to list the functional requirements of the application, it is necessary to understand how the user wishes to use it, which will allow us to provide an application that reflects what the user wants.
It may then be useful to offer the future user a test session during which he or she is allowed to get hands-on with the application under development. This will allow us to get direct feedback from them, but more importantly, to be able to observe how they use the application (this may differ from what was understood) and to see the elements on which they may be led to block.
In this way, it is possible to modify internal elements of the application, allowing the change of certain points considered important in view of the user's behaviour.
It is clear that the more data the user wants to load, the longer the application will take to load. This is why it is necessary to discuss with the user that these loading times are inevitable. It is also important to know when they will be willing to wait and when they will want to consume their data without delay. A user who mainly uses the initial view of their application should not have to wait when it opens, and a user who needs to navigate through all the pages of their application is not prepared to wait between each page, for example.
Finally, you should run your tests with test sets that are comparable to the target. In this way, you will be able to see what the user will really be confronted with.
II) Data Sources in Lumira Designer
Certainly the most important point of all, the Data Sources have a significant impact on the loading time of your application. It is therefore essential to ensure that they are used in an optimal way.
a) Preparation
To do this, limit the amount of data you want to load using precise filters and without considering the source of the data (Bex, HANA views, etc.).
But also, make it easy for Lumira Designer, by making sure you filter your data before importing it so that Lumira Designer only needs to display your data and not manipulate it. Calculations in dashboards are resource intensive unless they are unavoidable. It is therefore preferable to perform them in the backend system. This way, they can be reused at different times.
It should be noted that without calculations in the dashboard, the outgoing data can be tested much more easily because it will have the same visual as the request. The more internal calculations there are, the more complicated the tests will be.
The same views should not be loaded several times in different data sources. Each time a view is loaded, the overall waiting time increases.
It is important to remember that all of these points are not a general truth, in the sense that each application has its own specificities, some of which require going against what has been mentioned above.
b) Loading
In some cases, the number of data sources cannot be avoided. This is why you can decide to parameterise their loading in the script. By default, the Data Sources are loaded when the application is launched. By modifying the loading method (via the Data Source properties menu), you can require that the Data Sources be executed following a specific event in the script. We therefore choose a specific interaction which will load the Data Source (when we change page for example), for this we use the following code: .loadDataSource()
Load in script in Data Source property
In addition to load in script, background processing can be used. This feature allows a data source to load in the background, while the user will have the application loaded with the first visible components. We are not talking about a performance improvement here as this method will use more memory, we are talking about giving the impression of better performance to the user even if the overall performance decreases with its use.
Launching BackgroundProcessing
We will therefore concentrate, at the launch of the StartUp, on loading the Data Source(s) really useful for the display of the initial view. Then, we will launch the background processing event in the script to load the rest of the Data Sources.
When Data Sources are loaded, they are executed sequentially by default. It is possible to use a feature available in the Data Sources property menu: processing groups.
The method is simple, instead of loading all the Data Sources sequentially, we will create loading groups that will run in parallel.
The problem with using this feature is the use of memory. For each processing group that loads Data Sources, we will use more memory because it will require a new backend session over the load time. If you don't have any problems with memory, this method is for you!
To create a processing group, go to the properties panel of your Data Source, assign any name for the group and use this name for all the Data Sources in the group. Each processing group will run in parallel and the data sources in each group will load sequentially.
Think about the arrangement of your data sources in groups, they should be distributed so that the groups have a similar execution time.
Example of optimising the execution of two processing groups
By grouping the Data Sources in this way, the execution time of PG_1 is approximately equal to that of PG_2, so there is virtually no time loss. If you want to use processing groups, you must be careful not to load the Data Sources of the same processing group individually. Indeed, it is necessary to always load all the Data Sources of the processing groups in the same load:
Launching all the Data Sources of PG_1 and PG_2 of the previous example
Finally, Lumira Designer has its own management of input variables from your Query Bex. Indeed, all your input variables are stored in a container.
However, if you use the same variables several times in your different Query Bex, they will all be collected under one variable in the container. This means that using APPLICATION.setVariableValue() and APPLICATION.setVariableValueExt() for a specific Data Source will impact all Data Sources using the modified variable.
There are various methods to overcome this:
The first is to disable the prompts merging option in the application settings. The second is to remove the input variables in the Query Bex and use instead .setFilter() or .setFilterExt(). The second is to change the execution event, instead of the OnStartUp on place OnVariableInitalizationThis will avoid initialising the Data Sources twice in the Startup.
III) Using the components of Lumira Designer
It is important to use as few components as possible, as too many components will impair the performance of your application. When creating a new page, you have the possibility to reuse components already created for old pages. You can move your component to a new panel and then change the Data Source used:
Example of code to use to move components
Here, we first move a graph and a crosstab to the new page and then change the Data Sources of the latter.
We could push even further our optimization by reducing the number of Data Sources. Indeed, it would be enough to use .assignDataSource to change the source of our DS_1 by applying another data set to it.
a) Crosstab
Depending on the type of use, you can change the way the displayed data is loaded. The default crosstab scrolling loads lines in real time as they appear. You can change this scrolling method to " Pixel-Based Scrolling ". By using this method when loading your crosstab, the entire crosstab data will be sent to your browser. This results in a longer loading time when the crosstab is launched but a smoother navigation once it is loaded. This is why a good knowledge of the amount of target data displayed is important here.
b) Pagebook
The same is true for Pagebooks, their use should define the type of loading you wish to assign to them. This is called pre-loading, in the sense that the non-displayed pages will be loaded before they are launched. By default, no pre-loading is done, only the displayed page is loaded. The other pages will be loaded when they are launched. We have the possibility of activating " Previous & Next pages " which, as its name indicates, will allow the previous and following pages to be loaded when a page is launched. Finally, the most time-consuming method, " All pages ", will allow all the pages to be pre-loaded at launch. This will naturally take longer to load at launch, but the site will be smooth afterwards!
Pre-load option, PageBook property
IV) Using the script
You should keep in mind when developing that for each set and get you add to your script, a search will be performed, which means that your application will allocate memory to this search. Make it a habit, if you need to perform the same operation on various components or Data Sources, to create a global variable for the result of this get.
Example of using a global variable rather than repeating "get".
Here, a single search will be performed for the get. Without this variable, it would take twice as much memory!
When you want to change pages, you must hide all the components and display those of the new one. So think about hiding the containers in which your different components are arranged (hiding a panel containing five components rather than hiding its components one by one), you will thus reduce the number of lines in your script.
V) Choice of browser
As your application will be running on a web browser, it is important to choose a browser with qualities that correlate with your desire for application performance. SAP Lumira Designer uses different libraries, which must be transferred to your browser at least once. These libraries will then remain in the browser's cache and will not need to be transferred the next time the application is opened. For this reason, your browser should not delete the cache when you close it. In addition, the browser's cache space must be sufficient to allow all libraries to be downloaded.
SAP advises against the use of Microsoft Internet Explorer and recommends the use of other browsers such as Firefox, Chrome or Opera. As Microsoft is concentrating on the development of Edge, updates to Internet Explorer are only for security fixes.
VI) Mobile Application
With SAP Lumira Designer it is possible to create an application for mobile use. However, there are a few things that need to be taken into account before you start designing.
At first, you should be aware that your mobile version will have nothing in common with your web version. Assuming that you have gone to great lengths to customise your web version, incorporating multitudes of CSS classes and pixel-perfect components to match the size of the target screens, you will not be able to use these settings for your mobile version. The easiest way to do this is to create the new architecture for your mobile version from scratch. When you launch your application, you will need to add this:
var info = APPLICATION.getUserAgent() ;
if (info.indexOf(« Device« ) != 1 {…}
The getuserAgent() will identify your operating system and the browser you are using. By replacing Device with your target device, you will be able to separate your application into two versions. A mobile version and a PC version.
Example of a script to be placed at the beginning of a startup to identify the Device
For a mobile version of your application, you will have to limit the number of data sources and components. Indeed, on a mobile phone, the main performance factors are: the power of the device and therefore its capacity to process the information and above all your connection! Think that in GRPS or 3G your latency time will be on average five times higher than if you were in 4G or LTE (500ms in 3G against 100ms in 4G), and you will have to add to that the normal latency time to communicate with SAP BusinessObjects.
You must therefore apply all the points you have seen so far and make sure that your components are responsive (that they do not protrude from the screen). Finally, you must absolutely limit the rows and columns that you display in your crosstabs, the best being to not use a crosstab at all.
VII) Measuring the performance of your Lumira Designer application
In order to study the performance of your application a little further, SAP Lumira Designer has a built-in performance analyser. This analyzer is presented in the form of a dialog box that can be activated (Tools à Application Design à Support Settings à Activate Runtime Profiling). You can see in real time what the application is doing, which components are loaded, when and for how long they are loaded...
Each time a new event occurs, a dialog box is displayed to inform the user of what is happening. It is also possible to export this dialogue box for later analysis.
Runtime Profiling dialog box
The information that can be obtained by this Runtime Profiling is the following:
- Execution time of each navigation step.
- Loading time of the Data Sources.
- Correct execution of the Data Sources.
- Verification of the correct operation of processing groups.
- Execution and display time of the application components.
It is also possible to measure the execution or display of elements with the following code:
APPLICATION.getTickCount();
Conclusion
SAP Lumira Designer is a powerful tool, however, poor management of your application and its components can severely impact its performance. From setting up your Data Sources to finding the exact element that will save you 100ms of loading time, it is important to think about all these tips when developing your application.
However, you should be aware that each application has its own requirements.
It is then up to you to judge how best to use SAP Lumira Designer. You now have a number of keys that can improve the performance of your application. Just remember to keep it simple!
Learn more about the SAP Lumira Designer tool: Sap Lumira, Designer Edition: The Comprehensive Guide.
Aymeric Alos
Latest articles by Aymeric Alos (view all)
- SAP Analytics Designer - July 27, 2022
- Aggregation exceptions : Usage, Keep flag, push down - 27 October 2020
- How to improve the performance of your application in Lumira Designer? - 27 May 2019