Relier deux logiciels ne règle pas leur désaccord. Il faut d’abord savoir lequel fait référence, pour quelle information et à quel moment.
Un propriétaire par champ.
Un outil peut faire référence pour les coordonnées d’un compte, un autre pour un statut opérationnel. La règle doit être définie champ par champ.
Sans cette règle, une modification peut être annulée par la synchronisation suivante. Le problème vient alors de la responsabilité de la donnée, pas seulement du connecteur.
Reconnaître une opération déjà traitée.
Un fichier peut être renvoyé. Une requête peut expirer alors que l’outil a déjà effectué la modification. Une reprise doit reconnaître l’opération au lieu de la recréer.
Une référence stable et une règle de rejeu permettent de distinguer une nouvelle demande d’une nouvelle tentative de la même demande. C’est le principe d’idempotence.
Ne pas écraser un conflit.
Deux valeurs différentes ne se départagent pas systématiquement avec la date la plus récente. Le propriétaire du champ et la règle métier restent déterminants.
Un conflit non résolu est signalé avec les deux sources. Le flux peut continuer sur les opérations indépendantes si le périmètre l’autorise.
- Source et destination définies.
- Clé d’opération stable.
- Traitement des doublons et conflits.
- Journal et procédure de reprise.
Tester aussi l’interruption.
Les tests ne se limitent pas au fichier parfait. Rejouer une demande, couper un accès, recevoir un format inconnu ou reprendre après une interruption révèle les règles qui manquent.
6x37 documente ces conditions de fonctionnement dans le projet, avant la supervision dans la durée.