Zum Hauptinhalt springen
Gib den Personen, die Langdock nutzen, Viewer auf dem Workspace und Build auf dem semantischen Modell. Eine Power BI Pro-Lizenz reicht. Sie brauchen weder Fabric-Kapazität noch XMLA noch eine Kapazitätsrolle.
Langdock nutzt delegierte Microsoft-Berechtigungen. Jede Anfrage läuft als der angemeldete User. Langdock kann also kein Modell lesen, auf das der User nicht ohnehin zugreifen kann, und eine Row-Level Security (RLS) im Modell filtert für genau diese Person. Ausnahme: Ein geteilter Agent oder Workflow nutzt eine vorausgewählte Verbindung. Siehe Geteilte Agenten und Workflows. Ein Dienstkonto brauchst du nicht. Die OAuth-Scopes jeder Aktion findest du unter Power BI-Scopes.

​
Empfohlenes Setup

Leg den fachlichen Kontext ins semantische Modell selbst. Dann kann jeder Langdock-User mit Zugriff ohne zusätzliches Setup Fragen in natürlicher Sprache stellen, und der Kontext bleibt an der einen Stelle, die euer Datenteam ohnehin pflegt.
  • Gib Tabellen, Spalten und Measures klare fachliche Namen, zum Beispiel Nettoumsatz statt NR_AMT. Namen zählen am meisten, weil Langdock sie bei jeder Abfrage der Struktur sieht.
  • Gib jedem wichtigen Measure eine einzeilige Beschreibung, zum Beispiel „Umsatz aus gewonnenen Opportunities, ohne Retouren“.
  • Ordne Measures in Anzeigeordnern, pflege Synonyme im linguistischen Schema und blende technische Spalten wie Schlüssel und Sortierhilfen aus.
Brauchen User darüber hinaus Hinweise, die nicht ins Modell passen, etwa Geschäftsregeln, welches Measure Vorrang hat oder wie Antworten aussehen sollen, schreib einen Skill mit angehängter Power BI-Integration und teile ihn mit ihnen. Ein Skill wirkt in normalen Chats, User müssen also keinen separaten Agenten suchen. Er nutzt immer die eigene Power BI-Verbindung jedes Users, also gelten dessen eigene Berechtigungen. Sprich Measures im Skill über ihren Namen an, nicht über ihre Berechnung.

​
Viewer mit Build oder nur Viewer

Nur mit Viewer und Build beantwortet Langdock Fragen mit Daten. Microsoft verlangt Build für die Abfrage-API, die jede Datenaktion nutzt. Ohne Build hilft Langdock dabei, den richtigen Bericht zu finden, liefert aber keine Daten. Build zurückzuhalten macht den Zugriff nicht sicherer. Sollen verschiedene User verschiedene Zeilen sehen, nutze Row-Level Security.

​
Was jede Person braucht

Fragen stellen braucht nur Lesezugriff. Consumer brauchen also keine Contributor-Rolle oder höher. Builder brauchen Schreibzugriff nur, um Measure-Formeln zu sehen, denn Formeln brauchen XMLA und Schreibberechtigung auf dem Modell. Deshalb bekommen sie Schreibzugriff auf einer eigenen Kopie. Mit Contributor und höher kann man das geteilte Modell ändern oder löschen, und nutzt das Modell RLS, umgeht man sie damit auch.

​
Lizenzen

Abfragen funktionieren auf jeder Stufe gleich. Die Stufen unterscheiden sich darin, wer die Inhalte nutzen darf und ob es den XMLA-Endpunkt gibt. Microsoft 365 E5 und Office 365 E5 enthalten Power BI Pro. Mehr dazu bei Microsoft unter Fabric licenses.

​
Workspace-Rollen und Row-Level Security

