Power BI Bericht

PowerBIReport zeigt im Portal einen Power-BI-Bericht an Nutzer ohne Power-BI-Lizenz, wobei jeder Betrachter nur seine eigenen Zeilen sieht. Es ist in einem eigenen Paket enthalten – PowerPortalsPro.Web.Blazor.PowerBI für Blazor, @powerportalspro/react-powerbi für React – sodass ein Portal, das keine Berichte anzeigt, das Power BI-Skript nicht enthält.

Wie es funktioniert

Die Komponente benennt einen Bericht mit einem Schlüssel. Das Portal schlägt den Schlüssel nach, entscheidet, ob der Viewer den Bericht sehen darf, und bittet Power BI um ein Token für ihn – als die Identität, mit der es bereits mit Dataverse verbunden ist, sodass im Portal nichts mehr konfiguriert werden kann. Der Token trägt die ID des Betrachters als Benutzername: seine Kontakt-ID oder die Benutzer-ID, wenn er Mitarbeiter ist, der im Portal angemeldet ist. Besucher, die nicht angemeldet sind, erhalten den Benutzernamen anonymous. Die Komponente erneuert das Token einige Minuten vor Ablauf, und der Bericht behält seinen Status, wenn er das tut.

Jeder Betrachter kann 30 Mal pro Minute um Berichtstoken bitten – ein angemeldeter Nutzer über sein Konto, ein Besucher über seine Adresse – und wird mit einer 429 darüber hinaus abgelehnt. Ein Token wird wiederverwendet, solange es laufen kann, sodass eine Seite nie in die Nähe kommt; das Limit verhindert, dass ein Betrachter wiederholte Anfragen in eine Last für das Portal oder Power BI umwandelt. Ändere es mit PowerPortalsPro:PowerBIRateLimit:PermitLimit und Window in der Konfiguration; eine PermitLimit von 0 schaltet es aus.

Registrierung eines Berichts

Welche Berichte ein Portal anzeigen darf und wem, sind Daten in Dataverse und nicht im Code, da jede Umgebung Berichte aus ihrem eigenen Arbeitsbereich einbettet. Zwei Tabellen in der Power Portals Pro-Lösung enthalten das:

• Portal Power BI Report – der Schlüssel, den eine Komponente nennt, sowie für den Power BI Arbeitsbereich und Bericht, für den er steht. Allow Without Row-Level Security ist standardmäßig deaktiviert: Ein Bericht, dessen Modell keine Zeilensicherheit hat, wird abgelehnt, weil jeder Betrachter jede Zeile sehen würde.
• Portal Power BI Report Access – wer den Bericht sehen kann und welche Rollen des Modells er erhält. Jede Zeile richtet sich an Inhaber einer Portal-Rolle, jeden angemeldeten Nutzer, anonyme Besucher oder interne Nutzer – Mitarbeiter sind als sie selbst und nicht als Kontakt angemeldet – und nennt die Rollen des Modells in Power BI Rollen, getrennt durch Kommas.

Ein Viewer sieht den Bericht, wenn eine seiner Zugriffszeilen auf ihn zutrifft, wobei jede Rolle die Zeilen, die gelten, benennen. Ein Schlüssel, der keinen Bericht nennt, und ein Bericht, der nicht für den Viewer ist, sehen für ihn gleich aus: eine Nachricht, dass der Report nicht verfügbar ist. Registrierungen werden alle fünfzehn Minuten gelesen; löschen Sie den Cache PowerBIReports , um eine Änderung sofort anzuwenden.

Sicherheit auf Reihenebene

Power BI wendet die Zeilensicherheit des Berichts auf den Benutzernamen des Tokens an. Um jeden Betrachter auf seine eigenen Zeilen zu halten, gibt es dem Modell eine Rolle, die die Spalte mit der Kontakt-ID USERNAME()vergleicht:

Das Portal prüft das Modell, bevor es nach einem Token fragt. Ein Modell mit Zeilensicherheit erhält die ID und Rollen des Betrachters in jedem Token, und eine Zugriffszeile, die keine Rolle nennt, wird abgelehnt. Power BI überprüft keine Rollennamen, daher scheitert eine falsch geschriebene Rolle nur, wenn der Bericht gezogen wird: Der MCP-Server vergleicht sie beim Schreiben von Zugriffszeilen mit dem Modell.

Benutzerdefinierte Daten

