Vor einiger Zeit haben wir ein SAC KPI Tile Dashboard innerhalb der Analytic Applications umgesetzt. Mittlerweile spielen Applikationen in der SAP Analytics Cloud keine Rolle mehr und wurden vollständig von Stories ersetzt. Trotz leicht geänderter Menüs und Funktionen lässt sich das damals vorgestellte KPI Tile Dashboard problemlos in einer Story umsetzen.
Auch wenn die damals vorgestellte Lösung sehr variabel anpassbar war, gab es einen kleinen Haken. Für die Befüllung der Kacheln konnten nur KPIs aus einer Datenquelle verwendet werden.
In diesem Blogartikel erläutern wir, wie man ein großes KPI Board mit über 50 KPI Kacheln, die teilweise aus verschiedenen Quellen stammen, umsetzen könnte und welche Einschränkungen es dabei gibt.
SAC Tile Story
Auch wenn wir meistens argumentieren, dass der Best-Practice-Ansatz für Dashboarding maximal fünf bis acht verschiedene KPIs enthält, gibt es Szenarien, in denen ein großes KPI Board sinnvoll ist. Zum Beispiel als zentrale Landing-Page, um von dieser auf verschiedene Detail-Storys abzuspringen – ähnlich dem Ansatz der Overview Pages im S/4HANA Fiori Launchpad, die einen schnellen Überblick über relevante Kennzahlen bieten und als Einstiegspunkt für weiterführende Analysen dienen.
Durch die Umsetzung mit vielen kleinen Kacheln bietet es natürlich an, die Story auch auf Endgeräten mit kleineren Bildschirmen wie Tablet oder Smartphone zu konsumieren. Dies wurde natürlich bei der Entwicklung berücksichtigt und die Anzahl der Tiles die nebeneinander angezeigt werden, passt sich immer dem Bildschirm an.
KPI Tile Story auf Smartphone und Tablet
Die zentralen Bausteine der KPI Tile Story
Für unsere Story bedienen wir uns vorgefertigter Kacheln, die auf Wunsch ein- oder ausgeblendet werden können. Doch was sind KPI Kacheln eigentlich? Im Allgemeinen sind dies Widgets, welche Kennzahlen eventuell mit Dimensionen, Abweichungen oder Schwellenwerten darstellen. So gesehen das ganz normale Chart-Widget der SAC, komprimiert auf das Wichtigste, was mit einem Blick erfasst werden kann. Dies trifft in unserem Fall zwar zu, allerdings hängt die technische Umsetzung unserer Story an dem Panel-Widget. Somit spielt es keine Rolle was innerhalb des Panels liegt, neben dem Chart-Widget, könnten dies auch Custom Widgets, eingebettete Webelemente via iFrames, Bilder oder Absprünge zu anderen Stories sein. Natürlich lassen sich die verschiedenen Elemente auch kombinieren, allerdings ist aufgrund der Größe und Anzahl der Kacheln oft die Devise “weniger ist mehr”.
Aufbau einer KPI Kachel
Für eine ansprechende Kachel-Optik nutzen wir einige Tricks. Jede Kachel besteht aus einem Haupt-Panel (PA_001), einem inneren Panel (PA_BODY_001) und dem tatsächlichen Inhalt (CH_01).
- Haupt-Panel - wird in der Story ein- und ausblendet sämtliche Skript bezieht sich immer auf das Haupt-Panel
- Inneres-Panel - erzeugt die Kacheloptik, da innerhalb des Flow-Layout-Panels keine Abstände zwischen den Objekten erzeugt werden können
- Tatsächlicher Inhalt - durch den Ersteller definierter Inhalt, wie zum Beispiel ein Balkenchart
Die Umsetzung ist recht einfach, aber enthält auch die Einschränkung, dass die Reihenfolge der Kacheln nicht frei bestimmt werden kann, sondern immer einer vorgegebenen Struktur folgt.
Die wichtigsten Elemente des KPI Boards sind:
- Flow-Layout-Panel mit vorgefertigten Kacheln
- SAC Datenmodel mit einer Public-Dimension
- Input-Control zur Steuerung der Kacheln
- ScriptObjekte zur Steuerung der Kacheln
- Bookmarkfunktion
Umsetzung in der SAC Story
Grundsätzlich spielt das gewählte Story Layout (Canvas oder Flexible) keine Rolle, da wir ein Flow-Layout-Panel als Hauptcontainer nutzen. Lediglich der Header und das seitliche Filtermenü liegen außerhalb des Flow-Layout-Panels. Das Flow-Layout-Panel hat folgende Vor- und Nachteile:
Vorteile |
Nachteile |
|
|
|
|
|
Outline der KPI Tile Story
Die Unterteilung in Bereiche erhöht die Übersicht für die Nutzer. Durch den Einsatz des Input-Control Widgets zur KPI Konfiguration, gibt es eine KPI Suche “out-of-the-box”. Dies erhöht den Komfort deutlich, vor allem je mehr KPI Kacheln in der Story verbaut werden. Zusätzlich ermöglicht die versteckte Nutzung von Bookmarks die Individualisierung der Story. Immer wenn der Nutzer die KPI Konfiguration verändert, wird ein Default Bookmark erstellt, somit startet die Story das nächste Mal nur noch mit der Wunschkonfiguration des Nutzers, anstatt alle KPIs zu laden.
Dashboarding mit SAP Analytics Cloud -
Laden Sie hier das Whitepaper herunter!
Umsetzung der KPI Steuerung im Backend
Um die KPI Kacheln über ein Input-Control ein- und ausblenden zu können, brauchen wir eine zentrale Steuerungsdatenquelle. Sie muss so aufgebaut sein, dass Daten darin einfach geändert, hinzugefügt oder entfernt werden können, um die KPIs dynamisch zu verwalten. Dies kann über eine Query aus dem Business Warehouse erfolgen, die als Grundlage ein aDSO nutzt, welches via NextTables gepflegt wird. Alternativ kann auch ein Datenmodel mit einer PublicDimension in der SAC erstellt werden.
Public Dimension zur Konfiguration der Tiles
In unserem Fall ist das Datenmodel bewusst etwas großzügiger ausgelegt. Zum einen wollten wir ermöglichen, dass zu jeder KPI Kachel zusätzliche Informationen zur Verfügung stehen. Diese umfassen Angaben wie Quellsystem, Query oder Datenmodell und eine Beschreibung der verwendeten Kennzahl. Zum anderen ist das Datenmodell nicht an eine Story gebunden, sondern eine zentrale Pflegestelle für alle KPI Tile Stories.
Leider können Public Dimensions nicht direkt in der Story als Datenquelle verwendet werden, daher muss noch ein Datenmodell als “Dummy” angelegt werden. Dieses enthält lediglich die Public Dimension und eine Kennzahl um diese Einschränkung in der SAC zu umgehen und wird als Quelle für das InputControl genutzt.
Umsetzung der KPI Steuerung im Scripting
Nachdem KPI Kacheln in der Story angelegt und die Public Dimension mit Informationen gefüllt wurde, geht es zum letzten technischen Abschnitt. Das InputControl filtert grundsätzlich nur Daten in anderen Widgets. Für unseren Fall müssen wir via Scripting einen Zusammenhang zwischen unseren Kacheln und den Filterwerten des InputControls erstellen.
An der Stelle gibt es verschiedene Möglichkeiten, das Script auszuführen. Je nachdem, wie man die Konfiguration und die Nutzung der Bookmarks gestalten will, eignen sich die unterschiedlichen Ansätze mal mehr mal weniger. Grundsätzlich gilt aber immer der folgende Prozess:
Wir haben im Hintergrund eine Tabelle, die durch das Input-Control gesteuert wird. Das Script wird allerdings nur beim Auslösen des “onResultChanged” Triggers der Tabelle ausgeführt.
In unserem Fall werden mehrere Skripte ausgeführt:
Das temporäre Ausblenden des Flow-Panel-Layouts (FLP_BODY) während der Ausführung lässt den Prozess geschmeidiger aussehen. Sofern alle Kacheln in einem Bereich ausgeblendet werden, wird die Bereichsüberschrift ebenfalls ausgeblendet. Auch wird das Default Bookmark erstellt und gesetzt. Das Herzstück sind allerdings die beiden Skripte hideTiles() und showTiles().
Mit hideTiles() werden alle relevanten Kacheln ausgeblendet, auch wenn Kacheln nachträglich in der Story erstellt worden sind.
Nachdem alle Kacheln ausgeblendet wurden, blenden wir die neue Selektion mit showTiles() ein.
Um das Typ-Problem zwischen Input-Control Eintrag und tatsächlichem Panel zu umgehen, nutzen wir Applications.getWidgets. Grundsätzlich reicht dieses Skript aus, um die KPI Steuerung zu realisieren. Wir haben noch ein paar weitere Extras, wie eine InfoBox zu allen KPIs oder den Absprung zur jeweiligen Detail Story eingebaut, allerdings würde das den Rahmen dieses Blogbeitrages sprengen.
Ausblick und setModel Befehl
Bei näherer Betrachtung zwischen der damaligen KPI Kachel Applikation und der hier vorgestellten KPI Story fällt auf, dass beide Ansätze grundsätzlich die gleichen Ergebnisse liefern, allerdings mit unterschiedlichen Einschränkungen.
Die scheinbar optimale Lösung wäre eine Story, in der jede Kachel individuell konfigurierbar ist. Das bedeutet, dass der Nutzer sich Modell, Kennzahlen, Dimensionen und Charttyp selbst aussuchen kann.
Mit dem Q4.2024 Update sind wir dieser Lösung einen großen Schritt näher gekommen, da der .setModel Befehl für Charts eingeführt wurde. Damit kann via Skripting das Model ausgetauscht werden. Kennzahlen und Dimensionen können schon seit langer Zeit via Script platziert werden. Lediglich die Änderung des Charts fehlt noch in den API Befehlen.
Obwohl diese Funktionalität von einigen Entwicklern gewünscht wird, ist es in der Praxis oft nicht sinnvoll, den Charttyp flexibel ändern zu können. Eine Anpassung des Charttyps erfordert in der Regel auch Änderungen an weiteren Chart- und Layout-Einstellungen, um eine sinnvolle und aussagekräftige Darstellung sicherzustellen. Diese zusätzlichen Konfigurationen könnten den Anwender überfordern und würden zudem die Grenze zwischen einer individualisierbaren Story und Self-Service verwischen.
Daher bevorzugen Anwender meist die Flexibilität von KPI Boards mit vordefinierten, sinnvoll gestalteten KPI Kacheln. Eine Alternative wäre es, einzelne KPIs gezielt mit unterschiedlichen, durchdachten Charttypen anzubieten, um verschiedene Perspektiven zu ermöglichen.
Wir bleiben gespannt, ob sich die SAP zu dieser API Anpassung hinreißen lässt…
Sie haben Fragen zur SAP Analytics Cloud oder einem anderen Thema? Nehmen Sie einfach Kontakt zu uns auf - wir freuen uns auf den Austausch mit Ihnen!
SAP Analytics Cloud, Dashboarding
