[Jonathan]

Oui et non, dans mon exemple, c’est un premier appel qui permet d’obtenir les infos de la pagination, qu’à priori vous n’avez pas.

[Jonathan]

Bonjour Franck,

• Les tables de faits sont celles dans lesquelles on cherche à compter quelque chose (nombre de lignes, somme d’une colonne, moyenne etc…),
  • Une bonne table de faits ne doit, en théorie, contenir que des dates, des codes et des montants,
  • Toutes les choses qu’on utilisera pas dans la dataviz (donc à masquer dans la vue modèle),
    • A la place des dates, on utilisera la table des dates,
    • A la place des codes, on utilisera les dimensions,
    • A la place des montant, on utilisera des mesures,
• Les dimensions sont les axes d’analyse (ou référentiels) qui vont permettre d’analyser ces faits :
  • Le temps (table calendrier indispensable pour gérer le DAX facilement et pour faire votre analyse à la maille souhaitée),
  • Une table des produits par exemple,
  • Une table clients, etc…

Une bonne modélisation pour Power BI, c’est une modélisation en étoile, précisément, un modèle en étoile dénormalisé (c’est-à-dire que c’est à vous de mettre tous les attributs relatifs à une même dimension dans la même dimension).

• On évitera de faire une table Catégorie de produits, puis sous-catégorie de produits, puis produits.
• Si possible, on essaie de n’avoir que des relations de 1 à plusieurs entre les dimensions et les faits,
• On évite le bidirectionnel (qui crée de l’ambiguïté dans le modèle, le DAX vous permettra de gérer cela à la place),
• On ne fait jamais communiquer deux tables de faits entre elles (puisqu’on aura nécessairement du plusieurs à plusieurs),
• On les fait communiquer par un axe commun (par exemple la date, de date vers table de faits 1 puis de date vers table de faits 2),
• Si les faits n’ont pas la même granularité (factures à la maille journalière et budgets à la maille mensuelle par exemple), on les sépare dans deux tables de faits,

Ce sera déjà un bon début ! Un bon modèle, c’est du DAX facile et un modèle facilement requêtable par les utilisateurs finaux. Pensez à masquer tout ce qui est technique et qui ne les concerne pas, tables de faits, mesures intermédiaires, clés techniques etc… et pensez à documenter votre modèle, les tables, les colonnes, les mesures et même la partie Power Query.

Pour les ressources, une bonne formation sera toujours la meilleure option à mon sens car vous bénéficierez de l’expérience des formateurs et non pas seulement de la théorie des bouquins. J’ai personnellement démarré seul, avec des bouquins et des certifications en tout genre, j’ai également fait une formation en présentiel avec un formateur pas du tout à la hauteur… et jusque là, tout était ultra compliqué je trouve. Puis un jour j’ai eu la chance de tomber sur un excellent formateur, et là, tout est devenu bien plus clair !

Bon courage pour la suite et à bientôt sur le forum.

P.S. : la référence pour la modélisation, c’est Kimball 👍

[Jonathan]

Parfait, j’espère que vous arriverez à finaliser votre requête. Je pense que si l’API ne retourne rien comme info intéressante, il faudra faire une fonction récursive qui s’appelle elle-même jusqu’au moment où le résultat est vide. J’ai préparé un exemple pour plus tard 👌

[Jonathan]

Parfait 👍bonne continuation dans votre projet

[Jonathan]

C’est franchement laborieux pour formater son texte ici 😂

[Jonathan]

Bonjour Samuel,

Quand vous faites cet appel API de manière unitaire, par exemple pour la page 1, l’API ne vous renvoie pas d’information concernant le nombre de pages au total c’est bien ça ?

Assez souvent les APIs renvoient des informations, soit sur le nombre de pages à appeler, soit sur le nombre d’éléments total et le nombre d’éléments par page (à nous de calculer le nombre d’appels à faire).

Si ce n’est pas le cas, vous pouvez générer par exemple une liste de 1 à 10 pour tester = {1..10} puis vous appliquez votre fonction sur cette liste (que vous aurez au préalable convertie en table).

Vous verrez déjà si cela fonctionne et peut-être verrez-vous des tables vides ou des erreurs à la suite de cet appel. Vous pourrez gérer ça assez facilement côté Power Query je pense.

Je vous donne un exemple d’appel avec de la pagination :

let

method = “Document.getList”,

param = “””doctype””: “”invoice”””,

Source = FactAPICallInfo(method, APINbPerPage, “1”, param),

infos = Source[infos],

nbpages = infos[nbpages],

List_Pages= {1..nbpages},

Converted_to_Table = Table.FromList(List_Pages, Splitter.SplitByNothing(), null, null, ExtraValues.Error),

Renamed_Columns = Table.RenameColumns(Converted_to_Table”, {{“Column1”, “NumPage”}}),

Changed_Type = Table.TransformColumnTypes(Renamed_Columns, {{“NumPage”, type text}}),

Added_Custom = Table.AddColumn(Changed_Type, “Custom”, each FactGetAPIData(method, [NumPage], param))

in

Added_Custom

Au début, j’appelle l’API pour connaître le nombre de pages. Ensuite je crée une liste de 1 au nombre total puis j’appelle ma fonction X fois.

Donc je récapitule : vous gardez votre fonction en l’état. Vous créez pour le moment une liste de 1 à mettons 10 (Dans une nouvelle requête). Vous convertissez cette liste en table (vous changez le type en texte) puis vous appelez votre fonction sur cette colonne.

Ensuite si ça marche, vous agrandissez le 10 jusqu’à trouver des nuls pour voir comment gérer les “problèmes”.

• Cette réponse a été modifiée Il y a 6 mois, 4 semaines par  Jonathan.
• Cette réponse a été modifiée Il y a 6 mois, 4 semaines par  Jonathan.
• Cette réponse a été modifiée Il y a 6 mois, 4 semaines par  Jonathan.

[Jonathan]

Bonjour Samuel,

Quand vous faites cet appel API de manière unitaire, par exemple pour la page 1, l’API ne vous renvoie pas d’information concernant le nombre de pages au total c’est bien ça ?

Assez souvent les APIs renvoient des informations, soit sur le nombre de pages à appeler, soit sur le nombre d’éléments total et le nombre d’éléments par page (à nous de calculer le nombre d’appels à faire).

Si ce n’est pas le cas, vous pouvez générer par exemple une liste de 1 à 10 pour tester = {1..10} puis vous appliquez votre fonction sur cette liste (que vous aurez au préalable convertie en table).

Vous verrez déjà si cela fonctionne et peut-être verrez-vous des tables vides ou des erreurs à la suite de cet appel. Vous pourrez gérer ça assez facilement côté Power Query je pense.

Je vous donne un exemple d’appel avec de la pagination :

<div>
<div>let</div>
<div> method = “Document.getList”,</div>
<div> param = “””doctype””: “”invoice”””,</div>
<div> Source = FactAPICallInfo(method, APINbPerPage, “1”, param),</div>
<div> infos = Source[infos],</div>
<div> nbpages = infos[nbpages],</div>
<div> List_Pages= {1..nbpages},</div>
<div> Converted_to_Table = Table.FromList(List_Pages, Splitter.SplitByNothing(), null, null, ExtraValues.Error),</div>
<div> Renamed_Columns = Table.RenameColumns(Converted_to_Table”, {{“Column1”, “NumPage”}}),</div>
<div> Changed_Type = Table.TransformColumnTypes(Renamed_Columns, {{“NumPage”, type text}}),</div>
<div> Added_Custom = Table.AddColumn(Changed_Type, “Custom”, each FactGetAPIData(method, [NumPage], param))</div>
<div>in</div>
<div>Added_Custom</div>
<div> </div>
<div>Au début, j’appelle l’API pour connaître le nombre de pages. Ensuite je crée une liste de 1 au nombre total puis j’appelle ma fonction X fois. </div>
<div> </div>
<div>Donc je récapitule : vous gardez votre fonction en l’état. Vous créez pour le moment une liste de 1 à mettons 10 (Dans une nouvelle requête). Vous convertissez cette liste en table (vous changez le type en texte) puis vous appelez votre votre fonction sur cette colonne.</div>
<div> </div>
<div>Ensuite si ça marche, vous agrandissez le 10 jusqu’à trouver des nulls pour voir comment gérer les “problèmes”.</div>
</div>

[Jonathan]

Bonjour Franck,

