Comprendere l'associazione delle dipendenze nella distribuzione tra aree di lavoro

Quando distribuisci gli elementi Fabric tra gli spazi di lavoro (ad esempio, dallo sviluppo al test alla produzione), le dipendenze tra gli elementi possono rompersi. Alcuni elementi memorizzano riferimenti alle loro dipendenze come ID di oggetti (GUID specifici per lo spazio di lavoro), mentre altri usano ID logici (identificatori portatili cross-workspace memorizzati nel .platform file).

Gli elementi che usano ID logici nelle loro definizioni si associano correttamente all'elemento corrispondente nello spazio di lavoro di destinazione. Gli elementi che utilizzano ID oggetti rimangono puntati sullo spazio di lavoro sorgente, interrompendo la distribuzione.

Questo articolo mappa quali tipi di oggetti Fabric supportano il binding delle dipendenze tramite ID logici quando si usa l'integrazione con Git, e quali no. Per saperne di più sugli ID logici e su come gli elementi sono rappresentati nel controllo del codice sorgente, consulta Logical ID in Fabric.

Concetti chiave

  • ID logico: Un identificatore tra aree di lavoro generato automaticamente nel .platform file. Gli elementi con lo stesso ID logico sono trattati come lo stesso elemento tra gli spazi di lavoro.
  • ID oggetto: Un GUID specifico per uno spazio di lavoro che identifica un'istanza specifica. Gli ID degli oggetti non vengono mantenuti durante la distribuzione tra aree di lavoro senza intervento manuale o uso di parametri.
  • Lego delle dipendenze (Git): Quando sincronizzi un branch Git con un nuovo workspace, Fabric risolve i riferimenti alle dipendenze usando ID logici, puntando automaticamente all'elemento corretto nello workspace di destinazione.
  • Per nome o per URI: Alcuni elementi fanno riferimento alle dipendenze tramite nome visualizzato o URI piuttosto che tramite ID. Questi riferimenti potrebbero risolversi correttamente o meno, a seconda delle convenzioni di denominazione tra gli spazi di lavoro.

Come funziona l'associazione delle dipendenze

All'interno di uno spazio di lavoro, gli elementi fanno riferimento alle loro dipendenze usando gli ID degli oggetti. Quando Fabric esporta un elemento su Git, sostituisce alcuni di questi ID di oggetto con ID logici dal .platform file. Quando sincronizzi il ramo Git con un altro workspace, Fabric risolve quegli ID logici negli ID degli oggetti corretti nello workspace di destinazione. È questo che consente il corretto funzionamento dell'associazione delle dipendenze.

Tuttavia, non tutti i riferimenti alle dipendenze vengono sostituiti con ID logici durante l'esportazione. Gli elementi che mantengono gli ID degli oggetti nella loro rappresentazione Git puntano comunque allo spazio di lavoro originale dopo la sincronizzazione, e devi aggiornarli manualmente o tramite parametrizzazione.

Importante

L'associazione delle dipendenze si applica solo ai riferimenti tra elementi Fabric all'interno del medesimo spazio di lavoro. Se un elemento fa riferimento a un elemento Fabric in un altro spazio di lavoro, tale riferimento utilizza un ID oggetto e non viene associato automaticamente. Anche i riferimenti alle connessioni (connessioni di sorgenti dati, gateway) non si legano automaticamente. Usa librerie variabili con set di valori specifici per l'ambiente per gestire i riferimenti di connessione tra ambienti.

Compatibilità del binding delle dipendenze

Le tabelle seguenti mostrano se le dipendenze di ogni tipo di elemento Fabric si legano correttamente quando distribuisci tra i workspace. Attualmente, questo articolo tratta il comportamento di integrazione Git . Poiché il binding è determinato da come ogni elemento memorizza i riferimenti alle sue dipendenze nella definizione, lo stesso comportamento si applica ad altri meccanismi di distribuzione che riutilizzano tali definizioni, come pipeline di distribuzione e API di importazione (bulk).

Queste tabelle assumono che la dipendenza sia un altro elemento nello stesso spazio di lavoro dell'elemento sorgente. Un riferimento a un elemento in un altro spazio di lavoro non viene mai associato automaticamente. Rimane fissato all'ID dell'oggetto sorgente indipendentemente dal valore mostrato nella tabella.

La colonna Auto-bind in Git indica:

  • Sì: La definizione dell'elemento in Git memorizza il riferimento della dipendenza come un ID logico. Quando sincronizzi il branch con un nuovo workspace, il riferimento si lega automaticamente all'elemento corrispondente in quell'area di lavoro.
  • No: La definizione di elemento in Git memorizza il riferimento della dipendenza come ID oggetto (GUID specifico dello spazio di lavoro). Il riferimento continua a puntare allo spazio di lavoro di origine dopo la sincronizzazione. Devi aggiornarlo manualmente o parametrizzarlo per la distribuzione tra spazi di lavoro.
  • Parziale: L'elemento risolve la dipendenza per nome o URI, cosa che potrebbe funzionare se la denominazione è coerente tra gli spazi di lavoro.