Eine Rolle kann über DAXs CUSTOMDATA()nach etwas anderem filtern als wer der Betrachter ist – die Kontonummer, ihre Region – . Register an IPowerBICustomDataProvider im Server Program.cs: Es wird für jedes Token abgefordert, das das Portal für ein Element ausgibt, dessen Modell Zeilensicherheit nutzt, mit dem Viewer und dem Item, und was zurückgegeben wird, fließt in das Token. Es läuft auf dem Server und wird nie aus dem Browser entfernt, weil es bestimmt, welche Zeilen ein Viewer sieht. Es wird nicht nach einem Element gefragt, das mit dem eigenen Power-BI-Zugriff des Betrachters angezeigt wird.

Der MCP-Server schreibt add_powerbi_rls_role eine solche Rolle mit filter: "customdata", indem er eine Text- oder Zahlenspalte vergleicht. Sein Filter benötigt außerdem benutzerdefinierte Daten im Token, sodass ein Token ohne Token keine Zeilen anzeigt, sondern jede Zeile mit leerer Spalte.

Einrichtung mit dem MCP-Server

Der MCP-Server richtet alles ein, außer dem Bericht selbst, und fungiert als Power BI-Konto, mit dem du dich einmal pro Ordner dnx PowerPortalsPro.Mcp powerbi loginanmeldest. Dieses Konto benötigt eine Power BI Pro-Lizenz. Bitte deinen Assistenten, einen Bericht einzurichten, oder ruf die Tools selbst an:

1. create_powerbi_workspace erstellt den Arbeitsbereich, in den du den Bericht aus Power BI Desktop publizierst.
2. grant_powerbi_workspace_access macht die Identität des Portals zu einem Mitglied davon.
3. add_powerbi_rls_role schreibt eine Rolle in das Modell des Berichts: eine, die einen Viewer zu den eigenen Kontaktzeilen, deren Unternehmen, deren Unternehmen und Tochtergesellschaften beibehält, jene, die eine Mapping-Tabelle mit ihnen auflistet, oder feste Werte – oder eine, die jede Zeile anzeigt. Er gibt dem DAX die Möglichkeit, dieselbe Rolle in Power BI Desktop hinzuzufügen, da das erneute Veröffentlichen des Berichts das Modell ersetzt.
4. register_powerbi_report und set_powerbi_report_access schreibt die beiden Dataverse-Tabellen.
5. check_powerbi überprüft die gesamte Kette, die als Portal selbst angemeldet ist.

Zwei Power BI-Mandanteneinstellungen müssen ein Fabric-Administrator ändern: Service Principals können öffentliche Fabric-APIs aufrufen und Inhalte in Apps einbetten. Neue Tenants haben beides aktiviert. Wenn einer von beiden ausgeschaltet ist, wird angezeigt, check_powerbi welche eingeschaltet werden soll.

Öffnen auf einer Seite, auf einen Datensatz gefiltert

PageName Öffnet den Bericht auf einer Seite und Filters schränkt ihn auf Zeilen ein, deren Spalte einen der Werte enthält – zum Beispiel das Konto, um das sich eine Detailseite handelt. Eine Änderung betrifft den bereits angezeigten Bericht, ohne ihn neu laden zu müssen. Ein Filter ist eine Bequemlichkeit, keine Sicherheit: Der Betrachter kann ihn in seinem Browser entfernen. Was sie sehen, wird durch die Sicherheit auf Zeilenebene bestimmt.

Dashboards und einzelne Kacheln

Eine Registrierung kann ein Dashboard oder eine Kachel eines Dashboards anstelle eines Berichts benennen – also ihren Artikeltyp, mit der ID des Dashboards und der Kachel. Die gleiche Komponente zeigt sie an: PowerBIReport Einbettet die Registrierungsnamen des Schlüssels. Ein Dashboard zeigt angepasst an seine Breite und OnTileClicked (onTileClicked) zeigt an, wann eine Kachel angeklickt wird und wohin sie führt. Eine Seite, Filter, Fenster und die Farben des Portals gelten nur für einen Bericht: Ein Dashboard oder eine Kachel wird so angezeigt, wie sie erstellt wurde.

Die Kacheln eines Dashboards können aus mehreren semantischen Modellen stammen, und jedes unterliegt denselben Regeln wie ein Bericht: Ein Modell mit Zeilensicherheit erhält die Identität und Rollen des Betrachters, und ein Modell ohne wird abgelehnt, es sei denn, die Registrierung erlaubt es. Eine Textkachel oder ein Bild liest keine Zeilen und benötigt keine von beiden. register_powerbi_report dashboardnimmt , und tile für eine ihrer Kacheln, und list_powerbi_reports listet die Dashboards und Kacheln eines Arbeitsbereichs auf. Kacheln werden im Power BI-Service angepinnt; es gibt keine Möglichkeit, eines von außerhalb zu pinnen.

