Power BI Embedded: Hinzufügen von Analysen zu Ihrer Anwendung

Jede SaaS-Anwendung benötigt irgendwann Analysen. Benutzer wünschen sich Dashboards, die ihre Nutzungsmuster, Leistungskennzahlen und Geschäftsergebnisse anzeigen. Der Aufbau einer benutzerdefinierten Analyseschicht von Grund auf – Diagrammbibliotheken, Datenpipelines, Caching, Exportfunktionen, Drilldown-Interaktionen – erfordert 6–12 Monate an technischem Aufwand und fortlaufender Wartung. Power BI Embedded bietet eine Alternative: Analysefunktionen der Enterprise-Klasse, die direkt in Ihre Anwendung eingebettet sind und durch die Infrastruktur von Microsoft unterstützt werden.

Bei Power BI Embedded geht es nicht einfach darum, „einen Iframe auf eine Seite zu setzen“. Es handelt sich um eine umfassende Plattform für die Bereitstellung interaktiver, sicherer und mandantenfähiger Analyseerlebnisse innerhalb der Benutzeroberfläche Ihrer eigenen Anwendung. Ihre Kunden interagieren mit Analysen, die typisch für Ihr Produkt sind, während Sie die ausgereifte Visualisierungs-Engine, die DAX-Berechnungsebene und die Datenkonnektivitätsinfrastruktur von Power BI nutzen.

Dieser Leitfaden behandelt die Architektur, Authentifizierungsmodelle, mandantenfähige Sicherheit, Kapazitätsplanung, SDK-Integration und Preisüberlegungen für die Einbettung von Power BI in Ihre Anwendung. Wenn Sie eine eingebettete Analyseimplementierung planen, erkunden Sie unsere [Power BI-Dienste für eingebettete Analysen] (/services/powerbi/embedded-analytics) für Architekturberatung und Entwicklungsunterstützung.

Wichtige Erkenntnisse

– Power BI Embedded unterstützt zwei Szenarien: „Einbetten für Ihre Kunden“ (App besitzt Daten) und „Einbetten für Ihre Organisation“ (Benutzer besitzt Daten) – Die Dienstprinzipalauthentifizierung wird für mehrinstanzenfähige SaaS-Anwendungen empfohlen. Master-Benutzerkonten sind einfacher, erzeugen aber Single Points of Failure – Sicherheit auf Zeilenebene (RLS) ist der primäre Mechanismus zur Gewährleistung der Mandantendatenisolation in freigegebenen Datensätzen – Fabric F-SKUs bieten die kostengünstigste Kapazität für eingebettete Szenarien, beginnend bei F2 für die Entwicklung – Das JavaScript SDK ermöglicht eine umfassende programmatische Kontrolle: Anwenden von Filtern, Erfassen von Ereignissen, Steuern der Navigation und Anpassen von Themen – Die Kapazitätsgröße hängt von gleichzeitigen Benutzern, der Komplexität der Abfrage und dem Datenvolumen ab – nicht nur von der Gesamtbenutzerzahl – Benutzerdefinierte Designs und verstecktes Chrome sorgen dafür, dass sich eingebettete Berichte nativ in Ihre Anwendung einfügen

---

Einbettungsszenarien: Kunden vs. Organisation

Für Ihre Kunden einbetten (App besitzt Daten)

Das Szenario „App besitzt Daten“ ist der primäre Anwendungsfall für SaaS-Anwendungen. Ihre Anwendung authentifiziert sich bei Power BI über ein Dienstprinzipal- oder Masterbenutzerkonto, generiert ein Einbettungstoken und stellt den eingebetteten Bericht Ihren Endbenutzern bereit. Ihre Kunden interagieren nie direkt mit Power BI und benötigen keine Power BI-Lizenzen.

Architekturablauf:

1. Ihr Kunde meldet sich über Ihr Authentifizierungssystem bei Ihrer Anwendung an.
2. Ihr Anwendungs-Backend ruft die Power BI-REST-API auf, um ein Einbettungstoken zu generieren, das auf den spezifischen Bericht, das Dataset und die RLS-Rolle für diesen Kunden beschränkt ist.
3. Das Backend gibt das Einbettungstoken und die Einbettungs-URL an das Frontend zurück.
4. Das Frontend initialisiert das Power BI JavaScript SDK mit dem Einbettungstoken und rendert den Bericht in einem bestimmten Containerelement.
5. Das Einbettungstoken läuft nach einem konfigurierbaren Zeitraum (Standard 1 Stunde) ab und wird von Ihrer Anwendung transparent aktualisiert.

Hauptmerkmale:

• Kunden benötigen keine Power BI Pro- oder Premium-Pro-Benutzerlizenzen
• Alle Kapazitätskosten werden von Ihnen (dem Anwendungsanbieter) über Fabric/Embedded-SKUs getragen
• Sie haben die volle Kontrolle darüber, was Benutzer durch RLS und programmatische Filterung sehen
• Die Authentifizierung erfolgt vollständig im Authentifizierungssystem Ihrer Anwendung
• Einbettungstokens bieten zeitlich begrenzten Zugriff auf bestimmte Artefakte

Dies ist das Modell, das von ISVs, SaaS-Plattformen und internen Portalen verwendet wird, bei denen der Analysenutzer nicht wissen oder sich darum kümmern sollte, dass Power BI die zugrunde liegende Technologie ist.

Für Ihre Organisation einbetten (Benutzer besitzt Daten)

Das Szenario „Benutzer besitzt Daten“ dient der Einbettung von Power BI-Inhalten in interne Anwendungen, bei denen Benutzer bereits über Power BI-Lizenzen (Pro oder PPU) verfügen. Die eingebettete Erfahrung nutzt die eigene Power BI-Identität und -Berechtigungen des Benutzers.

Architekturablauf:

1. Der Benutzer authentifiziert sich über Ihre Anwendung bei Azure AD.
2. Ihre Anwendung ruft im Namen des Benutzers mithilfe des OAuth 2.0-On-behalf-of-Flows ein Zugriffstoken ab.
3. Die Anwendung ruft die Power BI-REST-API mit dem Token des Benutzers auf, um die Einbettungskonfiguration abzurufen.
4. Der Bericht wird mit den vollständigen Power BI-Berechtigungen des Benutzers gerendert.

Hauptmerkmale:

• Jeder Benutzer muss über eine Power BI Pro- oder Premium-Pro-Benutzer-Lizenz verfügen – Benutzer sehen Inhalte basierend auf ihren eigenen Power BI-Berechtigungen und RLS-Zuweisungen
• Es ist keine zusätzliche Fabric-/Embedded-Kapazität erforderlich (verwendet die Pro/PPU-Lizenzzuteilung des Benutzers)
• Weniger Kontrolle für den Anwendungsentwickler, mehr Autonomie für den Benutzer
• Einfachere Architektur, aber höhere Lizenzkosten pro Benutzer

Dieses Modell wird typischerweise für Intranetportale, SharePoint-Integrationen und interne Anwendungen verwendet, bei denen Benutzer bereits über Power BI-Lizenzen verfügen und ihre bestehenden Zugriffsberechtigungen behalten sollten.

Zwischen Szenarien wählen

Für die meisten SaaS-Anwendungen, die sich an externe Kunden richten, ist „App besitzt Daten“ die richtige Wahl. Der Rest dieses Leitfadens konzentriert sich hauptsächlich auf dieses Szenario.

---

Authentifizierung: Dienstprinzipal vs. Hauptbenutzer

Dienstprinzipalauthentifizierung

Ein Dienstprinzipal ist eine Azure AD-Anwendungsidentität, der Power BI vertraut, um programmgesteuert auf Ressourcen zuzugreifen. Dies ist die empfohlene Authentifizierungsmethode für eingebettete Produktionsanwendungen.

Setup-Anforderungen:

1. Registrieren Sie eine Anwendung in Azure AD.
2. Erstellen Sie ein Client-Geheimnis oder ein Zertifikat für die Anwendung.
3. Erstellen Sie eine Azure AD-Sicherheitsgruppe und fügen Sie ihr den Dienstprinzipal hinzu.
4. Aktivieren Sie im Power BI-Administratorportal den Dienstprinzipalzugriff für die Sicherheitsgruppe unter Mandanteneinstellungen > Entwicklereinstellungen.
5. Gewähren Sie dem Dienstprinzipal Zugriff auf die spezifischen Power BI-Arbeitsbereiche, die Ihre eingebetteten Inhalte enthalten.

Vorteile:

• Keine Abhängigkeit von einem bestimmten Benutzerkonto (eliminiert Single Point of Failure) – Client-Geheimnisse und Zertifikate können ohne Dienstunterbrechung rotiert werden – Dienstprinzipale können auf bestimmte Arbeitsbereiche beschränkt werden (geringste Rechte) – Funktioniert mit von Azure AD verwalteten Identitäten in von Azure gehosteten Anwendungen
• Unterstützt zertifikatbasierte Authentifizierung für höhere Sicherheit

Einschränkungen:

• Auf „Mein Arbeitsbereich“ (persönliche Arbeitsbereiche) kann nicht zugegriffen werden. – Bestimmte Admin-APIs können nicht aufgerufen werden – Erfordert Azure AD Premium für einige erweiterte Funktionen
• Initial setup is more complex than master user

Master-Benutzerauthentifizierung

Ein Hauptbenutzer ist ein reguläres Azure AD-Benutzerkonto mit einer Power BI Pro- oder PPU-Lizenz, das Ihre Anwendung zur Authentifizierung bei Power BI verwendet. Die Anwendung meldet sich als dieser Benutzer an, um Einbettungstokens zu generieren.

Vorteile:

• Einfachere Ersteinrichtung (Benutzer erstellen, Lizenz zuweisen, Zugriff auf den Arbeitsbereich gewähren) – Kann auf alle Power BI-Funktionen zugreifen, einschließlich Admin-APIs – Keine Azure AD-Anwendungsregistrierung erforderlich

Nachteile:

– Single Point of Failure: Wenn das Benutzerkonto gesperrt ist, das Passwort abläuft oder MFA ausgelöst wird, verliert Ihre Anwendung den Zugriff auf Analysen – Es können keine Richtlinien für bedingten Zugriff verwendet werden, die eine interaktive Anmeldung erfordern

• Für die Passwortrotation sind Anwendungsaktualisierungen erforderlich – Verstößt gegen die bewährte Sicherheitspraxis, keine menschlichen Konten für Maschinenprozesse zu verwenden
• Lizenzkosten für das Benutzerkonto

Empfehlung: Verwenden Sie die Dienstprinzipalauthentifizierung für alle Produktionsbereitstellungen. Hauptbenutzerkonten sind für Proof-of-Concept- und Entwicklungsumgebungen akzeptabel, in denen Einfachheit wichtiger ist als Zuverlässigkeit.

Token-Generierung und -Verwaltung

Unabhängig von der Authentifizierungsmethode generiert Ihre Anwendung Einbettungstokens über die Power BI-REST-API. Das Token kapselt die Berechtigungen für die eingebettete Sitzung.

Überlegungen zum Einbetten von Token:

• Token-Lebensdauer: Der Standardwert ist 1 Stunde, konfigurierbar bis zu 24 Stunden. Kürzere Lebensdauern sind sicherer, erfordern jedoch eine häufigere Aktualisierung.
• Token-Geltungsbereich: Jedes Token ist auf bestimmte Berichte, Datensätze und Arbeitsbereiche beschränkt. Generieren Sie einen möglichst engen Bereich.
• RLS-Identität: Bei Verwendung der Sicherheit auf Zeilenebene ist die RLS-Identität (Benutzername und Rollen) in das Token eingebettet. So stellen Sie die Isolation der Mieter sicher.
• Token-Aktualisierung: Ihr Frontend sollte den Token-Ablauf überwachen und vor Ablauf einen neuen Token anfordern. Das JavaScript SDK stellt hierfür Ereignisse bereit.

Beispielablauf für die Token-Generierung:

POST https://api.powerbi.com/v1.0/myorg/GenerateToken
{
    "datasets": [{"id": "dataset-guid"}],
    "reports": [{"id": "report-guid"}],
    "identities": [{
        "username": "[email protected]",
        "roles": ["TenantRole"],
        "datasets": ["dataset-guid"]
    }]
}

Die Antwort enthält ein Einbettungstoken und einen Ablaufzeitstempel. Ihr Backend speichert dieses Token (unter Berücksichtigung des Ablaufs) zwischen und stellt es authentifizierten Frontend-Anfragen zur Verfügung.

---

Multi-Tenant-Sicherheit auf Zeilenebene

Warum RLS für Embedded von entscheidender Bedeutung ist

In einer mandantenfähigen SaaS-Anwendung befinden sich die Daten mehrerer Kunden häufig im selben Power BI-Datensatz. Ohne Sicherheit auf Zeilenebene gewährt ein Einbettungstoken Zugriff auf alle Daten im Datensatz. RLS stellt sicher, dass jeder Kunde nur seine eigenen Daten sieht, auch wenn der zugrunde liegende Datensatz gemeinsam genutzt wird.

RLS ist für eingebettete Szenarien mit mehreren Mandanten nicht optional. Ein Fehler bei der Mandantenisolierung ist ein Datenschutzverstoß. Gestalten Sie RLS als grundlegende Sicherheitskontrolle und nicht als nachträglichen Gedanken.

Statisches RLS

Statisches RLS definiert feste Filterregeln mithilfe von DAX-Ausdrücken in Power BI Desktop. Jede Rolle verfügt über eine Reihe von Tabellenfiltern, die einschränken, welche Zeilen sichtbar sind.

Beispiel:

Eine „TenantRole“ mit diesem Filter in der Tabelle „Kunden“:

[TenantId] = USERNAME()

Beim Generieren eines Einbettungstokens setzt Ihre Anwendung den USERNAME()-Wert auf die Kennung des aktuellen Mandanten. Der DAX-Filter beschränkt alle Abfragen auf Zeilen, in denen TenantId übereinstimmt.

Statisches RLS ist einfach und effektiv für eine unkomplizierte Mieterisolierung. Es funktioniert gut, wenn:

• Tenant isolation is based on a single column (TenantId) that propagates through relationships
• Alle Mieter sehen die gleiche Berichtsstruktur, nur gefiltert nach ihren Daten
• Die Anzahl der RLS-Rollen ist klein und stabil

Dynamisches RLS

Dynamic RLS verwendet DAX-Ausdrücke, die zum Zeitpunkt der Abfrage basierend auf der Identität des Benutzers ausgewertet werden. Dies ermöglicht komplexere Sicherheitsszenarien, ohne dass für jeden Mandanten separate Rollen erstellt werden müssen.

Gemeinsame dynamische RLS-Muster:

