Contexte
Pour lisser les synchronisations auprès des établissements, et éviter de synchroniser toujours à la même heure, nous avons un calcul pour le délais entre les différentes tentatives de synchronisations.
Le calcul
Ce calcul varie selon l'état de la connexion.
La connexion n'est pas en bloquée :
Le calcul du délai de synchronisation dépend de plusieurs paramètres :
La fréquence de synchronisation est déterminée par la valeur du champ 'sync_frequency' du connecteur associé.
Cette information disponible en appelant le endpoint Connectors.
Si le paramètre 'sync_frequency' n'est pas renseigné pour le connecteur, nous utilisons la valeur renseignée dans la clé de configuration autosync.frequency
Un nombre d'heures est ajouté de façon aléatoire afin de ne pas lancer toutes les synchronisations au même moment.
La dernière synchronisation a échoué :
La date de prochaine tentative est indiquée dans le champs next_try de l'objet connection.
Dans le cas où le statut de connexion vaut 'additionalInformationNeeded' ou un autre statut équivalent (cf. https://docs.budget-insight.com/guides/handle-scas-connection-states), le champ 'next_try' reste à null. La synchronisation ne se fera pas tant que l'utilisateur n'aura pas fourni l'information supplémentaire.
Dans le cas où le statut vaut 'wrongpass', si c'est le premier statut de ce type d'affilé, une nouvelle tentative est prévue 12 heures plus tard. À partir de 2 'wrongpass' consécutifs, si la clé de configuration 'autosync.retry_wrongpass' vaut 1, une nouvelle tentative sera prévue 7 jours plus tard. Si la clé de configuration vaut 0, il n'y aura pas de tentative tant que l'utilisateur n'aura pas changé son mot de passe.
S'il s'agit d'un autre statut, et que la synchronisation précédente était un succès, alors une nouvelle tentative est prévue 2 heures plus tard.Si ce n'est pas le premier blocage, une nouvelle tentative sera faite entre 2 heures et 5 jours plus tard.
En savoir plus
La Faq
La documentation de référence
Les guides