eQ Services PFE

eQ Services

Projet de Fin d’Études pour l’obtention du titre d’Ingénieur d’Etat en Génie Informatique

Réalisation d’une solution de Reporting invocable via des services Web pour une application de questionnaire en ligne

Réalisé par : Fayçal TIRICH Distribution

Nom Organisation / Poste Florent BOUQUEROD HyperObjects: directeur général Pascal LIEBART HyperObjects: Responsable e-Questionnaire Brahim ER RAHA ENSA Agadir: Encadrant

eQ Services

I. Dédicace

À mes chers parents qui m’ont soutenu tout au long de mes études ainsi que dans ma vie

entière, pour les sacrifices qu'ils ne cessent de m’offrir, je vous dédie ce travail avec tout le

respect que je vous garderai.

À mes chers sœurs et frères, à toute ma famille et à tous mes amis.

À mes formateurs et à mes encadrants.

eQ Services

II. Remerciements

Le travail présenté dans ce mémoire a été effectué pour le compte de la SSII française

HyperObjects. J’aime donc exprimer ma reconnaissance à tous ceux qui ont contribué à la

réalisation de ce projet et plus particulièrement à Monsieur Florent BOUQUEROD pour

l’encadrement architectural, Monsieur Pascal LIEBART pour le suivi fonctionnel de mon travail

et Mademoiselle Marine FLORET pour l’intégration technique. Je tiens à féliciter leur

disponibilité durant toute la période de mon stage et aussi leur sympathie qui a permis de

créer un environnement de travail plus détendus.

J’adresse aussi mes remerciements au corps professoral de l’ENSA et spécialement mon

encadrant Monsieur Brahim ER RAHA ainsi que tout le staff administratif.

Enfin un clin d’oeil à tous les élèves ingénieurs de ma promotion, ainsi que toute personne qui

a contribué de près ou de loin à l’élaboration de ce travail.

eQ Services

III. Table des matièresI. Dédicace

II. Remerciements

III. Table des matières

IV. Liste des figures et des tableaux

V. Introduction 1

VI. Sujet de stage 3 A. Situation .......................................................................................... 3 B. Objectifs........................................................................................... 3 C. Tâches à réaliser ............................................................................... 3 D. Qualités requises ............................................................................... 4 E. Coachs ............................................................................................. 4

VII. Analyse de l’existant 5 A. Organisation ..................................................................................... 5 B. Présentation du e-Questionnaire v 4.5 .................................................. 6 C. Caractéristiques logicielles et matérielles............................................... 6 D. Limitations et perspectives .................................................................. 7 E. Planning prévisionnel.......................................................................... 8

VIII. Méthodologies de travail 9 1. Introduction............................................................................... 9 2. Découverte de l'eXtreme Programming .......................................... 9 3. eXtreme Programming en détails ................................................ 11

a) La naissance ................................................................................ 11 b) XP face aux méthodes traditionnelles............................................... 11 c) Le cycle de développement............................................................. 11 d) Les valeurs du XP ......................................................................... 12 e) Les pratiques du XP....................................................................... 12

4. Conclusion ............................................................................... 13

IX. eQ Charting Services 14 A. Introduction .................................................................................... 14 B. User Stories .................................................................................... 14 C. Architecture .................................................................................... 15

1. Architecture générale ................................................................ 15 2. eQ Générateur Dynamique des Diagrammes................................. 15

a) XmlDocument Provider .................................................................. 15 b) XmlToDataView Mapper ................................................................. 16 c) eQDDG Engine.............................................................................. 20 d) eQ Parameters ............................................................................. 25 e) Conclusion ................................................................................... 26

3. Partie Services Web .................................................................. 26 a) Introduction ................................................................................. 26 b) Caractéristiques d’un service Web ................................................... 27 c) Services Web : Le cas eQ ............................................................... 28 d) Service Oriented Architecture ......................................................... 28

eQ Services

e) Web Services Description Language................................................. 29 f) Simple Object Access Protocol ......................................................... 31 g) Les services Web sous le framwork .NET 2.0..................................... 33 h) Utilisation des services Web avec ASP.............................................. 34

D. Conclusion générale ......................................................................... 35

X. eQ Reporting Services 41 A. Introduction .................................................................................... 41 B. La génération des rapports dans eQ 4.5 .............................................. 41 C. Objectifs......................................................................................... 41 D. Enjeux du module eQ Reporting Services ............................................ 42 E. Étude des outils existants ................................................................. 42

1. Business Objects Crystal Report XI.............................................. 42 a) Introduction ................................................................................. 42 b) Fonctionnalités ............................................................................. 42 c) Architecture ................................................................................. 43 d) Création des rapports .................................................................... 43

2. SQL Server 2005 Reporting Services ........................................... 44 a) Introduction ................................................................................. 44 b) Fonctionnalités ............................................................................. 44 c) Architecture ................................................................................. 44 d) Création des rapports .................................................................... 45

3. Conclusion ............................................................................... 46 F. Solution adoptée.............................................................................. 48

1. Introduction............................................................................. 48 2. Architecture ............................................................................. 48 3. Explications ............................................................................. 49 4. Conclusion ............................................................................... 52

XI. Perspectives 53

XII. Conclusion générale 55

XIII. Références 56 A. Méthodologie .................................................................................. 56 B. POO, .NET et Infragistics................................................................... 56 C. XML ............................................................................................... 56 D. Services Web .................................................................................. 56

XIV. Annexe 57 A. Microsoft .NET Framework................................................................. 57

1. Introduction............................................................................. 57 2. Base Class Library .................................................................... 57 3. Le CLR et MSIL......................................................................... 57 4. ASP.NET.................................................................................. 58

B. Le modèle objet du eQ Charting Services ............................................ 59 1. Le module XmlDocument Provider ............................................... 59 2. Le module Xml To DataView Mapper............................................ 60 3. La Classe eQ Web Service .......................................................... 60 4. Le moteur eQGDD Engine .......................................................... 61 5. Les classes de base du eQGDD Engine ......................................... 62

eQ Services

IV. Liste des figures et des tableaux Figure 1 : Démarche non agile de gestion de projets ............................................................... 9 Figure 2 : Démarche agile de gestion de projets ................................................................... 10 Figure 3 : Cycle de vie du XP ............................................................................................. 11 Figure 4 : Architecture générale du eQ Charting Services ....................................................... 15 Figure 5 : Organigramme du module XML to DataView Mapper ............................................... 17 Figure 6 : Arrangement d’un XML d’une question simple ........................................................ 18 Figure 7 : Arrangement d’un XML d’une question groupée pondérée ........................................ 19 Figure 8 : Arrangement d’un XML d’une question groupée non pondérée .................................. 19 Figure 9 : Programmation classique .................................................................................... 20 Figure 10 : Programmation agile ........................................................................................ 21 Figure 11 : Modèle objet du eQGDD Engine.......................................................................... 23 Figure 12 : Aperçu sur l’utilisation de l’abstraction ................................................................ 24 Figure 13 : Aperçu sur un fragment du fichier de paramétrage................................................ 26 Figure 14 : Les services offerts par eQ Charting Services ....................................................... 29 Figure 15 : WSDL en action ............................................................................................... 30 Figure 16 : Aperçu sur le fichier WSDL du eQ Charting Services .............................................. 31 Figure 17 : L’assistant visuelle du Web Developer basé sur le WSDL ........................................ 31 Figure 18 : Exemple d’une demande SOAP de la méthode GetChartStream() ............................ 32 Figure 19 : Réponse positive du service Web via la balise <GetChartStreamResult> .................. 32 Figure 20 : Réponse négative du service Web via la balise <soap:Fault>.................................. 33 Figure 21 : Déclaration d’un service Web sous .NET .............................................................. 33 Figure 22 : Consommation bas niveau d’un service Web depuis ASP ........................................ 34 Figure 23 : Consommation d’un service Web en utilisant MS SOAP ToolKit pour ASP .................. 35 Figure 24 : Procédure du sauvegarde physique de l’image du diagramme................................. 35 Figure 25 : L’ancienne version de la partie analyse du eQ ...................................................... 36 Figure 26 : Les nouveaux paramètres des diagrammes offerts au client ................................... 37 Figure 27 : Résultat du service Web.................................................................................... 38 Figure 28 : Architecture d’une solution de Reporting avec Crystal Report.................................. 43 Figure 29 : Architecture d’une solution de Reporting avec Reporting Services............................ 45 Figure 30 : Architecture du eQ Reporting Services ................................................................ 48 Figure 31 : Les services offerts de génération de PDF ............................................................ 49 Figure 32 : Invocation du service Web eQ Reporting depuis ASP ............................................. 50 Figure 33 : Exemple de génération complexe des rapports PDF............................................... 51 Figure 34 : Aperçu sur les nouveaux diagrammes de eQ Charting Services v2........................... 54 Figure 35 : Exemple de diagramme financier visé dans la deuxième version du eQ .................... 54 Figure 36 : Architecture du Framework .NET ........................................................................ 57 Figure 37 : le Common Language Runtime........................................................................... 58 Figure 38 : La classe XmlDocumentProvider ......................................................................... 59 Figure 39 : La classe QuestionInfo ...................................................................................... 60 Figure 40 : La classe WebService eQ................................................................................... 60 Figure 41 : La classe eQGDD.............................................................................................. 61 Figure 42 : Le modèle objet du eQGDD Engine ..................................................................... 62 Figure 43 : Exemple d’abstraction et d’héritage du eQGDD..................................................... 63 Tableau 1 : Caractéristiques matérielles et logicielles du eQ v4.5 .............................................. 7 Tableau 2 : Planning prévisionnel ......................................................................................... 8 Tableau 3 : Exemple de diagrammes générés....................................................................... 40 Tableau 4 : Synthèse comparative de Crystal Report et Reporting Services............................... 47 Tableau 5 : Convention de la notation POO utilisée ............................................................... 59

eQ Services

1

V. Introduction Après la centralisation de l’information en ligne et le phénomène du commerce électronique, c’est à

présent le tour de l’ère des applications Web de marquer un nouveau tournement radical dans la

manière d’aborder et de gérer le côté informatique des secteurs économiques.

Ces nouveaux services loués par des entreprises appelées Fournisseur d’Applications Hébergées

(FAH) - ou Application Server Provider (ASP) en anglais - sont capables de proposer des outils à

forte valeur ajoutée aussi bien pour les PME que pour les grandes structures.

Cette manipulation s’inscrit dans le cadre de ce qui est couramment connu par l’externalisation ou

l’outsourcing ; C’est un processus par lequel une entreprise confie à un prestataire extérieur la

responsabilité de la gestion d'un domaine (ou d'une fonction) qu'elle-même peut assumer

directement en interne au moyen d'une combinaison spécifique de ressources propres.

Le FAH ne se limite pas à la seule mise à disposition d'un logiciel. En effet, le prestataire FAH

héberge et gère le logiciel et ses différentes versions, effectue les opérations de maintenance

classique, applique les mises à jour éditeur et, de façon plus générale, effectue toutes les tâches

déléguées normalement à la direction des services informatiques de l’entreprise cliente.

Afin d'apporter une solution aux sociétés qui ne disposent pas de structures informatiques et de

compétences internes suffisantes, le FAH a été développé au départ à destination des PME.

Cependant, vu tout l'avantage économique dégagé par cette démarche, ses fournisseurs ont plutôt

été aussi contactés par des grands groupes, et leurs clientèles ne se limitent plus aux simples

entreprises ou associations mais incluent aussi des grandes organisations privées et

gouvernementales.

Réduire les coûts, contrôler les dépenses, diminuer le délai du début d’exploitation, bénéficier du

savoir faire des FAH, éviter le piratage et l’utilisation illégale des produits, mieux connaître et tracer

la clientèle… Il faut dire que les attributions des FAH ne sont plus à démontrer.

www.e-questionnaire.com en est une belle démonstration : Ce service peut être loué et utilisé

directement par des managers et des responsables ne disposant pas forcément de compétences

informatiques avancées, évitant donc aux entreprises de réaliser eux-mêmes des applications pour

leurs questionnaires voire pire opter pour une démarche non informatisée.

Que se soit une compagne marketing, une étude de marché, un audit interne ou tout simplement

une enquête de satisfaction, cette application s’avère très flexible en s’adaptant à un grand nombre

