Verstehen Sie Abhängigkeitsbindungen bei der Cross-Workspace-Bereitstellung

Wenn Sie Fabric-Elemente arbeitsbereichsübergreifend bereitstellen (beispielsweise von der Entwicklung über den Test bis zur Produktion), können Abhängigkeiten zwischen den Elementen unterbrochen werden. Einige Elemente speichern Referenzen auf ihre Abhängigkeiten als Objekt-IDs (workspace-spezifische GUIDs), während andere logische IDs verwenden (cross-workspace portable Identifiers, die in der .platform Datei gespeichert sind).

Elemente, die logische IDs in ihren Definitionen verwenden, binden korrekt an das entsprechende Element im Ziel-Arbeitsbereich. Objekte, die Objekt-IDs verwenden, bleiben auf den Quellarbeitsbereich verwiesen, was die Bereitstellung unterbricht.

Dieser Artikel kartiert, welche Fabric-Item-Typen Abhängigkeitsbindungen über logische IDs unterstützen, wenn du Git-Integration nutzt, und welche nicht. Um mehr über logische IDs und die Darstellung von Elementen in der Quellcode-Kontrolle zu erfahren, siehe Logical ID in Fabric.

Zentrale Konzepte

  • Logische ID: Eine automatisch generierte arbeitsbereichsübergreifende Kennung in der .platformDatei. Artikel mit derselben logischen ID werden in Arbeitsbereichen als dasselbe Element behandelt.
  • Objekt-ID: Eine arbeitsbereichsspezifische GUID, die eine bestimmte Instanz identifiziert. Objekt-IDs überleben eine arbeitsübergreifende Bereitstellung ohne manuelle Intervention oder Parametrisierung nicht.
  • Dependency Binding (Git): Wenn Sie einen Git-Branch mit einem neuen Arbeitsbereich synchronisieren, löst Fabric Abhängigkeitsreferenzen mithilfe logischer IDs auf und zeigt automatisch auf das richtige Element im Ziel-Arbeitsbereich.
  • Nach Namen oder URI: Einige Elemente beziehen sich auf Abhängigkeiten anhand von Anzeigenamen oder URI statt nach ID. Diese Referenzen können je nach Namenskonventionen in Arbeitsbereichen korrekt gelöst werden oder auch nicht.

Wie Abhängigkeitsbindung funktioniert

Innerhalb eines Arbeitsbereichs verweisen Elemente auf ihre Abhängigkeiten mithilfe von Objekt-IDs. Wenn Fabric ein Item nach Git exportiert, ersetzt es einige dieser Objekt-IDs durch logische IDs aus der .platform Datei. Wenn du den Git-Branch mit einem anderen Arbeitsbereich synchronisierst, löst Fabric diese logischen IDs wieder auf die korrekten Objekt-IDs im Zielarbeitsbereich auf. Das ist es, was Abhängigkeitsbindungen funktionieren lässt.

Allerdings werden beim Export nicht alle Abhängigkeitsreferenzen durch logische IDs ersetzt. Objekte, die Objekt-IDs in ihrer Git-Darstellung behalten, zeigen nach der Synchronisierung weiterhin auf den ursprünglichen Arbeitsbereich, und du musst sie manuell oder durch Parameterisierung aktualisieren.

Important

Abhängigkeitsbindung gilt nur für Referenzen zwischen Fabric-Elementen innerhalb von demselben Arbeitsbereich. Wenn ein Item auf ein Fabric-Item in einem anderen Arbeitsbereich referenziert, verwendet diese Referenz eine Objekt-ID und bindet nicht automatisch. Referenzen auf Verbindungen (Datenquellenverbindungen, Gateways) binden sich ebenfalls nicht automatisch. Verwenden Sie Variable Libraries mit umgebungsspezifischen Wertesätzen, um Verbindungsreferenzen umgebungsübergreifend zu verwalten.

Abhängigkeitsbindungskompatibilität

