Oft werden wir gefragt, welche Funktionalität der QlikView Publisher umfasst. Leider kenne ich keine gutes Dokument, das alle Features übersichtlich listet. Unterhalb also mein Versuch die wichtigsten Punkte kurz zu beleuchten.
QlikView Server & Publisher auf zwei getrennte Maschinen
Kleine QlikView Installationen starten gerne mit einer Maschine die gleich zwei Aufgaben übernehmen muss: Das Beladen der QlikView Applikationen sowie die In Memory-Analyse über den QlikView Accesspoint.
Technisch übernehmen diese beide Aufgaben einerseits das QlikView Distribution Service (Beladung) und andererseits das QlikView Server Service (In Memory Analysen). Meist geht das eine Weile gut, doch eigentlich sind sich die beiden Services spinnefeind! Beide Services sind sehr Memory- und CPU-intensiv und wollen eigentlich alle Ressourcen für sich alleine!
Kastriert man den QlikView Server über seine WorkingSet-Limits, kann das Service weniger Cachen und die QlikView Anwendungen werden CPU-intensiver. Nutzt der QlikView Server alle Ressourcen um die Useranfragen schnellst möglich bereitzustellen, bleibt kein "Platz" mehr für die Beladung der Applikationen.
Wenn also über die Jahre die Datenmengen in den Applikationen wachsen, die Beladungen auch untertags stattfinden sollen oder immer mehr Kunden auf die Applikationen zugreifen - kurz gesagt wenn das Qlik Projekt ein Erfolg ist - dann streiten sich die beiden Services immer mehr um die beschränkten Rechner-Ressourcen, worunter die Gesamtperformance leidet. Am Sinnvollsten ist es dann, die Services auf zwei getrennten Servern zu konfigurieren. Lizenztechnisch ist das aber nur mit einer Publisher Lizenz möglich.
Aus unserer Erfahrung schlagen wir immer folgendes Deployment vor, welches auf Dauer viel stabiler als eine "Single Server"-Lösung läuft, die Ressourcen besser nutzt und leichter zu Warten ist.
 |
| Empfohlenes Deployment: Publisher und QlikView Server auf zwei Maschinen trennen |
Cluster Publisher
Haben Sie eine Publisher-Lizenz, so dürfen Sie damit einen Server betreiben. Benötigen Sie eine Lastverteilung der Beladungen über mehrere Server, so können Sie das Distribution Service clustern. Die Taskdefinition in der QMC bleibt gleich, und Qlik entscheidet aufgrund eines Loadbalancing-Algorithmus auf welchem Reload-Server der Task dann tatsächlich ausgeführt wird.
 |
| Mehrere Distribution Services sind sinnvoll, wenn sehr viele Beladetasks vorhanden sind |
And Trigger - On Multiple Events completed
Sehr häufig sehen wir bei Nicht-Publisher Kunden ewig lange Taskketten, da die QVD-Generatoren "seriell" nacheinander angestoßen werden. Das ist weder bezüglich Übersicht in der QMC, noch von der Laufzeit ideal.
Mit der Publisher-Lizenz wird ein weiterer Trigger-Typ freigeschalten: der "On Multiple Events Completed" oder auch "AND"-Trigger.
Typischerweise benötigt ein QlikView Datamart (Datenmodell) mehrere QVD-Generator als Vorgänger, da man oft pro Quellsystem einen eigenen QVDGenerator anlegt. Anstatt diese QVD-Generatoren seriell nacheinander laufen zu lassen, können Sie alle gleichzeitig wegstarten. Sobald der Langsamste fertig wird, startet der Datenmodell-Task. So lässt sich die Durchlaufzeit erheblich reduzieren.
 |
| Der Task startet, wenn der "langsamste" der drei (parallel laufenden) Vorgängertasks fertig ist |
Simple Reduce und Loop&Reduce
Sie haben eine große Applikation, die Sie in mehrere kleine Tortenstücke "schneiden" möchten? Mit der Publisher-Lizenz erhalten Sie den Menüpunkt "Reduce".
Typisches Anwendungsgebiet ist, dass Sie für Ihre Niederlassungen (US, EU, Asia) getrennte Applikationen berechtigen möchten, während die User im Stammhaus weiterhin alle Daten in einer großen Applikation im Zugriff haben sollen. Aus der Gesamtapplikation lässt sich in der QMC manuell oder als "Seriendruck" mehrere kleinere .qvws schneiden und automatisch für die User berechtigen.
 |
| Simple Reduce über Land=Deutschland, Österreich und den Kategorienamen=Getränke |
|
 |
| Loop&Reduce über das Feld "Land" erzeugt und berechtigt pro Land eine Applikation |
Distribute zu Email/Netzlaufwerk/Accesspoint
Ohne Publisher Lizenz muss die .qvw immer am Ort beladen werden, wo auch der User via Accesspoint darauf zugreift. Mit dem Publisher sind Sie hier flexibler: Sie können QlikView Auswertungen via Email verschicken, auf einem Netzlaufwerk bereitstellen, oder auf einen Ihrer Accesspoints verteilen. Der Menüpunkt "Distribute", über den Sie auch die Userberechtigungen steuern, wird mit der Publisherlizenz freigeschalten.
 |
| Der Distribute Reiter verteilt und berechtigt die QlikView Applikation |
Notify
Ein kleines Feature, aber nicht unwichtig: Sie wollen
Ihre Mitarbeiter informieren, dass eine aktualisierte Version der Qlik
Applikation am Accesspoint bereitsteht: setzen Sie den Haken "Notify" um
alle Berichtsempfänger zu informieren. Unter "System" können Sie das Notify-Emailtemplate bearbeiten.
 |
| Allen Empfängern eine Email schicken wenn QlikView Applikation frisch beladen wurde |
Mehr als ein Task pro .qvw möglich
Oft ärgerlich ohne Publisher-Lizenz: man kann pro .qvw nur einen Task anlegen. Manchmal möchte man aber den Task jeden Montag und am Monatsende laufen lassen. Oder man möchte neben einer zeitgesteuerten Ausführung den Task auch von einem externen System angestoßen lassen.
Mit der Publisher Lizenz können Sie pro .qvw beliebig viele Tasks anlegen.
 |
| Mehrere Tasks auf einer .qvw |
EDX (über schönen Tasknamen ansprechbar)
Hier geht es darum, die QlikView Tasks von extern anzustoßen. Ein Beispiel wäre, dass ein externer Scheduler den QlikView Task erst startet, nachdem das Data Warehouse fertig beladen wurde (da dies zu unterschiedlichen Uhrzeiten eintreten kann).
EDX oder "Event Driven Execution" geht genaugenommen auch ohne Publisher Lizenz. Aber man muss schon ziemlich gut im "Tasknamen Raten" sein, um den Task von einem Vorsystem anstoßen zu können. Mit der Publisher-Lizenz können Sie jedem Task einen Namen und eine Description geben, damit wird das Anstoßen der QlikView-Tasks durch das Vorsystem deutlich komfortabler.
 |
| Ein externer Scheduler kann den Publisher Task mit dem Namen anstarten |
Supporting Tasks
Neben dem reinen Beladen von QlikView Applikationen, können Sie mit dem Publisher auch weitere Tasks durchführen. Dazu zählt:
- Das Ausführen von External Programs (zB Powershell/Batch-File um Daten zu löschen/kopieren, CacheWarming, etc.)
- Database Command Tasks (zB Inserts in Log-Datenbank wenn alle Tasks erfolgreich durchgelaufen sind)
- QVD Creation Tasks: Erzeugen und Berechtigen von .QVD Datentöpfen auch ohne QlikView Applikation. Berechtigte Self Service BI-User können dann diese .qvds nutzen um Ihre eigenen Applikationen aufzubauen
- Pause Task: Dieser Tasktyp macht einfach mal Pause :-)
 |
| Supporting Tasks unabhängig von .qvws |
Document Administrator
Sie haben Fachabteilungen die sich Ihre Dashboards selbst beladen/schedulen und berechtigen können? Gleichzeitig wollen Sie aber vermeiden, dass diese User Systemeinstellungen Ihrer QlikView Umgebung ändern können!
Der Publisher erlaubt mit dem Document Administrator Feature, dass bestimmte User nur bestimmte Applikationen in der QMC verwalten dürfen. Typischerweise definiert man pro Fachabteilung einen Mount-Point in dem alle Applikationen sind, die die Document Adminstrators selbst verwalten sollen. Die anderen Abteilungs-Applikationen sowie der Reiter "System" bleiben für diese Document Administrator verborgen.
 |
| Dieser Document Administrator sieht nur seine Tasks im Mountpoint Default und HR. Der Reiter "Users" und "System" ist ebenfalls ausgeblendet |
User Suche und Section Access Management
Wenn die Berechtigungen nicht aus dem Vorsystem übernommen werden können, dann können Sie diese mit der Publisher-Lizenz zentral in der QMC managen. Benötigen Sie applikationsspezifische Berechtigungen (User X darf nur Kostenstelle Y sehen) so steht Ihnen hierfür der Menüpunkt "Section Access Management" zur Verfügung.
 |
| Zentrales Management von User Rollen für Section Access |
Parameter
Ähnlich gelagert wie "Loop & Reduce" können sie mittels Scriptparameter eine Variable an das QlikView-Skript übergeben. Wenn Sie im QlikView Script etwa eine Variable
vMandant haben, die im Skript wiefolgt genutzt wird
Select
*
from Fakten where MANDANT = $(vMandant);
so können Sie die Variable in der QMC als Script Parameter setzen. So können Sie eine .qvw als Vorlage benutzen, um mit dem Publisher mehrere Varianten der Applikation zu verteilen.
 |
| Das Script in der .qvw würde dreimal ausgeführt werden: für den Mandanten 200, 300 und 500. |
Remote Management Service
Wenn Sie in Ihrem Test/Quality System ebenfalls eine Publisher Lizenz haben, so können Sie in der Produktivumgebung dieses System als "Remote Distribution Service" eintragen. Damit können Sie die Taskdefinitionen aus dem Test/Quality System in die Produktivumgebung übernehmen.
 |
| Remote Management Service am Server "testsystem" |
Backup QVPR einstellbar
Die Taskdefinitionen der QMC werden defaultmäßig in einem XML-Repository abgelegt. Dieses liegt für gewöhnlich unter C:\ProgramData\QlikTech\ManagementService\QVPR. Dort wird auch täglich ein Backup angelegt. Mit der Publisher-Lizenz können Sie diese Backups auch in einem Ordner ablegen, der sowieso schon in Ihrem Backup-Plan enthalten ist.
 |
| QVPR Einstellungen für Pfad + Backup |
Supervisor User
Anstatt die Administratoren (zB die User der IT-Abteilung) in jeder einzelnen Applikation zu berechtigen, gibt es das Konzept der Supervisor User. Diese User werden automatisch in jedem Distribution Task angehängt und dürfen alle QlikView Applikationen sehen.
 |
| Supervisor User für "Whole Server" definiert |
Number of Task Attempts bei Taskdefinition einstellbar
Leider laufen Beladetasks manchmal auf einen Fehler. Weil das Quellsystem nicht da ist, weil die Netzwerkverbindung weg ist, oder weil am Server nicht genügend Ressourcen bereit stehen. Viele Administratoren starten dann den Task frühmorgens nochmal, und dann läuft er plötzlich durch. Mit der Publisher-Lizenz können Sie die Tasks so definieren, dass der Publisher nach einem "Fehlschlag" die Beladung nochmal versucht. Oft klappt es dann beim zweiten Mal!
 |
| Number of tries bevor der Publisher den Task "aufgibt" |
Audit
Vertrauen ist gut, Kontrolle ist besser. In manchen Anwendungsgebieten muss man einfach nachvollziehen können, welcher User wann welche Änderungen durchgeführt hat (Task Trigger geändert, User berechtigt). Mit der Publisher Lizenz haben Sie die Option einen Audit-Log für die QMC zu aktivieren. Das Logfile kann dann natürlich mit QlikView ausgewertet werden.
 |
| Audit Log für Änderungen in QMC kann in Config File aktiviert werden |
