Architecture et fiabilité des données
Flux retail : éviter les commandes en double grâce à l’idempotence
Une réservation réussit, mais sa réponse se perd. Relancer doit retrouver la même opération sans retirer du stock une deuxième fois. Ce guide suit un exemple fictif de bout en bout : identité de réservation, trace des états, frontière transactionnelle et tests concurrents. Il précise ce que le registre d’opérations protège et ce qu’il ne peut pas garantir lorsque l’ERP écrit dans une transaction distante.
Partir de l’effet métier à protéger
Commencez par identifier ce qu’un doublon provoquerait réellement : seconde commande dans l’ERP, réservation supplémentaire, mouvement de stock répété ou nouvelle demande d’expédition. Un fichier importé une seule fois peut contenir deux occurrences de la même opération. Inversement, deux messages identiques peuvent représenter deux achats légitimes. La ressemblance des données ne suffit donc pas à décider.
Organisez le cadrage autour d’un parcours précis, de sa source jusqu’à son effet final. Pour chaque étape, relevez le propriétaire métier, le système qui fait autorité et la preuve permettant de confirmer l’application. Une réponse technique favorable n’établit pas toujours que la commande est exploitable : une interface peut accepter une demande avant de la traiter.
- Définir l’opération protégée : création, modification, réservation, annulation ou expédition.
- Identifier les effets externes qui doivent également être contrôlés.
- Distinguer réception, validation métier et application effective dans les statuts.
Inscrire l’identité de l’opération dans le contrat de données
Le contrat doit distinguer l’identifiant de commande, l’identifiant d’opération et l’identifiant de tentative technique. Une commande traverse plusieurs opérations légitimes ; une tentative sert au diagnostic. Mélanger ces trois niveaux conduit soit à laisser passer les doublons, soit à bloquer une modification normale.
L’Amazon Builders’ Library décrit l’usage d’un identifiant de requête stable pour reconnaître les répétitions. Pour votre interface, formalisez sa portée : système source, enseigne éventuelle et type d’opération. Précisez qui le produit et comment il survit à une relance manuelle.
Ajoutez au contrat les champs nécessaires à l’interprétation : version de schéma, référence métier, version de l’objet et contenu de l’opération. Définissez aussi le traitement d’une clé reçue avec un contenu différent : rejet explicite et investigation, plutôt qu’une correction silencieuse. Une empreinte du contenu peut aider au contrôle, mais ne remplace pas l’identité métier.
Définir ce comportement dans le contrat et le dossier de recette
Exemple hypothétique : une réservation après une réponse perdue
Prenons un scénario entièrement fictif. Une boutique transmet la commande C-482 à un service de réservation. L’opération R-482 réserve deux unités du produit P-17 dans l’entrepôt NORD. La réservation aboutit, puis la connexion est interrompue avant le retour de confirmation. La supervision affiche alors un résultat inconnu.
Le comportement attendu est défini avant le développement : la reprise de R-482 retrouve la réservation et son résultat ; elle ne retire pas deux unités supplémentaires. Si le client ajoute ensuite une unité à sa commande, cette modification reçoit une nouvelle identité d’opération et suit les règles de modification convenues.
Le dossier de recette doit montrer la commande, la réservation et le stock attendu après chaque étape. Il doit aussi prévoir deux réservations légitimes portant sur le même produit et la même quantité. Ce cas vérifie que la protection n’efface pas des opérations distinctes simplement parce que leur contenu se ressemble.
- État initial : dix unités disponibles, aucune réservation R-482.
- Premier appel R-482 pour deux unités : réservation enregistrée, stock à huit ; confirmation perdue.
- Nouvelle tentative R-482 avec le même contenu : même réservation et résultat, stock toujours à huit.
- R-482 reçu avec trois unités : conflit explicite, aucune écriture métier supplémentaire.
- Nouvelle opération R-483 pour une unité : seconde réservation légitime, stock à sept.
- Deux tentatives simultanées de R-482 : une seule réservation ; la contrainte et la transaction empêchent deux effets.
Placer la protection au plus près de l’écriture
Demandez une revue de la frontière transactionnelle : quelles écritures réussissent ou échouent ensemble ? Dans une conception proposée, le destinataire conserve un registre des opérations appliquées et réalise l’écriture métier dans la même transaction locale. Le dossier technique doit rendre visible cette frontière, notamment lorsque plusieurs traitements peuvent recevoir simultanément une opération.
PostgreSQL documente une issue atomique pour INSERT avec ON CONFLICT DO UPDATE. Cela fournit une brique de gestion de concurrence, mais une mise à jour qui soustrait une quantité à chaque passage répète toujours cette soustraction. Examinez donc l’expression métier exécutée et les contraintes d’unicité, au-delà du choix de l’instruction SQL.
Pour un service .NET ou un traitement d’intégration, demandez une démonstration avec deux exécutions concurrentes et un arrêt au mauvais moment. Un simple contrôle préalable d’existence ne constitue pas une preuve suffisante. Documentez également le comportement après échec : attente, nouvelle tentative ou incident à traiter.
Séparer la publication fiable et la déduplication
Microsoft présente le modèle Transactional Outbox pour enregistrer une modification métier et son événement dans la même transaction, puis publier séparément cet événement. Cette approche répond au risque d’une commande enregistrée dont la notification ne part jamais. Son choix implique aussi un traitement de publication à exploiter et à surveiller.
La détection des doublons d’Azure Service Bus utilise l’identité du message dans une fenêtre configurée. Elle ne remplace donc pas une règle métier couvrant une reprise plus ancienne. Dans le dossier d’architecture, séparez explicitement la garantie de publication, le filtrage du transport et la protection du destinataire.
Si l’ERP expose uniquement une API distante, une transaction dans votre base ne couvre pas son écriture. Exigez une capacité d’idempotence distante ou une procédure de rapprochement adaptée. Lorsque l’issue reste ambiguë et qu’aucune vérification fiable n’existe, prévoyez un état à investiguer avant toute nouvelle création.
Adapter la règle aux stocks et au catalogue
Pour un stock, distinguez la publication d’une quantité absolue d’un mouvement. Réappliquer une quantité donnée et rejouer une sortie de stock ne suivent pas la même logique. Précisez aussi comment traiter une valeur ancienne reçue après une valeur récente. La version doit avoir une signification définie par la source ; l’heure de réception ne suffit pas.
Pour le catalogue, définissez l’identité au bon niveau : produit, variante, canal et langue selon le modèle retenu. Une correction descriptive ne doit pas être confondue avec une suppression puis une recréation. Prévoyez notamment le sort d’une ancienne publication reçue après le retrait d’un article.
Ces décisions appartiennent au contrat d’interface, que l’exécution repose sur du code .NET, un flux Semarchy xDI/Stambia ou un autre outil. Elles doivent rester compréhensibles par l’équipe qui exploite les données.
Arbitrer les coûts et éviter les reprises aveugles
Fixez la durée de conservation des preuves à partir des reprises réellement autorisées : incident récent, retraitement d’archives ou restauration. Une conservation plus longue augmente le volume et les besoins d’administration. Une conservation trop courte exige un autre moyen de reconnaître les opérations historiques.
Pour une reprise massive, préparez une sélection explicite des opérations, un aperçu des effets attendus et des conditions d’arrêt. Séparez les opérations à résultat inconnu des rejets métier établis. Corriger une référence produit invalide demande une décision différente de celle qui suit une coupure réseau.
Les erreurs courantes sont de générer une nouvelle clé à chaque relance, de purger le registre sans considérer les archives, ou de considérer tous les doublons comme des erreurs. Prévoyez des indicateurs distincts : répétitions reconnues, conflits de contenu, résultats inconnus et ancienneté des opérations en attente. Leur interprétation doit déboucher sur une action d’exploitation.
Checklist de recette avant mise en production
Associez chaque scénario à un état métier attendu et à une preuve consultable. Le résultat du job seul ne suffit pas. Exécutez ces tests avec les équipes responsables de la source, de l’intégration et du destinataire.
- Répéter une opération terminée et vérifier l’absence de nouvel effet métier.
- Envoyer simultanément deux tentatives et contrôler commandes, réservations et mouvements.
- Interrompre la réponse après application, puis vérifier la reprise du résultat.
- Réutiliser une clé avec un contenu différent et obtenir un diagnostic explicite.
- Traiter deux opérations légitimes de contenu identique sans en perdre une.
- Recevoir une ancienne version après une modification et vérifier la règle convenue.
- Tester une reprise historique après expiration des protections de transport.
- Contrôler les effets aval, les alertes, le rapprochement et les conditions d’arrêt.
Définir un périmètre de travail vérifiable
Pour préparer une intervention avec Sculpture Binaire, réunissez le contrat existant, un exemple anonymisé de résultat ambigu et la liste des écritures aval. Un premier périmètre peut couvrir un seul parcours de commande. Les livrables attendus sont alors concrets : règles d’identité, frontières transactionnelles, procédure de reprise et preuves de recette. Cette délimitation permet de discuter l’effort et les limites sans promettre une garantie générale sur tout le système.
Délimiter le parcours et les responsabilités avant de chiffrer la mission