Scénarios qui peuvent casser Tableau de bord / Blogs / Perficient

Arrière-plan

Excel est le tableur le plus utilisé de nos jours, utilisé à tous les niveaux de l’organisation. Une quantité considérable de données non organisées est conservée dans les classeurs Excel, en raison de la facilité de création, de stockage et de partage rapides de fichiers Excel sur une base de données. La plupart des rapports/tableaux de bord Power BI qui en résultent sont basés sur Excel comme source de données.

La conception Excel lui permet d’agir comme un quasi-SGBD, avec une feuille de calcul individuelle agissant comme un tableau et un classeur comme une base de données. Mais Excel, étant un logiciel de type tableur, manque d’applicabilité, ce qui le rend vulnérable à la décomposition de l’intégralité du rapport Power BI dans certains scénarios. Ce blog présente quelques scénarios auxquels les développeurs doivent prêter attention lorsqu’ils utilisent Excel comme source de données pour le rapport Power BI.

Scénario : Incompatibilité des types de données

Excel prend en charge les types de données tels que texte/nombre/date/heure/logique. Malheureusement, il ne prend pas en charge une application stricte des types de données dans les colonnes respectives. Par exemple, les utilisateurs sont libres de saisir du texte dans les colonnes de type de données de date, etc. Les règles de validation des données d’Excel peuvent appliquer cela, mais ces règles peuvent facilement être désactivées ou supprimées en quelques secondes.

Comme le montre la capture d’écran ci-dessus, les données contenaient toutes les dates de préparation du rapport Power BI initial. Mais un beau jour, un utilisateur a saisi des points d’interrogation (???) dans la colonne Date car il ne connaissait pas la date de la transaction lors de la saisie des données et a décidé de remplir ces informations lorsqu’elles seront disponibles. Mais ces valeurs d’espace réservé génèrent des erreurs, car Power BI tente d’ignorer ces lignes.

Power BI Desktop veillera à afficher l’erreur comme indiqué dans la capture d’écran ci-dessus. Mais le service Power BI peut ne pas afficher l’erreur visible et ignorer silencieusement les lignes chargeant les données restantes. Cela pourrait affecter les rapports puisque les montants écrits sur ces lignes ne seraient jamais ajoutés car ces lignes n’étaient pas importées dans le modèle de données.

Scénario : lignes récapitulatives en bas

De nombreuses personnes ont l’habitude de calculer les totaux généraux au bas des données dans Excel (voir capture d’écran ci-dessous).

Cela pourrait ruiner les rapports dans Power BI, car cette ligne est également incorporée aux données, gonflant ainsi les totaux. Vous trouverez ci-dessous la section d’images comparatives du rapport Power BI avec une carte récapitulative montrant différents chiffres avant/après la ligne récapitulative.

Il convient de faire preuve de prudence lorsque ces données Excel sont destinées à être utilisées comme source de données pour Power BI. L’utilisateur final du classeur Excel doit être informé de ce qui précède, et le résumé Excel doit être effectué dans des feuilles de calcul distinctes pour éviter cela.

Scénario : Lacunes dans les données

Parfois, l’utilisateur peut insérer un espace dans les lignes de données (généralement observé à des fins d’impression pour ajuster la plage d’aperçu avant impression)

Power BI importe des données, y compris des lignes vides. La majorité des calculs ne seraient pas affectés, à l’exception de quelques fonctions DAX qui incluraient des lignes vides dans les calculs.

Ci-dessus se trouve le résultat utilisant la fonction COUNTROWS ( ), qui inclut également des lignes vides dans le résultat du calcul.

Les résultats du calcul diffèrent un peu avec d’autres fonctions comme COUNT ( ) , puisque cette fonction exclut les cellules vides lors du comptage.

Peu de développeurs préfèrent utiliser la fonction COUNTROWS ( ), car elle donne des résultats plus rapidement (elle renvoie simplement le nombre de lignes du tableau). Alors que COUNT ( ) est relativement lent, car il valide les valeurs de chaque cellule lors du calcul. Le développeur de rapports Power BI doit tenir compte de ces scénarios et développer des mesures en conséquence.

Les lacunes créent également des options vides dans la liste déroulante du slicer, ce qui ne semble pas professionnel.

Le désordre ci-dessus pourrait être évité en ajoutant une étape supplémentaire de suppression des lignes vides (voir l’image ci-dessous)

