Développement d une application web de gestion des s

Transcription

1 Pantone 338 C Logo Final 14 / niversité u ice n sophia Antipolis Polices Logo NON VECTORISE C 47 % M 0 % J 32 % N 0% C 75% M 0 % J 7 % N 0 % Pantone 306 C Logo VECTORISE UNIVERSITÉ DE NICE - SOPHIA ANTIPOLIS Logo noir C 0 % M 6 % J 95 % N 0 % Nuancier Couleurs Pantone 108 C MASTER 2 IFI - IHM ANNÉE UNIVERSITAIRE RAPPORT DE STAGE Développement d une application web de gestion des s Étudiant Bastien AUDA Maître de stage Laurent BERTHELOT Tuteur enseignant Audrey OCCELLO Entreprise : Groupe pro Btp e Groupe PRO BTP Centre Technique National Parc Saint Véran Cagnes sur Mer raite P-RETRAITE Prévoyance Santé BTP-PRÉVOYANCE NRBTPIG KORÉLIO SÉVÉANE

2 Table des matières Remerciements 3 I Introduction 4 I.1 Présentation de l entreprise I.2 Sujet du stage I.3 Planning I.4 Environnement de travail II L application de prévisualisation 8 II.1 Description du travail proposé II.1.1 Les séquences relationnelles II.1.2 Les applications existantes II Les services publics II EVE II Pomme II COMET II.1.3 Description détaillée du sujet II.1.4 Les technologies utilisées : Socle Flex PRO BTP et Spring LCDS 14 II.1.5 La charte ergonomique et graphique PRO BTP II.2 Description du travail réalisé II.2.1 Analyse du sujet II.2.2 Écran de prévisualisation d s II Conception II Développement II.2.3 Prise en charge de plusieurs types de document - Ajout du type SMS II Conception II Développement II Documentation

3 III Évolution de l application Pomme 22 III.1 Description du travail proposé III.1.1 Les applications existantes III Le Processus FMA III WebSphere MQ III OGME III.1.2 Description détaillée du sujet III.2 Description du travail réalisé III.2.1 Prise en charge des maquettes FMA III.2.2 Mise en place d une MQ III Gestion des messages en erreur avec OGME III.2.3 Suppression des ordres traités III.2.4 Modification du sujet IV Conclusion 32 IV.1 Bilan pour le projet IV.2 Bilan personnel IV.3 Perspectives V Annexes 34 V.1 Présentation du groupe PRO BTP V.1.1 Historique du groupe V.1.2 Les activités V.1.3 Organisation du groupe V.2 Annexes application Pomme V.2.1 Exemple d personnalisable Pomme V.2.2 Exemple d personnalisable FMA V.3 Glossaire V.4 Webographie

4 Remerciements Je remercie M. Jean RANCATI, Directeur de la Direction des Développements Informatiques, de m avoir permis d effectuer ce stage. Je remercie M. Bruno DELORY, chef du département Maintenance Applicatifs Transverses, pour m avoir accueilli au sein de son département dans les meilleures conditions. Je remercie M. Laurent BERTHELOT, chef de projet de l équipe «Internet & GED», pour m avoir proposé ce stage et qui m a guidé et donné les directives pour ce stage. Je remercie particulièrement M. Henri BARALHE, de l équipe Internet, qui m a accompagné tout au long de ce projet pour sa disponibilité, son aide et sa confiance. Je remercie également l ensemble de l équipe Internet & GED pour l accueil qu ils m ont réservé. Leur sympathie, et l aide qu ils m ont apporté, ont fait en sorte que ce stage se déroule dans des conditions idéales. Enfin je remercie M me Audrey OCCELLO, maitre de conférences à l Université de Nice Sophia Antipolis, pour m avoir suivi durant cette période. 3

5 Partie I Introduction Contexte Dans ce rapport, je vais présenter le travail effectué durant mon stage de fin d études à PRO BTP, qui va clôturer mon parcours à l université de Nice-Sophia Antipolis. I.1 Présentation de l entreprise Ce stage se déroule à PRO BTP 1, le groupe de protection sociale du BTP. Comptant plus de 4900 collaborateurs répartis sur toute la France, PRO BTP propose des produits et services dans les domaines de la retraite, la prévoyance, la santé, l épargne, l assurance, l action sociale et les vacances. Le CTN 2 est situé à Cagnes-sur-mer dans un parc de huit hectares et regroupe des services centraux du groupe. Parmi ces services on retrouve la DDI 3, composée de près de 200 salariés celle-ci est divisée en trois départements : MAM - Maintenance Applications Métier DEV - Développement MAT - Maintenance Applications Transverses 1. Le groupe PRO BTP est présenté de manière plus générale et complète dans l annexe V.1 page Centre Technique National. 3. Direction des développements informatiques. 4

