Intervox Systèmes est une filiale du groupe Legrand, spécialisée dans la téléassistance à domicile ou en EHPAD.
Elle équipe les domiciles des clients finaux de transmetteurs qui permettent de mettre en relation les abonnés avec leurs proches ou des télé-assisteurs en cas de besoin. Des capteurs équipent les transmetteurs et des périphériques appairés à ces derniers : médaillons détecteurs de chutes, ouvertures de portes, température, etc.
Intervox a confié à Atol la mise en place d’un middleware dont le but est de fluidifier la communication entre la solution technique de gestion des transmetteurs et les applications fonctionnelles ouvertes. Ainsi, le middleware se charge de l’organisation et du retraitement de la masse des flux de données (ETL, ESB) et de présenter l’information avec une vision de plus haut niveau via une API HTTP REST sécurisée.

# Composants intégrés

La solution mise en place s’appuie sur les composants suivants :

API Web services RESTful Jax-RS

• Java 8
• Jetty 9 en mode embarqué
• Implémentation RESTEasy de Jax-RS
• Swagger 2.0 pour spécifier et documenter l’API, mettre à disposition un client de tests graphique et générer des stubs clients

Gestion de données :

• HikariCP : gestion d’un pool de connexions
• Flyway pour gérer l’application automatique des patches
• Jooq pour le requêtage
• JTA pour la gestion des transactions

Sérialisation / Désérialisation :

• Jackson 2 (json)

Tests, contrôles, qualité de l’API :

• async-http-servlet-3.0 : gestion de traitements asynchrones des requêtes
• resteasy-validator-provider-11, validation-api, hibernate-validator : annotations de contrôle des erreurs (@NotNull, etc.)
• Jsr-305 et immutables 2 (org.immutables – value)
• slf4j pour la journalisation (avec loggers asynchrones)
• junit pour les tests unitaires bouchonnés avec mockito-all

Configuration de l’application (gestion paramètres, configuration, injection dépendance) :

• Args4j pour parser la ligne de commande (lancement du serveur)
• TypeSafe Config pour la gestion de la configuration de l’application (configuration par défaut et surcharges via la ligne de commande par exemple)
• Guice pour l’injection de dépendances (gestion via des factories, facilite les tests unitaires)

Synchronisation / Intégration :

• Pentaho Data Integration
• Mule ESB

Authentification :

• Traitée en amont via utilisation de certificats clé publique / clé privée

Compilation / Développement :

• Maven 3
• IDE libre (éditeur de texte, Eclipse, IntelliJ IDEA, etc.)

Documentation :

• AsciiDoc / Markdown
• Eclipse Papyrus
• SQL Power Architect CE

# Vue d’ensemble de la plateforme

Le diagramme suivant fournit un aperçu de la plateforme et des flux en jeu :

# Communications des transmetteurs (existant)

La partie gauche du diagramme concerne la solution initialement mise en place par Intervox. Cette dernière qui est orientée informatique industrielle, permet au serveur de réception de remonter des informations techniques comme des journaux d’événements, le suivi d’activité des périphériques (capteurs de température, ouvertures de porte, etc.) ou encore de mettre à jour le logiciel embarqué d’un transmetteur. La mise en œuvre des communications avec les téléassistants passent également par ce biais. Cette plateforme éprouvée n’a pas été modifiée.

# Portail et applications mobiles

Les diagramme sont présentés dans la partie basse du diagramme : un portail web, des applications mobiles et d’autres systèmes externes. Ils ont été réalisés en même temps que l’API. Exemple de portail, réalisé par Pixine :

Portail qui s’appuie sur l’API mise en place

# API Mise en place

L’API a été créée avec un double objectif :

• Faciliter la mise en place du portail web et des applications mobiles par les équipes dédiées afin que ces dernières mettent l’accent sur les fonctionnalités et l’ergonomie
• Permettre l’accès aux données directement aux clients d’Intervox

# L’API développée

# API et client swagger

L’API a été réalisée avec les solutions citées précédemment. Intégrée à l’API, une interface de type Swagger permet de cataloguer les services disponibles, de les décrire et de les utiliser simplement à partir d’écrans de saisie :

L’interface expose la liste des services regroupés. Pour chaque web service exposé, une interface permet de faire appel au web service en renseignant les paramètres suggérés et en exécutant la requête. La requête cURL équivalente est fournie si bien que rejouer cette requête dans un script shell reste trivial (automatisation). La capture suivante montre un exemple de requête et le résultat obtenu après avoir renseigné un identifiant et cliqué sur « Try it out ! » :

# Simplicité de déploiement

Atol C&D héberge un dépôt de paquets alimenté automatiquement en bout de chaîne de compilation. Sur le serveur applicatif, l’installation pure de l’API et sa mise à jour restent simples. J’en veux pour preuve la commande système qui permet de l’installer :

yum install apiws-1.0

Ou celle qui permet de la mettre à jour :

yum update apiws-1.0

# Intégration de données

De manière à accélérer les temps de réponse de l’API et pour découpler l’API et la solution technique de réception, un nouveau modèle de données a été défini.
La gestion des flux a été conçue pour s’adapter aux besoins de chaque type de flux. Ainsi, plusieurs mécanismes de propagation des données ont été mis en œuvre avec un rythme adapté au volume en jeu et à la « fraîcheur » attendue :

# Le suivi d’activité

• Il s’agit des informations remontées par les capteurs (température, ouverture de portes, etc.) : la vitesse est privilégiée
  les web services de l’API sont consommés directement
• Disponibilité de l’ordre de la seconde

# Transmetteurs, périphériques et demandes de modifications (transactions)

• Lorsque les transmetteurs se connectent pour récupérer une nouvelle configuration (numéros à appeler en cas de chute, etc.), le nouvel état est transmis à l’API. A l’inverse, lorsqu’une demande de modification est enregistrée via le portail ou l’application mobile, une transaction est créée.
• Un ESB est utilisé pour propager l’information de manière asynchrone et « au fil de l’eau »
• Disponibilité de l’ordre de la minute

# Les journaux d’événements

• Les journaux constituent une trace séquentielle des événements techniques qui ont eu lieu au niveau du transmetteur : les communications, les déclenchements, etc.
• Un ETL est utilisé pour propager l’information de manière asynchrone et par lots
• Disponibilité de l’ordre de l’heure

La mise en œuvre de l’ESB pour la propagation des données fera l’objet d’un nouveau billet.