Surveiller votre intégration
Lundi, 8 h 30 : la boutique en ligne affiche des stocks de vendredi soir. Le poste où tourne Acomba a redémarré pendant la fin de semaine pour une mise à jour Windows, et personne ne s'en est aperçu. Une intégration qui tombe en silence coûte plus cher qu'une intégration qui tombe en panne : on la découvre par les clients.Dans cette recette, nous allons écrire une petite sonde qui vérifie toutes les 15 minutes que votre intégration ExoConnect va bien : l'API répond, la synchronisation avec Acomba avance, la copie locale est prête, et aucune erreur n'est apparue depuis le dernier passage. En cas de problème, elle le dit, et votre outil de surveillance peut vous prévenir.Ce que vous allez apprendrevérifier que l'API et l'accès à Acomba sont prêts ;
détecter une synchronisation arrêtée ou en retard ;
relever les erreurs survenues depuis le dernier passage ;
repérer les opérations qui échouent.
votre clé API : la sonde ne fait que des lectures ;
un endroit où la lancer toutes les 15 minutes (tâche cron, Planificateur de tâches Windows, outil de surveillance) ;
un fichier local où la sonde note l'heure de son dernier passage.
Ce que la sonde vérifie#
Avant d'écrire la sonde, voyons ce qu'elle surveille. ExoConnect tourne sur le poste où Acomba est installé : un superviseur lance l'API, qui lit Acomba et garde une copie locale des fiches de référence, rafraîchie à intervalle régulier.
Étape 1 : l'API est-elle prête ?#
Commençons par le plus simple : l'API répond-elle, et est-elle prête à lire Acomba ? child.state vaut ready quand tout va bien.Si la requête n'aboutit pas du tout, le poste Acomba est éteint, en veille ou sans réseau.
Étape 2 : la synchronisation avance-t-elle ?#
L'API rafraîchit sa copie locale à intervalle régulier (sync_interval_seconds, 15 minutes par défaut). Une synchronisation en erreur, bloquée ou en retard de plus de deux intervalles mérite une alerte.last_sync est à l'heure du poste Acomba, sans fuseau horaire : comparez-la à l'heure locale.La copie locale, entité par entité, se lit avec GET /system/indexing/status : chaque entité active doit être ready, sans last_error.
Étape 3 : des erreurs depuis le dernier passage ?#
Le journal de l'API garde les erreurs. since (heure locale du poste) limite la lecture à ce qui est arrivé depuis le dernier passage de la sonde.Enfin, GET /system/metrics compte les appels et les erreurs de chaque opération depuis le démarrage de l'API (operations.<nom>.errors).
Le script complet#
Assemblons la sonde : elle fait les quatre vérifications, affiche une ligne par alerte, note l'heure de son passage et sort avec le code 1 s'il y a une alerte.Exemple de sortie (extrait) : un premier passage qui relève une erreur de la journée, puis un passage normal :$ python sonde.py
ExoConnect 2.6.4, API ready, en marche depuis 8.1 h
ALERTE Erreur 2026-10-11T15:28:51 uvicorn.error : Exception in ASGI application
$ echo $?
1
$ python sonde.py
ExoConnect 2.6.4, API ready, en marche depuis 8.1 h
Tout va bien.
/opt/sonde/cle.env, qui contient export EXOCONNECT_API_KEY=… et n'est lisible que par vous) :*/15 * * * * cd /opt/sonde && . ./cle.env && python3 sonde.py >> sonde.log 2>&1
Bon à savoir#
Heures de /system : last_sync et les dates de /system/sync/status et /system/indexing/status sont à l'heure du poste Acomba sans fuseau ; les entrées du journal (timestamp) portent leur décalage. Lancez la sonde dans le même fuseau que le poste, ou ajustez heure_locale.
Poste en veille : un poste mis en veille arrête la synchronisation ; l'alerte de retard est alors normale. Configurez le poste Acomba pour qu'il ne se mette pas en veille.
Après un redémarrage de l'API, les compteurs de /system/metrics repartent de zéro.
Une erreur isolée n'est pas toujours grave (une requête invalide refusée, par exemple) ; une série d'erreurs sur la même opération l'est.
La sonde ne fait que lire : elle ne relance rien. Pour redémarrer l'API, passez par le gestionnaire ExoConnect sur le poste.
Une fois par 15 minutes suffit : la synchronisation elle-même tourne aux 15 minutes.
Et voilà#
Votre intégration est surveillée : si le poste Acomba s'éteint, si la synchronisation s'arrête ou si des erreurs apparaissent, vous le savez dans les 15 minutes, avant vos clients. Modified at 2026-10-12 00:39:00