d’applications surtout qu’elle nécessite pas d’installation mais tout simplement une connexion

Internet et un navigateur Web.

http://www.e-questionnaire.com/

eQ Services

2

De la création personnalisée des questions à l’analyse avancée des résultats en passant par la

diffusion et le suivi de la population interrogée, e-Questionnaire est une solution compacte,

autonome et performante et surtout un choix stratégique et économique vu les tarifs compétitifs

non comparables aux charges potentielles (logicielles, matérielles et humaines) que l’entreprise

allait supporter si elle avait adopté un développement interne de toutes pièces.

Mon projet consiste à améliorer certaines fonctionnalités de cette solution de questionnaire en

ligne, l'évolution de ce projet s'est poursuivie sur la lignée d’un cahier de charges qu’a dû aussi

connaître des améliorations fréquentes. Cela a donné naissance à plusieurs éléments reliés mais

autonomes en même temps. Afin d'éviter un discours incohérent, la suite de ce rapport suivra la

structure des différents modules qui composent le projet final.

Je discuterai d'abord globalement de la version actuelle de e-Questionnaire, les buts attendus de

mon PFE et la méthodologie de travail que j'ai employée.

Suivra ensuite une section pour chacun des éléments importants du projet. Chacune de ces

sections contiendra une description plus ou moins détaillée de la problématique à résoudre, de la

méthodologie employée, de l’architecture adoptée et d’un aperçu sur le résultat final.

Finalement je conclurai par un bilan global des résultats de ce projet ainsi que de ses suites et

perspectives futures.

eQ Services

3

VI. Sujet de stage Le sujet initial du stage a été décrit de la manière suivante : Adjonction de nouveaux modules à eQ

v4.5.

A. Situation HyperObjects a développé et anime le service en ligne e-Questionnaire qui permet à ses clients de

créer, de diffuser et d’analyser leurs propres enquêtes en toute autonomie. Ce service de gestion

d’enquêtes en ligne est commercialisé en mode ASP (Application Service Provider).

La version actuelle d’e-Questionnaire (v4.5) a été développée en ASP 3.0 et continue à grandir tous

les jours en fonctionnalités. HyperObjects souhaite aujourd’hui faire évoluer son application vers

des technologies plus récentes permettant de gagner en productivité sur tous ses développements

spécifiques.

Cependant, le développement d’une révision majeure de l’application est très délicat à l’heure

actuelle. HyperObjects souhaite donc privilégier le développement de modules fonctionnels et

autonomes sous forme de Web services invocables depuis la version actuelle d’e-Questionnaire.

B. Objectifs Les principaux modules à développer sont :

• Service Web dédié à la génération de diagrammes

• Service Web dédié à la génération de rapports (à cette occasion une investigation sera à faire

sur SQL Server 2005 avec Analysis And Reporting Services et Business Objects Crystal Report

Server)

C’est donc aussi l’occasion de passer sur des technologies plus récentes comme :

• SQL Server 2005 avec Analysis And Reporting Services ou bien Business Objects Crystal Report

Server

• ASP.NET 2.0

• Composants Infragistics.

Des difficultés d’intégration sont à prévoir (ces services devront être invoqués depuis un

environnement non .NET).

C. Tâches à réaliser • Se familiariser avec les outils mis en oeuvre (SQL Server, Visual Studio 2005, Business Objects

Crystal Report Server et composants .NET)

eQ Services

4

• Créer des modules en C# et ASP.NET 2.0 et des démonstrations de clients ASP consommateurs

en respectant les spécifications de construction délivrées par mon coach.

• Concevoir des architectures en services Web.

• Dialoguer efficacement avec mon coach à travers les différents outils mis à ma disposition

(Email, VOIP, IM…).

• Livrer du code robuste, testé et documenté

• Rédiger de la documentation en Français.

D. Qualités requises • Indépendance, relation « client - fournisseur » avec l’équipe de développement de Grenoble

• Esprit d’initiative, démarche expérimentale, force de proposition.

E. Coachs • Pascal LIEBART (fonctionnel)

• Florent BOUQUEROD (technique)

• Marine FLORET (intégration).

eQ Services

5

VII. Analyse de l’existant A. Organisation HyperObjects est une SSII (Société de Services en Ingénierie Informatique) de petite taille,

spécialisée dans les technologies Windows/Web. Fondée en 1996 à l’initiative de Florent

BOUQUEROD, diplômé de l’École Centrale de Paris et de Pascal DUBESSET, diplômé de l’ESC

Grenoble, celle-ci est située dans le quartier St-Bruno de Grenoble. Ils ont été rejoints en 1999 par

Philippe GRAÇA, diplômé de l’INSA de Lyon et l’actuel directeur technique.

Trois métiers sont au cœur de leurs activités:

• SSII spécialisée en systèmes d’information marketing

• Editeur de solutions

• Fournisseur d’Application Internet

Grandement insufflées par les fondateurs d’HyperObjects, les valeurs clés de l’entreprise reposent

sur trois piliers que sont le professionnalisme, la productivité et la pro activité. Ceux-ci sont

omniprésents au sein de l’entreprise dans le travail effectué et se confirment d’année en année.

Par son professionnalisme et par la réactivité de ses équipes de développement, HyperObjects a

réussi à lier très rapidement des liens commerciaux forts avec de grands noms de l’industrie et de

l’administration tels que Hewlett Packard, Schneider, Ricoh, ainsi que le Ministère de l’Equipement,

des Transports et du Logement.

En ce qui concerne les forces de la société, il apparaît clairement que la spécialisation de niche sur

le marché des systèmes d’informations marketing est un pilier pour son développement. De plus, le

fait de travailler avec de gros clients, comme HP, est un atout indéniable auprès de ses prospects.

En revanche, sa forte dépendance à HP, qui représente la majorité de son chiffre d’affaire, se

révèle être une de ses faiblesses principales. L’entreprise essaie aujourd’hui de s’affranchir en

devenant un éditeur de logiciel d’un produit de gestion de catalogue électronique.

Au niveau de la vitalité de l’entreprise, HyperObjects a été retenu pour sa forte croissance ses

dernières années (+228% de CA en 5 ans) lors de l'édition 2004 du Deloitte Technology Fast 50 qui

a réuni 259 entreprises. Le Fast 50 est devenu l’indicateur de référence du succès pour les

entreprises technologiques de croissance. HyperObjects a également été classé au niveau européen

dans le classement européen appelé Fast 500.

HyperObjects est composée de deux départements fonctionnels et d’un service, le département

«PIM» (Product Information Management), le service «e-Questionnaire» et le département

«Publications». Le premier, comme son nom l’indique, a pour mission le développement et la

maintenance des solutions de gestion de contenu telles que W-Esperanto (pour HP). Le service «e-

eQ Services

6

Questionnaire», qui est en charge de l’application portant son nom, se compose d’une seule

personne. Il peut arriver qu’une ressource du département PIM y soit allouée pour une période

temporaire en cas de besoin. Enfin Le département « Publications » qui se charge de la publication

des données ayant transitées par le département « PIM ».

B. Présentation du e-Questionnaire v 4.5 e-Questionnaire v4.5 comme a été mentionné auparavant, englobe toutes les étapes de création,

diffusion et d'analyse d'une enquête en ligne professionnelle. Ma mission par contre sera plutôt

focalisée sur la partie analyse.

Tous les résultats fournis par e-Questionnaire v4.5 sont sous forme de tableaux et de graphiques

détaillés. La version actuelle permet de choisir des graphiques parmi une bibliothèque de 17 styles:

• Secteurs (simples, éclatés, empilés)

• Histogrammes (simples, empilés, empilés à100%)

• Barres (simples, empilées, empilées à 100%)

• Courbes (simples, empilées, empilées à 100%)

• Anneaux (simples, éclatés)

• Radar (simple, plein)

• Surface.

On peut alors visualiser les réponses individuelles de chaque répondant ou choisir de construire un

rapport. Pour chaque question on peut choisir le graphique le plus sensé par rapport à la nature de

la question et la tendance qu'on veut mettre en évidence. On peut consolider dans un deuxième

temps le rapport en supprimant certaines réponses jugées non représentatives via des filtres ou en

faisant recours à une fonction de croisement qui permet de réaliser une analyse croisée entre deux

questions fermées.

Enfin l'utilisateur a le choix de télécharger le rapport final contenant les différents graphes et

tableaux au format Microsoft Word ou HTML.

C. Caractéristiques logicielles et matérielles Tous les éléments des questionnaires sont gérés et stockés dans des fichiers XML. Ces derniers (et

pour améliorer l'efficacité) passent par une étape de «dénormalisation» de données via des

procédures stockées afin de faciliter leurs utilisations dans des rapports.

Cette performance et cette grande flexibilité sont rendues possible grâce à l'alliance entre de

grands standards logiciels et matériels qui ont déjà fait leurs preuves.

eQ Services

7

Architecture client/serveur (Web) Stockage des questionnaires XML Mise en forme des questionnaires XSL, CSS2

SGBD SQL Server 2000 Composants COM/COM+

Serveur Web IIS 5.0 updated OS Windows Web 2000 Serveurs HP NetServer LP2000R

Processeurs Double Pentium 4, 1Ghz Mémoires 760Mo SDRAM Bande passante 2048MB

Tableau 1 : Caractéristiques matérielles et logicielles du eQ v4.5

D. Limitations et perspectives Victime de son propre succès, e-Questionnaire v4.5 a de plus en plus du mal à supporter seul la

charge des milliers d'utilisateurs instantanés. L'introduction donc d'un nouveau serveur s'impose. Et

vu leurs appétits excessifs aux ressources matérielles, il était clair que le module de génération des

rapports graphiques soit le candidat le mieux placé pour avoir l'honneur d'être hébergé dans la

nouvelle machine.

eQ Services

8

E. Planning prévisionnel mars avril mai juin juillet

9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

1 Familiarisation avec l'environnement et étude de l'existant

2 Étude avancée du XML et Infragistics dans le Framework .NET 2.0

3 Prototype du eQ Générateur Dynamique de Diagrammes (eQGDD)

4

eQ Web Service basé sur eQGDD en C# et exemple démonstration d'un client en ASP

5 Déploiement et adaptation du eQ Web Service et rédaction de sa documentation détaillée

6

Investigation avancée sur Reporting Services 2005 et Crystal Report et définition d'un cahier de charges adapté à eQ

7 Mise en oeuvre d'un premier prototype du eQ Reporting Services

8 Amélioration du prototype et déploiement de la solution

9 Finalisation du rapport final et préparation de la soutenance

Tableau 2 : Planning prévisionnel

eQ Services

9

VIII. Méthodologies de travail 1. Introduction Mon stage a démarré par une phase d'exploration volontairement étalée sur un mois. La première

quinzaine a été consacrée à une mise à niveau générale focalisée sur les nouveautés implémentées

par le Framework .NET 2.0, après je me suis plutôt concentré sur les classes et les composantes

qui m'ont apparues les plus susceptibles d’être utilisées d’après mon cahier de charge initial.

2. Découverte de l'eXtreme Programming À première vue, cela apparaît hasardeux de me lancer directement dans la programmation sans

passer par la démarche traditionnelle basée sur la célèbre séquence: spécification -> conception ->

réalisation -> validation.

À vrai dire, sans s’en rendre compte immédiatement, Monsieur Florent BOUQUEROD me faisait

initier à l'eXtreme Programming (XP) qui est un processus de développement logiciel et surtout un

des principaux représentants d'une famille apparaissant de processus: Les processus dits «agiles».

Normalement, avec les méthodes classiques, une grande partie est réservée à des entretiens avec

le client qui essaye d'exprimer son besoin particulier à des développeurs qui se trouvent souvent

face à du ''jamais vu''. Ces derniers tentent alors de croiser ce ''jamais vu'' avec leur expérience du

''déjà vu'' afin de réaliser une modélisation abstraite (totalement incompréhensible par le client

final) sur quoi se baser pour réaliser une application fonctionnelle avec des interfaces homme-

machine livrées aux optimistes des cas juste quelques semaines avant la fin officielle destinée à la

période du projet.

Conception Réalisation Livraison

Figure 1 : Démarche non agile de gestion de projets

Malheureusement, on est loin de vivre dans un monde parfait. Les équipes de développement qui

évoluent souvent dans un environnement changeant ou complexe savent déjà à quel point il est

difficile de s’en tenir aux décisions initiales.

Le client réalise que ses besoins ont changé, ou bien l’équipe découvre en phase d’implémentation

des erreurs de spécification ou de conception qui compromettent le plan initial du développement.

Le changement s’impose donc tôt ou tard… Mais voilà, cette organisation suppose l’absence de

changement, et celui-ci se révèle bien vite très coûteux, suffisamment parfois pour contrarier la

rentabilité du projet.

eQ Services

10

Mais puisque le changement est une composante incontournable de tout projet de développement

logiciel, pourquoi ne pas l’accepter ? N’existe-t-il pas un moyen pour que les équipes de

développement ne s’opposent plus à une inflexibilité gelée de la part de leur livrable face aux

demandes du client final ?

Les créateurs du XP ont trouvé une réponse à ces questions en découvrant que certaines pratiques

d’organisation d’équipe et de programmation, permettent de rendre le logiciel extrêmement agile à

tel point qu’il devient plus avantageux de le faire évoluer progressivement que de chercher à le

spécifier et le concevoir complètement dès le départ.

Partant de ce constat, ils ont conçu une démarche qui diffuse le processus de décision tout au long

du projet grâce à l’enchaînement de cycles itératifs très courts :

Livraison Livraison Livraison Livraison Livraison Livraison

Figure 2 : Démarche agile de gestion de projets

Le grand gagnant de cette démarche est d’abord le client du projet. Plutôt que de voir son

intervention limitée à la phase initiale de recueil du besoin, il intègre véritablement le projet pour

en devenir le pilote.

A chaque itération, il choisit lui-même les fonctionnalités à implémenter, collabore avec l’équipe

pour définir ses besoins dans le détail, et reçoit une nouvelle version du logiciel qui intègre les

évolutions en question.

Cette démarche présente de nombreux avantages en termes de conduite de projet :

• Le client jouit d’une très grande visibilité sur l’avancement du développement

• Le client utilise le logiciel lui-même comme support de réflexion pour le choix des

fonctionnalités à implémenter. Il peut en particulier intégrer très tôt les retours des utilisateurs

pour orienter le développement en conséquence

• La première mise en production du logiciel intervient très tôt dans le projet, ce qui avance

d’autant le moment à partir duquel le client peut en tirer des bénéfices

• L’ordre d’implémentation des fonctionnalités n’est pas guidé par des contraintes techniques,

mais par les demandes du client. Celui-ci peut donc focaliser les efforts de l’équipe sur les

fonctionnalités les plus importantes dès le début du projet, et ainsi optimiser l’utilisation de son

budget.

eQ Services

11

3. eXtreme Programming en détails a) La naissance On doit XP particulièrement à Kent Beck, un consultant et un vétéran de programmation avec le

