SSRS – Le nerf de la guerre c’est le contrôle de la requête

Il existe plusieurs outils BI pour générer des rapports, que ce soit OBIEE, Crystal Reports, Cognos, MicroStrategy, SSRS etc.

Ce qui distingue SSRS du lot c’est le fait qu’il permette au concepteur de rapports de programmer dynamiquementt la requête (SQL, MDX, XML etc.) selon la valeur des paramètres (le contexte d’exécution). Les autres outils nous forcent à utiliser leur générateur de requête visuel, ou à coder en dur la requête avec quelques filtres. C’est beaucoup moins flexible que ce que SSRS nous offre.

Ainsi, selon les paramètres, la structure de la requête pourrait complètement changer. Par exemple, plutôt que de présenter la dimension département sur les lignes, elle pourrait plutôt présenter la dimension groupe d’emploi.

En pratique, cela fait en sorte de diminuer le nombre de rapports à développer. Chaque rapport peut offrir une grande flexibilité sur ce qui est affiché:

  1. Choix de la vision (dimension présentée sur les lignes / colonnes)
  2. Choix du croisement (plusieurs dimensions sur les lignes / colonnes)
  3. Choix d’indicateurs à afficher dans les grilles / graphiques
  4. Afficher le membre sélectionné et ses enfants, peu importe le niveau ou le nombre de niveaux de la hiérarchie

Quand je dit programmer la requête, je veux dire que le développeur peut écrire une expression ou mieux du code VB.NET à même le rapport ou mieux encore du code C# dans un Dll externe afin de générer la chaîne de caractères de la requête à lancer.

SSRS se garde la responsabilité de lancer la requête sur la source de données. Le code à écrire est donc simple et consiste à concaténer des caractères. Un développeur peut utiliser directement System.Text.StringBuilder ou faire comme nous et créer une classe d’abstraction sur la génération de MDX.

La seule chose qu’il faut garder constant c’est le nom des colonnes dans le résultat de la requête. Un DataSet dans SSRS a un nombre de champs fixe et connu à l’avance et chaque champ pointe sur une colonne du résultat. On ne peut pas utiliser une expression pour le nom de la colonne.

Ainsi, lorsqu’on fait du MDX, on crée plusieurs WITH MEMBER afin de contrôler le nom de la colonne dans le résultat. On n’utilise pas les champs pointant sur les colonnes générées automatiquement car ceux-ci changent de nom selon le niveau, la dimension etc.

MEMBER Measures.[RowMemberCaption] AS Department.DH.CurrentMember.Properties(‘Long Caption fr’)

MEMBER Measures.[Column1] AS Measures.[Nb Abs Hrs]

Dans les deux exemples ci-haut, les champs du DataSet pointent sur les colonnes RowMemberCaption et Column1. Si la requête change pour utiliser une autre dimension sur les lignes ou une autre mesure, le rapport continue à fonctionner …

Le contrôle de la requête est ce qui rend la plate-forme SSRS extrêmement puissante et flexible!

2 réflexions sur “SSRS – Le nerf de la guerre c’est le contrôle de la requête

  1. […] Nous avons développé des techniques permettant de produire des rapports techniquement complexes: choix de visions, de croisements et d’indicateurs qui affectent plusieurs zones de données (grilles ou graphiques). Cela évite d’avoir une prolifération de rapports et tout les efforts que cela implique au niveau de la maintenance. Pour plus de détails, voir mon entrée SSRS – Le nerf de la guerre c’est le contrôle de la requête. […]

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