USERPRINCIPALNAME()-Muster:

[Email] = USERPRINCIPALNAME()

Das Einbettungstoken setzt den Benutzernamen der effektiven Identität auf die E-Mail-Adresse des Benutzers. Der Filter gleicht eine E-Mail-Spalte in einer Sicherheitszuordnungstabelle ab.

Sicherheitstabellenmuster: Erstellen Sie eine dedizierte Sicherheitstabelle, die Benutzern die Daten zuordnet, auf die sie zugreifen können:

Wenden Sie RLS-Filter an, die diese Sicherheitstabelle über Beziehungen mit Ihren Faktentabellen verbinden. Dieses Muster unterstützt Berechtigungen auf Benutzerebene innerhalb eines Mandanten und nicht nur die Isolation auf Mandantenebene.

RLS-Test und -Validierung

Tests vor der Bereitstellung:

1. Verwenden Sie in Power BI Desktop „Anzeigen als“, um jede RLS-Rolle mit Beispielbenutzernamen zu testen.
2. Stellen Sie sicher, dass die Kreuzfilterung zwischen Tabellen die RLS-Grenzen berücksichtigt.
3. Randfälle testen: Benutzer ohne übereinstimmende Zeilen (es sollten leere Berichte und keine Fehler angezeigt werden), Benutzer mit mehreren Rollen und Nullwerte in Filterspalten.
4. Stellen Sie sicher, dass DAX-Maßnahmen, die ALL() oder REMOVEFILTERS() verwenden, RLS nicht umgehen (dies sollte nicht der Fall sein, wird aber überprüft).

Produktionsvalidierung:

• Automatisieren Sie RLS-Tests als Teil Ihrer Bereitstellungspipeline
• Generieren Sie Einbettungstokens zum Testen von Mieteridentitäten und überprüfen Sie, ob die Abfrageergebnisse mit den erwarteten Daten übereinstimmen
• Überwachen Sie RLS-Umgehungsversuche in Kapazitätsmetriken (ungewöhnliche Abfragemuster, unerwartete Datenmengen).
• Führen Sie vierteljährliche Sicherheitsüberprüfungen der RLS-Konfigurationen durch

---

Kapazitätsgrößen und Stoff-SKUs

Kapazität verstehen

Power BI Embedded erfordert dedizierte Kapazität – Rechenressourcen, die für Ihre eingebetteten Workloads reserviert sind. Die Kapazität wird in Kapazitätseinheiten (CUs) gemessen, die die verfügbare Verarbeitungsleistung zum Rendern von Berichten, Ausführen von Abfragen und Aktualisieren von Datensätzen bestimmen.

Die Kapazität gilt nicht pro Benutzer. Es handelt sich um einen gemeinsamen Rechenpool, aus dem alle Ihre eingebetteten Sitzungen schöpfen. Das bedeutet, dass die Preise mit der Parallelität und der Komplexität der Abfragen skalieren, nicht mit der Gesamtbenutzerzahl.

Fabric F SKU-Optionen

Microsoft Fabric F-SKUs sind das aktuelle Preismodell für Power BI Embedded-Kapazität. Sie ersetzten die alten A-SKUs durch ein flexibleres, pausierbares Modell.

Wichtige Hinweise:

• Gleichzeitige Benutzer bedeuten nicht die Gesamtzahl der Benutzer. Dies bedeutet, dass Benutzer gleichzeitig aktiv Anfragen stellen. Ein typisches Verhältnis liegt bei 5–10 % aller Benutzer, die zu einem bestimmten Zeitpunkt gleichzeitig angemeldet sind.
• Dies sind ungefähre Richtwerte. Die tatsächliche Kapazität hängt stark von der Abfragekomplexität, der Modellgröße und der Anzahl der Visualisierungen pro Bericht ab.
• F-SKUs können angehalten werden, wenn sie nicht verwendet werden (im Gegensatz zu älteren P-SKUs), was für die Entwicklung und saisonale Arbeitslasten wertvoll ist. – F64 und höher umfassen Power BI Premium-Funktionen (paginierte Berichte, KI, Bereitstellungspipelines) ohne zusätzliche Lizenzkosten.

Methodik zur Kapazitätsdimensionierung

Schritt 1: Schätzen Sie gleichzeitige Benutzer.

Gleichzeitige Benutzer = Gesamtbenutzer x Höchstes Parallelitätsverhältnis

Für SaaS-Analyse-Dashboards, auf die während der Geschäftszeiten zugegriffen wird: 5–10 % Parallelitätsverhältnis. Für operative Dashboards, die den ganzen Tag über häufig überprüft werden: 15–25 % Parallelitätsverhältnis. Für ereignisgesteuerte Dashboards (Echtzeitüberwachung, Warnungen): 30–50 % Parallelitätsverhältnis.

Schritt 2: Bewerten Sie die Komplexität der Abfrage.

