Le besoin initial
La RTM a confié à bluedrop.fr, qui maintient et développe ses applications web, le soin de développer une application web, si possible mobile, permettant de diffuser, en temps réel, les pannes d'escalators et d'ascenseurs sur l'ensemble de son réseau. Ces informations, importantes à l'attention des usagers - notamment pour des questions d'accessibilité -, le sont également pour les équipes internes de la Régie des Transports qui doit, au plus vite, envoyer une équipe sur les lieux afin de remettre en état le matériel défectueux ou simplement stoppé. Cette application doit par conséquent proposer des degrés de lecture différents - localisation de la panne pour les usagers / type de panne pour les équipes techniques, notamment pour savoir si le dépannage doit concerner plusieurs ressources et quel outillage, plus ou moins lourd, à déployer sur place.
La RTM dispose de son propre outil de détection des pannes. En DMZ, des sondes remontent les dysfonctionnements et les stockent dans une base de données SQL Server. Le besoin concernait par conséquent la création d'une API, de ses webservices, afin d'exposer les données, les plus fraiches possibles, sur les différents outils de communication numérique du réseau. Notre mission a été de concevoir l'architecture de l'applicatif, de l'expliquer, puis de le développer. Il a consisté à :
- créer les webservices permettant aux différentes interfaces d’afficher les données ;
- documenter les webservices sous la forme d’une API simplifiée ;
- intégrer les webservices au site rtm.fr ;
- exposer les flux aux autres applicatifs abonnés.
Source des données à manipuler et webservices
Différents senseurs et automates peuvent monitorer l’état des équipements. Ces équipements utilisent des protocoles industriels (différents des standards du web) pour communiquer sur le réseau interne de la RTM :
- OPC
- MOD/TCIP
Ces données ont été consolidées dans une base de données et rendues accessibles via des réseaux séparés. Une application (la technologie employée n’a pas d’importance) a été mise à disposition par le client dans le but de requêter toutes les 20 secondes les différents automates et capteurs du réseau de transport et écrire les données pertinentes pour les webservices sur une seule base de données en DMZ.
Une fois cette base de données accessible, bluedrop.fr a pris en charge le développement d'une application web capable d’exposer ces données sous la forme d’une API RESTFUL au format JSON. Nous avons bien entendu veillé à mettre en place des solutions de cache (Varnish) pour solliciter au minimum les requêtes en base de données.
Les requêtes sur l’API sont limitées aux seuls prestataires autorisés (protection à l’aide d’un TOKEN).
Contraintes d'accès
La base de données doit être obligatoirement hébergée en DMZ sur le réseau interne de la RTM. Les services informatiques de la RTM étant très stricts sur la sécurité, il n'a pas été possible :
- de requêter cette base données directement de l’extérieur, même au travers d’un VPN ;
- de répliquer cette base de données (master -> slave) de la DMZ vers l'hébergeur.
Architecture retenue
1 |
Toutes les connections depuis internet (client http vers drupal, mobile) arrivent sur la plateforme de l'hébergeur.
|
2 |
L'applicatif mobile envoi ses requêtes en http sur une URL définie qui récupère le Json.
|
3 |
La plateforme gère donc les afflux, la montée en charge, les attaques, la disponibilité (99,9%).
|
4 |
L'applicatif gère un cache des réponses.
Il convient de transiger sur la durée de vie maximum des informations, les réponses à envoyer en cas de non réception (mode déconnecté, envoi des dernières informations, ou d'une erreur).
|
5 |
Nous préconisons un blocage IP entre les IP du client chez l’hébergeur et le réseaux du client, qui peuvent être gérées au sein des firewalls.
|
6 |
Nginx est utilisé comme serveur passerelle. Il permet le filtrage IP, le filtrage via regExp des URL, logging des accès. Il peut être hébergé sous Windows ou Linux. Il doit être transparent et ne pas modifier les données (aucun traitement, ni cache).
|
7 |
Les applicatifs développés par le client pour questionner les sondes envoient le résultat en http.
|
8 |
Un applicatif simplifié permet l’accès via webservice aux informations présentes dans la base volatile CouchDB. L’applicatif dispose de fonctions de formatage des réponses, d’aggrégation, et de gestion des TTL.
Il est possible de développer un "Getter" par variable, par type de variable ou pour toutes les variables (getAll).
|
9 |
L'applicatif CouchDB est préconisé comme mémoire volatile. Il ne permet pas de gérer l'historisation, la résilience, ni l'intégrité des données, mais présente une gestion des accès simultanés et un temps de réponse optimal pour cette fonction.
|
10 |
Disposant d’un accès http, CouchDB peut être joint directement par les sondes (en-tête à respecter) pour encore plus de réactivité.
|
Le déploiement du webservice et le traitement frontend
La page du site Internet - L’internaute consulte sur cette page l’état de marche des Escaliers mécaniques et des ascenseurs présents dans les stations de métro. Cette page est composée des éléments suivants :
- Les stations (liste de toutes les stations) ;
- Les détails d’état de marche par station.
- Les données de cette page sont requêtées en temps réel dans via le webservice dès l’ouverture de la page.
Les stations - Les stations des deux lignes de métro sont listées sur cette page. Les stations ayant un ou plusieurs dysfonctionnements sont mises en évidence (couleur, pictos d’alertes, cerclage ou autre). Cela permet à l’internaute de visualiser rapidement si sa station est concernée par un dysfonctionnement ou non.
L’utilisation des pictos est importante car en un coup d’œil, l'utilisateur doit savoir si le dysfonctionnement touche les Escaliers Mécaniques ou les Ascenseurs de sa station. Il doit aussi savoir combien d’appareils sont hors service sur le nombre d’appareils total. Des exceptions sont à prévoir pour les stations ayant des Escaliers Mécaniques en double qui ont le même sens de fonctionnement. Tant qu’une station dispose d’un Escalier Mécanique en montée et en descente, alors la station n’est pas considérée comme disposant d'un problème bloquant.
La maquette graphique
Comportement mobile
Le Webservice
- Le webservice renvoie les résultats au format JSON.
- Il peut être interrogé en HTTP ou Curl.
Exemple de résultats :
{
"total_rows": 131,
"offset": 0,
"rows": [
{
"id": "GTI.ASC.ARM.01",
"key": null,
"value": {
"_id": "GTI.ASC.ARM.01",
"_rev": "10875-cc9f29c4e1ee99a97650a1c553a5e2b2",
"date_evenement": "2016-03-04 8:51:26.290",
"id_evenement": "???",
"type_evenement": "0000",
"valeur_etat": "???",
"id_equipement": "GTI.ASC.ARM.01",
"type_equipement": "ASC",
"lieu": "ARM",
"num_equipement": "a",
"nom_equipement": "N°01 Louis Armand",
"lignes": "M1",
"id_data": "."
}
},
{
"id": "GTI.ASC.ARM.02",10pt">"key": null,
"value": {
"id": "GTI.ASC.ARM.02",
"_rev": "10875-7b6026dea7817118bc359106fd0f90ea",
"date_evenement": "2016-03-03 14:41:50.980",
"id_evenement": "???",
"type_evenement": "0000",
"valeur_etat": "???",
"id_equipement": "GTI.ASC.ARM.02",
"type_equipement": "ASC",
"lieu": "ARM",
"num_equipement": "a",
"nom_equipement": "N°02 Louis Armand",
"lignes": "M1",
"id_data": "."
}
},
...
]}
Vous pouvez bien entendu consulter l'évolution des pannes sur le réseau de la RTM aux url suivantes :