6 Enfin, chaque département est composé de plusieurs équipes, et c est au sein de l équipe «Internet & GED 4» du département MAT que j ai effectué mon stage. I.2 Sujet du stage Le sujet qui m a été proposé durant ce stage a été écrit par M. Laurent Berthelot, chef de projet de l équipe Internet et GED. Il s inscrit dans le cadre du développement d une application web d envoi d dénommée Pomme 5. Cette dernière permet l envoi d s personnalisés avec les informations de l adhérent. Mon stage est constitué en grande partie d une phase d étude de l existant dû au nombre conséquent d applications mises en jeu au cours du projet. Le sujet du stage sera explicité plus en détail dans les sous parties suivantes. 4. Gestion électronique des documents. 5. L application Pomme sera présentée plus en détail dans la section II p.9 5

7 I.3 Planning Stage de fin d'études 21 août 20 Diagramme de Gantt 2013 Mise en prod 6 Nom Date de début Date de fin Familiarisation env. travail 02/04/13 12/04/13 Rédaction rapport intermédiaire 02/05/13 15/05/13 Rédaction rapport final 15/07/13 27/08/13 Préparation support soutenance 02/09/13 13/09/13 Application de prévisualisation 10/04/13 27/06/13 étude du sujet 10/04/13 19/04/13 Développement écran prév. 22/04/13 24/05/13 Ajout prévisualisations SMS 20/06/13 25/06/13 Documentation outil de prév. 26/06/13 27/06/13 Application Pomme 27/05/13 16/09/13 Sujet FMA 27/05/13 24/06/13 étude du sujet FMA 27/05/13 07/06/13 Ajout maquettes FMA 10/06/13 14/06/13 Ajout maquettes SMS FMA 17/06/13 24/06/13 Sujet MQ 27/06/13 20/08/13 étude du sujet 27/06/13 09/07/13 Mise en place MQ Pomme 10/07/13 23/07/13 OGME 24/07/13 30/07/13 Suppression ordres traités 31/07/13 20/08/13 Tests 26/08/13 13/09/13 Mise en production 17/09/13 17/09/13 avril mai juin juillet août septembre Diagramme de Gantt du stage Les tâches sont explicitées plus en détail dans les sous parties correspondantes. 7. Sauf mention contraire, les tâches sont des tâches de développement.

8 I.4 Environnement de travail L environnement de travail utilisé par les développeurs PRO BTP est composé d un serveur d applications Java WebSphere et de l IDE IBM Rational Application Devloper (RAD). Cet IDE étant basé sur Eclipse, que j ai utilisé tout au long de mon cursus universitaire, la phase de familiarisation avec cet outil fut très rapide. Les autres logiciels utilisés à PRO BTP sont IBM Rational ClearCase, un outil de versioning, Lotus Notes pour la communication et la suite bureautique Open Office pour la rédaction de documents. 7

9 Partie II L application de prévisualisation II.1 II.1.1 Description du travail proposé Les séquences relationnelles Une séquence est définie comme une suite d étapes conditionnées les unes à la suite des autres exécutant des actions élémentaires. Une séquence relationnelle permettra donc de définir des actions à effectuer automatiquement en fonction d évènements externes à l application, telles les interactions de l utilisateur adhérent ou l écoulement d une certaine durée. On peut citer comme exemple la séquence d inscription définie comme suit : 1. Prospection : On envoie un à un ensemble d adhérents sélectionnés leur proposant de souscrire à une offre. Attente inscription : l étape suivante n est exécutée que si l adhérent s est inscrit. 2. Inscription : On envoie un courrier contenant un code de confirmation à l adhérent Attente validation 3. Envoi d un de confirmation d inscription 8

