Résoudre les problèmes de gestion du cycle de vie
Utilisez cet article pour résoudre les problèmes liés au processus de gestion du cycle de vie.
Pour comprendre les considérations et les limitations des différents problèmes de gestion du cycle de vie, consultez les liens du tableau suivant :
| Rubrique | Intégration Git | Pipelines de déploiement |
|---|---|---|
| Limitations générales | Limitations git générales | Limitations des pipelines de déploiement |
| Autorisations nécessaires | autorisations | autorisations |
| Limitations de l’espace de travail | workspaces | workspaces |
| Éléments Fabric pris en charge | Éléments pris en charge | Éléments pris en charge |
| Modèle sémantique | Limitations du modèle sémantique |
Intégration Git
Problèmes liés à l’accès
Je ne peux pas accéder à mon dépôt Azure DevOps
Description du problème : lorsque je vais à l’onglet d’intégration Git, je reçois un message d’erreur et je ne peux pas accéder à Azure DevOps.
Cause : si la méthode d’authentification dans Power BI est plus faible que la méthode d’authentification dans Azure DevOps, les fonctionnalités entre elles ne fonctionnent pas.
Solution de contournement : l’administrateur doit aligner la méthode d’authentification dans Power BI et Azure DevOps. Les stratégies d’authentification pour Microsoft Entra ID (anciennement Azure Active Directory) sont définies dans Gérer les méthodes d’authentification.
Problèmes de connexion
Échec de la connexion : impossible de se connecter au référentiel
Description du problème : lorsque je tente de me connecter à un référentiel git, je reçois un message indiquant qu’il ne peut pas se connecter, car l’espace de travail se trouve dans une autre région.
Cause : si l’espace de travail et le référentiel se trouvent dans des régions différentes, le commutateur interrégion doit être activé.
Solution : activez les actions Git sur les espaces de travail résidant dans d’autres emplacements géographiques.
Échec de la connexion : un message d’erreur s’affiche lorsque j’essaie de me connecter
Description du problème : après avoir sélectionné Se connecter dans l’onglet d’intégration Git, la boîte de dialogue Une erreur s’est produite s’affiche. En outre, lorsque vous sélectionnez le bouton de contrôle de code source, le volet indique que vous devez effectuer une synchronisation avec la branche Git.
Cause : si le dossier auquel vous essayez de vous connecter a des sous-répertoires, mais aucun élément Fabric, la connexion échoue.
Solution : ouvrez le référentiel Git dans Azure DevOps et accédez au dossier Git défini dans la connexion. Si le dossier Git contient des sous-répertoires, vérifiez qu’au moins l’un d’entre eux représente un répertoire d’éléments. Si le répertoire contient les fichiers item.config.json et item.metadata.json, il s’agit d’un répertoire d’éléments. Si le répertoire ne contient pas ces fichiers, il s’agit d’un sous-répertoire. Si le dossier Git ne contient pas de répertoires d’éléments, vous ne pouvez pas vous y connecter. Supprimez les sous-répertoires ou connectez-vous à un autre dossier qui ne contient pas de sous-répertoires.
Échec de la connexion : il me demande si je souhaite créer un dossier lorsque j’essaie de me connecter à une branche Git
Description du problème : après avoir sélectionné Se connecter dans l’onglet d’intégration Git, une boîte de dialogue s’affiche indiquant que le chemin d’accès au dossier n’est pas valide.
Cause : le dossier que vous essayez de connecter n’existe pas, a été supprimé ou diffère en ce qui concerne la casse des dossiers existants dans le référentiel. Ce message peut s’afficher si vous vous connectez à une nouvelle branche ou si le dossier a été supprimé de la branche.
Solution:
- Pour créer un dossier et le connecter à l’espace de travail, sélectionnez Créer et synchroniser.
- Pour connecter l’espace de travail à un autre dossier, sélectionnez Annuler et choisissez un autre dossier dans les paramètres de l’espace de travail de l’onglet d’intégration Git.
L’icône de contrôle de code source n’a pas de numéro
Description du problème : le numéro sur l’icône Contrôle de code source indique le nombre de modifications apportées à l’espace de travail depuis la dernière validation. Si l’icône n’a pas de numéro, il se peut qu’il y ait eu un problème de connexion à la branche.
Solution : déconnectez-vous et reconnectez-vous.
Échec de connexion : Une licence Premium est demandée pour me connecter à Git
Description du problème : Mon espace de travail était précédemment connecté à un référentiel Git, mais une licence Premium m’est maintenant demandée pour me connecter.
Cause : Vous ne pouvez vous connecter au référentiel Git que si vous disposez d’une licence Premium valide. Si votre licence a expiré ou si vous la modifiez en une licence sans intégration Git, vous ne pourrez plus vous connecter à ce référentiel. Cela concerne également les licences d’évaluation.
Solution : Déconnectez-vous de Git et travaillez sans contrôle de code source, sinon achetez une licence Premium.
Problèmes de validation
Le bouton Valider est désactivé
Description du problème : si des mises à jour ont été apportées à la branche Git, les validations sont désactivées jusqu’à ce que vous mettiez à jour votre espace de travail.
Solution : mettez à jour votre espace de travail pour activer les validations.
Problèmes de mise à jour
Les boutons Valider et Mettre à jour sont tous deux désactivés
Description du problème : la modification du même élément dans l’espace de travail et la branche Git peut entraîner un conflit. Si des modifications ont été apportées dans l’espace de travail et dans la branche Git sur le même élément, les mises à jour sont désactivées jusqu’à ce que le conflit soit résolu.
Solution : résolvez les conflits, puis réessayez.
Échec de la mise à jour : la mise à jour ne se termine pas, car elle interrompt les liens de dépendance
Description du problème : après avoir sélectionné Tout mettre à jour ou Annuler, une boîte de dialogue s’affiche indiquant l’échec, car l’action rompt un lien de dépendance.
Solution : ouvrez la vue de traçabilité pour rechercher le ou les éléments qui seraient supprimés de l’espace de travail dans la mise à jour et qui seraient liés à des éléments qui ne seront pas supprimés de l’espace de travail.
Pour résoudre le problème, supprimez le ou les éléments problématiques :
- Si l’élément n’est pas pris en charge par Git (par exemple, les tableaux de bord), supprimez-le manuellement de l’espace de travail.
- Si l’élément est pris en charge par Git (par exemple, les rapports), supprimez-le de Git (s’il existe) ou de l’espace de travail.
Sélectionnez Tout mettre à jour.
Pour plus d’informations, consultez Mise à jour manuelle à partir de Git.
Échec post-mise à jour : les dépendances ne pointent pas vers les éléments corrects
Description du problème : après la mise à jour à partir de Git, lorsque vous examinez la vue de traçabilité, les dépendances de certains éléments ne sont pas comme prévu. Par exemple, le modèle proxy ne pointe plus vers le modèle correct.
Motif : l’intégration de git ne prend pas en charge les modèles Direct Query et proxy pour l’instant.
Solution : pour corriger les dépendances, effectuez l’une des actions suivantes :
- Modifiez le fichier bim de ProxyDataset dans le référentiel Git afin qu’il pointe vers le jeu de données correct, puis, dans l’espace de travail, mettez à jour à partir de Git pour recevoir la modification.
- Utilisez l’API Mettre à jour la source de données pour mettre à jour les détails de connexion du modèle proxy dans l’espace de travail.
Résoudre les problèmes
Problèmes d’annulation
Échec d’annulation : après avoir sélectionné Annuler, une boîte de dialogue s’affiche pour indiquer l’échec, car la dépendance est introuvable.
Description du problème : l’erreur suivante s’affiche après une action d’annulation si une dépendance non validée dans l’onglet Modifications n’a pas été sélectionnée dans l’action Annuler.
Solution : sélectionnez toutes les dépendances de la base de données sélectionnée, puis réessayez.
Erreur de dépendance : après avoir sélectionné « Annuler », « Mettre à jour » ou « Changer de branche », une boîte de dialogue s’affiche pour indiquer un échec, car l’action interrompt un lien de dépendance
Description du problème : l’erreur suivante s’affiche après une annulation, une mise à jour ou un changement de branche :
Cause : un élément non pris en charge dans l’espace de travail dépend d’un élément qui n’est plus dans l’espace de travail, ce qui provoque un problème de dépendance.
Solution : ouvrez la vue de traçabilité pour rechercher le ou les éléments qui ont été sélectionnés pour être « annulés » et qui sont liés à des éléments qui ne sont pas sélectionnés.
Pour résoudre le problème, supprimez le ou les éléments problématiques :
- Si l’élément qui n’est pas sélectionné est pris en charge par Git (par exemple, les rapports), sélectionnez-le également pour qu’il soit supprimé.
- Si l’élément qui n’est pas sélectionné n’est pas pris en charge par Git (par exemple, Tableaux de bord), supprimez-le manuellement de l’espace de travail.
Pour en savoir plus sur les dépendances, consultez Comprendre les dépendances.
Pipelines de déploiement
Je ne vois pas le bouton Pipelines de déploiement
Si les conditions suivantes ne sont pas remplies, vous ne pouvez pas voir le bouton Pipelines de déploiement.
Vous disposez d’une licence Fabric.
Vous êtes administrateur d’un espace de travail.
La balise de phase de pipeline n’apparaît pas dans mon espace de travail
Les pipelines de déploiement présentent une balise de phase de pipeline dans les espaces de travail qui leur sont affectés. Pour afficher ces balises, vous devez être administrateur de pipeline. Les balises pour les phases de développement et de test sont toujours visibles. Toutefois, la balise Production n’apparaît que si vous avez accès au pipeline.
Connexions perdues après le déploiement
Description du problème : dans un pipeline complet, quand vous désattribuez un espace de travail d’une phase, puis effectuez un déploiement sur cette phase, les pipelines de déploiement rétablissent les connexions entre les éléments de la phase source à partir de laquelle vous avez effectué le déploiement et ceux de la phase cible. Cependant, parfois, les pipelines de déploiement ne peuvent pas rétablir les connexions entre les éléments des phases source et cible. Cela peut se produire, par exemple, quand vous supprimez accidentellement un élément.
Solution : pour rétablir ces connexions, désattribuez et réattribuez le même espace de travail à la phase cible.
Je ne peux pas attribuer un espace de travail à une phase
Cause : quand vous attribuez un espace de travail à une phase des pipelines de déploiement, ils vérifient les éléments (tels que les rapports et les tableaux de bord) dans l’espace de travail. S’il existe deux éléments du même type avec le même nom dans une phase adjacente, les pipelines de déploiement ne peuvent pas déterminer celui qui doit correspondre à celui de l’espace de travail attribué et le message d’erreur Impossible d’attribuer l’espace de travail. Par exemple, si vous essayez d’attribuer un espace de travail à la phase de test et que l’un de vos rapports est nommé « ventes régionales », si vous avez plusieurs rapports portant le même nom dans la phase de développement ou de production, l’attribution échoue. L’attribution de votre espace de travail échoue également si l’espace de travail que vous attribuez a deux modèles sémantiques nommés « modèles sémantiques de ventes régionales » et qu’il existe un modèle sémantique portant le même nom dans la phase de développement ou de production.
Solution : pour corriger cette erreur, modifiez le nom de l’élément qui ne correspond pas à l’élément de la phase que vous essayez d’attribuer. Vous pouvez sélectionner les liens fournis dans le message d’erreur pour ouvrir les éléments dans Fabric.
Je vois le symbole « différent » après avoir affecté un espace de travail avec des modèles sémantiques similaires aux modèles sémantiques dans les étapes adjacentes
Cause : la plupart des modèles sémantiques utilisent la fonctionnalité de métadonnées de modèle sémantique améliorée, également appelée modèle v3. Toutefois, les rapports plus anciens peuvent utiliser l’ancien type de métadonnées de modèle sémantique, parfois appelé modèle v1. Si vous affectez un espace de travail qui utilise l’ancien modèle de métadonnées de modèle sémantique (v1), les pipelines de déploiement ne peuvent pas évaluer si le modèle sémantique est similaire aux étapes adjacentes. Dans ce cas, le symbole d’IU différent est affiché, même lorsque les modèles sémantiques sont identiques.
Solution : pour résoudre ce problème, déployez les modèles sémantiques qui présentent le symbole différent.
Je ne vois pas tous mes espaces de travail lorsque j’essaie d’attribuer un espace de travail à un pipeline
Cause : il peut y avoir plusieurs raisons pour lesquelles vous ne pouvez pas voir un espace de travail dans la liste des espaces de travail que vous pouvez attribuer à un pipeline.
Solution : pour attribuer un espace de travail à un pipeline, les conditions suivantes doivent être remplies :
Vous êtes administrateur de l’espace de travail
L’espace de travail n’est affecté à aucun autre pipeline
L’espace de travail se trouve sur une capacité Fabric
Les espaces de travail qui ne respectent pas ces conditions ne sont pas affichés dans la liste des espaces de travail que vous pouvez sélectionner.
Mon premier déploiement a échoué
Cause : votre premier déploiement a peut-être échoué pour plusieurs raisons.
Solution : certaines raisons possibles de l’échec et leurs solutions sont répertoriées dans le tableau suivant.
| Erreur | Action |
|---|---|
| Vous n’avez pas d’autorisations de capacité. | Si vous travaillez dans une organisation qui dispose d’une capacité Fabric, demandez à un administrateur de capacité d’ajouter votre espace de travail à une capacité ou demandez l’attribution d’autorisations pour la capacité. Quand l’espace de travail est dans une capacité, redéployez-le.Si vous ne travaillez pas dans une organisation dotée d’une capacité Fabric, envisagez l’achat de Premium par utilisateur (PPU). |
| Vous n’avez pas les autorisations d’espace de travail. | Vous devez être membre de l’espace de travail pour pouvoir effectuer le déploiement. Demandez à votre administrateur d’espace de travail de vous accorder les autorisations appropriées. |
| Votre administrateur Fabric a désactivé la création d’espaces de travail. | Contactez votre administrateur Fabric pour obtenir de l’aide. |
| Vous utilisez le déploiement sélectif et vous ne sélectionnez pas tous les éléments liés. | Effectuez l’une des opérations suivantes : désélectionnez le contenu lié à votre modèle sémantique ou flux de données. Votre contenu non sélectionné (par exemple, les modèles sémantiques, les rapports ou les tableaux de bord) ne sera pas copié à l’étape suivante. Sélectionnez le modèle sémantique ou le flux de données lié aux éléments sélectionnés. Vos éléments sélectionnés seront copiés à la phase suivante. |
Mon espace de travail présente des « éléments non pris en charge » lors d’une tentative de déploiement
Cause : les pipelines de déploiement ne prennent pas tous les éléments en charge.
Solution : pour obtenir la liste complète des éléments pris en charge dans les pipelines de déploiement, consultez les sections suivantes :
Tout élément non répertorié dans la liste des éléments pris en charge n’est pas copié à la phase suivante.
Je souhaite modifier la source de données dans les phases du pipeline
Cause : vous ne pouvez pas modifier la connexion à la source de données dans le service Power BI.
Solution : si vous souhaitez modifier la source de données au cours des phases de test ou de production, vous pouvez utiliser des règles de déploiement ou des API. Les règles de déploiement sont prises en compte uniquement après le prochain déploiement.
J’ai résolu un bogue en production. Depuis, je ne peux plus sélectionner le bouton « Déployer sur une phase précédente »
Cause : vous pouvez uniquement revenir sur une phase vide. Si vous avez du contenu en phase de test, vous ne pourrez pas revenir en arrière à partir de la production.
Solution : après avoir créé le pipeline, utilisez la phase de développement pour développer votre contenu, et les phases de test pour l’examiner et le tester. Vous pouvez résoudre les bogues lors de ces étapes, puis déployer l’environnement corrigé sur l’étape de production.
Notes
Le déploiement vers l’arrière prend uniquement en charge le déploiement complet. Il ne prend pas en charge le déploiement sélectif
Message d’erreur : « continuer le déploiement »
Cause : les changements cassants du schéma de la phase source, tels que le remplacement d’un type de colonne d’un entier par une chaîne, entraînent une perte de données dans le modèle sémantique cible après le déploiement.
Pendant le déploiement, les métadonnées du modèle sémantique source sont vérifiées par rapport aux métadonnées cibles. Les changements cassants de schéma entraînent l’arrêt du déploiement. Dans ce cas, vous recevez le message Continuer le déploiement.
Solution : si vous poursuivez le déploiement, vous perdrez les données dans la phase cible. Vous pouvez utiliser cette option si les modifications apportées au modèle sémantique étaient intentionnelles. Une fois le déploiement terminé, vous devez actualiser le modèle sémantique cible.
Si les modifications ne sont pas intentionnelles, fermez la fenêtre de message, chargez un fichier .pbix fixe dans l’espace de travail source et redéployez.
Après l’échec d’un déploiement en raison de changements de schéma, la phase cible affiche le message Échec du déploiement, suivi du lien Afficher les détails. Le lien ouvre le même message continuer le déploiement déjà affiché lors de l’échec du déploiement.
Message d’erreur : « Impossible de démarrer le déploiement »
Cause : lorsque vous utilisez l’actualisation incrémentielle, seules certaines modifications apportées au modèle sémantique que vous déployez sont autorisées. Si vous avez apporté des modifications non autorisées au modèle sémantique, votre déploiement échoue et vous recevez ce message :
Solution : si vous avez apporté intentionnellement des modifications à votre modèle sémantique, utilisez l’une des solutions de contournement suivantes :
À l’aide de.pbix – Publiez vos modifications directement dans le modèle sémantique cible. Toutes les partitions et toutes les données sont perdues et vous devez actualiser le modèle sémantique.
Utilisation des outils XMLA : apportez vos modifications directement sur le modèle sémantique à l’étape cible.
Mon visuel s’est rompu après le déploiement d’un modèle sémantique ou d’un flux de données
Cause : les modèles sémantiques et les flux de données sont des éléments Fabric qui stockent des données et qui contiennent à la fois des données et des métadonnées. Pendant un déploiement, seules les métadonnées sont copiées ; les données ne le sont pas. Par conséquent, après son déploiement, le modèle sémantique ou le flux de données pourrait n’avoir aucune donnée, et le visuel de rapport s’appuyant sur ces données semblera incorrect.
Solution : pour résoudre ce problème, actualisez le flux de données, puis le modèle sémantique dans la phase cible.
Comment supprimer un pipeline qui n’a pas de propriétaire (pipeline orphelin) ?
Cause : quand vous travaillez avec des pipelines de déploiement, vous pouvez vous retrouver avec un pipeline qui n’a pas de propriétaire. Par exemple, un pipeline peut rester sans propriétaire quand un utilisateur à qui il appartenait quitte la société sans transférer la propriété. Quand un pipeline n’a pas de propriétaire, les autres utilisateurs ne peuvent pas y accéder. Comme un espace de travail ne peut être attribué qu’à un seul pipeline, s’il est attribué à un pipeline sans propriétaire, personne ne pourra annuler cette attribution et vous ne pourrez pas utiliser l’espace de travail dans un autre pipeline.
Solution : si un pipeline se trouve sans propriétaire, un administrateur Fabric peut lui en ajouter un nouveau ou le supprimer. Pour ajouter un propriétaire au pipeline, utilisez l’API Admin - Pipelines UpdateUserAsAdmin.
Vous pouvez également consulter notre script PowerShell, AddUserToWorkspacePipeline (disponible dans le dépôt GitHub PowerBI-Developer-Samples), qui vous permet d’effectuer les opérations suivantes :
Gérer l’accès au pipeline : ajoutez utilisateur à un espace de travail dans un pipeline.
Récupérer la propriété de l’espace de travail : ajoutez un utilisateur à un espace de travail dans un pipeline qui n’a pas de propriétaire, ce qui vous permet de le débloquer.
Pour utiliser ce script, vous devez fournir un nom d’espace de travail et un nom d’utilisateur principal (UPN). Le script trouve le pipeline auquel l’espace de travail est attribué, puis ajoute des autorisations d’administrateur à l’utilisateur que vous avez spécifié.
Erreur d’incompatibilité : Erreur d’incompatibilité de version du format de modèle sémantique source et cible
Description du problème : l’erreur Impossible de démarrer le déploiement qui indique que les modèles sémantiques source et cible ont des formats de modélisation de données différents se produit quand la version de modèle du modèle sémantique de la phase cible est supérieure à celle du modèle sémantique de la phase source. Dans ce cas, les pipelines de déploiement ne peuvent pas effectuer de déploiement de la phase source vers la phase cible. Pour éviter cette erreur, utilisez un modèle sémantique qui a la même version de modèle (ou une version ultérieure) dans la phase source.
Solution : vous pouvez mettre à niveau le modèle sémantique dans la phase source à l’aide d’un point de terminaison en lecture-écriture XMLA ou de Power BI Desktop. Après la mise à niveau du modèle sémantique, republiez-le à l’étape source.
Erreur d’incompatibilité : erreur d’incompatibilité du mode de connectivité de la source de données
Description du problème : pendant le déploiement, si les pipelines de déploiement découvrent que le mode de connectivité d’une source de données dans la phase cible n’est pas le même que celui de la source de données dans la phase source, ils tentent de convertir le mode de connectivité de la source de données dans la phase cible. Si vous utilisez une source de données avec le mode de connectivité connexion active ou temps réel, les pipelines de déploiement ne peuvent pas convertir le mode de connectivité de la source de données de la cible.
Solution : utilisez un point de terminaison en lecture-écriture XMLA ou Power BI Desktop pour modifier le mode de connexion de la source de données dans la phase source ou supprimer la source de données dans la phase cible pour que le déploiement le remplace.
Échec du déploiement de mon modèle sémantique
Cause : plusieurs raisons peuvent expliquer l’échec du déploiement de votre modèle sémantique. Les causes envisageables pour cette défaillance sont les suivantes :
- Un modèle sémantique volumineux qui n'est pas configuré avec le format de modèle sémantique volumineux.
- Le modèle sémantique contient une dépendance circulaire ou autonome (par exemple, l'élément A fait référence à l'élément B et l'élément B fait référence à l'élément A). Dans ce cas, vous verrez le message d'erreur suivant : Un ou plusieurs éléments n'ont pas pu être déployés, car cela entraîne une dépendance bidirectionnelle entre les éléments.
Solution :
- Si votre modèle sémantique fait plus de 4 Go et n’utilise pas le format de modèle sémantique volumineux, il peut ne pas être déployé. Essayez de paramétrer votre modèle sémantique pour lui permettre d’utiliser le format de modèle sémantique volumineux, et redéployez-le.
- Si votre modèle sémantique contient une dépendance circulaire ou autonome, supprimez la dépendance et redéployez.
J’ai un modèle sémantique avec le mode de connectivité DirectQuery ou Composite, qui utilise des tables de variation ou de date/heure automatiques
Cause : les modèles sémantiques qui utilisent le mode de connectivité DirectQuery ou Composite et qui ont des tables de variation ou de date/heure automatiques ne sont pas pris en charge dans les pipelines de déploiement.
Solution : si votre déploiement échoue et que vous pensez que c’est parce que vous avez un modèle sémantique avec une table de variation, vous pouvez rechercher la propriété variations dans les colonnes de votre table. Vous pouvez utiliser l’une des méthodes suivantes pour modifier votre modèle sémantique afin qu’il fonctionne dans les pipelines de déploiement.
Utilisez le mode importation au lieu du mode DirectQuery ou Composite dans votre modèle sémantique.
Supprimez les tables de date/heure automatiques de votre modèle sémantique. Si nécessaire, supprimez toutes les variantes restantes de toutes les colonnes de vos tables. La suppression d’une variante peut invalider les mesures créées par l’utilisateur, les colonnes calculées et les tables calculées. Utilisez cette méthode uniquement si vous comprenez comment fonctionne votre modèle de modèle sémantique, car cela peut entraîner une altération des données dans vos visuels.
Rapports paginés
Je ne parviens pas à déployer un rapport paginé
Solution : pour déployer un rapport paginé, vous devez être membre de l’espace de travail à partir duquel vous effectuez le déploiement (l’espace de travail de la phase source). Si vous n’êtes pas membre de l’espace de travail à la phase source, vous ne pouvez pas déployer le rapport paginé.
Incompatibilité de la source de données : le rapport paginé de la phase cible affiche les données d’un modèle sémantique Fabric à l’étape source
Description du problème : à l’heure actuelle, les modèles sémantiques sont traités comme une source de données Analysis Services externe et les connexions aux modèles sémantiques ne sont pas basculées automatiquement après le déploiement.
Lorsque vous déployez un rapport paginé qui est connecté à un modèle sémantique Fabric, il continue à pointer vers le modèle sémantique auquel il était connecté à l’origine. Utilisez les règles de déploiement pour faire pointer votre rapport paginé vers un modèle sémantique de votre choix, notamment le modèle sémantique de la phase cible.
Solution : si vous utilisez un rapport paginé avec un modèle sémantique Fabric, consultez Comment créer une règle de déploiement pour un rapport paginé avec un modèle sémantique Fabric ?
Échec de déploiement : un grand nombre de rapports paginés échouent
Description du problème : un déploiement d’un grand nombre de rapports paginés avec des règles peut échouer en raison d’une surcharge sur la capacité.
Solution : achetez une référence SKU supérieure ou utilisez un déploiement sélectif.
Dataflows
Affichage de traçabilité : j’ai supprimé une source de données qui appartenait à un dataflow, mais elle est toujours visible dans l’affichage de traçabilité
Cause : dans les dataflows, les anciennes sources de données ne sont pas supprimées de la page de source de données de dataflow. Pour prendre en charge la vue de traçabilité des dataflows, les éléments connectés ne sont pas supprimés.
Solution : ce comportement n’affecte pas les pipelines de déploiement. Vous pouvez toujours actualiser, modifier et déployer des dataflows dans un pipeline.
Je vois deux sources de données connectées à mon dataflow après avoir utilisé des règles de dataflow
Description du problème : après avoir changé la source de données d’un dataflow à l’aide d’une règle, la vue de traçabilité du dataflow affiche une connexion entre la source de données source du dataflow et la source de données configurée dans la règle.
Solution : ce comportement n’affecte pas les pipelines de déploiement.
Datamarts
Problème de déploiement : je ne parviens pas à déployer un datamart dans le pipeline
Solution : pour déployer un datamart, vous devez être le propriétaire du datamart.
Problème de déploiement : Mon déploiement datamart a échoué en raison d'une dépendance circulaire
Solution : il existe un élément qui fait référence lui-même, ou plusieurs éléments impliqués dans une chaîne circulaire de références (par exemple, l'élément A référence l'élément B et l'élément B fait référence à l'élément A). Pour déployer le datamart, supprimez la dépendance circulaire et redéployez.
Autorisations
Qui peut déployer le contenu entre les étapes ?
Le contenu peut être déployé sur une étape vide ou une étape qui contient du contenu. Le contenu doit résider sur une capacité Fabric.
Déploiement sur une phase vide : n’importe quel utilisateur Fabric doté d’une licence qui est membre ou administrateur dans l’espace de travail source.
Déploiement sur une phase avec du contenu : n’importe quel utilisateur Fabric doté d’une licence qui est membre ou administrateur des deux espaces de travail dans les phases de déploiement source et cible.
Remplacement d’un modèle sémantique : le déploiement remplace chaque modèle sémantique inclus dans l’étape cible, même si le modèle sémantique n’a pas été modifié. Tout utilisateur membre ou administrateur des deux espaces de travail, mais l’administrateur du locataire peut limiter cela uniquement aux propriétaires de modèles sémantiques cibles.
Je ne vois pas d’espace de travail dans le pipeline
Cause : les autorisations de pipeline et d’espace de travail sont gérées séparément. Il est possible que vous ayez des autorisations de pipeline, mais pas des autorisations d’espace de travail.
Solution : pour plus d'informations, consultez la section Autorisations.
Message d’erreur : « Autorisations de membre d’espace de travail requises »
Solution : pour attribuer un espace de travail, vous devez disposer au moins des autorisations de membre de l’espace de travail pour les espaces de travail dans ses phases adjacentes. Des autorisations de membre de l’espace de travail (ou des autorisations supérieures) dans les phases adjacentes sont nécessaires pour que les pipelines de déploiement puissent établir les connexions entre les éléments dans les phases de pipeline voisines.
Règles
Échec du déploiement en raison de règles rompues
Solution : si vous rencontrez des problèmes lors de la configuration des règles de déploiement, consultez Règles de déploiement et assurez-vous de suivre les limitations des règles de déploiement.
Si votre déploiement a réussi précédemment et échoue soudainement avec des règles rompues, cela peut être dû à une nouvelle publication d’un modèle sémantique. Les modifications suivantes apportées au modèle sémantique source entraînent l’échec du déploiement :
Règles de paramètre
Un paramètre supprimé
Un nom de paramètre modifié
Règles de source de données
Il manque des valeurs dans les règles de votre déploiement. Cela peut se produire si votre modèle sémantique a changé.
En cas d’échec d’un déploiement précédemment réussi en raison de liens rompus, un avertissement s’affiche. Vous pouvez sélectionner Configurer des règles pour accéder au volet Règles de déploiement, où le modèle sémantique ayant échoué est marqué. Lorsque vous sélectionnez le modèle sémantique, les règles rompues sont marquées.
Pour déployer avec succès, corrigez ou supprimez les règles non respectées, puis redéployez.
Problème de déploiement : j’ai configuré des règles, mais le déploiement a échoué
Cause : les règles de déploiement ne sont pas appliquées immédiatement après leur configuration.
Solution : pour appliquer les règles de déploiement, vous devez déployer les modèles sémantiques de la phase source vers la phase cible qui comprend les règles de déploiement créées. Après avoir configuré des règles de déploiement et avant celui-ci, l’indicateur différent s’affiche en regard du modèle sémantique avec les règles configurées. Cela indique que vous devez déployer ce modèle sémantique de l’étape source vers l’étape cible. Après le déploiement, si aucune autre modification n’a été apportée, l’indicateur différent disparaît, ce qui signifie que les règles ont bien été appliquées.
Les règles de déploiement sont grisées
Solution : pour créer une règle de déploiement, vous devez être le propriétaire de l’élément pour lequel vous créez une règle de déploiement. Si vous n’êtes pas le propriétaire de l’élément, les règles de déploiement sont grisées.
Si l’une des options de règle est grisée, cela peut être dû aux raisons suivantes :
Règles de source de données : il n’existe aucune source de données sur laquelle une règle peut être configurée.
Règles de paramètres : il n’existe aucun paramètre pour lequel une règle peut être configurée.
Échec de ma règle de source de données pour un modèle sémantique
Solution : l’enregistrement des règles de source de données peut échouer pour l’une des raisons suivantes :
Votre modèle sémantique contient une fonction connectée à une source de données. Dans ce cas, les règles de source de données ne sont pas prises en charge.
Votre source de données utilise des paramètres. Vous ne pouvez pas créer une règle de source de données pour un modèle sémantique qui utilise des paramètres. Créez plutôt une règle de paramètre.
Je ne peux pas me connecter à un modèle sémantique lors de la création d’une règle de modèle sémantique
Cause : lors de la construction d’un modèle sémantique à l’aide de Power BI Desktop, la chaîne de connexion peut être configurée. Plus tard, le modèle sémantique peut être publié et utilisé par les pipelines de déploiement dans le service Power BI. Lors de la création de la connexion dans Power BI Desktop, vous pouvez spécifier des paramètres supplémentaires. Lorsque vous spécifiez les paramètres, la source du modèle sémantique doit être le premier paramètre répertorié. Si vous répertoriez d’autres paramètres avant la source du modèle sémantique, vous rencontrerez des erreurs dans le service Power BI. Dans ce cas, lors de la configuration d’une nouvelle règle de modèle sémantique, si vous pointez vers un modèle sémantique qui n’a pas été configuré correctement dans Power BI Desktop, les pipelines de déploiement ne peuvent pas créer la règle.
Solution: Mettez en forme la connexion de modèle sémantique dans Power BI Desktop afin que la source du modèle sémantique apparaisse dans la première ligne. Ensuite, republiez le modèle sémantique.
Dépannage des erreurs
Utilisez cette section pour résoudre les problèmes liés aux règles de pipeline que vous avez créées. Si vous ne voyez pas de nom de message d’erreur de règle, passez en revue les limitations des règles de déploiement et les sources de données prises en charge pour les règles de flux de données et de modèle sémantique, puis essayez de reconfigurer la règle.
| Message d’erreur | Solution |
|---|---|
| La règle de source de données ne peut pas contenir de paramètre | Votre règle ne peut pas être appliquée, car le nom de serveur ou de base de données référencé dans la règle est contrôlé par un paramètre. Pour modifier le nom de serveur ou de base de données, utilisez une règle de paramètre ou supprimez le paramètre de contrôle de l’élément configuré. |
| Échec de l’exécution de la source de données | Une règle ne peut pas être appliquée en raison d’un problème de récupération des données à partir de la source de données. Supprimez la règle et vérifiez que le modèle sémantique comporte des requêtes valides. Essayez ensuite de recréer la règle. |
| La propriété de règle n’existe plus | Certaines des propriétés de règle configurées dans la règle n’existent plus. Actualisez la page et reconfigurez la règle. |
| Valeur illégale | Une valeur utilisée dans la règle configurée n’est pas valide. Vérifiez les valeurs de la règle et réessayez de configurer la règle. |
| Les sources de données multiples ne sont pas prises en charge | Une règle de modèle sémantique ne peut pas être appliquée en raison de sa configuration de source de données. Supprimez la règle ou réécrivez les requêtes de modèle sémantique à l’aide des outils Power BI Desktop standard. |
| Le modèle sémantique cible ne peut être modifié que par son propriétaire | Votre règle remplace certains modèles sémantiques dans l’espace de travail de destination. Vous devez être le propriétaire de n’importe quel modèle sémantique qui sera remplacé. |
Contenu connexe
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour