Begrijp afhankelijkheidsbinding bij cross-workspace implementatie

Wanneer je Fabric-items uitrolt over werkruimtes (bijvoorbeeld van Ontwikkeling naar Test naar Productie), kunnen afhankelijkheden tussen items breken. Sommige items slaan referenties naar hun afhankelijkheden op als object-ID's (werkruimte-specifieke GUID's), terwijl andere logische ID's gebruiken (cross-workspace portable identifiers opgeslagen in het .platform bestand).

Items die logische ID’s gebruiken in hun definities, worden correct gekoppeld aan het bijbehorende item in de doelwerkruimte. Items die object-id's gebruiken, blijven verwijzen naar de bronwerkruimte, waardoor de implementatie mislukt.

Dit artikel brengt in kaart welke Fabric-itemtypes dependency binding ondersteunen via logische ID's wanneer je Git-integratie gebruikt, en welke niet. Voor meer informatie over logische ID's en hoe items worden weergegeven in bronbeheer, zie Logical ID in Fabric.

belangrijke concepten

  • Logical ID: Een automatisch gegenereerde werkruimteoverschrijdende id in het .platform bestand. Items met dezelfde logische ID worden als hetzelfde item behandeld in werkomgevingen.
  • Object-ID: Een werkruimte-specifieke GUID die een specifieke instantie identificeert. Object-ID’s blijven bij uitrol tussen workspaces niet behouden zonder handmatige tussenkomst of parametrisering.
  • Dependency binding (Git): Wanneer je een Git-branch synchroniseert met een nieuwe workspace, lost Fabric dependency references op met behulp van logische ID's, waarbij automatisch wordt verwezen naar het juiste item in de doelwerkruimte.
  • Op naam of op URI: Sommige items verwijzen naar afhankelijkheden op basis van displaynaam of URI in plaats van op ID. Deze referenties kunnen wel of niet correct worden opgelost, afhankelijk van naamgevingsconventies tussen werkruimtes.

Hoe afhankelijkheidskoppeling werkt

Binnen een werkruimte verwijzen items naar hun afhankelijkheden met behulp van object-ID's. Wanneer Fabric een item exporteert naar Git, vervangt het sommige van deze object-ID's door logische ID's uit het .platform bestand. Wanneer je de Git-branch synchroniseert naar een andere workspace, lost Fabric die logische ID's weer op naar de juiste object-ID's in de doelwerkruimte. Dit is wat afhankelijkheidsbinding zo goed mogelijk maakt.

Echter, niet alle afhankelijkheidsreferenties worden tijdens export vervangen door logische ID's. Items die object-ID's in hun Git-representatie bewaren, wijzen na synchronisatie nog steeds naar de originele werkruimte, en je moet ze handmatig of via parametrisatie bijwerken.

Important

Dependency binding geldt alleen voor referenties tussen Fabric-items binnen dezelfde werkruimte. Als een item een Fabric-item in een andere werkruimte verwijst, gebruikt die referentie een object-ID en bindt niet automatisch. Verwijzingen naar Connections (databronverbindingen, gateways) binden ook niet automatisch. Gebruik variabele bibliotheken met omgevingsspecifieke waardesets om verbindingsreferenties tussen omgevingen te beheren.

Compatibiliteit van afhankelijkheidsbinding

De volgende tabellen tonen of de afhankelijkheden van elk Fabric-itemtype correct binden wanneer je over werkruimtes heen deployt. Momenteel behandelt dit artikel het gedrag van Git-integratie . Omdat binding wordt bepaald door hoe elk item zijn afhankelijkheidsreferenties in zijn definitie opslaat, geldt hetzelfde gedrag voor andere deploymentmechanismen die die definities hergebruiken, zoals deployment pipelines en de import (bulk) API's.

Deze tabellen gaan ervan uit dat de afhankelijkheid een ander item is in dezelfde werkruimte als het bronitem. Een verwijzing naar een item in een andere werkruimte bindt nooit automatisch. Het blijft vastgezet aan de bronobject-ID, ongeacht de waarde die in de tabel wordt weergegeven.

De kolom Auto-bind in Git geeft aan:

  • Ja: De itemdefinitie in Git slaat de afhankelijkheidsreferentie op als een logische ID. Wanneer je de branch synchroniseert met een nieuwe werkruimte, bindt de referentie automatisch aan het bijpassende item in die werkruimte.
  • Nee: De itemdefinitie in Git slaat de afhankelijkheidsreferentie op als een object-ID (workspace-specific GUID). De referentie blijft na synchronisatie naar de bronwerkruimte verwijzen. Je moet het handmatig bijwerken of parametriseren voor cross-workspace deployment.
  • Gedeeltelijk: Het item lost de afhankelijkheid op via naam of URI, wat kan werken als de naamgeving consistent is tussen werkruimtes.