10 II.1.2 II Les applications existantes Les services publics PRO BTP est équipé d un Mainframe MVS 1. Celui-ci stocke, entre autres, les informations concernant les adhérents PRO BTP. Les méthodes appelées sur le Mainframe et qui permettent de récupérer ou stocker des informations ont été normalisées et sont appelées services publics. Les services publics reposent sur plusieurs couches logicielles principalement développées en PL1 et Assembleur. Les bases de données utilisées sont en DB2, leur gestion n est pas assurée directement par les services publics mais par l une des sous-couches logicielles. II EVE EVE, qui signifie «EnVoi », est une application qui permet de générer l envoi de mails avec ou sans pièce jointe. Les Applications qui possèdent une fonctionnalité d envoi d s peuvent utiliser EVE en déposant les s à envoyer dans une file d attente de message 2. II Pomme Pomme est une application qui permet de gérer des campagnes d ing. Elle permet un fort niveau de personnalisation et de ciblage des campagnes grâce à ses fonctionnalités principales : L envoi sous condition : l ordre peut être répété à intervalle régulier et ce un certain nombre de fois jusqu à ce qu une condition soit vérifiée. On peut pour cela définir combien de fois l ordre doit être exécuté tant que la condition n est pas vérifiée, et l intervalle entre deux exécutions de l ordre. On peut par exemple envoyer par mail les identifiants internet à l adhérent, et ce toutes les semaines pendant trois semaines tant qu il ne s est pas connecté. La personnalisation du contenu des s : on peut placer dans le texte du mail des balises de la forme ${NomDuTag} qui seront ensuite remplacées par des pa- 1. Multiple Virtual Storage, le système d exploitation des mainframes IBM 2. Le fonctionnement des files d attentes de messages dans un environnement WebSphere est explicité plus en détail dans la section III page 24 9

11 ramètres personnalisés 3. On distingue trois types de paramètres : Les paramètres «service public» : ceux-ci proviennent des services publics 4 PRO BTP et fournissent donc des informations relatives à l adhérent (par exemple son nom, prénom, adresse...). Les paramètres système : ceux ci sont calculés par le système à l exécution, ils sont principalement utilisés pour afficher la date du jour. Les paramètres propres à la campagne : ceux-ci permettent de réutiliser une même maquette d pour plusieurs campagnes en changeant certaines valeurs ou portions de texte. On peut ainsi indiquer une variable ${Prix}, ainsi si le prix du produit change, il n est plus nécessaire de modifier la maquette, il suffit de modifier la valeur associée à la variable pour cette campagne. Pomme fonctionne à l aide d un timer défini sur le serveur. Celui-ci exécute la séquence suivante, que l on retrouve sur la figure II.1 page 11, à intervalle régulier : Pomme lit la liste des ordres. Pour chaque ordre il vérifie si la condition est vraie. Si elle est fausse, le traitement est arrêté et l ordre est mis à jour dans la base de donnée. Si la condition est vraie, il personnalise la maquette attachée à l ordre avec les informations personnalisées. L ainsi généré est transmis à EVE pour l envoi. Enfin une étape de gestion des ordres va ajouter les ordres reçus dans la base de donnée et vérifier si les ordres traités n ayant pas validé la condition doivent être conservés ou supprimés. Dans le contexte des séquences relationnelles, Pomme permet de vérifier les conditions et de traiter les actions élémentaires. II COMET COMET, qui signifie Client Orienté METiers est une application destinée aux utilisateurs internes. Son but est de regrouper en une seule application l ensemble des outils 3. Le code source d un qui peut être envoyé avec Pomme est disponible en annexe V.2.1 page Voir section II p. 9 10

12 FIGURE II.1 Schéma décrivant le fonctionnement de l application Pomme 11

13 FIGURE II.2 Capture d écran de l application COMET 5. Sont encadrés en rouge : le champ code opération (COP) le champ indicatif la zone d affichage de l application (une application Flex dans cet exemple). 12

