Wiederverwendung einer vorhandenen App
Letzte Aktualisierung: 14.10.2026QV2QS kann eine bestehende Qlik Sense-App als Ziel verwenden, anstatt bei jeder Bereitstellung eine neue App zu erstellen, was eine iterative Entwicklung ermöglicht und die App-ID beibehält.
Standardmäßig erstellt QV2QS bei jeder Bereitstellung eine neue App. Wählen Sie stattdessen eine vorhandene App als Ziel aus, um die App direkt zu aktualisieren und die App-ID beizubehalten. Dieser Ansatz ermöglicht eine iterative Entwicklung und behält Lesezeichen und Links bei, die auf eine bestimmte App-ID verweisen.
Drei Argumente sprechen für die Wiederverwendung:
--appId APP_ID— Geben Sie die App-ID direkt an.--appIdFile PATH— Liest die App-ID aus der ersten Zeile einer Textdatei.--reuseAppId— Lesen Sie die App-ID auscloud/cloud_state.jsonim Projektunterordner aus. Diese Datei wird nach jeder Bereitstellung automatisch geschrieben.
Die Datei cloud/cloud_state.json wird im Projektunterordner gespeichert (z. B. <outputDir>/Sales/cloud/cloud_state.json). Die Datei erfasst die App-ID, den Medien-Hash, die Arbeitsblatt-ID-Zuordnung, den Quelldateipfad und einen Zeitstempel. Das Flag --reuseAppId liest diese Datei automatisch, sodass nachfolgende Ausführungen dieselbe App aktualisieren, ohne dass eine manuelle Eingabe der App-ID erforderlich ist. Im Batch-Modus arbeitet --reuseAppId pro Projekt — jedes Projekt liest cloud_state.json aus seinem eigenen Ausgabeunterordner.
Sheet-ID-Zuordnung
Jedes QlikView-Dokument identifiziert Arbeitsblätter anhand interner Namen wie Document\SH01, Document\SH02 und so weiter. Qlik Sense verwendet UUIDs, um Arbeitsblätter zu identifizieren. Wenn QV2QS eine App zum ersten Mal bereitstellt, erhält jedes konvertierte Arbeitsblatt eine neue UUID. QV2QS speichert die Zuordnung zwischen dem QlikView-Arbeitsblattnamen und der Qlik Sense-UUID in der Ziel-App, sodass die Beziehung über Bereitstellungen hinweg erhalten bleibt.
Bei nachfolgenden Bereitstellungen in derselben App liest QV2QS die gespeicherte Zuordnung und weist den entsprechenden konvertierten Arbeitsblättern die ursprünglichen Qlik Sense-UUIDs zu. Die Zuordnung verhindert, dass duplizierte Arbeitsblätter in der App angezeigt werden, und behält Lesezeichen, Favoriten und direkte Links bei, die auf eine bestimmte Arbeitsblatt-ID verweisen.
Die Zuordnung wird an zwei Orten gespeichert:
- In der Qlik Cloud-App — Ein dediziertes Objekt innerhalb der App enthält die Zuordnung. Die Zuordnung wird mit der App übertragen, wenn die App in einen anderen Bereich verschoben oder als QVF exportiert wird.
- Im lokalen Projektordner — Die Datei
cloud/cloud_state.jsonenthält eine Kopie derselben Zuordnung. Das Flag--reuseAppIdliest die App-ID und die Zuordnung aus dieser Datei.
QV2QS liest bei der Vorbereitung einer erneuten Bereitstellung das Mapping immer aus der Cloud-App (nicht aus der lokalen Datei). Die lokale Datei ist eine Erleichterung für das Flag --reuseAppId, um die App-ID zu ermitteln.
Medien-Hash-Optimierung
QV2QS berechnet einen Hash aller Mediendateien (Arbeitsblatthintergründe, Objekthintergründe, Schaltflächenbilder) und speichert den Hash zusammen mit der Arbeitsblattzuordnung. Bei nachfolgenden Bereitstellungen vergleicht QV2QS den aktuellen Hash mit dem gespeicherten Wert. Wenn sich die Medien nicht geändert haben, wird der Upload-Schritt vollständig übersprungen.
Zuordnungsvalidierung
Bevor Arbeitsblätter für den Austausch vorbereitet werden, validiert QV2QS das gespeicherte Mapping anhand der Live-App. Wenn ein Arbeitsblatt zwischen Bereitstellungen manuell aus der Qlik Cloud-App gelöscht wurde, erkennt QV2QS, dass das Arbeitsblatt nicht mehr vorhanden ist, entfernt den veralteten Eintrag aus der Zuordnung und behandelt das entsprechende QlikView-Arbeitsblatt beim nächsten Build als neu. Die aktualisierte Zuordnung wird nach Abschluss des Builds in die App zurückgeschrieben.
In der QlikView-Quelle hinzugefügte oder entfernte Arbeitsblätter
Wenn der QlikView-Quelle nach der anfänglichen Bereitstellung ein Arbeitsblatt hinzugefügt wird, weist QV2QS dem Arbeitsblatt eine neue UUID zu und fügt den Eintrag der Zuordnung hinzu. Wenn ein Arbeitsblatt aus der QlikView-Quelle entfernt wird, ist das Arbeitsblatt nicht mehr in der Build-Ausgabe vorhanden und wird während des Builds aus der Qlik Cloud-App entfernt. Der Zuordnungseintrag für das entfernte Arbeitsblatt wird nicht übernommen.
Projektordner-Abgleich
QV2QS schreibt nach der ersten Konvertierung eine .qv2qs_source-Markerdatei in jeden Projektausgabeordner. Der Marker speichert den vollständigen Pfad der QVW-Quelldatei. Bei nachfolgenden Durchläufen verwendet QV2QS die Markierung, um den korrekten Projektordner für eine bestimmte QVW-Datei zu ermitteln, selbst wenn mehrere Ordner denselben Basisnamen haben (zum Beispiel Sales/, Sales_2/, Sales_3/).
Die Markierung stellt sicher, dass jede QVW-Datei genau einem Ausgabeordner zugeordnet ist. Beim Konvertieren einer QVW-Datei, die zuvor bereits konvertiert wurde, durchsucht QV2QS das Ausgabestammverzeichnis nach einem Unterordner, dessen Marker mit dem Quellpfad übereinstimmt. Wenn eine Übereinstimmung gefunden wird, verwendet QV2QS diesen Ordner wieder und liest die cloud_state.json darin. Wenn keine Übereinstimmung gefunden wird, erstellt QV2QS einen neuen Unterordner mit einem numerischen Suffix.
Im Assistenten gilt dieselbe Zuordnungslogik. Wenn Vorhandene App wiederverwenden aktiviert ist, prüft der Assistent den Ausgabeordner auf ein übereinstimmendes Projekt und füllt das Feld AppId automatisch aus der vorherigen Bereitstellung aus. Wenn keine vorherige Bereitstellung gefunden wird, bleibt das Feld leer und akzeptiert manuelle Eingaben oder die Durchsuchen-Auswahl.
Die .qv2qs_source-Markerdatei wird automatisch erstellt. Bearbeiten oder löschen Sie die Datei nicht. Das Entfernen der Markierung führt dazu, dass QV2QS beim nächsten Durchlauf einen neuen Projektunterordner erstellt, anstatt den vorhandenen wiederzuverwenden.
Verhalten bei erneuter Bereitstellung
QV2QS verwendet qlik app build, um in der Ziel-App bereitzustellen. Der Build-Befehl führt eine vollständige Ersetzung des App-Objektmodells durch. Alle in der Build-Ausgabe definierten Objekte werden in die App geschrieben. Objekte, die nicht in der Build-Ausgabe vorhanden sind, werden entfernt.
Vor der Ausführung des Builds bereitet QV2QS bestehende Arbeitsblätter auf die Ersetzung vor. QV2QS validiert die Arbeitsblattzuordnung anhand der Live-App (siehe Arbeitsblatt-ID-Zuordnung), erfasst den Veröffentlichungsstatus und den Rang jedes Arbeitsblatts und entfernt die alten Arbeitsblätter aus der Cloud-App. Die lokale Build-Ausgabe wird mit den ursprünglichen Qlik Sense-Arbeitsblatt-IDs gepatcht, sodass Lesezeichen und Links, die auf diese IDs verweisen, nach dem Build weiterhin funktionieren.
Nachdem der Build abgeschlossen ist, stellt QV2QS den ursprünglichen Zustand des Arbeitsblatts wieder her. Zuvor veröffentlichte Arbeitsblätter werden erneut als Basis-Arbeitsblätter veröffentlicht, und der ursprüngliche Rang (Anzeigereihenfolge) wird wiederhergestellt. Neue Arbeitsblätter, die in der vorherigen Bereitstellung nicht vorhanden waren, werden als Basis-Arbeitsblätter veröffentlicht, wenn die Einstellung Arbeitsblätter veröffentlichen aktiviert ist. Deaktivieren Sie die Einstellung, um neue Arbeitsblätter unveröffentlicht zu lassen.
Vom Benutzer erstellte Inhalte in der Ziel-App (manuell hinzugefügte Arbeitsblätter, Lesezeichen, Storys oder benutzerdefinierte Objekte, die nach der vorherigen Bereitstellung erstellt wurden) bleiben bei einer erneuten Bereitstellung nicht erhalten. Der Befehl qlik app build ersetzt den Inhalt der App durch die Build-Ausgabe. Sichern oder veröffentlichen Sie die App vor der erneuten Bereitstellung, wenn manuelle Anpassungen vorgenommen wurden.
Sicherung vor der Bereitstellung
Bei der Wiederverwendung einer bestehenden App exportiert QV2QS automatisch ein QVF-Backup ohne Daten, bevor die App geändert wird. Das Backup erfasst die App-Struktur (Arbeitsblätter, Objekte, Ladeskript und Metadaten) ohne Daten, sodass sich die App schnell exportieren lässt und die Datei klein ist.
Backups werden in cloud/backups/ innerhalb des Projektausgabeordners gespeichert. Jede Sicherungsdatei heißt <AppName>_<shortId>_<timestamp>_nodata.qvf. Zum Beispiel Sales_a1b2c3d4_20260226-143025_nodata.qvf.
Wenn das Exportieren des Backups fehlschlägt (beispielsweise aufgrund einer Netzwerkunterbrechung oder unzureichender Berechtigungen), protokolliert QV2QS eine Warnung und fährt mit der Bereitstellung fort. Der Fehler blockiert die Konvertierung nicht.
Um das automatische Backup zu überspringen, übergeben Sie --noBackup in der Befehlszeile oder aktivieren Sie Backup vor der Bereitstellung überspringen im Assistenten. Das Überspringen des Backups ist in CI/CD-Pipelines nützlich, in denen Backups extern verwaltet werden.
Beibehalten des Ladeskripts der Ziel-App
Standardmäßig ersetzt QV2QS das Ladeskript in der Ziel-App durch das konvertierte Ladeskript aus der QlikView-Quelle. Verwenden Sie --preserveTargetAppScript, um das bestehende Ladeskript in der Ziel-App unverändert beizubehalten. Das konvertierte Ladeskript wird in die lokale build/script.qvs-Datei geschrieben, aber nicht auf die Cloud-App angewendet.
Diese Option erfordert --appId oder --reuseAppId, da sie nur gilt, wenn eine vorhandene App das Ziel ist. Es kann mit --reload kombiniert werden, um das bestehende Skript nach der Aktualisierung der Benutzeroberfläche auszuführen, was nützlich ist, wenn die Ziel-App bereits über funktionierende Qlik Cloud-Datenverbindungen verfügt. Es kann auch mit --autoBinary kombiniert werden, um vorübergehend Daten aus der ursprünglichen QVW-Datei zu laden, während das Zielskript intakt bleibt.
Beibehalten der Ziel-App-Variablen
Standardmäßig ersetzt QV2QS die Variablen in der Ziel-App durch die konvertierten Variablen aus der QlikView-Quelle. Verwenden Sie --preserveTargetAppVariables, um die vorhandenen Variablen in der Ziel-App unverändert beizubehalten. Die konvertierten Variablen werden in die lokale variables.json-Datei geschrieben, aber nicht auf die Cloud-App angewendet.
Diese Option erfordert --appId oder --reuseAppId, da sie nur gilt, wenn eine vorhandene App das Ziel ist. Es kann mit --preserveTargetAppScript kombiniert werden, um sowohl das Ladeskript als auch die Variablen aus der Ziel-App intakt zu halten.