In den ursprünglichen SAC Stories (Classic Experience) gab es eine Vielzahl an no-code Funktionen die interaktive Dashboards ermöglichten. Seit der Zusammenführung von Stories und Applications können viele Anwendungsfälle mit Script oder aber auch weiterhin mit no-code Funktionen umgesetzt werden. Doch welche Unterschiede ergeben sich, wann stoßen die no-code Funktionen an Ihre Grenzen und für wenn sind diese interessant?
Schauen wir uns zuerst an welche no-code Funktionen es im Allgemeinen gibt. Dabei beziehen wir uns immer auf Funktionen, die dem User eine Interaktion ermöglichen. Das Setzen von Standardwerten bei Eingabevariablen, dynamischen Text und ähnliche Funktionen lassen wir außen vor.
o Filterwerte
o Dimensionen
o Kennzahlen
Grundsätzlich können die meisten Funktionen auch mit Script-Befehlen umgesetzt werden, welche über ein onClick Event auf verschiedenen Widgets wie Buttons, Checkboxgroups, Dropdownfeldern und anderen ausgelöst werden.
Storyfilter sind nicht an ein Widget gebunden, sondern filtern eine Datasource auf allen Seiten der Story. Via linked Dimensions ist es ebenfalls möglich mehrere Datasources miteinander zu verknüpfen. Die Handhabung ist ähnlich zu Eingabefiltern, allerdings sind Storyfilter weniger dynamisch und fest in der Filterleiste platziert.
Story Filter in der SAP Analytic Cloud
Grundsätzlich können alle Filterfunktionen auch mit einem eigenem Script nachgebaut werden. Allerdings unterliegen Storyfilter einigen Besonderheiten, sodass ein eigenes Script nicht das gleiche look&feel bietet und zusätzlich sehr aufwendig wäre. Gerade bei Stories mit vielen Datenquellen und Seiten glänzen Storyfilter mit ihrer Bedien- und Konfigurationsfreundlichkeit.
Eingabefilter wirken für viele Nutzer erstmal wie Storyfilter. Sie sehen ähnlich aus, beziehen sich auf eine Datasource und unterstützen Linked Dimensions. Allerdings lassen sie sich frei platzieren, optisch anderes gestalten und in Stories 2.0 kann ein Scriptevent direkt an den Filter gesetzt werden. Der größte technische Unterschied ist allerdings, dass die Abhängigkeiten zu anderen Widgets frei konfigurierbar sind. Zu Beginn der Konfiguration wird eine Datasource als Quelle angegeben und initial wirken sich Eingabefilter auf alle Widgets mit der gleichen Datasource aus. Über Linked Dimension können allerdings mehrere Datesources verbunden werden, sofern es in den Merkmalen passende Übereinstimmungen gibt. Der Clou ist aber das Konfigurationsmenu beziehungsweise die Diagrammansicht, die es ermöglichen beziehungen zwischen Eingabefiltern undeinander und zu Charts im Detail festzulegen.
Inputcontrol wirkt sich nur auf einen Teil der Charts aus
Diese out-of-the-box Funktion mit eigenem Script umzusetzen ist nicht unmöglich, allerdings wäre der Aufwand für die Entwicklung, Wartung und vor allem Anpassung beim Einfügen neuer Charts kaum zu vertreten. Es lohnt sich daher auch in Stories 2.0, den no-code Standard für Eingabefilter zu nutzen. Dennoch ermöglicht das spezifische ScriptEvent beim Filter die Implementierung komplexerer Interaktionen und Logiken. Beispielsweise können bei der Auswahl bestimmter Merkmalswerte die Darstellung angepasst, zusätzliche Charts angezeigt oder Daten im Hintergrund aktualisiert werden.
Versteckt in den Chart- und Tabelleneinstellungen unter Dimensionen beziehungsweise Kennzahlen können ebenfalls Eingabefilter konfiguriert werden. Mit zwei bis drei Klicks hat man so eine interaktive Option geschaffen, um verschiedene Sachverhalte in einem Chart oder einer Tabelle ein- und ausblenden zu können.
Dimensions-Eingabefilter in einer Tabelle
Natürlich lässt sich dies auch mit einem Dropdown und eigenem Script realisieren. An dieser Stelle gibt es keine klare Empfehlung, denn ob die no-code Lösung ausreichend ist, hängt vom Sachverhalt ab. Der Eingabefilter ist für mehrere Charts und Tabellen wiederverwendbar und lässt sich auch mit einem festen Dimensions- oder Kennzahlenaufriss kombinieren. Allerdings bietet er einige Einschränkungen.
Sobald eine Mehrfachauswahl, vor allem mit einer vom User bestimmten Reihenfolge, benötigt wird, kann hier auf ein eigenes Script nicht mehr verzichtet werden. Aber auch unterschiedliche Anzeigeeinstellungen können schon ein Grund sein, dem no-code Ansatz den Rücken zu kehren.
Grundsätzlich verfügt jedes Widget in der SAP Analytics Cloud über eigene Aktionen, die zur Laufzeit über das Kontextmenu abgerufen werden können. An dieser Stelle beziehen wir uns lediglich auf Widgets mit Datenbezug wie Tabellen und Charts, da diese die interessantesten Aktionen besitzen. So können Nutzer zum Beispiel die Sortierung ändern, sich nur die Top- oder Flop-N-Treffer anzeigen lassen oder Rankings erstellen. Ebenfalls können Filter direkt auf das Widget gesetzt oder bei Hierarchien ein Drilldown oder -up vollzogen werden.
Menu zur Konfiguration der Chartaktionen
Chartinteraktionen machen Widgets dynamisch und geben dem Nutzer viele Möglichkeiten, die Story zur Laufzeit seinen Informationsbedürfnissen anzupassen. Zeitgleich kann die Vielzahl an Optionen den Nutzer auch erschlagen und je nach Datenlage ist nicht jede Option sinnvoll. Glücklicherweise kann bei der Erstellung der Story für jedes Widget einzeln festgelegt werden, welche Aktionen es bieten soll. Je nach Story Design, kann es trotzdem zu Problemen für den Nutzer kommen. Bei einem zu minimalistischen Chart und Tabellendesign kann es passieren, dass der User nicht mehr erkennen kann, welche Aktionen er ausgeführt. Ebenfalls können sich Seiten-, Eingabe- und Chartfilter widersprechen, sodass keine Daten angezeigt werden.
Grundsätzlich lassen sich alle Aktionen auch über selbst erstelltes Script steuern. Auch hier macht es je nach Sachverhalt Sinn, auf die no-code Features zu verzichten und die Funktion gezielt über das BIAL-Script selbst zu gestalten. Zum Beispiel könnten sehr gezielte Aktionen, wie der Wechsel zwischen bestimmten Hierarchieebenen oder eine Kombination aus Filter- und Merkmalswechsel, um einen Drilldown zu simulieren, umgesetzt werden.
Hier ist der Name Programm. Widgets können miteinander verbunden werden und eine ausgeführte Aktion auf einem Widget gilt – sofern möglich – für alle verlinkten Widgets. Das wohl bekannteste Beispiel hierfür sind Filter, die direkt auf ein Chart gesetzt werden. Chart A enthält die Umsätze nach Ländern und Chart B die Absatzmengen. Sofern Chart A auf ein bestimmtes Produkt gefiltert wird, gilt dieser Filter auch automatisch für Chart B.
Abhängigkeiten zwischen Charts mit Linked Widgets definieren
Für die meisten Szenarien ist die no-code Funktion völlig ausreichend. Natürlich lassen sich über Script spezielle Szenarien abbilden, die unterschiedliche Abhängigkeiten berücksichtigen, und entsprechen dann pro Chart individuell. reagieren. Allerdings kann dies den Nutzer auch überfordern, sofern nicht mehr nachvollziehbar ist, warum sich mehrere Charts unterschiedlich anpassen.
Hinter URL / Storyabsprüngen verbirgt sich mehr als man denkt. URL-Absprünge sind im no-code Bereich recht überschaubar, allerdings sind Storyabsprünge innerhalb der SAC mit Filterübergabe möglich und dies ohne eine Zeile Code zu schreiben. Dabei gibt es die Möglichkeit, Storyfilter an eine andere Story zu übertragen, aber auch die Selektion im einem Chart kann als Filterparameter beim Absprung übergeben werden. Zudem kann auch bestimmt werden, zu welcher Seite einer Story navigiert werden soll.
Hyperlink Konfiguration eines Chart-Widgets mit Dimensionsübergabe
Für spezielle Szenarien oder falls URL-Variablen übergeben werden müssen, kann auch hier natürlich wieder mit Script die Lücke zum no-code Ansatz geschlossen werden. Übrigens sind URL-Variablen nicht nur für externe Seiten interessant, sondern können auch in SAC-Stories verwendet werden, um bestimmte Einstellungen im onInitialisation-Event auszuführen.
Durch die höhere Zugänglichkeit und verbesserte Benutzerführung in vielen FrontEnd Tools hat sich in de letzten Jahren ein Teil der Entwicklung von der IT zum Fachbereich verschoben. Im sogenannten Selfservice können kleinere Entwicklungen unkompliziert vom Fachbereich durchgeführt werden. Durch die praktische no-code Funktionen werden keine tieferen Script Kentnisse benötigt, um dynamische und interaktive Stories zu erstellen. Die Vorteile im Selfservice liegen klar auf der Hand:
Sind die no-code Funktionen auch für Entwickler außerhalb des Selfservices sinnvoll? Diese Frage kann mit einem klaren „Ja“ beantwortet werden. Die no-code Funktionen bieten einen soliden Grundstein und kaum Aufwand bei der Wartung. Zudem spricht nichts dagegen, einen Teil der no-code Funktionen zu nutzen und bestimmte Anforderungen mittels Script umzusetzen. Je nach Szenario kann es auch sinnvoll sein, die no-code Funktion mit Script zu erweitern. Viele no-code Funktionen können über das Script angesprochen werden, Eingabefilter haben sogar ein eigenes Scriptevent, so sind die Möglichkeiten fast grenzenlos.
|
Funktion |
No-code |
Script |
Kombiniert |
|
Storyfilter |
|
|
|
|
Eingabe Filter |
|
|
|
|
Dimensions- und Kennzahleneingabefilter |
|
|
|
|
Chartinteraktionen |
|
|
|
|
URL-Storyabsprünge |
|
|
|
Haben Sie Fragen zur SAP Analytics Cloud oder anderen Themen? Versuchen Sie das nötige Know-How in Ihrer Abteilung aufzubauen oder benötigen Sie Unterstützung bei einer konkreten Fragestellung? Nehmen Sie einfach Kontakt zu uns auf - wir freuen uns auf den Austausch mit Ihnen!