langage SmalTalk. Elle a été instaurée lors d'un projet nommé le « Chrysler Comprehensive

Compensation » ou « C3 » pour le compte du groupe américain Daimler Chrysler. Après, L'XP est

né officiellement en octobre 2000 avec le livre «Extreme Programming Explained».

b) XP face aux méthodes traditionnelles Par rapport aux autres méthodes plus traditionnelles comme RAD et Unified Process (qui s'appuie

sur UML), les professionnels répètent qu’il serait une erreur de les opposer aux méthodes agiles. XP

peut être vu plutôt comme une déclinaison de Unified Process (UP), en ayant bien en tête

cependant que c’est le client qui rédige les spécifications en XP contrairement à UP où les

spécifications sont une interprétation de ce qui a été compris par l’informaticien. Aussi, les

itérations qui sont un des principes des deux méthodes sont environ 6 fois plus fréquentes en XP.

Ainsi, les méthodes classiques et les méthodes agiles sont complémentaires.

UML qui est une méthode de modélisation n’est pas aussi comparable à XP qui est une méthode de

réalisation et d’organisation. D’ailleurs, XP utilise le langage universel qu’est UML pour

communiquer. Toutefois, par sa volonté de rapidité, XP reste prudent sur l’utilisation d’UML. Pour

cause, les diagrammes UML sont trop longs à réaliser alors que la conception en XP étant très

courte et réalisée au fur et à mesure.

c) Le cycle de développement

Approbation client

Scénarios utilisateur

Exploration Planning Itération Test d’acceptation

Estimations

Nouveaux scénarios

Spécifications

Figure 3 : Cycle de vie du XP

XP vise une réduction significative de la durée du cycle de développement, c’est-à-dire du temps

qui s’écoule entre le moment où l’on décide d’implémenter une fonctionnalité et celui où l’on met

en production une nouvelle version du logiciel qui intègre la fonctionnalité en question.

L'organisation en itérations fréquentes validées à chaque fois par le client constitue l'innovation de

XP en matière de réduction du temps de développement. L'équipe peut casser parfois la structure

en place lorsque l’ajout de nouvelles fonctionnalités l’exige, ou bien lorsque elle découvre des

eQ Services

12

défauts dans la mécanique existante, mais elle peut jamais avoir l’impression de revenir en arrière

ou de perdre du temps inutilement.

XP apporte des solutions concrètes à ces problématiques, avec un ensemble de pratiques qui forme

un système cohérent et efficace.

d) Les valeurs du XP XP repose sur 4 valeurs fondamentales:

• La communication: c'est le moyen fondamental d'éviter les erreurs. Le moyen à privilégier est la

conversation directe, en face à face. Les moyens écrits ne sont que des supports et des moyens

de mémorisation

• Le courage: il est nécessaire à tous les niveaux et de la part de tous les intervenants,

notamment chez les développeurs (quand des changements surviennent à un stade avancé du

projet, ou quand des défauts apparaissent) et chez le client (qui doit pouvoir prioriser ses

demandes)

• Le retour d'information (feedback): les itérations sont basées sur les retours d'informations du

client, permettant une adéquation totale entre l'application finale et sa demande;

• La simplicité: en XP, la façon la plus simple d'arriver à un résultat est la meilleure. Prévoir

préalablement des évolutions futures n'a pas de sens. Ce principe est résumé en une phrase:

«Tu n'en auras pas besoin.» (en anglais «You ain't gonna need it.»). La meilleure manière de

rendre une application extensible est de la rendre aussi simple (et donc simple à comprendre)

et aussi bien conçue que possible.

e) Les pratiques du XP Ces 4 valeurs se déclinent en 13 pratiques:

• Client sur le Site (On-Site Customer) : Pour une meilleure communication, le client et les

développeurs travaillent dans le même espace autant que possible.

• Séance de Planification (Planning Game) : Le client définit les scénarios utilisateurs prioritaires.

Les développeurs discutent le contenu de ces scénarios, définissent les tâches techniques sous-

jacentes, estiment ces tâches et y souscrivent.

• Intégration Continue (Continuous Integration) : Le système est intégralement assemblé et testé

une à plusieurs fois par jour.

• Livraisons Fréquentes (Frequent Releases) : Le rythme des livraisons est de l'ordre de quelques

semaines.

• Rythme Soutenable (Forty-hour Week) : L'équipe ne fait pas d'heures supplémentaires deux

semaines de suite.

• Tests de Recette (Acceptance Tests) : Retour d'information rapide sur le système, en général

automatisé, constitué à partir de critères de tests définis par le client.

eQ Services

13

• Tests Unitaires (Unit Tests) : Tests automatisés écrits pour chaque classe, chaque méthode, et

pour tout "ce qui pourrait casser" en général. Ces tests doivent passer à 100% continuellement.

• Conception Simple (Simple Design) : Le code doit passer tous les tests et répondre aux critères

de maintenabilité : concision, modularité, cohérence, lisibilité.

• Métaphore (Metaphor) : Une analogie utilisée comme modèle conceptuel du système en cours

de développement.

• Remaniement Continu ou Refactorisation de Code pratiquée sans relâche : modification du code

par laquelle on améliore sa conception sans en modifier le comportement.

• Convention de Code (Coding Standard) : Le code doit suivre une convention de nommage et de

présentation afin d'être lisible par tous les membres de l'équipe.

• Programmation En Binôme (Pair Programming) : Le code de production est toujours écrit par

deux développeurs : le pilote et le copilote. Les binômes changent au cours du projet.

• Propriété Collective du Code (Collective Code Ownership) : Chaque développeur peut modifier

chaque partie du code si le besoin s'en fait sentir.

4. Conclusion L’eXtreme Programming est une méthode révolutionnaire pour la gestion de projets informatiques.

Basée sur des principes simples, elle permet de venir enfin à bout des dépassements de délais et

donc de budget, tout en utilisant des pratiques agiles et adaptables face aux changements

fréquents des spécifications initiales.

Parmi ces pratiques, La démarche itérative de l’eXtreme Programming s’avère être le principal

atout surtout du point de vue de la maîtrise d'ouvrage.

eQ Services

14

IX. eQ Charting Services A. Introduction Ce chapitre a pour but de fournir un aperçu général sur le fonctionnement et les services offerts par

le module eQ Charting Services.

Cet aperçu est assisté par une description détaillée de l'ensemble de l'architecture adoptée afin

d'essayer de justifier au mieux les choix faits pour la conception et la réalisation technique du dit

service web.

B. User Stories Mon coach fonctionnel Pascal LIEBART a joué le rôle de mon client fictif direct. Sa grande

expérience et son sens de communication et de marketing lui ont permet d’avoir une perception

claire et limpide des besoins et des attentes des vrais clients finaux.

Ces spécifications peuvent être résumées comme suit:

• Créer des images représentant les diagrammes des questionnaires

• La source de données pour les diagrammes sera un fichier XML publié par la version ASP du eQ

• Le service Web devra pouvoir, dans un premier temps, choisir pour l'utilisateur final le

diagramme le plus adapté pour chaque question demandée. Après, l'utilisateur pourra à tout

moment personnaliser ce choix

• Les diagrammes générés doivent être facilement paramétrables

• Mise en oeuvre d'une démonstration d'un client en ASP consommant le service Web et générant

du code HTML contenant l'image résultante.

eQ Services

15

C. Architecture

1. Architecture générale

Flux

<?xml… <Report…

Xml To DataView Mapper

Chargement Importation

Réorganisation et filtrage

Paramètres personnalisés

Paramètres par défaut

Infragistics DLL

Code binaire

XML

XmlDocument

Provider

eQ ASP Client

eQ Dynamic Diagrams

Generator Engine

eQ Web Service

<?xml… <Width… <Height… SOAP

HTTP+XML

Source de données XML

Figure 4 : Architecture générale du eQ Charting Services

2. eQ Générateur Dynamique des Diagrammes a) XmlDocument Provider Ce module a pour fonction de retourner un objet XmlDocument représentant la structure XML des

données à analyser. XmlDocument est définie par le .NET 2.0 comme étant une classe qui

implémente le W3C Document Object Model (DOM). Le DOM est une représentation sous forme

d'arborescence en mémoire indépendante (cache) d'un document XML qui permet l'exploration de

ce document et sa modification.

J'ai opté pour l’isolation de cette fonction dans une classe à part, vu que la nature du canal de

transmission des données reçues en amont pouvait à tout moment changer. Par exemple dans un

eQ Services

16

premier temps, c'était temporairement un fichier XML accessible via un URL, après on a plutôt

adopté un flux communiqué par un service Web du côté ASP, ça pouvait aussi être un service offert

directement par le moteur SQL Server...

Donc, pour plus d'agilité, le reste du cheminement de la solution n'a pas à se préoccuper du

«Comment», les données sont récupérées, ce qui compte pour les autres composantes, c'est

s'attendre à un objet XmlDocument.

b) XmlToDataView Mapper Une fois la structure des données XML récupérée, il faut à présent la préparer pour être exploitable

dans la génération des diagrammes correspondants. En fait, la structure XML qui m'est fournie,

n'est pas optimisée uniquement pour mon service Web mais elle est aussi exploitable dans d'autres

applications externes.

Du coup je me trouve face à une structure non normalisée dont on ne peut tirer profit qu'après un

filtrage et une réorganisation des données. Autrement dit, il faut faire un «mapping» d'une

structure hiérarchique (XML) vers une autre structure tabulaire (Table) tout en gardant entre

temps, que les données nécessaires pour le diagramme.