14 mis à la disposition des agents PRO BTP. COMET offre une authentification unique (SSO) pour les applications auxquelles il permet d accéder. Ceci permet de simplifier la tâche des utilisateurs qui n ont alors besoin de s identifier qu une seule fois pour accéder à toutes les applications, tout en maintenant un fort niveau de sécurité. Son interface, que l on peut voir sur la figure II.2 page 12, présente dans sa partie supérieure une barre d outils qui contient deux champs. Le champ nommé Indicatif permet d entrer le numéro du dossier adhérent que l on veut consulter. Le champ COP permet d entrer un code opération (COP), ce code correspond en fait à l identifiant de l application qui va être utilisée pour afficher le dossier. Le dossier est ensuite affiché dans l application correspondante dans la zone centrale de l interface. Il peut s agir d un écran COMET, intégré directement dans le client, ou bien d une application web qui est alors affichée grâce au moteur de rendu d Internet Explorer. II.1.3 Description détaillée du sujet Mon travail sur ce sujet consistera à concevoir et développer une application web permettant de prévisualiser une maquette, puis, en renseignant les champs personnalisés de voir le résultat de la personnalisation du mail. Ceci permet à l utilisateur de comprendre le fonctionnement de la personnalisation dans Pomme et de s assurer que le design de la maquette reste lisible avec certaines données, comme, par exemple, un adhérent dont le nom comporterait un grand nombre de caractères. L utilisateur pourra ensuite renseigner une ou plusieurs adresses s afin de tester le rendu sur différents webmails ou logiciels de messagerie. La partie développement de cette application comprend le développement d un client Flex et d une application web Java qui fournira les webservices nécessaires au fonctionnement de l interface. L envoi d se fera via EVE comme c est le cas dans Pomme. Cette application étant destinée à être intégrée dans COMET, elle devra supporter l authentification unique, qui est gérée de base par le socle, et récupérer le numéro de dossier de l adhérent entré par l utilisateur dans COMET. La seconde partie de ce sujet consistera à faire évoluer l application afin qu elle permette la prévisualisation de maquettes d autres types de documents. Seules les ma- 5. Les données personnelles des adhérents ont volontairement été floutées sur les captures d écran. 13

15 quettes de type SMS seront implémentées dans un premier temps mais l architecture devra rester assez générique pour permettre d ajouter facilement de nouveaux types de documents. II.1.4 Les technologies utilisées : Socle Flex PRO BTP et Spring LCDS Afin de maintenir une certaine homogénéité dans les applications, et ainsi faciliter leur déploiement et leur maintenance, tous les projets d application web Flex PRO BTP doivent dériver d un projet de base. Celui-ci contient une application basique clientserveur, permettant ainsi d être rapidement opérationnel à la création d un nouveau projet. Le client est développé en Flex et doit utiliser le socle PRO BTP qui est en fait une bibliothèque Flex redéfinissant la plupart des éléments graphiques Flex afin que ceux ci correspondent à la charte graphique PRO BTP. Le socle propose aussi une fonctionnalité permettant de faire remonter les erreurs serveur à l utilisateur sous forme de popup. Ceci est fait en lançant un type d exception spécifique à laquelle on peut attacher un message. Le socle Flex va alors intercepter cette exception et afficher une popup contenant le message à l utilisateur. Le serveur, quant à lui, est basé sur IBM WebSphere Application Server (WAS), un serveur basé sur Java EE. Le serveur suit une architecture dite «en couche» qui est décrite sur la figure II.3 page 15. La communication entre le serveur et le client Flex se fait grâce à la transmission de messages AMF 6 et utilise Spring côté serveur et Spring ActionScript côté client Flex. II.1.5 La charte ergonomique et graphique PRO BTP La charte ergonomique et graphique des écrans Flex fournie aux développeurs PRO BTP décrit les bonnes pratiques à suivre lors de la conception d une interface d application Flex. D où l importance d utiliser les composants graphiques redéfinis par le socle Flex 6. Action Message Format : format binaire d échange de données conçu pour permettre l échange de données entre une application Adobe Flash et d autres systèmes tel un webservice. 14

16 FIGURE II.3 Schéma représentant l architecture «en couche» d un projet Spring LCDS 15