Notebooks

Dipendenza Auto-binding in Git Note
Lakehouse Yes Richiede di abilitare "Lakehouse Auto-Binding in Git" nelle impostazioni del notebook. Quando abilitato, l'ID dell'oggetto viene sostituito da un ID logico in notebook-settings.json. Questa opzione è disattivata per impostazione predefinita. Per maggiori informazioni, consulta Lakehouse auto-binding su Git.
Environment Yes
Database con il mirroring No

Annotazioni

L'associazione tra Notebook e Lakehouse non è abilitata per impostazione predefinita. Devi attivare l'impostazione "Lakehouse Auto-Binding in Git" nelle impostazioni di ogni notebook. Per altre informazioni, vedere Controllo del codice sorgente e distribuzione del notebook.

Reports

Dipendenza Auto-binding in Git Note
Modello Semantico (dal rapporto Power BI) Parziale Il report fa riferimento al modello tramite un riferimento relativo byPath in definition.pbir, non un ID logico esplicito. Viene risolto correttamente quando il modello viene distribuito nella stessa posizione relativa nell'area di lavoro di destinazione, ma non si associa tramite un ID logico. Per maggiori informazioni, consulta la cartella report progetti Power BI Desktop.
Modello Semantico (dal rapporto paginato) No La stringa di connessione del report fa riferimento al modello semantico mediante un ID specifico dell'area di lavoro che non viene riscritto durante la distribuzione, quindi continua a puntare al modello di origine. Devi aggiornare questo riferimento per la distribuzione tra aree di lavoro. (I report creati in Report Builder che fanno riferimento al modello per nome potrebbero invece essere risolti in base al nome visualizzato, ossia "Parziale".)

Pipeline

Dipendenza Auto-binding in Git Note
Pipeline Yes
Notebook Yes
Flusso di dati Gen2 Yes
SQL Database Yes
Definizione di lavoro Spark No L'attività SparkJobDefinition fa riferimento alla definizione di processo Spark in base all'ID oggetto e non all'ID logico, quindi continua a puntare all'elemento di origine dopo la distribuzione. Devi parametrizzare questo valore per la distribuzione tra aree di lavoro.
Lakehouse Yes
Modello semantico No L'attività PBISemanticModelRefresh si riferisce al modello semantico tramite l'ID dell'elemento, non l'ID logico. Devi parametrizzare questo valore per la distribuzione tra aree di lavoro.
Magazzino No Il data warehouse artifactId viene risolto tramite l'ID logico e viene ricollegato, ma linkedService memorizza anche l'SQL endpoint dell'area di lavoro di origine, che non viene riscritto. Configura i parametri di endpoint per la distribuzione tra aree di lavoro.

Modelli semantici

Dipendenza Auto-binding in Git Note
Modello semantico Parziale I riferimenti a modelli concatenati o compositi utilizzano stringhe di connessione per nome.
endpoint di analisi SQL (lakehouse) No La stringa di connessione Direct Lake in TMDL expressions.tmdl contiene un URL dell'endpoint specifico per l'area di lavoro e il GUID del database. Devi sostituire questi parametri per la distribuzione tra aree di lavoro.
KQL banca dati No La stringa di connessione con un cluster URI nelle espressioni TMDL contiene valori specifici dello spazio di lavoro.
SQL database No La stringa di connessione nelle espressioni TMDL contiene valori specifici dello spazio di lavoro.
Magazzino No La connessione all'endpoint SQL analytics del warehouse utilizza un URL specifico per lo spazio di lavoro.

Case sul lago

Dipendenza Auto-binding in Git Note
Lakehouse (collegamento) Yes Le scorciatoie interne di OneLake che puntano a un altro elemento Fabric, come una casa sul lago o un magazzino, vengono memorizzate come un ID logico e riassegnate all'oggetto oggetto dello spazio di lavoro. Le scorciatoie verso fonti esterne, come Azure Data Lake Storage Gen2 o Amazon S3, puntano all'esterno di Fabric e portano invece un riferimento di connessione, quindi non sono soggette a binding logical-ID. Per l'elenco completo delle destinazioni delle scorciatoie, consulta Scorciatoie di OneLake. Per informazioni sul comportamento della distribuzione, vedi Lakehouse Git integration and deployment pipelines.

Flussi di dati (Gen2)

