Skip to Content

Introduction

The dashboard at hand is supposed to provide insights into the new Lumira 2.0 features: The new composites, the integration of offline data and the adaptive containers are most important to note. Hence, this demo aims at showing how these features work in combination. Moreover, it serves as an inspiration and can be regarded as a template. Data used in dashboard is dummy data only. Visualizations have been chosen randomly to show a variety of chart types (e.g. radar, tag cloud, doughnut). The chosen type may therefore not match the type actually recommended for use for a specific KPI. Feel free to visit this blog regularly to stay up-to-date with the new Lumira innovations. The lumx-file can be downloaded at the end of the page.

Features:

  • Offline-data imported via Lumira Discovery
  • KPI-tiles as custom components
  • Fiori 2.0 Look & Feel
  • Details for all KPIs
  • Built-in search functionality for KPIs
  • Freely configurable front page
  • KPI-specific reports incl. map

 

Custom Components for Tiles

The tile composite can be used either with or without chart area. It has the following features / properties:

  • Display of KPI name
  • Display of values, optionally with color code
  • Unit of KPI
  • Trend icon and value
  • Link to KPI details

All relevant elements are binded to the composite properties, so no script is needed here. There is only some script in the formatter functions and for the central function setValues to set the composite properties from outside the composite.

 

Adaptive Container

Each page of the TabStrip makes use  of an adaptive container. In this demo, the adaptive container was configured in a way that it matches tablets, desktops and large desktop screens. There is also a fourth viewport used for smartphones, but it seems that smartphones does not support composites.

It is important to note, that due to the architecture of the adaptive container, tiles with charts should always be displayed at the beginning of a block in order to enable an optimal design. The different block size decides whether the lower part of the tile (the chart) is displayed or not.

Usage of Tiles

Tiles are initialized with the following command:

GS_TILES.calcTile(„1000“, KPI_TILE)

The value “1000” corresponds to the internal ID of the KPI. “KPI_TILE” is the technical name of the tile composite.

The values are read from a central DataSource and transferred to each tile via script. The tile itself does not have a data connection, it rather obtains its data using the consuming app and the respective DataSource. If you use a DataSource in a tile, the DataSource is loaded per instance of tile. Therefore, I would not recommend to use DataSources in Composites if you want to use the same composite more than once per Application.

In order to display chart data in the tile, the function setChartConfig is invoked within the tile. In this step, the type of the chart and the DataSources from the app are transferred to the tile.

The original solution was based on BW and the usage of attributes (KPI as main info object). To simulate attributes i decided to store all masterdata concatenated in one field separated by a “|”.

In the onstartup-Event the function “splitMasterdata” is called. In this function the masterdata is read from the DataSource and splitted among the different arrays.

The following illustration exemplary shows how master data is used:

Details

For each KPI, one can jump to a detail screen. This detail screen consists of the following areas: monthly progress, description and further evaluation of the KPI (if available).

The monthly progress shows the actuals, average and plan values. The description displays a long text for the KPI. The comment field on this page does not have a function. In the original BW-based solution, the text was written back to the BW using a specific planning function type from the BW-IP.

The detailed evaluation is always displayed in the same way. This area surely requires revision. However, it does show how KPI-specific evaluations can be integrated in a dashboard of this kind.

As Lumira 2.0 also provides an enhancement of the map component, a map illustration on the level of buildings was implemented for the KPI “Ø Energiekosten (pro Gebäude)”:

The map can be found on third tab. Switch to the chart, activate navigation and choose in the chart type picker the map. From technical point of view the chart is set to invisible and the map-component gets visible. Sure, the third tab needs a little bit of rework.

KPI-Search

In the demo data, several KPIs distributed along the four tabs were already illustrated. If  the end user searches for a specific KPI and does not want to click through all of the tabs, he or she can use the search function to directly navigate the desired KPI. The search can alternatively be invoked using CTRL+F.

