Comprendre la liaison des dépendances dans le déploiement multi-espaces de travail

Lorsque vous déployez des éléments Fabric à travers des espaces de travail (par exemple, du développement au test puis à la production), les dépendances entre les éléments peuvent se rompre. Certains éléments stockent des références à leurs dépendances sous forme d’ID d’objet (GUID spécifiques à l’espace de travail), tandis que d’autres utilisent des identifiants logiques (identifiants portables inter-espaces de travail stockés dans le .platform fichier).

Les éléments qui utilisent des identifiants logiques dans leurs définitions se lient correctement à l’élément correspondant dans l’espace de travail cible. Les éléments qui utilisent des identifiants d’objet continuent de pointer vers l’espace de travail source, ce qui entraîne l’échec du déploiement.

Cet article mappe quels types d'éléments Fabric supportent la liaison de dépendances via des identifiants logiques lorsque vous utilisez l'intégration Git, et lesquels ne le font pas. Pour en savoir plus sur les identifiants logiques et la représentation des éléments dans le contrôle de versions, voir Identifiant logique dans Fabric.

Concepts clés

  • Identifiant logique : un identifiant inter-espaces de travail généré automatiquement dans le .platform fichier. Les éléments avec le même ID logique sont traités comme le même élément dans les espaces de travail.
  • ID d’objet : Un GUID spécifique à l’espace de travail qui identifie une instance particulière. Les ID d’objets ne survivent pas au déploiement inter-espaces sans intervention manuelle ou paramétrisation.
  • Liaison de dépendances (Git) : Lorsque vous synchronisez une branche Git vers un nouvel espace de travail, Fabric résout les références de dépendances à l’aide d’identifiants logiques, pointant automatiquement vers l’élément correct dans l’espace de travail cible.
  • Par nom ou par URI : Certains éléments font référence aux dépendances par nom d’affichage ou URI plutôt que par ID. Ces références peuvent être résolues correctement ou non, selon les conventions de nommage d’un espace de travail à l’autre.

Comment fonctionne le liage des dépendances

Dans un espace de travail, les éléments référencent leurs dépendances à l’aide d’identifiants d’objets. Lorsque Fabric exporte un élément vers Git, il remplace certains de ces identifiants d’objet par des identifiants logiques du .platform fichier. Lorsque vous synchronisez la branche Git vers un autre espace de travail, Fabric résout ces identifiants logiques vers les identifiants d’objet corrects dans l’espace de travail cible. C’est ce qui fait fonctionner la liaison des dépendances.

Cependant, toutes les références de dépendance ne sont pas remplacées par des identifiants logiques lors de l’exportation. Les éléments qui conservent les identifiants d’objet dans leur représentation Git pointent toujours vers l’espace de travail original après synchronisation, et il faut les mettre à jour manuellement ou par paramétrisation.

Important

La liaison par dépendance ne s’applique qu’aux références entre éléments Fabric au sein du même espace de travail. Si un élément fait référence à un élément Fabric dans un autre espace de travail, cette référence utilise un identifiant d'objet et ne s'associe pas automatiquement. Les références aux connexions (connexions source de données, passerelles) ne se lient pas automatiquement non plus. Utilisez des bibliothèques de variables avec des ensembles de valeurs spécifiques à l’environnement pour gérer les références de connexion entre environnements.

Compatibilité de liaison de dépendance

Les tableaux suivants montrent si les dépendances de chaque type d'élément Fabric se lient correctement lors du déploiement entre espaces de travail. Actuellement, cet article traite du comportement d’intégration Git . Parce que la liaison est déterminée par la manière dont chaque élément stocke ses références de dépendance dans sa définition, le même comportement s’applique à d’autres mécanismes de déploiement qui réutilisent ces définitions, tels que les pipelines de déploiement et les API d’importation (en masse).

Ces tables supposent que la dépendance est un autre élément dans le même espace de travail que l’élément source. Une référence à un élément dans un autre espace de travail ne se lie jamais automatiquement. Il reste épinglé à l’ID de l’objet source, quelle que soit la valeur indiquée dans le tableau.

La colonne Association automatique dans Git indique :

  • Oui : La définition de l’élément dans Git stocke la référence de dépendance comme un identifiant logique. Lorsque vous synchronisez la branche vers un nouvel espace de travail, la référence se lie automatiquement à l’élément correspondant dans cet espace de travail.
  • Non : La définition de l’élément dans Git stocke la référence de dépendance sous forme d’identifiant d’objet (GUID spécifique à l’espace de travail). La référence continue de pointer vers l’espace de travail source après la synchronisation. Il faut le mettre à jour ou le paramétrer manuellement pour le déploiement multi-espaces de travail.
  • Partiel : L’élément résout la dépendance par nom ou URI, ce qui peut fonctionner si la nommisation est cohérente entre les espaces de travail.

Notebooks

