Webhooks en el servidor autogestionado

Este artículo describe cómo el servidor autogestionado ejecuta las automatizaciones de webhook.

Ejecución

Cuando configura un webhook, ActivityInfo enviará una notificación a la URL que especificó cada vez que un registro sea modificado (creado, actualizado o eliminado) y que coincida con el desencadenador de su automatización.

Cuando se activa un webhook, nuestro servidor envía los datos a su URL y espera un máximo de 15 segundos por una respuesta.

• Éxito: Si su servidor responde con un estado de éxito (cualquier código 2xx, como 200 OK) dentro de este tiempo, el proceso se marca como completado. Cualquier mensaje de error anterior almacenado para esta automatización será eliminado.

• Fallo: El intento se considera un fallo si su servidor:

• Tarda más de 15 segundos en responder (tiempo de espera agotado).

• Devuelve un estado de error (como 404 No Encontrado o 500 Error del Servidor).

• Es inalcanzable (p. ej., un fallo de DNS o conexión rechazada).

• Responde con una redirección (ver más abajo).

Las redirecciones no se siguen

Tenga en cuenta: ActivityInfo no sigue las redirecciones al enviar webhooks.

Si su servidor responde con un estado de redirección (como 301, 302 o 307), se tratará como un fallo, incluso si la nueva Ubicación es válida. Esto activará el proceso de reintento descrito anteriormente.

Por favor, asegúrese de que su URL de webhook sea el punto final, directo y no requiera una redirección.

Proceso de reintento

Si el primer intento falla, el sistema no se rendirá inmediatamente. Lo intentará de nuevo tres veces más, para un total de cuatro intentos.

El período de espera entre reintentos aumenta, dándole tiempo a su servidor para recuperarse:

• 1er Fallo: Espera 10 segundos antes del 2º intento.
• 2º Fallo: Espera 30 segundos antes del 3er intento.
• 3er Fallo: Espera 90 segundos antes del 4º (y último) intento.
• 4º Fallo: Si el último intento falla, el sistema se rinde y no lo intentará de nuevo.

Qué se registra

ActivityInfo hará un seguimiento del último error, que se muestra en la interfaz de usuario.

• En caso de Éxito: Cualquier mensaje de error anterior guardado para esta automatización es eliminado.
• En caso de Fallo (p. ej., Error 404): Si su servidor responde con un error, el código de respuesta y el mensaje se guardan (p. ej., 404,No Encontrado ).
• En caso de Fallo (p. ej., Tiempo de espera agotado): Si ocurre una excepción (como un tiempo de espera agotado de 15 segundos), el mensaje de la excepción se guarda.

Información más detallada, incluyendo errores que se resuelven posteriormente en un reintento, se registra en los registros del sistema.

• Webhook Exitoso: Se registra un mensaje por cada intento exitoso, incluyendo el código de retorno (p. ej., Automatización: [Mi Webhook] -> hook exitoso con código de retorno: 200).
• Solicitud de Webhook: Se crea un registro para cada intento, mostrando la URL y el código de resultado (p. ej., Automatización: Solicitud de webhook a https://example.com/hook el código de resultado es 404).
• Webhook Fallido (Error del Servidor): Registra cuando una conexión falla debido a un error del servidor (p. ej., fallo de conexión http al enviar webhook: 404,No Encontrado).
• Webhook Fallido (Excepción): Registra cuando una conexión falla debido a una excepción (p. ej., excepción ocurrida al enviar webhook: java.net.SocketTimeoutException: Read timed out).
• Errores Internos: Se registran errores graves si todo el proceso de automatización falla inesperadamente.

Los registros del sistema se pueden encontrar en el directorio de datos de ActivityInfo, generalmente en /opt/activityinfo/logs en plataformas Unix, o en C:\ActivityInfoData\logs en Windows Server.

Al desplegar ActivityInfo como una imagen de Docker, puede acceder a los registros del sistema utilizando el siguiente comando:

docker logs <container_name_or_id>