This is just a very simple search solution based on Stringsearch.

Home

Each user can select and save his favorite KPIs with the Dashboard start page.

Up  to nine tiles can be stored. Tiles can also be deleted using the ‘delete’-symbol. The ordering is displayed in accordance to the time stamp of recording. Here, the new bookmarks from Lumira 2.0 are used. In the background, solely the IDs (1000,1001, etc.) of the selected tiles are saved and the tiles are rebuild with every start.

 

Download

Please do not rename the lumx-file to avoid script errors during lumira 2.0 runtime. Just copy it to your lumira documents folder.

LUMX-File

If you want to upload the lumx-file to your BIP, please keep in mind to change the following:

GS_TILES->calcTile looks like:

I_TILE.as(ComponentType.LUM_C88EE0E557C0A60833590B6DAD6626FA_KPI_TILE).setValues(Convert.floatToStringUsingLocale(actual_value.value / scaling_factor,number_decimal_places), description, unit, delta, deltaValue , time, I_KPI, valueCondFormat, details, deltacolor,xxl_text);

“LUM_C88EE0E557C0A60833590B6DAD6626FA_KPI_TILE” is generated by Lumira Designer so you have to change it. Please use content assistant to find the right one (should be begin with LUM*).

Same in GS_TILES-> calcAllTiles. Replace all occurrences of “LUM_C88EE0E557C0A60833590B6DAD6626FA_KPI_TILE” with your new Tile-ID.

There are a few more places where the ID schould be replaced:

  • GS_SEARCH–> select
  • ICON_HOME_TILE_1_DELETE – ICON_HOME_TILE_9_DELETE -> onClick
  • TIMER_SEARCH -> onTime

In 2.0 SP2 PL1 it looks like there is an issue with composites as type in input paramaters of functions so I decided to use generic type “component” and cast it to the right type via “as”.

 

To report this post you need to login first.

13 Comments

You must be Logged on to comment or reply to a post.

  1. Brian Kudera

    This is AWESOME!!! Very nicely done! This meets 99.9% of our requirements for what we would need in a dashboard. The only remaining piece is to be able to set alerts on the KPI’s to proactively be notified when something is out of threshold rather than having to review the dashboard every hour/day etc. (Have you ever seen this type of capability added in a lumira document?)

    (1) 
    1. Michael Jung Post author

      mmh… in the previous bw-based solution i stored the favorites in a dso (custom planning function). so in this case you have the information about user and relevant kpi in bw. But there is something missing, the thresholds. With bpc or bi-ip you can also enable your users to maintain the thresholds in a crosstab. You can run a report every hour in background for executing query-result and check whether a threshold was exceeded. as the result you can send an email to the corresponding user with the link to the dashboard.

      (2) 
  2. Dror Golani

    Dear Michael

    The Dashboard look absolutely fantastic

    Can you please tell me how long did it take you to build it, assuming you have all data ready in BW?

    Thanks,

    Dror G

    (1) 
    1. Michael Jung Post author

      Hi Dror,

      difficult to say, because I’ve developed the dashboard over the last few years. I started only with some value-tiles created using Design Studio 1.4.

      Much work was the data model in BW (transactional data and especially masterdata). Then i devoloped a solution for the startpage, with integrated planning to store the favorites in BW (custom planning function).

      The final dashboard in the internal bw-based solution has more than 70 datasources, 250 KPIs and approx. 3500 components.

      Now i come back to your question: if you know what you want and you know how it works you need only few days if the data is well prepared. For the downloadable demo I spent about 10 days. You see, the effort with Lumira 2.0 is significantly lower.

      Best regards,

      Michael

      (1) 
  3. Peter Scheffelt

     

    Great Dashboard! and hard work from Micha,  I know how many hours/ days micha invested from the early begining in this dashboard, lumira 2.0 looks a bit like design Studio

    (1) 

Leave a Reply