Dépendance Liaison automatique dans Git Remarques
Lakehouse Oui Cela nécessite d’activer « Lakehouse Auto-Binding in Git » dans les paramètres du carnet. Lorsqu’il est activé, l’ID de l’objet est remplacé par un ID logique dans notebook-settings.json. Ce paramètre est désactivé par défaut. Pour plus d’informations, consultez la liaison automatique de Lakehouse dans Git.
Environment Oui
Base de données mise en miroir Non

Note

La liaison Notebook vers Lakehouse n’est pas activée par défaut. Vous devez activer le paramètre « Liaison automatique du Lakehouse dans Git » dans les paramètres de chaque notebook. Pour plus d’informations, consultez Le contrôle de code source et le déploiement de Notebook.

Rapports

Dépendance Liaison automatique dans Git Remarques
Modèle sémantique (extrait du rapport Power BI) Partiel Le rapport fait référence au modèle par une référence relative byPath dans definition.pbir, et non par un identifiant logique explicite. Il se résout correctement lorsque le modèle est déployé au même emplacement relatif dans l’espace de travail cible, mais ne se lie pas via un identifiant logique. Pour plus d’informations, consultez le dossier de rapports des projets Power BI Desktop.
Modèle sémantique (d’après rapport paginat) Non La chaîne de connexion du rapport fait référence au modèle sémantique par un identifiant spécifique à l'espace de travail qui n'est pas réécrit lors du déploiement, donc il reste pointé vers le modèle source. Vous devez mettre à jour cette référence pour le déploiement inter-espaces de travail. (Les rapports créés dans Report Builder qui font référence au modèle par son nom peuvent à la place être résolus en utilisant le nom d’affichage, qui est « Partial ».)

Pipeline

Dépendance Liaison automatique dans Git Remarques
Pipeline Oui
Notebook Oui
Dataflow Gen2 Oui
SQL Database Oui
Définition de la tâche Spark Non L’activité SparkJobDefinition fait référence à la Définition de Travail Spark par l’ID de l’objet, et non par l’ID logique, donc elle reste pointée vers l’élément source après le déploiement. Vous devez paramétrer cette valeur pour le déploiement multi-espaces de travail.
Lakehouse Oui
Modèle sémantique Non L’activité PBISemanticModelRefresh fait référence au modèle sémantique par l’ID de l’élément, et non par l’ID logique. Vous devez paramétrer cette valeur pour le déploiement multi-espaces de travail.
Entrepôt Non L’entrepôt artifactId se résout à l’aide de l’identifiant logique et se relie à nouveau, mais linkedService stocke également le SQL endpoint de l’espace de travail source, qui n’est pas réécrit. Paramétrez le endpoint pour le déploiement inter-espaces de travail.

Modèles sémantiques

Dépendance Liaison automatique dans Git Remarques
Modèle sémantique Partiel Les références de modèles en chaîne ou composites utilisent des chaînes de connexion nommées.
SQL Analytics Endpoint (lakehouse) Non La chaîne de connexion Direct Lake dans TMDL expressions.tmdl contient une URL de terminaison spécifique à chaque espace de travail et un GUID de base de données. Vous devez remplacer ces paramètres pour le déploiement entre espaces de travail.
Base de données KQL Non La chaîne de connexion contenant un URI de cluster dans les expressions TMDL contient des valeurs spécifiques à l’espace de travail.
SQL database Non La chaîne de connexion dans les expressions TMDL contient des valeurs spécifiques à chaque espace de travail.
Entrepôt Non La connexion au point de terminaison SQL Analytics de l’entrepôt utilise une URL spécifique à chaque espace de travail.

Maisons au bord du lac

Dépendance Liaison automatique dans Git Remarques
Lakehouse (raccourci) Oui Les raccourcis internes OneLake qui pointent vers un autre élément Fabric, comme un lakehouse ou un entrepôt, sont stockés sous la forme d’un ID logique et sont de nouveau associés à l’élément de l’espace de travail cible. Les raccourcis vers des sources externes, comme Azure Data Lake Storage Gen2 ou Amazon S3, pointent vers l'extérieur de Fabric et transportent une référence de connexion à la place, ils ne sont donc pas soumis à la liaison logique-ID. Pour la liste complète des cibles de raccourcis, voir les raccourcis OneLake. Pour le comportement de déploiement, voir l’intégration et les pipelines de déploiement de Lakehouse Git.

Flux de données (Gen2)