Donc après récupération du XmlDocument de la part du premier module XmlDocumentProvider, je

le fais passer par une étape de nettoyage et de filtrage. Vu la complexité du jeu de données qui

m’est fournie, les expressions de filtrage XPath se sont vite trouvées face à leurs limites et j’ai dû

les supporté par les possibilités d’itération offertes par le langage C#.

Une fois débarrassé des nœuds et attributs inutiles, on n’a nul besoin d’avoir une copie physique de

la structure tabulaire générée, si non, la performance sera sans doute pénalisée avec les allés

retours entre le module et la base de données.

.NET 2.0 se montre en parfaite adéquation avec nos besoins car il nous offre la classe DataTable

qui représente une table de données mais uniquement stockée et gérée en mémoire. C’est une

sorte de super tableau fortement typé qui contient une collection d’objets DataColumn. Après, pour

peupler la dite DataTable, on utilise la méthode NewRow qui retourne un nouvel objet DataRow

respectant le schéma de la collection des colonnes.

Une fois la DataTable créée et remplie, il se peut qu’on aille à la trier et la filtrer en cas de besoin.

Toujours avec le même espace de nom que celui de la DataTable (System.Data), on a aussi droit à

une autre classe DataView qui représente une vue personnalisée d’une DataTable pouvant faire

l'objet de liaisons de données pour le tri, la recherche, la modification et la navigation.

On peut encapsuler toutes ses étapes par l’organigramme suivant:

eQ Services

17

Figure 5 : Organigramme du module XML to DataView Mapper

Chercher la question

Question Id

Question Simple ou groupée?

Isoler le groupe de questions

Isoler les nœuds de modalités

Groupe pondéré?

Isoler pour chaque question son groupe de

modalités

Isoler pour chaque question

sa moyenne

Créer à la volée la DataTable

correspondante

Fournir une DataView

(triée ou non) sur la DataTable

Oui Non

Oui Non

eQ Services

18

Exemples de mapping entre le XML hiérarchique et la DataView tabulaire:

1- Pour le cas d’une question simple :

<Questionnaire QuestionnaireNameResultForXml Q_Id Q_Label Q_Sort

M_Id M_Label M_Sort Total TotalQuest TotalMod Qpercent TotalGroup Ponderation ResultDate Q_Type

LGroup TitleParent parentType

parentIdLR

LGroupResultForXml

ResultForXml Q_Id Q_Label Q_Sort M_Id M_Label M_Sort Total TotalQuest TotalMod Qpercent TotalGroup Ponderation ResultDate Q_Type


parentId

="Enquête d'accueil"> < ="460" ="Titre" ="7"

="465" ="Mademoiselle" ="8"="1.296000000000000e+003"

="2.881000000000000e+003"="0.000000000000000e+000"="4.498438042346407e+001"

="0.000000000000000e+000"="0" ="10/4/2006"

="52">< ="Mais avant toute chose, merci de

nous indiquer vos coordonnées" ="30"="460">

< /> </ > </ >

< ="460" ="Titre" ="7"="464" ="Madame" ="9"="4.280000000000000e+002"

="2.881000000000000e+003"="0.000000000000000e+000"="1.485595279416869e+001"

="0.000000000000000e+000"="0" ="10/4/2006"

="52">< ="Mais avant toute chose, merci de

nous indiquer vos coordonnées" ="30"="460">

<LR />

Figure 6 : Arrangement d’un XML d’une question simple

eQ Services

19

2- Pour le cas d’une question groupée pondérée

<ResultForXml Q_Id Q_Label Q_Sort

M_Id M_Label M_Sort moyenne maximum Total TotalQuest TotalMod Qpercent TotalGroup Ponderation ResultDate Q_Type


parentIdLR type idQuestion titleQ

idModalite idParent GroupTitle

countResponse Response

LR type idQuestion titleQ

="1095" ="- Intérêt de l'information présentée" ="167"

="1068" ="sans opinion" ="165"="3.0383878e+000"="4.0000000e+000"

="4.600000000000000e+001"="5.660000000000000e+002"

="4.300000000000000e+002"="8.127208480565370e+000"

="4.498000000000000e+003"="1" ="10/4/2006"

="41">< ="Merci de noter ces différents

aspects d'e-Questionnaire" ="41"="1060">

< ="verbatim" ="1095" ="- Intérêt de l'information présentée"

="1068" ="1060"="Merci de noter ces différents aspects

d'e-Questionnaire" ="1"="*" />

< ="verbatim" ="1095" ="-

I té êt d l'i f ti é té "

Figure 7 : Arrangement d’un XML d’une question groupée pondérée

3- Pour le cas d’une question groupée non pondérée

Figure 8 : Arrangement d’un XML d’une question groupée non pondérée

En plus de la DataView créée, ce module offre aussi d'autres informations sur la question cible à

savoir par exemple le numéro du questionnaire auquel elle appartient, sa nature, son type et ses

modalités...

eQ Services

20

c) eQDDG Engine Le moteur eQ Générateur Dynamique de Diagrammes est un rassemblement d'une vingtaine de

