Konnektivität mit Datasets mithilfe des XMLA-Endpunkts

Power BI Premium, Premium pro Benutzer und Power BI Embedded Arbeitsbereiche verwenden einen XMLA-Endpunkt, um die Konnektivität über offene Plattformen von Microsoft und Clientanwendungen und Tools von Drittanbietern zu unterstützen.

XMLA-Endpunkte

Arbeitsbereiche verwenden das XML for Analysis-Protokoll (XMLA) für den Datenaustausch zwischen Clientanwendungen und der Engine, die Ihre Power BI-Arbeitsbereiche und -Datasets verwaltet. Diese Kommunikation erfolgt über sogenannte XMLA-Endpunkte. XMLA ist das Kommunikationsprotokoll, das von der Microsoft Analysis Services-Engine verwendet wird, die die semantische Modellierung, Governance, Lebenszyklus und Datenverwaltung von Power BI ausführt. Daten, die über das XMLA-Protokoll gesendet werden, sind vollständig verschlüsselt.

Standardmäßig ist die Konnektivität mit Lesezugriff unter Verwendung des Endpunkts für die Datasetworkload in einer Kapazität aktiviert. Mit schreibgeschützten Anwendungen und Tools für die Datenvisualisierung können Modelldaten, Metadaten, Ereignisse und Schemas von Datasets abgefragt werden.

Lese-/Schreibvorgänge mithilfe des Endpunkts können aktiviert werden. Lese-/Schreibzugriff bietet mehr Datasetverwaltung, Governance, erweiterte semantische Modellierung, Debuggen und Überwachung. Wenn sie aktiviert sind, haben Datasets eine größere Parität mit Azure Analysis Services und SQL Server Analysis Services tabellarischen Modellierungstools und -prozessen auf Unternehmensniveau.

Nutzungsbedingungen

Die Verwendung des XMLA-Endpunkts unterliegt Folgendes:

Einzelbenutzeranwendung: Die Anwendung verwendet ein einzelnes Benutzerkonto oder eine App-Identität, um über den XMLA-Endpunkt auf ein Power BI-Dataset zuzugreifen. Beispiele für Einzelbenutzeranwendungen sind Entwicklertools, Administratorskripts und automatisierte Prozesse. Diese Anwendungen können Aufgaben wie Datenmodellierung und Verwaltungsaufgaben ausführen, die die Metadaten eines Datasets ändern, sicherungs- oder wiederherstellungsvorgangs oder eine Datenaktualisierung auslösen. Das Benutzerkonto oder die App-Identität, die die Clientanwendung für den Zugriff auf ein Dataset verwendet, muss über eine gültige Premium-Einzelbenutzerlizenz (Premium Per User, PPU) verfügen, es sei denn, das Dataset befindet sich in einer Premium-Kapazität.

Anwendung mit mehreren Benutzern: Die Anwendung bietet mehreren Benutzern Zugriff auf ein Power BI-Dataset. Dies kann beispielsweise eine Anwendung der mittleren Ebene sein, die ein Dataset in eine Geschäftslösung integriert und im Namen der Geschäftsbenutzer auf das Dataset zugreift.

  • Premium-Arbeitsbereiche pro Benutzer (PPU): Für die Anwendung muss sich jeder Benutzer bei Power BI anmelden. Für jeden Benutzer verwendet die Anwendung ein Zugriffstoken für den Zugriff auf die Datasets. Die Anwendung kann kein Dienstkonto oder eine andere App-Identität verwenden, um Aufgaben im Namen einzelner Benutzer auszuführen. Jeder Benutzer muss über ein eigenes Power BI-Konto für das Öffnen von Berichten, den Zugriff auf Datasets und das Ausführen von Abfragen verfügen.
  • Für Premium-Arbeitsbereiche kann die Anwendung entweder ein Dienstkonto oder eine App-Identität im Namen von Endbenutzern verwenden, ohne dass sich jeder Benutzer bei Power BI anmelden muss.

Clientanwendungen und -tools

Gängige Anwendungen und Tools, die mit Azure Analysis Services und SQL Server Analysis Services verwendet werden und jetzt von Power BI Premium Datasets unterstützt werden:

Microsoft Excel – Excel-Pivottabellen sind gängige Tools, mit denen Sie Übersichtsdaten aus Power BI-Datasets zusammenfassen, analysieren, untersuchen und darstellen können. Für Abfragevorgänge ist Lesezugriff erforderlich. Erfordert die Klick-und-Run-Version von Office 16.0.13612.10000 oder höher.

Visual Studio mit Analysis Services-Projekten– bekannt als SQL Server Data Tools(SSDT). SSDT ist ein Modellerstellungstool für Unternehmen für Analysis Services-Tabellarische Modelle. Alle Visual Studio 2017- und höheren Editionen, einschließlich der kostenlosen Community-Edition, unterstützen Analysis Services-Projekterweiterungen. Erfordert die Erweiterung Version 2.9.14 oder höher, um tabellarische Modelle in einem Premium-Arbeitsbereich bereitzustellen. Das Modell muss für die Bereitstellung den Kompatibilitätsgrad 1500 oder höher aufweisen. Erfordert XMLA-Lese-/Schreibzugriff für die Datasetworkload. Weitere Informationen finden Sie unter Tools für Analysis Services.

SQL Server Management Studio (SSMS) – unterstützt DAX-, MDX- und XMLA-Abfragen. Führen Sie detaillierte Aktualisierungsvorgänge und Skripterstellung von Datasetmetadaten mithilfe der Tabular Model Scripting Language (TMSL) aus. Erfordert schreibgeschützt für Abfragevorgänge. Erfordert Lese-/Schreibzugriff für Skriptmetadaten. Dafür ist mindestens SSMS-Version 18.9 erforderlich. Laden Sie SSMS herunter.

SQL Server Profiler – SQL Server Profiler mit SSMS installiert wird, ermöglicht es die Ablaufverfolgung und das Debuggen von Datasetereignissen. Obwohl für SQL Server offiziell veraltet, ist Profiler weiterhin in SSMS enthalten und wird weiterhin für Analysis Services und Power BI unterstützt. Erfordert mindestens SQL Server Profiler Version 18.9. Benutzer müssen das Dataset (Anfangskatalog) angeben, wenn sie eine Verbindung mit dem XMLA-Endpunkt herstellen. Weitere Informationen finden Sie unter SQL Server Profiler für Analysis Services.

Bereitstellungs-Assistent für Analysis Services – Dieses mit SSMS installierte Tool ermöglicht die Bereitstellung von mit Visual Studio erstellten Projekten mit tabellarischen Modellen in Analysis Services- und Premium-Arbeitsbereichen. Er kann interaktiv oder über die Befehlszeile zur automatischen Ausführung gestartet werden. XMLA-Schreib-/Lesezugriff ist erforderlich. Weitere Informationen finden Sie unter Bereitstellungs-Assistent für Analysis Services.

PowerShell-Cmdlets : Verwenden Sie Analysis Services-Cmdlets, um Datasetverwaltungsaufgaben wie Aktualisierungsvorgänge zu automatisieren. Erfordert XMLA-Lese-/Schreibzugriff. Erfordert Version 21.1.18256 (für Gen2 Premium-Kapazitäten siehe Premium Gen2-Voraussetzungen) oder höher des SqlServer PowerShell-Moduls. Azure Analysis Services Cmdlets im Modul Az.AnalysisServices werden für Power BI-Datasets nicht unterstützt. Einzelheiten dazu finden Sie unter PowerShell-Referenz zu Analysis Services.

Power BI-Berichts-Generator – Ein Tool, das für das Erstellen von paginierten Berichten verwendet wird. Erstellen Sie eine Berichtsdefinition, die die abzurufenden Daten angibt, wo sie abgerufen werden sollen und wie sie angezeigt werden sollen. Sie können eine Vorschau Ihres Berichts im Berichts-Generator anzeigen und dann im Power BI-Dienst veröffentlichen. Erfordert XMLA schreibgeschützt. Weitere Informationen finden Sie unter Power BI-Berichts-Generator.

Tabellen-Editor – Ein Open-Source-Tool zur Erstellung, Bearbeitung und Verwaltung tabellarischer Modelle mit einem intuitiven, benutzerfreundlichen Editor. Eine hierarchische Ansicht zeigt alle Objekte in Ihrem tabellarischen Modell. Organisiert Objekte nach Anzeigeordnern mit Unterstützung für die Bearbeitung von Mehrfachauswahleigenschaften und die HERVORHEBUNG der DAX-Syntax. Erfordert XMLA schreibgeschützt für Abfragevorgänge. Erfordert Lese-/Schreibzugriff für Metadatenvorgänge. Weitere Informationen erhalten Sie unter tabulareditor.github.io.

DAX Studio – Ein Open-Source-Tool für die Erstellung, Diagnose, Leistungsoptimierung und Analyse mit DAX. Zu den Features gehören Objektsuche, Integrierte Ablaufverfolgung, Aufschlüsselung der Abfrageausführung mit detaillierten Statistiken, Hervorhebung und Formatierung der DAX-Syntax. Erfordert XMLA schreibgeschützt für Abfragevorgänge. Weitere Informationen finden Sie unter daxstudio.org.

ALM-Toolkit – Ein Open-Source-Schemavergleichstool für Power BI-Datasets, das am häufigsten für ALM-Szenarios (Application Lifecycle Management) verwendet wird. Führen Sie die Bereitstellung in verschiedenen Umgebungen durch und behalten Sie die inkrementelle Aktualisierung der Verlaufsdaten bei. Vergleichen Sie Metadatendateien, Branches und Repositorys mithilfe des Diff-Tools, und führen Sie sie zusammen. Verwenden Sie gängige Definitionen zwischen den einzelnen Datasets wieder. Erfordert schreibgeschützt für Abfragevorgänge. Erfordert Lese-/Schreibzugriff für Metadatenvorgänge. Weitere Informationen finden Sie unter alm-toolkit.com.

Drittanbieter – Dazu gehören Clientanwendungen zur Datenvisualisierung und Tools, mit denen Verbindungen zu Datasets in Premium-Arbeitsbereichen hergestellt, diese abgefragt und genutzt werden können. Die meisten Tools erfordern die neuesten Versionen von MSOLAP-Clientbibliotheken, aber einige können ADOMD verwenden. Der XMLA-Endpunkt mit Lese- oder Lese-/Schreibzugriff hängt von den Vorgängen ab.

Clientbibliotheken

Clientanwendungen und -tools kommunizieren nicht direkt mit dem XMLA-Endpunkt. Stattdessen verwenden sie Clientbibliotheken als Abstraktionsschicht. Dies sind die gleichen Clientbibliotheken, über die Anwendungen eine Verbindung mit Azure Analysis Services und SQL Server Analysis Services herstellen. Microsoft-Anwendungen wie Excel, SQL Server Management Studio (SSMS) und Analysis Services-Projekterweiterungen für Visual Studio installieren alle drei Clientbibliotheken und aktualisieren sie im Rahmen der regulären Anwendungs- und Erweiterungsupdates. Entwickler können die Clientbibliotheken verwenden, um benutzerdefinierte Anwendungen zu erstellen. In einigen Fällen, insbesondere bei Anwendungen von Drittanbietern, kann es erforderlich sein, neuere Versionen der Clientbibliotheken zu installieren, wenn sie nicht mit der Anwendung installiert werden. Clientbibliotheken werden monatlich aktualisiert. Weitere Informationen finden Sie unter Clientbibliotheken zum Herstellen einer Verbindung mit Azure Analysis Services.

Die mindestens erforderlichen Clientbibliotheksversionen für Premium Gen2-Kapazitäten sind in den Premium Gen2-Voraussetzungen aufgeführt.

Optimieren von Datasets für Schreibvorgänge durch Aktivieren von großen Modellen

Es wird empfohlen, bei der Verwendung des XMLA-Endpunkts für die Verwaltung von Datasets mit Schreibvorgängen das Dataset für große Modelle zu aktivieren. Dadurch wird der Aufwand von Schreibvorgängen reduziert, wodurch diese erheblich beschleunigt werden. Bei Datasets über 1 GB (nach der Komprimierung) kann der Unterschied erheblich sein. Weitere Informationen finden Sie unter Große Modelle in Power BI Premium.

Aktivieren von XMLA-Lese-/Schreibzugriff

Standardmäßig ist bei der Premium-Kapazität oder bei Datasetworkloads der Premium-Einzelbenutzerlizenz die Eigenschaftseinstellung für den XMLA-Endpunkt auf „Schreibgeschützt“ festgelegt. Das bedeutet, dass Anwendungen nur ein Dataset abfragen können. Damit Anwendungen Schreibvorgänge ausführen können, muss für den XMLA-Endpunkt der Lese-/Schreibzugriff zunächst über die Eigenschaft aktiviert werden.

So aktivieren Sie den Lese-/Schreibzugriff für eine Premium-Kapazität

  1. Wählen Sie Einstellungen>Admin Portal aus.

  2. Klicken Sie im Verwaltungsportal auf Kapazitätseinstellungen>Power BI Premium>Kapazitätsname.

  3. Erweitern Sie Workloads. Wählen Sie in der Einstellung XMLA-Endpunkt die Option Lesen Schreiben aus. Die Einstellung des XMLA-Endpunkts gilt für alle Arbeitsbereiche und Datasets, die dieser Kapazität zugewiesen sind.

    Screenshot: Einstellungen des XMLA-Endpunkts Schreibzugriff ist ausgewählt.

So aktivieren Sie Lese-/Schreibzugriff für die Premium-Einzelbenutzerlizenz

  1. Wählen Sie Einstellungen>Admin Portal aus.
  2. Wählen Sie im Verwaltungsportal Premium-Einzelbenutzerlizenz aus.
  3. Erweitern Sie die Enstellungen für Datasetworkloads. Wählen Sie in der Einstellung XMLA-Endpunkt die Option Lesen Schreiben aus.

Herstellen einer Verbindung mit einem Premium-Arbeitsbereich

Arbeitsbereiche, die einer Kapazität zugewiesen sind, weisen eine Verbindungszeichenfolge im URL-Format auf. Beispiel:

powerbi://api.powerbi.com/v1.0/[tenant name]/[workspace name].

Anwendungen, die eine Verbindung mit dem Arbeitsbereich herstellen, verwenden die URL, als handele es sich dabei um einen Analysis Services-Servernamen. Beispiel:

powerbi://api.powerbi.com/v1.0/contoso.com/Sales Workspace.

Benutzer mit UPNs im gleichen Mandanten (nicht B2B) können den Namen des Mandanten durch myorg ersetzen. Beispiel:

powerbi://api.powerbi.com/v1.0/myorg/Sales Workspace.

B2B-Benutzer müssen den UPN ihrer Organisation im Mandantennamen angeben. Beispiel:

powerbi://api.powerbi.com/v1.0/fabrikam.com/Sales Workspace.

Um den primären Domänennamen und die ID eines Power BI-Mandanten zu ermitteln, melden Sie sich bei Azure-Portal an, wählen Sie im Hauptmenü „Azure Active Directory“ aus, und notieren Sie sich dann die Informationen auf der Übersichtsseite von Azure Active Directory. Weitere Informationen finden Sie unter Suchen wichtiger IDs für einen Benutzer.

Hinweis

Die Verbindungsherstellung mit Mein Arbeitsbereich mithilfe des XMLA-Endpunkts wird derzeit nicht unterstützt.

So rufen Sie die Arbeitsbereichverbindungs-URL ab

Klicken Sie im Arbeitsbereich auf Einstellungen>Premium>Workspace Connection (Arbeitsbereichsverbindung) und dann auf Kopieren.

Screenshot der Einstellungsseite Der Abschnitt

Verbindungsanforderungen

Anfangskatalog

Bei einigen Tools wie dem SQL Server Profiler müssen Sie einen Anfangskatalog festlegen. Dabei handelt es sich um das Dataset (Datenbank), mit dem in Ihrem Arbeitsbereich eine Verbindung hergestellt werden soll. Klicken Sie im Dialogfeld Verbindung mit Server herstellen auf Optionen>Connection Properties (Verbindungseigenschaften)>Verbindung mit Datenbank herstellen, und geben Sie den Namen des Datasets ein.

Screenshot des Dialogfelds SQL Server Profiler Verbindung mit Server herstellen Der Abschnitt Herstellen einer Verbindung mit der Datenbank ist hervorgehoben.

Doppelte Arbeitsbereichsnamen

Arbeitsbereiche in Power BI-Überprüfung verhindern das Erstellen oder Umbenennen von Arbeitsbereichen mit doppelten Namen. Wenn Sie eine Verbindung mit einem Arbeitsbereich herstellen, der denselben Namen wie ein anderer Arbeitsbereich aufweist, wird möglicherweise die folgende Meldung angezeigt:

Es kann keine Verbindung mit powerbi://api.powerbi.com/v1.0/[tenant name]/[workspace name] hergestellt werden.

Um zu umgehen, geben Sie zusätzlich zum Arbeitsbereichsnamen die ObjectIDGuid an. Sie können die ObjectIDGuid aus der Arbeitsbereichsobjekt-ID in der URL kopieren. Fügen Sie die objectID an die Verbindungs-URL an. Beispiel:

powerbi://api.powerbi.com/v1.0/myorg/Contoso Sales - 9d83d204-82a9-4b36-98f2-a40099093830.

Doppelter Datasetname

Um eine Verbindung mit einem Dataset mit demselben Namen wie ein anderes Dataset im selben Arbeitsbereich herzustellen, fügen Sie die Dataset-GUID an den Namen des Datasets an. Sie können sowohl den Namen des Datasets als auch seine GUID abrufen, wenn eine Verbindung mit dem Arbeitsbereich in SSMS besteht.

Verzögerung bei der Anzeige von Datasets

Wenn Sie eine Verbindung mit einem Arbeitsbereich herstellen, können Änderungen aus neuen, gelöschten und umbenannten Datasets bis zu einigen Minuten dauern, bis sie angezeigt werden.

Nicht unterstützte Datasets

Auf die folgenden Datasets kann nicht über den XMLA-Endpunkt zugegriffen werden. Folgende Datasets werden in SSMS oder anderen Tools nicht unter dem Arbeitsbereich angezeigt:

  • Datasets, die auf einer Liveverbindung mit einem Azure Analysis Services- oder SQL Server Analysis Services-Modell basieren.
  • Datasets, die auf einer Liveverbindung mit einem Power BI-Dataset in einem anderen Arbeitsbereich basieren. Weitere Informationen finden Sie unter Einführung in die Verwendung von Datasets in mehreren Arbeitsbereichen.
  • Datasets mit Push-Datenübertragung mithilfe der REST-API.
  • Datasets in „Mein Arbeitsbereich“
  • Datasets in Excel-Arbeitsmappen.

Server/Arbeitsbereichalias

Servernamenalias, die in Azure Analysis Services unterstützt werden, werden für Premium-Arbeitsbereiche nicht unterstützt.

Sicherheit