Di default, Dataflow Gen2 crea riferimenti assoluti agli elementi Fabric: la query memorizza l'ID dello spazio di lavoro sorgente e l'ID dell'oggetto dell'elemento, che non vengono riscritti durante il deployment. Un riferimento sorgente può invece usare un riferimento relativo: quando selezioni un elemento sotto !( Current Workspace) in un connettore Fabric, la query memorizza l'elemento per nome (senza GUID) e si risolve all'elemento corrispondente nello spazio di lavoro di destinazione durante il deployment. Le destinazioni di output usano sempre riferimenti assoluti e non ribindano. Per le destinazioni e per qualsiasi riferimento assoluto all'origine, parametrizzare i valori per la distribuzione tra aree di lavoro. Per ulteriori informazioni, vedi Referenze relative con connettori Fabric in Dataflow Gen2 e Dataflow Gen2 con integrazione CI/CD e Git.

Riferimenti fonti:

Dipendenza Auto-binding in Git Note
Lakehouse Parziale Si riassegna solo quando è scritto come riferimento relativo (!( Spazio di lavoro attuale)); Il riferimento assoluto predefinito non si riassocia.
Magazzino Parziale Si riassegna solo quando è scritto come riferimento relativo (!( Spazio di lavoro attuale)); Il riferimento assoluto predefinito non si riassocia.

Riferimenti di destinazione:

Dipendenza Auto-binding in Git Note
Lakehouse No
Magazzino No
SQL Database No

Definizioni di Job Spark

Dipendenza Auto-binding in Git Note
Environment Yes
Lakehouse No Il defaultLakehouseArtifactId usa un ID oggetto.

Operazioni di copia

Dipendenza Auto-binding in Git Note
Lakehouse Yes
Magazzino No Il data warehouse artifactId viene risolto tramite l'ID logico e ricollegato, ma linkedService archivia anche il codice SQL endPoint dell'area di lavoro di origine, che non viene riscritto. Configura i parametri di endPoint per la distribuzione tra aree di lavoro.
SQL Database Yes

API GraphQL

Dipendenza Auto-binding in Git Note
Punto di connessione SQL Yes
Magazzino Yes
SQL Database Yes

Per tutte le sorgenti dati API GraphQL, potresti dover riconfigurare la connessione e le credenziali dopo il deployment.

Flussi di eventi

Dipendenza Auto-binding in Git Note
Lakehouse Yes
Eventhouse Yes Tutte le destinazioni sono completamente supportate per CI/CD quando gli elementi sono nello stesso spazio di lavoro. Per Eventhouse con modalità Direct Ingestion, potresti dover riconfigurare manualmente la connessione dopo il deployment. Per maggiori informazioni, vedi Eventstream CI/CD.
Attivatore (Reflex) Yes Tutte le destinazioni sono completamente supportate per CI/CD quando gli elementi sono nello stesso spazio di lavoro. Per maggiori informazioni, vedi Eventstream CI/CD.

Elementi KQL

Dipendenza Auto-binding in Git Note
Database KQL a casa eventi Yes L'elemento parentEventhouseItemId in DatabaseProperties.json è un ID logico e fa riferimento all'eventhouse di destinazione. Un database KQL viene distribuito come elemento figlio del relativo eventhouse padre.
Queryset KQL nel database KQL Parziale Risolve attraverso clusterUri e databaseName, non l'ID dell'oggetto. La definizione include un databaseItemId, ma è un ID oggetto che non si riassegna, quindi la risoluzione dipende dall'URI tra gli ambienti.
Real-Time Dashboard al database KQL Parziale Utilizza un dataSources array con URI del cluster. Stesso schema del query KQL.

Magazzini

Dipendenza Auto-binding in Git Note
Magazzino (riferimento incrociato) No I riferimenti ad altri magazzini usano gli ID degli oggetti.
Punto di connessione SQL No Le referenze SQL Endpoint utilizzano identificatori specifici per lo spazio di lavoro.

Librerie di variabili

Dipendenza Auto-binding in Git Note
Elementi Fabric (tipo ItemReference) No Il ItemReference tipo variabile memorizza workspaceId e itemId come GUID grezzo. Devi aggiornare manualmente o sovrascrivere questi valori tramite i set di valori per ogni ambiente.

Elementi senza dipendenze

I seguenti elementi non presentano problemi relativi all'associazione delle dipendenze tra aree di lavoro:

  • Environment
  • SQL Database
  • Eventhouse (oggetto contenitore; I database KQL lo fanno riferimento)
  • Database Mirrored (solo configurazione sorgente esterna)

Sommario

Quando distribuisci elementi Fabric tra gli spazi di lavoro, le dipendenze tra gli elementi possono rompersi se i riferimenti vengono memorizzati come ID di oggetto specifici dello spazio invece che come ID logici portatili. Non tutti i tipi di elemento supportano il binding delle dipendenze tramite ID logici. Prima di impostare il deployment cross-workspace, consulta le tabelle di compatibilità in questo articolo per identificare quali dipendenze vengono associate automaticamente e quali richiedono una parametrizzazione manuale.

Contenuti correlati

  • Last updated on