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.