Qlik Cloud an OpenMetadata: einen begrenzten Pilot Schritt für Schritt aufbauen
Versionsbezug: Qlik Cloud SaaS · Prüfstand 23.10.2026 · 2026-10-23
Kein festes Client-Managed-Release: regionale Rollouts, Subscription und UI vor Umsetzung prüfen. Gateway-/Connectorversionen separat festhalten. Schrittfolgen können sich nach Updates ändern.
Qlik: What is new / staged rollouts ↗ Qlik: Space-Typen / Space types ↗ Referenz geprüft: 2026-10-23
Schritt-für-Schritt-Referenz: Qlik Cloud an OpenMetadata: einen begrenzten Pilot Schritt für Schritt aufbauen. Mit Pilotabnahme, Grenzen und Quellenstand 23.10.2026.
Versions- und Quellenstand: Qlik Cloud (SaaS), 23.10.2026. Kein festes Qlik-Sense-Client-Managed-Release. Cloudoberfläche und Funktionsumfang können sich auch bei kleineren Updates ändern; regionale Rollouts, Subscription und Tenantkonfiguration vor Umsetzung prüfen. Installierte Gateway-/Connectorversionen separat protokollieren. Redaktionell gegen Herstellerhilfe geprüft, nicht im Kundentenant ausgeführt.
Was der externe Katalog zusätzlich leisten soll
Ein externer Katalog ist ein eigenes System für Metadaten. Er kann fachliche Beschreibungen und Herkunft über mehrere Plattformen zusammenführen. Er ist nicht automatisch der Ort, an dem Qlik-App-Rechte erzwungen werden. Definiere vor dem Connector, welche konkrete Frage heute unbeantwortet bleibt, beispielsweise: „Welche freigegebenen Apps hängen von dieser Lieferung ab?“
Schritt für Schritt: einen Import mit Soll-Inventar abnehmen
- Lege
qlik_cloud_sales_prdals vorgesehenen Servicenamen fest. Verwende keine Personen- oder wechselnden Versionsnamen. Notiere Tenant-ID und die veröffentlichte Monats-App-ID aus der Grundlagenserie. - Erstelle eine Soll-Liste: ein konkretes App-Objekt, ein bekanntes Auswertungsobjekt und die erwartete Quelle. Trage IDs beziehungsweise tatsächlich gelieferte Kennungen ein; ein Sheet ist nicht ohne Prüfung gleichbedeutend mit jeder vom Connector erzeugten Dashboard-/Chart-Entität.
- Führe mit dem später beschriebenen Connector einen kleinen Import aus. Vergleiche jedes Soll-Objekt mit dem Ist-Objekt: Name, ID, Typ, Link und Umgebung. Zähle nicht nur eine grüne Laufmeldung.
- Verwende als Gegenprobe eine zweite, ähnlich benannte Test-App, die ausgeschlossen bleiben soll. Prüfe Filterwirkung und Berechtigungen mit dem tatsächlich verwendeten Runner-Konto.
- Ändere in der freigegebenen Testfassung einen bekannten Metadatenwert, führe erneut aus und halte fest, was aktualisiert wurde. Prüfe außerdem, ob bewusst extern kuratierte Beschreibung oder Verantwortung erhalten bleibt.
- Öffne den Katalog als dortiger Consumer. Ein Qlik-Link darf erst in Qlik selbst erlaubten Inhalt öffnen; die externe Beschreibung muss zusätzlich mit den Katalogrechten vereinbar sein.
Abnahmeergebnis: eine Liste erwarteter, gefundener, falscher und fehlender Objekte. Eine fehlende QVD-Kante wird nicht mit einem geratenen Datenbankobjekt ersetzt. Die Lücke erhält Ursache, verantwortliche Rolle und eine überprüfbare Schließungsmaßnahme.
Gegenstand und Versionsgrenze
Dieser Leitfaden verwendet die OpenMetadata-Dokumentationslinie 2.0.x, geprüft am 23.10.2026. Server, Ingestion-Paket und Runner müssen zur eingesetzten Version passen. Qlik Cloud und Qlik Sense Client-Managed haben unterschiedliche Connectorwege. Ein Cloud-Token ist kein Ersatz für ein Sense-Zertifikat.
Der Pilot soll eine bekannte produktive App, ihre Auswertungen und einen nachvollziehbaren Datenbezug zeigen. Er muss nicht alle Apps des Unternehmens importieren. Metadaten können selbst sensibel sein: Feldnamen, Querytexte oder interne Links enthalten möglicherweise Schutzbedarf, auch wenn keine Datensamples übertragen werden.
Schritt für Schritt
- Pilotkarte schreiben. Tenant, Space-ID, App-ID, ein Sheet/Chart, ein erwartetes Datenmodellobjekt und die bekannte Quelle festhalten. Dazu bewusst ausgeschlossene Apps und ein Metadaten-Leserkreis. Mit genau diesen Objekten später Vollständigkeit messen.
- Ingestion-Identität begrenzen. Den von der Connectorversion unterstützten Qlik-API-Token für eine kontrollierte Identität verwenden. Qlik-Rollen, Space-Zugriff, Tokenablauf und Rotation dokumentieren. Nicht für eine schnellere Fehlersuche pauschal Tenant-Admin geben. API-Verfügbarkeit und Unterstützung vorab prüfen.
- Runner vorbereiten. DNS, Proxy, TLS-Vertrauen und ausgehende Verbindung zu Qlik sowie OpenMetadata prüfen. Secrets auf dem ausführenden Runner bereitstellen. Ein Verbindungstest am eigenen Laptop beweist nicht die Erreichbarkeit im Container oder geplanten Runner.
- Dashboard Service erstellen. In OpenMetadata zu Settings → Services → Dashboard Services gehen und Qlik Cloud wählen. Eindeutigen Servicenamen wie
qlik_cloud_sales_prodvergeben; Tenant-Basisadresse in Host Port und Credential in das Secret-Feld. Keine echte Tokenzeichenfolge in eine Story oder Git-Datei kopieren. - Space-Typen und Filter festlegen. Nur benötigte Space-Typen und den Pilotumfang einschließen. Die UI erläutert die versionsabhängigen Felder; die aktuelle Anleitung beschreibt Namensfilter als reguläre Ausdrücke. Ein Includes-Muster ausdrücklich gegen ein gewünschtes und ein ausgeschlossenes Objekt testen. Ein auswählbarer Space-Typ verleiht keine Rechte auf dessen Inhalte.
- Verbindung testen und Ingestion ausführen. Lauf-ID, Warnungen, Objektanzahlen und Zeitpunkt sichern. Keine sensiblen Logdetails in breit sichtbare Tickets kopieren. Bei fehlender App zuerst Sichtbarkeit der Identität und Filter überprüfen, nicht blind mehr Rechte vergeben.
- Quellbezug ergänzen. Zugehörige Datenbankservices zuerst ingestieren und die Lineage-/Servicezuordnung entsprechend der eingesetzten Connectoroberfläche konfigurieren. Voll qualifizierte Namen und Umgebung abgleichen. Für eine QVD-only-Kette ohne ingestierte Datenbank keine erfundene Snowflake-Quelle eintragen.
- Nachkuratieren und absichern. Fachlichen Owner, PII-Klasse, Zweck und Freigabeverweis dort pflegen, wo sie autoritativ verwaltet werden. Nicht behaupten, jede Qlik-Eigenschaft oder jeder Owner/Tag werde automatisch vollständig synchronisiert. Verhalten bei erneutem Import testen: manuelle Entscheidungen dürfen nicht unbemerkt überschrieben werden.
Objektweise Abnahme
| Test | Erwartung |
|---|---|
| App/Chart | bekannte IDs und funktionierender Qlik-Link |
| Ausschluss | ausgeschlossene App bleibt außerhalb des Imports |
| Datenmodell/Lineage | tatsächliche bekannte Beziehung, kein gleichnamiges falsches Objekt |
| Änderung | definierte Teständerung nach neuem Lauf erkennbar |
| Sichtbarkeit | berechtigter Metadatenleser sieht nur vorgesehenen Kontext |
| Secretrotation | erneuter Lauf ohne Token im Repository |
Die Ingestion-Identität kann mehr Metadaten sehen als ein Consumer in Qlik. OpenMetadata erbt die Qlik-Sicherheitsmatrix nicht automatisch vollständig. Ein Link nach Qlik wird dort mit der Identität des aufrufenden Menschen geprüft; die externe Beschreibung benötigt zusätzlich eigene Katalogrechte.
Erweiterung: bestehende Anbindungshilfe und eigene OpenMetadata-Adapter. Die unterstützte Schnittstelle und den tatsächlichen Bedarf vor eigener Entwicklung im Projekt prüfen.
Quellen, Hilfe und Lernmaterial
- OpenMetadata: Qlik Cloud / 2.0.x
- Qlik: Data connections in spaces
- Qlik: Analytics lineage
- Qlik: Section Access
- Qlik: What is new / staged rollouts
Bei Videos hat die aktuelle schriftliche Hilfe Vorrang. Externe Medien werden vom jeweiligen Anbieter bereitgestellt.
Qlik Cloud: Catalog and governance operations
Part 2 of 4
View series