---
# System prepended metadata

title: PIM EAN doublons

---

# PIM EAN doublons

## Problème rencontré

Suite à un email du 1er décembre, on a vu des sizes avec un EAN assignés qui a déjà été assignés, deux causes trouvées:

- Pas de lock lors de la création d'une Size, du coup si l'on crée beaucoup de sizes d'un coup, on peut avoir des moments où la requête qui récupère l'EAN a assigner à une Size renvoie le même EAN ;
- Des restes de la migration de vers le nouvel ERP datant d'avril dernier (24 sizes au total, 12 EANs en doublons).

## Solutions mise en place
- Mise en place d'un lock sur la création d'une Size avant de récupérer l'EAN a lui attribuer. Celui-ci sera libéré une fois la Size crée ;
- Malgré le premier fix, nous avions toujours des soucis à cause de Kafka. Nous envoyons les messages Kafka avant de créer la Size chez nous. On a donc modifié ce comportement pour que le push Kafka soit fait une fois la Size crée et qu'il passe après tout autre process ;
- Mise en place d'une commande pour corriger les EAN et leur assigner des nouveaux EAN avec un rapport montrant le diff pour permettre de corriger les bons de commandes côté ERP ensuite.

## Barrages rencontrés
- L'instance ERP de QLF est moins puissante que celle de prod, du coup on ne pouvais pas reproduire la même pression sur le PIM ;
- Nous avions une seule instance PIM en QLF, ce qui empêche de tester les soucis de concurrence, nous avons du monter à 6 instances ;
- Pas de logs applicatifs remontés pour le PIM en QLF sur Datadog.

## Solutions à mettre en place plus tard
- Ajouter une contrainte d'unicité sur la table des Size du PIM pour la colonne EAN ;
- Remonter les logs applicatifs du PIM en QLF ;
- Supprimer la commande pour fix les EANs (plus de raison d'être).


## Des chiffres

Entre la mise en ligne du 16 novembre (gestion des EAN dans le PIM) et cet incident, nous avons eu 998 sizes crées, parmis celles-ci, 264 étaient en doublons (~26.5%).
Au 7 décembre à 10h20, nous sommes à 301 sizes crées depuis le fix et aucun doublons.
