Esup-SGC resynchronise régulièrement les données utilisateurs avec sa base de données.
Il récupère les données puis calcule si il doit ou non effectivement lancer la resynchronisation
- vis à vis de sa propre base de données
- mais aussi vis à vis des systèmes externes : controle d'accès, crous/izly, ...
Pour la synchronisation avec le crous/izly, avant de renvoyer des mises à jour de données (qui peuvent de plus provoquer un envoi de mail de la part d'Izly*), ESUP-SGC fait encore un calcul pour déterminer si un update (PUT) est véritablement nécessaire : pour ce faire il récupère par l'API (GET) les données de l'ayant droit IZLY (RightHolder) et les compare avec ce qu'il est censé envoyer (un calcul spécifique est également fait sut la date de fin de compte).
(* IZLY renvoie un mail à l'utilisateur lors d'un update / pu / mise à jour de ses données d'ayant droit (RightHolder) si celui-ci n'a pas activé/validé son compte : ce mail permet ainsi de renvoyer le lei nd'activation IZLY)
ESUP-SGC tente donc finalement de synchroniser les données que si nécessaire ...
Synchronisations excessives
Malgré celà, on a déjà pu constater des synchronisations 'abusives' ou 'excessives' ...
Celà vient principalement d'un problème de calcul entre des attributs qui sont null d'un côté et vides de l'autre.
Il faut arriver à les repérer pour les corriger.
Pour ce faire, on peut sur le SGC :
- désactiver la synchro auto totale toutes les 6 heures via le fichier applicationTasksContext.xml
- passer les logs à TRACE pour org.esupportail.sgc dans logback.xml
- identfier un utilisateur qui est dans la liste des utilisateurs synchronisés à chaque fois : via les logs on peut les repérer assez facilement :
[synchronize of user toto@univ-ville.fr was needed : done] - déclencher manuellement une synchro dessus,
- en regardant les logs on peut voir quel champ est considéré comme modifié depuis la dernière synchronisation et provoque cette resynchronisation.
Une fois repéré le champ, il faut arriver à voir et corriger ce qui est remonté : le champ en question n'est peut-être plus remonté depuis le SI par exemple (alors qu'il l'était avant) et il est vide dans la base : on peut alors forcer à le mettre à null dans la base ou encore faire en sorte qu'il remonte à nouveau depuis le SI ....