L’idée part d’un besoin simple : lancer un job Quartz toutes les heures ouvrées, hors week-end et jours fériés.
Pas très compliqué, mais il y a quelques trucs à savoir, notamment sur l’enchainement des calendriers.
Les jours fériés
Il existe différents algorithmes pour calculer les jours fériés et ils sont moyennement compliqués. Mais il faut quand même un calendrier pour tester l’algo. Et bien sûr, si le client veut exclure un jour férié (pourquoi pas ?), il faudra maintenir une liste des jours exclus.
La méthode retenue : mettre en dur les jours fériés pour les 20 prochaines années ! Si l’application survit jusque là, ça sera une sacré prouesse.
La liste des jours fériés est “hardcodées” dans un fichier de conf du projet. Ce fichier est lu par la conf Spring à l’aide d’un PropertyPlaceHolderConfigurer.
Cela donne quelque chose comme ça pour 2008 :
1
| |
Configuration Spring
Au total, il y aura trois calendriers :
- Un qui exclut les week-ends (fourni avec Quartz) ;
- Un qui exclut une plage horaire (fourni avec Quartz) ;
- Un “fait-maison” qui exclut une plage de dates fournie en paramètre.
Ces calendriers sont configurés pour être enchainés les uns aux autres. Techniquement, chaque calendrier se voit injecter dans son constructeur un autre calendrier. Ainsi chacun demande à son suivant si la date actuelle doit être exclue ou non. C’est une fonctionnalité de base des calendriers Quartz.
Dans la config Spring, cela donne :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | |
Le calendrier “multi-dates”
Cette classe est un calendrier au sens Quartz. Il exclut une liste de dates passées en paramètre sous la forme d’une String, comme celle spécifiée plus haut (ie. 2008-01-01,2008-03-21).
Il est utilisé dans la config Spring pour exclure les jours fériés.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 | |