Jeder Viewer hat seinen eigenen Power-BI-Zugriff

Der Embed-Modus einer Registrierung kann das Element mit dem eigenen Power-BI-Zugriff jedes Betrachters anzeigen, statt mit dem des Portals, wie es in Power BI der Fall ist. Power BI wendet seine eigene Freigabe und die zeilenebene Sicherheit der Modelle an – USERPRINCIPALNAME() das ist der Name, mit dem sie sich anmelden – sodass jeder Betrachter ein Arbeits- oder Schulkonto, eine Power BI-Lizenz und das mit ihm geteilte Element benötigt. Die Zugriffszeilen zeigen weiterhin an, wer fragen darf; ihre Power-BI-Rollen werden nicht genutzt. Das passt zu Mitarbeitern und Partnern, die bereits Power BI nutzen. Für Kunden benötigt der eigene Zugriff des Portals keine Lizenz.

Beim ersten Mal bietet die Komponente an, das Arbeitskonto des Betrachters mit Power BI zu verbinden. Sie melden sich bei Microsoft an, stimmen zu, dass das Portal ihre Power-BI-Berichte und Dashboards lesen darf, und kehren zur Seite zurück. Was dem Portal dadurch gegeben wird, bleibt auf dem Server, verschlüsselt auf dem Server des Hosters IDistributedCache; der Browser erhält nur ein kurzlebiges Zugriffstoken. Mit dem In-Memory-Cache verbinden sich die Viewer erneut, nachdem das Portal neu gestartet ist, und ein gemeinsamer Cache (Redis, SQL Server) hält sie verbunden. Das Abmelden trennt sie. Ein persönliches Microsoft-Konto, Google oder ein Passwort können sich nicht verbinden, und auch keine Sitzung, die jemand imitiert, kann sich verbinden.

Betrachter verbinden sich über die Microsoft-Anmelde-App-Registrierung des Portals, die Power BIs delegierte Report.Read.All und Dashboard.Read.All, Microsoft Graphs openid und offline_access, sowie die Redirect-URI https://<portal host>/signin-powerbibenötigt. Der MCP-Server add_powerbi_signin_permissions fügt sie alle hinzu und register_powerbi_report nimmt embedMode: "user". Ein Tenant, der nur Administratoren erlaubt, benötigt einmal, um ihn einmal zu erteilen. Um auch die Gäste des Tenants hereinzulassen, setzen PowerBIOptions.TenantId Sie den Tenant, der die Arbeitsbereiche hält.

Farben und Dunkelmodus

Standardmäßig nimmt der Bericht die Farben des Portals: sein helles oder dunkles Thema, seine Akzentfarbe und die Serienpalette, die die eigenen Diagramme des Portals verwenden. Er folgt dem Thema, wenn der Besucher es wechselt, ohne neu zu laden. Die Farben werden vom Fluent-Thema, in dem der Bericht steht, gelesen und als Power BI-Berichtsthema angewendet, das die Seite, den Text, die Achsen, den Filterbereich und die Serie des Berichts festlegt. Eine Farbe, die der Berichtautor auf ein Bild gesetzt hat, bleibt unverändert, und Power BI zeichnet die Seiten-Tabs unter dem Bericht in eigenen Farben, unabhängig vom Thema.

ThemeJson gibt dem Bericht stattdessen ein eigenes Thema im Theme-JSON-Format von Power BI; wie jedes Theme, das auf einen eingebetteten Bericht angewendet wird, ersetzt es das gespeicherte Thema des Berichts, anstatt es hinzuzufügen. UsePortalTheme="false" behält das Theme, mit dem der Bericht gespeichert wurde.

Entwicklung und Produktion

Ein Arbeitsbereich ohne Kapazität erhält die Test-Einbettungstoken von Power BI, die in ihrer Anzahl begrenzt sind, ein Banner zeigen und für Entwicklung und Tests gedacht sind. In der Produktion legt man den Arbeitsbereich auf eine Fabric-Kapazität: create_powerbi_capacity erstellt einen in Ihrem Azure-Abo, nachdem der Preis angezeigt wird, und set_powerbi_capacity_state pausiert ihn. Eine pausierte Kapazität erzeugt keine Berichte. Das Einbetten für Portalbesucher wird in einem Premium-per-Benutzer-Arbeitsbereich nicht unterstützt.