Einfache Berichte (5–10 visuelle Elemente, einfache Aggregationen, einzelne Faktentabelle): 1x Basislinie. Mittlere Berichte (10–20 Bilder, Zeitintelligenz, mehrere Faktentabellen): 2–3x Basislinie. Komplexe Berichte (mehr als 20 Visualisierungen, komplexer DAX, große Datenmengen, quellenübergreifende Abfragen): 4–6x Basislinie.

Schritt 3: Erforderliche Kapazität berechnen.

Beginnen Sie mit der SKU, die Ihrer Schätzung gleichzeitiger Benutzer aus der Tabelle oben entspricht. Multiplizieren Sie mit Ihrem Komplexitätsfaktor. Wenn das Ergebnis die Kapazität der SKU für gleichzeitige Abfragen überschreitet, wechseln Sie zur nächsten Ebene.

Schritt 4: Mit Auslastungstests validieren.

Die theoretische Dimensionierung ist ein Ausgangspunkt. Führen Sie vor dem Produktionsstart Auslastungstests mit realistischen Datenmengen, Abfragemustern und Parallelitätsstufen durch. Zu diesem Zweck stellt Microsoft ein Power BI Embedded-Tool zum Testen der Kapazitätsauslastung bereit.

Schritt 5: Planen Sie Wachstum.

Fügen Sie 30–50 % Spielraum über Ihrem aktuellen Höchststand hinzu, um dem Wachstum in den nächsten 6–12 Monaten Rechnung zu tragen. F-SKUs können ohne Ausfallzeit aktualisiert werden, sodass Sie die Größe schrittweise anpassen können.

Strategien zur Kostenoptimierung

• Entwicklungskapazitäten pausieren während der arbeitsfreien Zeit. F SKUs werden pro Sekunde abgerechnet, wenn sie aktiv sind, kostenlos, wenn sie pausiert sind. Durch die Automatisierung des Anhaltens/Fortsetzens mit Azure Automation oder Logic Apps können die Entwicklungskosten um 60–70 % gesenkt werden.

• Modelle optimieren, bevor die Kapazität skaliert wird. Ein gut optimiertes Modell auf F8 übertrifft oft ein schlecht optimiertes Modell auf F32. Investieren Sie in die Modelloptimierung, bevor Sie Leistungsprobleme mit der Rechenleistung lösen.

• Verwenden Sie Aggregationstabellen für große Datensätze. Durch die Voraggregierung von Daten mit gängigen Granularitäten (täglich, wöchentlich, monatlich) wird die Abfrageverarbeitung für visuelle Darstellungen auf Zusammenfassungsebene um 80–90 % reduziert, während die Drilldown-Fähigkeit für Details erhalten bleibt.

• Implementieren Sie Caching auf Berichtsebene über die Power BI REST API. Bei Dashboards mit seltenen Datenaktualisierungen reduzieren zwischengespeicherte Ergebnisse den Kapazitätsverbrauch pro Benutzersitzung.

• Berücksichtigen Sie separate Kapazitäten für unterschiedliche Arbeitslasten. Durch die Isolierung von Aktualisierungsvorgängen von interaktiven Abfragen wird verhindert, dass Aktualisierungsspitzen die Benutzererfahrung beeinträchtigen. Dies ist besonders wichtig, wenn Sie über große Datensätze verfügen, die während der Geschäftszeiten aktualisiert werden.

---

JavaScript SDK-Integration

Grundlegende Einbettung

Das Power BI JavaScript SDK (powerbi-client) bietet die programmgesteuerte Schnittstelle zum Einbetten und Steuern von Power BI-Inhalten in Ihrer Webanwendung.

Installation:

npm install powerbi-client

Grundlegender Einbettungsablauf:

import * as pbi from 'powerbi-client';

const powerbi = new pbi.service.Service(
    pbi.factories.hpmFactory,
    pbi.factories.wpmpFactory,
    pbi.factories.routerFactory
);

const embedConfig = {
    type: 'report',
    id: reportId,
    embedUrl: embedUrl,
    accessToken: embedToken,
    tokenType: pbi.models.TokenType.Embed,
    settings: {
        panes: {
            filters: { visible: false },
            pageNavigation: { visible: true }
        },
        background: pbi.models.BackgroundType.Transparent,
        layoutType: pbi.models.LayoutType.Custom,
        customLayout: {
            displayOption: pbi.models.DisplayOption.FitToWidth
        }
    }
};

const reportContainer = document.getElementById('report-container');
const report = powerbi.embed(reportContainer, embedConfig);

Programmatische Steuerung

Das SDK bietet umfassende programmgesteuerte Kontrolle über den eingebetteten Bericht:

Anwenden von Filtern:

const filter = {
    $schema: "http://powerbi.com/product/schema#basic",
    target: {
        table: "Sales",
        column: "Region"
    },
    operator: "In",
    values: ["North", "South"],
    filterType: pbi.models.FilterType.BasicFilter
};

await report.setFilters([filter]);

Ereignisse erfassen:

report.on('loaded', function() {
    console.log('Report loaded successfully');
});

report.on('dataSelected', function(event) {
    const data = event.detail;
    // Handle user selection — navigate to detail page, update other UI, etc.
});

