Stories über Stories? Ohne jegliche Struktur und Ordnung? Wenn Sie sich selbst in diesen Fragen wiederfinden, sind Sie auf dieser Seite bestimmt richtig! In diesem Blog-Beitrag erfahren Sie, welche Möglichkeiten Ihnen der SAP Digital Boardroom als Komponente des bereits umfangreichen und stets wachsenden Reportingtools SAP Analytics Cloud bietet, um eine Vielzahl von Story-Seiten strukturiert zu präsentieren.

Sie sind Entscheider und haben es daher eilig? Dann erhalten Sie im ersten Absatz kurz und bündig alle wesentlichen Informationen zum SAP Digital Boardroom. Wenn Sie jedoch herausfinden wollen, wie genau die Zusatzkomponente Ihre Entscheidungen unterstützen kann, laden wir Sie zum Weiterlesen ein.


Für eilige Leser:

Zusammengefasst bietet die Anwendung „SAP Digital Boardroom“ im Rahmen der SAP Analytics Cloud die Präsentation und Konsolidierung verschiedener (Story-)Dashboards als zentrales Management-Cockpit. Ausgewählte Seiten verschiedener Storys können innerhalb einer erstellten Anwendung strukturiert und entlang einer vorab erstellten Agenda betrachtet werden, ohne jede Story einzeln zu suchen, aufzurufen und zu laden. Die Zielgruppen der erstellten Anwendungen reichen vom Vorstand über das Management bis hin zu Entscheidungsgremien– sprich für jede Person, welche die Betrachtung mehrere Stories interessiert. Vorteile von SAP Digital Boardroom-Anwendungen liegen sowohl in der optimierten Ansicht auf großen Bildschirmen, einer vereinfachten Bedienung der Filter und Einstellungen als auch in der Strukturierung mit den Agenda-Tools.

Dashboard-Modus: Bringen Sie relevante Stories sinnstiftend zusammen

Der Dashboard-Modus bietet eine Buchstruktur, in welcher nach Themen (analog wie Buchkapitel) geclustert die verschiedenen Story-Seiten platziert werden können. Beispielsweise umfasst das Kapitel Human Resource die drei Story-Seiten Context, Salaries und Diversity (siehe Screenshot). Diese Seiten können in der Präsentationsansicht dann betrachtet und durchgeschaltet werden. Im Steuerelemente-Panel kann auch direkt eine Story-Seite ausgewählt werden oder in ein Thema gesprungen werden. Die Aktionsleiste bietet weitere Einstellmöglichkeiten, eine Such- und Favoriten-Funktion sowie das Anheften der Leiste und das Verlassen der Boardroom-Ansicht in das Dateimenü der SAP Analytics Cloud. Die Präsentationsschicht enthält die eigentliche Story-Seite, oben von einer Kopfzeile und unten mit einer Fußzeile eingefasst, in welcher beispielsweise ein Unternehmenslogo eingebettet werden kann.



Steuerung der Präsentation mit dem Multitool

Mit einem Rechtsklick öffnet sich ein „Multitool“ (siehe Screenshot). Mit diesem können Sie eine Suche starten, Filter für Story-Seiten bis hin zum gesamten Boardroom setzen, in andere Story-Seite springen, in den gezeigten Daten weitere Untersuchungen starten sowie weitere Einstellungen vornehmen.

Agenda-Modus: Bereiten Sie Ihre Berichtstermine effizient vor

Vor der Erstellung einer SAP Digital Boardroom-Anwendung ist allerdings eine wichtige Entscheidung zu treffen: Soll eine wie oben beschriebene „Buch-Präsentation“ von Story-Seiten oder ein gezielt strukturierter Termin mit einer Agenda vorbereitet werden?

Wenn Ihre Antwort auf Letzteres fällt, bietet auch hier der SAP Digital Boardroom Optionen. Im Agenda-Modus wird eine Reihenfolge von Themen erstellt, in welche jeweils einzelne Story-Seiten, aber auch Unterthemen verknüpft werden können. Wie dies in der Erstellungsansicht aussieht, zeigt der Screenshot. Sowohl im Dashboard- als auch im Agenda-Modus importieren Sie Stories in Ihre Boardroom-Anwendung. Ihre Boardroom-Präsentation zeigt die aktuelle Version der Story, sodass sowohl Aktualisierungen der Daten als auch von Grafiken, Texten, Farben und Diagrammen automatisch in den Digital Boardroom synchronisiert werden. Auch können neben dem Setzen von Filtern während der Präsentation mit dem Multitool bereits während der Anwendungserstellung Filter eingerichtet werden, sodass die Story-Seite sofort die gefilterten Diagramme und Tabellen darstellt.

