Rapport de stage Automate de tests SLE/SLC : STReAMS

Transcription

1 IUT de Lannion Rue Edouard Branly LANNION GL TRADE 28 rue Notre Dame des victoires PARIS Rapport de stage Automate de tests SLE/SLC : STReAMS Vincent KERGONNA Etudiant en 2 e année d IUT Génie des Télécommunications et Réseaux Stage effectué du 13 avril au 30 juillet 2004, sous la direction de Quynh-Nhu Phung (GL TRADE) et Jean-François Wicker (IUT).

2

3 IUT de Lannion Rue Edouard Branly LANNION GL TRADE 28 rue Notre Dame des victoires PARIS Rapport de stage Automate de tests SLE/SLC : STReAMS Vincent KERGONNA Etudiant en 2 e année d IUT Génie des Télécommunications et Réseaux Stage effectué du 13 avril au 30 juillet 2004, sous la direction de Quynh-Nhu Phung (GL TRADE) et Jean-François Wicker (IUT).

4 Mes remerciements à : Monsieur Pierre Gatignol pour m avoir permis d effectué mon stage dans sa société. Richard Gémon, directeur d European Exchange System. Loïc Borgne pour m avoir permis d intégrer son équipe. Quynh-Nhu Phung pour avoir accepté de me suivre sur le projet STReAMS. Vincent Babeau, Aude Cornouiller, Odile Dupuis, Faustin Essou, Nicolas Honoré, Laurent Lachèvre, Nicolas Latrille, Frédéric Lemaire, Magali Loison pour l aide qu il ont pu m apporter. Yann Conan et Xavier Poire pour leur patience lors des tout premiers tests grandeur nature de STReAMS.

5 Table des matières Introduction 8 I Présentation de l entreprise 9 1 Introduction 9 2 Historique 9 3 Stratégies et technologie au sein de GL Trade Stratégie de la société Les principaux produits de GL Trade Le GL WIN Le SLC : Serveur Local de Collecte Le SLE : Serveur Local d Emission Le GL NET Le département EES 1 15 II Le projet : STReAMS 17 5 Présentation du projet 17 6 Principes de fonctionnement Les différents modes de fonctionnement Le mode spy Le mode Client Le mode Serveur Le mode Duo Le mode Code/Decode Spécifications techniques Interface principale Protocole de communication Traitement des fichiers Traitement des trames Traitement fonctionnel Affichage/Décodage Debit règlable Requêtes GL Requête GL codée European Exchange System 5

6 7.8.2 Requête GL non codée Caractéristiques injection Duo Le besoin de synchronisation Merge des fichiers de messages client et bourse Cinématique d injection duo Contraintes de la reproduction d un dysfonctionnement Etapes de réalisation Package communication Codage / décodage GL Création d exécutable Etat de départ du projet 27 9 Les améliorations à apporter Mon travail sur STReAMS Entrée en matière Corrections de bugs et ajout de fonctionnalités Simulation sur le SLE Bovespa Amélioration des fonctionalités de communication Les sockets distantes Les sockets locales Intégration de librairies externes Création de packages d installation Autres taches Résultats Conclusion 33 A Annexes A 34 A.1 Fichiers Interfaces entre Java et une librairie native Références 36 Index 38 2 Version du SLE spécifique au brésil 6

7 Liste des tableaux 1 Données administratives Données financières Table des figures 1 Le siège de GL Trade La fenetre principale du GL Win Interconnexion SLC, SLE, Bourse et GL WIN Le réseau mondial GL NET Organigramme d EES Principe de fonctionnement global de STReAMS Principe de fonctionnement en mode Spy Principe de fonctionnement en mode Duo Fenêtre principale de STReAMS Fenêtre Spy Fenêtre Client/Server Fenêtre Duo Fenêtre Code/Decode Graphe d héritage de la classe StreamsSocket

8 Introduction Le stage que j effectue fait partie de ma formation de technicien des télécommunications et réseaux. Il se déroule du 13 avril au 30 juillet 2004 dans la société GL TRADE basée à Paris dans le second arrondissement. Cette société est spécialisée dans les solutions électroniques de négociation en temps réel. Mon stage s effectue sous le parrainage de Quynh-nhu Phung responsable architecture et qualité des produits EES 3. Je suis arrivé chez GL TRADE le 13 avril Je fut accueilli par monsieur Loïc Borgne qui me présenta le service dans lequel j allais travailler. Il me présenta aussi toutes les personnes qui allaient travailler avec moi au cours de mon stage ainsi qu un autre Stagiaire, Miguel Ferrero, qui travaille sur le même projet que moi. Je fus, dès lors, intégré dans le service chargé des développements pour la zone Paris Sud Europe et en charge du développement de mon projet. Ce projet, déjà commencé à mon arrivé, est destiné à fournir un automate de test pour les serveurs SLE 4 et SLC 5. Mais je commencerais tout d abord par vous faire une présentation de l entreprise et de ces produits pour ensuite présenter le projet qui m a été confié et le travail que j ai pu accomplir sur celui-ci. 3 European Exchange System 4 Serveur Local d Emission 5 Serveur Local de Collecte 8