report.on('pageChanged', function(event) {
    const pageName = event.detail.newPage.displayName;
    // Track page navigation in your analytics
});

Token-Aktualisierung:

report.on('tokenExpired', async function() {
    const newToken = await fetchNewEmbedToken();
    await report.setAccessToken(newToken);
});

Navigationssteuerung:

// Navigate to a specific page
const pages = await report.getPages();
const targetPage = pages.find(p => p.displayName === 'Revenue Analysis');
await targetPage.setActive();

// Set a specific slicer value
const visuals = await targetPage.getVisuals();
const slicer = visuals.find(v => v.type === 'slicer');
await slicer.setSlicerState({
    filters: [{
        $schema: "http://powerbi.com/product/schema#basic",
        target: { table: "Date", column: "Year" },
        operator: "In",
        values: [2026],
        filterType: pbi.models.FilterType.BasicFilter
    }]
});

Phasenweises Rendering für mehr Leistung

Bei komplexen Berichten mit vielen visuellen Elementen verbessert das phasenweise Rendering die wahrgenommene Leistung, indem Inhalte, die über dem Falz liegen, zuerst gerendert werden:

const embedConfig = {
    // ... standard config
    settings: {
        // ... other settings
        commands: [{
            visualRendered: {
                phase: 1,
                visualNames: ['revenue-kpi', 'trend-chart', 'summary-table']
            }
        }]
    }
};

report.on('visualRendered', function(event) {
    if (event.detail.phase === 1) {
        // Hide loading spinner, show report
        document.getElementById('loading').style.display = 'none';
    }
});

---

Benutzerdefinierte Themen und Branding

Warum benutzerdefinierte Themes wichtig sind

Standardmäßige Power BI-Visuals verwenden die Farbpalette und den Stil von Microsoft. In einem eingebetteten Kontext führt dies zu einer visuellen Inkonsistenz mit Ihrer Anwendung. Benutzerdefinierte Themen passen die eingebetteten Analysen an das Designsystem Ihres Produkts an und sorgen dafür, dass sich das Erlebnis nativ und nicht aufgesetzt anfühlt.

Theme-JSON-Struktur

Power BI-Designs werden als JSON-Dateien mit Kontrolle über Farben, Schriftarten, visuelle Standardeinstellungen und Elementstil definiert:

{
    "name": "MyApp Theme",
    "dataColors": [
        "#2563EB", "#7C3AED", "#059669", "#D97706",
        "#DC2626", "#0891B2", "#4F46E5", "#65A30D"
    ],
    "background": "#FFFFFF",
    "foreground": "#1E293B",
    "tableAccent": "#2563EB",
    "textClasses": {
        "callout": {
            "fontSize": 28,
            "fontFace": "Inter, sans-serif",
            "color": "#0F172A"
        },
        "title": {
            "fontSize": 14,
            "fontFace": "Inter, sans-serif",
            "color": "#1E293B"
        },
        "header": {
            "fontSize": 12,
            "fontFace": "Inter, sans-serif",
            "color": "#475569"
        },
        "label": {
            "fontSize": 11,
            "fontFace": "Inter, sans-serif",
            "color": "#64748B"
        }
    },
    "visualStyles": {
        "*": {
            "*": {
                "border": [{
                    "color": {"solid": {"color": "#E2E8F0"}},
                    "radius": 8
                }],
                "background": [{
                    "color": {"solid": {"color": "#FFFFFF"}},
                    "transparency": 0
                }]
            }
        }
    }
}

Themes programmgesteuert anwenden

Themen können zum Zeitpunkt der Einbettung angewendet oder dynamisch gewechselt werden (nützlich für die Unterstützung des Dunkelmodus):

// Apply theme at embed time
const embedConfig = {
    // ... standard config
    theme: { themeJson: customThemeJson }
};

// Switch theme dynamically (e.g., light/dark mode toggle)
await report.applyTheme({ themeJson: darkThemeJson });

Power BI Chrome ausblenden

Für ein vollständig natives Erscheinungsbild blenden Sie die integrierten UI-Elemente von Power BI aus und ersetzen Sie sie durch Ihre eigenen Anwendungssteuerelemente:

const settings = {
    panes: {
        filters: { visible: false },      // Hide filter pane
        pageNavigation: { visible: false } // Hide page tabs
    },
    bars: {
        actionBar: { visible: false },     // Hide action bar
        statusBar: { visible: false }      // Hide status bar
    },
    background: pbi.models.BackgroundType.Transparent,
    visualRenderedEvents: true
};

Erstellen Sie dann benutzerdefinierte Navigations-, Filter- und Exportsteuerelemente im UI-Framework Ihrer Anwendung. Verwenden Sie das JavaScript SDK, um Filter programmgesteuert anzuwenden, Seiten zu ändern und Exporte auszulösen, wenn Benutzer mit Ihren benutzerdefinierten Steuerelementen interagieren.