Scénario : Renommer une ou plusieurs colonnes

Il arrive souvent que les utilisateurs finaux modifient par inadvertance les titres des colonnes pour une meilleure compréhension ou une meilleure lisibilité. Certains utilisateurs professionnels peuvent ne pas préférer le nom technique de la colonne, ils pourraient donc être tentés de les renommer avant de créer des tableaux/graphiques PIVOT. Comme dans l’exemple ci-dessous, l’utilisateur du classeur Excel a modifié le nom de la colonne. Montant à Montant (en Rs) Étant donné que l’organisation dispose de rapports multidevises, l’utilisateur souhaite que le titre de la colonne décrive le fait que les montants sont en roupies indiennes.

Renommer les résultats en Échec de l’actualisation de l’ensemble de données pour les rapports Power BI, car à l’origine, lors du développement du rapport, la colonne était intitulée Montant. Power Query stocke les noms de colonnes dérivés d’Excel dans le script M pour l’importation de données Excel.

Vous trouverez ci-dessous l’erreur affichée lorsque le rapport Power BI est ouvert via Power BI Desktop.

La visionneuse de rapports doit être un peu vigilante dans la surveillance des erreurs d’actualisation, car elle apparaît sous la forme d’une petite icône d’erreur, comme le montre l’image ci-dessous.

En cliquant sur l’icône d’erreur, le message ci-dessous s’affiche et clarifie l’erreur en détail.

Les utilisateurs du rapport doivent ajouter leur identifiant de messagerie aux déclencheurs de notification d’échec d’actualisation. Power BI affichera les données de la dernière actualisation réussie des rapports, ce qui est encore plus désastreux.

Scénario : erreurs de cellule

Certaines fois, les formules Excel se cassent en raison de la suppression de cellules auxquelles la formule faisait référence ou pour toute autre raison diverse. Cela entraîne une erreur de cellule (comme indiqué dans la capture d’écran ci-dessous)

Tout comme l’inadéquation des types de données évoquée ci-dessus, lorsque le rapport est actualisé à partir de Power BI Desktop, il affiche le nombre de lignes contenant des erreurs. Mais dans le service Power BI, ces erreurs sont silencieuses. Bien que Power Query puisse effectuer un niveau de gestion de base pour ces erreurs, comme la substitution des erreurs par une autre valeur. Étant donné que cette erreur provient de la source, il est plus judicieux de la corriger dans la source que de la gérer dans Power BI.

Scénario : Renommer / Déplacer un fichier Excel

Power BI prend en charge le chemin absolu lors du référencement de n’importe quel fichier source (voir capture d’écran ci-dessous).

Ainsi, si le fichier est déplacé vers un autre dossier, ou peut-être renommé, le chemin doit également être mis à jour dans le rapport Power BI.

Il en va de même pour les fichiers Excel faisant référence à Sharepoint (voir capture d’écran ci-dessous).

Renommer ou déplacer le fichier vers un dossier différent entraînera une modification de l’URL du point de partage qui doit être mise à jour.

Les développeurs de rapports peuvent introduire des paramètres et lier le chemin/URL du fichier avec des paramètres faciles à mettre à jour à partir du service Power BI, sans avoir à télécharger, modifier et republier le rapport Power BI. Ce n’est pas une solution, mais juste un hack simple.

Google Sheets bénéficie d’un avantage dans ce scénario par rapport à Microsoft Excel, car les liens de Google Sheets ne changent pas lors du renommage ou du déplacement du fichier. Google Sheet attribue des identifiants uniques au fichier, indépendamment du nom ou de l’emplacement du fichier. Power BI prend en charge Google Sheets comme source de données et on peut en tirer parti si le renommage/le déplacement du fichier est inévitable et se produit fréquemment comme un scénario commercial normal.

Conclusion

Excel peut être un choix privilégié comme source de données, mais il faut penser dans une perspective plus large lorsqu’on l’utilise à des fins d’analyse et de reporting. Déplacer une partie de la saisie de données basée sur Excel vers Power Apps serait une solution efficace, car les formulaires ont la capacité de valider les données avant de les stocker. Power Apps utilise Dataverse comme backend auquel Power BI peut se connecter facilement. Au niveau organisationnel, cette approche offre une capacité de reporting plus forte par rapport à Excel.