Zusätzlich zur Konfigurierung der XMLA-Endpunkteigenschaft für Lese- und Schreibvorgänge durch den Kapazitätsadministrator muss die Einstellung XMLA-Endpunkte und "In Excel analysieren" bei lokalen Datasets zulassen im Verwaltungsportal aktiviert werden. Wenn Sie AIXL-Dateien (Analyze in Excel, In Excel analysieren) generieren müssen, die eine Verbindung mit dem XMLA-Endpunkt herstellen, sollte die Mandanteneinstellung Liveverbindungen zulassen ebenfalls aktiviert werden. Standardmäßig sind diese beiden Einstellungen aktiviert.

XMLA-Endpunkte und "In Excel analysieren" bei lokalen Datasets zulassen ist eine Integrationseinstellung.

Integrationseinstellung zum Zulassen von XMLA-Endpunkten

In der folgenden Tabelle werden die Auswirkungen der Einstellung Daten für XMLA exportieren und in Excel analysieren (AIXL) beschrieben:

Einstellung Zulassen von XMLA-Endpunkten und „In Excel analysieren“ mit lokalen Datasets = deaktiviert Zulassen von XMLA-Endpunkten und „In Excel analysieren“ mit lokalen Datasets = aktiviert
Liveverbindungen zulassen umschalten = deaktiviert XMLA nicht zulässig, Analyse in Excel nicht zulässig, AIXL für lokale Datasets nicht zulässig XMLA zulässig, Analysieren in Excel nicht zulässig, AIXL für lokale Datasets zulässig
Liveverbindungen zulassen umschalten = aktiviert XMLA nicht zulässig, Analysieren in Excel zulässig, AIXL für lokale Datasets nicht zulässig XMLA zulässig, Analysieren in Excel zulässig, AIXL für lokale Datasets zulässig

Liveverbindungen zulassen ist eine Export- und Freigabeeinstellung.

Export- und Freigabeeinstellungen zum Zulassen von Liveverbindungen

Beim Zugriff über den XMLA-Endpunkt wird die auf Arbeitsbereichs-/Anwendungsebene festgelegte Mitgliedschaft in der Sicherheitsgruppe berücksichtigt.

Arbeitsbereichsmitwirkende und höher verfügen über Berechtigungen zum Schreiben von Datasets, die effektiv mit Analysis Services-Datenbankadministratoren identisch sind. Sie können neue Datasets aus Visual Studio bereitstellen und TMSL-Skripts in SSMS ausführen.

Benutzer mit Berechtigungen zum Erstellen von Datasets entsprechen Analysis Services-Datenbanklesern. Sie können eine Verbindung mit Datasets herstellen und Daten für die Nutzung und Visualisierung durchsuchen. Regeln für die Sicherheit auf Zeilenebene (Row-Level Security, RLS) werden berücksichtigt, und es werden keine internen Datasetmetadaten angezeigt.

Vorgänge, die Analysis Services-Serveradministratorberechtigungen (anstelle von Datenbankadministratoren) erfordern, werden im Allgemeinen nicht unterstützt.

Identitätswechsel

Der Identitätswechsel des Benutzers mithilfe der Eigenschaft EffectiveUserName-Verbindungszeichenfolge wird beim Herstellen einer Verbindung mit Premium-Arbeitsbereichsdatasets unterstützt. Das in EffectiveUserName angegebene Konto muss sich im Azure Active Directory des Mandanten befinden und muss über Lese - und Buildberechtigungen für das Dataset verfügen, mit dem eine Verbindung hergestellt wird. Wenn das Konto nicht über die Berechtigungen Lesen und Erstellen verfügt, kann Power BI die Identität des Benutzerkontos nicht annehmen. Die Verbindung schlägt fehl, und ein Fehler wird zurückgegeben.

Sie können auch einen Identitätswechsel durchführen, indem Sie eine oder mehrere Arbeitsbereichsrollen in der Eigenschaft Rollen-Verbindungszeichenfolge angeben. Mit der Roles-Eigenschaft können Sie das Herabstufen von Rollenmitgliedern mit Schreibberechtigungen auf Leseberechtigungen testen. Die folgenden Rollenberechtigungen gelten abhängig vom Konto des angemeldeten Benutzers:

  • Wenn der Benutzer, der einen Identitätswechsel durchführt, ein Arbeitsbereichsadministrator ist , der effektiv mit einem Serveradministrator in Analysis Services übereinstimmt, muss er kein Mitglied einer der angegebenen Rollen sein.

  • Wenn der Benutzer, der den Identitätswechsel durchführt, kein Arbeitsbereichsadministrator ist , muss er einer oder mehreren der angegebenen Rollen angehören, andernfalls wird ein Benutzer nicht gefunden, oder es wird kein Berechtigungstypfehler zurückgegeben.

Modellrollen

Mit dem XMLA-Endpunkt können Rollen, Rollenmitgliedschaft, Sicherheit auf Zeilenebene (RLS) und Sicherheit auf Objektebene (OLS) für Benutzer in Azure Active Directory (Azure AD) des Mandanten definiert werden. Modellrollen in Power BI werden nur für RLS und OLS verwendet. Verwenden Sie das Power BI-Sicherheitsmodell, um Berechtigungen über RLS und OLS hinaus zu steuern.

