Konnektivität mit Datasets mithilfe des XMLA-Endpunkts

Arbeitsbereiche in Power BI Premium, der Power BI-Einzelbenutzerlizenz und Power BI Embedded unterstützen die Open Platform-Konnektivität von Microsoft- und Drittanbieter-Clientanwendungen und -tools durch Verwenden eines XMLA-Endpunkts.

Was ist ein XMLA-Endpunkt?

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 Kommunikationsvorgänge erfolgen über das, was allgemein als XMLA-Endpunkte bezeichnet wird. XMLA ist das gleiche Kommunikationsprotokoll, das von der Microsoft Analysis Services-Engine verwendet wird, die hinter den Kulissen arbeitet und die semantische Modellierung, die Governance, den Lebenszyklus und die 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, die den Endpunkt verwenden, können aktiviert werden und bieten zusätzliche Funktionen für die Verwaltung von Datasets, Governance, erweiterte semantische Modellierung, Debugging und Überwachung. Mit aktiviertem Lese-/Schreibzugriff sind Datasets mit Azure Analysis Services- und SQL Server Analysis Services-Tools und Prozessen für die tabellarische Modellierung auf Unternehmensebene gleichwertiger.

Nutzungsbedingungen

Die Verwendung des XMLA-Endpunkts unterliegt Folgendem:

Einzelbenutzeranwendung: Die Anwendung verwendet ein einzelnes Benutzerkonto oder eine App-Identität, um über den XMLA-Endpunkt auf ein Power BI-Dataset zuzugreifen. Typische Beispiele sind Entwicklertools, Administratorskripts und automatisierte Prozesse zum Durchführen von Datenmodellierungs- und Verwaltungsaufgaben wie das Ändern der Metadaten eines Datasets, das Ausführen eines Sicherungs- oder Wiederherstellungsvorgangs oder das Auslösen einer Datenaktualisierung. 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.

  • Bei PPU-Arbeitsbereichen erfordert die Anwendung, dass sich jeder Benutzer bei Power BI anmeldet. Die Anwendung verwendet das jeweilige Zugriffstoken der Benutzer für den Zugriff auf Datasets. Die Anwendung darf kein Dienstkonto oder eine andere App-Identität verwenden, um Aufgaben im Namen ihrer Benutzer auszuführen. Jeder Benutzer muss sein eigenes Power BI-Konto verwenden, um Berichte zu öffnen, auf Datasets zuzugreifen und Abfragen auszuführen.
  • Bei Premium-Arbeitsbereichen kann die Anwendung ein Dienstkonto oder eine App-Identität im Namen der Endbenutzer verwenden, ohne dass sich jeder Benutzer bei Power BI anmelden muss.

Tools für Datenmodellierung und -verwaltung

Nachstehend sind einige der gängigsten Tools aufgeführt, die mit Azure Analysis Services und SQL Server Analysis Services verwendet werden und nun von Premium-Datasets unterstützt werden:

Visual Studio mit Analysis Services-Projekten  – Auch als SQL Server Data Tools oder einfach SSDT bezeichnet, ist ein Modellierungstool zur Erstellung von tabellarischen Analysis Services-Modellen auf Unternehmensebene. Analysis Services-Projekterweiterungen werden von allen Visual Studio 2017- und späteren Editionen unterstützt, wie z.B. der kostenlosen Community-Edition. Für die Bereitstellung von tabellarischen Modellen in einem Premium-Arbeitsbereich ist die Erweiterungsversion 2.9.14 oder höher erforderlich. Bei der Bereitstellung muss das Modell den Kompatibilitätsgrad 1500 oder höher aufweisen. Für die Datasets ist XMLA-Lese-/Schreibzugriff erforderlich. 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 mit der Tabular Model Scripting Language (TMSL) präzise Aktualisierungsvorgänge und Skripterstellungen für Datasetmetadaten durch. Für Abfragevorgänge ist Lesezugriff erforderlich. Für das Erstellen von Metadatenskripts ist Lese-/Schreibzugriff erforderlich. Hierfür ist SSMS-Version 18.8 oder höher erforderlich.  Hier herunterladen.

SQL Server Profiler  – Dieses mit SSMS installierte Tool ermöglicht das Verfolgen und Debuggen von Datasetereignissen. Trotz der offiziellen Einstufung als veraltet für SQL Server ist der Profiler auch weiterhin in SSMS enthalten und wird für Analysis Services und Power BI weiterhin unterstützt. Erfordert SQL Server Profiler, Version 18.8 oder höher. Der Benutzer muss beim Herstellen einer Verbindung mit dem XMLA-Endpunkt das Dataset (Anfangskatalog) angeben. 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  – Analysis Services-Cmdlets können zur Automatisierung von Dataset-Verwaltungsaufgaben wie Aktualisierungsvorgängen verwendet werden. XMLA-Schreib-/Lesezugriff ist erforderlich. Version 21.1.18221 oder höher des SqlServer-PowerShell-Moduls ist erforderlich. Die Azure Analysis Services-Cmdlets im Az.AnalysisServices-Modul 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 angibt, welche Daten abgerufen werden sollen, wo Sie abgerufen werden können 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. XMLA-Lesezugriff ist erforderlich. 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. Objekte sind in Anzeigeordnern mit Unterstützung für die Bearbeitung mehrerer ausgewählter Eigenschaften und die Hervorhebung der DAX-Syntax organisiert. Für Abfragevorgänge ist XMLA-Lesezugriff erforderlich. Für Metadatenvorgänge ist Lese-/Schreibzugriff erforderlich. Weitere Informationen erhalten Sie unter tabulareditor.github.io.

DAX Studio  – Ein Open-Source-Tool für die Erstellung, Diagnose, Leistungsoptimierung und Analyse von DAX. Zu den Features gehören Objektsuche, Integrierte Ablaufverfolgung, Aufschlüsselung der Abfrageausführung mit detaillierten Statistiken, Hervorhebung und Formatierung der DAX-Syntax. Für Abfragevorgänge ist XMLA-Lesezugriff erforderlich. 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. Für Abfragevorgänge ist Lesezugriff erforderlich. Für Metadatenvorgänge ist Lese-/Schreibzugriff erforderlich. Weitere Informationen finden Sie unter  alm-toolkit.com.

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

Drittanbieter  – Dazu gehören Clientanwendungen zur Datenvisualisierung und Tools, mit denen Verbindungen zu Datasets in Premium-Arbeitsbereichen hergestellt, diese abgefragt und verbraucht werden können. Für die meisten Tools sind die aktuellsten Versionen der MSOLAP-Clientbibliotheken erforderlich, für einige jedoch möglicherweise ADOMD. Der XMLA-Endpunkt mit Lese- oder Lese-/Schreibzugriff hängt von den Vorgängen ab.

Clientbibliotheken

Clientanwendungen 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 auch die Clientbibliotheken verwenden, um benutzerdefinierte Anwendungen zu erstellen. In manchen Fällen, insbesondere bei der Arbeit mit Drittanbieteranwendungen, müssen möglicherweise neuere Versionen der Clientbibliotheken installiert werden, falls diese nicht mit der Anwendung installiert wurden. Clientbibliotheken werden monatlich aktualisiert. Weitere Informationen finden Sie unter  Clientbibliotheken zum Herstellen einer Verbindung mit Analysis Services.

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 mit einer Größe von mehr als 1 GB (nach der Komprimierung) kann dies einen erheblichen Unterschied ausmachen. Weitere Informationen finden Sie unter Große Modelle in Power BI Premium.

Aktivieren von XMLA-Lese-/Schreibzugriff

Standardmäßig ist bei einer Premium-Kapazität die Einstellung der Eigenschaften für XMLA-Endpunkte auf Lesezugriff gesetzt. 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. Die Einstellung der Eigenschaft für den XMLA-Endpunkt für diese Kapazität können Sie in der Datasetworkload vornehmen. Die Einstellung des XMLA-Endpunkts gilt für alle Arbeitsbereiche und Datasets, die dieser Kapazität zugewiesen sind.

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

  1. Klicken Sie im Verwaltungsportal auf Capacity settings (Kapazitätseinstellungen) > Power BI Premium, und wählen Sie dann den Kapazitätsnamen aus.

  2. Erweitern Sie Workloads. Wählen Sie in der Einstellung XMLA-Endpunkt die Option Lesen Schreiben aus.

    Aktivieren des XMLA-Endpunkts

Herstellen einer Verbindung mit einem Premium-Arbeitsbereich

Arbeitsbereiche, die einer Kapazität zugewiesen sind, weisen eine Verbindungszeichenfolge im URL-Format auf, z. B.
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.

Hinweis

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.

So rufen Sie die Arbeitsbereichverbindungs-URL ab

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

Arbeitsbereichs-Verbindungszeichenfolge

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.

Auswählen des Datasets im SQL Server Profiler

Doppelte Arbeitsbereichsnamen

Neue Arbeitsbereiche (die mithilfe der neuen Arbeitsbereichsfunktion erstellt wurden) erzwingen in Power BI eine Überprüfung, um doppelte Namen beim Erstellen oder Umbenennen von Arbeitsbereichen zu unterbinden. Nicht migrierte Arbeitsbereiche können zu doppelten Namen führen. Beim Herstellen einer Verbindung mit einem Arbeitsbereich, der den gleichen Namen wie ein anderer Arbeitsbereich aufweist, wird möglicherweise der folgende Fehler angezeigt:

Verbindung zu „powerbi://api.powerbi.com/v1.0/[Name des Mandanten]/[Name des Arbeitsbereichs] kann nicht hergestellt werden.“

Um diesen Fehler zu umgehen, geben Sie über den Namen des Arbeitsbereichs hinaus die ObjectIDGuid ein, die Sie aus der objectID des Arbeitsbereichs in die URL kopieren können. Fügen Sie die objectID an die Verbindungs-URL an. Beispiel:
„powerbi://api.powerbi.com/v1.0/myorg/Contoso Vertrieb - 9d83d204-82a9-4b36-98f2-a40099093830“

Doppelter Datasetname

Beim Herstellen der Verbindung mit einem Dataset mit dem gleichen Namen wie ein weiteres Dataset im selben Arbeitsbereich 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

Bei Verbindungen mit einem Arbeitsbereich kann es bis zu 5 Minuten dauern, bis Änderungen aus neuen, gelöschten und umbenannten Datasets angezeigt werden.

Nicht unterstützte Datasets

Auf die folgenden Datasets kann nicht über den XMLA-Endpunkt zugegriffen werden. Diese 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 Excel-Arbeitsmappen.

Server/Arbeitsbereichalias

Aliase von Servernamen, 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) 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 zugelassen, Analysieren in Excel nicht zugelassen, AIXL für lokale Datasets nicht zugelassen XMLA zugelassen, In Excel analysieren nicht zugelassen, AIXL für lokale Datasets zugelassen
Liveverbindungen zulassen umschalten = aktiviert XMLA nicht zugelassen, In Excel analysieren zugelassen, AIXL für lokale Datasets nicht zugelassen XMLA zugelassen, In Excel analysieren zugelassen, AIXL für lokale Datasets zugelassen

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.

Mitwirkende im Arbeitsbereich und höhere Berechtigungen haben Schreibzugriff auf das Dataset und sind daher mit den Analysis Services-Datenbankadministratoren gleichgestellt. Sie können neue Datasets aus Visual Studio bereitstellen und TMSL-Skripts in SSMS ausführen.

Vorgänge, die Analysis Services Server-Administratorberechtigungen (statt Datenbankadministrator) erfordern, wie z. B. Ablaufverfolgung auf Serverebene und Identitätswechsel von Benutzern unter Verwendung der Eigenschaft EffectiveUserName für Verbindungszeichenfolgen, werden derzeit in Premium-Arbeitsbereichen nicht unterstützt.

Andere Benutzer, die über eine Berechtigung „Erstellen“ für ein Dataset verfügen, sind mit Analysis Services-Datenbanklesern gleichgestellt. 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.

Modellrollen

Mithilfe des XMLA-Endpunkts können Rollen für ein Dataset, Rollenmitgliedschaften für Azure Active Directory-Benutzer (Azure AD) und Filter für die Sicherheit auf Zeilenebene (Row-Level Security, RLS) definiert werden. Modellrollen in Power BI werden nur für RLS verwendet. Verwenden Sie das Power BI-Sicherheitsmodell, um Berechtigungen über RLS 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 mithilfe von SSMS definiert werden, um Rollenobjekte zu erstellen und Rolleneigenschaften zu definieren. In den meisten Fällen können jedoch mithilfe von TMSL Skripts für Rollenobjektdefinitionen erstellt werden, um das Rollenobjekt zu erstellen oder zu bearbeiten. TMSL-Skripts können in SSMS oder über das PowerShell-Cmdlet Invoke-ASCmd ausgeführt werden.

Beim Arbeiten mit Datasetrollen ü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, die Arbeitsbereichsmitglieder- oder Administratorberechtigungen erfordern, können nicht zu Rollen 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.
  • Mit der Verbindungszeichenfolgen-Eigenschaft „Roles=“ kann das Herabstufen von Rollenmitgliedern mit Schreibberechtigungen auf Leseberechtigungen getestet werden. Das Mitgliedskonto muss weiterhin Mitglied der relevanten RLS-Rolle sein. Dies unterscheidet sich von der Verwendung des Identitätswechsels mit SQL Server Analysis Services oder Azure Analysis Services, wo die RLS-Rollenmitgliedschaft angenommen wird, falls es sich um das Konto eines Serveradministrators handelt. Da kein Serveradministrator vorhanden ist, muss das Konto für Premium-Arbeitsbereiche einer Rolle angehören, damit RLS angewendet werden kann.

Weitere Informationen finden Sie unter Rollen in tabellarischen Modellen.

Festlegen der Anmeldeinformationen für Datenquellen

Über den XMLA-Endpunkt spezifizierte Metadaten können Verbindungen zu Datenquellen herstellen, aber keine Anmeldeinformationen für die Datenquellen 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 auch mit dem XMLA-Endpunkt verwendet werden. So können Dataset-Verwaltungsaufgaben wie das Bereitstellen von Arbeitsbereichen und Modellen sowie das Aktualisieren von Datasets automatisiert werden mit:

  • 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, müssen Sie zunächst die Verbindungs-URL des Arbeitsbereichs in der Eigenschaft Bereitstellungsserver des Projekts festlegen. 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.

Bereitstellungseigenschaft

Wenn die Eigenschaft „Bereitstellungsserver“ angegeben wurde, 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 nach der Erstellung des Datasets im Arbeitsbereich aus den Modell-Metadaten die Verarbeitung zum Laden von Daten aus Datenquellen in das Dataset fehl.

Bei der Verarbeitung tritt ein Fehler auf, da bei der Bereitstellung in einer Azure- oder SQL Server Analysis-Serverinstanz, wo die Anmeldeinformationen für die Datenquelle als Teil des Bereitstellungsvorgangs abgefragt werden, im Gegensatz zur Bereitstellung in einem Premium-Arbeitsbereich die Anmeldeinformationen für die Datenquelle nicht als Teil des Bereitstellungsvorgangs angegeben werden können. Stattdessen werden nach der erfolgreichen Bereitstellung von Metadaten und der Erstellung des Datasets die Anmeldeinformationen für die Datenquelle im Power BI-Dienst in den Einstellungen des Datasets angegeben. Klicken Sie im Arbeitsbereich auf DataSets > Einstellungen > Anmeldeinformationen für die Datenquelle > Anmeldeinformationen bearbeiten.

Anmeldeinformationen für die Datenquelle

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 jedoch für eine Datenquelle noch keine Anmeldeinformationen im Power BI-Dienst angegeben wurden, schlägt die Verarbeitung selbst dann fehl, wenn die Bereitstellung der Metadaten erfolgreich ist. Sie können die Eigenschaft auf Nicht verarbeiten setzen, wodurch ein Versuch der Verarbeitung im Rahmen der Bereitstellung verhindert wird. Sie können die Eigenschaft jedoch auch wieder auf Standard setzen, da die Verarbeitung im Rahmen nachfolgender Bereitstellungsvorgänge erfolgreich ist, sobald die Anmeldeinformationen für die Datenquelle in deren Einstellungen 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.

    Herstellen einer Verbindung in SSMS

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

SSMS

Weitere Informationen über die Verwendung von SSMS zur Erstellung von Metadaten finden Sie unter Erstellen von Analysis Services-Skripts und Tabular Model Scripting Language (TMSL).

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. Sie können z.B. bestimmte inkrementelle Aktualisierungen von historischen Partitionen vornehmen, 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.

Aktualisierungsverlauf über den XMLA-Endpunkt

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 manche DMVs kann beispielsweise nicht zugegriffen werden, weil sie Administratorberechtigungen für Analysis Services-Server benötigen.

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 in Power BI Desktop erstelltes Dataset, dass es als PBIX-Datei wieder heruntergeladen 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. Zwar wird die Inline-Datenquellendeklaration von Power Query M in Premium-Arbeitsbereichen unterstützt, jedoch nicht von Azure Analysis Services oder SQL Server Analysis Services. Stattdessen erstellen Analysis Services-Datenmodellierungstools wie Visual Studio Metadaten mithilfe von strukturierten und/oder Anbieter-Datenquellendeklarationen. 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. Wird eine Liveverbindung verwendet, müssen die Daten nicht lokal repliziert werden. Dadurch wird es für Benutzer einfacher, Semantikmodelle zu verwenden. Es gibt zwei Möglichkeiten, wie Benutzer eine Verbindung herstellen können:

Durch Auswählen von Power BI-Datasets und dann Auswählen eines Datasets, 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.

Herstellen einer Liveverbindung mit einem Dataset

Die andere Möglichkeit zur Herstellung einer Verbindung besteht darin, Daten abrufen > Analysis Services zu verwenden, den Namen eines Power BI Premium-Arbeitsbereichs als URL anzugeben, Live verbinden auszuwählen und dann im Navigator ein Dataset auszuwählen. 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.

Herstellen einer Liveverbindung mit Analysis Services

Organisationen, in denen mit Berichten gearbeitet wird, die über Liveverbindungen mit Analysis Services-Datenmodellen verbunden sind, und die beabsichtigen, zu Premium-Datasets zu migrieren, müssen nur die Servername-URL in Daten transformieren > Datenquelleneinstellungen ä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 Fragen? Stellen Sie Ihre Frage in der Power BI-Community.