APERÇU RAPIDE
Ce qu'il faut retenir de l'article
- Chaque événement important a besoin d’une identité et d’un résultat traçable.
- La nouvelle tentative ne doit pas répéter l’effet métier.
- Les erreurs doivent avoir un propriétaire, un délai de résolution et la possibilité d’une récupération en toute sécurité.
Déterminer quel système est la source de la vérité
L'e-boutique accepte la commande, l'entrepôt réserve la marchandise et le système comptable gère le document. Si chaque système peut tout changer sans règles, des conflits surgissent. Pour chaque champ, déterminez le propriétaire : qui décide du prix, du statut de paiement, de la disponibilité et du statut d'expédition. D'autres systèmes reçoivent une modification vérifiée ou envoient une demande pour l'exécuter.
Pour plusieurs entreprises, l'identification doit également inclure l'entreprise. Un même numéro de commande peut exister dans deux agendas distincts. Par conséquent, le lien entre les enregistrements ne doit pas uniquement être basé sur le numéro affiché au client. Vous avez besoin d'identifiants internes et d'un mappage entre les systèmes. Le cadre métier décrit l'article sur entrepôt et boutique en ligne connectée à l'ERP.
Un webhook est une notification, pas une garantie d'achèvement
Le webhook informe l'autre application d'un événement, tel qu'un paiement réussi. Le destinataire doit vérifier l'expéditeur et les données. La documentation de Stripe met en garde contre la vérification de la signature, la possibilité d'événements en double et le fait que le bon de livraison peut ne pas être garanti. Ces fonctionnalités doivent être prises en compte dans la conception de chaque intégration spécifique selon sa documentation.
Nous vous recommandons de mettre d’abord l’événement en file d’attente en toute sécurité avant de confirmer sa réception. Le traitement commercial lui-même peut se poursuivre séparément. Le système fait ainsi la distinction entre les événements reçus, traités et d'erreur. Il ne suffit pas de répondre positivement et d'espérer que la prochaine étape soit franchie. Si le commit s'éteint avant d'être persistant, la panne peut faire perdre l'événement.
Idempotence : même instruction, même effet
L'idempotence signifie que répéter en toute sécurité la même instruction ne créera pas une deuxième commande, réservation ou facture. En pratique, le destinataire mémorise l'identifiant unique de l'événement et le résultat du traitement. En même temps, elle doit également protéger l’activité de l’entreprise, puisque deux événements techniques différents peuvent décrire le même changement.
Imaginez une panne après la création d'une commande dans l'ERP, mais avant que la confirmation ne soit renvoyée à l'e-shop. La boutique en ligne tentera à nouveau la demande. Le résultat correct est de rechercher la liaison existante et de renvoyer le même ordre, et non d'en créer une autre. Le contrôle doit également résister à deux tentatives simultanées ; un simple "trouver d'abord puis créer" sans protection de la concurrence peut ne pas suffire.
Les événements retardés ne doivent pas faire reculer l’ordre
Le message « commande reçue » peut arriver seulement après le message « payée ». Si tout le monde écrase l'état sans vérifier, les anciennes informations effaceront le résultat le plus récent. Utilisez les transitions d'état autorisées et la version ou l'heure disponible de l'événement. En cas de conflit, chargez l'état actuel depuis le système source.
L'annulation et le remboursement sont des événements distincts. Ne supprimez pas l'historique des ventes réussies ; notez le changement ultérieur. Le même principe s’applique aux expéditions partielles et aux commandes fractionnées. Un état universel de « terminé » ne suffit souvent pas pour le stockage, le transport et les documents.
| Zone | Postup | Que vérifier |
|---|---|---|
| Webhook répété | Le résultat existant, sans seconde opération. | Nombre de réservations et de documents. |
| Abandon après inscription | Répéter trouvera une commande déjà créée. | Liaison des identifiants entre les systèmes. |
| Mauvaise commande | Un statut plus ancien n’écrasera pas un statut plus récent confirmé. | Transitions et historique autorisés. |
| Données incorrectes | L'enregistrement s'arrête pour une raison précise. | Personne responsable et procédure de réparation sécuritaire. |
Répétition automatique et liste de travail des exceptions
Une panne temporaire peut être résolue en la répétant avec une distance croissante. Cependant, la répétition ne suffira pas à corriger un tarif manquant, un produit inconnu ou une mauvaise entreprise. Divisez les erreurs techniques en erreurs temporaires et substantielles. Après la limite définie, l'événement doit être placé dans la liste pour être résolu et non s'exécuter indéfiniment.
Le gestionnaire doit connaître le nombre de commandes bloquées, leur âge, leur valeur et leur raison. Le travailleur a besoin d’une prochaine étape spécifique et d’un accès aux documents pertinents. Après la réparation, seule la partie nécessaire du processus doit être restaurée. Nous discutons de la conception du rapport du matin dans l'article [tableau de bord multi-entreprises] (/clanky/majitelsky-dashboard-viac-firiem).
Vérifiez également ce qui n'est pas arrivé
La surveillance des événements détectera un message d'erreur, mais peut ne pas détecter un événement complètement manquant. Par conséquent, ajoutez un rapprochement régulier : commandes Web par rapport à l'ERP, paiements confirmés par rapport aux commandes payées, et expédition par rapport aux mouvements de stock. Les exceptions doivent être explicables et attribuables à une personne ou à un processus de réparation.
Exécutez le pilote sur un seul flux avec une portée limitée. Mesurez le temps de traitement, le taux d’intervention manuelle, le nombre de doublons et le nombre de différences en suspens. N'étendez l'automatisation que lorsque la panne peut être récupérée en toute sécurité. Une connexion fiable permet de réaliser des économies précisément parce que l'entreprise n'a pas besoin de vérifier manuellement chaque jour si quelque chose a été perdu.
