Etude d amélioration de la fonction Validation dans Chouette NOT - Chouette-Irys Etude Validation- V 1.2 12/06/2014
SOMMAIRE AIntroduction... 4 BFormat de restitution des rapports de validation... 4 Export Tabulaire...5 Export d un document de synthèse... 6 Export d un document détaillé... 6 CConfiguration des tests... 7 Présélection de tests selon une thématique...7 Regroupement de tests en un seul point de contrôle...7 Simplification des paramètres de tests...8 DSuivi de l état d avancement et file d attente... 9 EProposition d évolution vers un serveur IEV... 10 E.1Démarche pour le choix de la solution... 10 E.2Présentation de 3 cas d utilisation... 11 1. Cas nominal : API REST pour le service web (SW) de validation... 11 2. Validation par IHM... 11 3. Serveur de certification... 11 Comparaison avec Github (https://github.com/) & Travis (https://travis-ci.org/)... 12 Comparaison avec Github et d autres services de validation... 13 Comparaison avec l ancien site Bateri... 13 Besoin d informer sur les opérations en cours en cas de forte sollicitation... 14 E.3Proposition d un Service Web pour les fonctions IEV... 14 E.4Solution 1 : serveur IEV sans IHM... 15 1. Améliorations de Chouette apportées par le WS IEV...16 Hébergement de l application Chouette... 16 2. Cas d une plateforme de certification...17 Limitations par comparaison à Github / Travis... 18 Répartition de la charge... 18 Conclusion... 18 E.5Solution 2 : serveur IEV avec IHM... 19 1. Améliorations de Chouette apportées par un serveur IEV avec WS+IEV... 19 Hébergement de l application Chouette... 19 2. Cas d une plate-forme de certification...20 DO A130719-2 - Maintenance, accompagnement et recette de logiciels pour les échanges de données multimodales LOT 1 2/16
A Introduction Ce document est le résultat d'une étude commandée par l'afimb le 30/04/14 et dont le cahier des charges du 24/01 était le suivant «La version 2.2 est en cours de livraison. La fonctionnalité de validation est centrale pour Chouette, et assez complexe. Certaines améliorations ont déjà été identifiées. L'objectif de ce cahier des charges est d'étudier ces améliorations. Le devis devra séparer la proposition commerciale et la proposition technique, cette dernière étant partagée via BaseCamp. Les améliorations suivantes devront être étudiées : - export des résultats dans un fichier TXT, - mécanisme de validation en mode web service (soit via une sorte de session, soit par échanges entre serveur Chouette et serveur de données à valider - sur le principe de codeclimate qui va analyser régulièrement le code d'un dépôt git) - meilleure gestion de la file d'attente - configurabilité des tests à effectuer (beaucoup de points de contrôle sont complexes et n'ont pas forcément d'intérêt, selon les besoins) Cityway peut également proposer d'autres améliorations. Livrables attendus: - proposition technique et fonctionnelle pouvant servir de base à des spécifications en vue de lancer les développements, estimation du coût et du délai» Le plan de l étude traite successivement les améliorations suivantes : - exports TXT (B) - configurabilité (C) - le suivi de l avancement des validations (D) - validation en mode web service (E), qui est la partie principale de l étude Pour cette partie, on commence par présenter les 3 principaux cas d utilisation du service web de validation que nous avons identifiés (utilisation par une application tierce, chouette2, plate-forme de publication), puis on précise quel services devraient fournir l API web (qui couvrirait l ensemble IEV et pas la seule validation), enfin, on compare deux variantes de solutions, la première limitant l accès au serveur IEV au seul service web, la seconde complétant le serveur IEV par une IHM complète. B Format de restitution des rapports de validation Plusieurs formats de restitution de rapports peuvent être envisagés selon la finalité du rapport : - Pour un usage de statistiques et de métriques (suivi qualité des données par exemple), un format tabulaire est le mieux adapté. - Pour un usage de compte-rendu, ou de synthèse, un format documentaire est le mieux adapté. Un convertisseur de format peut enrichir le nombre de formats sans alourdir le développement; il peut : - soit être intégré à Chouette, - soit être proposé pour un usage spécifique d un utilisateur en dehors de Chouette. Pandoc (http://johnmacfarlane.net/pandoc) par exemple, fonctionnant sous Linux, Windows et MacOS répond à cette fonctionnalité pour les formats documentaires. L introduction d un tel outil permet de limiter le nombre de formats à réaliser dans l application tout en DO A130719-2 - Maintenance, accompagnement et recette de logiciels pour les échanges de données multimodales LOT 1 3/16
offrant un éventail plus riche. La conversion de tableaux est moins évidente car les plus simples à produire n offrent pas les fonctionnalités des plus complexes : formules, génération d histogramme, Toutefois, comme l usage de ces tableaux est très différent d un utilisateur à l autre, il nous semble difficile de proposer ces fonctionnalités. Nous proposons de nous limite donc à 3 types d export : 1. export tabulaire 2. export d un document de synthèse 3. export d un document détaillé Export Tabulaire Cet export restitue les résultats de chaque test en donnant la référence du test, l état, la gravité et le nombre d erreurs rencontrées. Les lignes seront classées par numéro de tests; les tableurs permettant de redéfinir le tri selon le souhait de chacun. Les formats envisagés sont : - csv : soit un seul fichier, soit un par niveau de tests - xlsx : soit un seul onglet, soit un par niveau de tests Export d un document de synthèse Le document de synthèse comprend : - un rapport synthétique précisant le nombre de fichiers et d objets de chaque type contrôlé, répartition des problèmes par état et par gravité. - la liste des différents tests avec leur gravité, leur état et le nombre d occurrence de l erreur si l état est erreur Les formats envisagés sont : - un format texte balisé tel que Markdown ou Textile pouvant être utilisé ensuite par Pandoc. - un format PDF selon une présentation unique définie lors de la réalisation - un format docx ou odt sans présentation; à charge à l utilisateur d apporter sa charte à postériori Export d un document détaillé Le document détaillé comprend : - le contenu du document de synthèse - la liste des tests en erreur avec pour chacun le détail des objets en erreurs limité aux n premiers objets rencontrés pour chaque test (la valeur n, non paramétrable, a été fixée lors du développement du module de test à 50). Les formats envisagés pour le document détaillé sont les mêmes que pour le document de synthèse. En pratique par rapport à la demande initiale d export des résultats dans un fichier au format Texte, nous proposons de produire un fichier.zip regroupant dans plusieurs fichiers tabulés de type CSV les différents types de résultats produits par une validation : synthèse, validations type 1/2/3. C Configuration des tests La fonction IHM de validation ne masque probablement pas suffisamment la complexité de cette fonction. DO A130719-2 - Maintenance, accompagnement et recette de logiciels pour les échanges de données multimodales LOT 1 4/16
Pour simplifier l usage, il est possible d agréger certains tests, de revoir leur classification. Il est possible aussi de simplifier l IHM de saisie des jeux de paramètres de validation. Ce chapitre présente ces différentes solutions. Présélection de tests selon une thématique Lors de la validation de niveau 3, il est intéressant de pouvoir limiter l analyse pour se concentrer sur une partie du domaine ou pour exclure des tests sur des données dont l'utilisateur sait qu'elles sont absentes. Thèmes pouvant être évoqués : - Réseau de surface : retirer les tests sur les accès - Topologie : retirer les tests sur les missions, courses, horaires et calendriers - Offre horaire : retirer les tests sur la topologie : réseau, groupes de ligne, arrêts, correspondances. - Référentiel des arrêts : limiter les tests aux arrêts, accès et correspondances Regroupement de tests en un seul point de contrôle Un certain nombre de tests peuvent être regroupés sous la même appellation : Niveau 2 : Tests Nouvelle cible Nouvelle description StopArea-2 StopArea-3 StopArea-4 StopArea-5 StopArea-6 AccessPoint-3 AccessPoint-4 AccessPoint-5 AccessPoint-6 StopArea non ITL Vérification de la correcte référence des fils des arrêts : - StopPlace : contient des StopArea de type StopPlace ou CommercialStopPoint - CommercialStopPoint : contient des StopArea de type Quay ou BoardinPosition - Quay et BoardingPosition : contient des StopPoint StopArea non ITL AccessPoint, AccessLink Vérification de la correcte référence à une position géographique (<AreaCentroid>) dans les arrêts (<StopArea>) (hors ITL) et de la référence réciproque dans la position géographique référencée. Vérification de liens d accès valides (<AccessLink>) sur les accès (<AccessPoint>) : - -tout accès a au moins un lien d accès, - -si l accès est de type in : il n a que des liens partant de lui, - -si l accès est de type out : il n a que des liens aboutissant à lui, - -si l accès est de type inout : il a au moins un lien partant de lui ET un lien aboutissant à lui. Remarque : Les tests actuels ont fait l objet d une présentation au GT7.2 le 24/09/13. Aucune opposition n a été formulée sur cette proposition. S il y a un changement au niveau de tests de conformité, une communication auprès GT7 est à prévoir, soit pour information ou pour avis. Tout changement dans les tests actuellement définis pose 2 problèmes la lisibilité des tests réalisés sur une version de Chouette antérieure à cette évolution. Il est aussi possible de convenir que tous les rapports de validation ou d import passés seront détruits au moment du déploiement de cette fonctionnalité. l indication dans le rapport de test de la version de Chouette utilisée. Autrement dit le rapport de validation est relatif à une version de Chouette. DO A130719-2 - Maintenance, accompagnement et recette de logiciels pour les échanges de données multimodales LOT 1 5/16
Niveau 3 : Pas de suggestion de regroupement de tests, ceux-ci ont déjà été suffisamment regroupés lors de leur première implémentation. Simplification des paramètres de tests Le jeu de paramètres est riche mais dans la plupart des cas, peut s avérer lourd à saisir. Il est possible de proposer une vue simplifiée regroupant des paramètres sous la même appellation : en résultat, les paramètres regroupés se partageront la même valeur ou une valeur déduite de la valeur simplifiée. A tout moment, l opérateur pourra revenir à la vue normale et ajuster comme il désire l ensemble des paramètres. Valeurs pouvant être regroupées : Libellés Nouveau libellé Règle de partage Distance maximum entre un arrêt et son parent Distance maximum entre les arrêts en correspondance Distance maximum d'une liaison accès arrêt Distance maximum entre un arrêt et un équipement Distance maximum entre 2 arrêts, accès ou équipement permettant un transfert piéton Egalité des valeurs Vitesse de marche maximum pour un voyageur ordinaire (Vord) Vitesse de marche maximum pour un voyageur occasionnel (Vocc) Vitesse de marche maximum pour un voyageur habituel (Vhab) Vitesse de marche maximum pour un voyageur à mobilité réduite (Vred) Vitesse de marche pour un voyageur ordinaire Proposition de règle de partage (critères à fixer lors du développement) Vocc = Vord x 75% Vhab = Vord x 150% Vred = Vord x 50% En résumé, nous proposons donc : - de regrouper certains tests de niveau 2 (en précisant ce qu il advient des rapports de validation & import passés et en informant le GT7.2 des changements) - de proposer de jouer certains tests groupés par types d objet - de proposer un paramétrage simplifié D Suivi de l état d avancement et file d attente Le suivi de l activité du serveur (ou application) IEV peut se suivre au niveau global par rapport à l ensemble des demandes en cours. Toutes les opérations IEV sont implémentées dans les composants Java. Il y a cependant une exception qui porte sur le l export KML. En effet cet export est implémenté directement sur l application IHM (application développée en Ruby On Rails). Si l on souhaite rendre compte de toutes les opérations IEV (y compris les exports KML), il est DO A130719-2 - Maintenance, accompagnement et recette de logiciels pour les échanges de données multimodales LOT 1 6/16
nécessaire de restituer une synthèse de l activité du serveur IEV et des exports KML sur l application IHM. Nous proposons en outre que le suivi soit aussi possible au niveau d une opération IEV. Pour cela, nous proposons de décomposer les processus IEV en une série d étapes. Les étapes dépendent de l opération (import, export ou validation) et du format (Neptune, GTFS, données en base, etc ). Par exemple dans le cas d un import, les étapes peuvent être éventuellement structurées de manière générique sous forme de phases et de compteur associé : Phase : lecture de fichier, avec un compteur 1 / n Phase : structuration & sauvegarde, avec un compteur 1 / n n représente le nombre de fichiers contenus dans l archive à importer (n = 1 pour un fichier Neptune XML). Dans cette proposition, l import se décompose en 2 phases seulement. Selon la finesse attendue au niveau du suivi des opérations IEV, les étapes peuvent être plus ou moins macroscopiques. Bien sur, plus les étapes sont nombreuses pour entrer dans le détail de l exécution de l opération, mieux l utilisateur peut suivre la progression. Par contre cela demande plus d effort de développement. Au cours de l exécution d une opération IEV, le serveur IEV pourra ainsi fournir une indication de l étape en cours. Ce suivi d avancement d une opération et de la file d attente globale IEV doit également être ajouté à l interface Web IEV discutée dans la partie suivante. E Proposition d évolution vers un serveur IEV E.1 Démarche pour le choix de la solution La demande de validation en mode web service vise à introduire une plus grande souplesse dans l utilisation de la validation Chouette, néanmoins elle implique des développements qui impactent l architecture du logiciel. Or Chouette est en fait constitué de 2 logiciels, chouette en java, qui implémente notamment, et chouette2 en ruby, l application, et qui utilise chouette en java (sous forme d un programme java compilé permettant de réaliser les opérations d import-export-validation IEV, chouette-gui-command.jar). Il faut donc une solution qui plus globalement s insère en une architecture cohérente chouette-java / chouette2-ruby. Il semble donc essentiel de l étudier de manière assez approfondie. Nous proposons la méthode suivante pour répondre à ce besoin : 1. présenter les principaux cas d usage de la validation - cas nominal : service web de validation - cas 1. validation via l IHM Chouette - cas 2. serveur de certification 2. préciser le service que doit fournir l API web 3. proposer une solution et analyser comment elle répond aux 3 cas d utilisation, le cas échéant comparer avec une variante 3. Conclure DO A130719-2 - Maintenance, accompagnement et recette de logiciels pour les échanges de données multimodales LOT 1 7/16
E.2 Présentation de 3 cas d utilisation Les cas d usage présentés dans ce chapitre illustrent différents besoins liés aux fonctionnalités IEV. 1. Cas nominal : API REST pour le service web (SW) de validation Pour le développement d applications tierces, l usage de Chouette peut se limiter à des opérations IEV et donc à la seule partie «java» de l application, dans l architecture actuelle. Le service web permet de lancer des opérations IEV à distance, sans héberger chouette sur son propre serveur (ce qui est nécessaire pour faire appel à la ligne de commande). Imaginons une société qui souhaite développer un service ayant un lien indirect avec une offre de transport TC : PDA, PDE, étude de «marchabilité», analyse d offre, étude d accessibilité, etc : pour ce type de service, l édition des données TC n a aucun intérêt ni même la visualisation de celle-ci. Seule la fonction d import des données est utile, par exemple lorsque celles ci sont proviennent de l OpenData. Dans ce cas, il est préférable de disposer d une interface permettant d alimenter une base Chouette à partir des jeux de données en OpenData. Le service web de validation doit faire partie d un service web donnant accès aux fonctions IEV par une API indépendante du langage. L application tierce ayant besoin de la fonction de validation (ou d import, ou d export) peut alors être développée dans un langage quelconque. 2. Validation par IHM L application web chouette2 doit évidemment continuer à permettre import, export et validation depuis l IHM web. Soit chouette2 continue à utiliser la librairie chouette-gui-command comme actuellement, soit chouette2 s appuie désormais sur le nouveau service web. 3. Serveur de certification Le cas d'usage visé ici correspond à celui d un serveur de certification de plates-formes de publication. Imaginons une plate forme de publication qui mette à disposition un jeu de données et en même temps son état de validité (à la manière de Travis pour une version de sources Github, Cf. ci-dessous) : à chaque opération de publication, une demande de validation est adressée au serveur de certification. De cette manière, il est possible de faire apparaître l état de validité sous la forme d un badge mettant en avant le résultat final (valide ou non) ainsi qu un accès au détail des tests de validation. Comparaison avec Github (https://github.com/) & Travis (https://travis-ci.org/) Les applications Github, Travis fournissent un exemple illustrant ce cas d utilisation (à noter que le code chouette2 publié sur le compte Github de l'afimb utilise travis, code climate et gemnasium.) ; nous décrivons ici la répartition des rôles entre Github et Travis et leurs interfaces. Dans notre cas, Github correspondrait un serveur de publication données transport «open data», et Travis correspondrait au serveur de validation Chouette. Github peut être vu comme une plateforme de «versionnement» et de publication de sources d application, ayant sa propre base d utilisateurs. Github est d abord un gestionnaire de sources qui permet, pour chaque nouvelle publication, de faire DO A130719-2 - Maintenance, accompagnement et recette de logiciels pour les échanges de données multimodales LOT 1 8/16
figurer un état de validation réalisé par Travis. Travis est un service de validation des sources d une application Github. Travis consulte seulement les sources sans les modifier. Travis s accompagne d une interface Web de consultation : - de l état des traitements en cours - de consultation du détail d une validation Travis n a pas de base d utilisateurs propre et repose sur celle de Github. Ceci permet de consulter sur Travis : - les validations propres à un utilisateur - relancer une validation Github permet d afficher pour chaque version de source le résultat de validation Travis. A chaque nouvelle version de sources déposée sur Github, Github déclenche un traitement de validation sur Travis. Comparaison avec Github et d autres services de validation CodeClimate (https://codeclimate.com/) est un service d évaluation de la qualité de code. Cette évaluation s applique à un code source dans un langage donné (ruby, javascript). Gemnasium (https://gemnasium.com/) est un service de contrôle de librairies ruby en dépendance d un code source. Le contrôle vérifie sur la version utilisée est récente ou non et si celles ci présente des failles de sécurité connues. Coveralls (https://coveralls.io/) est un service d évaluation de la couverture de tests entre autre Tous ces services permettent une inscription de s enregistrer directement ou bien d utiliser un compte Github. En dehors de ce mode d authentification, le principe de fonctionnement est le même que pour Travis. A chaque publication sur Github, ces services réalisent leurs différentes évaluations. Comparaison avec l ancien site Bateri L ancien site Bateri proposait un formulaire de validation de fichier accessible de manière anonyme. Par rapport aux fonctionnalités de Bateri, un serveur de certification de type Travis permettrait : de retrouver les précédentes validations d utilisateur de récupérer le fichier source testé un accès en Web Service de ne pas avoir à re-saisir à chaque fois ses propres critères de validation (pour les tests de niveau 3) de centraliser les résultats d une validation Besoin d informer sur les opérations en cours en cas de forte sollicitation Les fonctions IEV peuvent prendre un délai de traitement assez long qui dépend de la quantité de données à traiter. Par conséquent, il est possible qu à certain moment, le site appli.chouette.mobi soit fortement chargé par des traitements IEV en cours et moins disponible pour traiter de nouvelles demandes, fussent-elles sur de faibles volumes de données. Les outils tels que Travis sont confrontés au même problème. Les tests de validation de l application Chouette prennent plusieurs minutes en moyenne. Pour que l utilisateur n ait pas l impression que le service n est plus disponible, il est utile de rendre compte de DO A130719-2 - Maintenance, accompagnement et recette de logiciels pour les échanges de données multimodales LOT 1 9/16
l activité du serveur par une indication : des ou de la tâches en cours du nombre de tâches en attente L utilisateur pourra suivre ainsi la progression des traitements sans être tenté de recommencer inutilement un essai. Cette fonctionnalité est d ailleurs demandée dans le cahier des charges de la présente étude (cf. D). E.3 Proposition d un Service Web pour les fonctions IEV Actuellement les fonctions IEV sont fournies par différentes librairies JAVA (sources du dépôt Github chouette) et l accès à ces fonctions impose l usage d une ligne de commande. Les librairies JAVA peuvent être complétées pour fournir la mise à disposition des fonctions IEV en WS. Pour cela, il est possible de produire une librairie «war» pouvant être déployée sur des serveurs de type Tomcat, GlassFish Les applications tierces pourront ainsi utiliser les fonctions IEV indépendamment de l application chouette2 d édition & visualisation des données. L interface WS permet d utiliser le service indépendamment de java, ce qui laisse une grande liberté aux développeurs qui souhaitent intégrer ces fonctions IEV dans leurs projets : le choix du langage et des frameworks est très large pour s interfacer avec des WS. L interface WS peut être implémentée simplement sous forme d API REST JSON ou XML pour mettre à disposition les fonctions suivantes: - fonctions IEV actuelles - fonction d'abonnement du client Une API REST prévoit offre «traditionnellement» les 4 accès dénommés CRUD (pour Create, Read, Update, Delete). Dans le cas des fonctions IEV, la mise à jour (U dans l acronyme CRUD) ne fait pas de sens par rapport à ces fonctionnalités et ne sera pas proposée dans l API. Nous proposons d ajouter la fonction d abonnement car elle est nécessaire pour : notifier le client en fin d opération IEV produire des URLs vers les données en base dans le cas d une validation niveau 3 Lorsque une donnée en base qui est à l origine d une invalidité, les pages de résultat de validation fournissent une URL de page de visualisation de la donnée (cette page est produite par l application IHM Chouette). Il faut également préciser comment les autres évolutions proposées doivent être pris en compte par le WS : - la génération de rapports de validation sous forme de fichier texte relève de la présentation et donc de chouette2, et n a pas d impact sur les WS chouette-iev (étant entendu que le fichier texte ne contient pas d autres informations que celles déjà disponibles dans les IHM de validation) - le suivi des actions en cours et en attente doit être intégré à l API web - la configuration des paramètres de validation relève de l IHM et n a pas d impact sur le WS IEV L application Chouette IHM peut continuer à s interfacer en ligne de commande aux fonctions IEV comme actuellement, dès lors que les librairies d accès en ligne de commande sont maintenues. DO A130719-2 - Maintenance, accompagnement et recette de logiciels pour les échanges de données multimodales LOT 1 10/16
E.4 Solution 1 : serveur IEV sans IHM Cette solution scinde l application en 2 systèmes distincts ayant des interfaces interopérables: - serveur IHM - serveur IEV Le serveur IHM joue alors simplement un rôle : - de relais d'accès aux services IEV depuis un navigateur web - d affichage des rapports de validation, de consultation des opérations IEV 1. Améliorations de Chouette apportées par le WS IEV La prise en compte par chouette2 de l API IEV (à la place de chouette-gui-command actuellement) apporte les 3 améliorations suivantes : 1/ Suivi d avancement Au niveau du site appli.chouette.mobi, le serveur IHM serait désormais en mesure de : - notifier par mail l'utilisateur ayant lancé une opération IEV depuis l'ihm (pas en API REST qui est anonyme) lorsque l'opération est terminée. - rendre compte de la disponibilité des services IEV en indiquant combien de tâches sont en cours ou en attente - mettre à disposition les fonctions IEV en extension de son API REST existante 2/ Souplesse de déploiement Actuellement l accès à ces fonctions impose un passage par ligne de commande, et donc une installation en local d une partie de l application Chouette. Avec cette solution, le serveur IEV pourrait même être déployé sur une autre machine que le serveur IHM (sous réserve de partager un accès à la même base de données, celle-ci pouvant être hébergée également sur une autre machine). 3/ Evolutivité Le serveur IEV apporte une meilleure isolation entre les fonctions de présentation / édition des données (IHM) et les fonctions purement IEV. Ceci facilite notablement une éventuelle refonte de l'implémentation (à interface constante). Hébergement de l application Chouette Le serveur IEV n'a pas besoin d être accessible aux utilisateurs finaux, et donc de disposer de nom de domaine dédié. Les accès aux services IEV passent en effet par le serveur IHM qui reste le seul visible du «grand public». Le schéma ci-dessous présente la solution DO A130719-2 - Maintenance, accompagnement et recette de logiciels pour les échanges de données multimodales LOT 1 11/16
C est le serveur IHM qui se charge de produire les vues pour les fonctions IEV même si les traitements sont délégués au serveur IEV ensuite. 2. Cas d une plateforme de certification Le serveur IEV fournit les API à la plate-forme de certification. Pour une plate-forme de validation, les fonctions d export du service IEV ne seront pas utilisées. Il est nécessaire de faire évoluer la fonction de validation actuelle de Chouette de manière à réaliser : - d abord un import - ensuite une validation sur cet import (avec plus ou moins de tests de conformité de niveau 3) L import n a pas besoin d être visible du client, le référentiel associé à cet import doit être vide au début de l import et peut être détruit ensuite. Dans ce contexte donc, le serveur IEV doit disposer d une base locale de référentiels. Le serveur IEV ne gère pas de base d utilisateurs : cela implique que la plate-forme de certification ne peut proposer qu un service de validation anonyme. Par rapport aux tests de conformité de niveau 3 les tests ne peuvent être restreints à une seule partie des données mais doivent s appliquer à l ensemble du fichier fourni les rapports ne doivent plus pointer des données en base (comme c est le cas aujourd hui) mais leurs références dans le fichier source à valider. Selon la fréquentation de la plate-forme de certification et la profondeur d historisation souhaitée, il est nécessaire de prévoir : un espace de stockage suffisant DO A130719-2 - Maintenance, accompagnement et recette de logiciels pour les échanges de données multimodales LOT 1 12/16
une politique de nettoyage des ressources IEV (rapport ou fichiers d export) trop anciens Le schéma ci-dessous présente la solution dans ce contexte Le serveur BackOffice est en quelque sorte un CMS (Gestionnaire de contenu) qui met à disposition les jeux de données (au format GTFS, NEPTUNE, etc ) et qui fournit également les vues du détail de validation. Le serveur BackOffice renseigne ces vues en interrogeant le serveur IEV. Ce qui est important pour les utilisateurs finaux de la plate-forme de publication de données, c est d avoir accès au jeu de données en même temps que son état de validité. Limitations par comparaison à Github / Travis Comme l accès est anonyme, il n est pas possible pour un client de consulter uniquement ses propres opérations de validation. Par ailleurs, le serveur IEV ne fournit qu un WS REST au format JSON ou XML. Aucune vue HTML / JS n est produite : il s adresse donc à un système et pas à un utilisateur. La production d une vue HTML / JS (telles qu elles sont présentées dans Chouette) est à la charge du client, c est-à-dire de la plate-forme de publication. Répartition de la charge La fonction de validation seule offre une certaine souplesse pour être traitée en parallèle. Une opération de validation réalise de manière cachée utilise son propre référentiel pour réaliser un import. Deux validations concurrentes peuvent donc réaliser leur import en parallèle : seule la production des rapports d import se fait dans une base commune. Mais le temps nécessaire à l écriture du rapport est négligeable par rapport au temps de l import. DO A130719-2 - Maintenance, accompagnement et recette de logiciels pour les échanges de données multimodales LOT 1 13/16
Conclusion Cette solution ne fait pas de Chouette une plateforme de validation aussi complète que Travis. C est en effet une solution pour un service sans IHM sans compte utilisateur Cependant cette solution peut servir d étape avant un service du niveau de Travis. E.5 Solution 2 : serveur IEV avec IHM Dans cette solution, l application Chouette se découpe en : une application d édition de l offre une application IEV qui publie les fonctions IEV en IHM et en API REST Entre les 2 applications, il est nécessaire de prévoir un mécanisme d authentification unique (singlesign on : SSO) pour ne pas gêner la navigation des utilisateurs. Par rapport à la solution précédente : - l application IEV doit avoir la capacité de fournir un service en mode authentifié (en plus du mode anonyme) - la diffusion des rapports de validation sous forme de fichier Texte relève du serveur IEV. 1. Améliorations de Chouette apportées par un serveur IEV avec WS+IEV Par rapport à la solution 1, la solution décrite ici ajoute d autres avantages : - l IHM étant désormais côté serveur IEV, les vues HTML / JS et la génération des résultats au format texte sont réutilisables dans les différents contextes de déploiement (chouette2, plate-forme de publication...) - comme l application IEV gère des comptes utilisateurs, les utilisateurs peuvent consulter l historique de leurs propres validations. Hébergement de l application Chouette L application IEV est accessible aux utilisateurs finaux depuis un navigateur et dispose normalement d un nom de domaine dédié. Le schéma ci-dessous présente la solution dans ce contexte DO A130719-2 - Maintenance, accompagnement et recette de logiciels pour les échanges de données multimodales LOT 1 14/16
Les utilisateurs accèdent à 2 applications séparées ayant des facilités de navigation entre elles. Les applications tierces accèdent aux interfaces REST de l une ou l autre des applications. 2. Cas d une plate-forme de certification Par rapport à la solution précédente, le rapprochement avec Github / Travis est plus complet. Les utilisateurs (les personnes et pas seulement les systèmes) de la plate-forme de certification peuvent consulter les rapports de validation. Le schéma ci-dessous présente la solution dans ce contexte DO A130719-2 - Maintenance, accompagnement et recette de logiciels pour les échanges de données multimodales LOT 1 15/16
Dans cette solution, la plateforme de certification apporte les vues des fonctions IEV qui ne sont à la charge du backoffice de la plateforme de publication. Le Backoffice utilise néanmoins l API REST du serveur IEV pour déclencher une validation à chaque publication de jeu de données. De même, la page de publication (produite par le Backoffice) fait apparaître une indication de validité du jeu de données. Cette indication est obtenue par l interface REST du serveur IEV. En résumé: la solution 1, où le serveur chouette java est complété par un service web IEV mais reste sans IHM, la solution 2 où le serveur chouette-java est doté aussi de sa propre IHM, répond mieux au besoin d associer la validation à une plate-forme de publication de données. Elle nécessite toutefois une authentification commune avec chouette2 et de transférer l IHM IEV de chouette2 vers chouette, soit un effort de développement important. En pratique, on peut commencer par la solution 1, puis enchaîner sur la solution si le besoin de mettre en place un outil de certification à la Travis se confirmait. C est la solution que nous proposons qui permet des améliorations phasées avec une première possible livraison dès 2014. DO A130719-2 - Maintenance, accompagnement et recette de logiciels pour les échanges de données multimodales LOT 1 16/16