Références de variables dans un dataflow

Note

Cet article se concentre sur une architecture de solution à partir des architectures de solution CI/CD et ALM (Gestion du cycle de vie des applications) pour Dataflow Gen2 qui s’appuie sur l’intégration des bibliothèques de variables et s’applique uniquement à la prise en charge CI/CD.

Les bibliothèques de variables fabric dans Dataflow Gen2 permettent une gestion centralisée et réutilisable de la configuration dans les environnements. En référençant des variables directement dans vos scripts de flux de données, vous pouvez ajuster dynamiquement le comportement sans valeurs de codage en dur, ce qui est idéal pour les flux de travail CI/CD. Cette intégration simplifie le déploiement par étapes en autorisant les valeurs spécifiques à l’espace de travail (comme Lakehouse ou les ID d’espace de travail) à injecter au moment de l’exécution, ce qui rend vos dataflows plus adaptables et plus faciles à gérer.

Ce tutoriel vous guide tout au long d’un exemple de solution qui utilise des références de variables dans un dataflow et vous montre comment :

• Définir des variables : utilisation des bibliothèques de variables Fabric et de leurs types de données distincts
• Source pilotée par variable : utilisation d’un Lakehouse avec l’exemple de jeu de données WideWorldImpoters comme source
• Logique basée sur des variables : utilisation des widgets d’entrée disponibles tout au long de l’expérience dataflow
• Destination pilotée par des variables : utilisation d’un entrepôt en tant que destination

Note

Les concepts présentés dans cet article sont universels pour Dataflow Gen2 et s’appliquent à d’autres sources et destinations au-delà de celles présentées ici.

Scénario

Le flux de données utilisé dans ce scénario est simple, mais les principes fondamentaux décrits s’appliquent à tous les types de dataflows. Il se connecte à la table nommée dimension_city à partir de l’exemple de jeu de données Wide World Importers stocké dans un Lakehouse. Il filtre les lignes où la colonne SalesTerritory est égale au Sud-Est et charge le résultat dans une nouvelle table appelée City in a Warehouse. Tous les composants ( Lakehouse, Warehouse et Dataflow) se trouvent dans le même espace de travail. Pour rendre le flux de données dynamique, vous utilisez des variables pour piloter la table source, la valeur de filtre et la table de destination. Ces modifications permettent à l’exécution du flux de données avec des valeurs stockées dans des bibliothèques de variables Fabric au lieu de celles codées en dur.

Définition des variables

Note

Veillez à activer les bibliothèques de variables Fabric pour votre organisation ou groupe de sécurité. Apprenez-en davantage sur la prise en main des bibliothèques de variables.

En guise de meilleure pratique, il est toujours recommandé d’avoir une conception à l’esprit avant de créer une solution et quels composants de votre dataflow sont générés dynamiquement à partir d’une bibliothèque de variables. Bien que vous puissiez créer plusieurs bibliothèques dans un espace de travail, cet exemple utilise une bibliothèque unique nommée My Library qui contient les variables utilisées par Dataflow Gen2 :

Nom de la variable	Type	Objectif
WorkspaceId	GUID	Utilisé pour les scripts de source de données et de destination dans le dataflow
LakehouseId	GUID	Détermine l’ID de la Lakehouse utilisée comme source
WarehouseId	GUID	Détermine l’ID de l’entrepôt utilisé comme destination
Territoire	Chaîne	Définit la valeur à utiliser pour piloter la logique de filtre dans le dataflow

Veillez à définir les valeurs par défaut qui correspondent à votre propre environnement, puis enregistrez la bibliothèque de variables.

Source pilotée par des variables

Lorsque vous utilisez l’un des connecteurs Fabric, tels que Lakehouse, Warehouse ou Fabric SQL, ils suivent toutes la même structure de navigation et utilisent le même format d’entrée. Dans ce scénario, aucun des connecteurs n’a besoin d’une entrée manuelle pour établir une connexion. Toutefois, chacun affiche l’espace de travail et l’élément auquel il se connecte via les étapes de navigation de votre requête. Par exemple, la première étape de navigation inclut l’id d’espace de travail auquel la requête se connecte.

L’objectif est de remplacer les valeurs codées en dur dans la barre de formule par des variables. Plus précisément, vous souhaitez utiliser les variables WorkspaceId et LakehouseId pour piloter cette logique. Tout d’abord, vous devez importer ces variables dans Dataflow Gen2. Une approche recommandée consiste à créer des requêtes pour chaque variable distincte afin de centraliser et de gérer facilement toutes les variables que vous envisagez d’utiliser. Pour ce faire, créez une requête vide en accédant à l’entrée Obtenir des données dans le ruban et en sélectionnant l’option Requête vide dans le menu déroulant.

