Auf in eine transparente Zukunft

Vor einigen Wochen hatte ich die Anfrage alle "zukünftigen" Balken in einem gestapelten Balkendiagramm transparent darzustellen. Konkret ging es um Lagerbewegungen die bis in die Zukunft projiziert werden. Die Transparenz soll dem Anwender helfen zu sehen, ab welchem Monat es sich um "Forecast"-Zahlen handelt.

Aufgrund der Vielzahl an Produkten war es nicht gewünscht bereits im Skript Farben für jedes Produkt zu hinterlegen. Deswegen wollten wir die Standardfarben von QlikView benutzen.

Die Aufgabenstellung: Ab November (aktuelles Monat) die Balken transparent darstellen)

Mein erster Ansatz funktionierte, verlangt aber viele unschöne Stringoperationen:

if(Month >= month(today()),
 argb(120,
   mid(color(rowno()),5,3),
   mid(color(rowno()),9,3),
   mid(color(rowno()),13,3)
    )
 ,
 color(rowno())
)

Aus der aktuellen Farbe des Balkens color(rowno()) schneidet die Formel die Stellen für RGB aus, und füge Sie mit Transparenz 120 wieder in die ARGB()-Formel ein.

Farben in QlikView

Für eine bessere Lösung muss man sich zuerst klar werden, wie Farben in QlikView funktionieren. Jede Farbfunktion in QlikView liefert eine Zahl zurück. Ruft man etwa =num(black()) auf, bekommt man folgenden dezimalen Output:

Was auf den ersten Blick nach einer zufälligen Dezimalzahl aussieht, ist bei näherer Betrachtung eine Bit-Darstellung einer ARBG-Farbe. QlikView bietet fertige Funktionen um Zahlen in beliebigen Zahlenbasen darzustellen. Mit der Funktion =num(black(),'(hex)') bekommt man den aussagekräftigeren Hexadezimalen-Wert für die Farbe Schwarz: ff000000!

QlikView liefert also für jede Farbe einen ARGB-Wert zurück. Insgesamt haben wir als für jede Farbinformation 1 Byte = 8 Bit zur Verfügung. black() ist also nichts anderes als Rot=0, Grün=0, Blau=0 mit einer vollen Deckkraft von A=FF(hex)


Die Farbe Schwarz binär dargestellt liefert QlikView mit der Funktion =num(black(),'(bin)').
Man erinnere sich an seine Informatik-Ausbildung: 1Hex-Stelle sind 4 bit!

 

Transparent rechnen

Mit diesem Wissen lässt sich nun die Transparenz viel einfacher manipulieren.  Um den Transparentwert beispielsweise zu "dreivierteln" könnte man das 30. bit auf 0 setzen. Um das zu erreichen, kann man von der Farbe  2 hoch 30 abziehen: =num(black() - pow(2,30),'(bin)')

Zurückkommend auf die ursprüngliche Fragestellung, kann man jetzt komplett ohne String-Operationen auskommen. Die Formel um die Balken halb-transparent darzustellen lautet nun

if(Month >= month(today()),
 color(rowno()) - pow(2,31)
 ,
 color(rowno())
)

Das fertige Chart

Download Beispiel

Qv.exe /nodata als Shortcut am Desktop

Arbeitet man mit großen QlikView Applikationen, kann das Öffnen einer .qvw von der Festplatte schon mal etwas dauern. Will man aber nur schnell das Skript nachlesen, oder eine komplizierte Formel (bzw. ein ganzes Objekt) kopieren, ist es oft gar nicht notwendig die .qvw mit gesamten Daten zu öffnen.

Hat man die QlikView Applikation unter den "Zuletzt geöffneten Dateien" auf der Startseite gelistet, kann man mittels Rechtsklick|'Applikation ohne Daten öffnen' wählen.
Hat man die .qvw jedoch nicht in der Startliste, so müßte man kompliziert die Qv.exe mit dem Commandlineparameter /nodata benutzen. Wem das zu kompliziert ist, kann sich einen entsprechenden Shortcut am Desktop anlegen. Einfach den Pfad

                                        "C:\Program Files\QlikView\Qv.exe" /nodata


als Shortcut anlegen. Wenn man nun mittels Drag&Drop die .qvw auf den Shortcut fallen läßt, dann öffnet der QlikView Developer die Applikation ohne Daten. Die Applikation zeigt nun alle Listboxen mit "nicht verfügbar" an, aber das Skript und die Objektdefinitionen sind schnell griffbereit.

Eine kleine Warnung: Speichern Sie bitte die .qvw nur mit großer Vorsicht, nachdem Sie diese mit /nodata geöffnet haben. Leider werden bei diesem Feature nämlich keine Frontend-Variablen mitgeladen. Speichern Sie also die .qvw, dann gehen diese Variablen verloren. Gleiche Problematik hat übrigens auf das "-prj"-Ordner Feature für SVN/Team Foundation Server Integration! Als Workaround hilft nur, alle Variablen bereits im Skript zu definieren!

Update QV11.20SR4 12.11.2013
Öffnet man eine QlikView Applikation mit /nodata in  QV11.20 SR4 12129 werden Variablen nun korrekt mitgeladen. In den Release-Notes konnte ich zwar keine Anmerkung finden, aber wie der Screenshot unterhalb zeigt, sind bei meinem Test alle 3 Frontend-Variablen befüllt (nur das Tabellendiagramm kann natürlich nicht dargestellt werden, weil ja keine Daten geladen wurden). Zum Vergleich: QV10SR4 zeigt leere Variablendefinitionen.



Für den -prj-Folder konnte ich keine Änderung feststellen, also hier ist die Warnung weiterhin aufrecht!









QlikView Master Summit - Drop Fields Diskussion

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.


Masters Summit for QlikView

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.

Masters Summit for QlikView

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





Comment your .qvds - Zumindest bei Optimized Load!

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
heldendaten GmbH,2020