Cet article décrit comment le serveur autogéré exécute les automatisations de webhook.
Exécution
Lorsque vous configurez un webhook, ActivityInfo enverra une notification à l'URL que vous avez spécifiée chaque fois qu'un enregistrement est modifié (créé, mis à jour ou supprimé) et qu'il correspond au déclencheur de votre automatisation.
Lorsqu'un webhook est déclenché, notre serveur envoie les données à votre URL et attend une réponse pendant un maximum de 15 secondes.
Succès : Si votre serveur répond avec un statut de succès (n'importe quel code
2xx, comme200 OK) dans ce délai, le processus est marqué comme terminé. Tout message d'erreur précédent stocké pour cette automatisation sera effacé.Échec : La tentative est considérée comme un échec si votre serveur :
Met plus de 15 secondes à répondre (un délai d'attente).
Renvoie un statut d'erreur (comme
404 Not Foundou500 Server Error).Est inaccessible (par exemple, une défaillance DNS ou une connexion refusée).
Répond avec une redirection (voir ci-dessous).
Les redirections ne sont pas suivies
Veuillez noter : ActivityInfo ne suit pas les redirections lors de l'envoi de webhooks.
Si votre serveur répond avec un statut de redirection (comme 301, 302 ou 307), cela sera traité comme un échec, même si le nouvel Emplacement (Location) est valide. Cela déclenchera le processus de nouvelle tentative décrit ci-dessus.
Veuillez vous assurer que votre URL de webhook est le point de terminaison final et direct et ne nécessite pas de redirection.
Processus de nouvelle tentative
Si la première tentative échoue, le système n'abandonnera pas immédiatement. Il essaiera à nouveau trois fois de plus, pour un total de quatre tentatives.
La période d'attente entre les tentatives augmente, donnant à votre serveur le temps de récupérer :
- 1er échec : Attente de 10 secondes avant la 2ème tentative.
- 2ème échec : Attente de 30 secondes avant la 3ème tentative.
- 3ème échec : Attente de 90 secondes avant la 4ème (et dernière) tentative.
- 4ème échec : Si la dernière tentative échoue, le système abandonne et n'essaiera plus.
Ce qui est journalisé
ActivityInfo gardera une trace de la dernière erreur, qui est affichée dans l'interface utilisateur.
- En cas de Succès : Tout message d'erreur précédent stocké pour cette automatisation est effacé.
- En cas d'échec (par ex., Erreur 404) : Si votre serveur répond avec une erreur, le code de réponse et le message sont enregistrés (par ex.,
404,Not Found). - En cas d'échec (par ex., Délai d'attente) : Si une exception se produit (comme un délai d'attente de 15 secondes), le message de l'exception est enregistré.
Des informations plus détaillées, y compris les erreurs qui sont ensuite résolues lors d'une nouvelle tentative, sont journalisées dans les journaux système.
- Webhook réussi : Un message est journalisé pour chaque tentative réussie, y compris le code de retour (par ex.,
Automation: [My Webhook] -> hook successful with return code: 200). - Requête de webhook : Un journal est créé pour chaque tentative, montrant l'URL et le code de résultat (par ex.,
Automation: Webhook request to https://example.com/hook result code is 404). - Webhook échoué (Erreur serveur) : Journalise lorsqu'une connexion échoue en raison d'une erreur serveur (par ex.,
http connection failure while sending webhook: 404,Not Found). - Webhook échoué (Exception) : Journalise lorsqu'une connexion échoue en raison d'une exception (par ex.,
exception occurred while sending webhook: java.net.SocketTimeoutException: Read timed out). - Erreurs internes : Des erreurs graves sont journalisées si l'ensemble du processus d'automatisation échoue de manière inattendue.
Les journaux système se trouvent dans le répertoire de données d'ActivityInfo, généralement /opt/activityinfo/logs sur les plateformes Unix, ou C:\ActivityInfoData\logs sur Windows Server.
Lors du déploiement d'ActivityInfo en tant qu'image Docker, vous pouvez accéder aux journaux système en utilisant la commande suivante :
docker logs <container_name_or_id>