Performance of SAC Applications developed using Analytics Designer is key consideration for usability of the application. “SAP Analytics Cloud, analytics designer Developer Handbook” has a chapter dedicated to Performance best practices. Refer handbook for overview. It provides overview guidelines along with, some details. The actual implementation depends on your application scenario. In this article, I would like to bring out some practical scenarios on how these have been implemented along with my own experiences in application performance optimization.
Aim : Initialize only the widgets that are initially visible to the user and then load the invisible widgets in background to improve the application startup performance.
Refer screenshot below for overall analytic application settings.
For widgets which are not necessary on startup , Uncheck the check box “Show this item at view time”
Note: Widgets inside invisible panels (i.e. tabs in tab strips and pages in page book that are inactive at startup) are by default invisible and no need to set this option.
In the practical scenario, the initial application view would have been rendered for use, but there could still be some widgets loading in the background. Unaware of the situation, if the user tries to navigate on the application, he will have to wait until the background loading is finished for all invisible widgets.
It is possible to pause “initial refresh of invisible widgets” during startup with “Pause Data Refresh” option on the widget.
Use combination of “Loading Invisible Widgets in the background” and “Pause Data Refresh” for long running background widgets where possible. This will limit the impact to specific views of the application.
SAP recommends use of “Initialize Variables Via URL Parameters” with the intent of avoiding passing values through scripting in “on initialization()” event. Extend this concept, if possible set default values in the backend system which can give additional performance.
It is also recommended to “Leave the on Initialization event script empty”. As far as possible follow this guidelines. You could make exceptions to initialize global variables.
Try to keep static filters in widget level instead of filtering data through scripting in on initialization event. e.g. A chart in the application has to be filtered for last 10 days of data. SAP is already providing time range filters
1. Use the Pause Refresh API :
2. Widget Data Binding:
Refer Screenshot below:
Note:
Use method getResultSet () or getDataSelections () instead of get Members () because get Members () will always lead to an extra roundtrip to the backend system.
Get Members () method is mainly to retrieve the master data so every time it will hit backend. Most of the cases customers request cascading filters implementation, in such cases Get members is not useful anyhow.
3. Filters on Widget:
Note:
Keep instructions before loop which will improve the performance as like mentioned above, store all widget data sources into an array variable instead of get the data source inside the loop as like below.
Conclusion
From a performance perspective, it is important to follow best practice design guidelines. This article detailed some use cases which are not so obvious and implementation of the guidelines from a practitioner's perspective for those use cases.
Other References : https://saphanajourney.com/sap-analytics-cloud/learning-article/performance-best-practices-for-sap-a...
Initial Load performance:
Loading Invisible Widgets in Background
Aim : Initialize only the widgets that are initially visible to the user and then load the invisible widgets in background to improve the application startup performance.
Refer screenshot below for overall analytic application settings.
For widgets which are not necessary on startup , Uncheck the check box “Show this item at view time”
Note: Widgets inside invisible panels (i.e. tabs in tab strips and pages in page book that are inactive at startup) are by default invisible and no need to set this option.
Challenges with this method:
In the practical scenario, the initial application view would have been rendered for use, but there could still be some widgets loading in the background. Unaware of the situation, if the user tries to navigate on the application, he will have to wait until the background loading is finished for all invisible widgets.
It is possible to pause “initial refresh of invisible widgets” during startup with “Pause Data Refresh” option on the widget.
Use combination of “Loading Invisible Widgets in the background” and “Pause Data Refresh” for long running background widgets where possible. This will limit the impact to specific views of the application.
SAP recommends use of “Initialize Variables Via URL Parameters” with the intent of avoiding passing values through scripting in “on initialization()” event. Extend this concept, if possible set default values in the backend system which can give additional performance.
It is also recommended to “Leave the on Initialization event script empty”. As far as possible follow this guidelines. You could make exceptions to initialize global variables.
Try to keep static filters in widget level instead of filtering data through scripting in on initialization event. e.g. A chart in the application has to be filtered for last 10 days of data. SAP is already providing time range filters
Improve run time performance:
1. Use the Pause Refresh API :
To optimize the performance of charts and tables, pause their refresh, let the user apply several actions on them, then refresh the charts and tables all at once.
Some use cases:
- Add or remove multiple dimensions/measures to widgets
- Applying multiple filters
Each action will warrant a refresh event impacting runtime performance. Pause the widget refresh before doing such collective actions and resume the refresh subsequent to actions.
2. Widget Data Binding:
Currently data binding of filter widget is possible through scripting, but we have to be careful while writing the script to avoid performance issues.
Use case : Populating checkbox, list box and drop down list values
If sorting is needed for displaying items in above filter widgets, we have to loop the data two times if we use “Manual input” for data source type and script to load the possible options. This will impact loading performance.
In this case, better to bind data directly using “Script variables” option for data source type. This way you will be able avoid multiple loops.
Refer Screenshot below:
Note:
Use method getResultSet () or getDataSelections () instead of get Members () because get Members () will always lead to an extra roundtrip to the backend system.
Get Members () method is mainly to retrieve the master data so every time it will hit backend. Most of the cases customers request cascading filters implementation, in such cases Get members is not useful anyhow.
3. Filters on Widget:
Use the copyDimensionFilterFrom () method instead of setDimensionFilter ()
Use case : Filter widget uses one reference data source.The same dimension filters have to be applied to other data sources in the application.
Note:
Keep instructions before loop which will improve the performance as like mentioned above, store all widget data sources into an array variable instead of get the data source inside the loop as like below.
Conclusion
From a performance perspective, it is important to follow best practice design guidelines. This article detailed some use cases which are not so obvious and implementation of the guidelines from a practitioner's perspective for those use cases.
Other References : https://saphanajourney.com/sap-analytics-cloud/learning-article/performance-best-practices-for-sap-a...
- SAP Managed Tags:
3 Comments
