Ce que nous allons voir ici nous sera utile dans le dernier cas d'étude, à savoir le déploiement personnalisé via un projet de Setup.
Déployer un rapport ne suffit pas, il faut aussi déployer la source de donnée qui lui est associée.

Analysons un rapport serveur.

Tout d'abord, un Rapport Reporting Services n'est rien d'autre qu'un fichier XML.
Prenons un exemple simple (créer à l'aide du Wizard de Visual Studio 2005)Si nous demandons à ouvrir le rapport, non pas avec le designer, mais avec un éditeur XML (hum... Visual studio, au hasard.) Nous obtenons ceci :

On remarque entre autres les définitions de :

1. La source de donnée
2. Les DataSets générés pour le stockage en mémoire des données
3. Les marges ...

Il devient évident que la source de donnée référencée à partir de l'élément <DataSources> est aussi du type XML. La vérification de l'ouverture du fichier .rds (AdvDataSource.rds dans notre exemple) nous conforte dans cette voie :

Conclusion.

A l'analyse de ces fichiers, il est donc bien établi que les deux fichiers à déployer sont de types XML :

1. L'un étant le rapport Reporting Services.
2. L'autre étant une source de données.

Note : Vous aurez noté le rapprochement du rapport avec la source de donnée dans la partie XML réservée aux sources de données :Ces deux fichiers sont donc intimement liés, notamment par le fait que le rapport identifie sa source de donnée par son nom.

Un rapport Serveur est stocké dans une base de données SQL Serveur 2005. On parle de catalogue Reporting Services.
Une base de données SQL Serveur 2005 configurée pour gérer et stocker des rapports serveurs contient notamment deux bases de données :

1. ReportServer$Instance : C'est le catalogue
2. ReporteServer$InstanceTempDB : C'est une base de travail pour la génération des rapports

Note : "$Instance" étant le nom de votre instance SQL Serveur 2005. Si votre serveur SQL Serveur 2005 est une instance par défaut, les noms seront respectivement ReportServer et ReportServerTempDB
ReportServer$Instance contient toutes les informations nécessaires au traitement d'un rapport Reporting Services.

Déploiement via Visual Studio 2005
La première façon de déployer, surement la plus simple est aussi surement la moins élégante quand on parle de déploiement en environnement de production, et ce même si le déploiement passe par le port 80 et donc traverse les Firewall.
Cette méthode exige d'avoir Visual Studio 2005 avec la suite Business Intelligence pour pouvoir déployer un rapport.
Si cette condition ne vous rebute pas, c'est de loin la solution la plus simple !
Il suffit de paramétrer correctement les propriétés de votre projet Reporting Services et le tour est joué.
La fenêtre Propriétés d'un projet RS nous demande quelques renseignements indispensables au déploiement :

Trois propriétés à renseigner :

1. TargetDataSourceFolder : Nom du répertoire où seront stockées les sources de données.
2. TargetReportFolder : Nom du répertoire où seront stockés les reports.
3. TargetServerUrl : Url de connexion au web services Reporting Services (nous allons aborder ce point en détail)

Note : Attention quand on parle de répertoire, ce concept reste "très virtuel", puisque tout ceci n'est pas stocké sur un système de fichiers, mais bien dans une base de données SQL Serveur 2005

Attardons nous sur l'url du serveur de Report :
Dans notre exemple il s'agit de http://localhost/ReportServer$SQL2005

Cette adresse est l'adresse Http de connexion au serveur de rapport RS 2005.
On parle bien de se connecter à une base de données via une adresse web ... !
En effet SQL Serveur 2005 installe non pas un mais deux sites web qui vont nous permettre non seulement de déployer mais aussi de gérer les rapports contenus dans la base.
Petite Vérification en passant sur notre console de management IIS :Il existe une autre possibilité pour connaître ce genre d'informations : L'outil de configuration de Reporting Services Reporting Services Configurations : Depuis cet outil vous avez accès notamment à la rubrique Report Server Virtual Directory, qui vous donnera l'url http d'accès à votre Server Reporting Services :Note : Les plus curieux auront aussi noté qu'il existe dans ce panneau de configuration une autre rubrique qui contient aussi une url : La rubrique Report Manager Virtual Directory: Nous y reviendrons un peu plus tard.
Bien, il ne reste plus qu'à déployer nos rapports via l'outil de déploiement de Visual Studio.
Simplicité étant le mot d'ordre, un simple clic droit sur le projet, puis Deploy suffiront :Le projet est compilé puis déployé. Une analyse de la fenêtre Output nous révèle plusieurs choses :

1. Visual Studio a contacté le serveur SQL Serveur 2005 via l'adresse http du Serveur de rapports.
2. Il a déployé la source de donnée suivant le chemin /Data Sources/AdvDataSource
3. Il a également déployé notre rapport suivant le chemin /ArticleReportProject/Report1

Nos rapports sont bien déployés

Cette solution est de loin la plus aisée, mais il y manque à mon gout (si on omet l'énormité de dire qu'il est nécessaire d'avoir Visual Studio d'installé) la vérification du déploiement.
Où voir mes rapports déployés ?
Les deux prochaines façons de déployer vont entre autres nous permettre de "voir nos rapports déployés".

Déploiement via Visual Studio 2005

SQL Server Management Studio permet d'administrer des bases de données, c'est un fait établi (oui je sais ça surprend ;))
Mais, il est aussi capable de gérer des serveurs de rapports, autrement dit de se connecter à un serveur de rapport et d'en extirper les données.

Il existe deux façons de se connecter à un serveur de rapport depuis SQL Server Management Studio

1. Via l'url de connexion.
2. Via l'instance nommée.

De là, vous avez accès à l'ensemble des informations de votre serveur de rapports :

Il y aurait surement beaucoup à dire sur l'ensemble des fonctionnalités disponibles depuis l'interface de gestion fournit par SQL Serveur Management Studio (gestion de sécurité, scheduleur, Rôles ...) , mais nous attarderons uniquement sur l'aspect déploiement.
Comment déployer un rapport ici : Un simple clic droit : Import File

Cela implique donc de connaître l'endroit où se trouver le fichier rdl (notre fichier xml).
Pire encore, il va falloir faire cela pour chaque rapport à "déployer".
On peut convenir que cette manière de faire, même si elle ne nécessite pas Visual Studio, reste marginale pour un déploiement en production.
Sans oublier la source de donnée Bien sûr !
Bref une façon de faire, destinée aux administrateurs expérimentés, patients et consciencieux.

Déploiement via le site web d'administration

Dans la première partie nous avons étudié les paramètres mis à disposition via l'outil de configuration de Reporting Services.
Dans l'onglet Report Manager Virtual Directory, on retrouve le même genre d'informations que l'url de connexion à Reporting Services:

1. Une url d'un site web
2. Le site web de déploiement

A la différence de l'url de connexion à Reporting Services, celle-ci est l'url permettant de naviguer, via un site web à travers toute l'arborescence des rapports installés sur votre serveur SQL Serveur 2005.
L'installation de ce site reste optionnelle.
Un rapide petit tour sur cette url nous donne accès à l'interface web d'un Site Reporting Services
Note : Le premier chargement est toujours un peu plus long, car Sql Serveur 2005 génère le site web à la volée, en plus de le compiler en sortie.

Le site web d'administration va vous permettre d'effectuer de nombreuses taches, comme il va aussi vous permettre de visionner vos rapports.
Quant au déploiement, il s'avère aisé à effectuer ... à partir d'une interface web !

On retrouve le même problème relatif à la disponibilité du fichier RDL lors du déploiement, mais aussi un système de téléchargement plutôt classique dans une application web, qui va nous obliger à traiter le déploiement de nos rapports, un par un.
Cette méthode reste tout de même la plus indépendante d'un outil externe, puisqu'il n'est pas nécessaire d'avoir Visual Studio .Net d'installé ou encore l'accès direct à votre Serveur SQL SERVEUR 2005 via l'outil SQL Server Management Studio.
Reste que le déploiement d'une dizaine ou vingtaine de rapports va vite devenir laborieux ...

Déploiement via le site web d'administration

Reste la méthode du déploiement personnalisé. Vous l'aurez compris, celle qui pour moi est la plus efficace.
Il va s'agir d'embarquer les rapports dans un setup de déploiement et de les déployer directement sur un serveur cible.
Pour faire cela, nous allons aborder les thèmes suivants :

1. Web Services Reporting Services
2. Projet Setup d'installation
3. Action personnalisée
4. Class Installer