Die folgenden Tabellen zeigen, ob die Abhängigkeiten jedes Fabric-Artikeltyps korrekt binden, wenn Sie arbeitsbereichsübergreifend deployen. Derzeit behandelt dieser Artikel das Verhalten der Git-Integration . Da die Bindung dadurch bestimmt wird, wie jedes Element seine Abhängigkeitsreferenzen in seiner Definition speichert, gilt dasselbe Verhalten für andere Deployment-Mechanismen, die diese Definitionen wiederverwenden, wie Deployment-Pipelines und die Import-(Bulk-)APIs.

Diese Tabellen gehen davon aus, dass die Abhängigkeit ein weiteres Element im selben Arbeitsbereich wie das Quellelement ist. Eine Referenz auf ein Element in einem anderen Arbeitsbereich wird niemals automatisch gebunden. Sie bleibt unabhängig vom in der Tabelle angezeigten Wert an die Quellobjekt-ID gepinnt.

Die Spalte Auto-bind in Git zeigt Folgendes an:

  • Ja: Die Item-Definition in Git speichert die Abhängigkeitsreferenz als logische ID. Wenn du den Branch in einen neuen Arbeitsbereich synchronisierst, wird die Referenz automatisch mit dem passenden Element in diesem Arbeitsbereich verknüpft.
  • Nein: Die Item-Definition in Git speichert die Abhängigkeitsreferenz als Objekt-ID (workspace-spezifisches GUID). Die Referenz zeigt nach der Synchronisation weiterhin auf den Quellarbeitsbereich. Du musst es manuell aktualisieren oder parametrisieren für die arbeitsbereichsübergreifende Bereitstellung.
  • Partial: Das Element löst die Abhängigkeit durch Namen oder URI, was funktionieren kann, wenn die Benennung über Arbeitsbereiche hinweg konsistent ist.

Notebooks

Abhängigkeit Auto-bind in Git Hinweise
Lakehouse Ja Erfordert die Aktivierung von "Lakehouse Auto-Binding in Git" in den Notizbucheinstellungen. Wenn aktiviert, wird die Objekt-ID durch eine logische ID in notebook-settings.jsonersetzt. Diese Einstellung ist standardmäßig deaktiviert. Weitere Informationen finden Sie unter Lakehouse auto-binding in Git.
Environment Ja
Gespiegelte Datenbank No

Note

Die Bindung von Notizbuch zu Lakehouse ist standardmäßig nicht aktiviert. Du musst in den Einstellungen jedes Notizbuchs die Einstellung "Lakehouse Auto-Binding in Git" aktivieren. Weitere Informationen finden Sie unter Notebook-Quellcodeverwaltung und -bereitstellung.

Berichte

Abhängigkeit Auto-bind in Git Hinweise
Semantisches Modell (aus dem Power BI-Bericht) Partial Der Bericht referenziert das Modell durch eine relative byPath Referenz in definition.pbir, nicht über eine explizite logische ID. Sie wird korrekt aufgelöst, wenn das Modell am selben relativen Speicherort im Zielarbeitsbereich bereitgestellt wird, wird jedoch nicht über eine logische ID gebunden. Weitere Informationen finden Sie im Power BI Desktop Projektreportordner.
Semantisches Modell (aus paginiertem Bericht) No Der Verbindungszeichenfolge des Berichts referenziert das semantische Modell über eine arbeitsraumspezifische ID, die bei der Bereitstellung nicht neu geschrieben wird, sodass er auf das Quellmodell zeigt. Du musst diese Referenz für die arbeitsbereichsübergreifende Bereitstellung aktualisieren. (Berichte, die im Report Builder verfasst wurden und das Modell mit Namen referenzieren, können stattdessen nach Display-Name, also Partial, aufgelöst werden.)

Pipeline

Abhängigkeit Auto-bind in Git Hinweise
Pipeline Ja
Notebook Ja
Datenfluss Gen2 Ja
SQL Database Ja
Spark-Auftragsdefinition No Die SparkJobDefinition-Aktivität verweist über die Objekt-ID und nicht über die logische ID auf die Spark-Job-Definition, sodass sie auch nach der Bereitstellung weiterhin auf das Quellelement verweist. Du musst diesen Wert für die arbeitsbereichsübergreifende Bereitstellung parametrisieren.
Lakehouse Ja
Semantikmodell No Die PBISemanticModelRefresh-Aktivität referenziert das semantische Modell anhand von der Item-ID, nicht der logischen ID. Du musst diesen Wert für die arbeitsbereichsübergreifende Bereitstellung parametrisieren.
Lagerhalle No Das Data Warehouse artifactId wird über die logische ID aufgelöst und neu gebunden, aber linkedService speichert auch das SQL endpoint des Quellarbeitsbereichs, das nicht neu geschrieben wird. Parametrisieren Sie die endpoint für die arbeitsbereichsübergreifende Bereitstellung.

