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.
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, 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 ....