Notebooks

Afhankelijkheid Auto-bind in Git Aantekeningen
Lakehouse Yes Vereist het inschakelen van "Lakehouse Auto-Binding in Git" in de notebookinstellingen. Wanneer ingeschakeld, wordt de object-ID vervangen door een logische ID in notebook-settings.json. Deze instelling is standaard uitgeschakeld. Voor meer informatie, zie Lakehouse auto-binding in Git.
Environment Yes
Gespiegelde database No

Opmerking

Notebook naar Lakehouse binding is standaard niet ingeschakeld. Je moet de instelling "Lakehouse Auto-Binding in Git" inschakelen in de instellingen van elk notitieboek. Zie Broncodebeheer en implementatie van Notebook voor meer informatie.

Reports

Afhankelijkheid Auto-bind in Git Aantekeningen
Semantisch Model (uit Power BI-rapport) Partial Het rapport verwijst naar het model via een relatieve byPath referentie in definition.pbir, niet via een expliciete logische ID. Het lost correct op wanneer het model op dezelfde relatieve locatie in de doelwerkruimte wordt uitgezet, maar bindt niet via een logische ID. Voor meer informatie raadpleegt u rapportmap voor Power BI Desktop-projecten.
Semantisch Model (uit gepagineerd rapport) No De verbindingsreeks van het rapport verwijst naar het semantische model via een workspace-specifieke ID die niet wordt herschreven bij deployment, zodat het op het bronmodel blijft wijzen. Je moet deze referentie bijwerken voor werkruimteoverschrijdende implementatie. (Rapporten die in Report Builder zijn geschreven en het model bij naam verwijzen, kunnen in plaats daarvan worden opgelost op display name, namelijk Partial.)

Pipeline

Afhankelijkheid Auto-bind in Git Aantekeningen
Pipeline Yes
Notebook Yes
Gegevensstroom Gen2 Yes
SQL Database Yes
Spark-taakdefinitie No De SparkJobDefinition-activiteit verwijst naar de Spark Job Definition via object-ID, niet met logische ID, zodat deze na de uitrol op het bronitem blijft wijzen. Je moet deze waarde parametriseren voor cross-workspace deployment.
Lakehouse Yes
Semantisch model No De activiteit PBISemanticModelRefresh verwijst naar het semantische model aan de hand van de item-ID, niet van de logische ID. Je moet deze waarde parametriseren voor cross-workspace deployment.
Magazijn No Het magazijn artifactId lost op via de logische ID en rebindt, maar slaat linkedService ook de SQL endpointvan de bronwerkruimte op, die niet wordt herschreven. Maak de endpoint parameteriseerbaar voor implementatie over meerdere werkruimten.

Semantische modellen

Afhankelijkheid Auto-bind in Git Aantekeningen
Semantisch model Partial Gekoppelde of samengestelde modelreferenties gebruiken verbindingsstrings op naam.
SQL Analytics-eindpunt (lakehouse) No De Direct Lake-verbindingsreeks in TMDL expressions.tmdl bevat een werkruimte-specifieke endpoint-URL en database-GUID. Je moet deze parameters vervangen voor implementatie over meerdere werkruimten.
KQL-databank No De verbindingsreeks met een cluster-URI in TMDL-expressies bevat werkruimte-specifieke waarden.
SQL database No De verbindingsreeks in TMDL-expressies bevat werkruimte-specifieke waarden.
Magazijn No De verbinding met het warehouse-SQL-analyse-endpoint gebruikt een workspace-specifieke URL.

Meerhuisjes

Afhankelijkheid Auto-bind in Git Aantekeningen
Lakehouse (kortere route) Yes Interne OneLake-snelkoppelingen die wijzen op een ander Fabric-item, zoals een lakehouse of magazijn, worden opgeslagen als een logische ID en worden opnieuw gekoppeld aan het doel-werkruimteitem. Snelkoppelingen naar externe bronnen, zoals Azure Data Lake Storage Gen2 of Amazon S3, wijzen naar locaties buiten Fabric en bevatten in plaats daarvan een verbindingsverwijzing, waardoor ze niet onder logisch-ID-binding vallen. Voor de volledige lijst van snelkoppelingsdoelen, zie OneLake shortcuts. Voor implementatiegedrag, zie Lakehouse Git-integratie- en deploymentpipelines.

Dataflows (Gen2)

Standaard maakt Dataflow Gen2 absolute referenties naar Fabric-items: de query slaat de source workspace-ID en de object-ID van het item op, die niet worden herschreven tijdens deployment. Een bronreferentie kan in plaats daarvan een relatieve referentie gebruiken: wanneer je een item selecteert onder de !( Current Workspace) node in een Fabric-connector, slaat de query het item op naam op (geen GUIDs), en wordt het opgelost naar het overeenkomende item in de doelwerkruimte bij de deployment. Uitvoerbestemmingen gebruiken altijd absolute referenties en herbinden niet. Parametriseer de waarden voor bestemmingen en voor elke absolute bronreferentie voor implementatie over meerdere werkruimten. Voor meer informatie, zie Relatieve referenties met Fabric-connectoren in Dataflow Gen2 en Dataflow Gen2 met CI/CD- en Git-integratie.

