> Data > Tout sur Reporting Services

Tout sur Reporting Services

Data - Par iTPro.fr - Publié le 24 juin 2010
email

par Brian Larson et Martin Voegele - Mis en ligne le 19/01/2004 - Publié en Février 2004

Tout sur le nouvel outil SQL Server 2000 : le reporting de la conception à  la livraison

Initialement, Microsoft avait l'intention de livrer Reporting Services dans le cadre de la prochaine release Yukon de SQL Server. Mais les utilisateurs qui ont reçu les toutes premières descriptions et démonstration de Reporting Services ont été séduits et ont dit à  Microsoft qu'ils voulaient ces fonctions le plus tôt possible. Microsoft a écouté et a réagi de deux manières : en faisant de Reporting Services un add-in à  SQL Server 2000 et en intégrant les fonctions dans Yukon ...Mais pourquoi ce vif intérêt ? Sans Reporting Services, le seul moyen de délivrer des informations de gestion de dernière minute sur Internet ou sur l'intranet de la société consiste à  coder des pages Web dynamiques ou à  utiliser un outil de reporting tierce partie. Malheureusement, le coding de pages dynamique est une opération longue qui nécessite généralement un développeur expérimenté et les solutions de reporting tierce partie sont onéreuses.
Grâce à  Reporting Services, des utilisateurs plus ou moins compétents pourront créer leurs propres rapports dynamiques. Bien que vous puissiez ajouter du code à  un rapport pour mieux contrôler le formatage et les données, vous pouvez construire des rapports très élaborés sans aucune expérience de programmation. Vous pouvez présenter des rapports sur Internet ou sur un intranet en plusieurs formats, dont PDF et TIFF, de bonne apparence à  la fois dans un navigateur et sous forme imprimée. De plus, Reporting Services permet d'accéder à  ces rapports de manière commode et sécurisée.
Plutôt que de créer un nouvel environnement de développement pour produire des rapports Reporting Services, Microsoft a utilisé son IDE (integrated development environment) existant, Visual Studio .NET. Vous pouvez créer des rapports avec n'importe quelle édition de Visual Studio .NET 2003. Vous pouvez déployer les rapports provenant de Visual Studio .NET sur un Report Server, qui gère la sécurité, la mise en cache des données et autres fonctions de reporting. Le Report Server délivre les rapports aux destinataires dans divers formats par la méthode pull (à  la demande de l'utilisateur) ou push (livraison planifiée).
La « colle » qui relie le rapport conçu dans Visual Studio .NET au rapport que Report Server délivre est le nouveau RDL (Report Definition Language) de Microsoft. Ce langage de type XML contient toutes les informations concernant la conception de rapports. Vous commencez par créer un rapport comme un document RDL dans Visual Studio. Ce dernier déploie ensuite le RDL sur un Report Server, lequel le stocke dans une base de données SQL Server. Quand Reporting Services délivre un rapport à  un utilisateur, il traite la définition du rapport RDL et le présente dans un format plus usuel comme une page HTML ou un document Adobe PDF.

Tout sur Reporting Services

Vous concevez les rapports en sélectionnant
le type de projet Business
Intelligence dans Visual Studio .NET
2003. Ce type de projet, qui s’installe
en même temps que Reporting
Services, offre deux modèles de
projet : Report Project Wizard, un cheminement
pas à  pas de création de
rapport, et Report Project, qui vous
amène directement au Report
Designer. Le Report Project permet de
construire le rapport à  partir de zéro,
sans le moindre guidage. Les deux modèles
aboutissent à  un projet de rapport.
Vous utiliserez probablement le
Report Wizard pour la plupart des rapports,
particulièrement les tous premiers,
en lui laissant le soin de créer la
présentation d’un rapport initial et la
connectivité à  la base de données.
Vous pourrez ensuite apporter votre
touche personnelle à  l’aide du designer.
Vous utiliserez le Report Project
plus souvent au fur et à  mesure que
vous vous familiariserez avec la structure
du rapport. Puis vous aborderez
des modèles plus complexes.
Quelle que soit la méthode de
création du rapport, la première
étape consiste à  définir une source
de données. C’est la chaîne de
connexion que le rapport utilisera
pour communiquer avec SQL Server,
Analysis Services ou une autre source
de données OLE DB. Vous pouvez
définir une source de données dans
chaque rapport, ou bien la définir
dans le projet de rapport et permettre
son utilisation par de multiples
rapports dans ce projet. En
outre, un rapport peut contenir des
sources de données multiples s’il
doit tirer des informations de plus
d’un endroit. Quand vous utilisez le wizard,
vous définissez la source de données
sur la page Select the Data
Source. Vous pouvez taper la chaîne de
connexion pour référencer la source
de données, ou bien créer une référence
à  celle-ci en cliquant sur Edit et
en utilisant la boîte de dialogue Data
Link Properties qui apparaît.
Si vous voulez que les rapports
s’exécutent automatiquement (sans intervention
humaine), incluez le mot de
passe dans la source de données. Si
vous utilisez la boîte de dialogue Data
Link Properties, cochez la case Allow
Saving Password pour crypter le mot
de passe dans un fichier User Options
que Visual Studio crée localement.
Reporting Services crypte aussi le mot
de passe quand vous déployez le rapport
sur Report Server. Vous pouvez
utiliser des références Windows et
Integrated Security pour accéder à  la
source de données. Cette méthode
convient quand un utilisateur est
connecté au Report Server et qu’il extrait
un rapport interactivement. Elle
ne fonctionne pas quand le Report
Server produit un répertoire planifié,
parce que ce genre de rapport n’a pas
d’utilisateur interactif pour fournir des
références Windows.
Vous créez et modifiez les rapports
dans Visual Studio .NET au moyen du
Report Designer. Cet environnement
de création contient trois zones. La
zone Data permet de construire et de modifier les requêtes qui extrairont
des données destinées au rapport.
Vous construisez le rapport dans la
zone Layout, que montre la figure 1, en
faisant glisser des contrôles provenant
de la Toolbox et des champs provenant
de la fenêtre Fields, et en les déposant
sur le modèle du rapport. La zone
Preview montre quelle sera l’apparence
du rapport quand l’utilisateur
l’extraira.
Dans la zone Data, vous demandez
des données à  partir des sources, pour
en créer un ou plusieurs jeux dans le
rapport. Reporting Services exécute la
requête que vous définissez pour le jeu
de données vis-à -vis de la source de
données. Les lignes et colonnes qui résultent
de cette requête deviennent le
jeu de données. Vous construisez la requête
en utilisant une interface de
construction de requête propre au
type de source de données ou en tapant
la requête directement.
Souvent, vous laisserez à  l’utilisateur
le soin de préciser les valeurs de
paramètres pour la requête du jeu de
données afin de contrôler les lignes à 
renvoyer. Par exemple, vous pouvez
laisser l’utilisateur fournir l’intervalle
de date pour l’information qui apparaîtra
sur un rapport. Si SQL Server est
votre source de données, vous donnerez
à  l’utilisateur cette possibilité en incluant
les paramètres dans la clause
WHERE, en utilisant un signe arobas
(@) suivi du nom du paramètre. Le
code du listing 1 consulte des informations
de ventes dans la base de données
Pubs et inclut trois paramètres :
@StartDate, @EndDate et @StoreID.
(D’autres types de sources de données
pourraient utiliser une syntaxe de paramètres
différente). Le fait d’inclure
ces paramètres de requête dans une
chaîne de requête T-SQL conduit le
Report Designer à  créer trois paramètres
de rapport correspondants, qui
apparaissent comme des champs d’entrée
dans le rapport. La figure 2 montre
l a b o î t e de dialogue Report
Parameters, obtenue en choisissant
Report Parameters sur le menu Report.
Pour que l’utilisateur puisse sélectionner
une valeur dans une liste déroulante,
nous avons amélioré le paramètre
de rapport StoreID en créant un
second jeu de données appelé
StoreNames dans le rapport. Nous
avons sélectionné stor_name dans le
champ Label et stor_id dans le champ
Value. Ce jeu de données demande le
nom de store et l’ID de store à  partir
de chaque enregistrement store puis
peuple la liste déroulante au centre de
la figure 3. Cette configuration présente
les noms de store à  l’utilisateur
dans une liste déroulante et utilise l’ID
store correspondant comme le paramètre
@StoreID.
Quand Reporting Services sert le
rapport, un Content Manager or
Publisher peut spécifier des constantes
pour les valeurs de paramètres, si un
rapport sur un Report Server donné
est toujours subordonné à  un sous-ensemble
de données prédéterminé. Par
exemple, vous pourriez toujours exécuter
un rapport particulier sur un
Report Server pour l’Eastern Region et
le même rapport sur un autre Report
Server pour la Western Region. Si vous
n’avez spécifié aucun de ces paramètres,
l’utilisateur peut le faire dans
l’URL qui demande le rapport. Ou
bien, un rapport parent peut transmettre
des valeurs de paramètres à  un
sous-rapport. Si vous ne spécifiez pas
de paramètres par l’une quelconque
de ces méthodes, Reporting Services
les demandera à  l’utilisateur, comme
on le voit dans la partie centrale de la figure
3.

Téléchargez cette ressource

Sécuriser votre système d’impression

Sécuriser votre système d’impression

Longtemps sous-estimée, la sécurisation d’un système d’impression d’entreprise doit être pleinement prise en compte afin de limiter le risque de fuite d’informations sensibles. Voici les 3 principales précautions à prendre.

Data - Par iTPro.fr - Publié le 24 juin 2010

A lire aussi sur le site

Revue Smart DSI

La Revue du Décideur IT