Microsoft Power BI XMLA Verbindungsdetails

Einführung

Connector-Version

Diese Dokumentation basiert auf Version 23.0.8895 des Connectors.

Erste Schritte

Unterstützung für Microsoft Power BI XMLA Version

Der Connector verpackt die Komplexität der Verbindung mit Microsoft Power BI XMLA in einem Treiber: Führen Sie SQL-92-Abfragen aus oder leiten Sie MDX-Abfragen von relationalen Tools weiter.

Herstellen einer Verbindung

Herstellen einer Verbindung mit Microsoft Power BI XMLA

Zum Verbinden setzen Sie die Workspace-Eigenschaft zu einem gültigen PowerBIXMLA-Arbeitsbereich (Beispiel: ).

Authentifizieren bei Microsoft Power BI XMLA

Microsoft Entra ID

Azure AD ist der mehrinstanzenfähige, cloudbasierte Verzeichnis- und Identitätsverwaltungsdienst von Microsoft. Es handelt sich um eine benutzerbasierte Authentifizierung, für die Sie Folgendes festlegen müssen: AuthScheme Zu AzureAD.

Die Authentifizierung bei Microsoft Entra ID über eine Webanwendung erfordert immer die Erstellung einer benutzerdefinierten OAuth-Anwendung. Weitere Informationen finden Sie unter Erstellen einer benutzerdefinierten OAuth-App.

Desktop-Anwendungen

bietet eine eingebettete OAuth-Anwendung, die die Verbindung zu Microsoft Entra ID von einer Desktop-Anwendung aus vereinfacht.

Sie können sich auch von einer Desktop-Anwendung aus mit einer benutzerdefinierten OAuth-Anwendung authentifizieren. (Weitere Informationen finden Sie unter Erstellen einer benutzerdefinierten OAuth-App.) Um sich über die Microsoft Entra ID zu authentifizieren, legen Sie diese Parameter fest:

• AuthScheme: AzureAD.
• Nur benutzerdefinierte Anwendungen:
  • OAuthClientId: Die Client-ID, die Ihnen bei der Registrierung Ihrer benutzerdefinierten OAuth-Anwendung zugewiesen wurde.
  • OAuthClientSecret: Das Client-Geheimnis, das Ihnen bei der Registrierung Ihrer benutzerdefinierten OAuth-Anwendung zugewiesen wurde.
  • CallbackURL: Die Umleitungs-URI, die Sie bei der Registrierung Ihrer benutzerdefinierten OAuth-Anwendung definiert haben.

Wenn Sie eine Verbindung herstellen, öffnet der Connector den OAuth-Endpoint von Microsoft Power BI XMLA in Ihrem Standardbrowser. Melden Sie sich an und erteilen Sie der Anwendung Berechtigungen.

Der Connector schließt den OAuth-Prozess ab, erhält ein Zugriffstoken von Microsoft Power BI XMLA und verwendet es zum Anfordern von Daten. Die OAuth-Werte werden im in angegebenen Pfad gespeichert OAuthSettingsLocation. Diese Werte bleiben über Verbindungen hinweg bestehen.

Wenn das Zugriffstoken abläuft, aktualisiert der Connector es automatisch.

Microsoft Entra-Dienstprinzipal

Dienstprinzipale sind Sicherheitsobjekte innerhalb einer Microsoft Entra ID -Anwendung, die definieren, was diese Anwendung innerhalb eines bestimmten Microsoft Entra ID Mandanten tun kann. Dienstprinzipale werden im Azure-Dienstportal erstellt.

Im Rahmen des Erstellungsprozesses geben wir auch an, ob der Dienstprinzipal über ein Clientgeheimnis oder ein Zertifikat auf Microsoft Entra ID Ressourcen zugreift.

Die Berechtigungen von Dienstprinzipalen sind nicht an einen bestimmten Benutzer gebunden, sondern basieren auf den ihnen zugewiesenen Rollen. Der Anwendungszugriff auf die Ressourcen wird über die Berechtigungen der zugewiesenen Rollen gesteuert.

Wenn Sie sich mit einem Microsoft Entra-Dienstprinzipal authentifizieren, müssen Sie eine Anwendung bei einem Microsoft Entra ID Mandanten registrieren, wie unter Erstellen einer Microsoft Entra ID Anwendung mit Dienstprinzipal beschrieben.

Nach dem Festlegen der in diesem Unterabschnitt beschriebenen Eigenschaften können Sie eine Verbindung herstellen. Diese variieren, je nachdem, ob Sie sich über ein Client-Geheimnis oder ein Zertifikat authentifizieren.

Authentifizierung mit Client Secret

• AuthScheme: AzureServicePrincipal.
• AzureTenant: Der Microsoft Entra ID Mandant, mit dem Sie eine Verbindung herstellen möchten.
• OAuthGrantType: CLIENT.
• OAuthClientId: Die Client-ID in Ihren Anwendungseinstellungen.
• OAuthClientSecret: Das Client-Geheimnis in Ihren Anwendungseinstellungen.

Authentifizierung mit Zertifikat

• AuthScheme: AzureServicePrincipalCert.
• AzureTenant: Der Microsoft Entra ID Mandant, mit dem Sie eine Verbindung herstellen möchten.
• OAuthGrantType: CLIENT.
• OAuthClientId: Die Client-ID in Ihren Anwendungseinstellungen.
• OAuthJWTCert: Der JWT-Zertifikatspeicher.
• OAuthJWTCertType: Der JWT-Zertifikatspeichertyp.

Erstellen einer Microsoft Entra ID Anwendung

Erstellen einer Microsoft Entra ID Anwendung

Microsoft Power BI XMLA unterstützt benutzerbasierte Authentifizierung mit Microsoft Entra ID. Diese Authentifizierung ist OAuth-basiert.

bettet OAuth-Anwendungsanmeldeinformationen mit Branding ein, die beim Herstellen einer Verbindung mit Microsoft Power BI XMLA über eine Desktopanwendung oder eine Headless-Maschine verwendet werden können. Um eine Verbindung mit Microsoft Power BI XMLA über das Web herzustellen, müssen Sie immer eine benutzerdefinierte Anwendung erstellen, wie hier beschrieben.

Da benutzerdefinierte Microsoft Entra ID Anwendungen jedoch alle drei häufig verwendeten Authentifizierungsabläufe nahtlos unterstützen, möchten Sie möglicherweise für diese anderen Authentifizierungsabläufe eine benutzerdefinierte Anwendung erstellen (verwenden Sie Ihre eigenen Anmeldeinformationen für Microsoft Entra ID -Anwendungen).

Benutzerdefinierte OAuth-Anwendungen sind nützlich, wenn Sie:

• Kontrollieren Sie das Branding des Authentifizierungsdialogs.
• Steuern Sie die Umleitungs-URI, zu der die Anwendung den Benutzer nach seiner Authentifizierung umleitet.
• Passen Sie die Berechtigungen an, die Sie vom Benutzer anfordern.

Authentifizieren mit Microsoft Entra ID

In <https://portal.azure.com>:

1. Wählen Sie im linken Navigationsbereich Microsoft Entra ID > App registrations.

2. Klicken Sie auf New registration.

3. Geben Sie einen Namen für die Anwendung ein.

4. Geben Sie die Arten von Konten an, die diese Anwendung unterstützen soll:

   • Für Anwendungen zur privaten Nutzung wählen Sie Accounts in this organization directory only.
   • Für verteilte Anwendungen wählen Sie eine der Multi-Tenant-Optionen.

1. Setzen Sie die Umleitungs-URI auf http://localhost:33333 (Standard) ODER, wenn Sie möchten

   anderen Port angeben, gewünschten Port angeben und einstellen CallbackURL zur genauen Antwort URL, die Sie gerade definiert haben.

2. Um die neue Anwendung zu registrieren, klicken Sie auf Register. Ein Anwendungsverwaltungsbildschirm wird angezeigt. Notieren Sie diese Werte zur späteren Verwendung. (Sie verwenden die Application (client) IDWert zum Festlegen von OAuthClientId Parameter und die Directory (tenant) IDWert zum Festlegen von AzureTenant Parameter.)

3. Navigieren Sie zu Certificates & Secrets. Wählen New Client Secret für diese Anwendung und geben Sie die gewünschte Dauer an. Nachdem das Clientgeheimnis gespeichert wurde, zeigt die Azure App-Registrierung den Schlüsselwert an. Dieser Wert wird nur einmal angezeigt, notieren Sie ihn also für die zukünftige Verwendung. (Sie werden ihn verwenden, um den festzulegen OAuthClientSecret.)

4. Wählen Sie Power BI-Dienst -> Delegierte Berechtigungen -> Dataset.Read.All und Workspace.Read.All.

5. Wenn Sie die Verwendung von Berechtigungen angegeben haben, für die die Zustimmung des Administrators erforderlich ist (z. B. Anwendungsberechtigungen), können Sie diese vom aktuellen Mandanten aus auf der Seite „API Berechtigungen“ erteilen.

Administratoreinwilligung erteilen

Für einige benutzerdefinierte Anwendungen sind Administratorberechtigungen erforderlich, um innerhalb eines Microsoft Entra ID -Mandanten ausgeführt zu werden. Die Administratorzustimmung kann beim Erstellen einer neuen benutzerdefinierten Microsoft Entra ID Anwendung erteilt werden, indem relevante Berechtigungen hinzugefügt werden, die bereits mit „Administratorzustimmung erforderlich“ gekennzeichnet sind. Die Administratorzustimmung ist auch erforderlich, um Clientanmeldeinformationen im Authentifizierungsablauf zu verwenden.

So erteilen Sie die Administratoreinwilligung:

1. Lassen Sie einen Administrator sich anmelden bei https://portal.azure.com.
2. Navigieren Sie zu App Registrations und suchen Sie die benutzerdefinierte Microsoft Entra ID Anwendung, die Sie erstellt haben.
3. Unter API Permissions, klick Grant Consent und folgen Sie dem Assistenten.

Dadurch erhält Ihre Anwendung Berechtigungen für den Mandanten, unter dem sie erstellt wurde.

Erstellen einer Microsoft Entra ID Anwendung

Microsoft Power BI XMLA unterstützt benutzerbasierte Authentifizierung mit Microsoft Entra ID. Diese Authentifizierung ist OAuth-basiert.

bettet OAuth-Anwendungsanmeldeinformationen mit Branding ein, die beim Herstellen einer Verbindung mit Microsoft Power BI XMLA über eine Desktopanwendung oder eine Headless-Maschine verwendet werden können. Um eine Verbindung mit Microsoft Power BI XMLA über das Web herzustellen, müssen Sie immer eine benutzerdefinierte Anwendung erstellen, wie hier beschrieben.

Da benutzerdefinierte Microsoft Entra ID Anwendungen jedoch alle drei häufig verwendeten Authentifizierungsabläufe nahtlos unterstützen, möchten Sie möglicherweise für diese anderen Authentifizierungsabläufe eine benutzerdefinierte Anwendung erstellen (verwenden Sie Ihre eigenen Anmeldeinformationen für Microsoft Entra ID -Anwendungen).

