# Implémentation synchro Queen / Pearl [Front]

**Notes liées** :bookmark_tabs: :
- [Stratégie de synchronisation Pearl / Queen](/4z-cCYrtS3SOg0cB19Ut5w)
- [Travaux d'amélioration de la synchro Queen / Pearl](/bov9kNmNScewPDxn7gYe9g)
- [Implémentation synchro Queen / Pearl [Back]](/T0UhEz9wTXia2FQaRiXxJQ)

Cette note explique comment est implementée la synchronisation Pearl/Queen. Elle met l'accent sur la gestion des erreurs.
Cette note est ecrite dans l'ordre dans lequel se passe la synchronisation.

Ces choix d'implémentation résultent de la [discussion autour des pistes d'amélioration de la sychronsiation](/bov9kNmNScewPDxn7gYe9g).

**Remarque 1** : seules les erreurs 403, 404 et 500 sont traitées comme des erreurs non bloquantes. C'est à dire que si une erreur survient et qu'elle n'est ni 403/404 ou 500, la synchronsiation s'arrête (voir détails plus bas).

**Remarque 2** : n'importe quelle erreur qui survient lors d'un POST vers la zone "garage" (requête qui survient lors d'une erreur vers un PUT de sauvegarde) provoque l'interruption de la synchronisation (pour éviter de perdre de la donnée)

**Remarque 3 (évolution possible)** : au lieu de ne traiter "que" les erreurs 403,404 et 500, nous pouvons envisager de traiter une plage d'erreurs (par exemple toutes erreurs ayant pour code http supérieur à 300). Comme tout est déjà en place cette évolution est très peu couteuse.

## Pearl

### HealtCheck
- l'application lance un healthcheck pour vérifier que l'API Pearl-BO répond. (**/api/healthcheck**)
- elle demande à Queen de faire de même avec Qeen-BO.
- En fonction du resultat de ces healthcheck, 2 cas possibles :
1. au moins une des 2 APIs est KO : la synchronisation n'est alors pas lancée, l'application fait un retour à l'utilisateur l'invitant à réessayer plus tard ou de contacter l'assistance.
2. les 2 APIs répondent, la synchronisation démarre

### Erreur lors des PUT

- **403/404/500** : Si lors de l'envoie des données, l'application reçoit une erreur **403**,**404** ou **500**, l'application va faire un **POST** sur le end-point **/api/survey-unit/:id/temp-zone** pour sauvegarder l'unité enquêtée dans une zone temporaire ("garage").

- si une erreur survient (n'importe laquelle) lors de ce **POST** vers le "garage", l'application interrompt la synchronisation pour éviter de perdre de la donnée

- **autre** : levée d'une erreur, la synchronisation est interrompu pour erreur inconnue et éviter de perdre de la donnée.

**Remarque :** les unités enquêtées mises en zone "garage" sont mémorisés pour l'envoie d'un mail plus tard

### Erreur lors des GET

- unités enquêtées :
- **403**/**404**/**500** : l'erreur est simplement ignorée, la synchronisation continue
- **autre**: levée d'une erreur et interruption de la synchronisation pour une erreur inconnue

Si aucune erreur n'est levée, la synchronisation de Queen démarre.

A ce stade, si une erreur bloquante a eu lieu, aucune donnée n'a été perdue.
Soit on a une erreur bloquante durant l'envoie, la synchronisation s'arrête, le navigateur n'a pas encore été nettoyé, tout est encore en local, dans la base de donnée du navigateur.
Soit on a une erreur bloquante durant la réception des données, dans ce cas, l'utilisateur n'a plus de données, mais tout est déjà sauvegardé côté serveur dans l'étape précédente.

### Fin et bilan de synchronisation Pearl
- Calcul à partir des informations remontées par la synchronisation des informations suivantes:
- unités enquêtées récupérées sans problème
- unités enquêtées mises en zone "garage"
- si la synchronisation a réussi ou non (aucune erreur bloquante non traitée)
- Sauvegarde de ces informations dans le navigateur et passe la main à Queen

## Queen

### Erreur lors des PUT

- **403/404/500** : Si lors de l'envoie des données, l'application reçoit une erreur **403**,**404** ou **500**, l'application va faire un **POST** sur le end-point **/api/survey-unit/:id/temp-zone** pour sauvegarder l'unité enquêtée dans une zone temporaire ("garage").

- si une erreur survient (n'importe laquelle) lors de ce **POST** vers le "garage", l'application interrompt la synchronisation pour éviter de perdre de la donnée

- **autre** : levée d'une erreur, la synchronisation est interrompu pour erreur inconnue et éviter de perdre de la donnée.

**Remarque :** les unités enquêtées mises en zone "garage" sont mémorisés pour l'envoie d'un mail plus tard

### Erreur lors des GET

- questionnaire :
- **403**/**404**/**500** : l'erreur est ignorée, l'information comme quoi le questionnaire est inaccessible, est mémorisée, la synchronisation continue
- **autre**: levée d'une erreur et interruption de la synchronisation pour erreur inconnue

- ressources :
- **403**/**404**/**500** : l'erreur est ignorée, l'information comme quoi le questionnaire concerné concernée par les ressources en erreur est inaccessible, est mémorisée, la synchronisation continue
- **autre**: levée d'une erreur et interruption de la synchronisation pour erreur inconnue

- unités enquêtées :
- **403**/**404**/**500** : l'erreur est simplement ignorée, la synchronisation continue
- **autre**: levée d'une erreur et interruption de la synchronisation pour erreur inconnue

### Fin et bilan de synchronisation Queen
- Calcul à partir des informations remontées par la synchronisation des informations suivantes:
- unités enquêtées récupérées sans problème
- unités enquêtées mises en zone "garage"
- si la synchronisation a réussi ou non (aucune erreur bloquante non traitée)
- Sauvegarde de ces informations dans le navigateur et passe la main à Pearl

## Retour à Pearl : fin et bilan de synchronisation globale

A partir des informations de synchronisation Queen & Pearl, l'application calcul :
- les asymétries:
- les unités manquantes ou inaccessibles (manque questionnaire ou ressource) dans Queen
- les unités manquantes dans Pearl (en trop dans Queen)

### Sauvegarde de l'information en local
- en fonction de ces asymétries, l'application sauvegarde pour chaque unité enquêtée présente dans Pearl si le questionnaire est accessible ou non, afin de bloquer l'accès.

### Envoi de mail
- selon la présence ou non d'asymétrie, envoie d'un mail à l'administrateur de l'application pour information (avec les unités enquêtées concernées).

- selon la présence d'unités enquêtées envoyées en zone "garage", envoi d'un mail pour Pearl, un autre pour Queen (avec les unités enquêtées concernées).*

### Fin & retour utilisateur

En fonction du résultat de la synchronisation, il y a 3 cas :
1. Aucune erreur (bloquante ou non bloquante) : message pour prévenir l'utilisateur que tout s'est bien passé
2. Erreur non bloqunte : message pour prévenir l'utilisateur que tout ne s'est pas bien passé mais que tout a été pris en charge. On lui indique qu'il peut continuer à travailler
3. Erreur bloquante : message pour lui inviter à recommencer la synchronisation ultérieurement ou à contacter l'assistance si l'erreur persiste

Dans les cas 2 et 3, un message rassurant indique à l'utilisateur qu'aucune donnée n'a été perdue. :smile_cat: