[SSRS] Traitement des hiérarchies Ragged dans le Query Designer de RS

Le Query Designer de Reporting Services pour la partie MDX a une particularité sympathique que vous avez peut être déjà remarqué si vous ou vos utilisateurs utilisez Report Builder.
Il gère l’utilisation des hiérarchies Ragged n’importe comment. Et je me suis rappellé de ça hier soir en faisant une démo.
Pour rappel une hiérarchie ragged est une manière de gérer des hiérarchies déséquilibrées (ou la distance entre (All) et le membre le plus fin d’une branche n’est pas constante: cas typique des employés d’une entreprise…) avec une hiérarchie utilisateur « classique » (et non une Parent Child) principalement pour améliorer les perfs et contourner la relative mauvaise gestion des P/C par SSAS. On utilise pour ça la propriété HideMemberIf sur les niveaux de la hiérarchie utilisateur pour cacher des niveaux superflus.
Une fois réglé les problèmes connus (on borde par le bas, i.e. pour que ça marche les niveau « à vide » devront être vers le bas et non pas au milieu de la hiérarchie, cf ce post de Chris Webb) on est tous contents: ça marche dans Excel, dans les OWC (BIDS + SSMS) et dans Reporting Services… voir ci dessous, sans commentaires:

Pour information ici j’ai projeté une Ragged de 6 niveaux créée en HideMemberIf=ParentName, ainsi qu’une mesure de base, et j’ai filtré avec un attribut qui stocke le niveau (i.e. la distance au membre (All)) pour ne prendre en compte que les membres jusqu’au niveau 5, donc pas le niveau fin.

Et ça ne me renvoie rien: alors que je vous assure, j’ai des données.
Alors pourquoi?
Tout simplement parce que ce Query Designer est stupide à souhait. Désolé de le dire mais c’est le cas. Si je fais rapidement une analyse de ce qu’il me projette en lignes je verrais que c’est ce set là:
{ ([Organisation].[Hiérarchie Organisations].[Niveau 6].ALLMEMBERS ) }
Or effectivement, je n’ai pas de membres niveau 6. Si j’écrivais ce MDX, dans le but de projeter tous les membres de toute une hiérarchie j’écrirais quelque chose de la sorte:
{ ([Organisation].[Hiérarchie Organisations].ALLMEMBERS ) }
Puisque je n’ai jamais demandé de me filtrer uniquement les membres du Niveau 6. Bref en éditant le MDX je récupère ce que je veux , des (null) aux niveaux non renseignés. Au passage le NON EMPTY m’enlève le niveau 6 (cf mon filtrage plus haut).

Donc je dois faire écrire du MDX à mes utilisateurs dans Report Builder?

Hmmm. Autant vous dire tout de suite que ça pourrait être une solution immédiate mais que ce n’est pas forcément celle que je vous recommande🙂.
L’investissement en formation serait à mon avis un poil disproportionné. Comme ça je vois une solution utilisable dans le designer: rendre les niveaux de la hiérarchie utilisateur visibles.
Dès lors il suffit de notifier aux utilisateurs que ce sont ces hiérarchies d’attributs qui doivent être utilisées dans ce type de cas pour afficher les niveaux par CrossJoin, la précédente hiérarchie étant alors utilisée uniquement comme filtre. Problème: avec mes 6 niveaux cela risque rapidement de hurler. L’utilisateur n’aime pas trop enchaîner les glisser-déposer.

Si vous avez une suggestion, n’hésitez pas à la donner, je suis preneur.
Bonne journée!
PS: Vous avez le droit de voter pour corriger cela, sur Connect.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s