Les slides de cette très bonne introduction sont disponibles ici.
Pour ma part, voici ce que je retiens de cette présentation :
Qu’entend t-on lorsque l’on parle de batch ?
On parle ici de “Batch processing”, dont la traduction française est
“Traitement par lot”.
Il s’agit d’un enchaînement automatique de commandes ne nécessitant pas l’intervention d’un opérateur. Ces traitements peuvent réaliser des opérations métier sur de gros volumes de données.
Un exemple courant de batch est l’import d’un référentiel de données XML dans une base de données relationnelle.
L’accent a été porté par les intervenants sur le fait qu’il ne faut pas confondre batch avec scheduler. En effet, un scheduler (Cron, Quartz) n’est qu’un outil permettant de lancer un batch.
Il s’agit d’un enchaînement automatique de commandes ne nécessitant pas l’intervention d’un opérateur. Ces traitements peuvent réaliser des opérations métier sur de gros volumes de données.
Un exemple courant de batch est l’import d’un référentiel de données XML dans une base de données relationnelle.
L’accent a été porté par les intervenants sur le fait qu’il ne faut pas confondre batch avec scheduler. En effet, un scheduler (Cron, Quartz) n’est qu’un outil permettant de lancer un batch.
Les frameworks disponibles pour la réalisation de batchs ?
La réalisation d’applications WEB ou encore la gestion de la persistance
en Java sont des tâches couvertes par de nombreux frameworks.
Par contre, lorsque l’on s’attaque à la réalisation d’un batch, on peut parfois se sentir démuni de tout outil, pourtant Spring Batch est là.
Bien entendu, il ne répond pas forcément à tous les cas d’utilisation mais en faire un petit tour d’horizon peut aider à prendre une décision la prochaine fois que la réalisation d’un batch s’impose.
Par contre, lorsque l’on s’attaque à la réalisation d’un batch, on peut parfois se sentir démuni de tout outil, pourtant Spring Batch est là.
Bien entendu, il ne répond pas forcément à tous les cas d’utilisation mais en faire un petit tour d’horizon peut aider à prendre une décision la prochaine fois que la réalisation d’un batch s’impose.
A quoi ressemble un batch classique ?
Les batchs réalisés sans outils spécifiques présentent habituellement un
certain nombre de problèmes.
Ils consistent souvent en un bloc monolithique de code, ils sont de ce fait difficilement maintenables.
La réutilisation de code d’un batch à l’autre n’est pas une tâche aisée et l’on est souvent amené à réinventer la roue pour réaliser des fonctionnalités très semblables (lecture d’un fichier XML, écriture dans une base de données, ...).
Il est nécessaire de connaître la volumétrie avant le développement, de manière à découper en lots appropriés les traitements.
Il est difficile de faire évoluer un batch qui était initialement prévu pour traiter un fichier de 10ko pour qu’il traite à l’avenir des fichiers de 100mo.
La gestion des transactions et des rejets est laissée à la charge du développeur.
Ils consistent souvent en un bloc monolithique de code, ils sont de ce fait difficilement maintenables.
La réutilisation de code d’un batch à l’autre n’est pas une tâche aisée et l’on est souvent amené à réinventer la roue pour réaliser des fonctionnalités très semblables (lecture d’un fichier XML, écriture dans une base de données, ...).
Il est nécessaire de connaître la volumétrie avant le développement, de manière à découper en lots appropriés les traitements.
Il est difficile de faire évoluer un batch qui était initialement prévu pour traiter un fichier de 10ko pour qu’il traite à l’avenir des fichiers de 100mo.
La gestion des transactions et des rejets est laissée à la charge du développeur.
Quelle est la réponse de Spring Batch ?
Spring Batch répond de manière plutôt efficace à ces différentes
problématiques, il propose un cadre de développement et de
conception.
Il instaure un vocabulaire commun d’un batch à l’autre.
Il permet de répartir les traitements par lots et cela sur de gros volumes sans que les développements spécifiques ne soient impactés.
Ce framework intègre la gestion des transactions et un processus de commit régulier.
Bien entendu, l’intégration de Spring dans le batch est native. Au-delà de ces différents aspects de base, Spring Batch propose des fonctionnalités “avancées” permettant de répondre à des besoins plus spécifiques parmi lesquels :
Il instaure un vocabulaire commun d’un batch à l’autre.
Il permet de répartir les traitements par lots et cela sur de gros volumes sans que les développements spécifiques ne soient impactés.
Ce framework intègre la gestion des transactions et un processus de commit régulier.
Bien entendu, l’intégration de Spring dans le batch est native. Au-delà de ces différents aspects de base, Spring Batch propose des fonctionnalités “avancées” permettant de répondre à des besoins plus spécifiques parmi lesquels :
- Le partitionnement
- Le parallélisme
- La reprise sur erreur
Comment s’organise un batch Spring Batch ?
Dans la terminologie Spring Batch, un batch est un Job,
ce dernier peut être constitué de plusieurs étapes :
Step.
Une étape met en oeuvre un ItemReader, un ItemWriter et peut également faire appel à un ItemProcessor.
Ces trois éléments sont des interfaces, voici la vocation de chacune :
Le traitement des données dans une Step s’effectue par lots (Chunk) successifs. La gestion d’un lot s’effectue de la manière suivante : n items d’entrée sont lus successivement puis transformés en vue d’être écrits.
La taille des lots est définie par le commit-interval. Lorsque le nombre d’items lus atteint cette limite, les items sont écrits par l’ItemWritter et la transaction est “commitée”.
Dans la documentation Spring Batch, le schéma ci-dessus est représenté de la manière suivante en code :
Il est possible d’éxécuter un batch en ligne de commande et de lui passer ses paramètres en utilisant le CommandLineJobRunner.
Il a mis l’accent sur le fait qu’il y avait moins de code à écrire, cet élément couplé au fait que les batch réalisés avec Spring Batch sont fortement testables, les erreurs possibles sont moindres.
Un point important est le fait qu’il est plus facile à deux développeurs de batchs de communiquer grâce au vocabulaire porté par Spring Batch.
La délégation de la gestion des transactions à Spring Batch est un point appréciable.
Sur le plan concret les chiffres suivants ont été évoqués :
Une étape met en oeuvre un ItemReader, un ItemWriter et peut également faire appel à un ItemProcessor.
Ces trois éléments sont des interfaces, voici la vocation de chacune :
ItemReader : Comme son nom l’indique, cette interface est
chargée de lire un item à traiter dans une étape. Il en existe un bon nombre
d’implémentations, telles que la lecture de fichier plat, la lecture en base
via JDBC, Hibernate, ...
ItemProcessor : Il peut être utilisé pour réaliser des
transformations, validations ou encore filtrages sur les éléments traités dans
l’étape. Il transforme un élément et en retourne un autre, c’est le bon endroit
pour indiquer des règles métier.
ItemWriter : Encore une fois, il porte plutôt bien son
nom, l’ItemWriter va se charger d’écrire les éléments de sortie. Comme pour
l’ItemReader, diverses implémentations sont fournies.
Le traitement des données dans une Step s’effectue par lots (Chunk) successifs. La gestion d’un lot s’effectue de la manière suivante : n items d’entrée sont lus successivement puis transformés en vue d’être écrits.
La taille des lots est définie par le commit-interval. Lorsque le nombre d’items lus atteint cette limite, les items sont écrits par l’ItemWritter et la transaction est “commitée”.
Dans la documentation Spring Batch, le schéma ci-dessus est représenté de la manière suivante en code :
List items = new Arraylist();
for(int i = 0; i < commitInterval; i++){
items.add(itemReader.read());
}
itemWriter.write(items);
Pour une Step donnée, il est possible de définir des listeners à l’écoute
des différents évènements de celle-ci. Ainsi, combiné à un writer, un listener
peut permettre de renseigner un fichier de rejet.
Il est possible d’éxécuter un batch en ligne de commande et de lui passer ses paramètres en utilisant le CommandLineJobRunner.
Les tests :
Du fait du cadre proposé par Spring Batch, l’écriture de tests unitaires est relativement aisée. Il est ainsi possible de tester unitairement les différents composants de votre réalisation intervenant dans l'exécution du batch (itemReaders, itemProcessors, ...).
De même, il est tout à fait possible d’écrire des tests d’intégration.
Retour d’expérience des intervenants :
Olivier Bazoud nous a présenté son constat vis à vis de l’utilisation de Spring Batch en entreprise.Il a mis l’accent sur le fait qu’il y avait moins de code à écrire, cet élément couplé au fait que les batch réalisés avec Spring Batch sont fortement testables, les erreurs possibles sont moindres.
Un point important est le fait qu’il est plus facile à deux développeurs de batchs de communiquer grâce au vocabulaire porté par Spring Batch.
La délégation de la gestion des transactions à Spring Batch est un point appréciable.
Sur le plan concret les chiffres suivants ont été évoqués :
- 15% à 50% de gain sur le temps de développement
- 15% à 50% de gain sur le temps d'exécution des batchs
Conclusion :
Spring Batch est un outil fiable et qui présente de bon patterns, il
présente l’avantage de faciliter la testabilité et la maintenabilité des batchs
réalisés ce qui n’est pas toujours une tâche évidente lorsque l’on réalise un
batch sans outil spécifique.
De nombreuses fonctionnalités avancées sont intégrées à l’outil et peuvent être mises en place à moindre coût.
Bien que la productivité soit meilleure à termes, il faut toutefois être conscient que le coût initial est important.
Les intervenants ont évoqué la possibilité d’intervenir une prochaine fois sur les notions plus avancées de Spring Batch telles que le partitionning, le parallélisme, le remoting, la reprise sur erreur ou encore Spring Batch Admin
Liens :
La présentation
Le code qui a servi de support à la présentation
Documentation officielle Spring Batch
Le Spring User Group
La prochaine session du Spring User Group est prévue le 10 juin sur les styles d’injections de dépendances de Spring. Cette session sera animée par Chris Beams (ingénieur Spring Source).
De nombreuses fonctionnalités avancées sont intégrées à l’outil et peuvent être mises en place à moindre coût.
Bien que la productivité soit meilleure à termes, il faut toutefois être conscient que le coût initial est important.
Les intervenants ont évoqué la possibilité d’intervenir une prochaine fois sur les notions plus avancées de Spring Batch telles que le partitionning, le parallélisme, le remoting, la reprise sur erreur ou encore Spring Batch Admin
Liens :
La présentation
Le code qui a servi de support à la présentation
Documentation officielle Spring Batch
Le Spring User Group
La prochaine session du Spring User Group est prévue le 10 juin sur les styles d’injections de dépendances de Spring. Cette session sera animée par Chris Beams (ingénieur Spring Source).