Bronverwijzingen:

Afhankelijkheid Auto-bind in Git Aantekeningen
Lakehouse Partial Herbindt alleen wanneer het als een relatieve referentie wordt geschreven (!( Huidige werkruimte)); De standaard absolute referentie herbindt niet.
Magazijn Partial Herbindt alleen wanneer het als een relatieve referentie wordt geschreven (!( Huidige werkruimte)); De standaard absolute referentie herbindt niet.

Bestemmingsreferenties:

Afhankelijkheid Auto-bind in Git Aantekeningen
Lakehouse No
Magazijn No
SQL Database No

Spark-taakdefinities

Afhankelijkheid Auto-bind in Git Aantekeningen
Environment Yes
Lakehouse No Het defaultLakehouseArtifactId gebruikt een object-ID.

Kopieeropdrachten

Afhankelijkheid Auto-bind in Git Aantekeningen
Lakehouse Yes
Magazijn No Het magazijn artifactId lost op via de logische ID en rebindt, maar slaat linkedService ook de SQL endPointvan de bronwerkruimte op, die niet wordt herschreven. Maak de endPoint parameteriseerbaar voor implementatie over meerdere werkruimten.
SQL Database Yes

GraphQL-API’s

Afhankelijkheid Auto-bind in Git Aantekeningen
SQL-eindpunt Yes
Magazijn Yes
SQL Database Yes

Voor alle GraphQL API-gegevensbronnen moet je mogelijk de verbinding en inloggegevens na de implementatie opnieuw configureren.

Gebeurtenisstromen

Afhankelijkheid Auto-bind in Git Aantekeningen
Lakehouse Yes
Eventhouse Yes Alle bestemmingen worden volledig ondersteund voor CI/CD wanneer items in dezelfde werkruimte zijn. Voor Eventhouse met Direct Ingestion-modus moet je mogelijk de verbinding handmatig herconfigureren na de deployment. Voor meer informatie, zie Eventstream CI/CD.
Activator (Reflex) Yes Alle bestemmingen worden volledig ondersteund voor CI/CD wanneer items in dezelfde werkruimte zijn. Voor meer informatie, zie Eventstream CI/CD.

KQL-items

Afhankelijkheid Auto-bind in Git Aantekeningen
KQL-database naar eventhouse Yes De parentEventhouseItemId in DatabaseProperties.json is een logische ID en is gekoppeld aan het doel-eventhouse. Een KQL-database wordt geïmplementeerd als onderliggend element van het bovenliggende eventhouse.
van KQL-queryset naar KQL-database Partial Wordt opgelost via clusterUri en databaseName, niet via de item-id. De definitie bevat een databaseItemId, maar het is een object-ID die niet opnieuw bindt, dus de resolutie hangt af van de URI tussen omgevingen.
Real-Time Dashboard naar KQL-database Partial Gebruikt een dataSources array met cluster-URI's. Zelfde patroon als de KQL-queryset.

Magazijnen

Afhankelijkheid Auto-bind in Git Aantekeningen
Magazijn (kruisverwijzing) No Verwijzingen naar andere magazijnen gebruiken object-ID's.
SQL-eindpunt No SQL Endpoint-referenties gebruiken workspace-specifieke identifiers.

Variabelenbibliotheken

Afhankelijkheid Auto-bind in Git Aantekeningen
Fabric-items (van het type ItemReference) No Het ItemReference variabele type slaat workspaceId en itemId op als ruwe GUID's. Je moet deze waarden handmatig bijwerken of overschrijven via waardesets per omgeving.

Items zonder afhankelijkheden

De volgende items hebben geen problemen met afhankelijkheidskoppelingen tussen workspaces:

  • Environment
  • SQL Database
  • Eventhouse (containeritem; KQL-databases verwijzen hiernaar)
  • Gespiegelde database (alleen voor configuratie van de externe bron)

Overzicht

Wanneer je Fabric-items over werkruimtes uitrolt, kunnen afhankelijkheden tussen items breken als de referenties worden opgeslagen als werkruimte-specifieke object-ID's in plaats van draagbare logische ID's. Niet alle itemtypes ondersteunen afhankelijkheidsbinding via logische ID's. Voordat je cross-workspace deployment opzet, bekijk de compatibiliteitstabellen in dit artikel om te bepalen welke afhankelijkheden automatisch binden en welke handmatige parameterisatie vereisen.

Verwante onderwerpen

  • Last updated on