Für in Visual Studio erstellte Tabellenmodellprojekte können Rollen mithilfe des Rollen-Managers im Modell-Designer definiert werden. Für Datasets in Power BI können Rollen vor der Veröffentlichung im Dienst in Power BI Desktop definiert werden. Die Rollenmitgliedschaft wird im Power BI-Dienst angegeben. SSMS kann auch zum Erstellen und Verwalten von Rollen verwendet werden. In den meisten Fällen können Rollenobjektdefinitionen mithilfe von TMSL geskriptet werden, um das Roles-Objekt zu erstellen oder zu ändern. TMSL-Skripts können in SSMS oder über das PowerShell-Cmdlet Invoke-ASCmd ausgeführt werden.

Beim Arbeiten mit Rollen über den XMLA-Endpunkt gelten die folgenden Einschränkungen:

  • Die einzige Berechtigung für eine Rolle, die für Datasets festgelegt werden kann, ist die Leseberechtigung. Andere Berechtigungen werden über des Power BI-Sicherheitsmodell erteilt.
  • Dienstprinzipale funktionieren nicht mit RLS und OLS und können nicht als Modellrollenmember hinzugefügt werden.
  • Für den Lesezugriff über den XMLA-Endpunkt ist eine Berechtigung zum Erstellen eines Datasets erforderlich, unabhängig davon, ob Datasetrollen vorhanden sind.

Festlegen von Datenquellenanmeldeinformationen

Metadaten, die über den XMLA-Endpunkt angegeben werden, können Verbindungen mit Datenquellen herstellen, aber keine Datenquellenanmeldeinformationen festlegen. Stattdessen können die Anmeldeinformationen auf der Seite für die Dataseteinstellungen im Power BI-Dienst festgelegt werden.

Dienstprinzipale

Dienstprinzipale sind eine App-Registrierung in Azure Active Directory, die Sie in Ihrem Mandanten erstellen, um unbeaufsichtigte Vorgänge auf Ressourcen- und Dienstebene auszuführen. Es handelt sich dabei um eine besondere Art von Benutzeridentität mit einem App-Namen, einer Anwendungs-ID und einer Mandanten-ID sowie einem geheimen Clientschlüssel oder Zertifikat als Kennwort. Power BI Premium verwendet dieselbe Dienstprinzipalfunktion wie Power BI Embedded.

Dienstprinzipale können mit dem XMLA-Endpunkt verwendet werden, um Datasetverwaltungsaufgaben wie die Bereitstellung von Arbeitsbereichen, das Bereitstellen von Modellen und die Aktualisierung von Datasets mit zu automatisieren:

  • PowerShell
  • Azure Automation
  • Azure Logic Apps
  • Benutzerdefinierten Clientanwendungen

Weitere Informationen finden Sie unter Automatisieren von Arbeitsbereichs- und Datasetaufgaben in Power BI Premium mithilfe von Dienstprinzipalen.

Bereitstellen von Modellprojekten aus Visual Studio (SSDT)

Die Bereitstellung eines tabellarischen Modellprojekts in Visual Studio für einen Premium-Arbeitsbereich entspricht in etwa der Bereitstellung auf einem Azure- oder SQL Server Analysis Services-Server. Die einzigen Unterschiede bestehen in der für das Projekt angegebenen Bereitstellungsservereigenschaft und darin, wie die Anmeldeinformationen für die Datenquelle angegeben werden, damit Verarbeitungsvorgänge Daten aus Datenquellen in das neue Dataset im Arbeitsbereich importieren können.

Um ein in Visual Studio erstelltes Tabellarisches Modellprojekt bereitzustellen, legen Sie die Verbindungs-URL des Arbeitsbereichs in der Project Deployment Server-Eigenschaft fest. Klicken Sie in Visual Studio im Projektmappen-Explorer mit der rechten Maustaste auf das Projekt, und wählen Sie >Eigenschaften aus. Fügen Sie in der Eigenschaft Server die Arbeitsbereichverbindungs-URL ein.

Screenshot des Konfigurationsfensters. Server ist im Hauptbereich hervorgehoben. OK ist ausgewählt.

Wenn die Eigenschaft Bereitstellungsserver angegeben ist, kann das Projekt bereitgestellt werden.

Bei der erstmaligen Bereitstellung wird im Arbeitsbereich mithilfe von Metadaten aus der model.bim-Datei ein Dataset erstellt. Im Rahmen des Bereitstellungsvorgangs schlägt die Verarbeitung zum Laden von Daten aus Datenquellen fehl, nachdem das Dataset im Arbeitsbereich aus Modellmetadaten erstellt wurde.