Benutzerdefinierte OAuth-Anwendungen sind nützlich, wenn Sie:

• Kontrollieren Sie das Branding des Authentifizierungsdialogs.
• Steuern Sie die Umleitungs-URI, zu der die Anwendung den Benutzer nach seiner Authentifizierung umleitet.
• Passen Sie die Berechtigungen an, die Sie vom Benutzer anfordern.

Authentifizieren mit Microsoft Entra ID

In <https://portal.azure.com>:

1. Wählen Sie im linken Navigationsbereich Microsoft Entra ID > App registrations.

2. Klicken Sie auf New registration.

3. Geben Sie einen Namen für die Anwendung ein.

4. Geben Sie die Kontotypen an, die diese Anwendung unterstützen soll:

   • Für Anwendungen zur privaten Nutzung wählen Sie Accounts in this organization directory only.
   • Für verteilte Anwendungen wählen Sie eine der Multi-Tenant-Optionen.

1. Setzen Sie die Umleitungs-URI auf http://localhost:33333 (Standard) ODER, wenn Sie möchten

   anderen Port angeben, gewünschten Port angeben und einstellen CallbackURL zur genauen Antwort URL, die Sie gerade definiert haben.

2. Um die neue Anwendung zu registrieren, klicken Sie auf Register. Ein Anwendungsverwaltungsbildschirm wird angezeigt. Notieren Sie diese Werte zur späteren Verwendung. (Sie verwenden die Application (client) IDWert zum Festlegen von OAuthClientId Parameter und die Directory (tenant) IDWert zum Festlegen von AzureTenant Parameter.)

3. Navigieren Sie zu Certificates & Secrets. Wählen New Client Secret für diese Anwendung und geben Sie die gewünschte Dauer an. Nachdem das Clientgeheimnis gespeichert wurde, zeigt die Azure App-Registrierung den Schlüsselwert an. Dieser Wert wird nur einmal angezeigt, notieren Sie ihn also für die zukünftige Verwendung. (Sie werden ihn verwenden, um den festzulegen OAuthClientSecret.)

4. Wählen Sie Power BI-Dienst -> Delegierte Berechtigungen -> Dataset.Read.All und Workspace.Read.All.

5. Wenn Sie die Verwendung von Berechtigungen angegeben haben, für die die Zustimmung des Administrators erforderlich ist (z. B. Anwendungsberechtigungen), können Sie diese vom aktuellen Mandanten aus auf der Seite „API Berechtigungen“ erteilen.

Administratoreinwilligung erteilen

Für einige benutzerdefinierte Anwendungen sind Administratorberechtigungen erforderlich, um innerhalb eines Microsoft Entra ID -Mandanten ausgeführt zu werden. Die Administratorzustimmung kann beim Erstellen einer neuen benutzerdefinierten Microsoft Entra ID Anwendung erteilt werden, indem relevante Berechtigungen hinzugefügt werden, die bereits mit „Administratorzustimmung erforderlich“ gekennzeichnet sind. Die Administratorzustimmung ist auch erforderlich, um Clientanmeldeinformationen im Authentifizierungsablauf zu verwenden.

So erteilen Sie die Administratoreinwilligung:

1. Lassen Sie einen Administrator sich anmelden bei https://portal.azure.com.
2. Navigieren Sie zu App Registrations und suchen Sie die benutzerdefinierte Microsoft Entra ID Anwendung, die Sie erstellt haben.
3. Unter API Permissions, klick Grant Consent und folgen Sie dem Assistenten.

Dadurch erhält Ihre Anwendung Berechtigungen für den Mandanten, unter dem sie erstellt wurde.

Erstellen einer benutzerdefinierten OAuth-App

Erstellen einer Microsoft Entra ID Anwendung

Microsoft Power BI XMLA unterstützt benutzerbasierte Authentifizierung mit Microsoft Entra ID. Diese Authentifizierung ist OAuth-basiert.

bettet OAuth-Anwendungsanmeldeinformationen mit Branding ein, die beim Herstellen einer Verbindung mit Microsoft Power BI XMLA über eine Desktopanwendung oder eine Headless-Maschine verwendet werden können. Um eine Verbindung mit Microsoft Power BI XMLA über das Web herzustellen, müssen Sie immer eine benutzerdefinierte Anwendung erstellen, wie hier beschrieben.

Da benutzerdefinierte Microsoft Entra ID Anwendungen jedoch alle drei häufig verwendeten Authentifizierungsabläufe nahtlos unterstützen, möchten Sie möglicherweise für diese anderen Authentifizierungsabläufe eine benutzerdefinierte Anwendung erstellen (verwenden Sie Ihre eigenen Anmeldeinformationen für Microsoft Entra ID -Anwendungen).

Benutzerdefinierte OAuth-Anwendungen sind nützlich, wenn Sie:

• Kontrollieren Sie das Branding des Authentifizierungsdialogs.
• Steuern Sie die Umleitungs-URI, zu der die Anwendung den Benutzer nach seiner Authentifizierung umleitet.
• Passen Sie die Berechtigungen an, die Sie vom Benutzer anfordern.

Authentifizieren mit Microsoft Entra ID

In <https://portal.azure.com>:

1. Wählen Sie im linken Navigationsbereich Microsoft Entra ID > App registrations.

2. Klicken Sie auf New registration.

3. Geben Sie einen Namen für die Anwendung ein.

4. Geben Sie die Kontotypen an, die diese Anwendung unterstützen soll:

   • Für Anwendungen zur privaten Nutzung wählen Sie Accounts in this organization directory only.
   • Für verteilte Anwendungen wählen Sie eine der Multi-Tenant-Optionen.

1. Setzen Sie die Umleitungs-URI auf http://localhost:33333 (Standard) ODER, wenn Sie möchten

   anderen Port angeben, gewünschten Port angeben und einstellen CallbackURL zur genauen Antwort URL, die Sie gerade definiert haben.

2. Um die neue Anwendung zu registrieren, klicken Sie auf Register. Ein Anwendungsverwaltungsbildschirm wird angezeigt. Notieren Sie diese Werte zur späteren Verwendung. (Sie verwenden die Application (client) IDWert zum Festlegen von OAuthClientId Parameter und die Directory (tenant) IDWert zum Festlegen von AzureTenant Parameter.)

3. Navigieren Sie zu Certificates & Secrets. Wählen New Client Secret für diese Anwendung und geben Sie die gewünschte Dauer an. Nachdem das Clientgeheimnis gespeichert wurde, zeigt die Azure App-Registrierung den Schlüsselwert an. Dieser Wert wird nur einmal angezeigt, notieren Sie ihn also für die zukünftige Verwendung. (Sie werden ihn verwenden, um den festzulegen OAuthClientSecret.)

4. Wählen Sie Power BI-Dienst -> Delegierte Berechtigungen -> Dataset.Read.All und Workspace.Read.All.

5. Wenn Sie die Verwendung von Berechtigungen angegeben haben, für die die Zustimmung des Administrators erforderlich ist (z. B. Anwendungsberechtigungen), können Sie diese vom aktuellen Mandanten aus auf der Seite „API Berechtigungen“ erteilen.

Administratoreinwilligung erteilen

Für einige benutzerdefinierte Anwendungen sind Administratorberechtigungen erforderlich, um innerhalb eines Microsoft Entra ID -Mandanten ausgeführt zu werden. Die Administratorzustimmung kann beim Erstellen einer neuen benutzerdefinierten Microsoft Entra ID Anwendung erteilt werden, indem relevante Berechtigungen hinzugefügt werden, die bereits mit „Administratorzustimmung erforderlich“ gekennzeichnet sind. Die Administratorzustimmung ist auch erforderlich, um Clientanmeldeinformationen im Authentifizierungsablauf zu verwenden.

So erteilen Sie die Administratoreinwilligung:

1. Lassen Sie einen Administrator sich anmelden bei https://portal.azure.com.
2. Navigieren Sie zu App Registrations und suchen Sie die benutzerdefinierte Microsoft Entra ID Anwendung, die Sie erstellt haben.
3. Unter API Permissions, klick Grant Consent und folgen Sie dem Assistenten.

Dadurch erhält Ihre Anwendung Berechtigungen für den Mandanten, unter dem sie erstellt wurde.

Erstellen einer Microsoft Entra ID Anwendung

Microsoft Power BI XMLA unterstützt benutzerbasierte Authentifizierung mit Microsoft Entra ID. Diese Authentifizierung ist OAuth-basiert.

bettet OAuth-Anwendungsanmeldeinformationen mit Branding ein, die beim Herstellen einer Verbindung mit Microsoft Power BI XMLA über eine Desktopanwendung oder eine Headless-Maschine verwendet werden können. Um eine Verbindung mit Microsoft Power BI XMLA über das Web herzustellen, müssen Sie immer eine benutzerdefinierte Anwendung erstellen, wie hier beschrieben.

Da benutzerdefinierte Microsoft Entra ID Anwendungen jedoch alle drei häufig verwendeten Authentifizierungsabläufe nahtlos unterstützen, möchten Sie möglicherweise für diese anderen Authentifizierungsabläufe eine benutzerdefinierte Anwendung erstellen (verwenden Sie Ihre eigenen Anmeldeinformationen für Microsoft Entra ID -Anwendungen).

Benutzerdefinierte OAuth-Anwendungen sind nützlich, wenn Sie:

• Kontrollieren Sie das Branding des Authentifizierungsdialogs.
• Steuern Sie die Umleitungs-URI, zu der die Anwendung den Benutzer nach seiner Authentifizierung umleitet.
• Passen Sie die Berechtigungen an, die Sie vom Benutzer anfordern.

Authentifizieren mit Microsoft Entra ID

In <https://portal.azure.com>:

1. Wählen Sie im linken Navigationsbereich Microsoft Entra ID > App registrations.

2. Klicken Sie auf New registration.

3. Geben Sie einen Namen für die Anwendung ein.

4. Geben Sie die Kontotypen an, die diese Anwendung unterstützen soll:

   • Für Anwendungen zur privaten Nutzung wählen Sie Accounts in this organization directory only.
   • Für verteilte Anwendungen wählen Sie eine der Multi-Tenant-Optionen.

1. Setzen Sie die Umleitungs-URI auf http://localhost:33333 (Standard) ODER, wenn Sie möchten

   anderen Port angeben, gewünschten Port angeben und einstellen CallbackURL zur genauen Antwort URL, die Sie gerade definiert haben.

2. Um die neue Anwendung zu registrieren, klicken Sie auf Register. Ein Anwendungsverwaltungsbildschirm wird angezeigt. Notieren Sie diese Werte zur späteren Verwendung. (Sie verwenden die Application (client) IDWert zum Festlegen von OAuthClientId Parameter und die Directory (tenant) IDWert zum Festlegen von AzureTenant Parameter.)

3. Navigieren Sie zu Certificates & Secrets. Wählen New Client Secret für diese Anwendung und geben Sie die gewünschte Dauer an. Nachdem das Clientgeheimnis gespeichert wurde, zeigt die Azure App-Registrierung den Schlüsselwert an. Dieser Wert wird nur einmal angezeigt, notieren Sie ihn also für die zukünftige Verwendung. (Sie werden ihn verwenden, um den festzulegen OAuthClientSecret.)