17 PRO BTP plutôt que ceux natifs car leurs règles de style correspondent déjà à celles décrites dans la charte. Les recommandations de la charte donnent principalement des indications sur la façon de présenter les informations ou le placement de certains éléments graphiques. On peut par exemple citer les recommandations suivantes qui concernent directement l interface de l application de prévisualisation : L écran de l application doit pouvoir entrer entièrement sur un écran de 19 pouces au format 4/3. L application ne doit pas présenter d ascenseurs horizontaux et les ascenseurs verticaux doivent être évités. Les données doivent être regroupées dans des panels Flex. Ceux-ci sont repliables pour permettre à l utilisateur de masquer les informations qui lui semblent inutiles et ainsi accorder un espace plus grand à celles qui lui semblent importantes. Les boutons de navigation doivent se situer en haut à droite. Les boutons de modification doivent être placés en bas à droite. Le bouton de modification principal, s il y en a un, peut être activable avec la touche entrée. II.2 II.2.1 Description du travail réalisé Analyse du sujet Les deux premières semaines du stage furent dédiées à la familiarisation avec l environnement de travail et les technologies utilisées ainsi qu à l étude du sujet. Après que l on m ait présenté le sujet ainsi que les applications existantes j ai examiné le code du projet Pomme afin de comprendre son fonctionnement, et principalement comment étaient faits les appels aux différents services que je devrais utiliser pour mon projet. Une fois le sujet assimilé, j ai suivi la procédure de création d un nouveau projet web citée en II.1.4 p.14. Cela m a permis dans un premier temps de me familiariser avec les outils ClearCase et RAD. Une fois ceux-ci appréhendés, j ai pu débuter mon apprentissage des technologies Flex et Spring ; à l aide de tutoriels en ligne dans un premier temps puis en analysant et manipulant le code du projet de base. Celui-ci présente en effet un exemple complet d application web et permet de voir comment faire communiquer le serveur avec le 16

18 client Flex. II.2.2 II Écran de prévisualisation d s Conception La phase de conception fut plutôt courte étant donné le nombre important de contraintes concernant l architecture et les technologies utilisées. Le fonctionnement général de l application est décrit dans le schéma II.4 page 18. La personnalisation se faisant dans le client à l aide de Flex et JavaScript, la fonctionnalité de personnalisation qui existait dans Pomme n a pas été réutilisée. Si l on se reporte au schéma d architecture d un projet d application web PRO BTP de la figure II.3 page 15, la majorité du développement se fait sur les couches Application FLEX et Orchestration de service. C est durant cette phase que j ai réalisé une première maquette de l interface en prenant soin de suivre les recommandations de la charte ergonomique et graphique PRO BTP. L interface prévue, très similaire à celle développée dont on peut voir une capture d écran sur la figure II.5 page 19, devait initialement être composée de quatre panels Flex : Dans le premier panel l utilisateur choisit la maquette qu il veut afficher dans une liste déroulante. Les paramètres personnalisables de la maquette s affichent dans un formulaire sur un second panel. Un troisième panel situé sur le côté permet de prévisualiser la maquette. Enfin un dernier panel permet d entrer une adresse vers laquelle on veut envoyer la maquette. II Développement J ai commencé par développer une première version de l application de prévisualisation. Cette première version devait permettre à l utilisateur de sélectionner une maquette, d entrer les informations personnalisées et enfin de la prévisualiser. C est lors du développement de cette première version que j ai rencontré une première difficulté. En effet, les maquettes d s sont au format HTML, or, si Flex offre 17

19 Client Flex Serveur Choix de la maquette Récupération de la maquette Récupération de la maquette Disque local Ou URL Affichage/Personnalisation Envoi Envoi EVE FIGURE II.4 Schéma représentant les requêtes client-serveur de l application de prévisualisation. une fonctionnalité permettant d utiliser du HTML dans un composant, celle-ci est uniquement destinée à offrir aux développeurs un moyen simple de mettre en forme du texte, et non pas à offrir un véritable moteur de rendu HTML. La prévisualisation des s dans l application Flex était donc illisible, rendant cette approche inenvisageable. La solution que j ai proposée, et qui a été retenue, consiste à diviser l interface en deux. Sur la partie gauche nous avons l application Flex, qui comprends les différents formulaires, et sur la partie droite l est affiché dans une iframe, grâce à l appel de fonctions javascript depuis l application Flex. La première évolution de cette application consista à permettre l envoi de l personnalisé afin de pouvoir visualiser le résultat de la composition dans un client mail ou un webmail. Cet envoi s effectue en renvoyant au serveur la maquette avec ses informations personnalisées entrées par l utilisateur. Le serveur va ensuite envoyer cet via EVE. Une seconde évolution a permis l ajout d une fonctionnalité de personnalisation en direct. Celle-ci permet à l utilisateur de visualiser directement le résultat de la composition de l au fur et à mesure qu il entre les données dans le formulaire. 18

