Flux retail : préparer la recette et les reprises avec un contrat de données

Commencer par les décisions métier à protéger

Le premier atelier réunit les responsables des applications sources et cibles, l’exploitation et un représentant métier. Prenez un parcours précis : publier une disponibilité, transmettre une commande ou rendre un produit vendable. Désignez le système qui fait autorité pour chaque information et la personne habilitée à arbitrer un désaccord.

Définissez ensuite la fraîcheur acceptable, le comportement en cas de retard et la preuve de bonne réception. Une réponse technique positive peut seulement confirmer une prise en charge. Si la cible traite ensuite la demande, la recette doit vérifier son résultat final. Cette distinction évite de déclarer livré un flux dont les données restent bloquées en aval.

Le livrable de cadrage est une fiche par flux : périmètre, propriétaire, dépendances, objectifs de délai, règles de rejet et critères d’acceptation. Fixez les seuils avec le métier, à partir de ses contraintes ; un chiffre choisi uniquement pour faciliter le test ne constitue pas un engagement utile.

Définir d’abord le périmètre, les responsabilités et les lots de mission

Écrire un contrat qui précise le sens des données

Un schéma décrit la structure ; le contrat précise aussi ce qu’elle signifie. Pour le stock, indiquez s’il s’agit du physique, du réservé ou du disponible à la vente. Définissez la granularité article et emplacement, les unités, la signification de zéro et celle d’une valeur absente. Précisez si chaque échange remplace un état ou représente un mouvement.

Pour les commandes, documentez la clé métier, les identifiants de ligne et les transitions de statut autorisées. Pour le catalogue, distinguez produit, variante et offre commerciale. Une fiche valide dans le référentiel peut rester impropre à la publication sur un canal : les conditions de publication doivent être testables séparément.

La spécification AsyncAPI décrit notamment les messages, leurs en-têtes, leurs charges utiles et leur corrélation. Elle peut formaliser la partie technique d’un échange asynchrone. Complétez-la par les responsabilités, les règles métier et les engagements de service. Pour un fichier, une définition versionnée des colonnes accompagnée des mêmes règles peut suffire.

• Identité : clé métier, identifiant d’événement et périmètre d’unicité.
• Temporalité : instant métier, instant de réception et règle de classement des versions.
• Qualité : champs obligatoires, valeurs autorisées et traitement des références inconnues.
• Évolution : compatibilité attendue, consommateurs concernés et procédure de changement.

Livrable : un contrat de stock rempli, à adapter

Exemple pédagogique fictif, contrat STOCK-DISPONIBLE v1. Il porte sur un état absolu par variante et entrepôt. Le même document est remis au producteur, à l’intégrateur et au consommateur ; toute évolution est versionnée et réexaminée avec eux.

• Source et cible : ERP vers site marchand ; propriétaire métier : responsable disponibilité ; support : équipe exploitation désignée.
• Clé : variante + entrepôt. Valeur : quantité disponible à la vente en unités ; zéro signifie indisponible, une valeur absente est rejetée.
• Message : identifiant stable, version source croissante par clé, instant métier et quantité absolue. Un produit absent d’un lot partiel reste inchangé.
• Ordre : conserver la version la plus récente ; deux contenus différents portant la même version déclenchent un conflit à investiguer.
• Reprise : sélectionner les messages concernés, préserver leur identité et rapprocher l’état final avec la source avant clôture.
• Critère de fraîcheur : seuil à convenir avec le métier avant signature ; consigner le comportement commercial après dépassement.
• Preuve : contrat v1 + jeu d’entrée + état initial + résultat cible + journal de décision + accord du responsable métier.

Exemple hypothétique : un stock reçu dans le désordre

Imaginons une enseigne fictive dont l’ERP publie des états de stock vers un site marchand. Pour une variante et un entrepôt donnés, la version 42 indique sept unités disponibles. La version 43 en indique quatre. Après une coupure, la version 42 arrive une seconde fois, après la version 43. Ces valeurs illustrent un scénario de test, pas un résultat de mission.

Le contrat proposé prévoit une version croissante par couple variante et entrepôt. La cible conserve la version appliquée et ignore un état plus ancien. La recette attend donc quatre unités après réception des trois messages. Elle vérifie aussi que deux traitements simultanés ne peuvent pas contourner ce contrôle : comparaison et écriture doivent être protégées ensemble.

Cette solution convient à des états complets de disponibilité. Pour des mouvements à additionner, ignorer tout événement ancien pourrait perdre une variation légitime : il faut identifier les mouvements déjà appliqués et détecter les trous. De même, un horodatage seul ne constitue pas un ordre fiable si plusieurs producteurs utilisent des horloges non coordonnées.

Séparer doublons, ordre et confirmation d’écriture

Les scénarios de recette séparent trois propriétés : une répétition ne crée pas de second effet, une ancienne version ne remplace pas un état récent, et une confirmation perdue conduit à retrouver le résultat ou à investiguer. Réussir l’un de ces tests ne prouve pas les deux autres.

Documentez la capacité de la cible à retrouver l’opération et la durée de conservation des identifiants. Si une API distante ne permet pas de déterminer l’issue, le contrat doit prévoir un rapprochement et un état à investiguer avant une nouvelle création.

Voir la trace de réservation et le test d’idempotence détaillé

Préparer une reprise sélective et observable

Classez les incidents avant de définir les relances. Une indisponibilité temporaire peut justifier des tentatives espacées et limitées. Un code article inconnu demande plutôt une correction ou l’arrivée du référentiel attendu. Une réponse perdue exige une vérification de l’écriture. Relancer indistinctement ces trois situations rend le diagnostic plus difficile.

Dans Azure Service Bus, une file de lettres mortes permet d’inspecter les messages non traités et d’organiser leur resoumission ; elle n’est pas nettoyée automatiquement. Quel que soit l’outil retenu, attribuez un responsable aux rejets, un motif exploitable et une procédure de clôture.

Le mode opératoire de reprise précise la sélection des objets, les dépendances à rétablir et les contrôles avant réinjection. Conservez l’identité métier tout en traçant chaque tentative. Prévoyez un aperçu du périmètre et une limite de débit : une reprise massive ne doit pas empêcher les nouvelles commandes d’avancer.

Arbitrer la fraîcheur, le débit et la complexité

Un flux fréquent réduit potentiellement le retard, mais augmente les sollicitations de la cible. Un traitement par lots simplifie certains rapprochements, au prix d’une attente supplémentaire. Décidez par usage : le délai acceptable pour enrichir une description produit peut différer de celui d’une disponibilité commerciale.

Mesurez l’âge de la donnée métier et celui du plus ancien objet en attente, en plus des durées d’exécution. Un traitement rapide sur des données anciennes reste insuffisant. Préparez également une comparaison périodique entre source et cible, avec un périmètre temporel cohérent pour éviter les faux écarts pendant les mises à jour.

Dans un environnement Semarchy xDI ou Stambia, gardez les règles de validation et les procédures de reprise identifiables. Si un composant .NET complète le dispositif, explicitez sa responsabilité. Répartir la même règle entre plusieurs traitements augmente le risque de divergence lors d’une correction.

Checklist de recette avant la mise en production

Chaque cas doit associer des données d’entrée, un état initial, une action et un résultat attendu dans la cible. Conservez les preuves avec la version du contrat et des traitements. Un total de lignes identique ne suffit pas : deux commandes peuvent être inversées ou une valeur erronée peut remplacer la bonne.

• Cas nominal : vérifier les valeurs métier, les identifiants et le statut final dans chaque cible.
• Doublon : renvoyer le même événement et vérifier l’absence de deuxième effet métier.
• Désordre : inverser deux versions et contrôler l’état final selon le contrat.
• Coupure : interrompre après l’écriture cible mais avant sa confirmation, puis reprendre.
• Rejet partiel : mélanger objets valides et invalides et justifier le sort de chacun.
• Dépendance manquante : envoyer une commande avec une référence inconnue, puis régulariser.
• Évolution : tester un champ ajouté, un champ obligatoire absent et une valeur inconnue.
• Rattrapage : rejouer un arriéré avec du trafic courant et mesurer fraîcheur et débit.
• Rapprochement : rechercher les objets manquants, supplémentaires et incohérents.
• Exploitation : faire exécuter la procédure de reprise par l’équipe qui assurera le support.

Accepter une livraison sur des preuves partagées

Les erreurs courantes consistent à tester uniquement le parcours nominal, confondre réception et intégration, ou reporter la reprise après le lancement. Demandez un dossier réunissant contrat versionné, résultats de recette, écarts connus et procédures d’exploitation. Un retour arrière applicatif ne corrige pas automatiquement les données déjà écrites : prévoyez leur traitement.

Pour préparer la recette avec Sculpture Binaire, rassemblez un contrat existant, un échange anonymisé, les incidents observés et les critères métier. Hugues Dehen, basé à Raismes près de Valenciennes, peut délimiter avec vous le dossier de preuve et les modifications nécessaires aux flux.

Préparer la recette d’une reprise ou migration Stambia/xDI

Vérifier catalogue, offres et commandes dans une intégration Mirakl