Fonctionnement du rejeu :
1 - l'utilisateur coche les files à rejouer
2 - il clique sur 'rejouer'
3 - le service "dépile" les messages de la pile de refus. Pour chaque message, il :
a - récupère les dernières données en date
pour un delete, faire un get AMAR avec l'IdNat => si 404, jeter le message
pour un update, faire un get PS_API avec => si 404, jeter le message
b - ajouter les données refraichies à l'extract JSON en cours (une liste JSON) pour la file, nommé <operation>.json (ex : create.json)
c - ré-empiler le message dans la file normale correspondante /!\ c'est à ce moment qu'on
4 - une fois tous les messages "réempilés", le système archive ensemble les extracts générés (en fonction de la sélection il peut y en avoir 1,2 ou 3) dans un zip nommé sur le pattern : rejeu<YYYY-MM-DD_HH-mm-ss>.zip
5 - le système trie les fichier par ordre de nom décroissant efface les fichiers à partir de la sixième position
6 - le système envoie un e-mail avec le sujet :Rejeu des queues de refus et le texte :
<nb msg> messages ont été réinjectés.
Pour les télécharger cliquer sur Ce lien
Fonctionnement du rejeu : 1 - l'utilisateur coche les files à rejouer 2 - il clique sur 'rejouer' 3 - le service "dépile" les messages de la pile de refus. Pour chaque message, il : a - récupère les dernières données en date
<operation>.json
(ex :create.json
) c - ré-empiler le message dans la file normale correspondante /!\ c'est à ce moment qu'on 4 - une fois tous les messages "réempilés", le système archive ensemble les extracts générés (en fonction de la sélection il peut y en avoir 1,2 ou 3) dans un zip nommé sur le pattern :rejeu<YYYY-MM-DD_HH-mm-ss>.zip
5 - le système trie les fichier par ordre de nom décroissant efface les fichiers à partir de la sixième position 6 - le système envoie un e-mail avec le sujet :Rejeu des queues de refus et le texte :