Förstå bindning av beroenden vid distribution mellan arbetsytor

När du distribuerar Fabric-objekt över arbetsytor (till exempel från utveckling till test till produktion) kan beroenden mellan objekt brytas. Vissa objekt lagrar referenser till sina beroenden som objekt-ID (workspace-specifika GUID:er), medan andra använder logiska ID:n (portabla identifierare för tvärfunktionella arbetsytor lagrade .platform i filen).

Objekt som använder logiska ID:n i sina definitioner binder korrekt till motsvarande objekt i målarbetsytan. Objekt som använder objekt-ID:n förblir pekade mot källarbetsytan, vilket bryter distributionen.

Den här artikeln kartlägger vilka Fabric-objekttyper som stödjer beroendebindning genom logiska ID:n när du använder Git-integration, och vilka som inte gör det. För att lära dig mer om logiska ID:n och hur objekt representeras i versionshantering, se Logical ID in Fabric.

Viktiga begrepp

  • Logiskt ID: En automatiskt genererad arbetsyteövergripande identifierare i .platform-filen. Objekt med samma logiska ID behandlas som samma objekt över arbetsytor.
  • Objekt-ID: En arbetsytespecifik GUID som identifierar en viss instans. Objekt-ID:n överlever inte distribution över arbetsytor utan manuell inblandning eller parameterisering.
  • Beroendebinding (Git): När du synkar en Git-gren till en ny arbetsyta löser Fabric beroendereferenser med logiska ID:n och pekar automatiskt på rätt objekt i målarbetsytan.
  • Efter namn eller URI: Vissa objekt refererar till beroenden med visningsnamn eller URI snarare än med ID. Dessa referenser kan lösas korrekt eller inte, beroende på namngivningskonventionerna i olika arbetsytor.

Hur beroendebindning fungerar

Inom en arbetsmiljö refererar objekt till sina beroenden med hjälp av objekt-ID:n. När Fabric exporterar ett objekt till Git ersätter det några av dessa objekt-ID:n med logiska ID:n från filen.platform. När du synkroniserar Git-grenen till en annan arbetsyta löser Fabric tillbaka dessa logiska ID:n till rätt objekt-ID:n i målarbetsytan. Det är detta som gör att beroendebindning fungerar.

Dock ersätts inte alla beroendereferenser med logiska ID:n under exporten. Objekt som behåller objekt-ID i sin Git-representation pekar fortfarande på den ursprungliga arbetsytan efter synkronisering, och du behöver uppdatera dem manuellt eller genom parameterisering.

Important

Beroendebindning gäller endast referenser mellan Fabric-objekt inom samma arbetsyta. Om ett objekt refererar till ett Fabric-objekt i en annan arbetsyta använder den referensen ett objekt-ID och binds inte automatiskt. Referenser till anslutningar (datakällsanslutningar, gateways) binds inte heller automatiskt. Använd variabelbibliotek med miljöspecifika värdeuppsättningar för att hantera anslutningsreferenser över miljöer.

Kompatibilitet för beroendebindning

Följande tabeller visar om varje Fabric-objekttyps beroenden binds på rätt sätt när du distribuerar över arbetsytor. För närvarande handlar denna artikel om Git-integrationsbeteende . Eftersom bindning bestäms av hur varje objekt lagrar sina beroendereferenser i sin definition, gäller samma beteende för andra distributionsmekanismer som återanvänder dessa definitioner, såsom distributionspipelines och import- (bulk-) API:er.

Dessa tabeller antar att beroendet är ett annat element i samma arbetsyta som källobjektet. En referens till ett objekt i en annan arbetsyta binds aldrig automatiskt. Den förblir fastnålad till källobjektets ID oavsett värdet som visas i tabellen.

Auto-bind i Git-kolumnen indikerar:

  • Ja: Föremålsdefinitionen i Git lagrar beroendereferensen som ett logiskt ID. När du synkar grenen till en ny arbetsyta binds referensen automatiskt till det matchande objektet i den arbetsytan.
  • Nej: Föremålsdefinitionen i Git lagrar beroendereferensen som ett objekt-ID (workspace-specific GUID). Referensen fortsätter att peka på källarbetsytan efter synk. Du behöver manuellt uppdatera eller parametrisera den för distribution över arbetsområden.
  • Delvis: Föremålet löser beroendet med namn eller URI, vilket kan fungera om namngivningen är konsekvent mellan arbetsytor.