20 FIGURE II.5 Capture d écran de l interface de prévisualisation de documents. On distingue les différentes zones de l interface : L application Flex sur la gauche, divisée en trois zones : Zone de choix de la maquette Zone de personnalisation de la maquette Zone d envoi de la maquette Sur la droite, une iframe qui permet d afficher une prévisualisation de la maquette 19

21 II.2.3 II Prise en charge de plusieurs types de document - Ajout du type SMS Conception La gestion des différents type de documents se fait grâce au mécanisme d héritage. Les classes Java Mail et Sms héritent donc d une classe abstraite nommée Document. Cette dernière contient les éléments de base nécessaires à tout document personnalisable et destiné à l envoi. On retrouve donc les informations sur l expéditeur et le destinataire ainsi que les sujet et corps du message. La classe Document contient aussi les méthodes permettant de personnaliser le texte. Les classes filles, elles, implémentent les traitements spécifiques à chaque type de document. II Développement L essentiel des fonctionnalités de personnalisation de texte étant déjà implémentées pour gérer les maquettes de type , cette phase se résuma principalement à séparer les méthodes génériques qui peuvent être communes à tout type document (comme les méthodes de personnalisation de texte par exemple) des méthodes spécifique à chaque type de document (comme la méthode qui permet de récupérer la maquette depuis un fichier ou une url à l aide de son identifiant). Du côté du client Flex, si le langage ActionScript permet bien de faire de l héritage, il n est pas possible de conserver cette notion lors de la communication entre le client et le serveur avec Spring ActionScript. Le client ne connait alors que la classe mère, Document, qui contient les mêmes attributs en Java et en Flex. Afin de palier ce problème, celle ci contient un champ permettant de connaitre le type du document, celui ci permet d adapter le comportement du client en fonction du type de maquette traité. De plus, les classes filles et Sms ne devront pas contenir de données nécessaires au bon fonctionnement de l interface. Enfin, afin de permettre l affichage de documents qui ne seraient pas stockables dans une variable de type String (comme un fichier pdf, ou une image), et qui ne pourrait donc pas être injecté dans l iframe puis personnalisée via une fonction javascript, il a été prévu d utiliser une fonction javascript qui va modifier l url vers laquelle pointe l iframe, permettant ainsi d afficher une page jsp. Cette dernière devra pouvoir récupérer et personnaliser le document voulu, cela à l aide des paramètres passés par l url, puis, 20

22 soit d afficher directement le document dans le navigateur si cela est possible, soit de proposer le téléchargement du document personnalisé à ouvrir dans une application externe. II Documentation Afin de faciliter la tâche de l équipe qui va reprendre ce projet, il m a été demandé de fournir une documentation qui explique le fonctionnement général de l application ainsi qu une procédure détaillée expliquant de la marche à suivre pour ajouter le support d un nouveau type de document. 21

23 Partie III Évolution de l application Pomme III.1 III.1.1 III Description du travail proposé Les applications existantes Le Processus FMA Le processus FMA 1 est une application permettant de traiter des ordres de manière asynchrone. Ces ordres peuvent concerner aussi bien l envoi de messages ( ou sms par exemple) que des mises à jour, comme des appels aux services publics, qui ne requièrent pas un traitement immédiat. Les mises à jour asynchrones permettent de lisser les performances des applications appelantes. En effet, tout traitement ne nécessitant pas une action immédiate peut alors se résumer à une écriture dans une base de données. Comme on peut le voir sur la figure III.1 page 23, le serveur exécute en boucle le Processus FMA qui va alors traiter les ordres présents dans une base de donnée. Cette base de donnée est alimentée directement par les applications qui souhaitent effectuer des mises à jour de manière asynchrone. Les maquettes 2 du Process FMA sont stockées sous forme de fichier texte. Un fichier de configuration permet de retrouver le chemin du fichier contenant la maquette à partir de son identifiant. La personnalisation se fait via des tags numérotés du type {n} dans le corps de 1. Fournisseur de Mise à jour Asynchrone 2. Un exemple de maquette du processus FMA est présenté dans l annexe V.2.2 page39. 22

24 FIGURE III.1 Schéma présentant les différents composants mis en jeu lors de l exécution de process FMA. La TNFMB est une table DB2 alimentée directement par les applications désireuses de faire des mises à jour asynchrones. Le MAX est une application du MainFrame permettant de sérialiser les objets de la TNFMB en XML et inversement. 23