4. Wählen Sie Power BI-Dienst -> Delegierte Berechtigungen -> Dataset.Read.All und Workspace.Read.All.

5. Wenn Sie die Verwendung von Berechtigungen angegeben haben, für die die Zustimmung des Administrators erforderlich ist (z. B. Anwendungsberechtigungen), können Sie diese vom aktuellen Mandanten aus auf der Seite „API Berechtigungen“ erteilen.

Administratoreinwilligung erteilen

Für einige benutzerdefinierte Anwendungen sind Administratorberechtigungen erforderlich, um innerhalb eines Microsoft Entra ID -Mandanten ausgeführt zu werden. Die Administratorzustimmung kann beim Erstellen einer neuen benutzerdefinierten Microsoft Entra ID Anwendung erteilt werden, indem relevante Berechtigungen hinzugefügt werden, die bereits mit „Administratorzustimmung erforderlich“ gekennzeichnet sind. Die Administratorzustimmung ist auch erforderlich, um Clientanmeldeinformationen im Authentifizierungsablauf zu verwenden.

So erteilen Sie die Administratoreinwilligung:

1. Lassen Sie einen Administrator sich anmelden bei https://portal.azure.com.
2. Navigieren Sie zu App Registrations und suchen Sie die benutzerdefinierte Microsoft Entra ID Anwendung, die Sie erstellt haben.
3. Unter API Permissions, klick Grant Consent und folgen Sie dem Assistenten.

Dadurch erhält Ihre Anwendung Berechtigungen für den Mandanten, unter dem sie erstellt wurde.

Abrufen von PowerBI-Daten

Microsoft Power BI XMLA ist eine OLAP-Datenbank, die Daten als Würfel bereitstellt, die Sie mit MDX (multidimensional expressions) Abfrage können. Der Connector modelliert diese Würfel in relationalen Ansichten, die Sie mit SQL-92 Abfrage können. Die folgende Zuordnung dient dem Layout des Modells:

• Catalog - Wird im Connector als Katalog angezeigt.
• Cube - Wird im Connector als Schema angezeigt.
• Measure - Verfügbar im Connector unter der speziellen Maßnahmenansicht.
• Dimension - Jede Dimension wird als Ansicht angezeigt.
• Level - Jede einzelne Ebene einer Hierarchie wird als Spalte in der entsprechenden Dimensionsansicht angezeigt.

Kennzahlen und Dimensionen verknüpfen

Um Kennzahlen pro spezifischem Ebenenwert abzurufen, führen Sie eine Verknüpfung zwischen der Kennzahlenansicht und einer beliebigen Dimension oder einem Satz von Dimensionen aus. Wenn Sie beispielsweise Folgendes ausführen, wird die Anzahl der Kunden in jeder Stadt abgerufen:

SELECT m.[Customer Count], c.[City]
FROM [AdventureWorksDW2012Multidimensional-SE].[Adventure Works].Customer AS c
INNER JOIN [AdventureWorksDW2012Multidimensional-SE].[Adventure Works].Measures AS m

Beachten Sie, dass keine ON-Bedingung erforderlich ist. Das liegt daran, dass Tabellen in Microsoft Power BI XMLA bereits entsprechend verknüpft sind. Wenn Sie ein Tool verwenden, das ON-Bedingungen erfordert, setzen Sie IncludeJoinColumns auf true. Dadurch werden jeder Ansicht eine Reihe von Fremdschlüsselspalten angehängt, die sie miteinander in Beziehung setzen. Diese Spalten geben selbst keine Daten zurück, können aber automatisch mit Tools abgerufen werden, um bei Bedarf die ON-Bedingungen für Verknüpfungen zu konstruieren.

Aggregierte Daten

In Microsoft Power BI XMLA gespeicherte Daten sind bereits aggregiert. In vielen Fällen kann der Versuch, ein Aggregat abzurufen, syntaktisch dem Nichts-Angeben entsprechen. Beispielsweise gibt die folgende Abfrage genau dieselben Daten zurück wie die vorherige:

SELECT SUM(m.[Customer Count]), c.[City]
FROM [AdventureWorksDW2012Multidimensional-SE].[Adventure Works].Customer AS c
INNER JOIN [AdventureWorksDW2012Multidimensional-SE].[Adventure Works].Measures AS m
GROUP BY c.[City]

Die Ausnahme von dieser Regel ist, wenn eine Aggregation gefilterter Ergebnisse angefordert wird. In solchen Fällen wird eine Berechnung von Microsoft Power BI XMLA angefordert. Um beispielsweise die Summe und den Durchschnitt der Kunden in Frankreich und Deutschland zu berechnen:

SELECT SUM(m.[Customer Count]), AVG(m.[Customer Count]), c.[Country]
FROM [AdventureWorksDW2012Multidimensional-SE].[Adventure Works].Customer AS c
INNER JOIN [AdventureWorksDW2012Multidimensional-SE].[Adventure Works].Measures AS m
WHERE c.[Country] IN ('France', 'Germany')
GROUP BY c.[Country]

Mehrere Hierarchien auswählen

In Microsoft Power BI XMLA bestehen einzelne Dimensionen aus Hierarchien, die eine oder mehrere Ebenen haben können. Die Tabelle „AdventureWorks Customers“ enthält beispielsweise die Werte „Stadt“, „Land“ und „Geschlecht“. „Stadt“ und „Land“ sind Teil derselben Hierarchie, während „Geschlecht“ eine eigene Hierarchie darstellt.

Wenn Sie mehrere Hierarchien auswählen, besteht die Methode zur Unterstützung darin, die Werte in MDX zu verknüpfen. Dies ist zwar aus einem relationalen Tabellenmodell der Daten, wie es der Connector darstellt, nicht ersichtlich, kann jedoch dazu führen, dass sehr aufwändige Abfragen ausgeführt werden. Führen Sie beispielsweise Folgendes aus:

SELECT c.[Country], m.[Customer Count]
FROM [AdventureWorksDW2012Multidimensional-SE].[Adventure Works].Customer AS c
INNER JOIN [AdventureWorksDW2012Multidimensional-SE].[Adventure Works].Measures AS m

Ergibt 6 Zeilen. Wenn Sie jedoch auch Geschlecht auswählen:

SELECT c.[Country], c.[Gender], m.[Customer Count]
FROM [AdventureWorksDW2012Multidimensional-SE].[Adventure Works].Customer AS c
INNER JOIN [AdventureWorksDW2012Multidimensional-SE].[Adventure Works].Measures AS m

Ergibt jetzt 12 Zeilen. Das liegt daran, dass Geschlecht und Land in unterschiedlichen Hierarchien liegen, sodass ein Crossjoin erforderlich ist, um beide zusammen zurückzugeben. Jede zusätzliche Hierarchie, die zum SELECT hinzugefügt wird, multipliziert die Gesamtergebnisse mit der Anzahl der verfügbaren Werte in dieser Hierarchie. Um also zu ermitteln, wie viele Zeilen zu erwarten sind, kann man Folgendes ausführen:

SELECT (COUNT(c.[Country])*COUNT(c.[Gender])) AS totalrows
FROM [AdventureWorksDW2012Multidimensional-SE].[Adventure Works].Customer AS c

Zeilenlimit für Antworten

Da die Auswahl mehrerer Hierarchien die Gesamtzahl der Ergebniszeilen vervielfacht, kann die Anzahl der Antwortzeilen sehr schnell ansteigen, was zu Zeitüberschreitungen führen kann. Um zu versuchen, einen Einblick zu geben, welche Abfragen sehr teuer sind, ResponseRowLimit Die Verbindungseigenschaft wurde als Mechanismus hinzugefügt, um Benutzer zu einer idealen Konfiguration zu führen. Wenn sie festgelegt ist, wird berechnet, wie viele Zeilen zu erwarten sind, bevor eine Abfrage ausgeführt wird. Wenn die Anzahl der vorhergesagten Zeilen den Grenzwert überschreitet, wird ein Fehler ausgegeben, der angibt, wie viele Zeilen mit der Abfrage zu erwarten sind.

Es wird empfohlen, nur die erforderlichen Spalten auszuwählen oder ein WHERE-Kriterium anzuwenden. Beides kann die Anzahl der Antwortzeilen erheblich reduzieren, was sich enorm auf die Leistung auswirkt. Wenn Sie bereits mit dem Connector vertraut sind und wissen, welche Abfragen teuer sein können, ResponseRowLimit kann durch Setzen auf 0 deaktiviert werden.

Optimieren des Datenzugriffs

Optimieren des Datenzugriffs

Die folgenden Eigenschaften ermöglichen eine genauere Kontrolle des Datenzugriffs:

• UseMDX: Gibt an, ob MDX-Abfragen übermittelt werden. Standardmäßig ist dies „false“, was dazu führt, dass der Treiber nur SQL-92-kompatible Abfragen akzeptiert. Wenn Sie diese Eigenschaft auf „true“ setzen, werden alle Abfragen direkt an Microsoft Power BI XMLA weitergeleitet.

• ExtraProperties: Zusätzliche Eigenschaften, die zusammen mit einer MDX Abfrage übermittelt werden müssen. Nur sinnvoll, wenn UseMDX ist wahr.

• IncludeJoinColumns: Boolescher Wert, der angibt, ob zusätzliche Spalten hinzugefügt werden sollen, die zum Erstellen von ON-Bedingungen mit Verknüpfungen verwendet werden.

  Diese liefern keine Werte zurück - sie werden nur hinzugefügt, um Tools zu aktivieren, die sie benötigen, um beim Erstellen von Verknüpfungen automatisch Beziehungen zwischen Tabellen einzurichten.

• ResponseRowLimit: Legt eine berechnete Begrenzung der Zeilenanzahl fest, damit der Benutzer eine Auswahl treffen kann, bevor ein Fehler zurückgegeben wird.

  Da Abfragen in MDX übersetzt werden, kann die Auswahl nur weniger Spalten die Anzahl der erwarteten Ergebnisse exponentiell vervielfachen.

  Aus diesem Grund ResponseRowLimit ist verfügbar, um Hinweise darauf zu geben, welche Abfragetypen wahrscheinlich zu einem Timeout führen. Kann durch Setzen auf 0 deaktiviert werden.

Wichtige Hinweise

Konfigurationsdateien und ihre Pfade

• Alle Verweise auf das Hinzufügen von Konfigurationsdateien und deren Pfaden beziehen sich auf Dateien und Speicherorte auf dem Jitterbit-Agenten, auf dem der Connector installiert ist. Diese Pfade sind je nach Agent und Operationssystem entsprechend anzupassen. Wenn mehrere Agenten in einer Agentengruppe verwendet werden, werden auf jedem Agenten identische Dateien benötigt.

Erweiterte Funktionen

In diesem Abschnitt wird eine Auswahl erweiterter Funktionen des Microsoft Power BI XMLA Connectors beschrieben.

Benutzerdefinierte Ansichten

