Qlik Alerting – Proaktive Benachrichtigungen bei kritischen KPIs und administrativen Tasks (Teil 1)

Kevin Duchrow |
13. August 2020 |

Im April 2020 hat Qlik ein weiteres »Value Added Product« seiner End-to-End Data Analytics Suite hinzugefügt: Qlik Alerting integriert eine intelligente und kontextbezogene Benachrichtigungsplattform in Qlik Sense, die sowohl zentral als auch im Self-Service durch den Anwender konfiguriert werden kann.

Ich, Kevin aus dem fme Business Intelligence Team, habe Qlik Alerting auf unserem Server getestet und möchte in diesem Blogbeitrag unsere Eindrücke mit Ihnen teilen und Anwendungsfälle aufzeigen. Darüber hinaus erhalten Sie einige technische Einblicke. Zusätzlich gebe ich Ihnen noch ein paar Tipps mit auf den Weg, die uns bei der Installation und Einrichtung sehr geholfen haben.

In diesem ersten Teil des Blogposts möchte ich Ihnen einen ersten Überblick über die Funktionalität von Qlik Alerting geben. In Kürze wird ein weiterer Teil erscheinen, in dem ich Ihnen administrative Einblicke sowie Anpassungsmöglichkeiten vorstelle.

Qlik Alerting ist als zusätzliches Tool erhältlich und wird neben dem Qlik Sense Server installiert. Für den produktiven Einsatz empfiehlt Qlik eine Installation auf einem dedizierten Server.

Mit Qlik Alerting ist es möglich, Benachrichtigungen zu überschrittenen Kennzahlen (KPI), geänderten Stammdaten oder administrativen Tasks an User zu versenden. Die Benachrichtigungen können per E-Mail oder über die Qlik Alerting App, die für Android und IOS erhältlich ist, versendet werden. Qlik unterscheidet dabei zwischen vier verschiedenen Eventtypen.

  1. Qlik Data Alerts
  2. Qlik System Alerts
  3. Qlik Alerts Broadcasting
  4. Qlik Alerting – Konfiguration, Voraussetzungen und Lizenzmodell

 

Auf Typ eins bis drei gehe ich im Folgenden näher ein. Typ vier stelle ich in Kürze in einem zweiten Teil meines Blogposts ausführlich vor.

1. Qlik Data Alerts

Wie der Name bereits erahnen lässt, basieren diese Alerts auf Änderungen von Daten in Qlik Sense Apps. Ein Data Alert hängt immer unmittelbar mit einer veröffentlichten App in Qlik Sense zusammen. Die Data Alerts gehören zu den Key-Features dieses Tools und werden von Qlik als der Grundbaustein der »intelligent alerting platform« für Qlik Sense bezeichnet, da diese ein daten-basierendes Alerting ermöglichen.

Die Neuheit hierbei bildet der Self-Service Ansatz, ein Alleinstellungsmerkmal der Data Alerts – doch was bedeutet das genau?
Mithilfe einer zusätzlichen zertifizierten Extension für Ihre Qlik Sense Applikation wird dem Benutzer ermöglicht, sich direkt bei der Analyse in der App, basierend auf eigens ausgewählten Diagrammen, Tabellen, KPIs usw. Alerts zu definieren.

Dazu wählt der Benutzer im ersten Schritt ein Element aus der App aus und kann basierend auf seinen kontextbezogenen Filtern für das gewählte Element eine Regel definieren, die zu einer Benachrichtigung durch Qlik Alerting führt.

 

Ich bin überzeugt, dass…
… mit dieser Funktionalität der administrative Aufwand deutlich gesenkt wird. Benutzer werden – im Sinne der Self-Service Idee – befähigt sich individuelle Alerts zu erstellen und können selbst bestimmen, welche Kennzahlen zu welchen Limits eine Benachrichtigung auslösen sollen. Somit bleiben Ihre User immer auf dem Laufenden und haben alle Analysen »im Blick«.

 

Darüber hinaus steht eine Administrationsoberfläche zur Verfügung, die eine klassische Konfiguration der Alerts ermöglicht. Durch diese Konfiguration möchte ich Sie nachfolgend leiten, um den Funktionsumfang zu verdeutlichen:

Qlik Alerting Administrationsoberfläche

 

Ist eine App und ein dazugehöriges Arbeitsblatt ausgewählt, können als Datengrundlage für den neuen Alert Masterkennzahlen ausgewählt werden. In diesem ersten Schritt können auch zusätzliche »Drill to« Dimensionen sowie Filter eingestellt werden, die sich auf die Kennzahlen der Alerts auswirken.