classes (tout à fait ouvert à abriter d'autres) organisées entre elles en profitant au maximum des

possibilités de la programmation orientée objet offertes par le langage C# 2.0.

Le eQGDD repose principalement sur deux fichiers DLL:

• Infragistics2.WebUI.UltraWebChart.v6.1.dll

• Infragistics2.WebUI.Shared.v6.1.dll

Ces deux fichiers sont fournis par la société Infragistics qui a comme champs d'application, tout

besoin ayant une relation avec la couche présentation sous les environnements Microsoft.

Infragistics nous offre aussi une boite à outils intégrée à Web Developer Express Edition 2005 qui

permet de créer un diagramme personnalisé sans écrire la moindre ligne de code. Le challenge

était donc de réaliser une solution qui va permettre de générer des diagrammes d'une manière

dynamique et automatisée et qui ne nécessitera pas une intervention humaine.

Le eQGDD Engine doit donc fournir une certaine intelligence qui choisira le meilleur rendement pour

chaque type de question tout en offrant à l'utilisateur final la possibilité de personnaliser encore son

diagramme selon sa guise.

Alors normalement pour créer un diagramme avec Infragistics, une seule classe suffit:

UltraWebChart. Une fois instanciée, on doit ensuite régler un certain nombre de propriétés et

appeler principalement deux méthodes (DataBind() et SaveTo()) pour avoir notre graphe en sortie.

La démarche classique laisse penser l'architecture suivante:

Chart

Prop1 Prop2 … LoadParam() SetParam() DrawChart()

Void SetParam() { if(C1) { //… } if(C2) { //… } //… }

Void DrawChart() { //… }

Void LoadParam() { if(C1) { //… } if(C2) { //… } //… }

Figure 9 : Programmation classique Dans le schéma précédent, la classe Chart gère le cas C1 et le cas C2 sans grand problème. Mais

voilà: si un nouveau cas C3 doit aussi être géré, c'est inévitable, il faut modifier obligatoirement le

code de la classe Chart.

eQ Services

21

Tôt ou tard, des changements s'imposeront sur certaines parties du code et chacune de ces

modifications oblige à modifier le code existant... ce qu'est à la fois coûteux et risqué car tout le

monde sait au passage qu'il n'y a pas plus fragile qu'un code informatique.

Pour éviter ça, des pratiques ont été mises en oeuvre par les professionnels en la matière pour

réduire ce risque. Parmi ces pratiques; le principe d'ouverture/fermeture précise que tout module

doit être à la fois:

• Ouvert aux extensions: Le module peut être étendu pour proposer des comportements qui

n'étaient pas prévus lors de sa création

• Fermé aux modifications: Les extensions sont introduites sans modifier le code du module.

En d'autres termes, l'ajout de fonctionnalités doit se faire en ajoutant du code et non en éditant le

code existant. Cette agilité peut se réaliser grâce aux libertés d'abstraction fournies par le

Framework .NET 2.0 et son langage vedette C#.

Le code de la classe Chart peut donc être ouvert/fermé aux modifications en rendant cette dernière

comme étant une classe abstraite qui définie uniquement les méthodes qui ne dépendent pas d'un

cas précis. Par contre pour les autres méthodes qui doivent être individualisées selon une situation

particulière, ces méthodes sont déclarées abstraites et leurs comportements sont plutôt laissés à

des classes dérivées C1 et C2 qui représentent le cas C1 et le cas C2.

Chart

protected Prop1 protected Prop2 …

abstract LoadParam() abstract SetParam() public DrawChart()

C1

LoadParam() SetParam()

C2


…


Void DrawChart() { //… }

Void LoadParam() { //… }

Void SetParam() { //… }

Void SetParam() { //… }

Void LoadParam() { //… }

Figure 10 : Programmation agile

eQ Services

22

Si un troisième cas s'impose alors on introduit une classe C3 qui va aussi dériver de la classe Chart

en implémentant les méthodes abstraites selon le comportement souhaité et ceci, sans toucher ni à

la classe mère Chart ni aux autres classes C1 et C2.

Le mécanisme d'abstraction consiste donc à extraire la partie variable du code que l'on souhaite

rendre agile. Et pour permettre au code d'accueillir les évolutions futures, plutôt que de modifier le

code existant en compromettant le fonctionnement total de l'application, on introduit alors une

sorte de « Plugin » qui ne va avoir d’effet que sur la partie pour laquelle a été créé.

eQ Services

23

On peut par exemple voir de plus près l’application de cette technique dans ce zoom non exhaustif

du modèle objet (Voir l’annexe pour le modèle objet complet

Figure 11 : Modèle objet du eQGDD Engine

) :

eQ Services

24

Figure 12 : Aperçu sur l’utilisation de l’abstraction

La classe principale e nciable directement.

Cette classe contient un certain nombre de propriétés communes à tout type de diagrammes

omme par exemple les dimensions et la palette de couleurs. Quant aux méthodes, en plus des

st la classe Chart, c'est une classe abstraite non insta

c

fonctions privées, la classe Chart déclare deux autres méthodes abstraites LoadDefaultParameters()

et SetParameters() dont l'implémentation est laissée aux classes dérivées. Par contre et vu que le

eQ Services

25

rfaces classiques (Ces

les

métrer un grand nombre de propriétés spéciales. Cependant, il existe aussi

que le

meilleure combinaison des

er le

traitement des méthodes GetChartImagePath() et GetChartStream() est le même quelque soit la

diagramme, c'est donc la classe abstraite qui se charge de leurs définitions.

On peut donc remarquer l'utilité immense qui vient apporter les classes abstraites par rapport à la

démarche non orientée objet et aussi par rapport à l'utilisation des Inte

dernières ne donnent pas la possibilité de déclarer à l'intérieur même de la classe interface des

attributs ni d'implémenter des méthodes... ce qui n'est plus le cas avec les classes abstraites).

d) eQ Parameters Le module eQGDD donne assez de flexibilité aux clients rigoureux (avant de générer

diagrammes) de para

des clients ne disposant pas du temps pour chercher la bonne combinaison ou tout simplement

n’ont pas d’attentes particulières du eQ à part le fait d’avoir en sortie un diagramme lisible.

Pour rendre donc la tâche plus facile à cette dernière catégorie, eQGDD est doté d’une sorte

« d’intelligence » qui se charge de tout le travail pour eux. eQGDD n’attend de l’utilisateur

numéro de la question, une analyse avancée de la question est alors exécutée pour choisir le

meilleur diagramme avec les meilleurs paramètres selon la nature de question (simple ou groupée,

pondérée ou non, ouverte ou fermée, à choix multiples ou à choix unique…)

Un seul click est donc suffisant pour combler le client, après, s’il n’est pas entièrement satisfait, il

peut toujours surcharger cette proposition par ses propres réglages.

Cette flexibilité et cette puissance ont été rendues possibles en se basant plus particulièrement sur

un fichier XML nommé « ChartParameters.xml » qui regroupe la

paramètres. Cette démarche est tout à fait ingénieuse car un fichier XML est facilement

compréhensible pour les humains comme pour les machines, et donc on a pas besoin d’un éditeur

spécial ni de compétence ou de technologie informatique avancée pour régler ces paramètres.

En plus, cette méthode nous a permis de gagner en vitesse car puisque les paramètres par défaut

se situent plutôt à l’extérieur des classes du eQGDD, il n’est plus donc nécessaire de recompil

projet en cas de changement de ses paramètres.

eQ Services

26

Figure 13 : Aperçu sur un fragment du fichier de paramétrage

e) Conclusion Le eQ Générateur Dynamique de Diagramme est la brique principale de mon projet. Sa conception

architecturale et sa réalisation technique sont basées sur une démarche professionnelle, agile et

performante. En gros, ceci a été rendu possible grâce à:

• Division du programme en modules fonctionnels

• Exploiter à fond les nouveautés du Framework .NET 2.0

• Opter pour une programmation orientée objet agile

• Focaliser le paramétrage de l’ensemble de l’application autour de fichiers XML.

L'application de ces règles ainsi que d'autres principes dans le cas du eQGDD m'ont permis donc

d'avoir un modèle maniable, flexible et optimisé pour répondre aux nouvelles spécifications du

client dans des délais assez courts et sans nuire aux autres fonctionnalités du reste de l'application.

3. Partie Services Web a) Introduction Une fois le diagramme généré en local, il reste à présent de le faire parvenir à sa destination finale

qu'est la version actuelle en ASP/VBscript du eQ.

eQ Services

27

Bien que ASP et ASP.NET paraissent semblables vu leurs noms, il n'en est guerre le cas car le

premier est un langage interprété alors que le deuxième est un langage compilé. La difficulté était

donc de faire communiquer plus précisément les objets du ASP/VBscript d'un côté avec les classes

du eQGDD écrites en C# 2.0 de l'autre côté.

Pour résoudre ce problème, la réponse la plus spontanée ne pouvait pas être autre chose que les

services Web.

b) Caractéristiques d’un service Web Un service Web est un ensemble de protocoles et de normes informatiques utilisés pour échanger

des données entre les applications.

Les logiciels écrits dans divers langages de programmation et sur diverses plateformes peuvent

employer des services Web pour échanger des données à travers des réseaux informatiques

comme internet. Cette interopérabilité est due à l'utilisation de normes ouvertes regroupées au sein

du terme générique de SOA (Service Oriented Architecture ou Architecture Orientée Services).

L'OSI et le W3C sont les comités de coordination responsables de l'architecture et de la

standardisation des services Web.

Ses avantages sont :

• Les services Web fournissent l'interopérabilité entre divers logiciels fonctionnant sur diverses

plateformes

• Les services Web utilisent des standards et protocoles ouverts

• Les protocoles et les formats de données sont au format texte dans la mesure du possible,

facilitant ainsi la compréhension du fonctionnement global des échanges

• Basés sur le protocole HTTP, les services Web peuvent fonctionner au travers de nombreux

pare-feux (firewalls) sans nécessiter des changements sur les règles de filtrage.

Et ses inconvénients

• Les normes de services Web dans les domaines de la sécurité et des transactions sont

actuellement inexistantes ou toujours dans leur débuts comparées à des normes ouvertes plus

mûres de l'informatique répartie telles que CORBA.

• Les services Web souffrent de performances faibles comparées à d'autres approches de

l'informatique répartie telles que le RMI, CORBA, ou DCOM.

• Par l'utilisation du protocole HTTP, les services Web peuvent contourner les mesures de sécurité

mises en place au travers des pare-feux.

Quelles sont alors les raisons pour créer des services Web ?

eQ Services

28

Les services Web implémentent la logique métier rendue consommable par l'utilisation de

standards (majoritairement TCP/IP, HTTP/SMTP... pour le transport, puis XML pour le contenu), ce

qui permet à n'importe quelle technologie utilisant les standards de pouvoir l'exploiter, facilitant

ainsi l'interopérabilité des applications.

La création de service Web se justifie par l'architecture orientée service, c'est à dire la volonté de

rendre accessible un service qui implémente une logique métier cachée à des utilisateurs.

Dans le cadre de contrats d'échanges de données en Business to Business (entreprise <->

entreprise), comme en Business To Customer (entreprise <-> client/utilisateur), un autre intérêt

pour lequel des services Web sont employés est le fait qu'ils se fondent sur le HTTP (donc

possibilité d'utiliser le port 80). En fait, beaucoup d'entreprises se sont protégées en employant

des firewalls qui filtrent et bloquent beaucoup de trafic d'Internet pour des raisons de sécurité.

Dans ce milieu, beaucoup de (presque tous les) ports sont fermés au trafic entrant et sortant et les

administrateurs de ces firewalls ne sont pas désireux de les ouvrir. Le port 80, cependant, est

toujours ouvert parce qu'il est employé par le protocole HTTP utilisé par les navigateurs Web. Avec

cet avantage, le service Web représente une sorte de tunnel qui permet une ouverture et une

extensibilité infinie des applications déjà existantes chez les entreprises.

c) Services Web : Le cas eQ Dans notre cas précis, les problèmes de sécurité ne sont pas posés car le module offrant le service

Web et le module consommant ce dernier seront hébergés dans deux serveurs qui appartiennent

au même réseau local. Les règles d'accessibilités seront donc facilement paramétrables et surveillés

via les outils d'administration du IIS.

Côté performance, et toujours sachant que le serveur et le client appartiennent au même réseau

local, l'obstacle de la rapidité n'influence plus le fonctionnement de l'application vu que c'est

carrément une liaison directe point-à-point. On gagne donc en temps car on évite la perte destinée

initialement à se trouver un chemin optimum dans le réseau maillé qu'est internet. De même pour

le volume des informations échangées, le fait d'opérer sur un canal Fast Ethernet interne de 100

Mbit/s, on est donc sûr de ne pas interférer et surtout nuire aux utilisations initiales de l'application

ASP eQ 4.5.

d) Service Oriented Architecture Service Oriented Architecture (SOA) ou l'architecture orientée service est un modèle d’interaction

applicative qui met en oeuvre des services (composants logiciels) :

• Avec une forte cohérence interne

• Et des couplages externes «lâches».

Le service est une action exécutée par un «fournisseur» (ou «producteur») à l’attention d’un

«client» (ou «consommateur»).

eQ Services

29

Les architectures SOA ont été popularisées avec l'apparition des services Web dans l'e-commerce

(B2B ou B2C) et elles mettent en application une partie des principes d'urbanisation.

Les architectures SOA reposent principalement sur l’utilisation d’interface d’invocation (SOAP) et de

vocabulaire de description de données (WSDL et XML) qui doivent être communs à l’ensemble des

agents (fournisseurs de services et utilisateurs de services).

Ce dispositif permet de réutiliser les applicatifs métier et aussi permettre à l’entreprise de s’adapter

rapidement à un nouveau contexte de marché.

Figure 14 : Les services offerts par eQ Charting Services

e) Web Services Description Language Il s'agit d'une tentative de normalisation regroupant la description des éléments permettant de

mettre en place l'accès à un service réseau (service Web).

Le WSDL décrit une Interface publique d'accès à un Service Web. C'est une description basée sur le

XML qui indique «comment communiquer pour utiliser le service»; Le Protocole de communication

et le format de messages requis pour communiquer avec ce service.

Les opérations possibles et messages sont décrits de façon abstraite mais cette description renvoie

à des protocoles réseaux et formats de messages concrets.

eQ Services

30

L’objectif du WSDL peut être résumé comme suit:

Requête valide

Contrat WSDL

Réponse

Client

Consommateur

Web

Service

Quoi et Comment ?

Figure 15 : WSDL en action

Avec Web Developer 2005, le fichier WSDL est dynamiquement créé à partir des fichiers .asmx

synonyme de service Web sous le Framework .NET. Le fichier WSDL correspondant est facilement

récupérable en ajutant juste « ?wsdl » à l’URI du fichier .asmx précédent :

eQ Services

31

Figure 16 : Aperçu sur le fichier WSDL du eQ Charting Services

Côté client, une classe nommé Proxy Web doit être créée à partir du contrat WSDL. Cette classe

exploite les informations fournies sur le service Web afin de donner au développeur l'impression de

travailler en local. On peu ainsi:

• Appeler une méthode du service Web comme s'il s'agissait d'une méthode locale tout en

profitant de l'aide visuel du IDE

• Faire valider les appels par rapport au contrat WSDL avant l'envoi du message

• Interagir avec le service Web sans être familier avec la structure du WSDL et notamment pour les non-initiés du XML

On peut par exemple voir ici l’aide visuel du IDE Web Developer qui se base sur une copie du fichier

WSDL téléchargée en local.

Figure 17 : L’assistant visuelle du Web Developer basé sur le WSDL

f) Simple Object Access Protocol Simple Object Access Protocol (SOAP) est un protocole de RPC (Remote Procedure Call) orienté

objet bâti sur XML. Il permet la transmission de messages entre objets distants, ce qui veut dire

qu'il autorise un objet à invoquer des méthodes d'objets physiquement situés sur une autre

machine. Le transfert se fait le plus souvent à l'aide du protocole HTTP, mais peut également se

faire par un autre protocole, comme SMTP.

Le protocole SOAP est composé de deux parties :

• une enveloppe, contenant des informations sur le message lui-même afin de permettre son

acheminement et son traitement

• un modèle de données, définissant le format du message, c'est-à-dire les informations à

transmettre.

eQ Services

32

SOAP a été initialement défini par Microsoft et IBM, mais est devenu depuis une recommandation

du W3C et utilisé notamment dans le cadre d'architectures de type SOA pour les services Web.

L'exemple suivant représente la structure d'une requête SOAP :

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<SOAP-ENV:Body> <m:GetChartStream xmlns:m="http://www.e-questionnaire.com"> <m:XmlFile>http://marco/eQ/XMLReport.xml</m:XmlFile> <m:Question>422</m:Question> <m:ChartType>PieChart</m:ChartType> </m:GetChartStream> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Figure 18 : Exemple d’une demande SOAP de la méthode GetChartStream() En cas d'une requête correcte, le service Web répond positivement en renvoyant le résultat. Dans

ce cas précis, et comme le conteneur de la réponse est une balise XML, il est bien sûr impossible de

faire transporter des objets voire des types complexes ou personnalisés (un objet Stream dans ce

cas).

L'astuce était dans ce cas de figure d'envoyer plutôt le code binaire de l'image. On transmet alors

du texte simple non bloqué par les firewalls et dont la taille totale ne dépasse pas quelques dizaines

de kilo-octet.

<?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <soap:Body> <GetChartStreamResponse xmlns="http://www.e-questionnaire.com"> <GetChartStreamResult>iVBORw0KGgoAAAANSUhEUgAAAfQAAAEsCAYAAAHIFG

IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAgY0hSTQAAeiYAAICEAADAAAAGCC DDQSRYQABCAAAQj4EUDofoT4OwQgAAEIQCADBBB6BhqJIkIAAhCAAAAIJABA A41EESEAAQhAAAJ+BBC6HyH+DgEIQAACEMgAAYSegUaiiBCAAAQgAEIAABCGB .... </GetChartStreamResult> </GetChartStreamResponse> </soap:Body> </soap:Envelope>

Figure 19 : Réponse positive du service Web via la balise <GetChartStreamResult> Et en cas d'erreur, un message est transmis au client dans une balise <soap:Fault>

<?xml version="1.0" encoding="utf-8"?> <soap:Envelope

xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<soap:Body> <soap:Fault> <faultcode>soap:Server</faultcode> <faultstring>System.Web.Services.Protocols.SoapException:

Le serveur n'a pas pu traiter la demande; System.Exception: Numéro inéxistant à eQGDD.QuestionInfo.IsSimpleQuestion(String QuestionId)

eQ Services

33

... </faultstring> <detail/> </soap:Fault> </soap:Body> </soap:Envelope>

Figure 20 : Réponse négative du service Web via la balise <soap:Fault>

g) Les services Web sous le framwork .NET 2.0 La création d'un service Web avec Web Developer 2005 Express Edition est relativement simple et

il n'est plus nécessaire pour un développeur de prendre en charge les bas niveaux du service.

L'espace de nom System.Web.Services a été donc mis en oeuvre par Microsoft et se compose des

classes nécessaires dont doit dériver nos propres classes. Le Framework .NET offre aussi l'espace

de nom System.Web.Services.Protocols pour toutes les opérations de la transmission des données

entre le service Web et ses clients.

ASP.NET prend en charge les services Web via un fichier .asmx. Il s'agit d'un fichier texte similaire

à un fichier .aspx. Il peut faire partie d'une application ASP.NET et il est alors adressable par URI

tout comme les fichiers .aspx.

Voici un exemple très simple de fichier .asmx :

<%@ WebService Language="C#" Class="eQ" %> using System;using System.IO; using System.Web.Services; using System.Web.Services.Protocols; using eQGDD; [WebService(Namespace = "http://www.e-questionnaire.com")] public class eQ : System.Web.Services.WebService { [WebMethod] public Byte[] GetChartStream(string XmlFile, string Question, string ChartType) { eQGDD.eQGDD eQGDD = new eQGDD.eQGDD(XmlFile, Question); return eQGDD.GetChartStream(ChartType).ToArray(); } }

Figure 21 : Déclaration d’un service Web sous .NET

Ce fichier commence par une directive ASP.NET Web Service qui définit C# comme langage (On

peut également utiliser Visual Basic, C++ ou un des quelque 30 langages tiers supportés par le

Framework). Il importe ensuite l'espace de nom System.Web.Services et

System.Web.Services.Protocols qui sont obligatoires pour ce qui suit. Un espace de nom (facultatif)

est spécifié après pour le service Web.

Ensuite, la classe eQ est déclarée. Cette classe est dérivée de la classe de base WebService. Enfin,

toutes les méthodes qui seront accessibles à l'intérieur du service ont l'attribut personnalisé

[WebMethod] devant leur signature.

eQ Services

34

h) Utilisation des services Web avec ASP Le fait que SOAP repose sur des technologies normalisées à savoir HTTP et XML, il est donc tout à

fait possible d'utiliser le service Web créé avec C# sous le Framework 2.0 avec n'importe quel

langage offrant au minimum un support d’envoi et de réception de requêtes avec HTTP et celui de

la manipulation des données XML.

Pour le cas d'ASP/VBscript, on peut donc opter pour la démarche suivante:

<% Envelope = _ "SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"" & _ " xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"" & _ " xmlns:xsi=""http://www.w3.org/2001/XMLSchema-instance"" & _ " xmlns:xsd=""http://www.w3.org/2001/XMLSchema""><SOAP-ENV:Body>" & _ "<m:GetBestChartStream xmlns:m=""http://tempuri.org/""> & _ "<m:XmlFile>" & XmlFile & "</m:XmlFile>" & _ "<m:Question>" & Question & "</m:Question>" & _ "<m:D3>" & D3 & "</m:D3>" & _ "</m:GetBestChartStream></SOAP-ENV:Body></SOAP-ENV:Envelope>" set HTTPObject = server.CreateObject("MSXML.XMLHTTPRequest") HTTPObject.open "post", "http://marco/eQ/eQ.asmx", False HTTPObject.setRequestHeader "Content-Type", "text/xml" HTTPObject.setRequestHeader "SOAPMethodName", _ "urn:myserver/soap:m:GetBestChartStream" HTTPObject.send Envelope Result = HTTPObject.responseText set XMLObject = server.CreateObject("Microsoft.XMLDOM") XMLObject.loadXML Result XPathQuery ="soap:Envelope/soap:BODY/GetBestChartStreamResponse" Response = objReturn.selectSingleNode(XPathQuery).Text %>

Figure 22 : Consommation bas niveau d’un service Web depuis ASP

On peut très bien distinguer du code précédent l'utilisation bas niveau en détail d'un service Web

selon le protocole SOAP.

D'abord, on commence par l'initialisation d'une variable « Envelope » par un appel correcte d'une

méthode offerte par le service Web. La charge de transmission de cette enveloppe SOAP est

déléguée à un objet XMLHTTPRequest dont le résultat est chargé dans un autre objet XMLDOM. Ce

dernier est en fin parcouru via une requête XPath question d'isoler la balise contenant le résultat

attendu.

Bien que cette solution soit tout à fait fonctionnelle, on remarque d'abord la non utilisation du

fichier WSDL fournie par le service Web. Cette solution suppose donc que le développeur

eQ Services

35

consommateur est capable de créer à partir du néant une structure XML valide de l'enveloppe SOAP

et qu'il a une idée a priori du résultat potentiel retourné.

Cette démarche reste donc délicate et un peu difficile à mettre en oeuvre, c'est pourquoi Microsoft

a réalisé un ensemble d'utilitaires gratuits pour ses anciens langages: Microsoft SOAP ToolKit.

Ce Toolkit est un ensemble de DLL qui peuvent être exploités par n'importe quelle langage de la

famille COM. Il offre une structure souple et orientée objet pour créer et consommer des services

Web, il offre aussi une prise en charge du côté sécurité en implémentant des fonctionnalités telles

que l'authentification et l'autorisation.

Ainsi, au lieu de passer par toutes les étapes déjà citées en construisant à la main l'enveloppe

SOAP et en créant soit même les objets HTTP et XML pour envoyer la requête et exploiter la

réponse, ces tâches peuvent plutôt être déléguées à un seul objet «SoapClient» qui se base sur la

description WSDL.

Set eQClient = Server.CreateObject("MSSOAP.SoapClient") eQClient.ClientProperty("ServerHTTPRequest") = True eQClient.mssoapinit("http://marco/eQ/eQ.asmx?wsdl") Response = eQClient.GetBestChartStream(xmlfile, question, d3)

Figure 23 : Consommation d’un service Web en utilisant MS SOAP ToolKit pour ASP Dans ce cas précis, une fois le code binaire de l'image obtenu, il reste plus que de l'interpréter en

l'affichant dans des pages ASP pour l'utilisateur final ou de le sauvegarder physiquement pour des

utilisations ultérieurs.

Set FSObject = Server.CreateObject("Scripting.FileSystemObject") Set FSOFile = objFSO.CreateTextFile(Path) For i = 1 to LenB(Response) FSOFile.Write Chr(AscB(MidB(Response, i, 1))) Next FSOFile.Close

Figure 24 : Procédure du sauvegarde physique de l’image du diagramme

D. Conclusion générale Sans parler du gain en performance que cette architecture de service Web a apporté à e-

Questionnaire, sans parler de cette douce migration vers le Framework .NET qui ne pénalise pas

l’actuel exploitation du eQ V4.5, sans parler de cette génération dynamique qui offre le meilleur

rendement pour chaque question… une chose est sûre, c’est surtout le fait de donner aux

utilisateurs finaux plus d’agilité pour personnaliser les diagrammes qui constitue le principal

avantage du module eQ Charting Services

eQ Services

36

Alors que la version 4.5 en ASP ne permet que de changer le type du graphe :

Figure 25 : L’ancienne version de la partie analyse du eQ

eQ Services

37

En plus de l’amélioration du rendu graphique et la qualité de l’image générée, le nouvel module

permet d’aller plus loin comme on peut voir sur le site production d’eQ :

Figure 26 : Les nouveaux paramètres des diagrammes offerts au client

eQ Services

38

Figure 27 : Résultat du service Web

Le eQGDD est tout à fait extensible à fin de générer plus de 40 types différents de diagrammes,

cependant, pour le cas eQ, on a seulement mis l’accent sur les types les plus présentatifs et les

plus pertinents vis-à-vis de la nature des questions posées normalement dans ce genre d’enquêtes.

Exemple de diagrammes que eQGDD génère : Type Diagramme généré

Pie Chart 3D

eQ Services

39

Cylinder Bar Chart 3D

Stack Bar Chart 3D

Column Chart 3D

eQ Services

40

Doughnut Chart 3D

Line Chart 3D

Area Chart 3D

Tableau 3 : Exemple de diagrammes générés

eQ Services

41

X. eQ Reporting Services A. Introduction Alors que le domaine de l’aide à la décision est en pleine explosion, je me suis vu proposer comme

mission la mise en place d’un système fiable de génération de rapports et de prise de décision. En

fait, cette étape du cycle proposée par e-Questionnaire est l’étape la plus importante et la plus

attendue de la part des abonnées de notre service. En plus d’être assez pertinent et

considérablement concluant, le rapport final doit surtout être généré d’une manière optimisée et

performante pour satisfaire les clients dans un temps minime.

B. La génération des rapports dans eQ 4.5 La différence avec le précédent module de génération de diagrammes s’incarne dans le fait que la

génération du rapport ne traite pas chaque question à part mais analyse plutôt l’intégralité des

questions du questionnaire en un seul processus. De plus, la partie Reporting doit pouvoir donner

aux clients la possibilité d’exporter les rapports afin de les consulter ou les exposer ailleurs sans

être obligés d’ouvrir une session internet.

Les utilisateur souhaitant pousser d'avantage leurs analyses, la version 4.5 du eQ leurs propose

deux fonctionnalités intéressantes : le filtrage et le croisement :

• Le « Filtrage » permet de sélectionner une partie des réponses suivant un critère particulier. Par

exemple si l'une des questions d’une enquête permet de déterminer le sexe des répondants, il

sera très facile pour l’utilisateur d'éditer deux rapports distincts: un relatif aux hommes et

l'autre aux femmes.

• La fonction « Croisement » permet de réaliser une analyse croisée entre deux questions

fermées. Pour reprendre l'exemple précédent, si l'on croise les réponses à la question « sexe »

avec les réponses à la question « loisirs », on pourra facilement déterminer les passe-temps

favoris des femmes et mettre en évidence ceux des hommes.

C. Objectifs Mon intervention consistait d’abord à réaliser une étude comparative des solutions existantes du

Reporting. Je devais pour ça analyser de plus prés les deux solutions proposées par mon coach

technique à savoir SQL Server 2005 Reporting Services et Business Objects Crystal Report XI. Je

devais d’abord effectuer une étude comparative entre les deux solutions en cherchant la possibilité

de leur intégration dans les différentes applications de HyperObjects en général puis d’une manière

plus spéciale au cas eQ.

eQ Services

42

Une fois décidé, il fallait toujours depuis un environnement .NET offrir via des services Web la

possibilité à la version actuelle en ASP du eQ d’exploiter les rapports générés de la solution

adoptée.

D. Enjeux du module eQ Reporting Services Vu que le Reporting est l’initial et l’ultime objectif d’un quelconque questionnaire, ce module doit

donc assurer une performance irréprochable aux utilisateurs, sans trop surcharger le serveur

hébergeant eQ ni peser lourd sur la trésorerie financière de HyperObjects.

La priorité du format d’export des rapports a été donnée au format PDF. En fait le PDF (Portable

Document Format) certes créé par Adobe, mais reste un format ouvert dont les spécifications sont

publiques et utilisables librement.

Les rapports générés seront donc plus compacts et surtout exploitables gratuitement (par le biais

d’Acrobat Reader) pour les utilisateurs n’ayant pas des licences Microsoft Word.

E. Étude des outils existants

1. Business Objects Crystal Report XI a) Introduction Crystal Report est un outil de Reporting développé au début par la société Crystal Decisons puis

racheté par le géant Business Objects. Il permet de filtrer, grouper et publier de manière conviviale

et pertinente les données issues d’une base de données. Les fonctions Crystal Reports peuvent être

intégrées dans les applications Java, .NET et COM, et déployées sous Windows, UNIX et Linux.

b) Fonctionnalités Crystal Report est optimisé pour donner une vision absolue de l’activité des entreprises en :

• Créant des rapports avancés au formatage très complexe avec une grande richesse de

l'information contenue.

• Consultant les données et les formater sous forme d'informations dynamiques.

• Intégrant des éléments interactifs dans les rapports.

• Gérant les rapports et les publier sur le Web avec Business Objects Enterprise

Les rapports peuvent contenir des éléments interactifs : le même rapport peut ainsi s'adapter aux

besoins des différents utilisateurs. Les utilisateurs peuvent analyser ou éditer les informations en

passant instantanément d'une lecture statique à une analyse interactive. Ils peuvent également

consulter ces informations sur différents portails Web. Les rapports peuvent être intégrés (en

totalité ou en partie) et partagés en toute sécurité dans des documents Microsoft Office au format

Word, PowerPoint ou Excel.

eQ Services

43

c) Architecture Lors de la demande de l’affichage d’une page contenant un état Crystal Report, l’engin Crystal

report récupère la définition de la structure de l’état depuis un fichier .rpt. Les informations de

connexions à la source de données peuvent être intégrées à cette structure, ce qui permet au

moteur d’état de se connecter et de récupérer les informations nécessaires. Si tel n’est pas le cas, il

conviendra de fournir directement les données à présenter (sous forme de DataSet). Une fois les

informations récupérées, l’état est lié à un Crystal Report Viewer, contrôle permettant à la page

Web d’afficher l’état.

Navigateur

Client

.aspx Web

Forme

Data

Source

.rpt Template

Crystal Report

Engine Composant

Viewer

Crystal Report Designer

Création

Redéfinition des clauses SQL

Figure 28 : Architecture d’une solution de Reporting avec Crystal Report

d) Création des rapports Le Crystal Report Designer est un outil graphique de création d’états tel qu’on peut le trouver sous

Microsoft Access par exemple. On retrouve d’ailleurs quelques similitudes entre ces outils

notamment dans la logique de création des états :

• Sélection des données à présenter

• Tri, groupement et redéfinition des données

• Présentation des données et mise en page.

La création d’un état débute par la définition de sa structure. Vu que Crystal Designer est

directement intégré à Visual Studio .NET 2002, il suffit ainsi d’ajouter ou d’ouvrir un document

Crystal Report (.rpt) au sein d’une solution Visual Studio pour lancer l’application. Avec l’arrivée de

la version 2005 de Visual Studio, Microsoft a remplacé complètement Crystal Report par sa propre

eQ Services

44

solution de Reporting. Il faut donc l’installer comme une application indépendante, y créer les

documents (.rpt) puis les faire inclure dans le projet .NET.

Enfin, afin d’afficher le rapport dans une WebForm, on utilise le composant fourni par Business

Objects nommé CrystalReportViewer. C’est un contrôle doté d’une boite à outil offrant des

possibilités d’export, de zoom, de filtrage et qui est à la fois présent pour les WebForms et les

WindowsForms

2. SQL Server 2005 Reporting Services a) Introduction Microsoft définit SSRS comme une plate-forme serveur qui permet de créer et de gérer des

rapports tabulaires, matriciels et graphiques contenant des informations issues de sources de

données relationnelles et multidimensionnelles. Les rapports créés peuvent être affichés et gérés

via une connexion Web.

b) Fonctionnalités Reporting Services englobe les principaux composants décrits ci-dessous :

• Un jeu complet d'outils de création, de gestion et d'affichage des rapports

• Un composant Report Server hébergeant et traitant des rapports selon divers formats de sortie,

notamment HTML, PDF, TIFF, Excel, CSV…

• Une API permettant aux développeurs d'intégrer ou d'étendre le traitement des données et des

rapports dans des applications personnalisées, ou de créer des outils individualisés pour

élaborer et gérer des rapports.

Les rapports qu’on peut créer peuvent être élaborés selon des données relationnelles ou

multidimensionnelles provenant de SQL Server, Analysis Services, Oracle ou de tout autre

fournisseur de données Microsoft .NET tel que ODBC ou OLE DB. Ils peuvent être de type tabulaire,

matriciel ou libre. On a également la possibilité de créer des rapports adaptés à nos besoins qui

utilisent des modèles et des sources de données prédéfinis.

c) Architecture L’architecture du Reporting Services est pratiquement la même que celle de Crystal Report. La

grande différence réside dans le fait que Reporting Services exige de plus une base de données

SQL Server qu’il utilise comme une méta-base de tables décrivant les différents paramètres

nécessaires à la création des états.

Il faut aussi signaler que puis-ce qu’il se base sur le Framework .NET 2.0, Reporting Services, est

fortement optimisé pour être exploiter via des services Web.

eQ Services

45

.aspx Web

Forme

Data

Source

.rdl Template

Report Engine IIS + .NET 2.0

Composant Viewer

Report Designer (Visual Studio)

Création

Redéfinition des clauses SQL

Reporting Services DataBase

Service Web

Personnalisation du modèle par programmation

Navigateur

Client

Figure 29 : Architecture d’une solution de Reporting avec Reporting Services

d) Création des rapports Sur le marché actuel des applications de rapports pour bases de données, la plupart des

applications utilisent un format propriétaire pour représenter la définition des rapports. De plus, les

fournisseurs qui proposent un environnement d'exécution de rapports ne prennent généralement

en charge que leurs propres outils de création. Pour les clients, cela signifie que les rapports ne

peuvent pas être déplacés simplement d'un environnement de gestion de rapports à un autre et

qu'ils ont peu de possibilités de se procurer de nouveaux outils qui fonctionnent avec leur

environnement d'exécution.

Reporting Services se base plutôt sur le langage de définition de rapport (RDL, Report Definition

Language) qu’est une norme basée sur XML permettant de définir des rapports. Le but du langage

de définition de rapport est de favoriser l'interopérabilité des produits commerciaux en définissant

un schéma commun qui permet l'interchangeabilité des définitions de rapports. Pour encourager

l'interopérabilité, le langage de définition de rapport inclut la notion de niveaux de compatibilité que

les produits peuvent prendre en charge.

Visual Studio prend en charge la totalité de la création des états via un puissant éditeur WYSIWYG.

Les étapes de création de se diffèrent pas trop de celles de Crystal Report à part sur le fait que ce

dernier est orienté pour un public de développeurs mais aussi de managers non informaticiens alors

que Reporting Services exige qu’on soit des habitués de l’environnement Visual Studio. Pour

l’affichage dans les WebFoms, de même que pour Crystal Report, il faut faire recours à un

composant Viewer

eQ Services

46

3. Conclusion Reporting Services est une solution intégrée à des technologies Microsoft prêtes à l'emploi qui offre

la possibilité à des développeurs et à d'autres éditeurs d'élaborer des composants capables de

gérer les différents aspects d’un rapport. Son principal avantage réside dans le format ouvert de

définition des fichiers de rapports (RDL). Néanmoins, cette technologie reste encore très récente et

ne dispose toujours pas d’une API fiable à 100 % dont on peut faire confiance en la mettant dans

un serveur de production. À part le prix exagéré d’une licence pour un déploiement dans un serveur

dédié, il est en plus fortement déconseiller de cohabiter Reporting Services dans le même serveur

que le moteur de SQL Server (gratuit dans ce cas) car les processus du Reporting nuisent

considérablement les transactions habituelles du SQL Server.

Quant à Crystal Report, certes l’ensemble des ses outils apporte aux développeurs .NET un moyen

rapide et efficace de fournir aux utilisateurs la possibilité de consulter des données, mais son point

de faiblesse réside dans le format des ses document (.rpt) qu’est un format binaire et fermé face à

toute personnalisation externe à l’outil Crystal Report Designer. La licence reste comme même

réaliste face aux performances annoncées mais cette voie n’était plus envisageable surtout à cause

de la pauvreté de l’API offerte par Business Objects et qui ne permet que des opérations très

limitées par programmation.

Pour plus d’informations, la matrice suivante résume en gros les caractéristiques des deux

précédentes solutions :

Critère SQL SERVER 2005 Reporting Services Crystal Report XI Editeur

Création - SQL Server Business Intelligence Development Studio (ne nécessite pas l'installation de Visual Studio) - Visual Studio

- Crystal Report pour la version Entreprise - Intégré à Visual Studio pour la version Developer

Management et configuration

- Report Manager (Web Based) - SQL Server Management Studio

- Crystal Management Console (Web Based)

Assistant de création

Oui Oui

WYSIWYG designer

Oui Oui

Format interne de fichier

.RDL (Report Definition Language, XML ouvert) Binaire (.RPT)

Public ciblé Développeurs Toutes les versions sont destinées à un public

de développeurs Server Edition, Developer Edition, Professional Edition

Business users Report Builder (Se base sur des modèles créés avec Visual Studio)

Standard Edition

eQ Services

47

Coûts

Licence - Gratuit avec SQL Server 2005 (Version Standard) - Serveur additionnel (recommandé) - $6,000 - Entreprise Licence - $25,000

- Crystal Report .NET – Gratuit - Standard Edition: $ 200 - Entreprise Edition - $500 - Developer Edition - $600 - Crystal Report Server - $7,500

Source de données

SQL Server et OLDB

Oui Oui

XML Oui via programmation Oui Support Unicode Oui Oui OLAP Oui Oui

Sécurité Gestion des rôles Oui Oui

ASP.NET Forms Authentication

- Standard Edition : Non, Windows authentification est en plus nécessaire - Entreprise Edition: Oui

Oui

Publication et diffusion

Mode de diffusion À la demande ou programmé À la demande ou programmé

Canaux de diffusion

Fichiers publiés, Emails Fichiers publiés, Emails, FTP...

Formats d'export PDF, Excel, HTML, XML, images PDF, RTF, Excel, HTML, XML, images

Compatibilité SOA Oui Oui

Personnalisation

Extensibilité Architecture ouverte: API pour l'extension de traitement de données, de diffusion, de rendu, service Web et de sécurité (Édition Entreprise)

Architecture fermée

Personnalisation des graphes

Oui par programmation Très limitée

Mise en page des rapports

Oui Oui

Autres Passage de paramètres

- Valeur simple par défaut - Multi-valeurs

- Valeur simple - Multi-valeur - Intervalle de valeurs

Sous-rapports Oui Oui Drill-Down/Tri/ Pagination

Oui Oui

Tableau 4 : Synthèse comparative de Crystal Report et Reporting Services

eQ Services

48

F. Solution adoptée

1. Introduction Le cas de e-Questionnaire est un cas extrêmement complexe. Pratiquement chaque questionnaire

voire chaque question est un cas spécial et aucun modèle de base de données ne pourra nous offrir

la possibilité d’exploiter les réponses directement dans un rapport. De même que pour le module

eQ Charting Services, une étape intermédiaire s’avère nécessaire. Du coup, on sait jamais a priori

la structure de la base de données sur quoi se baser pour créer le rapport modèle pour Crystal

Report (.rpt template) et Reporting Services (.rdl). Certes, ce dernier cas est un fichier XML qu’on

peut générer par programmation mais on a opté comme même pour une génération propre à

HyperObjects pour les raisons de performances déjà citées.

2. Architecture

eQ Charting Services

XML Data

Source

HTML Report

CSS File

PDF Converter

Engine ABCPdf DLL

Binary Data

XML

eQ Web Service

SOAP HTTP+XML

eQ ASP Client

Stream

PDF Report

Figure 30 : Architecture du eQ Reporting Services

eQ Services

49

3. Explications La version actuelle du eQ permet de générer des rapports HTML organisés en pages contenant

chacune un diagramme et un tableau récapitulatif en se basant sur la source de données XML et le

module eQ Charting Services. C’est une génération très simple à mettre en œuvre depuis ASP ne

nécessitant pas un propre service Web. Par contre pour les rapports PDF, le recours à un

composant .NET était obligatoire.

On pouvait pour ça reconstruire notre rapport PDF de toutes pièces en partant des données XML

brutes, mais pour ne pas refaire le même travail deux fois et surtout pour garder le même style

que celui du HTML, on a alors opté pour une conversion du HTML. En fait, chaque client peut définir

un fichier de style personnalisé pour son questionnaire. Ces styles sont réutilisés dans la génération

des rapports ce qui permet d’avoir un résultat familiers aux clients ; Une raison de plus d’avoir

choisi un développement personnelle car ni Crystal Report ni Reporting Services ne nous

permettaient d’inclure ces fichiers CSS dans les rapports.

Après un test étalé sur une semaine des librairies existantes de manipulation du format PDF, j’ai

choisi en fin de compte le composant ABCPdf de la société webSuperGoo. Cette dernière disposait

du meilleur rapport performance/prix toute en offrant API riche et flexible qui s’adapter à nos

besoins.

Figure 31 : Les services offerts de génération de PDF

eQ Services

50

Avec la première « Web » méthode, l’objet PDF créé avec le module PDF Converter Engine ne

dispose que d’une seule zone qui va abriter les différentes pages du rapport. La deuxième « Web »

méthode quant à elle gère un objet PDF plus complexe avec la gestion des en-têtes et des pieds de

pages. Ce module assure aussi la gestion des sauts de pages et la conservation des hyperliens

internes qui jouent le rôle de la table des matières.

Figure 32 : Invocation du service Web eQ Reporting depuis ASP

Une fois le rapport HTML et les diagrammes produits, la génération du rapport PDF du coté .NET et

son acheminement au client ASP est quasi instantané. Une boite de dialogue propose alors aux

clients de sauvegarder le dit rapport PDF.

eQ Services

51

Gestion des marges

Gestion des sauts de page

Gestion des en-têtes (organisés en trois zones : Logo, Titre 1 et Titre 2)

Le corps du rapport

Gestion des pieds de pages

Gestion de la numérotation des pages

Gestion des liens internes de la table des matières

Figure 33 : Exemple de génération complexe des rapports PDF

eQ Services

52

4. Conclusion L’adoption d’un module de génération de rapport PDF développé en interne nous a permis d’un seul

coup de marquer plusieurs points positifs. En effet on a pu:

• Réaliser une économie considérable: Les licences de Reporting Services et de Crystal Report

sont plutôt orientées vers des très grandes organisations qui disposent de fonds monétaires

colossaux

• Améliorer la performance: Les fonctionnalités offertes par Reporting Services et Crystal Report

ne sont pas gratuite non plus en terme de performances car il faut aussi payer cash en

ressources matérielles du serveur. En programmant notre propre module, on était sûr d’avoir la

solution la plus adaptée et la plus optimisée pour le cas du eQ

• Ré exploiter le module de génération de graphe : On a alors évité de frustrer les utilisateurs en

leurs donnant deux allures différentes de diagrammes pour la même question (une version dans

la partie Web d’analyse et une autres dans les rapports créés avec Reporting Services ou

Crystal Report)

• Satisfaire pleinement les clients : Les utilisateurs du eQ peuvent désormais avoir un rapport

complet et compact dont le mise en forme est personnalisable et dont le format PDF permet

une impression sur papier de très haute qualité.

eQ Services

53

XI. Perspectives Il est bien évident qu’un projet d’une telle nature ne cessera jamais d’évoluer. La démarche

itérative suivie pour la livraison de mes composantes à mon maître d’ouvrage et aux utilisateurs

finaux de eQ m’a permet d’avoir des feed-backs rapides et constructives. En partant de cette base,

une deuxième version du module eQ Charting Services a déjà vu le jour à l’heure où je rédige ces

lignes. La première itération de la deuxième version offre déjà toutes les fonctionnalités de la

première version mais permet en plus:

• Une meilleure qualité d’image avec de nouveaux effets

• La possibilité de générer séparément la légende du diagramme dans une image isolée

• La possibilité de générer des digrammes interactifs qui affichent des fenêtres d’informations

(ToolTip) selon le positionnement du curseur de la souris

• Une meilleure gestion de chevauchement des labels et biens d’autres améliorations...

Pour les prochaines itérations de la dite deuxième version, on va pousser le challenge encore plus

loin en se penchant sur:

• La génération de graphes avec des image de type vectoriel: Une image décrite vectoriellement

est une image dont la structure est un ensemble d’opérations et de calcules mathématiques.

Cela permet spécialement d’avoir des images de très petite taille mais avec une qualité de

résolution extrême

• La possibilité d’avoir des graphes « navigables » qui offrent des options de Drill/Down: Le

graphe n’est plus alors une image statique mais plutôt un objet complexe avec des zones

cliquables qui offre une navigation sur plusieurs couches du même diagramme

• En plus des graphes ordinaires, le nouveau composant sera également un moteur d'analyse

statistique qui peut nous décharger de tâches complexes à l'avenir: répartition normale d'une

série de donnée, loi de poisson, chi2…

Avec un composant comme celui-ci, nous pouvons véritablement propulsé l'univers d'Analyse du eQ

tout en restant dans l'état d'esprit initiale: on fournit des rapports directement exploitables et

diffusables, ils sont riches en informations, faciles à comprendre ou à analyser et surtout présentés

d’une manière très professionnelle qu'automatisés.

Les résultats d'enquêtes sont à destination des décideurs (les chefs des services financiers par

exemple). Si nos rapports répondent à des critères de concision, de clarté, et de qualité de

