Forstå avhengighetsbinding i tverrarbeidsområde-distribusjon

Når du distribuerer Fabric-elementer på tvers av arbeidsområder (for eksempel fra utvikling til test til produksjon), kan avhengigheter mellom elementer brytes. Noen elementer lagrer referanser til sine avhengigheter som objekt-ID-er (arbeidsområde-spesifikke GUID-er), mens andre bruker logiske ID-er (tverrarbeidsområde-portable identifikatorer lagret i filen .platform ).

Elementer som bruker logiske ID-er i sine definisjoner bindes korrekt til det tilsvarende elementet i målarbeidsområdet. Elementer som bruker objekt-ID-er forblir pekt mot kildearbeidsområdet, noe som bryter distribusjonen.

Denne artikkelen kartlegger hvilke Fabric-objekttyper som støtter avhengighetsbinding gjennom logiske ID-er når du bruker Git-integrasjon, og hvilke som ikke gjør det. For å lære mer om logiske ID-er og hvordan elementer representeres i kildekodekontroll, se Logical ID in Fabric.

Nøkkelbegreper

  • Logisk ID: En automatisk generert identifikator på tvers av arbeidsområder i filen.platform. Elementer med samme logiske ID behandles som samme element på tvers av arbeidsområder.
  • Objekt-ID: En arbeidsområde-spesifikk GUID som identifiserer en bestemt instans. Objekt-ID-er overlever ikke distribusjon på tvers av arbeidsområder uten manuell inngripen eller parameterisering.
  • Avhengighetsbinding (Git): Når du synkroniserer en Git-gren til et nytt arbeidsområde, løser Fabric avhengighetsreferanser ved hjelp av logiske ID-er, og peker automatisk på riktig element i målarbeidsområdet.
  • Etter navn eller URI: Noen elementer refererer til avhengigheter etter visningsnavn eller URI i stedet for ID. Disse referansene kan eller kan ikke løses riktig, avhengig av navnekonvensjoner på tvers av arbeidsområder.

Hvordan avhengighetsbinding fungerer

Innenfor et arbeidsområde refererer elementene til sine avhengigheter ved hjelp av objekt-ID-er. Når Fabric eksporterer et element til Git, erstatter det noen av disse objekt-ID-ene med logiske ID-er fra filen.platform. Når du synkroniserer Git-grenen til et annet arbeidsområde, løser Fabric disse logiske ID-ene tilbake til riktige objekt-IDer i målarbeidsområdet. Dette er det som gjør at avhengighetsbinding fungerer.

Imidlertid blir ikke alle avhengighetsreferanser erstattet med logiske ID-er under eksport. Elementer som beholder objekt-ID-er i sin Git-representasjon peker fortsatt til det opprinnelige arbeidsområdet etter synkronisering, og du må oppdatere dem manuelt eller gjennom parameterisering.

Important

Avhengighetsbinding gjelder kun referanser mellom Fabric-elementer innenfor samme arbeidsområde. Hvis et element refererer til et Fabric-element i et annet arbeidsområde, bruker den referansen en objekt-ID og bindes ikke automatisk. Referanser til tilkoblinger (datakildetilkoblinger, gateways) bindes heller ikke automatisk. Bruk variabelbiblioteker med miljøspesifikke verdisett for å administrere tilkoblingsreferanser på tvers av miljøer.

Avhengighetsbindingskompatibilitet

Følgende tabeller viser om avhengighetene til hver Fabric-objekttype binder riktig når du deployerer på tvers av arbeidsområder. For øyeblikket dekker denne artikkelen Git-integrasjonsatferd . Fordi binding bestemmes av hvordan hvert element lagrer sine avhengighetsreferanser i sin definisjon, gjelder samme oppførsel for andre distribusjonsmekanismer som gjenbruker disse definisjonene, som distribusjonspipelines og import-API-er (bulk-)API-er.

Disse tabellene antar at avhengigheten er et annet element i samme arbeidsområde som kildeelementet. En referanse til et element i et annet arbeidsområde bindes aldri automatisk. Den forblir festet til kildeobjekt-ID-en uavhengig av verdien som vises i tabellen.

Auto-bind i Git-kolonnen indikerer:

  • Ja: Varedefinisjonen i Git lagrer avhengighetsreferansen som en logisk ID. Når du synkroniserer grenen til et nytt arbeidsområde, bindes referansen automatisk til det tilsvarende elementet i det arbeidsområdet.
  • Nei: Itemdefinisjonen i Git lagrer avhengighetsreferansen som en objekt-ID (workspace-specific GUID). Referansen fortsetter å peke til kildearbeidsområdet etter synkronisering. Du må manuelt oppdatere eller parameterisere det for distribusjon på tvers av arbeidsområder.
  • Delvis: Elementet løser avhengigheten med navn eller URI, noe som kan fungere hvis navngivningen er konsistent på tvers av arbeidsområder.

