Contrôler les communications multi-sites

Réponse directe

Conseil technicien général

1. Repères de version

Les références de version ci-dessous sont conservées comme repères documentaires. Les menus, options et comportements doivent être contrôlés sur la version et la sérialisation réellement installées ; une évolution plus récente peut avoir modifié le fonctionnement.

2. Licence et disponibilité

La dépendance de licence mentionnée dans ce document provient des sources. Sa disponibilité peut varier selon la version, la sérialisation, le partenaire ou l’installation ; faites-la valider techniquement avant de modifier l’environnement.

3. Distinguer KWISATZ des opérations externes

Un enregistrement dans KWISATZ ne prouve pas automatiquement qu’une opération a été exécutée dans un système externe : débit ou remboursement TPE, mouvement physique d’espèces, envoi de SMS ou d’e-mail, ou action réalisée sur une plateforme.

4. Protection des données

5. Terminologie

Les exécutables sont généralement nommés interface de communication du back-office et interface de communication de la caisse. Les formes BCOM, interface de communication du back-office, FCOM et interface de communication de la caisse sont souvent employées oralement ou dans les dossiers de support.

6. Sens général des flux

7. Cartographier l’architecture

Avant le diagnostic, notez pour chaque niveau :

• le dossier et la licence ;
• le rôle interface de communication du back-office ou interface de communication de la caisse ;
• le code magasin et le numéro de connexion ;
• l’adresse IP ou le nom du serveur ;
• les dossiers et alias M0X ;
• les données autorisées dans chaque sens ;
• la version de chaque exécutable.

8. Architecture simple

interface de communication de la caisse caisse/magasin → interface de communication du back-office back-office

• Le interface de communication de la caisse remonte les tickets.
• Le interface de communication du back-office intègre les ventes et peut redescendre produits, tarifs ou autres référentiels.
• Une connexion correspond généralement à une zone M01, M02, etc.

9. Architecture Super Concentrateur

Un interface de communication du back-office intermédiaire en mode Super Concentrateur peut conserver son rôle local et remonter vers un interface de communication du back-office de niveau supérieur.

interface de communication de la caisse caisses → interface de communication du back-office magasin → interface de communication du back-office central

10. BMDCOMM

BMDCOMM simplifie le lancement et l’enchaînement de plusieurs interface de communication du back-office.

• Validez chaque interface de communication du back-office séparément.
• Vérifiez les flux avant orchestration.
• Ajoutez BMDCOMM seulement après la recette individuelle.

11. Contrôler que les modules sont lancés

1. Ouvrez le Gestionnaire des tâches Windows.
2. Recherchez les processus interface de communication du back-office et interface de communication de la caisse attendus.
3. Vérifiez qu’un seul exemplaire de chaque module nécessaire est actif.
4. Contrôlez le dossier affiché dans la barre de titre ou le survol du module.
5. Vérifiez que le module n’est pas en sommeil selon sa plage horaire.
6. Consultez les premières lignes du journal.

12. Lancement et arrêt depuis KWISATZ

Les versions documentées proposent :

• Préférences > Général > Module d’actualisation interfaces de communication multi-sites > Lancement automatique ;
• Outils > Transfert de données > Arrêt du module de communication.

13. Surveillance depuis KWISATZ

Un ancien système technique documente les clés suivantes dans la section poste des préférences :

14. HeartBeat

Le système HeartBeat documenté fonctionne ainsi :

• interface de communication de la caisse envoie une trame TCP toutes les 30 secondes ;
• interface de communication du back-office écoute et journalise la présence ;
• le port par défaut est 12007 ;
• l’affichage des événements HeartBeat dans le log peut être activé ou désactivé ;
• le tableau de bord interface de communication du back-office affiche le dernier HeartBeat reçu pour chaque module.

15. Tableau de bord interface de communication du back-office

16. Journaux interfaces de communication multi-sites

Pour chaque incident, relevez :

• l’heure exacte ;
• le nom du module ;
• le dossier ;
• la connexion ;
• le fichier ou la table ;
• le document ou ticket ;
• le message complet ;
• la dernière opération réussie.