présentation, C’est sûr, les responsables des questionnaires passeront directement de eQ vers les

décideurs sans transiter par la case « retouche manuelle » obligatoire aujourd'hui via d’autres

logiciels plus spécialisés.

eQ Services

54

Figure 34 : Aperçu sur les nouveaux diagrammes de eQ Charting Services v2

Figure 35 : Exemple de diagramme financier visé dans la deuxième version du eQ

eQ Services

55

XII. Conclusion générale Sur le plan fonctionnel, ce projet a été clairement couronné de succès. Il est maintenant possible

de traiter d'une façon fiable les flux XML dégagés par les questionnaires publiés en ligne en

générant des graphes et des rapports paramétrables, puissants et tout à fait extensibles pour offrir

de nouvelles fonctionnalités.

Tout en préparant une nouvelle version majeure du eQ entièrement en .NET, et on faisant recours

à un déploiement orienté services Web sans oublier le fait de garder le meilleur compromis entre le

triplet prix, performance et simplicité, on a pu donner à la version actuelle du eQ en ASP la

possibilité de tirer profit des modules déjà réalisés et aux utilisateurs du eQ de les faire partie de

l’amélioration de la nouvelle version en anticipant leurs feed-backs ( et donc de les fidéliser à notre

service).

Sur le plan personnel, le fait de côtoyer pendant quatre mois de suite une structure aussi

professionnelle et spécialisée que celle de HyperObjects m’a permis d’acquérir un nombre

important de pratiques de travail issues du monde des méthodologies agiles. J’ai aussi vu ma

communication orale et écrite s’améliorer de plus en plus au fur et à mesure des nombreuses

expositions et autres conversations que j’ai souvent entamé avec mes coachs techniques et

fonctionnels.

Ce projet m’a été aussi très formateur et enrichissant sur le plan des compétences techniques

orchestrée autour du langage C#. Ça m’a permis d’explorer encore plus le monde architectural du

Framework .NET 2.0 et de la programmation orientée objet organisée en modules fonctionnels.

Certes les perspectives annoncées ne faisaient pas partie du cahier de charges initial, mais ce

projet ne sera complet au vrai sens du terme qu’une fois ce nouveau contrat rempli.

Pour conclure, j’espère avoir répondu aux attentes de mes coachs et de mon encadrant et avoir été

à la hauteur de la confiance qu’ils m’ont témoignée.

eQ Services

56

XIII. Références A. Méthodologie • Approche pragmatiques pour industrialiser le développement d'application,

Jean-Louis Bénard, François Mérand, BrainSonic éditions, 2005

• http://xp-france.net

• http://extremeprogramming.free.fr

• http://fr.wikipedia.org/wiki/Extreme_programming

B. POO, .NET et Infragistics • http://www.design-up.com/design/principesoo/index.html • http://msdn.microsoft.com/library/fre/default.asp?url=/library/FRE/vbcon/html/vbconabstractcl

asses.asp • http://devcenter.infragistics.com/Default.Aspx

C. XML • http://www.w3.org/XML/ • http://msdn.microsoft.com/library/fre/default.asp?url=/library/FRE/vbcon/html/vboriworkingwit

hxmldata.asp

D. Services Web • http://www.microsoft.com/france/msdn/technos/webservices.mspx • SOAP Toolkit 3.0 User Guide

2002 Microsoft Corporation

http://xp-france.net/

http://extremeprogramming.free.fr/

http://fr.wikipedia.org/wiki/Extreme_programming

http://www.design-up.com/design/principesoo/index.html

http://msdn.microsoft.com/library/fre/default.asp?url=/library/FRE/vbcon/html/vbconabstractclasses.asp

http://msdn.microsoft.com/library/fre/default.asp?url=/library/FRE/vbcon/html/vbconabstractclasses.asp

http://devcenter.infragistics.com/Default.Aspx

http://www.w3.org/XML/

http://msdn.microsoft.com/library/fre/default.asp?url=/library/FRE/vbcon/html/vboriworkingwithxmldata.asp

http://msdn.microsoft.com/library/fre/default.asp?url=/library/FRE/vbcon/html/vboriworkingwithxmldata.asp

http://www.microsoft.com/france/msdn/technos/webservices.mspx

eQ Services

57

XIV. Annexe A. Microsoft .NET Framework

1. Introduction L'objectif de .NET Framework est de faciliter la conception d'applications Windows et Web. Le .NET

Framework fournit également un ensemble de bibliothèques de classes que les développeurs

peuvent utiliser à partir de tout langage de programmation. Par dessus, différents modèles de

programmation fournissent des composants de plus haut niveau et des services s'adressant

spécifiquement au développement de sites Web et de services Web. La figure suivante présente

l'architecture de Microsoft .NET Framework :

Figure 36 : Architecture du Framework .NET

2. Base Class Library Le Framework fournit plusieurs classes de base accessibles par tous les langages .NET. En effet,

entre les différents langages seule la syntaxe change alors que et les classes restent les mêmes.

Tout comme en Java, ces classes, représentées de manière hiérarchisée, permettent aux

développeurs de posséder des outils pour réaliser leurs applications.

3. Le CLR et MSIL Le composant essentiel de l'architecture .NET Framework est le Common Language Runtime. Le

CLR permet l'exécution de code de n'importe quel langage de programmation moderne. Celui-ci se

place au-dessus du système d'exploitation pour en faire abstraction. Ce runtime fournit de

eQ Services

58

nombreux services simplifiant le développement du code et le déploiement de l'application, tout en

améliorant sa fiabilité.

Figure 37 : le Common Language Runtime

4. ASP.NET ASP.NET permet la création d’application Web au sein de .NET. Dans ce contexte la notion d’objet

est prédominante. En effet, de la page aux composants graphiques, par exemple un bouton est vu

comme un objet. Celui-ci est appelé un composant Web. Lorsqu’un développeur insère un

composant graphique sur son application Web, il doit insérer le contrôle du composant. C’est

ensuite ASP.NET qui se chargera de créer le code HTML correspondant au contrôle. L’exemple

suivant montre un contrôle de bouton :

<asp:Button id="btSave" runat="server" Text="Save"></asp:Button>

Au niveau de la structuration du code, il est à noter qu’en ASP.NET l’interface et le code sont

séparés. Ceci permet une meilleure structuration du code et facilite le travail du développeur et du

designer qui ont chacun leur espace de travail bien distinct.

Le code source d’une page demandée par le client, lors d’un premier appel, est compilé en code

intermédiaire puis au moment de l’exécution la CLR compile le MSIL en code binaire via le JIT et

exécute le code en mémoire. Une fois la page compilée, aux demandes suivantes ce processus ne

sera plus effectué. En effet, ce sera la page en mémoire qui sera transmise au visiteur (sauf si les

données de la page changent entre temps). Ce mécanisme permet d’augmenter considérablement

les performances des applications

eQ Services

59

B. Le modèle objet du eQ Charting Services La section suivante utilise la notation :

La notation représente… Classe

Classe abstraite Champ public

Champ privé Champ protégé

Propriété publique Propriété publique abstraite

Méthode publique Méthode privée

Méthode protégée Méthode protégée abstraire

La classe ColumnChart hérite de la classe Chart

Tableau 5 : Convention de la notation POO utilisée

1. Le module XmlDocument Provider

Figure 38 : La classe XmlDocumentProvider

eQ Services

60

2. Le module Xml To DataView Mapper

Figure 39 : La classe QuestionInfo

3. La Classe eQ Web Service

Figure 40 : La classe WebService eQ

eQ Services

61

4. Le moteur eQGDD Engine

Figure 41 : La classe eQGDD

eQ Services

62

5. Les classes de base du eQGDD Engine La classe eQGDD Engine encapsule le traitement d’un ensemble de classes dont voilà un aperçu :

Figure 42 : Le modèle objet du eQGDD Engine

Comme c’est très difficile de fournir un aperçu détaillé mais lisible de la totalité de ce modèle objet,

je vais juste me contenter de présenter ici trois niveaux avec les classes Chart, PieChart et

PieChart3D comme exemple.

La démarche est le même que pour les autres classes, chaque classe de niveau inférieur hérite les

champs, propriétés et les méthodes de la classe supérieur, ajoute ses propres champs et propriétés

et redéfinit les méthodes abstraites selon le comportement attendu d’elle.

eQ Services

63

Figure 43 : Exemple d’abstraction et d’héritage du eQGDD

eQ Services PFE

Technology

Transcript of eQ Services PFE