Lass Consumer Viewer bleiben. Workspace Admin, Member und Contributor haben Schreibzugriff auf jedes Modell im Workspace. Vergib Rollen, Build und gegebenenfalls RLS-Rollen an Microsoft Entra-Sicherheitsgruppen statt an einzelne User. So folgt der Zugriff deiner bestehenden Organisationsstruktur. Ohne RLS sieht jeder Viewer mit Build alle Daten im Modell. Nutzt ein Modell RLS, beachte Folgendes:
  • Langdock liefert nur die Zeilen, die die Sicherheitsrolle des Users erlaubt.
  • Schreibzugriff umgeht RLS. Eine workspaceweite Contributor-Vergabe schaltet RLS also für alle ab, die sie haben.
  • Nimm dieselben Entra-Gruppen, die Viewer und Build bekommen, auch in deine Sicherheitsrollen auf, damit jeder Consumer in einer Rolle landet. User außerhalb jeder Rolle bekommen einen Fehler, keine leeren Ergebnisse.

​
Was XMLA erfordert

Die meisten Aktionen nutzen die Power BI REST APIs und funktionieren auf jeder Stufe. Einige brauchen den XMLA-Endpunkt. Dafür brauchst du Fabric-Kapazität, Power BI Premium-Kapazität oder Premium Per User sowie die XMLA-Einstellungen.

​
Live-Verbindungen zu Analysis Services

Semantische Modelle, die Live-Verbindungen zu Azure Analysis Services oder SQL Server Analysis Services sind, kann Langdock auf keiner Stufe abfragen. Microsoft unterstützt für diese Modelle weder die Abfrage-API noch den XMLA-Endpunkt, und Fabric-Kapazität ändert daran nichts. Wenn du die Daten in Langdock nutzen willst, hoste das Modell stattdessen in Power BI oder Fabric. Microsoft nennt diese Grenzen unter Execute Queries und Unsupported semantic models.

​
Geteilte Agenten und Workflows

Damit jeder User in einem geteilten Agenten oder Workflow seinen eigenen Power BI-Zugriff behält, wähle bei den Power BI-Aktionen Ihre eigenen Zugangsdaten. Jeder User verbindet sein eigenes Microsoft-Konto, und seine eigenen Berechtigungen gelten. Mit Vorausgewählte Verbindung läuft jede Aktion als Owner dieser Verbindung. Nutze das nur, wenn alle Aufrufenden dieselben Daten sehen sollen. Siehe Verbindungen.

​
Admin-Checkliste

Prüfe jeden Punkt an der genannten Stelle. Der erwartete Zustand steht nach dem Doppelpunkt.
  • Fabric-Verwaltungsportal → Mandanteneinstellungen → Integrationseinstellungen → REST-API des semantischen Modells zum Ausführen von Abfragen: aktiviert für die gesamte Organisation oder für eine Sicherheitsgruppe, die alle Langdock-User enthält.
  • Jeder Workspace → Zugriff verwalten: Die Consumer-Gruppe hat die Rolle Anzeige (Viewer) und keine höhere Rolle.
  • Jedes semantische Modell, das User in Langdock abfragen → Berechtigungen verwalten → Direkter Zugriff: Bei der Consumer-Gruppe steht Build, ohne Schreib- oder Weiterfreigabe-Berechtigung.
  • Microsoft 365 Admin Center → Abrechnung → Lizenzen: Jeder Consumer hat Power BI Pro, Power BI Premium Per User, Microsoft 365 E5 oder Office 365 E5. Builder, die XMLA in einem Premium-Per-User-Workspace nutzen, haben Premium Per User.
  • Nur wenn ein Modell RLS nutzt: semantisches Modell → Weitere Optionen → Sicherheit: Jede Consumer-Gruppe ist Mitglied mindestens einer Rolle.
  • Nur wenn Builder XMLA brauchen: Fabric-Verwaltungsportal → Kapazitätseinstellungen → die Kapazität mit den Builder-Modellen → Power BI Workloads → XMLA-Endpunkt: Schreibgeschützt oder Lesen und schreiben.
  • Nur wenn du Agenten oder Workflows mit Power BI teilst: in Langdock, jeder davon → jede Power BI-Aktion: Ihre eigenen Zugangsdaten ist ausgewählt.
  • Ein typischer Consumer besteht Einrichtung prüfen.