Werte eines Tabellendiagramms mittels Code exportieren
Hallo Leute,
gibt es eine Möglichkeit, die Werte eines Tabellendiagramms in eine Excel (oder csv, txt..) mittels Code zu exportieren?
Ich habe es mit folgendem Code probiert aber bekomme nur eine Datei mit irgendeinem XML-Inhalt und nicht die Werte des Diagramms:
CH63_Tab:
Load
Datum,
offen,
abgeschlossen
FROM [C:\Mein Qlikviewbericht.qvw](xmlSimple, Table is [CH63]);
SET vExportFile = 'c:\CH63_Tab.xlsx';
Store CH63_Tab INTO $(vExportFile)[ooxml, embedded labels];
DROP Table CH63_Tab;
CH63 wäre der Name des Tabellendiagramms was in den Diagrammeigenschaften im Tab Allgemein steht.
Mache ich was falsch oder ist sowas garnicht möglich?
Sofern NPrinting zur Verfügung steht, sollte man auch das nutzen und nicht eigene Makro-Lösungen entwickeln.
Wie gut sich solche Extraktionen wieder einbinden lassen, wird von einer ganzen Reihe an Parametern abhängen, insbesondere wie interaktiv diese Daten ins Datenmodell integriert werden sollen. So wäre u.a. denkbar, auch gar keine Verlinkung vorzunehmen, sondern diese Daten als loosen table einzuladen. Die Verknüpfung über ein oder zwei Key-Felder, z.B. der Perioden und/oder Produkt-Kategorien und/oder Regional-Strukturen ist vermutlich auch nicht sonderlich schwierig und/oder aufwändig (jeder weitere Schritt wird dann eher exponentiellen als linearen Aufwand bedeuten). Klar ist dann, das Objekt kann nur bedingt mit den anderen/normalen Auswahlen genutzt werden. Für den jeweiligen Verwendungszweck muss das aber auch nicht unbedingt mehr sein - entsprechende Hinweise im Titel des Objekts und/oder im Sheet würden etwaige Verwirrungen vermeiden.
Davon abgesehen stellt sich auch die Frage, muss das Ganze denn überhaupt sein - denn Zeitverläufe lassen sich prinzipiell auch so in Qlik abbilden. Auch bei etwas komplexeren Szenarien, wie Was-Wäre-Wenn-Thematiken mit Variablen-Parametern oder ähnliches sollte man das nicht grundsätzlich ausschließen.
Es ist nicht möglich vom Skript aus auf Daten und Objekte der Oberfläche innerhalb einer Anwendung zuzugreifen, denn zu diesem Zeitpunkt existiert noch keine Oberfläche. Ein externer Zugriff auf Objekte ist zwar möglich, jedoch bestehen hier alle Objekte nur aus den Meta-Daten, also welche Formeln und Dimensionen werden wo verwendet, und nicht aus den Daten, die jeweils nur zur Laufzeit bzw. beim Aufruf und/oder Änderungen im Selection-State evaluiert werden.
Alternativ wäre der Export per (VBS) Makros. Hierzu gibt es multiple Postings in der Community und sehr hilfreich ist hier auch der APIGuide.qvw, der sich irgendwo im QlikView Installationsverzeichnis bei Automation befindet. So eine Export-Routine selbst ist ziemlich simpel - jedoch kann es recht komplex werden, diese zu triggern, denn z.B. der AJAX client führt diese Makros nicht aus und auch über die qmc gestartete Tasks führen die Makros nicht aus.
Insofern sollte geprüft werden, ob diese Informationen nicht auch und/oder sogar einfacher/besser direkt aus dem Load erzeugt werden. Prinzipiell sind ja alle erforderlichen Daten vorhanden und es bedarf vielleicht nur einer extra Aggregation mit Filtern + Berechnung, um diese Daten zu generieren - die man dann als csv speichert (xlsx steht nicht als Speicherformat zur Verfügung).
Ich benötige wöchentlich ein Snapshot von ein paar Diagrammen, die ich dann wiederum in den Bericht laden kann, um eine Historie zu sehen.
Ich habe erst mit dem Store Befehl probiert, die verwendeten Tabellen zu extrahieren. Das funktioniert auch ganz gut und simpel. Nur beim Laden der Tabellen kommt es zu Problemen wegen den Keyfeldern die die gleichen Namen haben. Und ich bin mir dabei auch nicht sicher ob es genügt nur die verwendeten Tabellen zu extrahieren oder auch alles andere drumherum die mit den Keys verbunden sind, damit das richtig funktioniert. Wenn ja, dann wird mir das viel zu komplex.
Eine alternative wäre noch die Diagramme mittels Nprinting-Job als Excel zu extrahieren. Ich dachte aber es gäbe bessere Möglichkeiten.
Das mit den Makros wäre auch keine Option für mich.
Sofern NPrinting zur Verfügung steht, sollte man auch das nutzen und nicht eigene Makro-Lösungen entwickeln.
Wie gut sich solche Extraktionen wieder einbinden lassen, wird von einer ganzen Reihe an Parametern abhängen, insbesondere wie interaktiv diese Daten ins Datenmodell integriert werden sollen. So wäre u.a. denkbar, auch gar keine Verlinkung vorzunehmen, sondern diese Daten als loosen table einzuladen. Die Verknüpfung über ein oder zwei Key-Felder, z.B. der Perioden und/oder Produkt-Kategorien und/oder Regional-Strukturen ist vermutlich auch nicht sonderlich schwierig und/oder aufwändig (jeder weitere Schritt wird dann eher exponentiellen als linearen Aufwand bedeuten). Klar ist dann, das Objekt kann nur bedingt mit den anderen/normalen Auswahlen genutzt werden. Für den jeweiligen Verwendungszweck muss das aber auch nicht unbedingt mehr sein - entsprechende Hinweise im Titel des Objekts und/oder im Sheet würden etwaige Verwirrungen vermeiden.
Davon abgesehen stellt sich auch die Frage, muss das Ganze denn überhaupt sein - denn Zeitverläufe lassen sich prinzipiell auch so in Qlik abbilden. Auch bei etwas komplexeren Szenarien, wie Was-Wäre-Wenn-Thematiken mit Variablen-Parametern oder ähnliches sollte man das nicht grundsätzlich ausschließen.
