Power BI · Data Engineering
Das Diagramm, das sich die Stakeholder wirklich gewünscht haben
Custom Visuals für Power BI mit KI-Agenten bauen – und mit einem Plan.
Michael Wetzel · Data Engineer · ca. 6 Min. Lesezeit
Auf einen Blick
- Mit KI-Agenten entstehen Custom Visuals in Tagen statt Wochen.
- Mindestens die Hälfte der Arbeit steckt in der Spezifikation.
- Der Performance Analyzer zeigt, ob der Fehler in der Abfrage oder im Rendering liegt.
Wer in Power BI Dashboards baut, kennt die Lücke zwischen dem herrlich ambitionierten Diagramm, das Stakeholder im Kopf haben, und dem, was die integrierten Visuals tatsächlich darstellen können. Bis vor Kurzem brauchte es, um diese Lücke zu schließen, fundiertes Know-how in TypeScript und dem Power BI Visuals SDK, wochenlanges Budget für ein einziges Diagramm und eine Abhängigkeit, die das Projekt überdauert: Jede spätere Änderung an einer Farbe oder einer Beschriftung läuft über Fachkräfte, die diese Technologien beherrschen. Noch nie war es jedoch so günstig, diese Lücke zu schließen: Mit KI-Agenten sind hochindividuelle Custom Visuals nicht länger Entwicklungsteams vorbehalten, und sie entstehen in Tagen statt Wochen. Das heißt allerdings nicht, dass man die Arbeit nachlässig abgeben kann. Ohne eine durchdachte Strategie gerät ein solches Projekt schnell außer Kontrolle und wird für alle Beteiligten frustrierend.
Erst die Spezifikation, dann der Code
Nach unserer Erfahrung fließt mindestens die Hälfte der Arbeit an einem Custom Visual in eine recht ausgefeilte Spezifikation, denn jede wichtige Entscheidung, die hier nicht festgehalten wird, kommt später zurück – und zwar zu einem ungünstigeren Zeitpunkt. Grob wächst die Spezifikation in drei Schritten, in der Praxis sind es meist mehr.
- Das Stakeholder-Gespräch: Am Anfang steht das fachliche Problem, das das Visual lösen soll, und ein ehrlicher Blick darauf, ob es dafür überhaupt ein Custom Visual braucht. Eine 90-Prozent-Lösung aus Standard-Visuals ist oft gut genug; das Custom Visual ist damit die letzte Antwort, nicht die erste. Ist das geklärt, geht es darum, was das Visual zeigen muss und was bei jedem Klick passiert. Ein Mockup hilft enorm, die Erwartungen abzugleichen, bevor die erste Codezeile existiert. Dafür braucht es weder Kenntnisse im Grafikdesign noch Zeichentalent, und mit KI kostet ein brauchbarer Entwurf kaum Aufwand.
Selbsttest · 1 Minute
Brauche ich überhaupt ein Custom Visual?
Drei Fragen, die wir in jedem Stakeholder-Gespräch klären, bevor die erste Codezeile entsteht.
- Recherche: Gibt es offizielle Visuals oder etablierte Community-Lösungen, die das Problem bereits abdecken oder zumindest als Vorlage dienen? Die Chancen stehen gut, dass schon jemand ein ähnliches Problem hatte und die Lösung auf GitHub gestellt hat. Welche technischen Hürden sind zu erwarten, wie lassen sie sich lösen, und was kann Power BI trotz aller Flexibilität schlicht nicht leisten?
- Die zentralen technischen Entscheidungen, jeweils mit Begründung.
Das Ergebnis sollte ein strukturiertes Markdown-Dokument sein, das das Was und das Wie festlegt:
Checkliste · Vorlage zum Mitnehmen
Was in die Spezifikation gehört
Haken Sie ab, was Ihr Dokument schon abdeckt. Die leere Vorlage können Sie direkt kopieren und Ihrem KI-Agenten mitgeben.
0 / 6
Erst die Abfrage prüfen, dann das Rendering
Der Bau des Visuals selbst ist ein fast enttäuschend gewöhnliches Softwareprojekt. Der Agent arbeitet im Repository, baut mit der Visuals-CLI (pbiviz package), versioniert und committet. Der Bericht liegt im PBIP-Format vor (Power BI Project: ein Ordner mit JSON-Dateien statt einer binären .pbix-Datei), sodass der bevorzugte KI-Agent das gepackte Visual selbst in den Bericht installiert und bei jeder Iteration aktualisiert. Die Berichtseinstellungen bleiben erhalten, und jede Änderung ist ein lesbarer Diff.
Unsere Geheimwaffe beim Testen ist der Performance Analyzer in Power BI Desktop, ein Werkzeug, das alle erfahrenen Power-BI-Fachleute in- und auswendig kennen. Die meisten öffnen ihn, um zu sehen, wie lange jedes Visual zum Laden braucht. Für unseren Zweck ist jedoch ein Detail weitaus wertvoller: Er zeigt die exakte DAX-Abfrage, die ein Visual an das Modell sendet, und mit einem Klick läuft diese Abfrage in der DAX-Abfrageansicht. Das Ergebnis ist die Tabelle, die das Visual erhält – ganz ohne Rendering.
Wer DAX beherrscht, erkennt das Problem in dieser Abfrage oft sofort: ein Feld, das es nie in die Abfrage geschafft hat, ein Filter, wo keiner erwartet wurde, ein Measure, das auf der falschen Ebene aggregiert wird. Für alle anderen erledigt eine einfache Heuristik den Großteil der Arbeit:
Ist die Tabelle falsch, liegt der Fehler in den Data Roles oder Capabilities. Ist sie richtig, liegt er im Rendering.
So oder so ist diese Aufteilung einer der hilfreichsten Hinweise, die ein KI-Agent beim Debugging bekommen kann, denn sie führt ihn zur richtigen Hälfte des Codes.
Debug-Wegweiser
Abfrage oder Rendering – wo steckt der Fehler?
- Performance Analyzer in Power BI Desktop öffnen und Aufzeichnung starten.
- Beim betroffenen Visual Abfrage kopieren bzw. In DAX-Abfrageansicht ausführen.
- Ergebnistabelle ansehen – das ist genau das, was Ihr Visual erhält.
Stimmt die Tabelle?
Ein Diagramm, drei Entscheidungen
Wie sehr sich ein strukturierter Prozess auszahlt, zeigte sich in einem Kundenprojekt, in dem ein Radar-Chart mit 15 Achsen gefragt war, gruppiert in vier farbige Cluster, das das aktuelle Jahr als gefüllte Fläche dem Vorjahr als gestrichelte Linie gegenüberstellt. Ein Klick auf eine beliebige Achse sollte den Rest der Seite filtern, und die Kundenseite wollte Farben, Linien und Beschriftungen ohne unsere Hilfe anpassen können. Weder die integrierten Visuals noch eine Community-Lösung kamen dem auch nur nahe. Drei dieser Anforderungen wurden zu Architekturentscheidungen, die vor der ersten Codezeile geklärt sein mussten.
Damit Sie sich das Ergebnis besser vorstellen können, haben wir das Prinzip mit fiktiven Daten nachgebaut:
Interaktives Beispiel · fiktive Daten
So funktioniert das Radar-Chart aus dem Projekt
Klicken Sie auf eine Achse, um sie zu „filtern“. Der Filter bleibt aktiv, bis Sie ihn entfernen – genau wie mit der Filter API.
Klickverhalten: Die Kundenseite wollte, dass ein Klick auf eine Achse den Rest der Seite filtert und aktiv bleibt, bis er entfernt wird. Power BI bietet dafür zwei Mechanismen. Die Selection API hebt visualübergreifend hervor, wird aber beim nächsten Klick irgendwo auf der Seite zurückgesetzt, während sich die Filter API wie ein Slicer verhält und bestehen bleibt. Da Persistenz gefordert war, fiel die Wahl naheliegend auf die Filter API. Den Unterschied können Sie hier selbst ausprobieren:
Zum Ausprobieren
Selection API vs. Filter API
Wählen Sie einen Modus, klicken Sie auf einen Balken – und dann irgendwo auf die leere Berichtsfläche.
Umsatz nach Region
Umsatz gesamt
–
alle Regionen
leere Berichtsfläche – hier klicken
Vereinfachte Darstellung mit Beispielwerten.
Cluster: Die 15 Achsen gehören zu vier Clustern, jeder mit eigenem Farbband und eigener Beschriftung. Clusterzugehörigkeit und Farben sollten in den Datentabellen definiert werden; sie kommen daher als eigene Data Role aus dem Modell, nicht aus manueller Formatierung. Diese Rolle nachträglich hinzuzufügen, hätte bedeutet, capabilities.json, den Datenkonverter und das Rendering gleichzeitig zu ändern.
Konfigurierbarkeit: Die Kundenseite wollte vieles am Visual selbst im Formatbereich anpassen: Farben, Linienstile, Beschriftungen. Technologien wie Deneb (Vega-Lite-JSON in einem Container-Visual) oder HTML Content (von einem Measure erzeugtes HTML) sind zwar einfacher umzusetzen, bringen aber keinen eigenen Formatbereich mit. Deshalb haben wir ein SDK-Visual gebaut (Power BI Visuals SDK, TypeScript), das sich wie jedes reguläre Power-BI-Diagramm verhält.
| Ansatz | Aufwand | Eigener Formatbereich | Passt, wenn … |
|---|---|---|---|
| Deneb (Vega-Lite) | gering | nein | das Team die Gestaltung selbst pflegt |
| HTML Content | gering | nein | ein Measure das HTML erzeugen kann |
| SDK-Visual (TypeScript) | höher | ja | die Fachbereiche selbst anpassen sollen unsere Wahl |
Selbst die beste Spezifikation lässt Raum für eine Überraschung. Bei uns waren es die Beschriftungen für Achsen und Cluster. Als Kategorien definiert, wurden sie Teil dessen, wonach die Abfrage des Visuals gruppierte – und da sie aus zwei voneinander unabhängigen Tabellen stammten, wuchsen dem Diagramm doppelte Achsen. Die DAX-Abfrage im Performance Analyzer entlarvte die Übeltäter auf einen Blick: zwei zusätzliche Spalten in der Gruppierung. Die Lösung lag in den Data Roles, nicht im Rendering. Als wir die Beschriftungen in Measures umwandelten, fielen sie aus der Gruppierung heraus, und die Achsen rückten wieder an ihren Platz.
Das Endergebnis kann sich sehen lassen. Das fertige Visual greift jede zentrale Anforderung des Mockups auf, und zahlreiche Optionen im Formatbereich ermöglichen es der Kundenseite, jedes Element pixelgenau anzupassen.
Fazit
Der Weg vom Wunsch der Kundenseite zu einem Visual, das genau passt, war kurz – und das nicht zufällig. Die Spezifikation, die frühen Entscheidungen und der Abfragetest haben die meisten Umwege beseitigt, bevor sie entstehen konnten. Die gute Nachricht: Um anspruchsvolle Custom Visuals zu bauen, muss niemand mehr Softwareentwicklung beherrschen. Es schadet aber sicher nicht, so zu denken wie in der Softwareentwicklung: erst spezifizieren, früh entscheiden und die Abfrage vor dem Rendering prüfen. Den Code schreibt die KI. Die Strategie bleibt unsere Sache.
Sie haben ein Diagramm im Kopf, das Power BI nicht kann?
Wir begleiten Sie von der Spezifikation bis zum fertigen Custom Visual.