Die erstellte Agenda bietet nun die Möglichkeit, die Story-Seiten als eine Präsentation vorführen zu können und ausgehend von der Agenda in der gewählten Reihenfolge die Themen zu präsentieren. In der geöffneten Story kann wieder analog zum Dashboard-Modus beispielsweise mit dem Multitool gesucht oder gefiltert werden.

Welche Voraussetzungen sind zu treffen und zu beachten?

Da der Digital Boardroom ein Zusatzmodul der SAP Analytics Cloud ist, sind vorhandene Lizenzen für ebendiese eine Voraussetzung, um den Digital Boardroom dazuzubuchen. Wichtig für die Einrichtung eines Digital Boardrooms ist, dass nur Story-Seiten des Typs „Responsive“ oder „Canvas“ in den Boardroom-Designer importiert werden können. Für Analytic Applications ist dies nach dem derzeitigen Stand aufgrund der deutlich individuelleren Anpassbarkeit der Anwendungen ebenfalls nicht möglich. Die an die SAP zu entrichteten Lizenzkosten betragen eine monatliche Pauschale von 4.000 € (https://www.sapstore.com/solutions/40120/SAP-Digital-Boardroom; Stand 13.01.2022), unabhängig der Anzahl der erstellten Anwendungen oder nutzenden Personen.

Mögliche Use Cases des Digital Boardrooms

Einsatzmöglichkeiten des SAP Digital Boardrooms bieten sich vor allem dann, wenn Abteilungen, Bereiche oder Personen an die übergeordnete Stelle oder eine Stabsstelle berichten und ihre Ergebnisse in Storys festhalten. So kann beispielsweise die Performance zu den verschiedenen Anwendungen in der IT-Abteilung Ihres Unternehmens auf Basis einer Story berichtet werden. Zum wöchentlichen Performance-Meeting können dann live die Ergebnisse in den Storys via SAP Digital Boardroom betrachtet und ausgewertet werden, sodass der Vorbereitungsaufwand für dieses Meeting gegen null geht. Es muss lediglich einmal der Boardroom eingerichtet und ggf. bei Änderungen wie dem Hinzukommen einer IT-Anwendung und damit auch neuer Story-Seiten angepasst werden. Ebenso ist vorstellbar, dass der Status von Projekten im Rahmen eines Programms oder Projektportfolios mit einem Digital Boardroom berichtet werden kann. SAP Analytics Cloud verfügt in Stories über weitere Stärken hinsichtlich der Gestaltung von Grafiken und Texten, sodass auch Kommentierungen und beispielsweise die beliebten „Ampel“-Grafiken gezeigt werden können. Zusätzlich bietet sich hier die Möglichkeit, durch das Filtern die Veränderungen zwischen den einzelnen Berichtsperioden zu analysieren und somit Trends erkennbar zu machen.

Zusammenfassung

Lohnt sich nun der SAP Digital Boardroom für Sie? Die Antwort ist wie immer: „Es kommt darauf an.“ Wenn Ihre KPI-Berichte bereits eine hohe Vergleichbarkeit hinsichtlich Kennzahlen und Dimensionen aufweisen und ihr Unternehmen, ihre Projekte oder ihre Bereiche die Performance nahezu allesamt in Story-Seiten darstellen können, empfehlen wir den Einsatz des SAP Digital Boardrooms. Dafür liegt der wesentliche Grund in einem übersichtlichen, strukturierten und zugleich funktionell hoch anpassbarem Gesamt-Reporting, sodass Sie keine regelmäßige Erstellung von Power Point Präsentationen zu forcieren brauchen.

Über den Autor

Christoph Ochs betreut und berät als Consultant Kunden mit dem Schwerpunkt Projektmanagement, aber auch in der Frontend-Entwicklung. Er studierte Wirtschaftsingenieurwesen mit den Schwerpunkten Projektmanagement und Wirtschaftsinformatik.

Christoph Ochs gehört zum Team Reporting & Analytics.

In dem fünften Beitrag unserer Qlik-Reihe geht es um das performante Verarbeiten von Daten in Qlik durch Aggregieren, Joinen und Parallelisieren.

Alle Daten sind angebunden, das Skript läuft ohne Fehler, das Qlik-Dashboard ist fertig. Um aktuelle Daten in das Dashboard zu laden, wird der Reload-Knopf gedrückt und jetzt läuft der Task und läuft und läuft und läuft… . Um diese Situation zu vermeiden, sollte bereits bei der Erstellung des Qlik-Skripts darauf geachtet werden, die Verarbeitung der Daten möglichst performant zu gestalten.

In der Datenverarbeitung sind die Qlik-Prozesse, welche viel Zeit in Anspruch nehmen, häufig Schleifen oder Aggregierungen oder Joins großer Datensätze. Doch „For/while-Schleifen“ sollten überall vermieden werden, wo es möglich ist.

Performantes Aggregieren

Bei Aggregierungen mit der Verwendung group by kann es von Vorteil sein, die Datensätze vorher nach der Dimension zu sortieren, auf die aggregiert wird.


Vor allem bei mehreren Dimensionen kann zu deutlichen Verbesserungen in der Performance führen.


Sobald eine große Tabelle nach mehreren Dimensionen aggregiert wird, ist es schneller, zunächst ein Schlüsselfeld aus diesen Dimensionen zu bilden, dann nur auf den Schlüssel zu aggregieren und später die Dimensionen wieder hinzuzunehmen. Die Funktion Autonumber() eignet sich hierfür besonders gut, weil sie einen zusammengesetzten Schlüssel mit numerischen Werten bildet und daher dieser Schlüssel schneller von Qlik verarbeitet werden kann.

Die Aggregierung selbst läuft hier jetzt lediglich noch über ein nummerisches Schlüsselfeld. Bei großen Datensätzen ist dieser Weg performanter, obwohl zusätzlich der Schlüssel erst gebildet werden muss und die Felder später per Left Join angehängt werden müssen.

Performantes Joinen

Auch ein Join kann die Ladegeschwindigkeit des Skripts deutlich ausbremsen. Muss nur ein Feld hinzugefügt werden, ist ein ApplyMap() wie hier links dargestellt schneller als ein Left Join wie unten dargestellt. Bei mehreren Feldern wiederum wäre ein Left Join schneller.

Parallelisierungen

Die Optimierung innerhalb des Skripts klappt nicht immer. Manchmal sind langsame Berechnungen einfach notwendig und es gibt keine Möglichkeit, diese durch eine schnellere Alternative zu ersetzen. Hier kommt eine weitere gute Option ins Spiel, um viel Zeit im Skript einzusparen: Parallelisierungen. Teile der Datenverarbeitung können manchmal ausgelagert werden und laufen dann parallel.

Beispielsweise könnte ein größerer Join oder eine Aggregierung in ein separates Skript geschrieben werden und diese könnte dann parallel zu anderen unabhängigen Datenverarbeitungen laufen. Das Skript speichert das Ergebnis in eine QVD und diese QVD kann im anderen Skript wieder optimiert eingelesen werden.

Nachfolgendes Beispiel zeigt ein Datenmodell, in dem lokale Umsatzdaten aus verschiedenen Verkaufsstandorten weltweit zu einer Tabelle mit vergleichbaren Werten in Währung EUR umgewandelt wird, die mit Informationen zum Standort angereichert wird.



Anstatt alle Datenverarbeitungsschritte in einem Datenmodell-Skript durchzuführen, wurden hier zwei Skripte verwendet, die dann parallel über zwei verschiedene Tasks laufen können und dadurch die finale Tabelle schneller zur Verfügung stellen können.
Datenmodell 1 nimmt das Datum und den Umsatz aus der lokalen Sales-Tabelle und führt mit einer Wechselkurs-Tabelle eine Währungsumrechnung durch. Die Euro-Umsätze werden dann abgespeichert. Währenddessen hat Datenmodell 2 zu den Verkaufsstandorten weitere Informationen gesammelt. Hier werden mehrere Joins durchgeführt und daher hat Datenmodell 2 eine längere Laufzeit als Datenmodell 1. In Datenmodell 2 kann daher dann direkt noch die fertige Euro-Sales Tabelle eingebunden werden.


Über die Autorin

Daniela Pohl berät und betreut als Senior Consultant Kunden im Bereich Reporting und Analytics. Ihr Schwerpunkt liegt dabei auf den Themen Frontendentwicklung und Konzeption.

Daniela Pohl gehört zum Team Reporting & Analytics.

Um eine performante Ladekette für eine Qlik-Applikationen zu erhalten, kann das Augenmerk gleich an den Anfang gelegt werden: An die Anbindung der Daten und das Einlesen nach Qlik. Daten werden generell am schnellsten aus QVDs geladen, dem Qlik-eigenen Datenformat. Hier wird zwischen zwei Lademodi unterschieden, die Qlik jeweils automatisch verwendet: dem Standard Load und dem Optimized Load.

Qlik kann QVDs optimiert laden, wenn keine Umformungen oder Einschränkungen während des Ladevorgangs an den Daten vorgenommen werden. Ausnahmen dazu sind das Umbenennen von Feldern mittels AS und die „where exists“-Bedingung. Die einfache where-Bedingung im Ladestatement führt dazu, dass Qlik wieder im Standard-Modus lädt.

Wenn beispielsweise die Daten des aktuellen Jahres geladen werden sollen, würde

Daten:
Load
*
From Data.qvd
where Year = 2021;

nur die Standard-Ladegeschwindigkeit erreichen. Wohingegen das Laden der entsprechenden Jahreszahl in eine Hilfstabelle und die Abfrage mit „where exists“ einen „optimized load“ ermöglicht und das folgende Skript wesentlich schneller lädt:

Einschränkung_tmp:
Load * Inline [
Year
2021
];

Daten:
Load *
From Daten.qvd
where exists (Year);

Drop Table Einschränkung_tmp;

Bei einer notwendigen Umformung oder Berechnung von Daten während des Ladens sollte der Ladevorgang in zwei Stufen aufgeteilt werden. Statt einem

Daten:
Load
Netto_Sales * 1.19 as Brutto_Sales
From Data.qvd;

Ladestatement, welches lediglich in Standard-Geschwindigkeit eingelesen werden kann, sollte in solchen Fällen auf einen optimierten Ladevorgang gesetzt und anschließend die Umformung in einem Resident-Load durchgeführt werden:

Basisload:
Load
Netto_Sales
From Data.qvd;

NoConcatenate
Daten:
Load
Netto_Sales * 1.19 as Brutto_Sales
Resident Basisload;

Drop Table Basisload;

Obwohl die Tabelle in diesem Fall zweimal geladen wird, ist dieser Ausdruck besonders bei großen Datenmengen viel performanter als das vorherige Ladestatement.

Um das optimierte Laden von Qlik bestmöglich auszunutzen, empfiehlt es sich, QVD-Generatoren vorneweg einzubauen, die die Quelldaten abziehen und als QVD speichern. Diese QVDs kann das spätere Qlik-Skript schneller einlesen mit Hilfe des optimized load.

Sobald mehrere unterschiedliche Quellen oder unterschiedliche Tabellen aus einer Quelle abgezogen werden, können die Ladeskripte dafür in verschiedene, voneinander unabhängige QVD-Generatoren geschrieben werden. Diese QVD-Generatoren können dann gleichzeitig laufen und die Daten schnell als QVDs bereitstellen.




Über die Autorin

Daniela Pohl berät und betreut als Senior Consultant Kunden im Bereich Reporting und Analytics. Ihr Schwerpunkt liegt dabei auf den Themen Frontendentwicklung und Konzeption.

Daniela Pohl gehört zum Team Reporting & Analytics.

Auslagerung der Qlik-Skripte

Für jede Anpassung im Dateneditor einer Qlik Sense Applikation muss die App kopiert, das Skript angepasst und die gesamte App neu veröffentlicht werden. Für eine kleine Code-Änderung und ohne dass an den Visualisierungen irgendetwas gemacht wurde, ist dieser Prozess eher aufwändig.
Für diese Fälle kann das Skript aus der Applikation ausgelagert werden. Denn das Skript lässt sich ganz einfach in einem Textdokument speichern und durch den Befehl Must_Include als Datei im Dateneditor einbinden. Die Textdatei kann mit der Endung qvs gespeichert werden. Damit können Editoren den Text als Qlik-Code erkennen und entsprechend highlighten. Beispielsweise kann das Skript dann mit Notepad++ oder mit Visual Studio Code bearbeitet werden.


Im Qlik-Dateneditor sind dann nur noch der Befehl zum Einbinden sowie Pfad und Dateiname anzugeben:

So kann nun das Skript in der ausgelagerten Datei jederzeit angepasst werden, ohne dass die Qlik-Applikation verändert werden muss.
Ein weiterer Vorteil dieser Auslagerung ist, dass ein Skript für mehrere Apps verwendet werden kann und Änderungen immer nur an einer Stelle durchgeführt werden müssen. Die Applikationen beziehen diese Änderungen automatisch und müssen nicht alle einzeln manuell angepasst werden.

NEUESTE BEITRÄGE



Weitere Services:


Reporting & Analytics

Code-Versionierung

Bei größeren Projekten mit mehreren Qlik-Entwicklern ist es nun auch hilfreich, den Code zu versionieren. Dies ermöglicht es zu sehen, wer wann zuletzt welche Änderung durchgeführt hat. Zudem kann bei Problemen einfach auf den letzten funktionierenden Stand zurückgekehrt werden.

GIT bietet diese Versionsverwaltung kostenlos und als Open Source-Software. Wird der Pfad, auf dem die Skripte liegen, nun mit GIT verwaltet, dann kopiert sich jeder Entwickler den Ordner mit den Skripten und führt Änderungen immer nur in seinem Ordner durch.

Beispiel: In diesem Fall sind drei Entwickler Hannah, Stephen und Tom beteiligt, alle können parallel die Skripte in ihrem eigenen Ordner bearbeiten. Die produktiven Apps beziehen sich die Skripte aus dem master-Ordner, indem der Must_Include-Pfad um den master-Ordner erweitert wird:

$ (Must_Include=[lib://Qlik-Skripte/master/Datenmodell.qvs]);

Die eigenen Änderungen am Code können dann in einer Kopie der App getestet werden. Dafür muss lediglich der Pfad angepasst werden und auf den eigenen Ordner verweisen.


Nach erfolgreichem Test können die Änderungen mit GIT in den master-Ordner übernommen werden und die produktive App lädt beim nächsten Ladelauf automatisch das geänderte Skript.

Die Änderungen selbst werden auf sogenannten Branches durchgeführt. Auf einem Ordner ist immer ein Branch eingestellt, der master-Branch liegt dabei immer auf dem master-Ordner. So kann nun jederzeit nachvollzogen werden, welcher Entwickler wann was gemacht hat. Die Qlik-Skripte haben damit eine Versionierung und bei Problemen kann auf einen alten Stand zurückgegriffen werden.

In diesem Beispiel ist der master in rot dargestellt.
Zuerst hat Stephen einen neuen Branch erstellt (blau), um ein neues Feld im QVD-Generator einzufügen. Seine erste Änderung hat er direkt in den master überführt. Währenddessen hat Hannah eine Korrektur im Datenmodell durchgeführt (gelb) und dann hat Tom den Schlüssel für den Masterkalender geändert (grau). Anschließend hat Stephen einen weiteren Branch erstellt, um ein Problem mit doppelten Werten zu beheben (grün – noch nicht in den master übernommen), bevor er auf seinem ursprünglichen Branch (blau) weitergearbeitet hat.

Ein Entwickler kann mehrere Branches erstellen und dadurch an mehreren Stellen parallel und völlig unabhängig von einander arbeiten. Stephen hat gleichzeitig einen Branch für das neue Feld und einen für den Fix. Seinen Ordner kann er mit GIT umschalten.


Anwendungsfall: Self-Service

Das Prinzip eignet sich auch hervorragend im Rahmen von Self-Service-Projekten. Auf ihren eigenen Branches können die Fachbereiche selbst Änderungen durchführen und testen. Anschließend stellen sie Pull Requests, damit ihre Änderungen in den master übernommen werden. Hier kann dann eingestellt werden, dass bestimmte Qlik-Entwickler oder der Betrieb die Änderungen zunächst prüfen und genehmigen.



Über die Autorin

Daniela Pohl berät und betreut als Senior Consultant Kunden im Bereich Reporting und Analytics. Ihr Schwerpunkt liegt dabei auf den Themen Frontendentwicklung und Konzeption.

Daniela Pohl gehört zum Team Reporting & Analytics.




Qlik Sense bietet seinen Nutzern die Möglichkeit, Daten auf Dashboards zu visualisieren und alle Informationen im Blick zu haben. Dennoch wird oft unnötig Zeit damit verbraucht, die Qlik-Apps zu öffnen und festzustellen, dass sich die Datenlage zum vorhergehenden Datenlauf nicht geändert hat. Häufig wird nach Ausreißern gesucht oder es muss so schnell wie möglich reagiert werden, wenn irgendwo ein Grenzwert überschritten wird. Das erfordert ein Prüfen der Qlik-Apps. Niemand will seine Reports ständig im Blick haben müssen. Hier kommt das Konzept der Alerts ins Spiel.

Qlik Sense bietet E-Mail-Benachrichtigung auf Basis der Daten in den Apps. So entfällt das Prüfen der Reports. Qlik informiert automatisch, wenn eine individuell definierbare Auffälligkeit eintritt.

Solche E-Mail-Benachrichtigungen sind schon von Task-Abbrüchen bekannt, wo die Qlik-Management-Konsole bereits für QlikView und für Qlik Sense automatisiert den entsprechenden Qlik-Entwickler verständigt, sobald ein Fehler auftritt und die Daten nicht aktualisiert wurden.

Nun kann auch eine einzelne App diese Benachrichtigungen verschicken. Das Feature wird seit der Qlik Sense Version April 2020 angeboten.


In QlikView sind die Alarme noch in jedem QlikView-Dokument unter den Extras zu verwalten:

In der On Premise-Version von Qlik Sense wird dazu eine separate Installation der Qlik-Alert-Software auf einem eigenen Server benötigt, die während des Installationsvorgangs mit der Qlik Sense Installation verknüpft wird und sich automatisch sowohl die Qlik-Lizenz als auch die User Informationen der Qlik Sense Installation bezieht. Ein Qlik Sense Nutzer mit einer Professional Lizenz wird in den Qlik-Alerts eigene Alerts anlegen können und kann diese an andere Nutzer verteilen, wohingegen ein Nutzer mit einer Analyzer Lizenz nur eigene Alerts für sich selbst anlegen kann. Alle anderen können die Benachrichtigungen nur empfangen.

Zusammen mit der Qlik-Alert-Software kann auch eine Qlik-Alert-Extension installiert werden, die es erlaubt, die Alerts direkt aus den Qlik-Apps heraus einzustellen, ohne über das Qlik-Alerting-Webfrontend zu gehen.

NEUESTE BEITRÄGE



Weitere Services:


Reporting & Analytics

Die Cloud-Plattform basierte SaaS-Version von Qlik Sense bietet Daten-Alerts automatisch mit an. Hier kann direkt in der App per Rechtsklick ein neuer Alert konfiguriert werden (siehe Grafik rechts). Die Alerts können auf alle Daten und Kennzahlen eingestellt werden. Außerdem sind als Bedingungen für die Benachrichtigung von einfachen Wertüberschreitungen bis zu Ausreißer-Erkennung über Standard-Deviation verschiedenste Einstellungen möglich.

Die Applikation wird vom technischen User-Qlik-Alerting aufgerufen, dies passiert entweder nach jedem Reload der App oder nach einem bestimmten Zeitplan. Sobald die Bedingung greift, werden E-Mail-Benachrichtigungen an die vorher eingestellten E-Mailadressen oder -verteiler versendet. Die E-Mail enthält einen Link, der den Nutzer direkt in die Applikation führt.

Die Benachrichtigungen können nicht nur per E-Mail empfangen werden, sondern auch über die Qlik-Alert-App auf dem Smartphone.

Über die Autorin

Daniela Pohl berät und betreut als Senior Consultant Kunden im Bereich Reporting und Analytics. Ihr Schwerpunkt liegt dabei auf den Themen Frontendentwicklung und Konzeption.

Daniela Pohl gehört zum Team Reporting & Analytics.

Eine schnellere Welt erfordert schnellere Daten. Qlik bietet für Datenloads eine mächtige In-Memory Engine und effiziente Speicherformate. Doch die nächtliche Datenaktualisierung reicht oft nicht mehr aus, es müssen mehr Daten häufiger nachgeladen werden. Das führt zu Auslastungsproblemen und einem Daten-Overload auf der Qlik-Plattform und Frust bei Nutzern und Entwicklern.


Qlik Daten-OverloadÜberlastung mit Reload-Tasks

Je mehr Qlik-Applikationen produktiv laufen, desto mehr Ladeprozesse werden in der Qlik Management Konsole (QMC) eingerichtet. Oft teilen sich mehrere Bereiche eine Qlik-Plattform und alle wollen ihre Daten zur gleichen Zeit, möglichst nachts, laden, damit zum morgendlichen Arbeitsbeginn alle Applikationen aktualisiert bereitstehen. Die Nacht ist lang und die Beteiligten werden sich einig, wer in welchem Zeitfenster seine Tasks einplant. Doch spätestens bei einem zweiten Datenlauf mittags, um für den Nachmittag noch aktuellere Daten zu bekommen, wird es jetzt eng auf der QMC. Der sogenannte Scheduler, der die Tasks in der QMC verwaltet und die Reloads durchführt, hat nur begrenzte Ressourcen und kann nur eine bestimmte Anzahl Tasks gleichzeitig ausführen. Alle weiteren Tasks, die getriggered werden, starten nicht, sondern landen in der Warteschlange.
Die Sanduhr der Warteschlange ist zum verhassten Symbol aller Nutzer von vollen Qlik-Plattformen geworden. Hier hilft Up-Scaling des Qlik Schedulers.

NEUESTE BEITRÄGE



Weitere Services:


Reporting & Analytics

Qlik Daten-Overload

Statt nur einem Scheduler auf der QMC können sich auch mehrere Scheduler die Arbeit teilen. Damit wird auch linear die Anzahl der Tasks, die parallel ausgeführt werden können, erhöht.

Hier können je nach Konfiguration die Scheduler einfach parallel laufen und sich die Tasks aus der Warteschlange greifen. Das kann allerdings dazu führen, dass die CPU beider Scheduler zwar ausgeglichen ist, sie sich in der RAM-Auslastung aber deutlich unterscheiden. Beispielsweise, weil ein Scheduler immer einfache kleinere Load und Store Tasks ausführt, der andere aber große Datenmengen verknüpft oder aggregiert.

Die bessere Wahl bei unterschiedlichen Tasks ist die Konfiguration, dass ein bestimmter Scheduler als Master dient, das Load Balancing durchführt und die Tasks auf die anderen Scheduler als Slaves verteilt.
Auch kann es nötig sein, den oder die Scheduler selbst mit mehr Power auszustatten. Ein paar GB mehr RAM für den Scheduler wirken wahre Wunder, was Taskabbrüche anbelangt, die der Auslastung der Plattform zuzuschreiben sind.

Überlastung des Hubs oder des Laufwerks

Je mehr Entwickler auf der Plattform sind, desto öfter gibt es auch Probleme beim Daten laden im DEV-Hub, dem Qlik-Entwicklungsserver. Jeder möchte sein Skript einmal schnell testen oder seine gerade entwickelte Applikation einmal reloaden und so wird der Weg gespart, eigens einen Task dafür anzulegen, indem im DEV-Hub geladen wird. Läuft das Skript auf einen Fehler, so muss kein Logfile durchsucht werden, sondern es kann direkt während des Datenladens jeder Schritt mitverfolgt werden und das Skript direkt debugged werden. Kein Wunder also, dass nicht nur ein einziger Entwickler auf diese Idee kommt und da geht der DEV-Knoten schon mal in die Knie. Abhilfe schafft hier ein Upscaling des DEV-Hubs.

Wenn die Qlik-Plattform dann stabil läuft und fleißig Daten läd, müssen diese schlussendlich auch irgendwo abgespeichert werden. Auch wenn Qlik mit den QlikView-Daten (QVD) ein eigenes sehr kompaktes Dateiformat entwickelt hat, kann das Qlik-Laufwerk voll werden. Zumindest wenn sich der Entwickler an das Best Practice Vorgehen hält und die Daten mehrfach als QVDs vorhält, einmal als direkter Quellabzug und einmal bereits transformiert und fertig fürs Einladen in die Apps. Hier gibt es die Möglichkeit weitere NAS-Laufwerke einzuhängen, um den Speicherplatz zu erhöhen.

Je mehr Daten ein Kunde hat und je unterschiedlicher die Ladestrategien sind, desto komplizierter wird es. Hier sind passgenaue Lösungen gefragt.

Über die Autorin

Daniela Pohl berät und betreut als Senior Consultant Kunden im Bereich Reporting und Analytics. Ihr Schwerpunkt liegt dabei auf den Themen Frontendentwicklung und Konzeption.

Daniela Pohl gehört zum Team Reporting & Analytics.

Dieser Beitrag ist der Auftakt unserer „Gewusst wie“-Reihe rund um die SAP Analytics Cloud. In diesem Artikel erfahren Sie, wie Sie Berichte ganz einfach dynamischer gestalten können. Die Anwender danken es Ihnen, da Sie die vorgestellten Informationen noch einfacher und schneller erfassen können. Dies verbessert zugleich die Entscheidungsfindung und die Zusammenarbeit zwischen den Nutzern deutlich.


Neben der Funktion „Datenpunktkommentar“ bietet SAP Analytics Cloud in der Komponente Analytic Application die Möglichkeit, Tabellendaten in eine zusätzlich in die Tabelle eingefügte Spalte zu kommentieren. Der Unterschied zwischen den Kommentierungsarten besteht darin, dass die zusätzliche Tabellenspalte die Kommentare permanent sichtbar macht und anzeigt. Die Endbenutzer können ihre Kommentare, zum Beispiel Erklärungen von Abweichungen oder Bemerkungen, in die neue Spalte selbst einfügen oder bereits vorhandene Anmerkungen bearbeiten und anpassen.

Durch diese in SAP Analytics Cloud eher versteckte Funktion lassen sich die Berichte noch dynamischer gestalten. Weitere Vorteile sind, dass Entscheidungen schneller getroffen werden können und die Zusammenarbeit zwischen Nutzern deutlich verbessert wird.

Eine Kommentarspalte erstellen 


Nach dem Einfügen der Tabelle in den Grafikbereich der Analytic Application ist die Zelle mit dem Kennzahlkopf mit der rechten Maustaste anzuklicken und zunächst die Optionen „Spalte hinzufügen“ und anschließend „Wiederkehrend“ auszuwählen.

Eine neue Spalte wird automatisch der Tabelle rechts der Kennzahl hinzugefügt. Anschließend klicken Sie auf „…“ und selektieren die Option „Vollbild“.

Dann aktivieren Sie die erste Zelle der neu hinzugefügten Spalte und geben das Skript „=comments(erste_Datenzelle_der_betroffenen_Kennzahl)“ ein.

In diesem Beispiel wurde das Skript „=comments(H4)“ eingegeben, Sie wie dem nebenstehenden Screenshot entnehmen können.

Sobald die Applikationsentwicklung beendet ist, speichern Sie die Applikation und klicken auf „Analytic Application ausführen“, um in den Ansichtsmodus zu wechseln.

Um einen Kommentar in eine Zelle einzutragen, führen Sie einen Doppelklick auf die gewünschte Zelle aus. Es öffnet sich automatisch ein Popup-Fenster. Nach der Texteingabe wird der Kommentar mit einem Klick auf das Feld „Kommentar schreiben“ gespeichert.

Hinweise:
  • Wenn mehrere Kommentare in die gleiche Zelle eingegeben wurden, ist jeweils nur der aktuellste Kommentar in der Tabelle sichtbar. Der gesamte Kommentarverlauf einer Zelle kann durch Doppelklick auf die jeweilige Zelle angezeigt werden.
  • Ein Kommentar darf maximal 3.000 Zeichen enthalten.

Über die Autorin

Eleni Viseri, Autor für den Fachbereich Reporting & AnalyticsEleni Viseri betreut und berät als Junior Consultant Kunden im Bereich Reporting und Analytics. Ihr Schwerpunkt liegt dabei auf der Frontendentwicklung. Sie studierte Mathematik mit dem Schwerpunkt Informatik und war zuvor als Business Intelligence-Consultant für eine Unternehmensberatung tätig.

Eleni Viseri gehört zum Team Reporting & Analytics.