Der Connector ermöglicht Ihnen die Definition virtueller Tabellen, sogenannter benutzerdefinierter Ansichten, deren Inhalt durch eine vorkonfigurierte Abfrage bestimmt wird. Diese Ansichten sind nützlich, wenn Sie die an die Treiber gesendeten Abfragen nicht direkt steuern können. Siehe Benutzerdefinierte Ansichten für einen Überblick über das Erstellen und Konfigurieren benutzerdefinierter Ansichten.

SSL-Konfiguration

Verwenden Sie SSL-Konfiguration, um anzupassen, wie der Connector TLS/SSL-Zertifikatsverhandlungen handhabt. Sie können aus verschiedenen Zertifikatsformaten wählen; siehe SSLServerCert-Eigenschaft unter „Verbindungszeichenfolgenoptionen“ für weitere Informationen.

Proxy

So konfigurieren Sie den Connector mit privaten Agent-Proxy-Einstellungen, wählen Sie die Use Proxy Settings Kontrollkästchen auf dem Verbindungskonfigurationsbildschirm.

Abfrageverarbeitung

Der Connector verlagert möglichst viel der Verarbeitung der SELECT-Anweisung auf Microsoft Power BI XMLA und verarbeitet dann den Rest der Abfrage im Speicher (clientseitig).

Siehe Abfrageverarbeitung für weitere Informationen.

Benutzerdefinierte Ansichten

Mit dem Microsoft Power BI XMLA Connector können Sie eine virtuelle Tabelle definieren, deren Inhalt durch eine vorkonfigurierte Abfrage bestimmt wird. Diese werden als benutzerdefinierte Ansichten bezeichnet und sind in Situationen nützlich, in denen Sie die an den Treiber gesendete Abfrage nicht direkt steuern können, z. B. wenn Sie den Treiber von Jitterbit verwenden. Die benutzerdefinierten Ansichten können verwendet werden, um Prädikate zu definieren, die immer angewendet werden. Wenn Sie in der Abfrage an die Ansicht zusätzliche Prädikate angeben, werden diese mit der bereits als Teil der Ansicht definierten Abfrage kombiniert.

Es gibt zwei Möglichkeiten, benutzerdefinierte Ansichten zu erstellen:

• Erstellen Sie eine Konfigurationsdatei im JSON-Format, die die gewünschten Ansichten definiert.
• DDL-Anweisungen.

Definieren von Ansichten mithilfe einer Konfigurationsdatei

Benutzerdefinierte Ansichten werden in einer JSON-formatierten Konfigurationsdatei namens UserDefinedViews.json. Der Connector erkennt die in dieser Datei angegebenen Ansichten automatisch.

Sie können auch mehrere Ansichtsdefinitionen haben und diese mit steuern UserDefinedViews Verbindungseigenschaft. Wenn Sie diese Eigenschaft verwenden, werden vom Connector nur die angegebenen Ansichten angezeigt.

Diese Konfigurationsdatei für benutzerdefinierte Ansichten ist wie folgt formatiert:

• Jedes Stammelement definiert den Namen einer Ansicht.
• Jedes Stammelement enthält ein untergeordnetes Element namens query, das die benutzerdefinierte SQL- Abfrage für die Ansicht enthält.

Zum Beispiel:

{
    "MyView": {
        "query": "SELECT * FROM [AdventureWorksDW2012Multidimensional-SE].[Adventure Works].Customer WHERE MyColumn = 'value'"
    },
    "MyView2": {
        "query": "SELECT * FROM MyTable WHERE Id IN (1,2,3)"
    }
}

Verwenden Sie UserDefinedViews Verbindungseigenschaft, um den Speicherort Ihrer JSON-Konfigurationsdatei anzugeben. Beispiel:

"UserDefinedViews", "C:\Users\yourusername\Desktop\tmp\UserDefinedViews.json"

Definieren von Ansichten mit DDL-Anweisungen

Der Connector kann das Schema auch über DDL-Anweisungen wie CREATE LOCAL VIEW, ALTER LOCAL VIEW und DROP LOCAL VIEW erstellen und ändern.

Erstellen einer Ansicht

Um eine neue Ansicht mit DDL-Anweisungen zu erstellen, geben Sie den Ansichtsnamen und die Abfrage wie folgt an:

CREATE LOCAL VIEW`[MeinAnsichtsname] `AS SELECT * FROM Customers LIMIT 20;

Wenn keine JSON-Datei vorhanden ist, erstellt der obige Code eine. Die Ansicht wird dann in der JSON-Konfigurationsdatei erstellt und ist nun erkennbar. Der Speicherort der JSON-Datei wird durch angegeben UserDefinedViews Verbindungseigenschaft.

Ändern einer Ansicht

Um eine vorhandene Ansicht zu ändern, geben Sie den Namen der vorhandenen Ansicht zusammen mit der neuen Abfrage an, die Sie stattdessen verwenden möchten:

ALTER LOCAL VIEW`[MeinAnsichtsname] `AS SELECT * FROM Customers WHERE TimeModified > '3/1/2020';

Die Ansicht wird dann in der JSON-Konfigurationsdatei aktualisiert.

Löschen einer Ansicht

Um eine vorhandene Ansicht zu löschen, geben Sie den Namen eines vorhandenen Schema neben der neuen Abfrage an, die Sie stattdessen verwenden möchten.

DROP LOCAL VIEW [MyViewName]

Dadurch wird die Ansicht aus der JSON-Konfigurationsdatei entfernt. Sie kann nicht mehr abgefragt werden.

Schema für benutzerdefinierte Ansichten

Benutzerdefinierte Ansichten werden im angezeigt UserViews Schema standardmäßig. Dies geschieht, um zu vermeiden, dass der Name der Ansicht mit einer tatsächlichen Entität im Datenmodell kollidiert. Sie können den Namen des für UserViews verwendeten Schema ändern, indem Sie UserViewsSchemaName Eigentum.

Arbeiten mit benutzerdefinierten Ansichten

Beispielsweise eine SQL-Anweisung mit einer benutzerdefinierten Ansicht namens UserViews.RCustomers listet nur Kunden in Raleigh auf:

SELECT * FROM Customers WHERE City = 'Raleigh';

Ein Beispiel für eine Abfrage an den Treiber:

SELECT * FROM UserViews.RCustomers WHERE Status = 'Active';

Daraus ergibt sich die effektive Abfrage an die Quelle:

SELECT * FROM Customers WHERE City = 'Raleigh' AND Status = 'Active';

Dies ist ein sehr einfaches Beispiel für eine Abfrage an eine benutzerdefinierte Ansicht, die tatsächlich eine Kombination aus der Abfrage und der Ansichtsdefinition ist. Es ist möglich, diese Abfragen in viel komplexeren Mustern zusammenzustellen. Alle SQL-Operationen sind in beiden Abfragen zulässig und werden bei Bedarf kombiniert.

SSL-Konfiguration

Anpassen der SSL-Konfiguration

Standardmäßig versucht der Connector, SSL/TLS auszuhandeln, indem er das Zertifikat des Servers mit dem vertrauenswürdigen Zertifikatspeicher des Systems vergleicht.

Um ein anderes Zertifikat anzugeben, siehe SSLServerCert Eigenschaft für die verfügbaren Formate, um dies zu tun.

Datenmodell

Überblick

Dieser Abschnitt zeigt die verfügbaren API Objekte und bietet weitere Informationen zur Ausführung von SQL für Microsoft Power BI XMLA APIs.

Der Connector modelliert Dimensionen als Tabellen, Würfel als Schemata und eine Kombination aus Arbeitsbereich und DataSet-Katalog als Katalog. Der Connector unterstützt die gleichzeitige Verbindung mit mehreren Arbeitsbereichen, indem er eine durch Kommas getrennte Liste von Arbeitsbereichen im bereitstellt Workspace-Eigenschaft. Das Ergebnis ist, dass jeder Arbeitsbereich in den Katalogen als angezeigt wird WorkspaceName_CatalogName.

Hauptmerkmale

• Der Connector modelliert Microsoft Power BI XMLA Entitäten wie Dokumente, Ordner und Gruppen als relationale Ansichten, sodass Sie SQL schreiben können, um Microsoft Power BI XMLA Daten Abfrage.
• Gespeicherte Prozeduren ermöglichen Ihnen, Vorgänge für Microsoft Power BI XMLA auszuführen.
• Durch die Live-Konnektivität zu diesen Objekten werden alle Änderungen an Ihrem Microsoft Power BI XMLA Konto bei Verwendung des Connectors sofort berücksichtigt.

Measure-Attribute

Standardmäßig werden alle Maßattribute in einer „Maßnahmen“-Ansicht aufgelistet. Sie können jedoch Folgendes festlegen: SplitMeasures auf „true“, um die Maßansicht aufzuteilen; das Ergebnis ist, dass jedes Maßattribut in seiner jeweiligen Ansicht basierend auf dem Maßgruppenwert enthalten ist. Eine weitere Klassifizierung basierend auf „Maßverzeichnissen“ ist nicht enthalten.

Gespeicherte Prozeduren

Gespeicherte Prozeduren sind funktionsähnliche Schnittstellen zu Microsoft Power BI XMLA. Gespeicherte Prozeduren ermöglichen Ihnen die Ausführung von Vorgängen in Microsoft Power BI XMLA, einschließlich des Herunterladens von Dokumenten und Verschiebens von Umschlägen.

Gespeicherte Prozeduren

Gespeicherte Prozeduren sind funktionsähnliche Schnittstellen, die die Funktionalität des Connectors über einfache SELECT-Operationen mit Microsoft Power BI XMLA hinaus erweitern.

Gespeicherte Prozeduren akzeptieren eine Liste von Parametern, führen ihre beabsichtigte Funktion aus und geben dann alle relevanten Antwortdaten von Microsoft Power BI XMLA zurück, zusammen mit einem Hinweis, ob die Prozedur erfolgreich war oder fehlgeschlagen ist.

Gespeicherte Prozeduren für den Microsoft Power BI XMLA Connector

GetAdminConsentURL

Ruft die Administratoreinwilligungs URL ab, die von einem Administrator einer bestimmten Domäne separat geöffnet werden muss, um Zugriff auf Ihre Anwendung zu gewähren. Nur erforderlich, wenn benutzerdefinierte OAuth-Anmeldeinformationen verwendet werden.

Eingang

Ergebnissatzspalten

GetOAuthAccessToken

Ruft das Authentifizierungstoken ab, das zur Authentifizierung beim Dienst verwendet wird.

Eingang

Ergebnissatzspalten

GetOAuthAuthorizationUrl

Ruft eine Autorisierungs URL aus der Datenquelle ab. Die Autorisierungs URL kann verwendet werden, um einen Prüfer zu generieren, der zum Abrufen des OAuth-Tokens erforderlich ist.

Eingang

Ergebnissatzspalten

Aktualisieren Sie das OAuthAccessToken

Erhält einen aktualisierten OAuthAccessToken, wenn ein Token zum Aktualisieren übergeben wird.

Eingang

Ergebnissatzspalten

Systemtabellen