Notebooks

Beroende Auto-bind i Git Notes
Lakehouse Yes Kräver att man aktiverar "Lakehouse Auto-Binding in Git" i anteckningsbokens inställningar. När den är aktiverad ersätts objekt-ID:t med ett logiskt ID i notebook-settings.json. Den här inställningen är avstängd som standard. För mer information, se Lakehouse auto-binding i Git.
Environment Yes
Speglad databas No

Anmärkning

Bindning från anteckningsbok till Lakehouse är inte aktiverad som standard. Du måste aktivera inställningen "Lakehouse Auto-Binding in Git" i inställningarna för varje anteckningsbok. Mer information finns i Källkontroll och distribution av notebook-filer.

Reports

Beroende Auto-bind i Git Notes
Semantisk modell (från Power BI-rapporten) Partial Rapporten refererar modellen genom en relativ byPath referens i definition.pbir, inte en explicit logisk identifiering. Den löses korrekt när modellen distribueras till samma relativa plats i målarbetsytan, men binder inte genom ett logiskt ID. För mer information, se Power BI Desktop projektrapportmappen.
Semantisk modell (från paginerad rapport) No Rapportens reťazec pripojenia refererar till den semantiska modellen via ett arbetsområdesspecifikt ID som inte skrivs om vid distribution, så den förblir pekad mot källmodellen. Du behöver uppdatera den här referensen för distribution mellan arbetsytor. (Rapporter som skrivs i Report Builder och refererar till modellen med namn kan istället lösas efter visningsnamn, vilket är Partial.)

Pipeline

Beroende Auto-bind i Git Notes
Pipeline Yes
Notebook Yes
Dataflöde Gen2 Yes
SQL Database Yes
Definition av Spark-jobb No Aktiviteten SparkJobDefinition refererar till Spark Job Definition med objekt-ID, inte logiskt ID, så den förblir pekad på källobjektet efter distribution. Du behöver parametrisera detta värde för distribution över arbetsmiljöer.
Lakehouse Yes
Semantisk modell No PBISemanticModelRefresh-aktiviteten refererar till den semantiska modellen med artikel-ID, inte logiskt ID. Du behöver parametrisera detta värde för distribution över arbetsmiljöer.
Lager No Lagret artifactId löser via det logiska ID:t och binder om, men lagrar linkedService också källarbetsytans SQL endpoint, som inte skrivs om. Parametrisera endpoint för distribution mellan arbetsytor.

Semantiska modeller

Beroende Auto-bind i Git Notes
Semantisk modell Partial Länkade eller sammansatta modellreferenser använder anslutningssträngar med namn.
Slutpunkt för SQL-analys (lakehouse) No Direct Lake-anslutningssträngen i TMDL expressions.tmdl innehåller en arbetsytespecifik slutpunkts-URL och en GUID för databasen. Du behöver ersätta dessa parametrar för distribution över arbetsytor.
KQL-databas No Anslutningssträngen med en kluster-URI i TMDL-uttryck innehåller arbetsytesspecifika värden.
SQL database No reťazec pripojenia i TMDL-uttryck innehåller arbetsytespecifika värden.
Lager No Anslutningen till lagrets SQL-analysendpoint använder en arbetsplatsspecifik URL.

Sjöhus

Beroende Auto-bind i Git Notes
Lakehouse (genväg) Yes Interna OneLake-genvägar som pekar på ett annat Fabric-objekt, såsom ett sjöhus eller lager, lagras som ett logiskt ID och binds om till mål-arbetsytsobjektet. Genvägar till externa källor, som Azure Data Lake Storage Gen2 eller Amazon S3, pekar utanför Fabric och bär istället en anslutningsreferens, så de omfattas inte av logisk ID-bindning. En fullständig lista över mål för genvägar finns i OneLake-genvägar. För distributionsbeteende, se Lakehouse Git-integration och distributionspipelines.

Dataflöden (Gen2)

