Skip to Content
Technical Articles
Author's profile photo Jove Shi

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:

  1. The default “Summary” page shows KPI overview and highlights information “Nevada consistently underperforms for across all product groups”.
  2. 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:

  1. 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);​
  2. The new opened page can receive previous page’s context via shared script variables during its “Page – onActive” script event callback.
  3. 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:

Summary

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.

Related Blogs

Unifying Story and Analytic Application with the New Optimized Story Experience in SAP Analytics Cloud

This is the end of the blog. Your comments and suggestions are welcome.

Assigned Tags

      3 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Jef Baeyens
      Jef Baeyens

      Thanks! The page events will help so much in app coding 🙏 😀

      Ps. Why use script variable & setdimensionfilter with strings...? I think best practice is use memberinfo object or copydimensionfilter() api 😉

      Author's profile photo Jove Shi
      Jove Shi
      Blog Post Author

      Good catch! This is just to simplify the sample code:)

      Author's profile photo Yoav Yahav
      Yoav Yahav

      thanks for this blog, a bit off topic, but Jove Shi is there a way to extract all the activity data regarding the usage of analytic designer? e.g. which stories and users are running analytic designer applications?

      Regards

      Yoav