9 Première partie Présentation de L entreprise : GL Trade 1 Introduction La société GL Trade a été fondée en 1987 lors de la première électronisation complète du marché financier le MONEP par Mr Pierre GATIGNOL et Mr Louis-Christophe LAURENT. GL Trade est une société technologique spécialisée dans les services d information financière et de négociation boursière. Elle fut la première société à fournir les outils nécessaires pour la négociation des options sur la place de Paris. Tout juste un an après sa création, elle avait déjà plus de 30 clients parmis les 40 sociétés boursières présentes dans la région de Paris. Le siège de GL Trade se situe à Paris au 48 rue Notre Dame des victoires, juste derrière le palais de la bourse. La société compte aujourd hui plus de 860 employés à travers le monde et dispose de bureaux sur toutes les grandes places boursières. GL Trade s est imposé comme le leader mondial dans son domaine. Fig. 1 Le siège de GL Trade 2 Historique GL Trade est une Société Anonyme à conseil d administration. Lors de sa fondation GL Trade s appellait GL Consultants. Pendant les premières années GL Consultants ne développe ses produits que pour la bourse de Paris. C est à partir de 1995 que les choses s accélèrent lorsque l électronisation des marchés prend de l ampleur. GL Consultants signe des accords un peu partout en europe et vend ses produits en Suisse, Allemangne et Suède. En 9

10 1997, GL Consultants signe un contrat avec le CME 6. En 1998, la gamme des produits GL s étend avec le rachat de Chronobourse. GL Consultants devient alors GL Trade. Cette même année, GL Trade ouvre des bureaux à Frankfort, New York et Chicago. En 1999 GL Trade acquiert FL Software à Londre et Tenor Software en France, faisant ainsi de GL Trade le leader dans son domaine. Depuis la société continue de signer des contrats avec les différents marchés boursiers à travers le monde. Elle continue ainsi a s agrandir et à gagner de nouvelles parts de marché, tout en affichant une très bonne rentabilité. Nom GL Trade Status Société Anonyme à conseil d administration Adresse 28 rue notre Dame des victoires Paris Représentants légaux Pierre Gatignol et Louis-Christophe Laurent Téléphone Mail info@gltrade.com Tab. 1 Données administratives CA Q1 CA Q2 CA Q3 CA Q4 CA 1er Semestre CA Annuel 2003 (MAC) (MAC) (MAC) (MAC) (MAC) Tab. 2 Données financières 3 Stratégies et technologie au sein de GL Trade 3.1 Stratégie de la société S appuyant sur le succès de sa station de négociation multi-marché GL WIN et de son réseau mondial GL NET, GL TRADE développe une gamme de produits électroniques pour les opérations de middle-office et propose aux professionnels des solutions originales de négociation via internet. La principale stratégie de GL Trade est donc de fournir des produits et des services multi-marchés. En effet, GL Trade se heurte généralement seulement à des concurents locaux très spécialisés 7 ce qui lui permet de s imposer rapidement sur de nouveaux marchés. 6 Chicago Mercantile Exchange 7 Exemple : Atos en France. 10

11 3.2 Les principaux produits de GL Trade GL Trade développe trois produits principaux pour ces clients. Ces produits sont : le GL WIN, le Serveur Local de Collecte et le Serveur Local Emission Le GL WIN Le GL WIN est un des composants principaux de l architecture de GL TRADE. GL WIN est un client universel fonctionnant sous Windows NT (figure 2 page 11). Fig. 2 La fenetre principale du GL Win Entièrement configurable, il couvre les 3 principaux domaines de compétence de GL TRADE : Station de visualisation de flux financiers pemettant d afficher notament : Les cours des valeurs Les dépêches financières Des graphiques journaliers (intradays) et historiques Station de négociation évoluée permattant l envoi et la gestion Des ordres simples Des stratégies (ordres multiples) 11

12 Des paniers de valeurs (basket trading) Des ordres soignants (care orders) D ordres issus de modules de négociation automatique destinés au arbitragistes (Arwin) et aux market markers (Automate) Outil de Middle office incluant des fonctionnalités de : Tenue de position Contrôles de risques Affectation de comptes, split et regroupement des exécutions Un client GL WIN est, par ailleurs, toujours connecté au minimum à un SLC Le SLC : Serveur Local de Collecte Le SLC est un serveur de collecte d informations financières permettant d alimenter des clients (cf. figure 3 page 12). Au début de la chaîne de diffusion, le SLC permet d intégrer plusieurs flux financiers issus : Bourse SLC SLE Client GL WIN Fig. 3 Interconnexion SLC, SLE, Bourse et GL WIN 12