Sie können die in diesem Abschnitt beschriebenen Systemtabellen Abfrage, um auf Schema, Informationen zur Datenquellenfunktionalität und Statistiken zu Operation Charge.

Schematabellen

Die folgenden Tabellen geben Datenbankmetadaten für Microsoft Power BI XMLA zurück:

• sys_catalogs: Listet die verfügbaren Datenbanken auf.
• sys_schemas: Listet die verfügbaren Schemata auf.
• sys_tables: Listet die verfügbaren Tabellen und Ansichten auf.
• sys_tablecolumns: Beschreibt die Spalten der verfügbaren Tabellen und Ansichten.
• sys_procedures: Beschreibt die verfügbaren gespeicherten Prozeduren.
• sys_procedureparameters: Beschreibt Parameter gespeicherter Prozeduren.
• sys_keycolumns: Beschreibt die Primär- und Fremdschlüssel.
• sys_indexes: Beschreibt die verfügbaren Indizes.

Datenquellentabellen

Die folgenden Tabellen enthalten Informationen dazu, wie eine Verbindung zur Datenquelle hergestellt und diese Abfrage wird:

• sys_connection_props: Gibt Informationen zu den verfügbaren Verbindungseigenschaften zurück.
• sys_sqlinfo: Beschreibt die SELECT-Abfragen, die der Connector an die Datenquelle auslagern kann.

Abfrageinformationstabellen

Die folgende Tabelle gibt Abfrage für Datenänderungsabfragen zurück:

• Systemidentität: Gibt Informationen zu Charge oder einzelnen Updates zurück.

Sys_catalogs

Listet die verfügbaren Datenbanken auf.

Die folgende Abfrage ruft alle durch die Verbindungszeichenfolge ermittelten Datenbanken ab:

SELECT * FROM sys_catalogs

Spalten

Sys_schemas

Listet die verfügbaren Schemas auf.

Die folgende Abfrage ruft alle verfügbaren Schemata ab:

SELECT * FROM sys_schemas

Spalten

Sys_tables

Listet die verfügbaren Tabellen auf.

Die folgende Abfrage ruft die verfügbaren Tabellen und Ansichten ab:

SELECT * FROM sys_tables

Spalten

Sys_tablecolumns

Beschreibt die Spalten der verfügbaren Tabellen und Ansichten.

Die folgende Abfrage gibt die Spalten und Datentypen für die Tabelle [AdventureWorksDW2012Multidimensional-SE].[Adventure Works].Customer zurück:

SELECT ColumnName, DataTypeName FROM sys_tablecolumns WHERE TableName='Customer' AND CatalogName='AdventureWorksDW2012Multidimensional-SE' AND SchemaName='Adventure Works'

Spalten

Sys_procedures

Listet die verfügbaren gespeicherten Prozeduren auf.

Die folgende Abfrage ruft die verfügbaren gespeicherten Prozeduren ab:

SELECT * FROM sys_procedures

Spalten

Sys_procedureparameters

Beschreibt Parameter gespeicherter Prozeduren.

Die folgende Abfrage gibt Informationen zu allen Eingabeparametern für die gespeicherte Prozedur SelectEntries zurück:

SELECT * FROM sys_procedureparameters WHERE ProcedureName='SelectEntries' AND Direction=1 OR Direction=2

Spalten

Sys_keycolumns

Beschreibt die Primär- und Fremdschlüssel.

Die folgende Abfrage ruft den Primärschlüssel für die Tabelle [AdventureWorksDW2012Multidimensional-SE].[Adventure Works].Customer ab:

SELECT * FROM sys_keycolumns WHERE IsKey='True' AND TableName='Customer' AND CatalogName='AdventureWorksDW2012Multidimensional-SE' AND SchemaName='Adventure Works'

Spalten

Sys_foreignkeys

Beschreibt die Fremdschlüssel.

Die folgende Abfrage ruft alle Fremdschlüssel ab, die auf andere Tabellen verweisen:

SELECT * FROM sys_foreignkeys WHERE ForeignKeyType = 'FOREIGNKEY_TYPE_IMPORT'

Spalten

Sys_primarykeys

Beschreibt die Primärschlüssel.

Die folgende Abfrage ruft die Primärschlüssel aus allen Tabellen und Ansichten ab:

SELECT * FROM sys_primarykeys

Spalten

Sys_indexes

Beschreibt die verfügbaren Indizes. Durch das Filtern nach Indizes können Sie selektivere Abfragen mit schnelleren Abfrage schreiben.

Die folgende Abfrage ruft alle Indizes ab, die keine Primärschlüssel sind:

SELECT * FROM sys_indexes WHERE IsPrimary='false'

Spalten

Sys_connection_props

Gibt Informationen zu den verfügbaren Verbindungseigenschaften und den in der Verbindungszeichenfolge festgelegten Eigenschaften zurück.

Bei der Abfrage dieser Tabelle sollte die Konfigurationsverbindungszeichenfolge verwendet werden:

jdbc:cdata:powerbixmla:config:

Mit dieser Verbindungszeichenfolge können Sie diese Tabelle ohne eine gültige Verbindung Abfrage.

Die folgende Abfrage ruft alle Verbindungseigenschaften ab, die in der Verbindungszeichenfolge festgelegt oder über einen Standardwert gesetzt wurden:

SELECT * FROM sys_connection_props WHERE Value <> ''

Spalten

Sys_sqlinfo

Beschreibt die SELECT- Abfrage, die der Connector an die Datenquelle auslagern kann.

Entdecken der SELECT-Funktionen der Datenquelle

Nachfolgend sehen Sie einen Beispieldatensatz mit SQL-Funktionen. Einige Aspekte der SELECT-Funktionalität werden in einer durch Kommas getrennten Liste zurückgegeben, sofern sie unterstützt werden. Andernfalls enthält die Spalte NO.

Die folgende Abfrage ruft die Operatoren ab, die in der WHERE-Klausel verwendet werden können:

SELECT * FROM sys_sqlinfo WHERE Name = 'SUPPORTED_OPERATORS'

Beachten Sie, dass einzelne Tabellen unterschiedliche Einschränkungen oder Anforderungen an die WHERE-Klausel haben können; siehe Datenmodell Abschnitt für weitere Informationen.

Spalten

Systemidentität

Gibt Informationen zu versuchten Änderungen zurück.

Die folgende Abfrage ruft die IDs der geänderten Zeilen in einer Operation Charge:

SELECT * FROM sys_identity

Spalten

Systeminformationen

Beschreibt die verfügbaren Systeminformationen.

Die folgende Abfrage ruft alle Spalten ab:

SELECT * FROM sys_information

Spalten

Erweiterte Konfigurationseigenschaften

Die erweiterten Konfigurationseigenschaften sind die verschiedenen Optionen, die zum Herstellen einer Verbindung verwendet werden können. Dieser Abschnitt enthält eine vollständige Liste der Optionen, die Sie konfigurieren können. Klicken Sie auf die Links, um weitere Einzelheiten zu erfahren.

Authentifizierung

Azure-Authentifizierung

OAuth

JWT OAuth

SSL

Schema

Verschiedenes

Authentifizierung

Dieser Abschnitt enthält eine vollständige Liste der Authentifizierungseigenschaften, die Sie konfigurieren können.

AuthScheme

Der Authentifizierungstyp, der bei der Verbindung mit Microsoft Power BI XMLA verwendet werden soll.

Mögliche Werte

AzureAD, AzureServicePrincipal, AzureServicePrincipalCert

Datentyp

string

Standardwert

AzureAD

Hinweise

• Microsoft Entra ID: Legen Sie dies fest, um die Microsoft Entra ID OAuth-Authentifizierung durchzuführen.
• AzureServicePrincipal: Legen Sie dies fest, um die Authentifizierung als Microsoft Entra-Dienstprinzipal mit Clientanmeldeinformationen durchzuführen.
• AzureServicePrincipalCert: Legen Sie dies fest, um die Authentifizierung als Microsoft Entra-Dienstprinzipal mithilfe eines Zertifikats durchzuführen.

Azure Authentifizierung

Dieser Abschnitt enthält eine vollständige Liste der Azure-Authentifizierungseigenschaften, die Sie konfigurieren können.

AzureTenant

Der Microsoft Online-Mandant, der für den Datenzugriff verwendet wird. Wenn nicht angegeben, wird Ihr Standardmandant verwendet.

Datentyp

string

Standardwert

""

Hinweise

Der Microsoft Online-Mandant, der für den Datenzugriff verwendet wird. Beispiel: contoso.onmicrosoft.com. Alternativ können Sie die Mandanten-ID angeben. Dieser Wert ist die Verzeichnis-ID im Azure-Portal > Microsoft Entra ID > Eigenschaften.

Normalerweise ist es nicht notwendig, den Mandanten anzugeben. Dies kann von Microsoft automatisch ermittelt werden, wenn der OAuthGrantType verwendet wird auf CODE (Standard) eingestellt. Es kann jedoch fehlschlagen, wenn der Benutzer mehreren Mandanten angehört. Wenn beispielsweise ein Administrator der Domäne A einen Benutzer der Domäne B als Gastbenutzer einlädt, gehört der Benutzer nun beiden Mandanten an. Es ist eine gute Praxis, den Mandanten anzugeben, obwohl es im Allgemeinen funktionieren sollte, ohne ihn angeben zu müssen.

AzureTenant ist beim Festlegen von OAuthGrantType erforderlich zu CLIENT. Bei der Verwendung von Client-Anmeldeinformationen gibt es keinen Benutzerkontext. Die Anmeldeinformationen werden aus dem Kontext der App selbst übernommen. Microsoft erlaubt zwar weiterhin den Abruf von Client-Anmeldeinformationen ohne Angabe des Mandanten, aber die Wahrscheinlichkeit, den spezifischen Mandanten auszuwählen, mit dem Sie arbeiten möchten, ist viel geringer. Aus diesem Grund benötigen wir AzureTenant muss bei allen Client-Anmeldeinformationen-Verbindungen explizit angegeben werden, um sicherzustellen, dass Sie Anmeldeinformationen erhalten, die für die Domäne gelten, mit der Sie eine Verbindung herstellen möchten.

Azure-Umgebung

Die beim Herstellen einer Verbindung zu verwendende Azure-Umgebung.

Mögliche Werte

GLOBAL, CHINA, USGOVT, USGOVTDOD

Datentyp

string

Standardwert

GLOBAL

Hinweise

In den meisten Fällen funktioniert es, die Umfeld auf global eingestellt zu lassen. Wenn Ihr Azure-Konto jedoch einer anderen Umfeld hinzugefügt wurde, wird die AzureEnvironment kann verwendet werden, um die Umfeld anzugeben. Die verfügbaren Werte sind GLOBAL, CHINA, USGOVT, USGOVTDOD.

OAuth

Dieser Abschnitt enthält eine vollständige Liste der OAuth-Eigenschaften, die Sie konfigurieren können.

OAuth initiieren

Legen Sie diese Eigenschaft fest, um den Prozess zum Abrufen oder Aktualisieren des OAuth-Zugriffstokens beim Herstellen einer Verbindung zu starten.

