-
Notifications
You must be signed in to change notification settings - Fork 0
02 ‐ Introduction à Spring Batch
Spring Batch est :
-
Un framework open-source léger pour concevoir des applications batch en Java
-
Il a été conçu à partir du Framework Spring, et donc fonctionne à partir de la JVM

-
Il permet de faciliter l'écriture d'applications Batch
-
Il fournit des solutions à des problèmes que l'on peut rencontrer en écrivant des applications batch à la main
Spring Batch n'est PAS : un framework de planification
-
Gestionnaire d'état : ce qui permet de récupérer l'état d'un Job
-
Gestion des erreurs, si un Job a échoué dans son exécution :
- Skip : passer le Job qui n'a pas fonctionné
- Restart : redémarrer l'endroit du job qui a échoué
- Retry : redémarrer tout le Job en précisant le nombre de fois
-
Sacabilité : Spring Batch fournit plusieurs options pour faire de la scalabilité, que ce soit dans une seule ou multiple JVMs.
-
Lecteurs et auteurs (Readers and Writers) :
-
Spring Batch fournit déjà des Readers et Writers pour intéragir avec des jeux de données populaires :
- FlatFileItemReader, FlatFileItemWriter : pour les fichiers CSV
- JdbcCursorItemReader, JdbcBatchItemWriter : pour les bases de données relationnelles
- JsonItemReader, JsonFileItemWriter : pour les fichiers JSON
- KafkaItemReader, KafkaItemWriter : pour Kafka
-
Chaque Reader implémente l'interface ItemReader, et chaque Writer implémente l'interface ItemWriter

Il existe une 3ème intereface, ItemProcessor : qui va contenir la logique de traitement.
- Gestion des transactions, utile lorsqu'on écrit dans des bases de données relationnelles (= ACID)
Exemple :
On bénéficie d'un très gros fichier XML, et l'on souhaite le traiter pour ensuite y écrire dans une base de données. Plutôt que de le traiter en une seule fois, on peut demander de faire un traitement par lot / chunk pour veiller à la cohérence des données à l'insertion dans la base.
Si quelque chose se passe mal dans l'écriture d'un chunk, il n'est pas commit, car il s'agit d'une transaction.
-
Un Job représente le flux entier de ce qui sera exécuté dans le processus de batch
-
Un Job peut être composé d'une ou plusieures étapes qui seront exécutés dans l'ordre

-
Une étape est une unité de travail
-
Il représente une phase indépendante dans un job batch, mais peut être lié logiquement avec d'autres étapes.

Une Tasklet est un type d'étape qui permet d'exécuter une seule tâche seulement.
Une tâche de type Tasklet doit implémenter l'interface Tasklet (pour la méthode d'exécution execute())
Des exemples de cas d'utilisation :
- Pour exécuter une simple instruction en base de données (insertion, mise à jour, suppression)
- Envoyer un e-mail
- Préparer des ressources
- Effectuer un nettoyage...
L'exemple de job ci-dessus (générer un rapport de vente), pourrait avoir des Tasklets comme type d'étapes :
- La collecte de données est une Tasklet
- La génération de rapport est une autre Tasklet
- Et enfin, l'envoi d'e-mail est une autre Tasklet
Une tâche en blocs est un type d'étape qui permet de décomposer une tâche en plusieurs blocs : cela est surtout intéressant lorsqu'il faut traiter un gros jeu de données.
Cette tâche possède le concept de Item : il s'agit d'une donnée lue, ou écrite dans une source de données.
Ainsi POUR UNE SEULE de ce type d'étape, on a une implémentation pour :
- ItemReader
- ItemProcessor (optionnel)
- ItemWriter

Chaque implémentation sera invoquée par bloc de donnée.
Voici un exemple :

L'importation des produits va se faire par bloc / lot : pour chaque lot, on aura l'exécution du Reader, du Processor et du Writer.
Différence avec la Tasklet : dans une Tasklet, la lecture, le traitement et l'écriture se ferait en 3 étapes de type Tasklet. Tandis qu'en chunk-based, cela se fait en une seule étape.
Un JobLauncher (ou exécution de Job) permet de démarrer un Job.
Cela peut se faire de différentes manières :
- Via un planificateur / scheduler
- Via un endpoint d'API
- Via des fonctionnalités de SpringBoot (comme une ligne de commande)
Un JobRepository a pour responsabilité de stocker des métadonnées d'un Job en base de données (un peu comme Doctrine en PHP, qui doit inscrire ses migrations en base)