Sind die gewünschten Daten nicht direkt als Masterkennzahl verfügbar, können auch benutzerspezifische Kennzahlen definiert werden. Bei komplexen Formeln bietet es sich an, diese in der App zu entwickeln und in die Administrationsoberfläche zu kopieren, da in dieser keine Syntaxüberprüfung zur Verfügung steht.

 

Mein Tipp:Die ausgewählten Filter oder Bookmarks in der App werden für diesen Alert gespeichert. Klickt ein User in der Benachrichtigungs-E-Mail auf den Link zu der App, werden die voreingestellten Filter und Bookmarks direkt angewendet. Somit ist es möglich, Sichten vorzubereiten, ohne dass weitere Filterungen nötig sind. Es kann sofort mit der spezifischen Analyse gestartet werden.

 

Zum einfacheren Nachvollziehen werden die ersten zehn Ergebnisse in einer Vorschau unter der Konfiguration angezeigt, wodurch eine erste Validierung sehr einfach ist.

Im Anschluss folgt das Konfigurieren der Bedingungen, die über das Senden einer Benachrichtigung entscheiden. Die Bedingungen können auf einen manuell definierten Wert basieren oder sich an den vorherigen Werten des letzten Reloads orientieren. Somit ist es möglich, auf Änderungen in den Daten zu reagieren.

Zum Beispiel könnte man einen Alert für eine bestimmte Abteilung generieren, der die verantwortlichen Mitarbeiter benachrichtigt, sobald sich die Menge der Bestellungen verglichen mit dem letzten Reload nicht oder nur unzureichend verändert hat.

 

Technical Insights:
Für die Definition der Regeln stehen logische Operatoren ( >, >=, <, <=, ==, !=), sowie die einfachen String Operatoren »Starts/Ends with« und »Includes« zur Verfügung. Es können bis zu fünf Bedingungen pro Alert definiert werden. Die Bedingungen werden im Anschluss durch Regeln verknüpft. Standardmäßig wird für jede Bedingung eine Regel angelegt, die sequenziell ausgewertet werden. Sind alle Regeln zutreffend, wird der Alert ausgelöst. Regeln sind im Standard mit einem Logischen UND verknüpft.
Zusätzlich ist die Verknüpfung der Regeln auch anpassbar. So können beispielsweise drei Bedingungen definiert werden und in einer Regel durch logische Operatoren verknüpft werden. Hier stehen die logischen Operatoren UND (&&) ODER (||) und NICHT (!) zur Verfügung. Natürlich wird auch die Setzung von Klammern unterstützt.

 

In einem weiteren Schritt konfiguriert der User, wann die Regeln ausgewertet werden. Standardmäßig ist dies auf den Reload der dazugehörigen App eingestellt. Natürlich kann die Ausführung auch unabhängig des Reloads anhand von Zeitintervallen konfiguriert werden.

 

Mein Tipp:
Aktualisiert die App sehr häufig ist es ratsam, die Auswertung der Regeln z. B nur einmal täglich durchzuführen. Schließlich ist es vermutlich nicht ihr Ziel, die User mit E-Mails zu nerven und keinen Spielraum für die Analyse des Sachverhaltes einzuräumen.

 

Schlussendlich lässt sich der Empfängerkreis und das Erscheinungsbild des Alerts konfigurieren. Hier können einzelne Personen oder Gruppen als Rezipienten hinzugefügt werden. Auch eine Benachrichtigung auf der mobilen App ist möglich. Auf die Konfigurierbarkeit der Nachricht werde ich im Anschluss noch näher eingehen.

 

Zusammenfassung möglicher Anwendungsfälle:

  • Änderung der Umsatzprognose
  • Überbuchung von Projekten
  • Überwachung von Überlastungen (zum Beispiel Lagerbestand)

2. Qlik System Alerts

Als System Alerts werden alle Alerts bezeichnet, mithilfe derer das Überwachen von Reload Tasks (im Folgenden als Task bezeichnet) bewerkstelligt werden kann. Hier können einzelne oder mehrere Tasks ausgewählt werden, die als Grundlage für die Bemächtigung berücksichtigt werden.

Für die ausgewählten Tasks kann zwischen fünf verschiedenen Eventtypen gewählt werden:

  1. Success – Task ist, wie erwartet, erfolgreich beendet wurden
  2. Failed – Task wurde beendet, es ist jedoch ein Fehler bei der Ausführung aufgetreten
  3. Aborted –Task wurde oder wird zurzeit unterbrochen
  4. System Aborted –Task wurde systemseitig unterbrochen ohne benutzerseitigen Eingriff
  5. In Progress – Ausführung des Tasks läuft

 