25 l . Une liste de paramètre enregistrée avec l ordre dans la base de données contient les valeurs à remplacer dans le texte. Les valeurs n dans le texte représentent la position du texte de remplacement dans la liste de paramètres. Le texte des SMS, plus court, est quant à lui directement stocké dans le fichier de configuration sous forme d attribut XML. Les envois de messages du processus FMA se font actuellement par des appels directs au serveur smpt. III WebSphere MQ Une MQ (Message Queue ou file d attente de message en français) est une technique de programmation utilisée pour la communication de serveur à serveur. Pour gérer les MQ, Java propose un standard nommé Java Message Service (JMS) dont WebSphere MQ en est une implémentation propriétaire. La particularité des MQ est que le client ne s adresse pas directement aux composants du serveur mais publie un message sur un réceptacle JMS (une queue). La réception d un message dans une queue va déclencher sur le serveur l activation d une instance de l EJB concerné pour pouvoir traiter ce message. Les EJB destinés au traitement de messages JMS sont appelés EJB orientés message ou Message Driven Bean (MDB). III OGME OGME 3 est un outil interne développé à PRO BTP qui permet de visualiser et de corriger les messages en erreur en provenance de plusieurs applications via une interface web. En effet, les applications qui utilisent une MQ reçoivent parfois des messages qui ne peuvent pas être traités. Cela arrive si un message est incomplet, mal formaté ou à cause de l indisponibilité d un service par exemple. Par défaut, WebSphere propose deux mécanismes pour gérer ce type d erreur. Si rien n est fait, le message est consommé quoi qu il arrive à la sortie de la méthode. On perd donc l information contenue dans le message. L autre option, le rollback, permet de remettre le message en file d attente afin de le traiter ultérieurement. Cette option n a d intérêt que dans le cas d une indisponibilité 3. Outil de Gestion des Messages en Erreur 24

26 FIGURE III.2 Liste des messages en erreur dans l application OGME temporaire d un service. En effet, un message mal formé ne pourra jamais être traité sans une rectification externe et bouclerait dans la MQ. Le rollback présente néanmoins des défauts majeurs, en plus de la consommation obligatoire des messages mal formés, en cas de longue indisponibilité d un service on risque d avoir un nombre conséquent de messages en rollback, au risque d atteindre la limite de la MQ ce qui provoquerai le blocage de l envoi de nouveaux messages. De plus WebSphere possède un mécanisme qui va supprimer les messages de la file d attente au bout d un certain nombre de rollback. On risque alors de perdre des messages, soit car ils ont été remis trop souvent en file d attente, soit car ils n ont pas pu être émis car la file d attente était pleine. C est pour palier ces problèmes qu OGME a été créé. Il va réceptionner via une MQ tout les messages qui ont été mis en erreur car ils n ont pas pu être traités par l application qui les a reçu. L utilisateur pourra alors utiliser l interface web d OGME pour visualiser la liste des messages en erreur pour une application donnée (cf. figure III.2 page 25). Cette 25

27 FIGURE III.3 Écran d édition d un message en erreur dans OGME liste permet de visualiser en un coup d œil le nombre de massages en erreur, la date à laquelle ils ont été déposés et enfin, la raison pour laquelle le message n a pas pu être traité. L utilisateur peut alors directement choisir de remettre le message dans la MQ de l application (si l erreur est due à une indisponibilité de service par exemple), de le supprimer ou bien de l éditer. S il choisit de l éditer, l utilisateur arrive alors sur l interface présentée sur la figure III.3 page 26 qui affiche les valeurs des attributs du message et permet d en modifier certains. Là encore l utilisateur peut choisir soit de supprimer le message s il s avère que celui-ci ne peut pas être corrigé, soit de le modifier afin de le renvoyer dans la MQ de l application source pour un nouveau traitement. 26