Dieser Ansatz erfordert mehr Entwicklungsaufwand, sorgt aber für ein nahtloses Erlebnis, bei dem Benutzer nicht zwischen den nativen Funktionen Ihrer Anwendung und den eingebetteten Power BI-Inhalten unterscheiden können.

---

Leistungsoptimierung für Embedded

Frontend-Leistung

• Verzögertes Laden des SDK. Das Power BI JavaScript SDK ist ca. 300 KB groß. Laden Sie es asynchron und nur, wenn der Benutzer zu einer Analyseseite navigiert.
• Einbettungstokens vorab laden. Einbettungstokens generieren, bevor der Benutzer den Bericht anfordert. Wenn Ihre Anwendung weiß, dass der Benutzer wahrscheinlich Analysen anzeigen wird (basierend auf Navigationsmustern), laden Sie das Token während Seitenübergängen vor.
• Bootstrap-Einbettung verwenden. Das SDK unterstützt ein Bootstrap-Muster, das den Iframe initialisiert, bevor das Einbettungstoken verfügbar ist, wodurch die wahrgenommene Ladezeit um 200–500 ms reduziert wird.

// Bootstrap first (fast — creates iframe immediately)
const report = powerbi.bootstrap(container, { type: 'report' });

// Load later when token is available
const embedConfig = { /* full config */ };
report.load(embedConfig);

• Report-Caching implementieren. Sobald ein Bericht geladen ist, behält ihn der Iframe im Speicher. Wenn der Benutzer weg navigiert und zurückkehrt, verwenden Sie den vorhandenen Iframe erneut, anstatt ihn erneut einzubetten. Dadurch entfällt die Ladezeit für erneute Besuche innerhalb derselben Sitzung vollständig.

Backend-Leistung

• Einbettungstokens zwischenspeichern. Einbettungstokens sind für ihre gesamte Lebensdauer gültig (Standard 1 Stunde). Zwischenspeichern Sie sie in Redis oder im Arbeitsspeicher und verwenden Sie sie bei mehreren Anfragen für dieselbe Bericht-/Identitätskombination wieder.
• Batch-Token-Generierung. Wenn das Dashboard eines Benutzers mehrere eingebettete Berichte enthält, generieren Sie alle Einbettungs-Tokens in einem einzigen API-Aufruf mithilfe der Multi-Ressourcen-Funktion des GenerateToken-Endpunkts.
• Überwachen Sie die API-Ratenbegrenzungen. Die Power BI REST API verfügt über Ratenbegrenzungen pro Dienstprinzipal. Überwachen Sie 429 Antworten und implementieren Sie einen exponentiellen Backoff. Verteilen Sie bei umfangreichen Anwendungen die Last auf mehrere Dienstprinzipale.

Berichtsdesign für Embedded

Bei für die eingebettete Nutzung konzipierten Berichten sollte die Leistung Vorrang vor der visuellen Komplexität haben:

• Beschränken Sie die Anzahl der Visuals auf 8–12 pro Seite (jedes Visual generiert eine separate Abfrage)
• Verwenden Sie nach Möglichkeit den Importmodus anstelle von DirectQuery (10-100x schneller)
• Voraggregieren Sie Daten mit der entsprechenden Granularität
• Vermeiden Sie komplexe DAX-Kennzahlen auf Zielseiten (bewahren Sie sie für Drill-Through-Details auf)
• Verwenden Sie Lesezeichen für vorberechnete Ansichten anstelle dynamischer Berechnungen
• Testen Sie die Ladezeiten von Berichten auf Ihrem erwarteten Parallelitätsniveau, nicht nur bei Einzelbenutzern

Für Organisationen, die eingebettete Analysen implementieren, bietet ECOSIRE Architekturberatungs- und Entwicklungsdienste, um vom ersten Tag an eine optimale Leistung sicherzustellen.

---

Sicherheitsüberlegungen für Embedded

Token-Sicherheit

Einbettungstoken gewähren Zugriff auf Power BI-Inhalte. Behandeln Sie sie als vertrauliche Referenzen:

• Legen Sie Einbettungstokens niemals im clientseitigen Quellcode oder in URL-Parametern offen
• Generieren Sie Token serverseitig und stellen Sie sie über authentifizierte API-Endpunkte bereit
• Verwenden Sie die kürzeste praktische Token-Lebensdauer (die Standardeinstellung von 1 Stunde ist für die meisten Anwendungen angemessen). – Implementieren Sie eine Token-Aktualisierungslogik, anstatt langlebige Token zu generieren
• Überwachen Sie die Token-Generierungsmuster auf Anomalien (ungewöhnliches Volumen, unerwartete Berichts-IDs).

Mandantenisolationsvalidierung

Überprüfen Sie bei mandantenfähigen Anwendungen kontinuierlich die Mandantenisolation:

– Automatisierte Tests, die Einbettungstokens für Mandant A generieren und überprüfen, ob auf die Daten von Mandant B nicht zugegriffen werden kann – Abfrageprotokollierung zur Erkennung mandantenübergreifender Datenzugriffsversuche

• Regelmäßige RLS-Konfigurationsprüfungen (RLS-Rollen können in Power BI Desktop geändert und versehentlich geschwächt werden)
• Benachrichtigung bei RLS-Filterfehlern (die auf eine Fehlkonfiguration hinweisen könnten)

Netzwerksicherheit

– Beschränken Sie den Power BI-REST-API-Zugriff auf bekannte IP-Bereiche mithilfe des bedingten Azure AD-Zugriffs – Verwenden Sie private Endpunkte für Gateway-Verbindungen zu lokalen Datenquellen – Aktivieren Sie die Audit-Protokollierung im Power BI-Verwaltungsportal, um alle API-Aufrufe zu verfolgen und die Token-Generierung einzubetten

• Implementieren Sie Content Security Policy-Header, um die Einbettung von Iframes auf die Domäne Ihrer Anwendung zu beschränken

---

FAQ

Wie viel kostet Power BI Embedded für eine SaaS-Anwendung mit 10.000 Benutzern?

Die Kosten hängen von den gleichzeitigen Benutzern ab, nicht von der Gesamtzahl der Benutzer. Wenn 5 % Ihrer 10.000 Benutzer zu Spitzenzeiten gleichzeitig arbeiten (500 gleichzeitige Benutzer), benötigen Sie etwa F32-Kapazität zu etwa 8.200 US-Dollar pro Monat (Pay-as-you-go). Bei einer Reservierung (1-Jahres-Verpflichtung) sinkt dieser Betrag auf etwa 5.500 US-Dollar pro Monat. Ihre tatsächlichen Kosten können je nach Berichtskomplexität, Datensatzgröße und Nutzungsmuster höher oder niedriger sein. Start with F8 for a pilot, load test with realistic concurrency, and scale based on actual measurements.

Kann ich Power BI Embedded ohne Azure verwenden?

Power BI Embedded erfordert Azure AD für die Authentifizierung und die über Azure bereitgestellte Fabric/Embedded-Kapazität. Ihre Anwendung selbst kann überall gehostet werden (AWS, GCP, lokal), aber die Power BI-Ressourcen müssen sich in Azure befinden. Das Dienstprinzipal- oder Masterbenutzerkonto muss sich in Azure AD befinden und die Kapazität muss eine Azure-Ressource sein. Für Organisationen ohne vorhandenen Azure-Footprint fügt die Einrichtung etwa 2–4 ​​Stunden Azure-Konfigurationsarbeit und minimale laufende Azure-Verwaltung über die eigentliche Kapazität hinaus hinzu.

Was ist der Unterschied zwischen Power BI Embedded A-SKUs, EM-SKUs und Fabric F-SKUs?

Bei den A-SKUs handelte es sich um die ursprüngliche Power BI Embedded-Kapazität, die über Azure bereitgestellt wurde. EM-SKUs waren eine Lizenzierungsoption für die interne Einbettung in Office 365. Beide wurden durch Fabric F-SKUs ersetzt, die ein einheitliches Kapazitätsmodell für alle Power BI- und Fabric-Workloads bieten. F-SKUs bieten eine sekundengenaue Abrechnung, die Möglichkeit zum Anhalten/Fortsetzen und eine einfachere Preisstruktur. Verwenden Sie für neue Implementierungen ausschließlich F-SKUs. Bestehende A-SKU-Kunden sollten die Migration zu F-SKUs planen, um bessere Preise und Funktionen zu erhalten.

Können Benutzer Daten aus eingebetteten Berichten exportieren?

Ja, aber Sie steuern dies über die Einbettungseinstellungen. Mit dem JavaScript SDK können Sie Exportfunktionen (Export nach Excel, PDF, PowerPoint) pro Bericht aktivieren oder deaktivieren. Sie können auch benutzerdefinierte Exportfunktionen über die Export-API implementieren, die Ihnen mehr Kontrolle über Format, angewendete Filter und Audit-Protokollierung geben. Deaktivieren Sie für vertrauliche Daten den integrierten Export und stellen Sie Ihren eigenen Exportmechanismus bereit, der zusätzliche Autorisierungsprüfungen und Wasserzeichen anwendet.

Wie gehe ich mit der Berichtsentwicklung in einem eingebetteten Szenario um?

Die Berichtsentwicklung folgt dem standardmäßigen Power BI-Workflow: Berichte in Power BI Desktop erstellen, in einem Entwicklungsarbeitsbereich veröffentlichen, mit Beispiel-Einbettungstoken testen, über Bereitstellungspipelines in die Produktion hochstufen. Der Hauptunterschied besteht darin, dass eingebettete Berichte zusätzliche Tests auf RLS-Verhalten, Leistung bei Parallelität, reaktionsfähiges Layout über alle Bildschirmgrößen und Interaktion mit der Benutzeroberfläche Ihrer Anwendung erfordern. Richten Sie eine CI/CD-Pipeline ein, die als Teil jeder Berichtsbereitstellung automatisierte RLS-Validierung und Leistungsregressionstests umfasst.