Open Office Hours Saison 1 : Session 8 - Logs & Runs : votre boîte à outils de dépannage
Comment utiliser les logs et les runs dans MyRapidi pour dépanner votre intégration
Lorsque votre intégration renvoie une erreur, la première question est toujours la même : où chercher ? Dans MyRapidi, les logs et les runs vous donnent la réponse. Ils montrent précisément ce qui s’est passé, quel transfert en est à l’origine, combien de temps il a duré et ce que dit le message d’erreur. Une fois que vous savez les lire, le dépannage devient beaucoup plus rapide.
Cet article explique ce que sont les runs et les logs, comment ils fonctionnent ensemble et comment vous en servir pour diagnostiquer et corriger les problèmes de votre intégration.
En bref
Regarder la session complète
Cet article s’appuie sur la session 8 du programme de formation Open Office Hours de Rapidi. La session complète comprend une démonstration en direct des runs et des logs dans MyRapidi, un exemple réel de message d’erreur et une démo d’Albert en action.
Diapositives de la présentation
Qu’est-ce qu’un run ?
Un run est un événement d’exécution unique. Chaque fois qu’une planification se déclenche ou que vous exécutez un transfert manuellement, MyRapidi crée un enregistrement de run qui regroupe tout ce qui s’est passé à ce moment-là.
Par exemple, si une planification s’exécute toutes les heures, vous verrez une entrée de run par heure. Chaque entrée indique la date et l’heure, les systèmes source et de destination, la description (nom de la planification ou du transfert), la durée et une icône de statut.
Les icônes de statut vous renseignent d’un coup d’œil :
- Coche verte : le run s’est terminé sans problème
- Icône rouge : quelque chose a échoué et demande votre attention
- Jaune (en cours de traitement) : le transfert est toujours en cours d’exécution
Les runs distinguent aussi deux types d’exécution. Un « S » à côté d’un run signifie qu’il a été déclenché par le planificateur. Un « M » signifie qu’il a été lancé manuellement, par exemple après la modification d’un mapping ou pour tester quelque chose.
Vous accédez à la page des runs directement via Logs > Runs, ou depuis la page Schedules en cliquant sur l’icône des runs à côté d’une planification donnée. La seconde option est pratique lorsque vous voulez voir les runs d’une seule planification.
À quoi servent les runs ?
Les runs remplissent quatre fonctions principales :
- Suivre les exécutions. Visualisez chaque run dans l’ordre chronologique, avec la date, l’heure, la source et la destination. Vous obtenez ainsi une vue complète de ce qui s’est exécuté et à quel moment.
- Repérer rapidement les erreurs. Les icônes de statut signalent immédiatement les runs en échec. Vous pouvez aussi filtrer pour n’afficher que les runs en erreur et ignorer tout ce qui s’est déroulé sans problème.
- Mesurer la durée. Chaque run indique combien de temps il a pris. Si un transfert qui dure normalement 2 minutes en prend soudain 15, c’est un signal qui mérite d’être examiné. C’est là que les champs datetime et les filtres de vos transferts font la différence, car ils déterminent la quantité de données récupérée à chaque run.
- Accéder directement aux entrées de log. Depuis n’importe quel run, vous pouvez déplier l’enregistrement et voir la liste complète des entrées de log qui lui appartiennent. C’est le moyen le plus rapide de comprendre ce qui s’est réellement passé.
Que sont les logs ?
Une entrée de log est un enregistrement détaillé de ce qui s’est passé pendant le run d’un transfert. Considérez le run comme le parent et les entrées de log comme le détail qu’il contient.
Chaque entrée de log vous indique le nom du transfert, les systèmes source et de destination, le nombre d’enregistrements lus, insérés, mis à jour et supprimés, ainsi que les éventuels messages d’erreur. Si une planification comprend cinq transferts, vous verrez cinq entrées de log dans un seul run.
Les logs servent à :
- Diagnostiquer les erreurs : les entrées en rouge et les indicateurs d’erreur montrent exactement où quelque chose s’est mal passé et quel système a renvoyé l’erreur.
- Contrôler le nombre d’enregistrements : vous pouvez vérifier combien d’enregistrements ont été traités et si les chiffres correspondent à ce que vous attendiez.
- Filtrer et rechercher : filtrez par transfert, planification, plage de dates, connexion ou statut d’erreur pour trouver exactement ce qu’il vous faut sans faire défiler des pages d’entrées.
- Retracer un run complet : suivez un run à travers toutes ses entrées de log pour reconstituer l’ensemble de ce qui s’est passé, et dans quel ordre.
Comment trouver et diagnostiquer les erreurs
Lorsque quelque chose échoue, voici la marche à suivre :
-
Ouvrez Runs. Repérez l’icône d’erreur rouge. Vous pouvez aussi utiliser le filtre de statut d’erreur pour n’afficher que les runs en échec.
-
Dépliez le run. Cliquez sur la flèche pour le déplier. Vous verrez toutes les entrées de log de cette exécution, regroupées par transfert. Celle qui contient l’erreur est surlignée en rouge.
-
Lisez le message d’erreur. Chaque entrée affiche le code d’erreur et sa description. Certains systèmes renvoient un message long et détaillé qui désigne directement l’enregistrement. D’autres se contentent d’un message court et obscur. Dans les deux cas, le log indique aussi quelle connexion a renvoyé l’erreur, pour que vous sachiez s’il faut regarder du côté du système source ou du système de destination.
-
Demandez à Albert. Si le message d’erreur n’est pas clair, cliquez sur l’icône en forme de personnage à droite de l’entrée de log. Une conversation s’ouvre avec Albert, l’assistant IA de Rapidi, avec le message d’erreur déjà chargé. Albert est connecté au wiki Rapidi et peut vous suggérer ce que signifie l’erreur et ce qu’il faut vérifier ensuite.
Si Albert ne vous donne pas de réponse claire, faites une recherche directement dans le wiki Rapidi avec des mots-clés tirés du message d’erreur. Si vous ne parvenez toujours pas à résoudre le problème, contactez le support.
Bon à savoir : le message d’erreur du log provient du système de destination, et non de Rapidi lui-même. Si vous envoyez des données de Business Central vers Salesforce et que quelque chose échoue, l’erreur que vous voyez est celle que Salesforce a renvoyée. Cela vous indique où concentrer votre attention.
La formule Message : ajouter du contexte à vos logs
Certains messages d’erreur n’indiquent pas quel enregistrement précis a causé le problème. Dans ce cas, la formule Message peut vous aider.
La formule Message est un paramètre que vous ajoutez à un transfert. Elle indique à MyRapidi d’inclure la valeur d’un champ donné dans la sortie du log. Par exemple, si vous transférez des clients, vous pouvez ajouter le champ du numéro de client à la formule. À chaque exécution de ce transfert, le log affichera alors le numéro de client à côté de chaque enregistrement, ce qui permet de repérer beaucoup plus facilement l’enregistrement qui pose problème.
Vous pouvez ajouter plusieurs champs à la formule si vous avez besoin de plus de contexte. C’est particulièrement utile pour les transferts dont les messages d’erreur du système connecté sont vagues.
Filtrer les runs et les logs
La page des runs et la page des logs proposent les mêmes filtres. Vous pouvez filtrer par :
- Plage de dates et d’heures
- Planification
- Groupe
- Transfert
- Connexion source ou de destination
- Statut (terminé ou en erreur)
- Recherche par mot-clé
Si vous allez sur la page Schedules et cliquez sur l’icône des runs d’une planification donnée, la page des runs s’ouvre avec cette planification déjà filtrée. Vous pouvez ensuite ajouter d’autres filtres pour affiner encore les résultats.
Regardez toutes les sessions et inscrivez-vous aux prochaines : rapidionline.com/resources/open-office-hours
Open Office Hours
Chaque semaine, nos spécialistes de l’intégration animent une session de formation gratuite de 30 minutes sur un thème précis de MyRapidi.
Consultez le programme complet de la saison 1 : rapidionline.com/product-updates/open-office-hours-season-1
Questions fréquentes
Mon message d’erreur est très court et n’explique pas ce qui s’est passé. Que dois-je faire ?
Les messages d’erreur obscurs sont fréquents, et leur origine dépend du système. Certains ERP et CRM renvoient des codes très brefs, sans beaucoup de contexte. Le moyen le plus rapide d’y remédier est de cliquer sur l’icône Albert à droite de l’entrée de log. Albert ouvre une conversation avec l’erreur déjà chargée et peut vous suggérer ce qu’elle signifie et ce qu’il faut vérifier. Si cela ne suffit pas, copiez le message d’erreur et recherchez-le dans le wiki Rapidi. En dernier recours, contactez le support en lui transmettant l’entrée de log complète.
Comment savoir si les erreurs proviennent du système source ou du système de destination ?
Chaque entrée de log affiche un libellé « error on connection » qui vous indique exactement quel système a renvoyé l’erreur. Si vous envoyez des données de Business Central vers Salesforce et que Salesforce rejette un enregistrement, le log indiquera que l’erreur provient de la connexion Salesforce. Vous savez ainsi où chercher. Si l’erreur vient de la source, l’enregistrement n’existe probablement pas ou pose problème au moment de la lecture. Si elle vient de la destination, le système récepteur n’a pas accepté les données, ce qui renvoie généralement à une règle de validation de champ, à un champ obligatoire manquant ou à un format de données incompatible.
Des erreurs se produisent, mais personne ne les remarque avant qu’un problème n’apparaisse en aval. Comment les détecter plus tôt ?
C’est l’un des problèmes d’intégration les plus courants. Dans MyRapidi, la page des runs affiche une icône de statut rouge chaque fois qu’un transfert échoue, la première étape consiste donc à la consulter régulièrement. Prendre l’habitude de passer les runs en revue au début de chaque journée prend moins d’une minute. Vous pouvez aussi utiliser le filtre de statut d’erreur pour n’afficher que les runs en échec, sans avoir à tout faire défiler. Pour les équipes qui utilisent Continue on Error, les erreurs de données sont stockées séparément sous Logs > Data Errors et n’apparaissent pas dans le statut principal du run, si bien que cette page demande sa propre vérification régulière. Des notifications par e-mail pour les erreurs de données sont également disponibles — contactez le support Rapidi pour les faire configurer sur votre service.
Les mêmes enregistrements échouent à chaque run. Pourquoi l’erreur ne disparaît-elle pas après que j’ai consulté le log ?
Consulter une entrée de log ne corrige pas le problème sous-jacent. Si les mêmes enregistrements échouent à répétition, le problème se situe dans les données elles-mêmes ou dans la configuration du système, pas dans le log. Parmi les causes fréquentes figurent un champ obligatoire du système de destination qui est vide dans la source, un format de données qui ne correspond pas à ce qu’attend le système récepteur, ou une règle de validation du système de destination que l’enregistrement ne respecte pas. Utilisez la description de l’erreur dans le log et la formule Message (si elle est configurée) pour identifier l’enregistrement concerné, puis corrigez-le dans le système source ou de destination. Si l’erreur touche systématiquement de nombreux enregistrements, vérifiez les mappings de champs dans la configuration du transfert.
Mes transferts prennent beaucoup plus de temps que d’habitude. Par où commencer le dépannage ?
Commencez par la page des runs et regardez la colonne de durée. Comparez les runs récents aux plus anciens pour voir quand le ralentissement a commencé. La cause la plus fréquente de lenteur est un filtre datetime qui récupère trop de données sur le transfert, soit parce qu’il est mal configuré, soit parce que quelqu’un l’a modifié. Vérifiez que vos transferts utilisent correctement les champs datetime, afin que seuls les enregistrements nouveaux ou mis à jour soient récupérés à chaque run, et non l’ensemble des données. Si la durée semble normale mais que la planification dans son ensemble est plus lente, vérifiez si un autre transfert de la même planification constitue le goulot d’étranglement, en dépliant le run et en comparant la durée de chaque transfert.