ESUPSGC

Arborescence des pages

Cf la FAQ à ce propos, 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 : contrôle d'accès, crous/izly, ...

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

Vis-à-vis de sa propre base de données

esup-sgc synchronise l'ensemble des informations d'un utilisateur qui a une carte sauf si une des conditions suivantes est rencontrée :

  • esup-sgc ne détecte rien à synchroniser (tous les champs remontés sont "égaux" aux champs en base)
  • le champ synchronize a été positionné à false - cf Configurations ESUP-SGC et ESUP-NFC-TAG-SERVER
  • la propriété caducIfEmpty est utilisé et le champ utilisateur référencé par caducIfEmpty est vide -> les cartes sont rendues caduques sans synchronisation
  • les dates de fin en base et remontées sont antérieures à la date du jour

Vis-à-vis du 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 lien d'activation IZLY)

Depuis la version 3.0.0 d'esup-sgc, la page "Erreurs CROUS" remonte le npmbre d'occurrence (essais) où une requête sur l'API a eu lieu et a provoqué la même erreur en boucle : ces appels systématiques correspondent ainsi à des appels excessifs qu'il faut tenter de résoudre, à la fois pour : 

  • permettre à l'usager de bénéficier au mieux su service CROUS via sa carte
  • ne pas surcharger l'API CROUS

Suivant les cas, si une adaptation/correction du SI (champs utilisateurs) ne suffit pas, on pourra rééditer une carte ou encore simplement désactiver l'option CROUS si l'usager n'en a pas l'utilité - voir la page Erreurs CROUS

Synchronisations excessives

Malgré 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 : 

[INFO ] 23/06/2025 04:34:19 o.e.s.s.s.ResynchronisationService (ResynchronisationService.java:63)  - Sync users ok - StopWatch '': running time = 37 min 7 sec 063 ms - nb updated (needed) \
: 205 - nb no updated (no need) : 82859 - errors : 6

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

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

Il faut arriver à les repérer pour les corriger.

Pour ce faire, on peut sur le SGC :

  • passer les logs à DEBUG pour org.esupportail.sgc dans logback.xml si ce n'est pas déjà le cas

  • identifier un utilisateur qui est dans la liste des utilisateurs synchronisés à chaque fois : via les logs on peut les repérer assez facilement : 

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

On peut aussi trouver des logs similaires issus de ResynchronisationUserService : 

[INFO ] 23/06/2025 04:00:24 o.e.s.s.s.ResynchronisationUserService (ResynchronisationUserService.java:183)  - Synchronize of user toto@example.org is needed : [birthday, dueDate, address, cnousReferenceStatut, eduPersonPrimaryAffiliation, email, firstname, indice, name, recto2, recto3, recto7, rneEtablissement, secondaryId, verso1, verso2, verso3, verso5, idRate] is/are not synchronized.
Enfin, depuis la version 3.0.0 d'esup-sgc, on peut retrouver pour chaque utilisateur la raison de la resynchronisation directement dans l'interface web. Sont donnés au même niveau la date de mise à jour qui a nécessité une resynchronisation ainsi que le nombre de resynchronisations successives. Ce dernier élément, que l'on peut retrouver dans la tableau des utilisateurs dans la vue 'manager' et sur lequel on peut trier (depuis un grand écran, dézommer si nécessaire dans le navigateur), permet d'identifier les utilisateurs liés à des resynchronisations systématiques et donc exessives.

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


  • Aucune étiquette