28 III.1.2 Description détaillée du sujet Le process FMA se présente sous la forme d une application Java standard qui est exécutée à intervalle régulier par un script sur un serveur. Cette configuration la rend plus difficile à maintenir qu une application Java WebSphere. De plus le process FMA n offre que des fonctionnalités assez basiques qui ne correspondent plus au besoin actuel. En effet, le process FMA ne dispose pas d une MQ pour recevoir ses ordres, il ne permet pas donc pas d utiliser OGME pour gérer les erreurs et il ne prend pas en charge les pièces jointes pour les s. L application Pomme offre des fonctionnalités similaires au processus FMA. Le but est de proposer Pomme en substitution du process FMA aux développeurs qui ont besoin d utiliser la messagerie asynchrone dans leurs applications. De plus Pomme propose une fonctionnalité de personnalisation plus avancée grâce à la possibilité d indiquer directement dans le code source de la maquette, quelles informations provenant des services publics doivent être récupérées pour être insérées dans le texte. Mon travail sur cette partie consistera donc dans un premier temps à faire évoluer l application Pomme afin que celle-ci soit compatible avec le type de maquettes utilisées par le Process FMA. Le support des maquettes FMA de type sera implémenté dans un premier temps, puis, le type de document SMS et le support des maquettes FMA de type SMS seront ajoutés. La seconde partie consistera elle à mettre en place une MQ afin de simplifier l ajout d ordre dans Pomme depuis les autres applications. Je devrais donc développer un MDB 4 qui va lire l ordre reçu afin de l enregistrer dans la base de donnée s il est valide. Ce MDB devra utiliser OGME pour gérer les messages en erreur. Je devrais donc aussi modifier OGME afin d y ajouter la prise en charge des messages en provenance de Pomme. Enfin une phase de test suivie de la mise en production de l application est prévue après la phase de développement. 4. Message Driven Bean (cf glossaire p. 40) 27

29 III.2 III.2.1 Description du travail réalisé Prise en charge des maquettes FMA L application Pomme gère déjà deux types de maquettes différents, les maquettes JCMS récupérées depuis une url, et les s dont le corps du message est inscrit directement dans la base de données avec l ordre. Plutôt que de développer une nouvelle classe spécifique aux maquettes FMA, il fut plus simple et plus pertinent de modifier uniquement la partie permettant de récupérer la maquette afin de réutiliser les fonctionnalités de personnalisation déjà existante. Le support des maquettes FMA de type se résuma donc à l ajout d une méthode qui va lire le fichier de configuration FMA afin de récupérer le corps du message depuis le fichier adéquat. Une fois celui-ci récupéré, les balises FMA du type {0} sont converties en balise ${POMPARAM-0} afin que le texte soit directement personnalisable via Pomme. De plus cette approche permet d inclure des variables Pomme services publics ou système dans des maquettes du Process FMA. L ajout des maquettes SMS FMA demanda l ajout d un nouveau type de document dans Pomme. J ai donc dû développer la classe SMS destinée à être manipulée par les applications consommatrices de Pomme et stockée dans la base de données. La récupération des maquettes SMS se fait en lisant le fichier de configuration FMA, de la même manière que pour les maquettes FMA de type . L envoi de SMS n étant pas pris en charge par EVE, cette partie a été mise en suspens dans l attente de trouver la solution la plus appropriée pour gérer l envoi de ce type de document. III.2.2 Mise en place d une MQ Afin de permettre aux applications d utiliser l outil Pomme, nous avons mis en place une MQ. Celle-ci permet de transmettre facilement des objets java d une application à une autre. Ces messages sont stockés dans un réceptacle géré par un serveur WebSphere, que l application destinataire soit démarrée ou non, ce qui permet d avoir une plus grande fiabilité, aussi due au fait que l on ne dépend pas d un service tiers tel une base de données. Mon travail sur cette partie consista à développer un MDB qui est chargé de réceptionner l ordre puis vérifier son intégrité avant de le placer dans la base de données. Si 28

30 l ordre n est pas valide ou si une erreur intervient lors du déroulement de l une de ces étapes, le message sera placé dans une MQ d erreur dédiée à Pomme. III Gestion des messages en erreur avec OGME OGME est configuré pour lire les MQ de rejet d une liste d applications données. Il me fallut donc dans un premier temps configurer OGME afin de lui indiquer l identifiant de la MQ de rejet de Pomme. FIGURE III.4 Édition d un ordre en erreur dans OGME La liste des messages 5 peut alors être affichée, elle présente le nombre de message en erreur avec, pour chaque message, la raison pour laquelle il est en erreur. Afin de pouvoir afficher correctement le formulaire d édition, OGME doit connaitre le nombre de champs disponibles et leur type. Pour cela il faut indiquer dans un fichier 5. Une capture d écran de l interface présentant la liste des messages en erreur est disponible en figure III.2 page