Für den Alert lassen sich ein oder mehrere Eventtypen auswählen. Nur bei dem Eventtypen »In Progress« ist es möglich, eine zusätzliche Einstellung zu tätigen: Hier ist ein Schwellwert konfigurierbar. Dieser Wert beschreibt die Zeit, in der sich der Task in diesem Status befindet, bevor eine Benachrichtigung gesendet wird. Dadurch soll ermöglicht werden, länger währende Tasks zu überwachen und möglichen Verzögerungen proaktiv und schnell entgegen zu wirken.

Ein selbstbestimmbarer, konditionaler Zusammenhang (z. B. ein bestimmter Task ist abgeschlossen aber ein anderer unterbrochen) lässt sich aktuell nicht umsetzen.

Beim Testen dieser Funktionalität und damit zusammenhängenden Anwendungsfällen fiel uns ein weiterer Punkt auf: Das konfigurieren »Dynamischer Alerts« ist leider aktuell nicht möglich – was meine ich damit?

Wir haben uns einen Anwendungsfall überlegt, indem ein Systemadministrator einen Alert erstellen möchte, bei dem er alle Tasks auf dem Server beobachtet und bei einem Fehler benachrichtigt wird. Dazu haben wir einen System Alert angelegt und über den Kopf der Tabelle (hier ist ein zusätzliches Auswahlfeld, wenn alle Apps ausgewählt werden sollen) alle Apps ausgewählt. Zudem haben wir den Eventtypen »Failed« (s. o.) angeklickt. Für uns bedeutete dies, wenn nun irgendein Task fehlschlägt bekommt der Administrator eine E-Mail – leider ist dies nicht der Fall!

Denn Qlik Alerting erweitert diese Alerting nicht, wenn neue Tasks angelegt werden. Obwohl wir explizit alle Tasks ausgewählt haben, wird das Alerting nur auf die Tags angewendet, die zu dem Zeitpunkt des Erstellens existierten. Die Lösung hier ist also, manuelles bearbeiten der Alerts, wenn ein neuer Task angelegt wird. Bei einer großen Menge, wie bei verschiedenen Kundensystemen, ist dies jedoch mit einem sehr hohen Zeitaufwand verbunden.

 

Zusammenfassung möglicher Anwendungsfälle:

  • Reload dauert zu lange
  • Reload fehlgeschlagen

Quelle: https://help.qlik.com/en-US/alerting/June2020/Content/QlikAlerting/system-alerts.htm

3. Qlik Alerts Broadcasting

Mit dem Broadcasting ermöglicht Qlik Alerting Nachrichten an eine größere Menge von Usern zu senden. Denkbare Szenarien könnte hier eine anstehende Serverwartung oder auch eine Benachrichtigung einer Benutzergruppe über Änderungen in einer App oder einem Stream sein.

Diese Art von Benachrichtigung ist von keinen Objekten aus Qlik Sense abhängig. Konfigurierbar ist hier der Inhalt der Benachrichtigung, der sich auch an Unternehmensstandards anpassen lässt, sowie die Zielgruppe und Planung des Alerts.

Für diese Art des Alerting ist das Zuordnen einer weiteren Lizenz für den erstellenden Benutzer nötig. Hierauf gehe ich in Kürze in Teil zwei dieses Blogposts im Kapitel »Lizensierung« näher ein.

 

Zusammenfassung möglicher Anwendungsfälle:

  • Neue App ist in einem Stream verfügbar
  • Anstehende Serverwartung

 

Damit sind wir auch schon am Ende des ersten Teils. Im zweiten Teil beleuchte ich die Konfigurationsmöglichkeiten sowie die Administrationsübersicht näher und gebe tiefere, technische Einblicke in Qlik Alerting. Viel Spaß beim Lesen:

Qlik Alerting – Proaktive Benachrichtigungen bei kritischen KPIs und administrativen Tasks (Teil 2)

 

Sind noch Fragen offengeblieben? Dann freue ich mich, von Ihnen zu hören!

 

 

 

 

Weitere Informationen

 

 

×
Haben wir Ihr Interesse geweckt? Dann schreiben Sie uns gerne an.
JETZT KONTAKT AUFNEHMEN

Folgen Sie uns auf unseren Social Media Accounts, um keinen neuen Blogartikel zu verpassen.

linkedin     xing     facebook     twitter

0 Kommentare

Einen Kommentar abschicken

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert