QlikView + Qlik Sense Blog von Heldendaten

Rob Wunderlich hat sich in seinem aktuellen Blogpost einer unserer Diskussionen vom MasterSummit for QlikView in Barcelona angenommen.

Falls Sie Rob's Document Analyzer benutzen, um Felder am Ende des Skripts zu droppen, hier nochmals meine Beobachtung.

Attached a small example that shows the issue:

- 01_testDatabase.qvw produces a .qvw with about 350MB on disk
- 02_testDatabaseBinaryDrop400fields.qvw does a BINARY Load and then drops 400 fields --> it's about 18 MB on disk (136 MB in Memory including QV.exe)

So one would expect that 18 MB is the final size of the .qvw!
However when I do an additional RESIDENT-Load after dropping fields, the .qvw gets much smaller:

- 03_testDatabaseBinaryDrop400fields_Resident does a BINARY Load, then drops 400 fields and THEN makes a RESIDENT LOAD on the table, dropping the original table

--> suddenly the .qvvw is only 1.2 MB on disk (26 MB in Memory including qv.exe)!
Download Example

Rob hat dies nun weiter analysiert und bemerkt, dass die  Record pointers nicht freigegeben werden.  Erst mit einem weiteren RESIDENT-Load wird tatsächlich der komplette DISK/MEMORY-Space freigegeben.

• Im Moment ist es besser die nicht benutzen Felder im Skript auszukommentieren, anstatt Sie erst am Ende des Skripts zu droppen!
• Falls dies nicht möglich ist, sollte man nach den Drop Fields Statement die (Fakten)-Tabelle nochmals resident laden.

Vergangene Woche hatte ich die Gelegenheit drei Tage am "Masters Summit for QlikView" in Barcelona teilzunehmen. Neben den QlikCommunity-Größen Rob Wunderlich, Bill Lay, Barry Harmsen und Oleg Troyansky, trafen sich gut 50 QlikView Spezialisten aus der ganzen Welt zu Vorträgen und regem Gedankenaustausch.


Die dreitägige Vortragsreihe hatte einen Schwerpunkt auf die QlikView Developer- und Designerrolle, mit dem Anspruch selbst erfahrenen Entwicklern noch die eine oder andere Neuigkeit beizubringen. Also durchaus schwere Kost, die uns aber durch das wundervolle Wetter in Barcelona versüßt wurde :-)

Die Themen waren:

• Advanced Scripting: Vorstellung der QlikView Components durch Rob Wunderlich himself
• Data Modeling: Barry Harmsen ging mit uns durch die typischen Datenmodell-Patterns für Fortgeschrittene inklusive Concat-Datenmodell, LinkTable, GenericKey und AsOf-Kalender (den ich bisher selbst immer Superkalender nannte) für Lagerbewegungen
• Set Analysis: Oleg Troyansky über Alternate State, Bucketanalyse mit Rank und AGGR sowie Advanced Set Analysis
• Effective Visualizations: Bill Lay's Gedanken über die Grundsätze von Stephen Few
• QlikView Competency Center Best Practice: Diskussion des typischen 3-4 Schichten Modells in QlikView (Aufteilung QVD/Datenmodell/Layout). SVN Integration, sowie einige gute Gedanken zu Regressiontesting mit dem JMeter-Tool des QlikView Scalability Centers. 
• Performance Tuning: Oleg Trojansky mit einer ausgezeichneten Erklärung wie QlikView Daten mittles bit-stuffed Pointers in den Symboltables ablegt.

Einzig der Vortrag über QlikView Server Administration inklusive  EDX-Integration, HTTP-Header Authentication und Ticketing schien mir zu wenig in die Tiefe zu gehen. Aber vielleicht ist das einfach meiner Historie als Expert Service Spezialist zu genau diesen Themen bei der QlikTech geschuldet. Dafür hatte unser Blog höchstpersönlich einen Auftritt beim MasterSummit: Das Development Team Easter Egg sorgte für allgemeine Erheiterung nach den anstrengenden Sessions!

Für all jene, die es zu dem Summit nach Barcelona nicht geschafft haben, und auch unseren hd Business Roundtable vergangenen Freitag bei Resch&Frisch in Wels verpasst haben, findet sich eine kleine aber feine Applikation mit einigen Tipps&Tricks auf unserem Accesspoint (auch zum Download).

Roland Vecera

Seit QlikView 10 ermöglicht das Feature "Comment & Tagging" Metainformationen auf Tabellen- und Feldebene zu hinterlegen. Der Entwickler des Datenmodells (zumeist aus der IT) kann somit zusätzliche Informationen an den QlikView Designer (zumeist Fachanwender) weitergeben.

Folgendes Skript hinterlegt die passenden Kommentare zu den Feldern des Kundenstamms.

Customer:
LOAD Firma,
    `Kunden-Code`,
    Land,
    Ort,
    PLZ,
    Region;
SQL  select
*
FROM Kunden;

Mapping_FieldComments:
Mapping
LOAD * INLINE [
    Field, Comment
    Firma, Company Long Name 
    Kunden-Code, Company Unique ID
    Land, Country Long Name from Customer Dimension
    Ort, City Long Name from Customer Dimension
    PLZ, Zip Code from Customer Dimension
    Region, Region Long Name
];

comment fields using Mapping_FieldComments;

Damit erhält der Benutzer am QlikView Frontend in der Tabellenvorschau und bei "Felder auswählen" die Feldbeschreibungen als Tooltip:


Bisher hatte ich verstanden, dass diese Kommentar-Information in der .qvw hinterlegt ist. Eleganter wäre es natürlich, wenn die Kommentare in der .qvd abgespeichert wären. Greift eine .qvw auf die Daten einer .qvd zu, so sollten auch die Kommentare in der Applikation zur Verfügung stehen. So hätte man die gleiche Feldbeschreibungen in jeder .qvw die auf diese .qvd aufsetzt!

Kommentar in .qvd gespeichert

Über einen Supportcase entdeckte ich indirekt folgende Information: Öffnet man die .qvd mit einem Texteditor (oder mit einem der netten QVD-Viewer die es mittlerweile gibt. zB EasyQlik QViewer), findet sich im XML-Header der .qvd-Datei doch tatsächlich ein Tag <Comment> das die Kommentarinformation für jedes Feld enthält!


Sehr nett! Die Frage nun: würde meine Idee mit der zentralen Speicherung der Feldbeschreibungen in .qvds auch funktionieren? Folgende 3 Tests habe ich durchgeführt:

1) Lädt man die .qvd UNOPTIMIZED, erscheinen die Kommentare leider nicht in der .qvw:

LOAD Firma, 
     [Kunden-Code], 
     Land, 
     Ort, 
     PLZ, 
     Region
FROM
Customer.qvd
(qvd) where 1=1;  //unoptimized

2) Lädt man die .qvd OPTIMIZED, bekommt man tatsächlich die Kommentare in der .qvw angezeigt.

LOAD Firma, 
     [Kunden-Code], 
     Land, 
     Ort, 
     PLZ, 
     Region
FROM
Customer.qvd
(qvd);  //optimized

3) Der BINARY-Load verhält sich lieder genauso wie der "UNOPTIMIZED"-Load. Die Feldkommentare werden in QV11.20SR3 nicht in die .qvw übernommen. Abhilfe schafft hier, indem man die .qvd als XML-Datei lädt und sich die Kommentare so manuell hinzufügt:

Binary [2_loadqvd_optimized.qvw];
//SET Variables here

Mapping_QvdFieldHeader:
Mapping
LOAD FieldName,
    Comment
FROM Customer.qvd (XmlSimple, Table is [QvdTableHeader/Fields/QvdFieldHeader]);


comment fields using Mapping_QvdFieldHeader;

Somit haben wir momentan ein "JEIN" als Antwort auf  die Frage einer zentralen Speicherung von Feldbeschreibungen in .qvds! Ich bin gespannt ob die Lücke in neuen ServiceReleases geschlossen wird. Für Fall 1) UNOPTIMIZED gibt es zumindest schon eine BugID!


Alle Beispiele zum Nachvollziehen und Ausprobieren finden sich unter: http://www.heldendaten.eu/blog/commentField_StoredInQVD.zip

QlikView Scripte extern zu speichern ist aus vielen Gründen sinnvoll:

• Config Dateien extern halten
• Wiederkehrende Skriptteile nur einmal pflegen (zB KalenderScript, oder Libraries wie QlikView Components
• Datenbank Connections extern halten, um zwischen Entwicklungs- und Produktivumgebung nicht manuell in die .qvw eingreifen zu müssen.

Der Qlikview Befehl für externe Skripte lässt sich im Skripteditor generieren und erzeugt für eine externe Datei "scriptfile.txt" folgenden Include-Befehl:

$(Include=.\scriptfile.txt);

So weit, so gut! Nur was passiert wenn die Datei scriptfile.txt nicht existiert (weil das File versehentlich in einem anderen Verzeichnis liegt, oder man sich vertippt hat)? Der erfahrende Qlikview Entwickler weiß: Es passiert gar nichts! Per Definition ignoriert QlikView das Fehlen des externen Skripts und läuft einfach mit dem restlichen Skript weiter! Im besten Fall bekommt man einen (irreführenden) Folgefehler, weil zb. die im include-File gepflegte Datenbank-Connection nicht geöffnet werden konnte. Die Fehlersuche kann dann aber häufig langwierig sein, da man zumeist nicht als erstes an das nicht-vorhandene Include-File denkt.

Ein ähnliches Verhalten kennt man aus PHP! Dort können externe Skripte mit "include" (entspricht der QlikView-Denke) oder mit "require" (wirft einen Fehler wenn die externe Datei nicht gefunden wurde) eingebunden werden.

Gibt es nun ein "require"-Verhalten in QlikView? Ja, gibt es - aber erstmal gut versteckt! Toni Kautto hat es als Erster in einem QlikCommunity-Forumthread folgende Lösung gepostet:

$(must_include=scriptFile.txt);

Testet man mit einem Script wie im Screenshot unterhalb, so wirft $(must_include) einen Fehler der klar zeigt, daß die Datei "doesNotExist.txt" vom must_include-Befehl nicht gefunden werden konnte!


In QV11.20 SR3 lässt sich der Befehl nun auch in der offiziellen Dokumentation finden. Damit können hoffentlich auch alle Sorgen (wie an anderen Stellen  in der QlikView Blogosphere geäußert) zerstreut werden, dass dieses Feature nicht offiziell supported ist!


Viel Spaß beim Abändern Ihrer existierenden Skripte & einen schönen Sommer!
Ihr heldendaten Team

QlikView bietet zu jedem Objekt in der Titelleiste ein Kommentar-Feld an. Dieses Feld ist sehr praktisch um kurze Erklärungen zu jedem Objekt zu verfassen. Wer aber komplexere Informationen hinterlegen will, würde vielleicht gerne auf eine Wiki-Seite mit detaillierter Dokumentation verweisen.

Leider interpretiert QlikView im Kommentarpopup keine Hyperlinks. Ein Klick auf das Kommentar-Popup schließt dieses, und man kehrt zu QlikView zurück. QlikView bietet uns im Full Browser/AJAX-Client ab Version 11 eine schöne Möglichkeit dieses Verhalten zu ändern: Document Extensions.

Document Extensions sind GUI-lose Modifizierungen, mit denen man das Verhalten des AJAX-Clients abändern kann. In der folgenden Document Extension wollen wir also anstatt das Popup zu schließen, lieber dem Hyperlink zu unserer Detaildokumentation folgen!

Für den Anwender

Für den Anwender kann das also wie folgt aussehen (eine Livedemo finden sie unter demo.heldendaten.net):

1) Normales QlikView Verhalten: Das Kommentar wird bei MouseOver als Tooltip angezeigt

Document Extension

Was ist passiert? Technisch läuft beim Öffnen der Applikation ein kleiner Javascript Code der sich zum Klick-Event des Kommentar-Popups hängt.

Qva.AddDocumentExtension('HD_ClickCommentExtension', function() {
       
    //Add Pointer-Cursor to class QvMessagePopup table 
    $("").appendTo("head");
    
    $("body").on("click", ".QvMessagePopup table", function(event){
        var comment = $(this).text();
        var URL = "";
        //extract URL from Comment 
        //Text between < >  is interpreted as URL
        URL = comment.substring(comment.indexOf('<') + 1,comment.indexOf('>'));
        //Check if it's a valid URL
        if(/^(http|https|ftp):\/\/[a-z0-9]+([\-\.]{1}[a-z0-9]+)*\.[a-z]{2,5}(:[0-9]{1,5})?(\/.*)?$/i.test(URL)){
          //Open new tab
          window.open(URL);
        }
        else
        { if (URL.length > 0)
            alert("Sorry, no URL");
        }
    });
  
});

Findet die Dokument-Extension im KommentarText eine URL in spitzen Klammern (<URL>), dann öffnet es beim Klick mit window.open() die Seite.

Wie bekommt man die Document Extension in die .qvw?

Eine Document Extension ist genauso ein .qar-Packet wie herkömmlichen Extensions. Ein Doppelklick auf die Extension führt die Installation im QVDeveloper durch.
Um die Document Extension in die .qvw hinzuzufügen, muß man den Menüpunkt "Eigenschaften des Dokuments|Tab Erweiterungen" aufrufen. Dort kann man die installierte Document Extension als "Aktive Erweiterung" definieren.


Damit funktioniert die Extension im WebView-Modus des QlikView Developers. Um die Extension für alle Benutzer am Server verfügbar zu machen, muss man sie am Server unter den Defaultpfad entpacken: C:\ProgramData\QlikTech\QlikViewServer\Extensions\Document\HD_ClickCommentExtension