Die Verarbeitung schlägt fehl, da im Gegensatz zur Bereitstellung in einer Azure- oder SQL Server Analysis Server-Instanz, bei der Sie im Rahmen des Bereitstellungsvorgangs zur Eingabe von Datenquellenanmeldeinformationen aufgefordert werden, bei der Bereitstellung in einem Premium-Arbeitsbereich keine Datenquellenanmeldeinformationen im Rahmen des Bereitstellungsvorgangs angegeben werden können. Stattdessen werden nach der erfolgreichen Metadatenbereitstellung und dem Erstellen des Datasets die Anmeldeinformationen der Datenquelle im Power BI-Dienst in den Dataseteinstellungen angegeben. Klicken Sie im Arbeitsbereich auf DataSets>Einstellungen>Anmeldeinformationen für die Datenquelle>Anmeldeinformationen bearbeiten.

Screenshot: Dialogfeld

Wenn die Anmeldeinformationen für die Datenquelle festgelegt sind, können Sie dann das Dataset im Power BI-Dienst aktualisieren, die zeitgesteuerte Aktualisierung konfigurieren oder die Verarbeitung über SQL Server Management Studio durchführen, um Daten in das Dataset zu laden.

Die im Projekt in Visual Studio spezifizierte Bereitstellungseigenschaft Verarbeitungsoption wird berücksichtigt. Wenn für eine Datenquelle jedoch keine Anmeldeinformationen im Power BI-Dienst angegeben wurden, schlägt die Verarbeitung fehl, selbst wenn die Metadatenbereitstellung erfolgreich ist. Sie können die -Eigenschaft auf Do Not Process (Nicht verarbeiten) festlegen, um jegliche Verarbeitungsversuche im Rahmen der Bereitstellung zu verhindern. Möglicherweise möchten Sie die Eigenschaft wieder auf Standard festlegen, da die Verarbeitung im Rahmen nachfolgender Bereitstellungsvorgänge erfolgreich ausgeführt wird, sobald die Datenquellenanmeldeinformationen in den Datenquelleneinstellungen für das neue Dataset angegeben sind.

Herstellen einer Verbindung mit SSMS

Die Verwendung von SSMS zur Verbindung mit einem Arbeitsbereich ähnelt einer Verbindung mit einem Azure- oder SQL Server Analysis Services-Server. Der einzige Unterschied besteht darin, dass Sie die Arbeitsbereichs-URL im Servernamen angeben, und Sie müssen die Authentifizierung Active Directory: universell mit MFA verwenden.

Herstellen einer Verbindung mit einem Arbeitsbereich mithilfe von SSMS

  1. Klicken Sie in SQL Server Management Studio auf Verbinden>Verbindung mit Server herstellen.

  2. Wählen Sie unter Servertyp die Option Analysis Services aus. Geben Sie in Servername die Arbeitsbereichs-URL ein. Wählen Sie in Authentifizierung die Option Active Directory: universell mit MFA aus, und geben Sie dann in Benutzername Ihre Organisationsbenutzer-ID ein.

    Screenshot des Dialogfelds

Bei hergestellter Verbindung wird der Arbeitsbereich als Analysis Services-Server angezeigt, und im Arbeitsbereich vorhandene Datasets werden als Datenbanken angezeigt.

Screenshot des Fensters

Weitere Informationen zur Verwendung von SSMS zum Erstellen von Skripts für Metadaten finden Sie unter:

Datasetaktualisierung

Der XMLA-Endpunkt ermöglicht eine Vielzahl von Szenarios für detaillierte Aktualisierungsfunktionen mit SSMS, Automatisierung mit PowerShell, Azure Automation und Azure Functions mit TOM. Beispielsweise können Sie bestimmte verlaufsbezogene Partitionen der inkrementellen Aktualisierung aktualisieren, ohne alle Verlaufsdaten neu laden zu müssen.

Anders als bei der Konfiguration von Aktualisierungen im Power BI-Dienst sind Aktualisierungsvorgänge über den XMLA-Endpunkt nicht auf 48 Aktualisierungen pro Tag beschränkt. Außerdem gilt der Timeout für geplante Aktualisierungen nicht.

Datum, Uhrzeit und Status von Datasetaktualisierungsvorgängen, die eine Schreibtransaktion über den XMLA-Endpunkt enthalten, werden aufgezeichnet und im Aktualisierungsverlauf des Datasets angezeigt.

Hinweis

Aktualisierungsvorgänge, die vom XMLA-Endpunkt ausgeführt werden, aktualisieren Kachelcaches nicht automatisch. Kachelcaches werden nur aktualisiert, wenn ein Benutzer auf den Bericht zugreift.

Screenshot des Bildschirms

Dynamische Verwaltungssichten (Dynamic Management Views, DMVs)

