Position du problème :
On souhaite faire interagir des rapports de façon à ce que l'utilisateur puisse 'naviguer' d'un rapport à l'autre sans ressaisir les paramètres d'exécution de chacun des sous rapports.
Prenons ce rapport principal :
Il montre le nombre des abonnés à un club sportif mois par mois.
On voudra souvent connaitre le détail des données, par exemple utiliser ce genre de rapport qui montre la ventilation par tranche d'âge, sexe et type d'abonnement :
Vous aurez noté que ce rapport possède 3 paramètres :
- Un paramètre à simple valeur pour l'année
- Un paramètre à simple valeur pour le mois
- Un paramètre à valeur multiple pour le type d'abonnement
Nos allons voir comment lier ces deux rapports en exécution :
Il faut définir une action sur une des zones de texte du rapport 'principal' :
Comme vous le voyez, il y autant de paramètres mappés que dans le rapport cible.
En exécution, un simple clic sur la zone de texte fait apparaitre le rapport cible avec les bonnes valeurs.
A noter :
Ici le binding pour TypeAbonnement (notre paramètre multivalué) prend un des champs du dataset
Ce qui fait que, dans ce cas une valeur est associée à l'une des valeurs du tableau de valeurs possibles du paramètre.
On a donc ce binding :
Le type d'abonnement rejoint la 1ère valeur du paramètre cible.
Tentons maintenant le plusieurs-plusieurs :
Pour cela, il me faut ajouter un paramètre de type abonnement multi-valué aussi dans le rapport principal :
Il me faut un dataset de remplissage :
Et un paramètre de rapport :
Qui se remplit à partir de mon dataset :
Et enfin, modifier mon dataset principal pour utiliser ce paramètre :
Ok le paramètre fonctionne :
Revoyons le binding de l'action :
Cette fois nous ne pouvons récupérer le champ du dataset puisqu'il s »agit d'un tableau de valeurs :
Voici ce que propose l'assistant des expressions !
Cela ne fait pas mon bonheur, car seule la 1ère valeur de paramètre passe.
Si on tente une référence à l'objet (Parameters !TypeAbonnement) , rien ne passe au sous rapport : le passage de plusieurs à plusieurs parait donc compromis !
Revenons aux fondamentaux :
Un paramètre multivalué de type string accepte ce type de valeur par défaut :
Or, pour obtenir ce genre de CSV il y a une fonction qui le permet :
Il 'suffit' donc de mixer le tout :
De cette manière :
Et de vérifier que tout est OK :
Vous noterez que le 1 qui s'affiche est une textbox de contrôle des paramètres (elle confirme le choix des paramètres)
Qui enchaine sur :
Et un choix multiple :
Qui enchaine bien sur :
Je n'ai pas développé le code de SSRS (soyons modestes !) mais j'imagine bien ce qui se passe : on a plusieurs types de données et le seul qui compte au final est le type string, d'où la solution.
On donc bien :
Vous allez voir ci-dessous une manière encore plus simple de faire du binding de n à n (Attention je suis sous SSRS 2008 : par défaut , la solution avec Join et Split fonctionnera aussi sous 2005)
Validation avec des rapports sur des cubes :
Voici le rapport principal :
Comme tout à l'heure, deux paramètres simples et un paramètre multi-valué.
Et voici le rapport détaillé :
Avec les mêmes paramètres.
Et enfin le binding des paramètres :
Vous noterez que les @ font référence aux paramètres, donc pas besoin d'expression !
Et cela fonctionne pour les 1 à 1, 1 à n et n à n !
Du bon travail de la part des développeurs de Reporting .
Nota : dans le cas de SSAS se méfier des Key Columns et Name Columns car , pour que la liste combo soit correctement adressée dans le choix des paramètres, il faut que l'écriture du membre respecte exactement celle de son chargement.
C'est la raison pour laquelle j'ai utilisé ici @DimTempsAnnee (le paramètre) et non Annee (le champ du dataset)
A défaut, il aurait fallu écrire ceci :
Ce qui donne le même résultat (dans ce cas particulier)
Conclusion :
Pas mal de possibilités de liens entre rapports grâce à tout cela…