Mögliche Werte

OFF, GETANDREFRESH, REFRESH

Datentyp

string

Standardwert

OFF

Hinweise

Folgende Optionen stehen zur Verfügung:

1. OFF: Gibt an, dass der OAuth-Flow vollständig vom Benutzer gehandhabt wird. Zur Authentifizierung ist ein OAuthAccessToken erforderlich.
2. GETANDREFRESH: Gibt an, dass der gesamte OAuth-Flow vom Connector verarbeitet wird. Wenn derzeit kein Token vorhanden ist, wird es durch eine entsprechende Aufforderung an den Benutzer über den Browser abgerufen. Wenn ein Token vorhanden ist, wird es bei Bedarf aktualisiert.
3. REFRESH: Gibt an, dass der Connector nur das Aktualisieren des OAuthAccessToken übernimmt. Der Benutzer wird vom Connector nie aufgefordert, sich über den Browser zu authentifizieren. Der Benutzer muss zunächst das Abrufen des OAuthAccessToken und des OAuthRefreshToken übernehmen.

OAuthClientId

Die Client-ID, die zugewiesen wird, wenn Sie Ihre Anwendung bei einem OAuth-Autorisierungsserver registrieren.

Datentyp

string

Standardwert

""

Hinweise

Im Rahmen der Registrierung einer OAuth-Anwendung erhalten Sie die OAuthClientId-Wert, manchmal auch Consumer-Schlüssel genannt, und ein Client-Geheimnis, das OAuthClientSecret.

OAuthClientSecret

Das Client-Geheimnis, das zugewiesen wird, wenn Sie Ihre Anwendung bei einem OAuth-Autorisierungsserver registrieren.

Datentyp

string

Standardwert

""

Hinweise

Im Rahmen der Registrierung einer OAuth-Anwendung erhalten Sie die OAuthClientId, auch Consumer-Schlüssel genannt. Sie erhalten außerdem ein Client-Geheimnis, auch Consumer-Geheimnis genannt. Legen Sie das Client-Geheimnis im OAuthClientSecret Eigentum.

OAuth-Zugriffstoken

Der Zugriffstoken für die Verbindung per OAuth.

Datentyp

string

Standardwert

""

Hinweise

Der OAuthAccessToken Eigenschaft wird für die Verbindung über OAuth verwendet. Die OAuthAccessToken wird im Rahmen des Authentifizierungsprozesses vom OAuth-Server abgerufen. Es hat ein serverabhängiges Timeout und kann zwischen Anfragen wiederverwendet werden.

Das Zugriffstoken wird anstelle Ihres Benutzernamens und Passworts verwendet. Das Zugriffstoken schützt Ihre Anmeldeinformationen, indem es sie auf dem Server speichert.

OAuthSettingsLocation

Der Speicherort der Einstellungsdatei, in der OAuth-Werte gespeichert werden, wenn InitiateOAuth auf GETANDREFRESH oder REFRESH eingestellt ist. Alternativ können Sie diesen Speicherort im Speicher halten, indem Sie einen Wert angeben, der mit beginnt 'memory://'.

Datentyp

string

Standardwert

%APPDATA%\PowerBIXMLA Data Provider\OAuthSettings.txt

Hinweise

Wenn InitiateOAuth ist auf gesetzt GETANDREFRESH oder REFRESH, der Connector speichert OAuth-Werte, damit der Benutzer die OAuth-Verbindungseigenschaften nicht manuell eingeben muss und die Anmeldeinformationen über Verbindungen oder Prozesse hinweg gemeinsam genutzt werden können.

