Avec TM1, vous aurez plus de temps pour l'analyse et d'autres activités utiles sans avoir à renoncer à Excel. Cubewise vous montrera comment.
Mise à jour sur les tests Cubewise de la version 2.0.9.1 de TM1
Depuis, IBM a publié une note sur ce sujet qui peut être lue ici.
Sécurité du sous-ensemble MDX
Comportement avant le 2.0.9.1
Il y a deux applications principales du MDX lorsque l'on parle des sous-ensembles de la dimension TM1. La première est un "sous-ensemble dynamique" dans lequel une requête MDX est enregistrée avec le sous-ensemble pour garantir que les éléments renvoyés reflètent automatiquement les modifications apportées à la structure de la dimension (par exemple, un nouvel élément ajouté à une dimension) ou les modifications apportées aux données du cube (par exemple, les cinq comptes les plus performants).
Un exemple serait le MDX suivant qui montre tous les éléments sous la consolidation "Monde".
{TM1DRILLDOWNMEMBER( {[Région].[Monde]}, ALL, RECURSIVE )}
Pour un utilisateur ayant accès à tous les éléments, cela ressemblerait à l'exemple ci-dessous :

Lorsque la sécurité des éléments est assignée à une dimension, un utilisateur final ne verra que les éléments qui répondent aux critères de sélection du MDX ET pour lesquels l'utilisateur a un accès minimum en LECTURE. Dans cet exemple, nous avons un groupe de sécurité dont l'accès est limité à l'Amérique du Sud (tel que défini dans le cube de sécurité des éléments comme ci-dessous)

Pour un utilisateur de ce groupe de sécurité - n'ayant accès qu'à l'Amérique du Sud - il en résulterait ce qui suit - uniquement les éléments auxquels l'utilisateur a accès :

Nouveau comportement
Dans la version 2.0.9.1 de la TM1, l'interprétation de la sécurité des éléments et des requêtes MDX a changé. Alors qu'auparavant, il semblait que la couche de sécurité était appliquée après la génération du MDX, elle l'est désormais avant.
Notez qu'il n'est pas strictement vrai que la sécurité a été appliquée après le MDX dans les versions antérieures, mais le résultat effectif était une liste d'éléments auxquels l'utilisateur avait accès et qui répondaient aux critères du MDX. Il est juste plus facile en termes d'explication de dire que la sécurité a été appliquée comme un filtre après la génération de l'ensemble.
Si nous prenons l'exemple ci-dessus, nous devons comprendre un peu plus ce qui se passe avec le MDX. La déclaration MDX renvoie d'abord l'élément "Monde", puis tous les éléments qui se trouvent en dessous, jusqu'aux éléments au niveau des feuilles.
{TM1DRILLDOWNMEMBER( {[Région].[Monde]}, ALL, RECURSIVE )}
La nouvelle interprétation serait que, puisque l'utilisateur n'a pas accès à l'élément "Monde", le MDX ne renverrait aucun élément. Ceci est vrai tant pour les sous-ensembles dynamiques que pour les expressions de sous-ensembles MDX utilisées dans les applications client (par exemple une définition de ligne dans un formulaire actif ou un rapport dynamique)

Résultats des tests supplémentaires
Le cas mentionné ci-dessus est vrai si nous utilisons la consolidation "Monde" mais si nous devions utiliser un parent direct des éléments, l'utilisateur final aurait à nouveau accès aux changements de comportement
{TM1DRILLDOWNMEMBER( {[Région].[Amériques]}, ALL, RECURSIVE )}

Selon l'interprétation, on pourrait s'attendre à ce que le MDX ne renvoie aucun élément, puisque l'utilisateur n'a pas accès à l'élément "Amériques", mais comme nous pouvons le constater, ce n'est pas le cas. Cela est très probablement dû à la différence entre les "membres" dans le MDX et les "éléments" dans les dimensions du TM1. Si vous souhaitez en savoir plus à ce sujet, veuillez consulter le blog de Cubewise CODE https://code.cubewise.com/blog/the-future-of-tm1-time-dimensions-in-the-world-of-hierarchies
Conclusion
Lors de la mise à niveau vers la version 2.0.9.1 TM1, les administrateurs doivent veiller à tester pleinement les sous-ensembles dynamiques sauvegardés et les applications d'utilisateur final pour les déclarations MDX sur les dimensions avec la sécurité des éléments. Les déclarations de sous-ensembles MDX peuvent être assez complexes lorsqu'on utilise des fonctions plus avancées et des filtres de données cubiques, et ce changement dans l'ordre d'exécution de la déclaration MDX et de la couche de sécurité peut donc entraîner des sous-ensembles et des rapports vides pour les utilisateurs si on ne les contrôle pas.