Notebooks

Avhengighet Auto-binding i Git Merknader
Lakehouse Ja Krever aktivering av "Lakehouse Auto-Binding in Git" i notatbokinnstillingene. Når den er aktivert, erstattes objekt-ID-en med en logisk ID i notebook-settings.json. Denne innstillingen er deaktivert som standard. For mer informasjon, se Lakehouse auto-binding i Git.
Miljø Ja
Speilet database Nei

Note

Binding fra Notebook til Lakehouse er ikke aktivert som standard. Du må slå på innstillingen "Lakehouse Auto-Binding in Git" i hver notatboks innstillinger. For mer informasjon, se Notebook kildekode og distribusjon.

Rapporter

Avhengighet Auto-binding i Git Merknader
Semantisk modell (fra Power BI-rapporten) Delvis Rapporten refererer modellen gjennom en relativ byPath referanse i definition.pbir, ikke en eksplisitt logisk ID. Den løses korrekt når modellen deployeres til samme relative plassering i målarbeidsområdet, men binder ikke gjennom en logisk ID. For mer informasjon, se Power BI Desktop prosjektrapportmappe.
Semantisk modell (fra paginert rapport) Nei Rapportens tilkoblingsstreng refererer til den semantiske modellen via en arbeidsområde-spesifikk ID som ikke skrives om ved utrulling, så den forblir pekt mot kildemodellen. Du må oppdatere denne referansen for utrulling på tvers av arbeidsområder. (Rapporter skrevet i Report Builder som refererer modellen med navn, kan i stedet løses etter visningsnavn, som er Partial.)

Pipeline

Avhengighet Auto-binding i Git Merknader
Pipeline Ja
Bærbare Ja
Dataflyt gen2 Ja
SQL Database Ja
Spark-jobbdefinisjon Nei SparkJobDefinition-aktiviteten refererer til Spark Job Definition etter objekt-ID, ikke logisk ID, slik at den forblir pekt på kildeelementet etter distribusjon. Du må parameterisere denne verdien for distribusjon på tvers av arbeidsområder.
Lakehouse Ja
Semantisk modell Nei PBISemanticModelRefresh-aktiviteten refererer til den semantiske modellen etter element-ID, ikke logisk ID. Du må parameterisere denne verdien for distribusjon på tvers av arbeidsområder.
Lager Nei Lageret artifactId løser gjennom den logiske ID-en og binder på nytt, men lagrer linkedService også SQL-koden endpointtil kildearbeidsområdet, som ikke skrives om. Parameteriser for endpoint utrulling på tvers av arbeidsområder.

Semantiske modeller

Avhengighet Auto-binding i Git Merknader
Semantisk modell Delvis Lenkede eller sammensatte modellreferanser bruker tilkoblingsstrenger etter navn.
SQL Analytics Endpoint (lakehouse) Nei Direct Lake-tilkoblingsstreng i TMDL expressions.tmdl inneholder en arbeidsplassspesifikk endepunkts-URL og database-GUID. Du må erstatte disse parameterne for distribusjon på tvers av arbeidsområder.
KQL-database Nei tilkoblingsstreng med en klynge-URI i TMDL-uttrykk inneholder arbeidsområdespesifikke verdier.
SQL-database Nei tilkoblingsstreng i TMDL-uttrykk inneholder arbeidsområdespesifikke verdier.
Lager Nei Tilkoblingen til varehusets SQL-analyseendepunkt bruker en arbeidsplassspesifikk URL.

Sjøhus

Avhengighet Auto-binding i Git Merknader
Lakehouse (snarvei) Ja Interne OneLake-snarveier som peker til et annet Fabric-element, som et lakehouse eller lager, lagres som en logisk ID og bindes på nytt til mål-arbeidsområdet. Snarveier til eksterne kilder, som Azure Data Lake Storage Gen2 eller Amazon S3, peker utenfor Fabric og bærer en tilkoblingsreferanse i stedet, slik at de ikke er underlagt logisk ID-binding. For fullstendig liste over snarveimål, se OneLake snarveier. For distribusjonsatferd, se Lakehouse Git-integrasjon og distribusjonspipelines.

Dataflyter (Gen2)

