Some time ago, we implemented an SAC KPI Tile Dashboard within the Analytic Applications. By now, applications in the SAP Analytics Cloud are no longer relevant and have been completely replaced by Stories. Despite slightly changed menus and functions, the KPI Tile Dashboard presented back then can easily be implemented in a Story.
Although the original solution was highly adaptable, there was one limitation: KPIs for the tiles could only come from a single data source.
In this blog post, we will explain how to implement a large KPI board with over 50 KPI tiles, some sourced from different data sources, and discuss the limitations involved.
SAC Tile Story
Even though we usually advocate a best-practice approach that includes a maximum of five to eight different KPIs per dashboard, there are scenarios where a large KPI board makes sense. For example, as a central landing page that allows navigation to various detailed Stories - similar to the Overview Pages in the S/4HANA Fiori Launchpad, which provide a quick overview of relevant key figures and serve as an entry point for further analysis.
By implementing many small tiles, the Story can also be consumed on devices with smaller screens, such as tablets or smartphones. This was, of course, taken into account during development, ensuring that the number of tiles displayed side by side automatically adjusts to the screen size.
KPI-Tile Story on smartphone and tablet
The Core Components of the KPI Tile Story
For our Story, we use pre-built tiles that can be shown or hidden as needed. But what exactly are KPI tiles? In general, these are widgets that display key figures, possibly with dimensions, deviations, or thresholds. Essentially, it’s the standard chart widget of the SAC, compressed to highlight only the most important information at a glance.
While this description applies in our case, the technical implementation of our Story relies on the panel widget. This means it doesn’t matter what is inside the panel - besides the chart widget, it can also contain custom widgets, embedded web elements via iFrames, images, or links to other Stories. Various elements can be combined, but given the number and size of the tiles, the rule often applies: less is more.
Structure of a KPI Tile
To create an appealing tile design, we use a few tricks. Each tile consists of:
- Main Panel (PA_001) – This is the primary element that is shown/hidden in the Story, and all scripts refer to it.
- Inner Panel (PA_BODY_001) – Creates the tile’s visual structure, since spacing between objects cannot be generated within a flow-layout panel.
- Actual Content (CH_01) – The content defined by the creator, such as a bar chart.
The implementation is quite simple, but it has the restriction that the order of tiles cannot be freely determined; instead, they always follow a predefined structure.
Key Elements of the KPI Board:
- Flow-layout panel with pre-built tiles
- SAC data model with a public dimension
- Input control to manage the tiles
- Script objects for tile management
- Bookmark function
Implementation in an SAC Story
The chosen Story layout (Canvas or Flexible) doesn’t really matter since we use a flow-layout panel as the main container. Only the header and side filter menu are outside of this panel. The flow-layout panel has the following advantages and disadvantages:
| Advantages |
Disadvantages |
|
|
|
|
|
Outline of the KPI Tile Story
Dividing the dashboard into sections improves clarity for users. Using the input-control widget for KPI configuration provides a built-in KPI search, significantly enhancing usability - especially when many KPI tiles are included in the Story. Additionally, leveraging hidden bookmarks allows for Story personalization. Whenever a user changes the KPI configuration, a default bookmark is created. This ensures that the next time the Story loads, it starts with the user’s preferred configuration instead of displaying all KPIs.
Dashboarding with SAP Analytics Cloud -
Download the Whitepaper here!
Backend Implementation of KPI Control
To toggle KPI tiles on and off via input control, we need a central control data source. It must be structured so that data can be easily modified, added, or removed to manage KPIs dynamically. This can be achieved using a Business Warehouse query based on an aDSO, which is maintained via NextTables. A different approach ist the usage of a SAC data model with a Public Dimension.
Public Dimension for Tile Configuration
In our case, the SAC data model was deliberately designed with some flexibility. Firstly, we wanted to provide additional information for each KPI tile, such as the source system, query or data model, and a description of the key figure used. Secondly, the data model is not tied to a single Story but serves as a central maintenance point for all KPI Tile Stories.
Unfortunately, Public Dimensions cannot be directly used as a data source in a Story. To bypass this SAC limitation, we create a “dummy” data model containing only the Public Dimension and a single key figure, which is then used as the input control source.
Scripting the KPI Control
Once KPI tiles are created in the Story and the Public Dimension is populated, we move on to the final technical step. Input controls typically filter only data within other widgets. In our case, we need to use scripting to establish a connection between our tiles and the filter values of the input control.
There are different ways to execute the script, depending on how you want to handle configuration and bookmarks. However, the following process always applies:
We have a table in the background controlled by the input control. The script runs only when the “onResultChanged” trigger of the table is activated.
In our case, multiple scripts are executed:
Temporarily hiding the flow-panel layout (FLP_BODY) during execution makes the process look smoother. If all tiles in a section are hidden, the section header is also hidden. Additionally, the default bookmark is created and set. However, the core components are the two scripts hideTiles() and showTiles().
With hideTiles(), all relevant tiles are hidden, even if tiles were added to the Story after the initial GoLive.
After all tiles have been hidden, we display the new selection using showTiles().
To handle the type mismatch between the input control entry and the actual panel, we use Applications.getWidgets. This script is sufficient for implementing KPI control. Additionally, we have included some extra features, such as an info box for all KPIs and links to respective detail Stories, but these go beyond the scope of this blog post.
Future Outlook and the setModel Command
When comparing the original KPI Tile Application with the new KPI Story, both approaches achieve similar results but with different limitations.
The ideal solution would be a Story where each tile can be individually configured—allowing users to select the model, key figures, dimensions, and chart type themselves.
With the Q4.2024 update, we are one step closer to this goal, as the .setModel command for charts has been introduced. This allows the model to be swapped via scripting. Key figures and dimensions have been scriptable for a long time, but chart type changes are still missing from the API commands.
Although some developers desire the ability to change chart types dynamically, this is often impractical. Adjusting the chart type typically requires modifying other chart and layout settings to ensure a meaningful display. These additional configurations could overwhelm users and blur the line between a customizable Story and self-service analytics.
For this reason, users generally prefer KPI boards with well-designed, predefined KPI tiles. A good alternative would be to offer selected KPIs with multiple, carefully chosen chart types to provide different perspectives.
We are eager to see whether SAP will implement this API adjustment…
Do you have questions about SAP Analytics Cloud or other topics? Simply get in touch with us - we look forward to exchanging ideas with you!