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
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.
Les articles les plus consultés
- Stockage autonome, Evolutivité & Gestion intelligente, Pure Storage offre de nouvelles perspectives aux entreprises
- 9 défis de transformation digitale !
- ActiveViam fait travailler les data scientists et les décideurs métiers ensemble
- Intelligence Artificielle : DeepKube sécurise en profondeur les données des entreprises
- Dark Web : où sont vos données dérobées ?