Par défaut, Dataflow Gen2 crée des références absolues aux éléments Fabric : la requête stocke l'ID de l'espace de travail source et l'ID de l'objet de l'élément, qui ne sont pas réécrits lors du déploiement. Une référence source peut utiliser à la place une référence relative : lorsque vous sélectionnez un élément sous le nœud !(Espace de travail actuel) dans un connecteur Fabric, la requête enregistre l’élément par son nom (sans GUID) et il est résolu en l’élément correspondant dans l’espace de travail cible lors du déploiement. Les destinations de sortie utilisent toujours des références absolues et ne se relient pas. Pour les destinations et pour toute référence absolue à la source, paramétrez les valeurs pour le déploiement entre espaces de travail. Pour plus d’informations, voir Références relatives avec des connecteurs Fabric dans Dataflow Gen2 et Dataflow Gen2 avec intégration CI/CD et Git.

Références source:

Dépendance Liaison automatique dans Git Remarques
Lakehouse Partiel Ne se relie que lorsqu’elle est rédigée sous forme de référence relative (!(Current Workspace)) ; la référence absolue par défaut ne se relie pas.
Entrepôt Partiel Ne se relie que lorsqu’elle est rédigée sous forme de référence relative (!(Current Workspace)) ; la référence absolue par défaut ne se relie pas.

Références de destination :

Dépendance Liaison automatique dans Git Remarques
Lakehouse Non
Entrepôt Non
SQL Database Non

Définitions de travaux Spark

Dépendance Liaison automatique dans Git Remarques
Environment Oui
Lakehouse Non Le defaultLakehouseArtifactId utilise un ID d'objet.

Tâches de copie

Dépendance Liaison automatique dans Git Remarques
Lakehouse Oui
Entrepôt Non L’entrepôt artifactId se résout à l’aide de l’identifiant logique et se relie à nouveau, mais linkedService stocke également le SQL endPoint de l’espace de travail source, qui n’est pas réécrit. Paramétrez le endPoint pour le déploiement inter-espaces de travail.
SQL Database Oui

API GraphQL

Dépendance Liaison automatique dans Git Remarques
Point de terminaison SQL Oui
Entrepôt Oui
SQL Database Oui

Pour toutes les sources de données de l’API GraphQL, il se peut que vous deviez reconfigurer la connexion et les identifiants après le déploiement.

Flux d’événements

Dépendance Liaison automatique dans Git Remarques
Lakehouse Oui
Eventhouse Oui Toutes les destinations sont entièrement prises en charge pour CI/CD lorsque les éléments se trouvent dans le même espace de travail. Pour Eventhouse avec mode Ingestion Directe, il se peut que vous deviez reconfigurer manuellement la connexion après le déploiement. Pour plus d’informations, voir Eventstream CI/CD.
Déclencheur (Reflex) Oui Toutes les destinations sont entièrement prises en charge pour CI/CD lorsque les éléments se trouvent dans le même espace de travail. Pour plus d’informations, voir Eventstream CI/CD.

Éléments KQL

Dépendance Liaison automatique dans Git Remarques
De la base de données KQL à Eventhouse Oui Le parentEventhouseItemId dans DatabaseProperties.json est un identifiant logique et est associé à l’Eventhouse cible. Une base de données KQL est déployée en tant qu’enfant de sa maison d’événements mère.
Requête KQL vers la base de données KQL Partiel Résout à travers clusterUri et databaseName, pas l’ID de l’objet. La définition inclut un databaseItemId, mais c’est un ID d’objet qui ne se relie pas, donc la résolution dépend de l’URI selon les environnements.
Tableau de bord en temps réel vers la base de données KQL Partiel Utilise un tableau dataSources avec des URI de cluster. Même schéma que le query set KQL.

Entrepôts

Dépendance Liaison automatique dans Git Remarques
Entrepôt (référence croisée) Non Les références à d’autres entrepôts utilisent des identifiants d’objet.
Point de terminaison SQL Non Les références SQL Endpoint utilisent des identifiants spécifiques à chaque espace de travail.

Bibliothèques de variables

Dépendance Liaison automatique dans Git Remarques
Éléments Fabric (de type ItemReference) Non Le ItemReference type de variable stocke workspaceId et itemId sous forme de GUID brut. Vous devez mettre à jour ou remplacer manuellement ces valeurs via les ensembles de valeurs par environnement.

Éléments sans dépendances

Les éléments suivants ne présentent aucune question de liaison de dépendance entre espaces de travail :

  • Environment
  • SQL Database
  • Salle d’événements (article en conteneur ; Les bases de données KQL y font référence)
  • Base de données miroir (configuration source externe uniquement)

Résumé

Lorsque vous déployez des éléments Fabric à travers des espaces de travail, les dépendances entre éléments peuvent se rompre si les références sont stockées sous forme d’identifiants d’objets spécifiques à chaque espace de travail au lieu d’identifiants logiques portables. Tous les types d’éléments ne supportent pas la liaison de dépendances via des identifiants logiques. Avant de configurer un déploiement multi-espaces de travail, consultez les tables de compatibilité de cet article pour identifier quelles dépendances se lient automatiquement et lesquelles nécessitent une paramétrisation manuelle.

Contenu connexe

  • Last updated on