Semantikmodelle

Abhängigkeit Auto-bind in Git Hinweise
Semantikmodell Partial Verkettete oder zusammengesetzte Modellreferenzen verwenden Verbindungsstrings nach Namen.
SQL-Analyseendpunkt (lakehouse) No Die Direct Lake-Verbindungszeichenfolge in TMDL expressions.tmdl enthält eine arbeitsbereichsspezifische Endpunkt-URL und eine Datenbank-GUID. Du musst diese Parameter für die arbeitsbereichsübergreifende Bereitstellung ersetzen.
KQL-Datenbank No Die Verbindungszeichenfolge mit einer Cluster-URI in TMDL-Ausdrücken enthält arbeitsbereichsspezifische Werte.
SQL database No Der Verbindungszeichenfolge in TMDL-Ausdrücken enthält workspace-spezifische Werte.
Lagerhalle No Die Verbindung zum SQL-Analytics-Endpunkt des Warehouse verwendet eine workspace-spezifische URL.

Seehäuser

Abhängigkeit Auto-bind in Git Hinweise
Lakehouse (Abkürzung) Ja Interne OneLake-Verknüpfungen, die auf ein anderes Fabric-Element verweisen, beispielsweise ein Lakehouse oder Warehouse, werden als logische ID gespeichert und dem Element im Zielarbeitsbereich erneut zugeordnet. Verknüpfungen zu externen Quellen wie Azure Data Lake Storage Gen2 oder Amazon S3 verweisen auf Inhalte außerhalb von Fabric und enthalten stattdessen einen Verbindungsverweis, sodass sie nicht der Bindung an logische IDs unterliegen. Die vollständige Liste der Abkürzungsziele finden Sie unter OneLake-Abkürzungen. Für das Bereitstellungsverhalten siehe Lakehouse Git Integration und Deployment-Pipelines.

Datenflüsse (Gen2)

Standardmäßig erstellt Dataflow Gen2 absolute Referenzen auf Fabric-Artikel: Die Abfrage speichert die Quell-Arbeitsbereichs-ID und die Objekt-ID des Artikels, die bei der Bereitstellung nicht neu geschrieben werden. Eine Quellreferenz kann stattdessen eine relative Referenz verwenden: Wenn Sie in einem Fabric-Connector ein Element unter dem Knoten !(Current Workspace) auswählen, speichert die Abfrage das Element nach Namen (ohne GUIDs), und bei der Bereitstellung wird es dem entsprechenden Element im Zielarbeitsbereich zugeordnet. Ausgabeziele verwenden immer absolute Referenzen und binden nicht neu. Für Destinationen und für jede absolute Quellreferenz parametrisieren Sie die Werte für die arbeitsübergreifende Bereitstellung. Weitere Informationen finden Sie unter Relative Referenzen mit Fabric-Connectoren in Dataflow Gen2 und Dataflow Gen2 mit CI/CD- und Git-Integration.

Quellen:

Abhängigkeit Auto-bind in Git Hinweise
Lakehouse Partial Wird nur dann erneut gebunden, wenn es als relative Referenz angegeben ist (!(Aktueller Arbeitsbereich)); die standardmäßige absolute Referenz wird nicht erneut gebunden.
Lagerhalle Partial Wird nur dann erneut gebunden, wenn es als relative Referenz angegeben ist (!(Aktueller Arbeitsbereich)); die standardmäßige absolute Referenz wird nicht erneut gebunden.

Zielreferenzen:

Abhängigkeit Auto-bind in Git Hinweise
Lakehouse No
Lagerhalle No
SQL Database No

Spark-Auftragsdefinitionen

Abhängigkeit Auto-bind in Git Hinweise
Environment Ja
Lakehouse No Sie defaultLakehouseArtifactId verwendet eine Objekt-ID.

Kopieraufträge

Abhängigkeit Auto-bind in Git Hinweise
Lakehouse Ja
Lagerhalle No Das Data Warehouse artifactId wird über die logische ID aufgelöst und neu gebunden, aber linkedService speichert auch das SQL endPoint des Quellarbeitsbereichs, das nicht neu geschrieben wird. Parametrisieren Sie die endPoint für die arbeitsbereichsübergreifende Bereitstellung.
SQL Database Ja

GraphQL-APIs

Abhängigkeit Auto-bind in Git Hinweise
SQL-Endpunkt Ja
Lagerhalle Ja
SQL Database Ja

Für alle GraphQL-API-Datenquellen müssen Sie möglicherweise die Verbindung und Zugangsdaten nach der Bereitstellung neu konfigurieren.

Ereignisströme

Abhängigkeit Auto-bind in Git Hinweise
Lakehouse Ja
Eventhouse Ja Alle Ziele werden für CI/CD vollständig unterstützt, wenn sich die Objekte im selben Arbeitsbereich befinden. Für Eventhouse mit Direct Ingestion Mode musst du die Verbindung nach der Bereitstellung möglicherweise manuell neu konfigurieren. Weitere Informationen finden Sie unter Eventstream CI/CD.
Auslöser (Reflex) Ja Alle Ziele werden für CI/CD vollständig unterstützt, wenn sich die Objekte im selben Arbeitsbereich befinden. Weitere Informationen finden Sie unter Eventstream CI/CD.

KQL-Elemente

Abhängigkeit Auto-bind in Git Hinweise
KQL-Datenbank zu eventhouse Ja Das parentEventhouseItemId In DatabaseProperties.json ist eine logische ID und bindet an das Ziel-Eventhouse. Eine KQL-Datenbank wird als Kind ihres übergeordneten Eventhouse bereitgestellt.
KQL-Abfragesatz zur KQL-Datenbank Partial Wird über clusterUri und databaseName aufgelöst, nicht über die Item-ID. Die Definition beinhaltet eine databaseItemId, aber es handelt sich um eine Objekt-ID, die nicht neu gebunden wird, sodass die Auflösung von der URI in verschiedenen Umgebungen abhängt.
Echtzeit-Dashboard für die KQL-Datenbank Partial Verwendet ein dataSources Array mit Cluster-URIs. Dasselbe Muster wie beim KQL-Abfragesatz.

Lager

Abhängigkeit Auto-bind in Git Hinweise
Lagerhaus (Querverweise) No Verweise auf andere Lagerhäuser verwenden Objekt-IDs.
SQL-Endpunkt No SQL-Endpunkt-Referenzen verwenden workspace-spezifische Identifikatoren.

Variable Bibliotheken

Abhängigkeit Auto-bind in Git Hinweise
Fabric-Elemente (Typ ItemReference) No Der ItemReference variable Typ speichert workspaceId und itemId als rohe GUIDs. Du musst diese Werte manuell aktualisieren oder überschreiben durch Wertesätze pro Umgebung.

Elemente ohne Abhängigkeiten

Die folgenden Elemente haben keine Abhängigkeitsbindungsbedenken über den Arbeitsbereich hinaus:

  • Environment
  • SQL Database
  • Eventhouse (Containerelement; KQL-Datenbanken beziehen sich auf das)
  • Gespiegelte Datenbank (nur externe Quellkonfiguration)

Zusammenfassung

Wenn Sie Fabric-Elemente arbeitsbereichsübergreifend bereitstellen, können Abhängigkeiten zwischen den Elementen beeinträchtigt werden, wenn die Verweise als arbeitsbereichsspezifische Objekt-IDs statt als portierbare logische IDs gespeichert werden. Nicht alle Item-Typen unterstützen Abhängigkeitsbindungen über logische IDs. Bevor Sie eine arbeitsübergreifende Bereitstellung einrichten, sehen Sie sich die Kompatibilitätstabellen in diesem Artikel an, um herauszufinden, welche Abhängigkeiten automatisch binden und welche manuelle Parametrisierung erfordern.

Verwandte Inhalte

  • Last updated on