Reporting Services est une solution de génération d’états fournie avec SQL server depuis la version 2000. Ses services s’intègrent aujourd’hui parfaitement à la plateforme .Net.

Elle offre la possibilité de générer des rapports tabulaires, matriciels ou libres à partir d’une source de données gérée par .Net (SQL Server, Oracle, ODBC, OLE DB…), et permet également les rapports dynamiques avec des fonctionnalités Web.

La conception modulaire de l’outil facilite son intégration à différentes architectures applicatives. En effet, Reporting Services propose deux modes d’exécution, en déporté et en local, ce qui laisse plusieurs possibilités. Que ce soit pour une application Web ou Winform, l’utilisateur a le choix entre le mode de génération local ou déporté. Ceci permet de choisir l’architecture de l’application selon les besoins, la génération locale ne s’appuyant pas sur un serveur Web IIS.

Les rapports sont définis dans des fichiers .RDL au format XML. Le développement et le déploiement des rapports sont possibles via SQL Server, Visual Studio ou avec le générateur de rapports fourni avec Reporting Services.

Dans le cas d’un fonctionnement local, il faut fournir aux rapports les objets contenant les données à afficher. C’est alors l’application qui se charge de remplir ces objets à partir d’une ou plusieurs sources de données.

Le générateur de rapports fourni avec Reporting Services

Pour un fonctionnement déporté, les formulaires d’impression sont publiés sur un serveur de rapports à installer sur un serveur HTTP IIS de Microsoft. Ce serveur fournit un gestionnaire de rapports disponible sur l’URL http://nomserveur/reports/, ce dernier permettant de publier les états, de configurer le serveur, de lancer le générateur de rapport ou encore de définir de nouvelles sources de données. Des outils en ligne de commande pour l’administration du serveur de rapports sont installés par défaut. De plus, un requêteur SQL acceptant les procédures stockées est intégré pour faciliter l’utilisation.

« L’interface Web du serveur de rapports »

Dans le cas d’une exécution déportée (sur un serveur de rapports à part), une authentification sur ce serveur est nécessaire. Pour accéder aux données, il faut définir une DataSource au rapport qui permet au serveur de les récupérer. De plus, il est nécessaire de configurer l’accès aux données du serveur ainsi que les paramètres d’authentification et la liste des utilisateurs. Ces données sont stockées dans une base SQL Server, spécifique au serveur de rapports.

Pour visualiser les formulaires d’impression dans une application .Net Web ou Winform, Reporting Services fournit le composant « reportViewer » qui permet l’affichage de l’état. Ce composant propose à l’utilisateur une fonction d’exportation au format XML, Tiff, PDF, Excel, CVS ou Web archive en exécution déportée, et PDF ou Excel en exécution locale. Notons que l’on peut définir tous les paramètres de l’état dans le code associé à la page ASPX.

« Exemple de rapport. »

Architecture de Reporting Services

L’interface permet de communiquer avec les autres applications via des services Web. Lorsqu’une application se connecte au serveur de rapports via l’interface, la vérification des droits d’utilisateur est faite par les extensions d’authentification, qui reposent par défaut sur l’authentification Windows. Le processus de rapports exécute l’état en le remplissant avec les données et les éléments de mise en page. Les extensions de traitement des rapports se focalisent chacune sur un type d’élément de formulaire particulier (table, graphique …). Des extensions peuvent être ajoutées de manière à pouvoir traiter des éléments personnalisés, sachant qu’il existe une extension de rendu par format d’exportation possible. Par exemple, dans le cas d’un rendu par une application Web, c’est l’extension pour le HTML qui est utilisée.

Les données quant à elles sont récupérées par les extensions de traitement des données, avec une extension par type de source (SQL Server, Oracle, ODBC …). Ce sont ces extensions qui ouvrent la connexion, passent les requêtes, et envoient au processus les données sous forme de tableau bidimensionnel. Le processus de planification déclenche les exécutions planifiées et remet le formulaire d’impression à la destination voulue. Pour l’envoi par email ou sur le réseau, ce sont les extensions de remise qui sont utilisées, avec toujours une extension par type de destination. Par défaut, l’envoi par mail utilise le protocole SMTP.

« Exemple de rapport. »

Alternatives à Reporting Services

La solution la plus radicale consiste à développer soi-même un module de génération de rapports dans le ou les formats voulus. Mais cette solution prend beaucoup de temps, surtout dans le cas d’une utilisation poussée (graphiques, nombre de formats différents …). Une alternative est cependant possible avec Crystal Report, l’outil standard de reporting livré depuis 1993 avec Visual studio. Mais Crystal Report est moins complet que Reporting Services : il n’offre pas d’exécution déportée sur un serveur, son fonctionnement est moins paramétrable (on ne peut pas ajouter d’extensions), il propose moins de formats d’exportation et moins de fonctionnalités (pas de requêteur SQL, pas de gestion de droits utilisateurs …). De plus, comme en témoigne l’utilisation d’une syntaxe spécifique ou du Basic pour les formules algorithmiques, son intégration à la plateforme .Net est moins aboutie. Enfin, Crystal Report n’utilise pas de format XML pour les fichiers d’état, ce qui rend l’édition (dans un éditeur texte) et le partage des documents plus difficile, voire souvent impossible.

Points forts et points faibles

Points forts

1) Intégration à la plateforme .Net. 2) Le fonctionnement en mode serveur ou local et la conception modulaire permettent d’adapter ce service à différentes architectures applicatives. 3) Facile d’utilisation (Editeur dans Visual studio ou le générateur de rapports), et peu exigeant pour le SQL grâce au requêteur intégré. 4) Puissance malgré de nombreuses fonctionnalités (formats d’export, envoi des rapports par mail, sur le réseau ou en HTTP, rapports dynamiques, graphiques, sécurité et service d’authentification, interfaces SOAP et WMI …).

Points faibles

1) Dans le cadre d’une application Web utilisant le serveur de rapports, l’utilisation des fonctions dynamiques n’est pas performante. En effet, à chaque action de l’utilisateur, il est fait appel au serveur, qui exécute systématiquement l’intégralité du formulaire (requêtes SQL compris). L’utilisation de l’exécution locale permet néanmoins d’éviter ce problème, des objets applicatifs gardant toutes les données en mémoire (système de cache). Mais conséquence, certaines fonctionnalités du serveur sont perdues (envoi du rapport par email ou sur le réseau, certains formats d’exportation …). 2) L’exécution du serveur de rapports est faite sur le serveur IIS, ce qui peut conduire à une baisse sensible des performances du serveur HTTP. La séparation physique du serveur de rapports et du serveur Web applicatif peut alors être envisagée, mais elle demande dans ce cas un serveur supplémentaire. 3) Dans des environnements complexes et/ou hétérogènes, la configuration du serveur et de l’authentification peut s’avérer non triviale. Une nouvelle fois, l’exécution en local permet de passer outre ces problèmes, mais présente l’inconvénient de perdre les fonctionnalités de sécurité du serveur. 4) L’utilisation du serveur de rapports exige le déploiement des formulaires d’impression sur le serveur, même pour une simple mise à jour effectuée.

Conclusion

Reporting Services nous semble se placer comme la relève de Crystal Report chez Microsoft. Tout du moins à terme, puisque Microsoft propose actuellement une aide en ligne pour la migration de Crystal Report vers Reporting Services. Même si pour le moment les deux outils cohabitent, les nombreux avantages de Reporting Services et la logique d’intégration à la plateforme .Net en font un produit plus abouti, plus complet et a priori plus pérenne que son devancier.

Néanmoins, cette solution souffre encore de certains défauts, comme le manque de performance des fonctions dynamiques sur les rapports, ou encore le système d’authentification dans les environnements complexes. Notons aussi que l’abondance d’outils différents et de configurations possibles peut perturber un utilisateur débutant, contrairement à d’autres outils moins riches mais plus concis, tels que Crystal Report ou Birt (Logiciel Open Source basé sur Eclipse).