La bonne nouvelle à propos de M est que vous pouvez déjà l’écrire. J’entends par là que chaque
exemple que vous avez suivi dans les 11 chapitres précédents a écrit une ou plusieurs lignes de code M pour vous. En effet, chaque étape d’un processus de chargement et de transformation de données que vous avez généré lors de l’utilisation de l’éditeur Power Query a créé automatiquement du code M pour vous.
Cela signifie plusieurs choses (très positives) :
- Vous n’êtes pas obligé de commencer à écrire le code M à partir d’une ardoise vierge. Souvent, vous pouvez utiliser l’éditeur de requête
Code « M » pour une étape appliquée
- Dans la barre de formule, modifiez le code M pour remplacer IsDealer par Année de déclaration.
- Appuyez sur Entrée ou cliquez sur l’icône de coche (coche) dans la barre de formule pour confirmer vos modifications.
L’étape et les données suivantes seront mises à jour pour refléter vos modifications.
La modification que vous avez effectuée à l’étape 5 signifie en fait que vous rajoutez la colonne IsDealer et que vous supprimez la colonne ReportingYear à la place. Vous pourriez
l’ont fait à l’aide de l’interface (en cliquant sur l’icône d’engrenage dans la liste des étapes appliquées pour cette étape), mais l’essentiel est de comprendre que les deux options sont disponibles et que l’interface Power Query génère et modifie uniquement le code M. Vous pouvez donc modifier ce code directement, si vous préférez.
Si vous êtes un utilisateur expérimenté d’Excel (comme le sont de nombreux aficionados de Power BI), vous pouvez soyez pardonné de penser que cela est similaire au développement de macros Excel. En effet, c’est à certains égards :
- Le code core peut être enregistré (VBA pour Excel, M pour Power BI).
- Le code résultant peut alors être modifié.
Il s’agit, bien sûr, d’une comparaison très simpliste. Les deux approches peuvent être similaires, mais les deux langages sont très différents. Pourtant, si cela aide en tant que métaphore à vous encourager à passer au développement M, alors qu’il en soit ainsi.
Il y a inévitablement une série de mises en garde lors de la modification du code M pour une étape de requête dans la barre de formule. Ceux-ci incluent (mais sont loin d’être limités à) les éléments suivants :
- Toute erreur entraînera non seulement l’échec de l’étape, mais également l’échec de l’ensemble du processus de chargement et de transformation des données à partir de l’étape en cours.
- Vous devez vous rappeler que M est sensible à la casse, et même la moindre erreur à ce niveau peut entraîner l’échec de l’ensemble du processus.
- L’utilisation de guillemets pour définir des éléments littéraux (tels que des noms de colonnes) doit être respecté.
- M utilise abondamment les parenthèses et les accolades. Il peut être nécessaire de pratiquer et de comprendre la logique sous-jacente pour apprécier pleinement leur utilisation dans divers contextes.
Heureusement, M fournira des messages d’erreur assez clairs si (ou quand) des erreurs s’infiltrent. Si vous entrez un nom de champ erroné, par exemple, vous pourriez voir un message comme celui de la figure .
Un message d’erreur “M”
Cependant, je ne veux pas que vous pensiez que modifier le code M est difficile ou dangereux. Donc, pour étendre l’exemple précédent, voici à quoi ressemblerait le code M si vous l’étendiez pour supprimer deux colonnes, et pas une seule :
= Table.RemoveColumns(#”Changed Type”,{“ReportingYear”, “IsDealer”})
Remarque Plus généralement, il est souvent préférable d’examiner le code des étapes existantes (ou de créer un code « factice » à l’aide d’un exemple de jeu de données en parallèle) pour avoir une idée de ce à quoi ressemble le code M d’une fonction particulière. cela indiquera alors comment modifier au mieux le code.