Anstatt einen Dateipfad anzugeben, können Sie den Speicher verwenden. Speicherorte werden durch einen Wert angegeben, der mit beginnt 'memory://' gefolgt von einer eindeutigen Kennung für diesen Satz von Anmeldeinformationen (z. B. memory://user1). Die Kennung können Sie frei wählen, sie sollte jedoch für den Benutzer eindeutig sein. Im Gegensatz zur dateibasierten Speicherung, bei der die Anmeldeinformationen über Verbindungen hinweg bestehen bleiben, werden die Anmeldeinformationen bei der Speicherspeicherung in den statischen Speicher geladen und die Anmeldeinformationen werden für die Dauer des Prozesses unter Verwendung derselben Kennung zwischen Verbindungen geteilt. Um Anmeldeinformationen außerhalb des aktuellen Prozesses beizubehalten, müssen Sie die Anmeldeinformationen vor dem Schließen der Verbindung manuell speichern. Auf diese Weise können Sie sie in der Verbindung festlegen, wenn der Prozess erneut gestartet wird. Sie können OAuth-Eigenschaftswerte mit einer Abfrage an abrufen sys_connection_props Systemtabelle. Wenn mehrere Verbindungen mit denselben Anmeldeinformationen bestehen, werden die Eigenschaften aus der zuvor geschlossenen Verbindung gelesen.

Der Standardspeicherort ist „%APPDATA%\PowerBIXMLA Data Provider\OAuthSettings.txt“ mit %APPDATA% auf das Konfigurationsverzeichnis des Benutzers gesetzt. Die Standardwerte sind

• Windows: "register://%DSN"
• Unix: "%AppData%..."
• Mac: "%AppData%..."

wobei DSN der Name des aktuellen DSN ist, der in der offenen Verbindung verwendet wird.

Die folgende Tabelle listet den Wert von auf %APPDATA% nach Operationssystem:

OAuthVerifier

Der von der OAuth-Autorisierungs URL zurückgegebene Prüfcode.

Datentyp

string

Standardwert

""

Hinweise

Der von der OAuth-Autorisierungs URL zurückgegebene Prüfcode. Dieser kann auf Systemen verwendet werden, auf denen kein Browser gestartet werden kann, z. B. auf Headless-Systemen.

Authentifizierung auf Headless-Maschinen

Siehe, um die zu erhalten OAuthVerifier Wert.

OAuthSettingsLocation festlegen zusammen mit OAuthVerifier. Beim Verbinden tauscht der Connector die OAuthVerifier für die OAuth-Authentifizierungstoken und speichert sie verschlüsselt am angegebenen Speicherort. Setzen Sie InitiateOAuth zu GETANDREFRESH, um den Austausch zu automatisieren.

Sobald die OAuth-Einstellungsdatei generiert wurde, können Sie entfernen OAuthVerifier aus den Verbindungseigenschaften und verbinden Sie sich mit OAuthSettingsLocation festgelegt.

Um die OAuth-Tokenwerte automatisch zu aktualisieren, legen Sie OAuthSettingsLocation fest und setzen Sie zusätzlich InitiateOAuth zum AKTUALISIEREN.

OAuthRefreshToken

Das OAuth-Aktualisierungstoken für das entsprechende OAuth-Zugriffstoken.

Datentyp

string

Standardwert

""

Hinweise

Der OAuthRefreshToken Eigenschaft wird verwendet, um den OAuthAccessToken zu aktualisieren bei Verwendung der OAuth-Authentifizierung.

OAuthLäuftAbIn

Die Lebensdauer des OAuth AccessToken in Sekunden.

Datentyp

string

Standardwert

""

Hinweise

Mit OAuthTokenTimestamp kombinieren, um zu bestimmen, wann der AccessToken abläuft.

OAuthTokenTimestamp

Der Unix-Epochenzeitstempel in Millisekunden, als das aktuelle Zugriffstoken erstellt wurde.

Datentyp

string

Standardwert

""

Hinweise

Kombinieren Sie es mit OAuthExpiresIn, um zu bestimmen, wann das AccessToken abläuft.

JWT OAuth

Dieser Abschnitt enthält eine vollständige Liste der JWT OAuth-Eigenschaften, die Sie konfigurieren können.

OAuthJWTCert

Der JWT-Zertifikatspeicher.

Datentyp

string

Standardwert

""

Hinweise

Der Name des Zertifikatspeichers für das Client-Zertifikat.

Der OAuthJWTCertType Feld gibt den Typ des durch angegebenen Zertifikatspeichers an OAuthJWTCert. Wenn der Store kennwortgeschützt ist, geben Sie das Kennwort in OAuthJWTCertPassword an.

OAuthJWTCert wird in Verbindung mit OAuthJWTCertSubject verwendet

Feld, um Client-Zertifikate anzugeben. Wenn OAuthJWTCert hat einen Wert und OAuthJWTCertSubject gesetzt ist, wird eine Suche nach einem Zertifikat eingeleitet. Bitte beachten Sie das OAuthJWTCertSubject für weitere Einzelheiten.

Die Bezeichnungen der Zertifikatsspeicher sind plattformabhängig.

Nachfolgend sind die Bezeichnungen der gebräuchlichsten Benutzer- und Maschinen-Zertifikatspeicher in Windows aufgeführt:

In Java ist der Zertifikatsspeicher normalerweise eine Datei, die Zertifikate und optionale private Schlüssel enthält.

Wenn der Zertifikatsspeichertyp PFXFile ist, muss diese Eigenschaft auf den Namen der Datei gesetzt werden. Wenn der Typ PFXBlob ist, muss die Eigenschaft auf den binären Inhalt einer PFX-Datei (d. h. PKCS12-Zertifikatsspeicher) gesetzt werden.

OAuthJWTCertType

Der Typ des Schlüsselspeichers, der das JWT-Zertifikat enthält.

Mögliche Werte

USER, MACHINE, PFXFILE, PFXBLOB, JKSFILE, JKSBLOB, PEMKEY_FILE, PEMKEY_BLOB, PUBLIC_KEY_FILE, PUBLIC_KEY_BLOB, SSHPUBLIC_KEY_FILE, SSHPUBLIC_KEY_BLOB, P7BFILE, PPKFILE, XMLFILE, XMLBLOB

Datentyp

string

Standardwert

USER

Hinweise

Diese Eigenschaft kann einen der folgenden Werte annehmen:

OAuthJWTCertPasswort

Das Passwort für das OAuth JWT-Zertifikat.

Datentyp

string

Standardwert

""

Hinweise

Wenn der Zertifikatspeicher von einem Typ ist, der ein Passwort erfordert, wird diese Eigenschaft verwendet, um dieses Passwort anzugeben, damit der Zertifikatspeicher geöffnet werden kann.

OAuthJWTCertSubject

Der Betreff des OAuth JWT-Zertifikats.

Datentyp

string

Standardwert

*

Hinweise

Beim Laden eines Zertifikats wird der Betreff verwendet, um das Zertifikat im Speicher zu lokalisieren.

Wenn keine genaue Übereinstimmung gefunden wird, wird der Speicher nach Betreffs durchsucht, die den Wert der Eigenschaft enthalten.

Wenn immer noch keine Übereinstimmung gefunden wird, wird die Eigenschaft auf eine leere Zeichenfolge gesetzt und kein Zertifikat ausgewählt.

Der spezielle Wert „*“ wählt das erste Zertifikat im Zertifikatspeicher aus.

Der Betreff des Zertifikats ist eine durch Kommas getrennte Liste von Distinguished Name-Feldern und-Werten. Zum Beispiel „CN=www.server.com, OU=test, C=US, E=example@jbexample.com“. Allgemeine Felder und ihre Bedeutungen werden unten angezeigt.

Wenn ein Feldwert ein Komma enthält, muss es in Anführungszeichen gesetzt werden.

SSL

Dieser Abschnitt enthält eine vollständige Liste der SSL-Eigenschaften, die Sie konfigurieren können.

SSLClientCert

Der TLS/SSL-Client-Zertifikatspeicher für die SSL-Client-Authentifizierung (bidirektionales SSL).

Datentyp

string

Standardwert

""

Hinweise

Der Name des Zertifikatspeichers für das Client-Zertifikat.

Der SSLClientCertType Feld gibt den Typ des durch angegebenen Zertifikatspeichers an SSLClientCert. Wenn der Store kennwortgeschützt ist, geben Sie das Kennwort in SSLClientCertPassword an.

SSLClientCert wird in Verbindung mit SSLClientCertSubject verwendet, um Client-Zertifikate anzugeben. Wenn SSLClientCert hat einen Wert und SSLClientCertSubject gesetzt ist, wird eine Suche nach einem Zertifikat eingeleitet. Siehe SSLClientCertSubject für weitere Informationen.

Die Bezeichnungen der Zertifikatsspeicher sind plattformabhängig.

Nachfolgend sind die Bezeichnungen der gebräuchlichsten Benutzer- und Maschinen-Zertifikatspeicher in Windows aufgeführt:

In Java ist der Zertifikatsspeicher normalerweise eine Datei, die Zertifikate und optionale private Schlüssel enthält.

Wenn der Zertifikatsspeichertyp PFXFile ist, muss diese Eigenschaft auf den Namen der Datei gesetzt werden. Wenn der Typ PFXBlob ist, muss die Eigenschaft auf den binären Inhalt einer PFX-Datei gesetzt werden (z. B. PKCS12-Zertifikatsspeicher).

SSLClientCertType

Der Typ des Schlüsselspeichers, der das TLS/SSL-Clientzertifikat enthält.

Mögliche Werte

USER, MACHINE, PFXFILE, PFXBLOB, JKSFILE, JKSBLOB, PEMKEY_FILE, PEMKEY_BLOB, PUBLIC_KEY_FILE, PUBLIC_KEY_BLOB, SSHPUBLIC_KEY_FILE, SSHPUBLIC_KEY_BLOB, P7BFILE, PPKFILE, XMLFILE, XMLBLOB

Datentyp

string

Standardwert

USER

Hinweise

Diese Eigenschaft kann einen der folgenden Werte annehmen:

SSLClientCertPassword

Das Passwort für das TLS/SSL-Client-Zertifikat.

Datentyp

string

Standardwert

""

Hinweise

Wenn der Zertifikatspeicher von einem Typ ist, der ein Passwort erfordert, wird diese Eigenschaft verwendet, um dieses Passwort zum Öffnen des Zertifikatspeichers anzugeben.

SSLClientCertSubject

Der Betreff des TLS/SSL-Client-Zertifikats.

Datentyp

string

Standardwert

*

Hinweise

Beim Laden eines Zertifikats wird der Betreff verwendet, um das Zertifikat im Speicher zu lokalisieren.

Wenn keine genaue Übereinstimmung gefunden wird, wird der Speicher nach Betreffs durchsucht, die den Wert der Eigenschaft enthalten. Wenn immer noch keine Übereinstimmung gefunden wird, wird die Eigenschaft auf eine leere Zeichenfolge gesetzt und kein Zertifikat ausgewählt.

Der spezielle Wert „*“ wählt das erste Zertifikat im Zertifikatspeicher aus.

Der Betreff des Zertifikats ist eine durch Kommas getrennte Liste von Distinguished Name-Feldern und-Werten. Beispiel: „CN=www.server.com, OU=test, C=US, E=support@company.com“. Die allgemeinen Felder und ihre Bedeutungen werden unten angezeigt.

Wenn ein Feldwert ein Komma enthält, muss es in Anführungszeichen gesetzt werden.

SSLServerCert

Das vom Server zu akzeptierende Zertifikat bei einer Verbindung per TLS/SSL.

Datentyp

string

Standardwert

""

Hinweise

Bei Verwendung einer TLS/SSL-Verbindung kann diese Eigenschaft verwendet werden, um das vom Server zu akzeptierende TLS/SSL-Zertifikat anzugeben. Jedes andere Zertifikat, dem der Computer nicht vertraut, wird abgelehnt.

Diese Eigenschaft kann folgende Formen annehmen:

Wenn nicht angegeben, wird jedes vom Computer vertrauenswürdige Zertifikat akzeptiert.

Zertifikate werden vom Computer basierend auf dem Trust Store des Systems als vertrauenswürdig validiert. Der verwendete Trust Store ist der für das System angegebene Wert „javax.net.ssl.trustStore“. Wenn für diese Eigenschaft kein Wert angegeben ist, wird der Standard-Trust Store von Java verwendet (z. B. JAVA_HOME\lib\security\cacerts).

Verwenden Sie „*“, um anzugeben, dass alle Zertifikate akzeptiert werden. Beachten Sie, dass dies aus Sicherheitsgründen nicht empfohlen wird.

Schema

Dieser Abschnitt enthält eine vollständige Liste der Schema, die Sie konfigurieren können.

Standort

Ein Pfad zum Verzeichnis, das die Schema enthält, die Tabellen, Ansichten und gespeicherte Prozeduren definieren.

Datentyp

string

Standardwert

%APPDATA%\PowerBIXMLA Data Provider\Schema

Hinweise

Der Pfad zu einem Verzeichnis, das die Schema für den Connector enthält (.rsd-Dateien für Tabellen und Ansichten, .rsb-Dateien für gespeicherte Prozeduren). Der Ordnerspeicherort kann ein relativer Pfad vom Speicherort der ausführbaren Datei sein. Der Location Eigenschaft wird nur benötigt, wenn Sie Definitionen anpassen möchten (z. B. einen Spaltennamen ändern, eine Spalte ignorieren usw.) oder das Datenmodell mit neuen Tabellen, Ansichten oder gespeicherten Prozeduren erweitern möchten.

Wenn nichts angegeben wird, ist der Standardspeicherort „%APPDATA%\PowerBIXMLA Data Provider\Schema“ mit %APPDATA% wird auf das Konfigurationsverzeichnis des Benutzers eingestellt:

DurchsuchbareSchemas

Diese Eigenschaft beschränkt die gemeldeten Schemata auf eine Teilmenge der verfügbaren Schemata. Beispiel: BrowsableSchemas=SchemaA,SchemaB,SchemaC.

Datentyp

string

Standardwert

""

Hinweise

Das Auflisten der Schemata aus Datenbanken kann aufwändig sein. Die Bereitstellung einer Liste von Schemata in der Verbindungszeichenfolge verbessert die Leistung.

Tabellen

Diese Eigenschaft beschränkt die gemeldeten Tabellen auf eine Teilmenge der verfügbaren Tabellen. Beispiel: Tabellen=TabelleA,TabelleB,TabelleC.

Datentyp

string

Standardwert

""

Hinweise

Das Auflisten der Tabellen aus einigen Datenbanken kann teuer sein. Die Bereitstellung einer Liste von Tabellen in der Verbindungszeichenfolge verbessert die Leistung des Connectors.

Diese Eigenschaft kann auch als Alternative zum automatischen Auflisten von Ansichten verwendet werden, wenn Sie bereits wissen, mit welchen Sie arbeiten möchten, und es sonst zu viele wären.

Geben Sie die gewünschten Tabellen in einer durch Kommas getrennten Liste an. Jede Tabelle sollte ein gültiger SQL-Bezeichner sein, wobei alle Sonderzeichen mit eckigen Klammern, Anführungszeichen oder Backticks maskiert werden. Beispiel: Tables=TableA,[TableB/WithSlash],WithCatalog.WithSchema.`TableC With Space`.

Beachten Sie, dass Sie beim Herstellen einer Verbindung zu einer Datenquelle mit mehreren Schemata oder Katalogen den vollqualifizierten Namen der Tabelle in dieser Eigenschaft angeben müssen, wie im letzten Beispiel hier, um Mehrdeutigkeiten zwischen Tabellen zu vermeiden, die in mehreren Katalogen oder Schemata vorhanden sind.

Ansichten

Beschränkt die gemeldeten Ansichten auf eine Teilmenge der verfügbaren Tabellen. Beispiel: Ansichten=AnsichtA,AnsichtB,AnsichtC.

Datentyp

string

Standardwert

""

Hinweise

Das Auflisten der Ansichten aus einigen Datenbanken kann teuer sein. Die Bereitstellung einer Liste von Ansichten in der Verbindungszeichenfolge verbessert die Leistung des Connectors.

Diese Eigenschaft kann auch als Alternative zum automatischen Auflisten von Ansichten verwendet werden, wenn Sie bereits wissen, mit welchen Sie arbeiten möchten, und es sonst zu viele wären.

Geben Sie die gewünschten Ansichten in einer durch Kommas getrennten Liste an. Jede Ansicht sollte ein gültiger SQL-Bezeichner sein, wobei alle Sonderzeichen mit eckigen Klammern, Anführungszeichen oder Backticks maskiert werden. Beispiel: Views=ViewA,[ViewB/WithSlash],WithCatalog.WithSchema.`ViewC With Space`.

Beachten Sie, dass Sie beim Herstellen einer Verbindung zu einer Datenquelle mit mehreren Schemata oder Katalogen den vollqualifizierten Namen der Tabelle in dieser Eigenschaft angeben müssen, wie im letzten Beispiel hier, um Mehrdeutigkeiten zwischen Tabellen zu vermeiden, die in mehreren Katalogen oder Schemata vorhanden sind.

Katalog

Der zu verwendende Power BI-Arbeitsbereich und Datensatz.

Datentyp

string

Standardwert

""

Hinweise

Der Connector kombiniert jeden Power BI-Arbeitsbereich und jedes Dataset zu einem einzigen Katalognamen. Wenn Sie beispielsweise einen Arbeitsbereich mit dem Namen haben,MyWorkspace und ein Datensatz namens MyDataset dann lautet sein Katalogname MyWorkspace_MyDataset.

Standardmäßig meldet der Connector alle Arbeitsbereiche und Datensätze als separate Kataloge. Eine Abfrage kann den Katalog entweder direkt verwenden oder ihn weglassen, damit der Connector nach einer passenden Tabelle sucht.

-- Use this specific catalog
SELECT ... FROM MyWorkspace_MyDataset.Model.MyDimension

-- Search for a catalog containing this table
SELECT ... FROM Model.MyDimension

Wenn Sie jedoch UseMDX aktiviert haben,, möchten Sie diesen Wert möglicherweise so festlegen, dass MDX-Abfragen an den richtigen Arbeitsbereich und Datensatz gesendet werden. Der Connector kann den Arbeitsbereich und den Datensatz nicht automatisch aus einer MDX- Abfrage ermitteln.

IncludeJoinColumns

Setzen Sie dies auf „true“, um zusätzliche Verknüpfungsspalten in jede Tabelle einzuschließen.

Datentyp

bool

Standardwert

false

Hinweise

Einige Tools erfordern möglicherweise eine ON-Bedingung (oder generieren sie automatisch) basierend auf Fremdschlüsselreferenzen. Durch das Setzen von IncludeJoinColumns auf true setzen, jede Tabelle enthält einen Fremdschlüsselverweis auf die anderen Tabellen. Diese Spalten geben keine Daten zurück und sind für nichts anderes nützlich, als sie als ON-Bedingungen zu übergeben, auf deren Grundlage Verknüpfungen ausgeführt werden.

In Microsoft Power BI XMLA sind die Dimensionen und Kennzahlen, aus denen die Tabellen bestehen, bereits auf natürliche Weise verknüpft. Es wird kein Kontext bereitgestellt, in dem sie verknüpft werden können. Daher unterstützt der Microsoft Power BI XMLA Connector das Verknüpfen ohne Angabe einer ON-Bedingung, sodass die Angabe optional ist.

Verschiedenes

Dieser Abschnitt enthält eine vollständige Liste verschiedener Eigenschaften, die Sie konfigurieren können.

BenutzerdefinierteHeader

Andere Header nach Wahl des Benutzers (optional).

Datentyp

string

Standardwert

""

Hinweise

Diese Eigenschaft kann auf eine Zeichenfolge mit Headern festgelegt werden, die an die aus anderen Eigenschaften (wie „ContentType“, „From“ usw.) erstellten HTTP-Anforderungsheader angehängt werden.

Die Header müssen das Format „Header:Wert“ aufweisen, wie in den HTTP-Spezifikationen beschrieben. Headerzeilen sollten durch die Zeichen für Wagenrücklauf und Zeilenvorschub (CRLF) getrennt sein.

Verwenden Sie diese Eigenschaft mit Vorsicht. Wenn diese Eigenschaft ungültige Header enthält, können HTTP-Anforderungen fehlschlagen.

Diese Eigenschaft ist nützlich, um die Funktionalität des Connectors für die Integration mit spezialisierten oder nicht standardmäßigen APIs zu optimieren.

ExposeMemberKeys

Bestimmt, ob jede Ebene in eine Kennzahl umgewandelt werden soll, sodass Berechnungen für die Kennzahl durchgeführt werden können.

Datentyp

bool

Standardwert

false

Hinweise

Standardmäßig sind alle Ebenen vom Typ String. Durch Aktivieren dieser Option kann eine Ebene bis zu ihrer Schlüsseleigenschaft aufgelöst werden, wodurch eine Kennzahl erstellt wird, die den DBType-Datentyp der Ebene hat. Anschließend können Berechnungen für die Kennzahl durchgeführt werden.

AusdruckInBeschreibung

Setzen Sie dies auf „true“, um Ausdrücke als Teil der Beschreibung in Maßspalten zu melden.

Datentyp

bool

Standardwert

false

Hinweise

Der Connector meldet die Bemerkungen für mehrere Entitätstypen (Dimensionen, Kennzahlen, Kennzahlengruppen und Hierarchien) als Tabellen- und Spaltenbeschreibungen. Standardmäßig schließt der Connector nur die Bemerkungen in die Kennzahlenspaltenbeschreibungen ein.

Wenn diese Option aktiviert ist, wird der Kennzahlenausdruck zusammen mit den Bemerkungen in die Kennzahlenspaltenbeschreibung aufgenommen. Die Beschreibungen anderer Entitätstypen sind davon nicht betroffen.

Zusätzliche Eigenschaften

Zusätzliche Eigenschaften, die bei jeder MDX-Anforderung an Microsoft Power BI XMLA übermittelt werden sollen.

Datentyp

string

Standardwert

""

Hinweise

Beim Einstellen von UseMDX auf true gesetzt ist, können Eigenschaften mithilfe dieser Verbindungseigenschaft angegeben werden, um zusätzliche Werte in der PropertiesList der XMLA-Anforderung auszufüllen. Verwenden Sie Name=Wert-Paare, die durch ein Semikolon getrennt sind, um die Eigenschaften zu übermitteln. Beispiel: Catalog=MyCatalog;Cube=MyCube;.

Eine Liste der Eigenschaften kann durch Ausführen von SELECT * FROM $System.DISCOVER_PROPERTIES gefunden werden.

MaxRows

Begrenzt die Anzahl der zurückgegebenen Zeilen, wenn in der Abfrage keine Aggregation oder GROUP BY verwendet wird. Dies hat Vorrang vor LIMIT-Klauseln.

Datentyp

int

Standardwert

-1

Hinweise

Begrenzt die Anzahl der zurückgegebenen Zeilen, wenn in der Abfrage keine Aggregation oder GROUP BY verwendet wird. Dies hat Vorrang vor LIMIT-Klauseln.

Andere

Diese versteckten Eigenschaften werden nur in bestimmten Anwendungsfällen verwendet.

Datentyp

string

Standardwert

""

Hinweise

Die unten aufgeführten Eigenschaften sind für bestimmte Anwendungsfälle verfügbar. Für normale Anwendungsfälle und Funktionen von Treiber sollten diese Eigenschaften nicht erforderlich sein.

Geben Sie mehrere Eigenschaften in einer durch Semikolon getrennten Liste an.

Integration und Formatierung

Antwortzeilenlimit

Die Anzahl der zulässigen Antwortzeilen, bevor ein Fehler ausgelöst wird. Auf 0 setzen, um keine Begrenzung zu erhalten.

Datentyp

int

Standardwert

100000

Hinweise

Wenn Sie viele Spalten auswählen, treten bei der Übersetzung in ein für Microsoft Power BI XMLA akzeptables Format eine Reihe von Crossjoins im Hintergrund auf. Dies ist nicht intuitiv, wenn Sie mit MDX nicht vertraut sind. Es kann leicht zu sehr großen Antworten führen, bei denen es zu einer Zeitüberschreitung kommt. Das ResponseRowLimit soll den Benutzer auf sehr teure Anfragen aufmerksam machen.

VersteckteElemente anzeigen

Setzen Sie dies auf „true“, um ausgeblendete Dimensionen, Maße und Ebenen einzuschließen.

Datentyp

bool

Standardwert

false

Hinweise

Standardmäßig meldet der Connector keine Entitäten, die Microsoft Power BI XMLA als ausgeblendet markiert. Durch Aktivieren dieser Option können Sie sie Abfrage.

Maße teilen

Setzen Sie dies auf „true“, um die Maßtabelle in einzelne Tabellen aufzuteilen.

Datentyp

bool

Standardwert

false

Hinweise

Alle Kennzahlen sind derzeit in einer einzigen Tabelle „Kennzahlen“ gruppiert. Setzen Sie dies auf „true“, um die Kennzahlentabelle in einzelne Tabellen aufzuteilen (wenn eine Tabelle nur Kennzahlen enthält) und Kennzahlen in die jeweiligen Dimensionstabellen aufzunehmen.

Maße teilenEin

Verwenden Sie diese Eigenschaft in Verbindung mit SplitMeasures, um die Priorität festzulegen, nach der Maßnahmen in Tabellen organisiert werden sollen.

Datentyp

string

Standardwert

MeasureGroup

Hinweise

Diese Eigenschaft steuert die Reihenfolge, in der Maßspeicherattribute verwendet werden, um sie in Untertabellen zu sortieren, wenn SplitMeasures ist wahr. Geben Sie eine durch Kommas getrennte Liste der Speichermethoden in der Reihenfolge an, in der sie priorisiert werden sollen. Verfügbare Werte sind:

• MeasureGroup
• DisplayFolder

Split-Measure-Tabellen werden nach dem Attribut benannt, das in der Liste zuerst erscheint, oder in eine allgemeine „Measures“-Tabelle sortiert, wenn keiner der Werte in der Liste für die Maßnahme ausgefüllt ist.

Zeitüberschreitung

Der Wert in Sekunden, bis der Timeout-Fehler auftritt und der Operation abgebrochen wird.

Datentyp

int

Standardwert

60

Hinweise

Wenn Timeout = 0, Operationen werden nicht abgebrochen. Die Operationen werden ausgeführt, bis sie erfolgreich abgeschlossen sind oder bis ein Fehler auftritt.

Wenn Timeout abläuft und der Operation noch nicht abgeschlossen ist, löst der Connector eine Ausnahme aus.

Verwenden Sie MDX

Setzen Sie dies auf „True“, um MDX-Abfragen unverändert an Microsoft Power BI XMLA zu übergeben.

Datentyp

bool

Standardwert

false

Hinweise

Sie können SQL-92-SELECT-Abfragen an die vom Connector modellierten Ansichten ausführen. Legen Sie diese Eigenschaft fest, um stattdessen MDX-Abfragen direkt an Microsoft Power BI XMLA auszuführen.

BenutzerdefinierteAnsichten

Ein Dateipfad, der auf die JSON-Konfigurationsdatei verweist, die Ihre benutzerdefinierten Ansichten enthält.

Datentyp

string

Standardwert

""

Hinweise

Benutzerdefinierte Ansichten werden in einer JSON-formatierten Konfigurationsdatei namens UserDefinedViews.json. Der Connector erkennt die in dieser Datei angegebenen Ansichten automatisch.

Sie können auch mehrere Ansichtsdefinitionen haben und diese mit steuern UserDefinedViews Verbindungseigenschaft. Wenn Sie diese Eigenschaft verwenden, werden vom Connector nur die angegebenen Ansichten angezeigt.

Diese Konfigurationsdatei für benutzerdefinierte Ansichten ist wie folgt formatiert:

• Jedes Stammelement definiert den Namen einer Ansicht.
• Jedes Stammelement enthält ein untergeordnetes Element namens query, das die benutzerdefinierte SQL- Abfrage für die Ansicht enthält.

Zum Beispiel:

{
    "MyView": {
        "query": "SELECT * FROM [AdventureWorksDW2012Multidimensional-SE].[Adventure Works].Customer WHERE MyColumn = 'value'"
    },
    "MyView2": {
        "query": "SELECT * FROM MyTable WHERE Id IN (1,2,3)"
    }
}

Verwenden Sie die UserDefinedViews Verbindungseigenschaft zur Angabe des Speicherorts Ihrer JSON-Konfigurationsdatei. Beispiel:

"UserDefinedViews", C:\Users\yourusername\Desktop\tmp\UserDefinedViews.json

Beachten Sie, dass der angegebene Pfad nicht in Anführungszeichen steht.

Arbeitsbereich

Die durch Kommas getrennten PowerBI-Arbeitsbereiche, mit denen eine Verbindung hergestellt werden soll.

Datentyp

string

Standardwert

""

Hinweise

Die durch Kommas getrennten PowerBI-Arbeitsbereiche, mit denen eine Verbindung hergestellt werden soll. Wenn nicht angegeben, sind Objekte aus allen Arbeitsbereichen verfügbar. Dies führt dazu, dass zusätzliche Anfragen ausgeführt werden, um Objekte aus allen Arbeitsbereichen aufzulisten.