Som standard lager Dataflow Gen2 absolutte referanser til Fabric-elementer: spørringen lagrer kildearbeidsområdets ID og objektets ID, som ikke skrives om under distribusjon. En kildereferanse kan i stedet bruke en relativ referanse: når du velger et element under !( Current Workspace)-node i en Fabric-kobling, lagrer spørringen elementet etter navn (ingen GUIDs), og det løses til det tilsvarende elementet i målarbeidsområdet ved distribusjon. Utdatadestinasjoner bruker alltid absolutte referanser og binder ikke på nytt. For destinasjoner, og for enhver absolutt kildereferanse, parameteriser verdiene for distribusjon på tvers av arbeidsområder. For mer informasjon, se Relative referanser med Fabric-kontakter i Dataflow Gen2 og Dataflow Gen2 med CI/CD- og Git-integrasjon.

Kildereferanser:

Avhengighet Auto-binding i Git Merknader
Lakehouse Delvis Binder på nytt kun når det er skrevet som en relativ referanse (!( Nåværende arbeidsplass)); Den standard absolutte referansen bindes ikke på nytt.
Lager Delvis Binder på nytt kun når det er skrevet som en relativ referanse (!( Nåværende arbeidsplass)); Den standard absolutte referansen bindes ikke på nytt.

Destinasjonsreferanser:

Avhengighet Auto-binding i Git Merknader
Lakehouse Nei
Lager Nei
SQL Database Nei

Definisjoner av Spark-jobber

Avhengighet Auto-binding i Git Merknader
Miljø Ja
Lakehouse Nei Den defaultLakehouseArtifactId bruker en objekt-ID.

Kopijobber

Avhengighet Auto-binding i Git Merknader
Lakehouse Ja
Lager Nei Lageret artifactId løser gjennom den logiske ID-en og binder på nytt, men lagrer linkedService også SQL-koden endPointtil kildearbeidsområdet, som ikke skrives om. Parameteriser for endPoint utrulling på tvers av arbeidsområder.
SQL Database Ja

GraphQL API-er

Avhengighet Auto-binding i Git Merknader
SQL Endpoint Ja
Lager Ja
SQL Database Ja

For alle GraphQL API-datakilder kan det hende du må konfigurere tilkoblingen og legitimasjonen på nytt etter utrulling.

Hendelsesstrømmer

Avhengighet Auto-binding i Git Merknader
Lakehouse Ja
Eventhouse Ja Alle destinasjoner støttes fullt ut for CI/CD når elementer er i samme arbeidsområde. For Eventhouse med Direct Egestion-modus kan det hende du må konfigurere tilkoblingen manuelt etter utrulling. For mer informasjon, se Eventstream CI/CD.
Aktivator (Refleks) Ja Alle destinasjoner støttes fullt ut for CI/CD når elementer er i samme arbeidsområde. For mer informasjon, se Eventstream CI/CD.

KQL-gjenstander

Avhengighet Auto-binding i Git Merknader
KQL-database til eventhouse Ja Inn-en parentEventhouseItemIdDatabaseProperties.json er en logisk ID og binder til mål-eventhuset. En KQL-database distribueres som et barn av sitt overordnede hendelseshus.
KQL-spørringssett til KQL-database Delvis Løses gjennom clusterUri og databaseName, ikke gjenstands-ID-en. Definisjonen inkluderer en databaseItemId, men det er en objekt-ID som ikke bindes på nytt, så oppløsningen avhenger av URI-en på tvers av miljøene.
Real-Time Dashbord til KQL-database Delvis Bruker et dataSources array med klynge-URI-er. Samme mønster som KQL-forespørselssettet.

Lagre

Avhengighet Auto-binding i Git Merknader
Lager (krysreferanse) Nei Referanser til andre lagre bruker objekt-IDer.
SQL Endpoint Nei SQL Endpoint-referanser bruker arbeidsplassspesifikke identifikatorer.

Variabelbiblioteker

Avhengighet Auto-binding i Git Merknader
Fabric-elementer (ItemReference-type) Nei Den ItemReference variable typen lagres workspaceId og itemId som rå GUID-er. Du må manuelt oppdatere eller overstyre disse verdiene gjennom verdisett per miljø.

Elementer uten avhengigheter

Følgende elementer har ingen bekymringer om avhengighet på tvers av arbeidsområder:

  • Miljø
  • SQL Database
  • Eventhouse (beholdergjenstand; KQL-databaser refererer til det)
  • Speilet database (kun ekstern kildekode-konfigurasjon)

Sammendrag

Når du distribuerer Fabric-elementer på tvers av arbeidsområder, kan avhengigheter mellom elementer brytes hvis referansene lagres som arbeidsområdespesifikke objekt-ID-er i stedet for bærbare logiske ID-er. Ikke alle item-typer støtter avhengighetsbinding gjennom logiske ID-er. Før du setter opp utrulling på tvers av arbeidsområder, bør du lese kompatibilitetstabellene i denne artikkelen for å identifisere hvilke avhengigheter som binder automatisk og hvilke som krever manuell parameterisering.

Relatert innhold

  • Last updated on