Mail report pour Spring- batch

Informatique
24 juin 2015 par Eric Taix
Pas de commentaires sur cet article

 

Lorsque l’on doit développer des traitements d’intégration de données , l’utilisation du projet Spring-Batch est une des solutions possibles.

Bien que le coût d’entrée ne soit pas gratuit, Spring-Batch permet de donner de la rigueur à votre traitement en vous forçant à respecter les phases de lecture / traitement / écriture, communs à tous les traitements et vous fournit out-of-the-box un squelette prêt à l’emploi.

Les batchs étant des traitements sans interaction utilisateur, la problématique de remontée d’informations sur le résultat d’un traitement devient importante. Dois-je me connecter tous les matins en SSH pour consulter mes logs ou alors me connecter à la base de données pour consulter les tables stockant les informations sur l’exécution des steps et des jobs ?

Sauf si vous n’avez rien de mieux à faire, aucune des solutions mentionnées n’est satisfaisante. Personnellement je veux pouvoir disposer d’un système me permettant de remonter de façon automatique le status des traitements !

Cet article vous propose de réaliser cette remontée à travers l’envoi d’un mail à la fin de l’exécution de vos jobs.

JobExecutionListener à la rescousse

JobExecutionListener est une interface permettant d’intervenir dans le cycle de vie d’un Job.

L’idée est donc de créer une implémentation  JobReporter implémentant cette interface et envoyant un mail en fonction du status final du Job.

La responsabilité du JobReporter se limite à vérifier la concordance du status du Job avec les différents Report que l’on souhaite implémenter. Cela permet de définir :

  • Les status où l’on souhaite avoir un report
  • Le sujet du mail en fonction du status
  • Un template spécifique en fonction du status
  • Un destinataire spécifique par status

Pour un exemple de définition de Report, se reporter à La configuration Spring

La génération du contenu du mail ainsi que l’envoi proprement dit sont délégués respectivement au Templater et au MailService.

Système de template

Pour générer le contenu du mail, c’est Mustache qui a été utilisé mais vous pouvez adapter le fonctionnement à ThymeleafVelocityFreemarker ou tout autre système de templating.

La génération du template est définie au travers de l’interface Templater ce qui permettra de définir les différentes implémentations (Mustache, Thymeleaf, …) dans des projets différents et de linker celle-ci au run-time.

L’implémentation Mustache, est quand à elle sans difficulté particulière.

Un exemple de template

Ceci n’est qu’un exemple pour les Jobs ayant échoué avec Mustache (affichage du Step ayant provoqué l’erreur ainsi que de la stack trace). Reportez-vous à la documentation de Mustache pour plus d’informations.

L’envoi de mail

L’envoi de mail est délégué au MailService. Les propriétés de ce service sont les suivantes :

  1. host : le nom du serveur d’envoi
  2. port : le port du serveur d’envoi
  3. procotol : le protocol à utiliser (« stmp », « smtps », …)
  4. username : le nom de connexion pour l’envoi d’un mail avec un système à authentification
  5. password : le mot de passe du compte de connexion
  6. mailProperties : chaîne définissant les propriétés supplémentaires à utiliser

Arrêtons nous 2 minutes sur la dernière propriété mailProperties. Suivant l’implémentation utilisée à JavaMailAPI, de nombreuses propriétés sont disponibles pour paramétrer la connexion au serveur de mail (cf com.sun.mail.smtp). Malheureusement ces propriétés sont spécifiques à l’implémentation utilisée : il n’est donc pas possible d’avoir toutes ces propriétés définies dans MailService. L’idée de mailProperties est de pouvoir définir ces propriétés spécifiques sous forme de chaîne avec le format suivant <proprety_key1>=<property_value1>:<property_key2>=<property_value2>. Par exemple « mail.smtps.auth=true:mail.debug=false »

La configuration Spring

On notera au passage que les propriétés ne sont pas directement définies dans le fichier de configuration Spring, bien que cela soit possible, mais au travers de l’environnement JNDI. En effet chacun de nos environnements (test, intégration, production) définit ses propres variables d’environnement. Cela permet par exemple de pouvoir utiliser un tag spécifique dans le sujet du mail afin de bien savoir si c’est un batch en production ou en test qui a planté !

Utilisation dans les jobs

Le JobReporter avec ses dépendances est défini, il ne reste donc plus qu’à relier ce dernier avec les Jobs.

Il est possible de définir pour chaque Job un listener. Cependant si votre application définit de nombreux jobs, cela risque d’être du copier/coller et c’est mal !

Afin de pallier à ce problème il est préférable de définir un Job parent dont tous vos Jobs vont « hériter ».

Ainsi tous vos jobs auront le reporting de façon automatique ! Elle est pas belle la vie ?

A noter que le job parent est défini en abstract, sinon Spring provoque une erreur au chargement car aucun step n’est défini !

Le résultat

Voici un extrait du résultat que nous recevons dans nos boites email lorsqu’un job se plante:

 

 

Conclusion

Ce système nous a permis de passer d’un système où l’on est aveugle sur le résultat des tâches de fond à un système permettant, de façon rapide et modulable, de nous avertir d’une erreur tout en gardant de la souplesse et de la configuration en fonction de l’environnement d’exécution.

Si vous avez résolu ce type de problématique d’une autre façon, n’hésitez pas à laisser des commentaires.

Eric Taix Eric Taix
Co-leader of Montpellier Java User Group. Tech adict, I believe in communities, sharing knowledge. #java #android #dartlang lover.
Commentaires
Soyez le premier à réagir sur cet article !

UP