13 Des systèmes centraux de bourse. De prestataires divers : AFP (dépêches) REUTERS A l autre bout de la chaîne, le SLC diffuse les informations aux postes clients qui en font la demande. Les informations sont traitées en temps réel tout au long du processus. Le flux d information reçu par le SLC est diffusé par une bourse dans un format qui lui est propre. Lorsque le SLC reçoit ce flux, il traduit les informations au format GL TRADE, afin que ces informations puissent être transmises au poste GL WIN. L intégration de ces informations et leur traduction au format GL TRADE est réalisée par un processus spécifique. Il en existe un par bourse Le SLE : Serveur Local d Emission Le SLE est chargé d acheminer les ordres du négociateur jusqu à la bourse concernée et traite les réponses du marché. Le SLE appartient à un membre du marché. Le SLE est capable d accepter les connexions de plusieurs clients ainsi que d assurer la gestion des ordres de plusieurs négociateurs (cf. figure 3 page 12). Chaque bourse dispose d un système central de négociation spécifique. Il est donc nécessaire d avoir une version spécifique du SLE pour chaque système central. Ainsi une version du SLE permettant par exemple de négocier sur EUREX ne peut pas être utilisée sur LIFFE. Le SLE maintient en local un carnet d ordres qui est la copie de ce que contient le système central de cotation pour ce SLE. Ce carnet d ordres permet de : 1. gérer et mettre à jour les ordres de chaque utilisateur en fonction : des commandes utilisateurs des retours du marché 2. répondre aux demandes de consultation des applications clientes telles que : historique des ordres synthèse des exécutions Le SLE gère aussi une base d authorisation qui contient : 1. la liste des utilisateurs autorisés à se connecter ainsi que le mot de passe associé à chaque utilisateur 2. le profil de chaque utilisateur. Un utilisateur peut-être : Normal Superviseur. Le superviseur est un utilisateur qui a la possibilité de visualiser, modifier et annuler les ordres des utilisateurs qu il supervise. 13

14 Soignant. Le principe des ordres soignants (Care orders) est de permettre à un vendeur d envoyer des ordres à un négociateur afin que ce dernier les exécute sur le marché. filtré ou non. 3.3 Le GL NET GL TRADE dispose aussi de son propre réseau de communications : GL NET. GL NET est une de clés de voûte de l offre GL car ce réseau permet de déployer les applications client/serveur à l échelle mondiale sur un réseau privé. Fig. 4 Le réseau mondial GL NET Le réseau GL NET à pour but de : Diffuser les flux en temps réel Acheminer les ordres issus d écrans délocalisés vers les membres locaux des différentes bourses. Le réseau GL NET permet l accès à la majorité des marchés électroniques. GL TRADE à mis en place des points d accès appelés «Hubs», à proximité des principales places financières et de ces clients. Ces Hubs consituent l infrastructure physique et logique permettant aux clients de se raccorder au réseau GL NET. Tous les Hubs sont reliés entre eux par des liaisons haut débit et sécurisées, gérées par différents opérateurs télécom d envergure mondiale ou nationale. De plus GL TRADE a opté pour une stratégie de doublement physique de 14

15 ses points d accès pour garantir une disponibilité maximale de son réseau. GL TRADE offre ainsi à ses clients une sécurité accrue. 4 Le département EES 8 Mon stage s effectue au sein du département EES de la direction des produits. Le rôle du département EES est de développer des passerelles bourse pour la zone européenne. Ce département est divisé en plusieurs équipes spécialisées. Chacune d entre elles s occupe d une zone géographique particulière. Chaque équipe est composée d un manager, d un chef d équipe de développement, de chefs de projet fonctionnel et de développeurs. L équipe avec laquelle je travaille est celle chargée des développements pour la zone PSE 9, incluant les bourses de Paris, Luxembourg, Lisbone, Madrid... 8 European Exchange System 9 Paris Sud Europe 15

16 Fig. 5 Organigramme d EES 16

17 Deuxième partie Le projet : STReAMS 5 Présentation du projet Mon projet de stage consiste à développer un simulateur de tests permettant de rejouer une séquence de fonctionnement d un serveur SLE ou SLC. Ceci afin de palier à la non disponibilité des plates-formes de bourses, et aussi dans le but d automatiser les tests. Ce simulateur, nommé STReAMS, est entièrement écrit en java ce qui facilite le portage du logiciel vers différentes plates-formes. Il est ensuite destiné à être utilisé par les développeurs et les testeurs afin d effectuer des tests sur les SLE et les SLC. Ces tests consisteront à rejouer une séquence définie et enregistrée à l avance, afin de comparer les résultats obtenus avec ceux obtenus lors de l enregistrement de cette séquence. Ceci permettra de valider d éventuelles corrections de bug ou, la non régression d un logiciel. Fig. 6 Principe de fonctionnement global de STReAMS Pour réaliser ce projet je travaille avec un autre stagiaire, Miguel Ferrero, qui effectue son stage de validation de DESS. Nous sommes la troisième génération de stagiaires a travailler sur STReAMS. Le but est de finaliser STReAMS et de le rendre opérationnel. 17

18 6 Principes de fonctionnement Le principe de fonctionnement de STReAMS est assez simple. STReAMS est capable, au choix, d enregistrer un flux qui transite entre deux applications ou de rejouer un flux enregistré auparavant. Pour enregistrer un flux, on place STReAMS entre les deux applications qui échangent ce flux. STReAMS va alors se comporter comme un tuyau et enregistrer tout ce qui passe dans ce tuyau (cf. figure 7 page 18). Pour réaliser, par exemple, l enregistrement d un flux entre un client et un SLE, on connecte le client à STReAMS qui lui même se connecte au SLE. Fig. 7 Principe de fonctionnement en mode Spy Pour rejouer un flux, on configure STReAMS pour simuler, soit un client, soit la bourse ou même les deux à la fois. Pour réaliser une telle simulation STReAMS va lire des fichiers de logs contenant les flux à rejouer. STReAMS va se connecter au SLE du coté client comme si il s agissait d un client GL WIN et simuler un serveur de bourse sur lequel le SLE va venir se connecter (cf. figure 8 page 19) 18

