Lire les journaux de requêtes solvethree lorsqu’une intégration échoue

1. 1.

   Ouvrez les journaux des requêtes

   Dans la console, ouvrez /request-logs. Le champ de recherche est identifié par son texte indicatif : « ID de requête, site, action ou erreur ». Recherchez l’identifiant de tâche ou de requête que vous avez enregistré ; utilisez le site ou l’action pour trouver les tentatives associées.

2. 2.

   Commencez par Toutes

   Gardez le filtre Toutes sélectionné pendant que vous recherchez la requête. Affinez ensuite les résultats avec Réussies, Échouées, En file d’attente ou Rejetées. Commencer avec un filtre plus restrictif peut masquer la tentative que vous examinez.

3. 3.

   Faites correspondre l’horodatage

   Les colonnes sont ID de requête, Site, Action, Facturation, Latence, Heure et Résultat. Faites correspondre Heure, Site et Action avec les enregistrements de votre application pour éviter d’examiner une autre tentative sur la même cible.

Comparez la Latence des lignes pertinentes pour repérer les tentatives plus lentes. Gardez à côté les mesures de durée HTTP de votre application ; ne supposez pas qu’une seule valeur de la console explique tout le délai observé par votre client.

Exporter en CSV exporte les lignes filtrées. Réglez la recherche et les filtres sur les tentatives pertinentes avant l’exportation, puis vérifiez le fichier avant de le partager.

Les filtres de la console décrivent les résultats des requêtes et des résolutions du service. Réussies ne confirme pas que le site web en aval a accepté votre jeton. Utilisez la réponse HTTP et les données de la tâche pour identifier la partie qui a échoué.

L’API a renvoyé un statut HTTP autre qu’un succès.

Lisez le statut et la réponse d’erreur enregistrés par votre client. Ne les traitez pas comme les données d’une tâche réussie.

Essayez ceci : Traitez d’abord l’erreur HTTP et corrigez le problème signalé avant de réessayer. Ne supposez pas que chaque échec signifie un crédit insuffisant. Consultez la gestion des erreurs API.

La tâche est en attente ou en cours de résolution.

Ce sont des statuts de tâche non finaux, pas des solutions utilisables.

Essayez ceci : Continuez à interroger cette tâche jusqu’à ce qu’elle soit prête ou en échec. Ne créez pas de tâche de remplacement simplement parce qu’aucune solution n’est encore disponible.

La tâche est en échec.

Lisez à la fois errorCode et error. Par exemple, site-unreachable est un code d’erreur de tâche.

Essayez ceci : Cessez d’interroger cette tâche et traitez la cause signalée avant une nouvelle tentative. Les résolutions échouées sont remboursées ; réessayer avec les mêmes entrées invalides ne les corrigera pas.

La création de la tâche a dépassé le délai et vous ignorez si elle a réussi.

Conservez tout ID de tâche ainsi que le requestId utilisé pour la tentative. Un délai de connexion dépassé ne prouve pas que la création a échoué.

Essayez ceci : Récupérez la tâche si vous avez son ID. Sinon, si vous avez fourni un requestId, renvoyez la même requête de tâche avec cet ID pour récupérer la tâche existante. Ne le réutilisez pas avec des entrées modifiées ; cela crée un conflit.

La tâche est prête, mais le site web rejette l’envoi.

Examinez la requête sortante vers le site web. Vérifiez qu’elle contient solution.token plutôt que l’ID de la tâche ou un ancien jeton.

Essayez ceci : Utilisez les valeurs userAgent et secChUa renvoyées avec le proxy ayant réussi et la cible prévue. Ne mélangez pas les identités et ne changez pas de proxy entre la résolution et l’envoi. Un HTTP 403 de la cible ne suffit pas à identifier la protection qui a rejeté la requête.

Si la cause reste incertaine, contactez [email protected] avec suffisamment d’informations pour retrouver la tentative et distinguer un échec du service d’un envoi rejeté par le site web.

• L’ID de tâche et/ou le requestId, le produit et l’horodatage avec son fuseau horaire.
• Le statut HTTP de l’API, ou les valeurs errorCode et error de la tâche à son état final.
• Le nom d’hôte cible et l’action.
• Une description expurgée de la réponse, précisant si elle provient de solvethree ou du site web cible.
• Les lignes de journal filtrées pertinentes, si elles sont utiles, vérifiées et expurgées avant l’envoi.

Retirez les clés API, mots de passe de proxy, jetons, cookies et données clients du rapport et de toutes les pièces jointes. L’assistance accepte les ID de tâche ou de requête et les horodatages expurgés ; un jeton brut n’est pas nécessaire pour identifier la tentative.