Working with Additional Data Loading Settings and Functionality

You can use the Always initialize on startup feature to influence the performance of story when either Viewport Loading or Background loading has been set as the Loading Optimization Setting for the story.

If you set the widget action to Always initialize on startup in the widget's Styling panel, then it is initialized with all of the visible widgets as part of the initial rendering phase. This might improve performance in situations where the widgets are accessed while scripts are being processed and before the background loading is finished.

If you use this function for widgets that are embedded in a container, ensure that either the container itself is visible at runtime or that you have enabled Always initialize on startup for the container.

Always initialize on startup doesn’t work on widgets in popups. To use this option, move the widget from a popup to the canvas.

If the widget is used as a data pool and is never visible at runtime, then best practice is to place this widget directly on the canvas instead of embedding it in a container.

When the story is saved, its first page’s query definition with required model metadata is cached publicly for all the users. This improves the initial loading performance by avoiding extra round-trip requests such as loading model metadata.

When a user opens a story, it is checked to see if the existing public cache is valid. The cache becomes invalid when a related model is changed (including a version change in a planning model). If the public cache is valid, then the cache will be used. If not, a separate request will be made to fetch current metadata. This newly fetched metadata then replaces the old cache.

The cache cannot be used for widgets that have a data source referenced by a script event.

Examples of scripts that will prevent the cache from being used:

• Chart.getDataSource().setDimensionFilter() or
• Chart.getDataSource().getResultset()

A full list of APIs that prevent the cache from being used can be found in the appendix at the end of this lesson.

When working with bookmarks there is an extra public cache object that stores the query definition and the model metadata.

For the initial story creation (first time saving the story) the following logic applies:

• If bookmark scope is configured to State-Changed Components Only (default option) or All Components in the Story , then the cache is created when the story is saved.
• If bookmark scope is configured to Selected Components Only, then the cache is created when the first user views the story.

For any change of an existing story (re-saving the story) the following logic applies:

• Any existing bookmark cache will be removed.
• When the first user views the story the public cache will be generated.

Using the bookmarkset.apply() script API to load bookmark will not consume or generate the bookmark cache.

The default values in the Query Settings are designed to be the best fit for the majority of SAP Analytics Cloud stories. It is for this reason, we recommend keeping the default values, as shown below.

The Batch Settings are only relevant for the following data sources:

• SAP Analytics Cloud import models
• SAP Datasphere live models
• SAP HANA live models

If you are accessing data from other connections, this setting is not relevant.

In the Batch Settings section, the following options are available to you:

• Enable Query Batching
• Enable Query Merge

You can enable one of the two options or disable both options.

When the Enable Query Batching is selected, the various queries against the same model are combined into a batch consisting of individual analytics objects and sent together as a single HTTP request. On the server, the analytics calls are processed as isolated queries using threads.

Depending on specific settings in the source systems, such as limits on the amount of assigned resources per request, then you might consider reducing the upper limit of the number of Queries Per Batch.

Selecting Enable Query Merge merges requests against the same model when their result sets have different measures but the same dimensions/drilldown level. When you save a story with this setting enabled, then widgets containing queries that can be merged are colored in the same color to let you see what can be merged. This setting can only have a positive impact on data loading performance if you have a high number of widgets that have a matching result set and are rendered with data at the same time.

The cache referred to in this setting is the cache that is created per user and per session.

When the user opens a story and navigates through the story's pages, up to 10 pages with their widgets are cached locally in the browser. The system default is 150, however, this can be changed in System → Administration. When the user navigates back to a page that they have already viewed and is available within the cache, then this cache is used meaning the page opens faster. If Override Cache Limit is enabled, then more widgets are cached. However, as this uses more browser memory, then it can impact on the user's interactions with the story by slowing them down.

When compared to, for example, the data Loading Optimization Setting, the aim of this setting is to speed up the initial start time of the story. This setting only targets the story page navigation performance and not the initial loading time of the story.