19 Fig. 8 Principe de fonctionnement en mode Duo 6.1 Les différents modes de fonctionnement Lorsque l on démarre STReAMS on obtient une fenêtre principale telle que représentée sur la figure 9 page 19. Fig. 9 Fenêtre principale de STReAMS Le mode spy Le mode spy a pour but d enregistrer un ou plusieurs flux. Le spy peut être placé entre le client et le SLE/SLC ou entre le SLE/SLC et la bourse. Comme on peut le voir sur la figure 10 page 20 le spy affiche toute les trames qu il capture dans sa fenêtre. Il fonctionne un peu comme un analyseur de trame. Il capture une trame au format que l on lui a indiqué, la décode, l affiche et enfin l enregistre. L enregistrement se fait dans deux fi- 19

20 chiers différents : un pour les trames venant du serveur et un pour les trames venant du client. Le but du mode spy est d enregistrer des séquences que l on pourra ensuite rejouer à l aide du mode Client/Server ou à l aide du mode Duo. Fig. 10 Fenêtre Spy Le mode Client Le mode client (fig. 11 page 21) a pour but de simuler un client. Il va pour celà se connecter sur un SLE au travers d un P3 10, comme le ferais un client GL WIN. Pour celà il suffit, comme pour le mode spy, de configurer STReAMS en lui donnant l adresse IP et le port du serveur sur lequel il doit se connecter. On pourra ensuite choisir le fichier de log que l on veut rejouer Le mode Serveur Le principe du mode serveur est un peu le même que celui du mode client. Sauf que cette fois c est le client GL Win ou le SLE qui va venir se connecter à STReAMS. Là encore, il suffit de choisir le fichier de log que l on veut rejouer après avoir configurer le port sur lequel STReAMS va attendre les connections. STReAMS simulera alors soit un SLE, soit la bourse. 10 Routeur par lequel passe toutes les requêtes GL avant d atteindre un SLE ou un SLC 20

21 Fig. 11 Fenêtre Client/Server Le mode Duo Le mode Duo est le mode le plus intéressant : c est grâce à ce mode que l on va pouvoir automatiser les tests d un serveur SLE ou SLC. Dans ce mode STReAMS est capable de simuler à la fois un client GL WIN et la bourse. Ceci va nous permettre de rejouer un flux enregistré chez le client et, en même temps, les réponses renvoyées par la bourse à ce même client. La fenêtre du mode Duo se présente comme sur la figure 12 page Le mode Code/Decode Le mode Code/Decode (figure 13 page 22 est un mode qui permet de décoder un fichier de log contenant des trames au format GL et de les modifier pour ensuite les recoder. Cependant ce mode de STReAMS est encore en cours de développement et permet, pour l instant, seulement de décoder des requêtes. 21

22 Fig. 12 Fenêtre Duo Fig. 13 Fenêtre Code/Decode 7 Spécifications techniques 7.1 Interface principale La barre principale est totalement indépendante, celà veut dire que STReAMS pourra gérer les diverses fonctionnalités en même temps : espion, test mode, injection mode. Chaque fonctionnalité s exécutera sur une fenêtre indépendante. Les fonctionnalités sur l IHM 11 de STReAMS seront communes aux tests SLE et SLC. La fenêtre principale se présentera sous la forme d une barre de menu. Puis, selon la fonctionnalité choisie, STReAMS ouvrira une fenêtre spécifique au mode choisi. 11 Interface Homme Machine 22

23 Pour la fonctionnalité espion, STReAMS ouvrira autant de fenêtres que d espions voulus. Chaque fonctionnalité demandée s exécutera dans une fenêtre indépendante. Ainsi, l utilisateur peut tester à la fois SLC, SLE, envoyer des requêtes, du flux tout en surveillant les messages passés entre les processus. 7.2 Protocole de communication 1. Le protocole de communication entre le client, le SLE et la bourse sera direct suivant le protocole TCP/IP d envoi. Les flux de messages sont échangés sur des sockets. 2. Les formats des messages échangés sont multiples. Du côté client, l application dialoguera au format GL (GLV3 et GLV5). Du côté bourse, l application sera modulaire pour intégrer les différents formats bourses (FIX, MMTP,...). Les deux applications pourront dialoguer au format des requêtes GL codées. 3. Pour gérer la communication entre les applications et le SLE, il faudra configurer les ports dans les deux applications et pour chacune ajouter certaines informations : Dans l application Cliente, il faudra configurer l adresse IP de la machine où le P3 se trouve, le port de connexion avec le P3, et le format de requête. Dans l application Bourse, il faudra configurer le port de connexion avec le SLE. Le format bourse (FIX 4-1, FIX ) sera choisi par l utilisateur. Principales techniques utilisées : Connexion par socket TCP/IP Connexion par socket TCP/IP type local pour les processus SLC. Connexion de type pipe Gestion de threads 12 pour connexion multi-serveurs/clients 7.3 Traitement des fichiers Sauvegarde et chargement des fichiers de configuration Sauvegarde et chargement des fichiers pour injection Merge des fichiers client et serveur pour injection en mode duo 7.4 Traitement des trames Reconnaître les structures de données (format de messages, format de requêtes) en dynamique. 12 Fils en français. Ils permettent à un programme d exécuter plusieurs actions en même temps. 23

24 Utiliser les méthodes de codage/décodage GL existantes en dynamique Découper les trames GL Coder/Décoder les trames GL Transformer hexa/ascii 7.5 Traitement fonctionnel Analyse/Comparaison des résultats de tests automatiques. 7.6 Affichage/Décodage Ce mode peut être activé ou désactivé pour chaque fonctionnalité : test, injection, espion. En cas de besoin de rapidité de l outil (injection de paniers par exemple ou tests de performances) le décodage du message pour l affichage du message complet peut être désactivé totalement ou partiellement (affichage juste quelques données essentielles). Le décodage est le principal acteur de consommation de ressources dans STReAMS. 7.7 Debit règlable STReAMS fournit un bilan à la fin de l injection pour certaines informations comme le débit réel effectué. On pourra éventuellement mettre en place un système de réglage de débit en utilisant une temporisation. 7.8 Requêtes GL Requête GL codée Les requêtes GL codées sont enregistrées en hexadécimal dans le fichier de log. On enregistre chaque requête sur une nouvelle ligne. Format : 11h37mn39s79 => #0251fa1f2ff0018cfafa # Pour reproduire un dysfonctionnement il est impératif d avoir tous les messages tracés Requête GL non codée Le format est à valider, la proposition est comme suit : une requête par ligne horodatage avec requête entourée par # numéro de champs = valeur du champs séparé par le caractère pipe. Exemple : 11h37mn39s79 => #1=toto 2=titi 3=tat# 24

25 7.9 Caractéristiques injection Duo Le besoin de synchronisation Pour reproduire exactement une séquence de messages, il est essentiel de respecter l ordre d envoi des messages aussi bien dans les applications elles mêmes qu entre les différentes applications. Or, les dates des messages heure de capture sont très proches, même milliseconde. Pour respecter l ordre des messages, il faut d une part tracer la date au centième de secondes et d autre part ralentir la séquence en ajoutant un paramètre temps. Deux paramètres sont à utiliser : Temporisation entre les envois Nombre d envois à chaque activation Merge des fichiers de messages client et bourse Pour reproduire la séquence de message, à partir des deux fichiers client et bourse qui seront de la forme date/message, un nouveau fichier chronologique sera créé permettant à l application de lire ce fichier et de gérer l envoi de messages des deux côtés. Ce fichier sera de la forme : C0 t1 message1 C1 t2 message2 S0 t3 message3 S0 t4 message4 C0 t5 message5 S1 t6 message6 S1 t7 message7 S0 t8 message8... Ce fichier doit être mergé avant la procédure d envoi. Le résultat du merge peut être sauvegardé dans un fichier pour la réutilisation. Ceci veut dire que STReAMS doit permettre aux utilisateurs la possibilité de : Merger les fichiers Sauvegarder le fichier de résultats Injecter le flux à partir d un fichier mergé Injecter le flux à partif de deux fichiers client et bourse (dans ce cas STReAMS utilise la fonctionnalité merge et la fonctionnalité envoi) Cinématique d injection duo Afin de respecter la synchronisation des deux applications cliente et bourse, l interface de saisie des deux noms de fichier servira aussi d arbitre 25

26 pour cadencer le client et la bourse afin de les prévenir d envoyer un certain message à un certain moment. Pour cela, l application va parcourir deux fichiers client et bourse, les lire et gérer l envoi des messages dans les applications client et bourse Contraintes de la reproduction d un dysfonctionnement Le SLE doit être dans le même état que lors de l enregistrement du scénario c est à dire posséder les bases et les mêmes paramètres de configuration. Dans le fichier slesfe.ini : il faut changer l adresse IP de connexion la bourse, les numéros de maillon émis et reçu (que l on trouve dans le premier message bourse). Dans le fichier seqnum.ini, les numéros de séquence émis et reçu (que l on trouve dans le premier message bourse). Dans le fichier log bourse, le SLE ne trace pas tous les messages, en particulier les heartbeats qui sont envoyés par la bourse environ toutes les secondes ce qui rendrait les fichiers trop volumineux. Il faut donc recréer les messages manquants. Il faut trouver une solution pour pallier à ces problèmes Etapes de réalisation Package communication Revoir le fonctionnement du package communication, pour permettre la connexion de plusieur clients simultanément sur un même port. Développer une librairie pour permettre à STReAMS d utiliser les sockets locales sous unix Codage / décodage GL Tester, debugger la librairie de décodage et codage GL. Réintégrer la nouvelle librairie de de codage/décodage dans STReAMS Création d exécutable Package d installation : outil d installation Création Binaire solaris Création Binaire NT Création Binaire Linux Documentation Guide Utilisateurs 26

27 8 Etat de départ du projet Lorsque je suis arrivé STReAMS était déjà capable d enregistrer et de rejouer des séquences dans les protocoles FIX et MMTP. STReAMS disposait aussi d une interface utilisateur complètement terminée. STReAMS souffrait cependant de quelques lacunes comme l automasation inexistante des tests, un mauvais support du codage/décodage des trames GL ainsi que des fonctionnalités manquantes dans la partie communication. 9 Les améliorations à apporter Le but du stage est de finaliser le produit. Les tâches à effectuer sont les suivantes : 1. Générer un package du logiciel 2. Rédiger une documentation utilisateur 3. Amélioration des fonctions de communications 4. Support du Codage/Décodage des requêtes GL 5. Support du Codage/Décodage des messages Bourse Format SIBE Format SAX Format greffon EUREX Format greffon XETRA Format greffon IPE Format greffon EBS Format greffon LIFFE 6. Automatisation des tests 10 Mon travail sur STReAMS 10.1 Entrée en matière Mon travail sur STReAMS consistait la première semaine à comprendre le fonctionnement de ce qui avait déjà été fait et à rédiger une documentation utilisateur. Comprendre le code source du programme ne fut pas des plus aisé. En effet il n y avait que très peu de commentaires dans le code source et de plus celui-ci était souvent mal indenté, ce qui rendait sa lecture difficile Corrections de bugs et ajout de fonctionnalités Pour mieux comprendre le code et rentrer un peu dans le projet j ai commencé par corriger les petits bugs que je trouvais et par ajouter quelques nouvelles fonctionalités. J ai par exemple amélioré et harmonisé le support 27

28 de la sauvegarde et du chargement des fichiers de configuration qui ne fonctionnait pas correctement dans tous les modes auparavant. J ai aussi ajouté une fonctionnalité pour exporter les trames décodées dans un fichier. Par ailleurs, j ai aussi procédé à la documentation du code afin de permettre aux futur développeurs qui interviendront sur STReAMS de comprendre plus rapidement le code Simulation sur le SLE Bovespa 13 En parallèle avec le déveoleppement de STReAMS j ai effectué des tests de l outil sur la version Bovespa du SLE. Au départ ces tests ont été réalisés dans l optique de reproduire un bug. Pour ces tests j ai travaillé en colaboration avec Yann Conan et Xavier Poiré qui s occupent du développement du SLE Bovespa. Nous avons pour ces tests utilisé le mode Duo de STReAMS. Le but était de rejouer les fichiers de log fournis par le client afin de reproduire le bug que le client avait rencontré. Cependant la tache s est avérée être plus compliquée que prévue et nous n avons pas réussi à rejouer correctement ces fichiers de log Amélioration des fonctionalités de communication Cependant, la plus grosse partie de mon travail à par la suite consité à améliorer les fonctionalités de communications de STReAMS Les sockets distantes En effet, en mode spy STReAMS ne peut accepter qu une seule connexion sur son port d écoute. J ai donc choisi quitte à repartir de zéro de développer et de mettre en oeuvre de nouveaux objets, dédiés à la communication, qui permettent d accepter plusieurs clients simultanément. Cette partie de mon travail sur STReAMS est l une de celles qui m a posé le plus problème. En effet, il n était pas question de détruire complètement l existant. Or réutiliser les objets existant, nécessitait une réécriture complète de ceux-ci. J ai donc développer mes propres objets de communication dans l optique de les intégrer au spy pour commencer. Ils se déclinent comme suit : StreamsSocket : contient les attributs et méthodes commun à tous les objets StreamsSocket StreamsServerSocket : contient les methodes de connexion spécifiques à un serveur. StreamsClientSocket : contient les méthodes de connexion spécifiques à un client. 13 Version du SLE spécifique au brésil 28

29 StreamsSocketSpy : contient les méthodes permettant de capturer et d enregistrer un flux sur une socket. StreamsSocketReplayer : contient les méthodes nécessaires pour rejouer un flux sur une socket. Tous ces objets sauf le premier héritent de StreamsSocket et sont threadés. Fig. 14 Graphe d héritage de la classe StreamsSocket Deux problèmes majeurs ce sont posés à moi lors de la création de ces objets. Le premier problème s est posé pour un objet de type StreamsSocket- Server associé à des objets StreamsSocketSpy. En effet, lorsqu un nouveau client se connecte sur un objet de type StreamsSocketServer, celui-ci accepte la connexion puis récupère un nouveau descripteur de socket avant de créer un objet de type StreamsSocketSpy. Cet objet StreamsSocketSpy est totalement indépendant et écoute sur le descripteur de socket nouvellement créé. Or lorsque l utilisateur demande à se déconnecter il faut pouvoir fermer tous les descripteurs de socket ouverts. Pour pouvoir faire celà l objet StreamsSocketSpy est doté d une méthode close qui permet de fermer la socket. L objet StreamsServerSocket quand à lui rescense tous les objets StreamsSocketSpy qu il a créé. Ainsi lorsque l on fait appel à la méthode close de StreamsServerSocket, celle-ci fera appel à la méthode close de chaque objet StreamsSocketSpy rescensé. Le second problème que j ai rencontré est que dans le mode Spy STReAMS doit agir comme un tuyau. Un objet StreamsSocketSpy doit donc être capable de retransmettre la communication à tous les objets StreamsSocketSpy qui ne sont pas du même type que lui, à savoir client ou serveur. Pour réaliser celà j ai défini un objet spécifique à l intérieur même de l objet StreamsSocketSpy : SpyObject. Cet objet contient une référence au descripteur de socket et le type de la socket. J ai aussi ajouté un attribut statique à l objet StreamsSocketSpy. Cet attribut n est autre qu un tableau qui référence tous les objets SpyObject créés. Du fait de sa nature statique ce tableau est commun à tous les objets StreamsSocketSpy créés et permet donc de renvoyer 29

30 facilement les données sur les autres sockets, donc de l autre coté du tuyau Les sockets locales Un autre des problèmes de streams est qu il ne peut pas se connecter sur des sockets locales de type unix. Or il peut être nécessaire d utiliser les sockets locales. Dans le cas d un SLC par exemple, celà permettrait de capturer les communications qui circulent entre les différents processus du SLC. Développer un support pour les sockets locales sous unix, s est avéré, au final être assez compliqué. En effet, le language Java ne propose pas d objets ou de méthodes permettant d accéder à ce type de sockets. Il a donc fallu trouver une solution pour permettre tout de même à STReAMS de lire et d écrire sur celles-ci. Le choix s est porté sur le développement d une librairie externe spécifique à unix. La librairie a été développée en C 14 s et dispose de toutes les fonctions nécessaires pour connecter, déconnecter, lire et écrire sur des sockets locales. Une telle librairie utilisée dans un programme Java est une librairie dite native. Lors du développement d une librairie native pour un programme Java il faut commencer par écrire le fichier d interface en Java. Une fois ce fichier interface créé, on peut à partir de celui-ci générer un fichier d en-tête spécifique pour la librairie native. Ensuite, il ne reste plus qu à programmer la librairie en C, sans se soucier du reste. Le développement de cette librairie ne m a pas vraiment posé de problèmes. Je regrette juste de ne pas avoir pu faire de tests en utilisant cette librairie, ce faute de disponibilité de la plate-forme de tests et aussi à cause d un changement dans les priorités de développement Intégration de librairies externes Un autre problème de STReAMS était le mauvais fonctionnement du décodage pour les requêtes GL. Il etait, par ailleurs, complètement impossible de les recoder. Miguel Ferrero, l autre stagiaire qui travaille sur le projet avec moi, a donc développé des librairies externes capables de faire ce travail. C est ensuite à moi qu à été confiée la tache de les intégrer dans le code source de STReAMS. J ai donc du éliminer toutes les méthodes de codage qui étaient obsolètes et intégrer la nouvelle librairie pour les remplacer. Cette librairie est écrite en C/C++. Comme j avais déjà développé une librairie externe pour STReAMS le principe d intégration était exactement le même. L intégration a été assez aisée, d autant que le fichier interface existait déjà puisqu il est nécessaire de le créer avant de commencer à programmer la librairie. 14 Le C est un langage de programmation 30

31 J ai donc intégré la librairie de codage/décodage dans STReAMS et j en ai profité pour concevoir un objet dédié à l affichage des trames sur l écran. Avant l intégration de la librairie l affichage était programmé de manière un peu anarchique, c est à dire que chaque objet contenait du code nécessaire à l affichage. Celà avait pour effet de rendre ce code redondant et la maintenance de celui-ci difficile Création de packages d installation Une partie de mon travail sur STReAMS a aussi été de créer des packages d installation. Pour réaliser cette tache j ai utilisé un petit logiciel gratuit disponible librement sur internet : Install Creator. Un binaire d installation pour windows à ainsi pu être réalisé. Ceci afin de faciliter l installation du logiciel pour les utilisateurs. Sous Linux et Solaris j ai opter pour un simple fichier d archive compressé. Un script permettant à l utilisateur de lancer facilement le programme sur ces systèmes d exploitations à aussi été écrit. Ainsi l utilisateur n a plus qu à décompresser l archive de STReAMS dans son répertoire et à lancer le script pour démarrer l application. On notera cependant que nous nous heurtons pour l instant à un problème d intégration de la librairie de codage/décodage pour les version Solaris et Linux de STReAMS. STReAMS peut fonctionner sur ces systèmes seulement si l on désactive l affichage des requêtes décodées, ce qui limite les fonctionnalités de l outil Autres taches En parrallèle de tout ceci, le support utilisateur pour les développeurs qui avaient commencés à utiliser STReAMS a dû être assuré. J ai aussi eu l occasion d effectuer des tests sur des SLE avec certains d entre eux. Nous avons, par ailleurs, travaillé en collaboration avec Maximilien Holle pour la mise en ligne de STReAMS sur le site intranet de la société Résultats STReAMS, dispose maintenant des fonctionnalités de communication qui lui faisaient défaut auparavant. A savoir : utiliser les sockets locales de type unix pour discuter avec d autres processus et accepter plusieurs clients sur sa socket d écoute. Nous sommes aussi capables à ce jour de coder et décoder correctement les requêtes GL. De plus nous avons finallement résolu le problème rencontré lors des test sur le SLE Bovespa et sommes maintenant capable de rejouer correctement ces logs (cf. section 10.3 page 28). 31

32 Cependant les fonctionnalités d automatisation des tests sont toujours en cours de développement, mais nous devrions être en mesure de terminer cette partie automatisation des tests assez rapidement. 32

33 Conclusion Le projet STReAMS n a pas encore atteind les buts qui lui était fixés. Cependant mon stage se prolonge jusqu au 30 juillet et j espère donc dans ce labs de temps restant pouvoir atteindre les objectifs fixés. Durant mon travail sur le projet STReAMS j ai rencontré différents problèmes que j ai dû résoudre dans des délais les plus courts possible. La difficulté du sujet étant importante il n est cependant pas évidant que tous les buts du projet STReAMS seront atteints d ici à la fin juillet. En effet, les problèmes rencontrés en rejouant certaines trames MMTP pourraient bien se reproduire pour d autres protocoles et nous faire prendre du retard. D un point de vu général ce stage m a apporté une meilleure connaissance de l entreprise et de son fonctionnement. Il m aura par ailleurs permi de mettre mes connaissances acquises au cours de mes deux années d iut en application et à la disposition de mes collègues. J ai aussi eu, durant mon stage, à rendre compte de l avancement de mon projet au travers de réunions de projet. D un point de vue technique il m aura permi de consolider mes connaissances en programmation. Sur le plan personnel ce stage m a permi de montrer mon aptitude à travailler en équipe et à m intégrer au sein d un groupe. Il m a aussi permi de prouver mes capacités d adaptations faces aux différentes situations qui pouvaient se présenter à moi. Et finallement il m a permi d acquérir une expérience professionnelle très enrichissante. 33

34 A Annexes A A.1 Fichiers Interfaces entre Java et une librairie native Pour implémenter certaines fonctionnalités de STReAMS nous avons été obligé d utiliser des librairies dites natives. Ne connaissant pas du tout le JNI 15 avant de commencer, nous nous sommes basés sur le livre de [1] Sheng Liang. Voici un exemple de fichier interface que nous avons du écrire (code Java) : /** * StreamsDecodeGL.java */ public class StreamsDecodeGL { static { System.loadLibrary("StreamsDecodeGL"); } public static native String decode(string sens, String msg); public static native String code (String sens, String msg); } Le fichier ci-dessus est en fait une classe Java. Nous allons ensuite compiler cette classe à l aide du programme javac livré en standard dans le JDK de Sun. javac StreamsDecodeGL.java On obtient suite à cette commande un fichier du même nom mais avec l extension.class cette fois. Il nous suffit maintenant de donner le nom de ce fichier en argument à la commande javah. javah -jni StreamsDecodeGL Le résultat est le fichier entête (.h) suivant : /* DO NOT EDIT THIS FILE - it is machine generated */ #include <jni.h> /* Header for class StreamsDecodeGL */ #ifndef _Included_StreamsDecodeGL #define _Included_StreamsDecodeGL #ifdef cplusplus extern "C" { #endif /* * Class: StreamsDecodeGL * Method: decode 15 Java Native Interface 34

35 * Signature: (Ljava/lang/String;)Ljava/lang/String; */ JNIEXPORT jstring JNICALL Java_StreamsDecodeGL_decode(JNIEnv *, jclass, jstring, jstring); JNIEXPORT jstring JNICALL Java_StreamsDecodeGL_code(JNIEnv *, jclass, jstring, jstring); #ifdef cplusplus } #endif #endif Par la suite on écrit le programme en C comme à l habitude. La seule difficulté réside ici dans le fait qu il faut faire le lien entre Java et C. C est pourquoi on utilise ici des types définis dans les fichiers d entêtes du JNI. Compiler la librairie native ne pose ensuite pas de problèmes particuliers. Sous solaris par exemple on compile la librairie comme ceci : cc -G -I/java/include -I/java/include/solaris StreamsDecodeGL.c -o libstreamsdecodegl.so Comme on le voit sur la ligne de commande ci-dessus, il ne faut pas oublier d indiquer le chemin vers les fichiers d entête du JNI. 35

36 Références [1] Sheng Liang. The Java Native Interface Programmer s Guide and Specification [2] Sun Microsystems, Inc. Java API Reference : http ://java.sun.com/j2se/1.4.2/docs/api/ 36

37 Index EES, 15 GL NET, 14 GL WIN, 11 Modes de fonctionnement, 19 Client, 20 Code/Decode, 21 Duo, 21 Serveur, 20 Spy, 19 MONEP, 9 SLC, 12 SLE, 13 STReAMS, 17 Améliorations à apporter, 27 Principes de fonctionnement, 18 Spécification techniques, 22 37

38 Résumé Mon stage se déroulait du 13 avril au 30 juillet 2004 dans la société GL TRADE sous le parrainage de Quynh-Nhu Phung. finaliser et de mettre en oeuvre un simultateur de tests. Nous commencerons par présenter brièvement l entreprise avant de rentrer dans le vif du sujet à savoir le projet. La société GL TRADE fut créée en 1987 à l occasion du MONEP par monsieur Pierre Gatignol et monsieur Louis-Christophe Laurent. GL TRADE est spécialisé dans le developpement de solutions électroniques de négociation en temps réel. Elle développe trois principaux produits qui sont : le GL WIN, le Serveur Local de Collecte et le Serveur Local d Emission. GL TRADE dispose aussi de son réseau de communications, baptisé GL NET. GL TRADE base sa stratégie sur son réseau et ses trois produits principaux, afin de fournir à ses clients un environnement de négociation multi-marché. Le projet sur lequel j ai travaillé était la réalisation d un simulateur de tests pour le SLE. Ce simulateur, appelé STReAMS, devrait permettre à terme d automatiser les tests sur un SLE, tout en palliant à la non disponibilité des plate-formes de bourse. STReAMS est capable d enregistrer un flux sur le réseau et de le rejouer. L intêret est ici de pouvoir simuler soit un client, soit la bourse ou les deux à la fois. Le travail apporté sur STReAMS à principalement consisté en l amélioration des fonctions de communications et du décodage des différents protocoles utilisés par les produits GL. L automatisation des tests est actuellement toujours en cours de développement. Finallement, le projet est en passe d atteindre ses objectifs mais ne sera sans doute pas terminé à la fin de mon stage.