Analysis Services DMVs ermöglichen die Sichtbarkeit von Metadaten, der Datenherkunft und der Ressourcennutzung von Datensets. DMVs, die für Abfragen in Power BI über den XMLA-Endpunkt verfügbar sind, beschränken sich höchstens auf diejenigen, die Datenbankadministratorberechtigungen erfordern. Auf einige DMVs kann beispielsweise nicht zugegriffen werden, da sie Analysis Services-Serveradministratorberechtigungen erfordern.

Erstellte Power BI Desktop-Datasets

Erweiterte Metadaten

XMLA-Schreibvorgänge für Datasets, die in Power BI Desktop erstellt und in einem Premium-Arbeitsbereich veröffentlicht wurden, erfordern erweiterte Metadaten. Weitere Informationen finden Sie unter Aktivieren erweiterter Datasetmetadaten.

Achtung

Zu diesem Zeitpunkt verhindert ein Schreibvorgang für ein Dataset, das in Power BI Desktop erstellt wurde, dass es als PBIX-Datei zurückgedownloadet wird. Stellen Sie sicher, dass Sie die ursprüngliche PBIX-Datei beibehalten.

Datenquellendeklaration

Bei der Verbindung mit Datenquellen und der Abfrage von Daten verwendet Power BI Desktop Power Query M-Ausdrücke als Inline-Datenquellendeklarationen. Obwohl in Premium-Arbeitsbereichen unterstützt wird, wird Power Query M-Inlinedatenquelldeklaration von Azure Analysis Services oder SQL Server Analysis Services nicht unterstützt. Stattdessen erstellen Analysis Services-Datenmodellierungstools wie Visual Studio Metadaten mithilfe von strukturierten Oder Anbieterdatenquelldeklarationen. Mit dem XMLA-Endpunkt unterstützt Premium auch strukturierte und Anbieterdatenquellen, jedoch nicht als Teil von Power Query M-Inline-Datenquellendeklarationen in Power BI Desktop-Modellen. Weitere Informationen finden Sie unter Grundlegendes zu Anbietern.

Power BI Desktop im Liveverbindungsmodus

Power BI Desktop kann über eine Liveverbindung mit einem Power BI Premium-Dataset verbunden werden. Mithilfe einer Liveverbindung müssen Daten nicht lokal repliziert werden, sodass Benutzer semantische Modelle leichter nutzen können. Es gibt zwei Möglichkeiten, wie Benutzer eine Verbindung herstellen können:

  • Wählen Sie Power BI-Datasets und dann ein Dataset aus, um einen Bericht zu erstellen. Dies ist die empfohlene Vorgehensweise für Benutzer, um Liveverbindungen mit Datasets herzustellen. Diese Methode bietet eine verbesserte Erkundungsumgebung, die den Zustimmungsgrad von Datasets zeigt. Benutzer müssen keine Arbeitsbereichs-URLs finden und nachverfolgen. Um ein Dataset zu finden, geben Benutzer einfach den Datasetnamen ein, oder sie scrollen, bis sie das gesuchte Dataset gefunden haben.

    Screenshot der Power BI Desktop power BI-Datasets ist im Menüband hervorgehoben. Das Dialogfeld Dataset auswählen befindet sich im Hauptbereich.

  • Geben Sie unter Abrufen von Data>Analysis Services einen Power BI Premium Arbeitsbereichsnamen als URL an, wählen Sie Live verbinden aus, und wählen Sie dann im Navigator ein Dataset aus. In diesem Fall verwendet Power BI Desktop den XMLA-Endpunkt, um eine Liveverbindung mit dem Dataset so herzustellen, als wäre dieses ein Analysis Services-Datenmodell.

    Screenshot: Auswahl von Power BI Desktop Analysis Services Live verbinden ist im Analysis Services-Datenbankdialogfeld hervorgehoben.

Organisationen, die über live mit Analysis Services-Datenmodellen verbundene Berichte verfügen und die eine Migration zu Premium-Datasets beabsichtigen, müssen nur die Servernamen-URL in denEinstellungen für Datenquellen transformieren> ändern.

Überwachungsprotokolle

Wenn Anwendungen eine Verbindung mit einem Arbeitsbereich herstellen, wird der Zugriff über XMLA-Endpunkte in den Power BI-Überwachungsprotokollen mit den folgenden Vorgängen protokolliert:

Anzeigename für Vorgang Vorgangsname
Verbunden mit Power BI-Dataset aus einer externen Anwendung ConnectFromExternalApplication
Aktualisierung von mit Power BI-Dataset aus einer externen Anwendung angefordert RefreshDatasetFromExternalApplication
Power BI-Dataset aus einer externen Anwendung erstellt CreateDatasetFromExternalApplication
Power BI-Dataset aus einer externen Anwendung bearbeitet EditDatasetFromExternalApplication
Power BI-Dataset aus einer externen Anwendung gelöscht DeleteDatasetFromExternalApplication

Weitere Informationen finden Sie unter Power BI-Überwachung.

Siehe auch

Weitere Informationen zu diesem Artikel finden Sie unter: