Création d’un rapport local

Ouvrez la boîte de dialogue ReportViewer Tasks. Cliquez sur le lien Design a new report, afin de créer un rapport nommé Report1.rdlc. Ouvrez ce fichier dans la fenêtre du concepteur de rapports.
3. Cliquez sur le lien Add New Data Source dans le volet gauche pour accéder au Data Source Configuration Wizard. Cet assistant vous demande de préciser la source de ses données. Vous pouvez faire appel à une base de données, un service Web ou un objet Microsoft .NET. Dans le cadre de cet exemple, laissez l’option Database par défaut et cliquez sur Next.

4. Définissez la connexion de données qui sera employée par la source de données. Sélectionnez une connexion existante, si vous en avez déjà défini une, ou cliquez sur l’option New Connection afin d’en créer une nouvelle. Si vous définissez une nouvelle connexion, effectuez ce processus. Lorsque vous avez terminé, cliquez sur Next.

5. Sélectionnez si vous souhaitez stocker les informations de chaîne de connexion dans le fichier de configuration de l’application ou laisser les informations incorporées dans le code. L’enregistrement de la chaîne de connexion dans le fichier de configuration offre plus de souplesse car l’environnement de base de données peut changer. Après avoir spécifié l’emplacement de la chaîne de connexion, cliquez sur Next.

6. Sélectionnez les éléments de la source de données à inclure dans le dataset. Lorsque votre source est une base de données, les éléments peuvent être des tables, des vues, des procédures stockées et des fonctions. Non seulement vous pouvez sélectionner les objets de base de données, mais également des champs spécifiques de ces objets, comme l’illustre la figure 3. Après la sélection des éléments de base de données, cliquez sur Finish. L’assistant crée alors un dataset typé, qui apparaît en tant qu’élément XSD (XML Schema Definition) dans l’Explorateur de solutions (Solution Explorer). Ce dataset typé sert de source de données pour le rapport.

7. Vous pouvez désormais créer le rapport dans la fenêtre Data Source, comme n’importe quel rapport SSRS. La seule différence est que le concepteur de rapports n’inclut pas d’onglet Data ou Preview. En effet, les données proviennent du dataset typé, d’où l’inutilité de l’onglet Data et, comme le rapport est prévisualisé en exécutant l’application, l’onglet Preview est également superflu. (Notez que notre exemple ne prend pas en charge les paramètres de rapports ou sous-rapports. Je vous expliquerai comment les utiliser dans la partie 2.)

8. Une fois le rapport terminé, revenez au formulaire contenant le contrôle ReportViewer. Pour affecter un nouveau rapport local à ReportViewer, sélectionnez le rapport dans la liste déroulante Choose Report au niveau de la boîte de dialogue ReportViewer Tasks. Vous pourrez constater que l’assistant a ajouté les objets DataSet, BindingSource et TableAdapter à la fenêtre de conception de formulaire. Ces objets fournissent les données pour le rapport local.

Lorsque vous exécutez l’application, le rapport local apparaît dans une fenêtre Report Viewer, comme l’illustre la figure 4. Ce rapport est ajouté au projet en tant que fichier .rdlc (Report Definition Language Client) car il s’agit d’un rapport côté client. Le fichier .rdlc est quasiment identique au fichier .rdl que vous avez créé et déployé sur un serveur de rapports SSRS. La seule différence réside dans la section rd :Data- SetInfo du fichier .rdlc.

Cette section, illustrée à la figure 5, est utilisée par Visual Studio 2005 pour ajouter des objets et générer du code à l’intérieur du formulaire hébergeant ReportViewer. La section rd :DataSetInfo fournit les informations nécessaires pour créer et remplir les objets DataSet, BindingSource et TableAdapter, puis pour les lier au rapport local. Par défaut, les rapports locaux sont compilés directement dans les fichiers .exe ou .dll de l’application.

Ainsi, les rapports sont autonomes et faciles à distribuer. Néanmoins, cette approche présente deux inconvénients potentiels. Premièrement, il faut créer un contrôle ReportViewer pour chaque rapport local à mettre à la disposition des utilisateurs finaux. Deuxièmement, la révision d’un rapport existant ou l’ajout d’un nouveau rapport à une application nécessite de recompiler et de redistribuer l’application. Ainsi, si vous devez créer de nombreux rapports ou si vous avez un environnement de reporting dynamique, le recours aux rapports locaux n’est peut-être pas souhaitable.