La sélection de cette option permet d’afficher une nouvelle boîte de dialogue dans laquelle vous pouvez voir la requête vide créée. Vous pouvez sélectionner OK pour apporter cette nouvelle requête vide.

Une fois que votre requête a été créée et apparaît dans le flux de données, renommez-la en WorkspaceId et remplacez la formule de l’étape source comme suit :

Variable.ValueOrDefault("$(/**/My Library/WorkspaceId)", "Your Workspace ID")

Ce script est fondamentalement celui qui est en mesure de déterminer la bibliothèque et la variable à extraire. Le deuxième argument de la Variable.ValueOrDefault fonction détermine la valeur à fournir lorsqu’une variable ne peut pas être extraite.

Note

Veillez à remplacer la chaîne « Votre ID d’espace de travail », le deuxième argument de la fonction, par votre propre valeur correspondante dans votre environnement et enregistrez la requête.

Répétez ce processus pour la variable LakehouseId et créez une requête portant le même nom que la variable, mais utilisez la formule suivante pour l’étape Source :

Variable.ValueOrDefault("$(/**/My Library/LakehouseId)", "Your Lakehouse ID")

Note

Veillez à remplacer la chaîne « Your Lakehouse ID », le deuxième argument de la fonction, par votre propre valeur correspondante dans votre environnement et enregistrez la requête.

Une fois les deux requêtes créées, vous pouvez mettre à jour le script de requête pour les utiliser au lieu de valeurs codées en dur. Cela implique de remplacer manuellement les valeurs d’origine dans la barre de formule par des références aux requêtes WorkspaceId et LakehouseId. Le script de requête d’origine ressemble à ceci :

let
  Source = Lakehouse.Contents([]),
  #"Navigation 1" = Source{[workspaceId = "8b325b2b-ad69-4103-93ae-d6880d9f87c6"]}[Data],
  #"Navigation 2" = #"Navigation 1"{[lakehouseId = "2455f240-7345-4c8b-8524-c1abbf107d07"]}[Data],
  #"Navigation 3" = #"Navigation 2"{[Id = "dimension_city", ItemKind = "Table"]}[Data],
  #"Filtered rows" = Table.SelectRows(#"Navigation 3", each ([SalesTerritory] = "Southeast")),
  #"Removed columns" = Table.RemoveColumns(#"Filtered rows", {"ValidFrom", "ValidTo", "LineageKey"})
in
  #"Removed columns"

Une fois que vous avez mis à jour les références dans les étapes de navigation, votre nouveau script mis à jour peut ressembler à ceci :

let
  Source = Lakehouse.Contents([]),
  #"Navigation 1" = Source{[workspaceId = WorkspaceId]}[Data],
  #"Navigation 2" = #"Navigation 1"{[lakehouseId = LakehouseId]}[Data],
  #"Navigation 3" = #"Navigation 2"{[Id = "dimension_city", ItemKind = "Table"]}[Data],
  #"Filtered rows" = Table.SelectRows(#"Navigation 3", each ([SalesTerritory] = "Southeast")),
  #"Removed columns" = Table.RemoveColumns(#"Filtered rows", {"ValidFrom", "ValidTo", "LineageKey"})
in
  #"Removed columns"

Vous remarquerez également qu’il évalue toujours correctement l’aperçu des données dans l’éditeur dataflow avec les références directes créées dans la vue diagramme entre toutes les requêtes impliquées :

Logique pilotée par des variables

Maintenant que la source utilise des variables, vous pouvez vous concentrer sur la modification de la logique de transformation du flux de données. Dans ce scénario, l’étape de filtre est l’emplacement où la logique est appliquée et la valeur filtrée, actuellement codée en dur comme Sud-Est, doit être remplacée par une requête qui fait référence à une variable. Pour ce faire, vous répétez le même processus de création d’une requête vide et réaffectez la formule de son étape source pour contenir la variable pour Territory et remplacez également le nom de la requête par le nom de la variable. Utilisez le script suivant :

Variable.ValueOrDefault("$(/**/My Library/Territory)", "Mideast")

Étant donné que votre étape de filtre a été créée à l’aide de l’interface utilisateur, vous pouvez passer à l’étape des lignes filtrées, double-cliquez sur elle pour ouvrir la boîte de dialogue des paramètres de l'étape de filtre. Cette boîte de dialogue vous permet de sélectionner, via le widget d’entrée, si vous souhaitez utiliser une requête au lieu d’une valeur statique :

Après avoir sélectionné l’option Sélectionner une requête, une liste déroulante s’affiche pour afficher toutes les requêtes parmi lesquelles vous pouvez choisir. Dans cette liste, vous pouvez sélectionner la requête Territory nouvellement créée.

Une fois que vous avez sélectionné OK, notez que la vue de diagramme a déjà créé le lien entre la requête Territory et la requête en cours d’utilisation. L’aperçu des données affiche maintenant des informations pour le territoire du Moyen-Orient, non seulement cela.

Destination pilotée par des variables

Note

Il est recommandé de vous familiariser avec le concept de destinations de données dans Dataflow Gen2 et la façon dont son script mashup est créé à partir de l’article sur les destinations de données et les paramètres managés

Le dernier composant à modifier dans ce scénario est la destination. Bien que les informations sur la destination des données soient disponibles dans l’éditeur dataflow, pour modifier cette partie du flux de données, vous devez utiliser Git ou l’API REST.

Ce tutoriel vous montre comment apporter les modifications via Git. Avant de pouvoir apporter des modifications via Git, veillez à :

• Créez une requête pour la variable WarehouseId : suivez le même processus décrit dans les sections précédentes pour créer une requête vide et remplacer la formule de l’étape Source :

Variable.ValueOrDefault("$(/**/My Library/WarehouseId)", "Your Warehouse ID")

Note

Veillez à remplacer la chaîne « Votre ID d’entrepôt », le deuxième argument de la fonction, par votre propre valeur correspondante dans votre environnement et enregistrez la requête.

Important

Assurez-vous que toutes vos requêtes avec une variable ont le staging désactivé.

• Enregistrez le flux de données : utilisez le bouton Enregistrer sous l’onglet Accueil du ruban.

Une fois votre dataflow enregistré, veillez à valider les modifications apportées à votre dépôt Git et à accéder à votre dépôt pour afficher le fichier mashup.pq de votre dataflow. Lorsque vous examinez le fichier mashup.pq , recherchez la requête avec laquelle vous avez associé la destination des données. Dans ce scénario, le nom de cette requête est dimension_city. Vous voyez un attribut d’enregistrement au-dessus de ce nom de requête :

[DataDestinations = {[Definition = [Kind = "Reference", QueryName = "dimension_city_DataDestination", IsNewTarget = true], Settings = [Kind = "Manual", AllowCreation = true, ColumnSettings = [Mappings = {[SourceColumnName = "CityKey", DestinationColumnName = "CityKey"], [SourceColumnName = "WWICityID", DestinationColumnName = "WWICityID"], [SourceColumnName = "City", DestinationColumnName = "City"], [SourceColumnName = "StateProvince", DestinationColumnName = "StateProvince"], [SourceColumnName = "Country", DestinationColumnName = "Country"], [SourceColumnName = "Continent", DestinationColumnName = "Continent"], [SourceColumnName = "SalesTerritory", DestinationColumnName = "SalesTerritory"], [SourceColumnName = "Region", DestinationColumnName = "Region"], [SourceColumnName = "Subregion", DestinationColumnName = "Subregion"], [SourceColumnName = "Location", DestinationColumnName = "Location"], [SourceColumnName = "LatestRecordedPopulation", DestinationColumnName = "LatestRecordedPopulation"]}], DynamicSchema = false, UpdateMethod = [Kind = "Replace"], TypeSettings = [Kind = "Table"]]]}]
shared dimension_city = let

Cet enregistrement d’attribut a un champ portant le nom QueryName, qui contient le nom de la requête qui a toutes les logiques de destination de données associées à cette requête. Cette requête se présente comme suit :

shared dimension_city_DataDestination = let
  Pattern = Fabric.Warehouse([HierarchicalNavigation = null, CreateNavigationProperties = false]),
  Navigation_1 = Pattern{[workspaceId = "8b325b2b-ad69-4103-93ae-d6880d9f87c6"]}[Data],
  Navigation_2 = Navigation_1{[warehouseId = "527ba9c1-4077-433f-a491-9ef370e9230a"]}[Data],
  TableNavigation = Navigation_2{[Item = "City", Schema = "dbo"]}?[Data]?
in
  TableNavigation

Vous remarquez que, de la même façon que le script de la source pour Lakehouse, ce script pour la destination a un modèle similaire où il code en dur le workspaceid qui doit être utilisé et également le warehouseId. Remplacez ces valeurs fixes par les identificateurs des requêtes que vous avez créées et votre script doit se présenter comme suit :

shared dimension_city_DataDestination = let
  Pattern = Fabric.Warehouse([HierarchicalNavigation = null, CreateNavigationProperties = false]),
  Navigation_1 = Pattern{[workspaceId = WorkspaceId]}[Data],
  Navigation_2 = Navigation_1{[warehouseId = WarehouseId]}[Data],
  TableNavigation = Navigation_2{[Item = "City", Schema = "dbo"]}?[Data]?
in
  TableNavigation

Vous pouvez maintenant valider cette modification et mettre à jour votre flux de données à l’aide des modifications de votre flux de données via la fonctionnalité de contrôle de code source dans votre espace de travail.

Vous pouvez maintenant exécuter votre dataflow, qui utilise des valeurs à partir de bibliothèques de variables.