Webhooks et ERP : éviter les commandes en double
Distinguez événement et commande. Un exemple complet couvre les répétitions, les arrivées simultanées et une réponse ERP perdue.
Prévoyez les notifications répétées comme un cas normal de l’intégration de votre boutique. Un webhook est un message HTTP déclenché par le système émetteur. Sans accusé de réception, il peut arriver à nouveau. Il ne doit pas créer une commande ERP supplémentaire.
Stripe documente les événements répétés et la possibilité d’événements distincts pour un même objet. Vérifiez les règles de votre émetteur réel. L’exemple suivant est fictif et ne décrit pas l’API Stripe.
Deux identifiants, deux fonctions
La boutique shop-1 possède la commande W-240. L’événement evt-17 annonce sa création. L’ERP lui attribue E-901. L’identifiant d’événement reconnaît une nouvelle livraison du même message ; boutique et commande identifient ensemble l’opération métier. Un événement ultérieur evt-18 peut annoncer une modification de cette commande.
Message reçu ou incident | Résultat attendu |
|---|---|
Premier evt-17 | Créer E-901 dans l’ERP et l’associer à W-240. |
evt-17 répété | Reconnaître l’opération existante ; aucune autre commande. |
Deux copies simultanées de evt-17 | Une contrainte d’unicité ne laisse créer qu’une seule tâche de traitement. |
evt-18 pour W-240 | Associer la modification à la commande existante et vérifier les règles de modification. |
L’ERP crée la commande, mais sa réponse se perd | Résultat d’abord incertain ; rapprocher avec le même identifiant avant de recréer. |
Enregistrer durablement la réception
Authentifiez d’abord le message selon la méthode de l’émetteur. Enregistrez ensuite durablement l’événement avant d’en confirmer la réception. Une règle d’unicité sur émetteur et événement empêche deux copies simultanées de créer deux tâches. Une simple recherche avant insertion ne suffit pas face à la concurrence.
Le traitement suivant doit partir de façon fiable de ce stockage durable. Un processus de fond peut reprendre les événements enregistrés en attente. L’opération reste ainsi retrouvable après une panne entre réception et traitement.
Réponse possible après cet enregistrement :
{
"eventId": "evt-17",
"orderId": "W-240",
"status": "queued"
}Dans l’exemple, le statut HTTP est 202. Il confirme l’entrée dans le traitement, pas une commande ERP. Si l’enregistrement durable échoue, le destinataire ne doit pas annoncer une réception réussie.
Protéger aussi l’appel ERP
Utilisez une clé de création stable comme shop-1:W-240:create si la destination le permet. Conservez-la lors d’une nouvelle tentative sûre. Stripe illustre ce principe pour sa propre API ; sa signification exacte et sa durée de conservation dépendent de la destination.
Sans cette fonction, il faut une autre correspondance fiable : par exemple un identifiant externe rendu unique dans la destination et une recherche du résultat. Après une expiration de délai laissant la création incertaine, l’opération reste à rapprocher. Un nouvel identifiant aléatoire ferait passer la répétition pour une nouvelle création.
L’enregistrement de l’événement et la création ERP dans deux systèmes ne constituent pas automatiquement une transaction commune. Séparez réception, traitement, résultat incertain et fin confirmée. Ici, seule l’association confirmée à E-901 termine la création.
Inclure les incidents dans la recette
Renvoyez evt-17 successivement puis simultanément. Coupez la réponse après une création ERP réussie. Testez ensuite evt-18 comme vraie modification. Attendez une seule création, une correspondance conservée et un état de rapprochement visible si le résultat est inconnu. Définissez aussi la conservation des identifiants selon les répétitions possibles.
Sources
À lire aussi
Tous les articles
Interfaces & intégration avec ASES
ERP, CRM et boutique bien connectés