03 ‐ Architecture de Spring Batch
Voici l'architecture type d'une application Spring Batch, avec un Job qui possède des étapes de traitement en chunk :
Pour que le Job puisse être exécuté, il faut avoir un déclencheur pour lancer le JobLauncher, on suppose qu'ici, il s'agit d'un scheduler
L'exécution d'un Job est a ses métadonnées inscrites en base de données via le JobRepository
Il s'agit d'une classe qui représente l'exécution logique / théorique (ou "souhaité") d'un Job qui contient les informations suivantes :
-
Le Job
-
Des paramètres (comme la date d'exécution dans le cas d'une planification)
À chaque exécution par le scheduler, une instance de JobInstance sera créé.
Il s'agit d'une instance représentant l'exécution réelle du Job, il a pour responsabilité de représenter la tentative d'exécution.
Supposons qu'un Job doit se lancer le 1 décembre :
- Une instance JobInstance sera créé, avec les informations du Job, et de la date d'exécution
- Une instance JobExecution* sera créé
- En cas d'échec de l'exécution, une nouvelle instance de JobExecution sera créée, on ne touche pas à JobInstance, car il représente l'exécution LOGIQUE / THÉORIQUE / D'UN CAS NOMINAL
StepExecution est une instance qui représente l'exécution d'une étape.
Dans un cas nominal, le nombre d'instances de StepExecution sera égal au nombre de Steps configurés (sauf en cas d'échec bien sûr).
À chaque étape de flux d'exécution, les métadonnées seront mis à jour dans la base de données.
Toute exécution doit être sauvegardée quelque part.
JobRepository est le mécanisme de persistence, il fournit des opérations CRUD pour :
- Le JobLauncher
- Le Job
- La Step
En utilisant l'annotation @EnableBatchProcessing, ce repository est automatiquement configuré.