How to use scripts to build cross-pages interaction for the new optimized story of SAP Analytics Cloud?
Whether you were building stories or analytic applications, now you can use the new Optimized Story Experience, which unifies features from both stories and analytics designer as one design experience. In addition to creating your stories in a self-service workflow, you can create customized interactions with a variety of widgets, functionalities and scripting capabilities for business users to discover valuable insights behind data.
Beyond with classic analytical application’s TabStrip container, Story Page with Script API is introduced for users with analytical application developer role and permission to better organize their applications with optimized initial loading performance. Only the technical scripting objects and initial page’s widgets are created during the story view time initialization, and other pages’ widgets will only be created when user switches to that page. This mechanism allows inactive pages’ widgets to be created in a later time and improve the initial loading performance.
Shared technical components (e.g. Script Variable, Data Action, Timer…) can be accessed by all the pages via scripting, but each page’s widgets can only be accessed by same page’s scripts according to the performance consideration. The way to use script to manipulate widgets crossing different pages is different from the classic application programming model. This article explains the best practice about how to use scripts to build cross-pages interaction while leveraging the story page lazy load mechanism to improve initial loading performance.
Sample Scenario: change chart dimension filters on another page
Let’s first define a typical cross pages scripting scenario:
- The default “Summary” page shows KPI overview and highlights information “Nevada consistently underperforms for across all product groups”.
- End user can click the highlights information of “Nevada” to open the “Analysis” page to see the details filtered by “Nevada” location.
Coding Pattern: pass page context to other pages via script variables
To improve the initial loading performance and reduce memory consumption, all the widgets on “Analysis” page are not created until “Analysis” page is opened, and all the widgets on previous “Summary” page will be destroyed after “Analysis” page is opened. This means all the widgets on “Analysis” page cannot be referenced by the default opening “Summary” page via application scripts, vice versa.
To balance between the performance and cross-pages interaction, the recommended coding pattern is to pass page context to other pages via script variables:
- This current opening page stores its shared page context as script variables which are created during initialization and accessible by all the pages.
// Store shared page context to script variables SummaryPage_CurrentLocation = "[Location_4nm2e04531].[State_47acc246_4m5x6u3k6s].&[SA2]"; SummaryPage_CurrentProduct = "[Product_3e315003an].[Product_Catego_3o3x5e06y2].&[PC2]"; // New Script API for switching to Analysis Page Application.setActivePage(Analysis_Page);
- The new opened page can receive previous page’s context via shared script variables during its “Page – onActive” script event callback.
- The new opened page can transform and apply previous page’s context to its widgets like applying filters during its “Page – onActive” script event callback.
// Triggered after page is switched to visible, onActive event is triggered after onInitialization event if the page is first time loaded NetRevEvents_by_City.getDataSource().setDimensionFilter("Location_4nm2e04531", SummaryPage_CurrentLocation); DiscountRev_by_Location.getDataSource().setDimensionFilter("Product_3e315003an", SummaryPage_CurrentProduct);
Following diagram shows the entire workflow:
Story Page’s lazy loading mechanism to only create current page’s widgets brings better initial loading performance for complicated stories and analytical applications. To leverage such benefit while building cross-pages interaction scenario, the coding pattern is recommended to pass current page context to other pages via script variables instead of referencing other page’s widgets directly in the scripts.
This is the end of the blog. Your comments and suggestions are welcome.