Arborescence des pages

Comparaison des versions

Légende

  • Ces lignes ont été ajoutées. Ce mot a été ajouté.
  • Ces lignes ont été supprimées. Ce mot a été supprimé.
  • La mise en forme a été modifiée.

Cf la FAQ à ce propos, Esup-SGC resynchronise régulièrement les données utilisateurs avec sa base de données.

...

  • vis à vis de sa propre base de données
  • mais aussi vis à vis des systèmes externes : controle contrôle 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 / put / 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 ndlien d'activation IZLY)

ESUP-SGC tente donc finalement de synchroniser les données que si nécessaire ...

Synchronisations excessives

Malgré celàcela, on a déjà pu constater des synchronisations 'abusives' ou 'excessives' ...

En log info, on peut retrouver le nombre de synchronisations réalisées : 

Bloc de code
languagetext
themeRDark
[INFO ] 25/02/2020 13:53:54 o.e.s.s.s.ResynchronisationService (ResynchronisationService.java:62)  - Sync users in 3709.102sec - nb updated (needed) : 59 - nb no updated (no need) : 63797 - errors : 3

Le 'nb updated (needed)' avec des informations issues du Système d'Information, devrait être usuellement très faible.

Si il est élevé à chaque synhronisationsynchronisation, celà cela vient principalement d'un problème de calcul où des attributs qui étaient intitalement initialement renseignés ne le sont plus.

...

  • passer les logs à DEBUG pour org.esupportail.sgc dans logback.xml si ce n'est pas déjà le cas
  • identfier identifier un utilisateur qui est dans la liste des utilisateurs synchronisés à chaque fois : via les logs on peut les repérer assez facilement : 

    Bloc de code
    languagetext
    themeRDark
    [DEBUG] 25/02/2020 13:52:13 org.esupportail.sgc.domain.User (User.java:389)  - Users [toto@univ-ville.fr] not synchronized because indice is not synchronized : 0 <> 441

    Dans le cas ci-dessus, l'indice n'est plus remonté ...

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

Jouer avec le champ utilisateur "synchronize" peut permettre également de ne pas lancer le processus de synchronisation sur des comptes utilisateurs anciens qui ne sont plus présents dans le SI : voir le tableau des UserInfo présentant ce champs spécial 'synchronize".