Som standard skapar Dataflow Gen2 absoluta referenser till Fabric-objekt: frågan lagrar källarbetsyts-ID och objektets ID, vilka inte skrivs om vid distribution. En källreferens kan istället använda en relativ referens: när du väljer ett objekt under !( Current Workspace) nod i en Fabric-anslutning, lagrar frågan objektet med namn (inga GUID), och det löses till det matchande objektet i målarbetsytan vid distribution. Utdatadestinationer använder alltid absoluta referenser och ombinds inte. För mål och alla absoluta källreferenser, parametrisera värdena för distribution mellan arbetsytor. För mer information, se Relativa referenser med Fabric-kontakter i Dataflow Gen2 och Dataflow Gen2 med CI/CD- och Git-integration.

Källhänvisningar:

Beroende Auto-bind i Git Notes
Lakehouse Partial Ombinder endast när den skrivs som en relativ referens (!( nuvarande arbetsplats)); Den standardabsoluta referensen binder inte om.
Lager Partial Ombinder endast när den skrivs som en relativ referens (!( nuvarande arbetsplats)); Den standardabsoluta referensen binder inte om.

Destinationsreferenser:

Beroende Auto-bind i Git Notes
Lakehouse No
Lager No
SQL Database No

Definitioner för Spark-jobb

Beroende Auto-bind i Git Notes
Environment Yes
Lakehouse No Den defaultLakehouseArtifactId använder ett objekt-ID.

Kopieringsjobb

Beroende Auto-bind i Git Notes
Lakehouse Yes
Lager No Lagret artifactId löser via det logiska ID:t och binder om, men lagrar linkedService också källarbetsytans SQL endPoint, som inte skrivs om. Parametrisera endPoint för distribution mellan arbetsytor.
SQL Database Yes

GraphQL-APIer

Beroende Auto-bind i Git Notes
SQL-slutpunkt Yes
Lager Yes
SQL Database Yes

För alla GraphQL API-datakällor kan du behöva konfigurera om anslutningen och uppgifterna efter distribution.

Eventstreams

Beroende Auto-bind i Git Notes
Lakehouse Yes
Eventhouse Yes Alla destinationer stöds fullt ut för CI/CD när objekten är i samma arbetsyta. För Eventhouse med Direct Ingestion-läge kan du behöva konfigurera om anslutningen manuellt efter utrullning. För mer information, se Eventstream CI/CD.
Aktivator (Reflex) Yes Alla destinationer stöds fullt ut för CI/CD när objekten är i samma arbetsyta. För mer information, se Eventstream CI/CD.

KQL-föremål

Beroende Auto-bind i Git Notes
KQL-databas till eventhouse Yes parentEventhouseItemId i DatabaseProperties.json är ett logiskt ID och är kopplat till målhändelsehuset. En KQL-databas driftsätts som en underordnad resurs till sitt överordnade eventhouse.
KQL-frågeuppsättning till KQL-databasen Partial Löser genom clusterUri och databaseName, inte via objekt-ID:t. Definitionen inkluderar en databaseItemId, men det är ett objekt-ID som inte binds om, så upplösningen beror på URI:n i olika miljöer.
Real-Time Dashboard till KQL-databas Partial Använder en dataSources array med kluster-URI:er. Samma mönster som KQL-frågesetet.

Lagerhus

Beroende Auto-bind i Git Notes
Lager (korshänvisning) No Referenser till andra lager använder objekt-ID:n.
SQL-slutpunkt No SQL Endpoint-referenser använder arbetsytespecifika identifierare.

Variabelbibliotek

Beroende Auto-bind i Git Notes
Fabric-items (ItemReference-typ) No Variabeltypen ItemReference lagras workspaceId och itemId som råa GUID:er. Du måste manuellt uppdatera eller åsidosätta dessa värden genom värdeuppsättningar per miljö.

Objekt utan beroenden

Följande objekt har inga bekymmer med beroendebindning mellan arbetsområden:

  • Environment
  • SQL Database
  • Eventhouse (behållarobjekt; KQL-databaser syftar på den)
  • Speglad databas (endast extern källkodskonfiguration)

Sammanfattning

När du distribuerar Fabric-objekt över arbetsytor kan beroenden mellan objekt brytas om referenserna lagras som arbetsytsspecifika objekt-ID:n istället för portabla logiska ID:n. Alla objekttyper stödjer inte beroendebindning via logiska ID:n. Innan du sätter upp cross-workspace distribution, granska kompatibilitetstabellerna i denna artikel för att identifiera vilka beroenden som binder automatiskt och vilka som kräver manuell parameterisering.

Relaterat innehåll

  • Last updated on