top of page
Suche

Deneb-Visuals in Power BI kopieren

Du hast ein Deneb-Visual einmal sauber gebaut – und dann beginnt der Alltag: Der gleiche Chart soll in den nächsten Report, ins nächste Projekt, in die nächste Variante. Genau dafür zeigt dieser Beitrag einen pragmatischen Weg: Kopieren, Einfügen und Anwenden von einer Power-BI-Quelldatei zu einer Zieldatei, gesteuert über VS Code, den Power BI MCP-Server und GitHub Copilot Chat (im Beispiel im Agent-Mode mit Claude Opus 4.6).


Am Ende hast du das Deneb-Visual inklusive JSON-Spezifikation im Zielreport – ohne das Visual neu zu zeichnen oder die Spezifikation von Grund auf zu schreiben. Danach kommt der wichtige Teil: Mapping, Semantik, Checks.


Deneb-Visuals in Power BI kopieren

Ausgangslage und Zielbild

Wenn du Deneb nutzt, tust du das meist aus einem Grund: Du willst Visuals, die Power BI so nicht liefert – oder du willst volle Kontrolle (Vega/Vega-Lite). Häufig entsteht so ein Visual in einem Beispiel-Report, einem Prototyp, oder du startest mit einem Template aus der Community.


Das Ziel ist klar: Du nimmst ein funktionierendes Deneb-Visual aus Report A und bringst es nach Report B – inklusive Spezifikation – und passt es anschließend an dein semantisches Modell an.


Am wichtigsten ist dabei die Haltung: Kopieren ist der schnelle Teil. Das saubere Anwenden ist der Teil, der Qualität erzeugt.


Voraussetzungen: Was du brauchst, bevor du startest

Der Ablauf funktioniert am besten, wenn du den Report als Power-BI-Projektordner (PIBP) vorliegen hast. Die Präsentation arbeitet explizit mit einem Berichtsordner im pibp-Format und verbindet diesen in VS Code über Copilot Chat und die Power BI MCP-Erweiterung.


Du brauchst:

  • Eine Quelldatei mit funktionierendem Deneb-Visual

  • Eine Zieldatei, in die das Visual soll (anfangs ohne Deneb ist okay)

  • VS Code

  • GitHub Copilot Chat

  • Power BI MCP-Erweiterung/Anbindung im VS Code Kontext


In unserem Beispiel wurden alle Schritte im Agent-Mode mit Claude Opus 4.6 in der kostenpflichtigen GitHub-Variante umgesetzt. Du musst das nicht exakt so nachbauen – aber es erklärt, warum der Agent mehrere Schritte am Stück ausführen kann.


Wenn du PIBP + VS Code + Copilot Chat sauber stehen hast, fühlt sich der Rest eher wie Projektarbeit an – nicht wie Copy-Paste-Chaos.


Phase 1: Quelle und Ziel im PIBP-Format verbinden

Jetzt geht es darum, beide Reports als Projektordner im selben Arbeitskontext verfügbar zu machen. Die Präsentation beschreibt zuerst das Speichern des Quell-Reports inklusive Deneb in einem PIBP-Ordner und danach die Verbindung dieses Ordners über VS Code mit MCP-Server und Copilot.


Praxis-Prompt: Copilot auf das Quellprojekt setzen

Nutze die Power BI MCP-Tools und verbinde dich mit diesem Power-BI-Projektordner (PIBP):
<PFAD_ZUR_QUELLE>

Gib mir danach eine kurze Übersicht:
- Welche Report-Ordner/Artefakte siehst du?
- Welche Seiten enthält der Report?

Dann kommt das Gleiche für das Ziel: Zieldatei als pibp-Ordner anbinden. Als Vereinfachung empfiehlt die Präsentation, alle Ordner eines Berichts in einem übergeordneten Ordner zu sammeln, damit der Pfadwechsel trivial ist.


Praxis-Prompt: Auf das Zielprojekt wechseln

Wechsle jetzt in den Ziel-PIBP-Ordner:
<PFAD_ZUM_ZIEL>

Bestätige, dass du mit dem Power BI-Ordner verbunden bist, und liste danach alle Seiten der Zieldatei auf.

Abschlussgedanke: Wenn Quelle und Ziel sauber verbunden sind, ist der Agent nicht mehr nur Chat – er wird zur Navigationshilfe durch die Projektstruktur. Genau hier gewinnt der Ansatz Zeit.


Phase 2: Zielseite finden oder erstellen

Bevor du ein Visual kopierst, brauchst du eine klare Zielseite. Dazu kannst du zunächst eine Eingabeaufforderung nutzen, um alle Seiten der Zieldatei aufzulisten.


Praxis-Prompt: Seiten inventarisieren

Liste alle Seiten im Zielreport auf.
Gib mir die Seitennamen und eine kurze Beschreibung, was auf jeder Seite liegt (wenn erkennbar).

Danach kommt die Entscheidung, ob eine vorhandene Seite genutzt oder neue Seite erstellt und ggf. umbenannt werden soll.


Praxis-Prompt: Zielseite anlegen und sauber benennen

Erstelle eine neue Seite im Zielreport mit dem Namen:
Deneb – <THEMA>

Falls eine Seite mit ähnlichem Zweck existiert, schlage mir alternativ eine Umbenennung oder Wiederverwendung vor.
Setze die neue Seite als Zielseite für das Deneb-Visual.

Nimm dir am Ende kurz die 10 Sekunden: Stimmt der Seitentitel, ist der Zweck klar, gibt es keine Nebenwirkungen? Das spart dir später Überraschungen beim Review.


Phase 3: Deneb-Visual inklusive JSON kopieren

Jetzt kommt der Teil, wegen dem du hier bist: Kopiere die Deneb-Visualisierung von der Quelldatei in die Zieldatei – inklusive JSON-Spezifikation – und lass die Änderungen zu.


Praxis-Prompt: Deneb-Visual kopieren

Kopiere das Deneb-Visual von Seite <QUELLSEITE> aus dem Quellreport
und füge es auf der Zielseite Deneb – <THEMA> im Zielreport ein.

Wichtig:
- Spezifikation/JSON muss vollständig übernommen werden
- Layout/Größe möglichst beibehalten
- Danach zeige mir, welche Dateien/Definitionen im Zielprojekt geändert wurden

Nach den letzten Schritten sind Visual und Seite im Ziel zwar da, funktionieren aber noch nicht – und sind bereit für Anpassungen an die eigenen Anforderungen. Das ist kein Fehler, sondern der Normalzustand: Das Visual lebt von Feldnamen, Measures, Kalenderlogik und Modellstruktur. Kopieren überträgt die Logik – aber nicht automatisch deine Semantik.


Phase 4: Felder verstehen und Mapping an dein Modell anpassen

Jetzt beginnt die eigentliche Arbeit: Du musst wissen, welche Felder die Deneb-Spezifikation erwartet. Dazu musst du die Struktur bzw. die erforderlichen Felder prüfen – entweder mit Agent oder klassisch im Power BI Desktop.


Praxis-Prompt: Erforderliche Felder herausarbeiten

Analysiere das eingefügte Deneb-Visual im Zielreport:
- Welche Felder, Measures und Dimensionen werden benötigt?
- Welche davon fehlen in meinem Zielmodell?
- Welche scheinen nur anders zu heißen?

Gib mir eine Mapping-Tabelle:
Quelle_Feld -> Ziel_Feld_Vorschlag -> Kommentar/Risiko

Als Alternative wäre auch eine direkte Eingabeaufforderung an den Agenten möglich: Er soll die Felder nennen, die Deneb braucht, damit es im eigenen File funktioniert.


Praxis-Prompt (nah an der Präsentation): Felder aus Deneb ableiten

Gib mir die Felder aus dem Deneb-Visual, die ich verwenden muss,
damit die Visualisierung in meiner Datei funktioniert.
Zeige außerdem die relevanten Einstellungen, die davon abhängen.

Wichtiger Kontext: Selbst wenn Modelle ähnlich wirken, teilen sie oft nur Teile, z. B. eine Datumstabelle – aber nicht denselben Kalender. Das ist einer der häufigsten Gründe, warum ein kopiertes Visual zunächst nicht aufgeht.


Zum Abschluss dieser Phase: Du willst nicht, dass ein Agent rät. Du willst, dass er transparent macht, was er sieht – und du entscheidest, was du ersetzen willst.


Phase 5: Feldzuordnung ändern oder JSON-Spezifikation anpassen

Du kannst entweder das Mapping der Felder in der Deneb-Visualisierung ändern oder den JSON-Code der Spezifikation anpassen. Beides ist möglich. Wenn du schon weißt, was du ändern willst, ist das der bessere Weg. Denn das Beispiel zeigt auch: Mischmodelle aus Deutsch und Englisch sind nicht Best Practice, und Zuordnungen sollten auf deiner Absicht basieren – nicht auf Vermutungen des Agents.


Praxis-Prompt: Mapping-Änderung, ohne Spekulation

Ich gebe dir jetzt die Ziel-Feldliste aus meinem Modell.
Nutze nur diese Felder, keine erfundenen Namen.

Ziel-Felder:
<LISTE_DER_FELDER_UND_MEASURES>

Passe das Deneb-Visual so an, dass:
- jedes benötigte Feld gemappt ist
- Kalenderlogik auf meine Datumstabelle <DATUMSTABELLE> umgestellt wird
- keine Layoutänderungen vorgenommen werden, außer wenn zwingend
Gib mir danach eine kurze Änderungszusammenfassung.

Praxis-Prompt: Wenn du die JSON-Spezifikation gezielt ändern willst

Ändere die Deneb-Spezifikation (JSON) wie folgt:
- Ersetze <ALT_FELD> durch <NEU_FELD>
- Ersetze <ALT_MEASURE> durch <NEU_MEASURE>
- Passe ggf. Transform/Calculate-Schritte an, damit die Semantik gleich bleibt

Wichtig:
- keine kosmetischen Reformats
- nur die minimal nötigen Änderungen
- danach eine Diff-Zusammenfassung in Klartext

Abschlussgedanke: Der beste Workflow ist der, bei dem du nach 5 Minuten sagen kannst, was geändert wurde – und warum. Alles andere wird später teuer im Debugging.


Phase 6: Änderungen zulassen, neu öffnen, gründlich prüfen

Als nächstes gilt es die Änderungen an der JSON-Datei zuzulassen und beizubehalten und dann die Datei erneut in Power BI zu öffnen.


Praxis-Prompt: Sicher committen und neu testen

Behalte alle Änderungen im Zielprojekt bei.
Gib mir eine Liste der betroffenen Dateien und was sich darin geändert hat.

Danach:
- Nenne mir die Tests, die ich in Power BI Desktop direkt durchführen sollte,
  um zu prüfen, ob das Deneb-Visual korrekt funktioniert.

Der nächste Schritt wird oft unterschätzt: Die erstellte Visualisierung muss gründlich geprüft werden, und alle Elemente, die nötig sind, müssen angepasst werden. Im konkreten Beispiel wird sogar empfohlen, HR-bezogene Nomenklatur durch universellere Terminologie zu ersetzen.


Das ist der Moment, wo aus Copy-Paste echte Wiederverwendung wird: fachliche Begriffe, Achsentitel, Tooltips, Kategorien, Farben, Beschriftungen – alles, was im Quellkontext Sinn ergab, muss im Zielkontext stimmen.


Was daraus wird: Visual Library statt Einmal-Visual

Der spannendste Teil ist nicht der Kopiervorgang, sondern die Konsequenz: Du kannst Vega-Bibliotheken mit deinen Power-BI-Anwendungsfällen kombinieren und daraus eine Visual Library machen – gesteuert über VS Code, Agent und MCP.


Damit sind nicht nur Spezialvisuals möglich, sondern auch Kombinationsdiagramme für IBCS-nahe Szenarien. Und: Das Kopieren, Einfügen und Anwenden funktioniert nicht nur für einzelne Visuals, sondern auch für ganze Seiten und die in Definitionen gespeicherten Elemente.


Zum Abschluss: Wenn du Deneb ernst nimmst, behandelst du Visuals wie Produktbausteine. Nicht wie Bastelobjekte. Dieser Workflow ist ein praktischer Schritt dorthin.

Fazit: Deneb-Visuals schnell wiederverwenden

Du kannst ein Deneb-Visual inklusive Spezifikation aus einer Quelle in ein Ziel übertragen und es ohne Neuschreiben der Spezifikation lauffähig machen, indem du VS Code, Copilot/Claude und den Power BI MCP-Server nutzt.


Die harte Wahrheit bleibt: Der Kopiervorgang ist nur die Hälfte. Die Qualität entsteht beim Mapping, beim Kalender, bei der Semantik und beim gründlichen Review.

Der nächste sinnvolle Schritt

Power BI entfaltet seinen Nutzen erst dann vollständig, wenn Dashboards sauber aufgebaut, Datenmodelle durchdacht und Kennzahlen klar definiert sind.Genau diese Grundlagen entscheiden darüber, ob Berichte genutzt oder ignoriert werden.


Wenn du Power BI strukturiert aufsetzen oder bestehende Lösungen verbessern willst, unterstützen wir dich mit:


So wird aus einem funktionierenden Bericht eine belastbare Analytics-Lösung.

bottom of page