Créer des batchs avec JAVABATCH – JSR352

Je suis actuellement en train de tester la JSR 352 ( ou JAVA BATCH). Cette API est une des nouveautés de la spécification JAVA EE 7.  Elle permet ( entre autres ) de lancer des BATCHS depuis un serveur JEE.

the-evolution-of-java-ee-7_5252edf90af4c_w1500

 

Mais vous allez me dire : il y a SPRING BATCH ! Oui, JAVA BATCH est une standardisation de JAVA BATCH avec l’ intégration du moteur dans un serveur JEE. D’ailleurs, SPRING BATCH est désormais compatible avec cette API.

Ce dernier offre la possibilité de contrôler l’état des jobs à travers l’outil d’administration du serveur via le JOB REPOSITORY.

jsr352-schematic

Pour ceux qui connaissent SPRING BATCH et le monde chatoyant des ETL, le concept de la JSR 352 sera assez simple à appréhender :

Un batch est spécifié avec un job qui a plusieurs steps qui sont découpés en étapes de lecture, de transformation et de chargement (ETL).

Avantages

Les principaux avantages à faire tourner les batchs dans un contexte JEE ( si si il y en a ) sont les suivants :

  • On peut utiliser l’outillage du serveur pour monitorer les jobs
  • On dispose de toute la stack JEE (CDI, JPA, JTA,JAX-RS,…) pour développer des batchs
  • Un batch peut être déclenché de plusieurs manières (script, service REST,…)
  • Par rapport aux solutions ETL du marché, on peut avoir des tests unitaires, de la qualimétrie de code avec SONARQUBE,…

Inconvénients

C’est une V1. Il y a encore des choses à améliorer ( gestion des properties par ex)

Définition d’un job

Le job se définit par un fichier XML

Les références des différents élements font appel aux références des beans CDI développés. Dans mon exemple, je n’ai pas utilisé de processor car je ne devais pas transformer les données. J’ai cependant eu besoin de séparer les différents traitements en les parallélisant dans des partitions. Pour déterminer les données de chaque partition, j’ai utilisé un mapper.

Le reader

On voir dans l’exemple que l’injection se fait par CDI. Il faut spécifier le scope Dependent pour que les beans soient accessibles dans le contexte BATCH.

La récupération des données se fait via la méthode open(). Logiquement , on doit récupérer toutes les données à ce moment. Ca peut être problématique avec des très grosses volumétries . Dans ce cas on pourra privilégier le lazy loading.

La lecture de chaque item (ex. une ligne ) se fait dans la méthode readItem().  L’une des choses que je trouve un peu dommage dans l’API BATCH est le manque de générique. En effet, ça aurait été un peu plus « sympa » d’avoir une classe AstractItemReader<T> qui paramètre la méthode readItem().

Le writer

De la même manière on spécifie le writer

Sur l’utilisation de la méthode writeItems(), j’ai la même remarque que pour la méthode readItem() . Un peu de générique, ça n’aurait pas été du luxe….

Le mapper

La propriété « PROP » définie dans le fichier XML et utilisée dans le reader est définie pour chaque partition. Les différentes partitions sont stockées dans un partitionPlan.

Démarrage du batch

Le batch peut se démarrer  de la manière suivante

Ce code peut être appelé depuis une servlet, un service REST …..

Monitoring

Pour suivre l’exécution du batch on peut utiliser les outils du serveur d’applications. Sous glassfish on peut utiliser la commande asadmin.

On peut également utiliser les beans JMX pour monitorer les jobs.

Conclusion

La stack JSR 352 est assez simple à utiliser. Elle est certes perfectible ( absence de générique, gestion des propriétés assez compliquée de prime abord) mais fait le boulot.

Par rapport aux autres solutions (spring batch) elle permet la supervision des batchs via les outils du serveur d’application et peut facilement s’intégrer dans une application JAVAEE.

Intégrer la base adresse nationale dans Elasticsearch

L’état fourni désormais via sa plateforme OPENDATA son référentiel des adresses du territoire français.

Si vous souhaitez avoir plus d’informations sur la démarche OPENDATA, vous pouvez consulter cette page.

Cette base est issue des données de l’IGN, de la poste, des collectivités territoriales ou encore de la communauté openstreetmap.

Chaque adresse contient le nom normalisé ainsi que les coordonnées .

Voici le descriptif des données.

Les cas d’utilisation de ces données sont nombreux. L’un deux pourrait être de les utiliser dans les recherches d’adresses. Il faudrait charger ses données dans un moteur de recherche (ELASTICSEARCH par ex.)  et de rechercher la présence d’une adresse avec pondération selon plusieurs critères ( avec filtres, recherches complexes ) et d’obtenir l’adresse normalisée et les coordonnées géographiques .

Je vais essayer de décrire les actions que j’ai réalisé pour intégrer ces données.

Architecture mise en œuvre

Présentation1

Les fichiers CSV sont placés dans un répertoire. L’archive téléchargeable contient un fichier CSV par département.

LOGSTASH joue ici pleinement le rôle d’un ETL.

Configuration LOGSTASH

La configuration est assez simple. Il suffit de savoir configurer le plugin CSV de LOGSTASH.

 ELASTICSEARCH

Le mapping généré par LOGSTASH est assez basique mais permet déjà de réaliser pas mal de requêtes. On peut également brancher KIBANA pour analyser plus finement les données.

Voici un exemple de recherche que l’on peut exécuter :

J’essaierai dans un prochain article e brancher kibana sur cet index pour avoir plus de stats.