La taille du point est fonction d’une mesure donc en faisant une mesure qui renvoie une plus grande valeur, vous pourrez augmenter la taille du point. Mais il y a un gros “Mais”, ça fausse la lecture du graphique, pourquoi faire ça ? Je ne vois pas bien le cas d’usage en réalité.

Pour la deuxième partie de la question, on ne peut pas gérer l’ordre mais on peut gérer la transparence des points. On peut donc imaginer les points non essentiels en légère transparence et le point principal sans aucune transparence.

Pour gérer la transparence, vous pouvez ajouter deux chiffres à votre code HEX, 50 veut dire 50% d’opacité, 10, 10% d’opacité etc…

Bon courage pour la suite de votre projet, n’hésitez pas à partager un exemple de ce que vous souhaiteriez obtenir.

[Jonathan]

Bonjour Laurence,

Voici 2 images qui synthétisent les mesures, le modèle et le résultat attendu au niveau de l’info-bulle.

J’espère que ça vous aidera.

[Jonathan]

Bonjour Brice, bonjour Nathalie,

Ici le CALCULATE ne sert strictement à rien. Si l’on veut juste faire des sommes, SUM est suffisant. Une bonne pratique sera d’ailleurs de faire réellement ces mesures de base puis de les utiliser ensuite.

Dans ce cas précis, on cherche à faire la somme de colonnes qui viennent de la même table, un simple SUMX sera suffisant. SUMX(Ma_Table, Ma_Table[Col1] + Ma_Table[Col2] + Ma_Table[Col3])

P.S. : ce n’est pas très clair, mais je répondais à ce message plus haut 😀 :

“Mon Total des valeurs =
Var Sommedesoccurences1 = CALCULATE(SUM(Valeur1))
Var Sommedesoccurences2 = CALCULATE(SUM(Valeur2))
Var Sommedesoccurences3 = CALCULATE(SUM(Valeur3))
Var SommeTotal = Sommedesoccurences1 + Sommedesoccurences2 + Sommedesoccurences3
RETURN SommeTotal”

• Cette réponse a été modifiée Il y a 6 mois, 4 semaines par  Jonathan.

[Jonathan]

Bonjour Dalia,

Voici une vidéo qui pourrait t’aider dans ce projet.

Il y a d’autres approches, tu peux par exemple faire des mesures qui calculent directement les N derniers Mois (avec la fonction DATESINPERIOD).

Mais l’approche décrite dans la vidéo est simple à mettre en œuvre et t’évitera d’avoir à gérer du DAX un peu complexe.

[Jonathan]

Bonjour,

Il faut faire une fonction personnalisée et variabiliser ce qui doit l’être.

Si par exemple, c’est le nom de la base qui change :

• Dans le code M, le nom de la base est “Toto”,
• Au tout début du code M, avant le let, vous saisissez : (Nom_Base as text) as table =>
• Vous remplacez ensuite Toto par Nom_Base (le nom de votre paramètre),
• Vous faites ensuite une liste des noms des bases à agréger (avec entrer les données par exemple),
• Vous appliquez la fonction sur cette colonne (Ajouter une colonne puis appeler une fonction personnalisée),
• Vous dépliez les données,

C’est possible que le refresh ne fonctionne que dans le desktop et pas dans le service avec cette technique. A creuser du coup…

[Jonathan]

Je pense que l’impact est lié à la gestion de la confidentialité des données. On a déjà ce problème dans Power Query en standard où, lorsqu’on fusionne nous données, si on ne le fait pas “correctement”, on peut avoir des messages d’erreur liés à la confidentialité des données. On peut alors, paramétrer correctement la confidentialité des données pour chaque source et/ou faire des fusions dans de nouvelles requêtes au lieu de les faire sur les requêtes existantes.

J’ai l’impression que c’est un peu ça ici, ou tout simplement un moyen de nous “contraindre” d’aller vers une version premium 🙂

[Jonathan]

Bonjour Magalie,

Cet article vous sera utile, il montre une technique simple pour s’affranchir du Premium dans ce cas précis.

[Jonathan]

Merci Bertrand, très clair. Je passe la main, je n’utilise pas du tout cette fonctionnalité (Je préfère créer mes propres textes dynamiques via des mesures, je trouve justement cela bien plus simple).