L'utilisation des attributs de membres d'un cube SSAS dans un rapport SSRS ne se fait pas de manière transparente.

En effet, alors que les attributs sont visibles dans l'éditeur graphique de source de données SSAS de Reporting Services, ils ne sont pas sélectionnables.

Pour y avoir accès dans un rapport, il est nécessaire de basculer en mode Requête MDX, et de modifier sa requête de la manière suivante:

SELECT

NON EMPTY { [Measures].[...]} ON COLUMNS,
NON EMPTY { ([Dimension].[Hierarchy].[Level].ALLMEMBERS * [Dimension].[Hierarhcy].[Level].ALLMEMBERS * ... ) }
DIMENSION PROPERTIES MEMBER_CAPTION, MEMBER_UNIQUE_NAME, [Dimension].[Hierarchy].[Level].[Attribute]
ON ROWS

FROM [Cube]
WHERE ...

Les mots clefs DIMENSION PROPERTIES permettent de passer les valeurs des attributs directement dans le résultat de la requête MDX, les rendant accessibles dans l'onglet mise en page de SSRS.

Ainsi, dans le rapport, la syntaxe à utiliser sera : Fields!######("Nom de l'attribut")

Sources:
Blog de Braulio Malaga (Avanade)
MSDN

Afin de disposer des propriétés ParentUniqueName ou Level dans les rapports de SSRS, il peut être utile de formuler sa requête MDX comme suit.

En effet dans le cas de dimensions parent-enfant SSRS arrive à communiquer avec SSAS pour obtenir ces infos. Pour toutes les autres dimensions cela ne fonctionne pas, et l'utilisation de cette syntaxe permet de contourner ce manque et de disposer des propriétés attendues. Pour certains rapports tordus cela peut être bien utile!


WITH

MEMBER [Measures].[UniqueName] as axis(1).item(0).item(0).hierarchy.currentmember.uniquename
MEMBER [Measures].[ParentUniqueName] as axis(1).item(0).item(0).hierarchy.currentmember.parent.uniquename
MEMBER [Measures].[P2UniqueName] as axis(1).item(0).item(0).hierarchy.currentmember.parent.parent.uniquename
MEMBER [Measures].[ParentName] as axis(1).item(0).item(0).hierarchy.currentmember.parent.name
MEMBER [Measures].[Name] as axis(1).item(0).item(0).hierarchy.currentmember.name
MEMBER [Measures].[Level] as axis(1).item(0).item(0).hierarchy.currentmember.level.ordinal

SELECT

{[Measures].[UniqueName],[Measures].[ParentUniqueName], [Measures].[Name], [Measures].[ParentName], [Measures].[P2UniqueName] , [Measures].[Level], [Measures].[Nb Employés] } ON COLUMNS,

NonEmpty(
{ STRTOMEMBER(@DimOrganisationOrganisation, CONSTRAINED).CHILDREN
}) ON ROWS

FROM [CubeDWH]
WHERE (STRTOSET(@DimTempsTemps, CONSTRAINED))

La problématique est de proposer un portail sur SSRS qui dispose de :

* 2 datasets, un SSAS et un SQL Server
* une page d’accueil classique à base de requête SQL : A
* une navigation dans un cube en format matrice : MM
* une navigation dans un cube en format liste : ML
* une page de détail à base de requête SQL : D

Les navigations RS détaillées dans ce post sont : A > MM > ML > D.

En comprenant les syntaxes utilisées pour ces sauts il est possible de monter un réseau complet depuis n'importe quel type de rapport vers n'importe quel autre.

La principale difficulté dans ce type d’architecture repose sur le passage des paramètres entre les 2 technologies.

Il est à noter que le sujet de la sécurité ne sera pas abordé. En effet selon les best practices il est nécessaire de définir la sécurité des données au niveau des bases (SSAS ou SQL Server) et non au niveau de l’outil de reporting, afin de garantir le même niveau de sécurité selon tous les modes d’accès.

Toutes les syntaxes détaillées ci-dessous sont à définir dans la fenêtre paramètre de l’onglet navigation de la zone devant disposer du lien.

1 - A > MM
Dans ce saut de rapport, une valeur SQL est passée à un rapport branché sur cube. Le paramètre attendu par le cube est une coordonnée de dimension permettant de filtrer les données. Il est donc nécessaire de transformer la valeur pour qu’elle adopte le format attendu :

ParamètreAttendu
="[Dimension].[Hiérarchie].[Niveau].&["+ Fields!ChampSQL.Value +"]"

2 - MM > ML
Dans notre exemple 2 valeurs sont transmises à ML :

La première provient du dataset de MM. Attention au fait que ce n’est pas la valeur du champ qu’il faut transmettre mais bien sa coordonnée dans le cube. On ne transmet donc pas à ML une Value mais un UniqueName qui correspond à cette coordonnée:
ParamètreAttendu

=Fields!ChampDeLaDimensionAttendue("UniqueName")

Pour la seconde valeur, qui est fournie par le paramètre de DimTemps de MM, la syntaxe est la Value, car dans cette value est stockée une coordonnée MDX qui dans notre cas provient du point 1 :
ParamètreAttendu
=Parameters!NomDuParametre.Value


3 - ML > D
Enfin, pour passer de ML à D, il suffit simplement de transmettre la valeur du champ attendu et non ses coordonnées comme précédemment. La propriété Value suffit donc :
ParamètreAttendu
=Fields!ChampDeLaDimensionAttendue.Value


Et voilà !
Facile en fin de compte ;)

Vous le savez sans doute deja, mais chaque outil de SQL Serveur 2005 à son propre mode de deployement, je me suis donc attaché à trouver un mode pour chacun. Dans le cadre ou je souhaite laisser un livrable pret à installer par mon client ou mon service d'exploitation.
Très vite on trouvera le generateur de "deployement manifest" de SSIS ainsi que les fichier de publication de SSAS à utiliser avec l'assitant de deployement.
Pour SSRS ce point est bien plus complexe.
Les choix qui s'offre à nous :
- Deploiement via Visual Studio
- Deplacement des fichiers RDL
...
Après quelques recherche je suis tomber sur le pilotage de l'application RS.exe via un fichier RSS.
il nous faut donc plusieurs elements pour effectuer un livraison avec ce mode
1 Fichier .RSS
1 Fichier .Bat (pour lancer le tout)
x fichiers .Rdl