17. Messages d’avancement

Les modules échangent aussi des messages d’avancement, historiquement via UDP dans certaines fonctions. KWISATZ peut afficher un état figé pendant une opération de cacheupdates lorsque la surveillance est active.

18. Zones import/export M0X

Ces zones sont des tampons techniques. Après une intégration normale, les fichiers traités doivent disparaître ou évoluer selon le mécanisme prévu.

19. Alias DB-server et dossiers physiques

Le DB-server utilise des alias qui pointent vers les répertoires physiques.

20. Suivre un flux de bout en bout

1. Choisissez une donnée de test non ambiguë.
2. Notez son code, numéro, date, magasin et caisse.
3. Déclenchez l’export côté source.
4. Vérifiez l’apparition du fichier dans la zone export de la source ou import de la cible selon l’architecture.
5. Contrôlez le journal du module émetteur.
6. Vérifiez la disparition du fichier après intégration.
7. Ouvrez la donnée dans la base cible.
8. Contrôlez qu’elle n’existe qu’une seule fois.

21. Test de remontée d’un ticket

22. Test de descente d’un article

1. Choisissez un article de recette.
2. Modifiez une seule donnée clairement identifiable.
3. Déclenchez la mise à jour produits côté interface de communication du back-office.
4. Vérifiez la création du fichier d’actualisation.
5. Contrôlez sa réception et son import par interface de communication de la caisse.
6. Ouvrez l’article sur le site distant.
7. Contrôlez les zones protégées par les options « Conserver valeurs locales ».

23. Options d’import des articles

Les versions documentent des options telles que :

• accepter les articles existants ;
• conserver les tarifs et quantités locaux ;
• conserver les tarifs spéciaux ;
• conserver les opérations spéciales ;
• conserver les informations de réapprovisionnement ;
• conserver les informations Dépôt/Vente, Resto ou Web selon la version.

24. Compatibilité des versions

• Comparez la version et la révision de interface de communication du back-office, interface de communication de la caisse et KWISATZ.
• Mettez idéalement les deux modules à niveau ensemble.
• Contrôlez les notes de version lorsqu’une structure ou un nom de fichier change.
• Testez produits, tarifs, tickets et documents après mise à jour.

25. Plages horaires d’activité

La fenêtre de configuration documente une gestion de l’activité par tranche horaire avec 24 cases.

• Vérifiez que l’heure courante est autorisée.
• Contrôlez l’horloge Windows.
• Évitez la mise en sommeil pendant les heures de vente.
• Planifiez éventuellement l’inactivité pendant la sauvegarde.

26. Ports réseau

27. Contrôle réseau

1. Vérifiez les adresses IP de la source et de la cible.
2. Testez le ping lorsque le réseau l’autorise.
3. Testez les ports nécessaires depuis le poste concerné.
4. Contrôlez le pare-feu Windows.
5. Vérifiez le VPN ou le routage inter-sites.
6. Contrôlez les redirections NAT après un changement de box.
7. Préférez une liaison filaire pour un serveur critique.

28. Adresse IP et erreur de socket

Un message de type could not bind socket peut apparaître lorsque interface de communication de la caisse tente d’écouter sur une ancienne adresse locale qui n’appartient plus au poste.

• Contrôlez les interfaces réseau actives.
• Vérifiez les changements DHCP.
• Utilisez 127.0.0.1 uniquement lorsqu’il s’agit réellement d’un dialogue local validé.
• Sauvegardez tout fichier INI avant modification.

29. Nettoyage contrôlé des zones d’échange

1. Identifier la connexion exacte, par exemple M01.
2. Arrêter interfaces de communication multi-sites.
3. Vérifier qu’aucun transfert n’est en cours.
4. Copier les fichiers bloqués dans un dossier de diagnostic.
5. Effacer uniquement les fichiers contenus dans la zone concernée.
6. Ne pas supprimer le dossier M01/M02.
7. Ne pas supprimer l’alias DB-server.
8. Relancer les modules.
9. Forcer un nouvel export propre.
10. Contrôler l’intégration et les doublons.

30. Fichier partiellement écrit

Un arrêt ou plantage pendant le transfert peut laisser un fichier incomplet. Les symptômes possibles sont :

• message de table ou entête corrompu ;
• fichier restant dans la zone d’échange ;
• intégration bloquée toujours sur le même fichier ;
• entête de ticket présent sans lignes ;
• erreur répétée après chaque relance.

31. Erreur moteur de données pendant l’intégration

1. Relever la table et le numéro exact de l’erreur.
2. Sauvegarder la base.
3. Arrêter interface de communication du back-office, interface de communication de la caisse et les accès concernés.
4. Distinguer fichier tampon endommagé et table cible endommagée.
5. Réparer ou réindexer uniquement la table signalée sous procédure technique.
6. Relancer le même flux de test.
7. Traiter la table suivante seulement si une nouvelle erreur la désigne.

32. Entête sans lignes de ticket

Lorsqu’un ticket est visible côté interface de communication du back-office mais sans détail :

• vérifiez le ticket complet côté interface de communication de la caisse ;
• contrôlez TICKET_ENTETE, TICKET_VENTE et TICKET_REGLEMENT ;
• relancez l’envoi du ticket ou de la journée selon la procédure ;
• contrôlez les versions et les index ;
• vérifiez l’absence de doublon après le renvoi.

33. Document non mis à jour

Avant de conclure à une panne de communication, comparez exactement :

• le numéro du document ;
• le client ou fournisseur ;
• la date ;
• le statut ;
• les filtres actifs dans les listes.

34. Rattrapage volumineux

Un interface de communication de la caisse qui rattrape de nombreux tickets peut fortement solliciter le poste.

• Surveillez CPU, mémoire, disque et réseau.
• Évitez le rattrapage pendant un pic d’encaissement.
• Contrôlez le paramètre documenté Délai d’inactivité entre 2 opérations, historiquement initialisé à 50 ms.
• Ne modifiez pas ce délai sans mesurer le résultat.

35. Procédure de reprise standard

1. Sécuriser et sauvegarder.
2. Noter les derniers tickets et documents intégrés.
3. Arrêter proprement interfaces de communication multi-sites.
4. Contrôler réseau, versions et plages horaires.
5. Contrôler les dossiers et alias M0X.
6. Isoler les fichiers bloqués.
7. Purger uniquement le contenu nécessaire.
8. Relancer d’abord le serveur et interface de communication du back-office.
9. Relancer interface de communication de la caisse.
10. Tester HeartBeat.
11. Tester un ticket.
12. Tester une mise à jour produit.
13. Surveiller les journaux et les doublons.

36. Plan de test

37. Surveillance quotidienne

38. Actions à éviter

• Supprimer le dossier M01/M02.
• Supprimer un alias DB-server sans plan de reconstruction.
• Purger toutes les connexions à la fois.
• Relancer plusieurs fois un export sans contrôler les doublons.
• Comparer deux documents portant des numéros différents.
• Mettre à jour interface de communication du back-office sans contrôler la compatibilité interface de communication de la caisse.
• Activer Super Concentrateur sans interface de communication du back-office central.
• Utiliser BMDCOMM avant de valider les interface de communication du back-office.
• Ouvrir les ports sur Internet sans VPN ou filtrage.
• Réparer globalement les tables de tickets sans message précis.

39. Compatibilité documentée

40. Diagnostic rapide

41. Résultat attendu

42. Sources documentaires

• Suivi de développement — HeartBeat TCP, port 12007 et tableau de bord interface de communication du back-office.
• Suivi de développement — lancement automatique, surveillance réglages internes de surveillance et arrêt applicatif du module.
• Suivi de développement — options d’import automatique et conservation des valeurs locales.
• Base support — architecture interfaces de communication multi-sites, Super Concentrateur et BMDCOMM.
• Base support — zones import/export/M01, fichiers temporaires et piège des alias DB-server.
• Base support — ports 6202, 12005, 12006 et 12007.
• Base support — erreurs moteur de données, remontées de tickets incomplètes et reprise ciblée.