15. Saltar a contenido

15. Notificaciones a sistemas de terceros

Trak.e considera una serie de eventos cuando se crean, modifican y borran ciertos recursos:

Recurso Create Update Delete
Legajo x x x
Documento x x x
Alertas x x x
Transacción x x x

Trake se puede configurar para que se invoque un endpoint ante cada uno de estos eventos (el mismo endpoint o uno específico para cada uno indistintamente).

Trake maneja un esquema de reintentos con backoff exponencial y penaliza aquellos endpoints con tiempos de respuesta altos o alta tasa de fallos. Las notificaciones comienzan en la cola de baja latencia y van siendo degradado hasta la cola de alta latencia.

  • Baja latencia y alta prioridad: tiene un timeout de 2s en la invocación del endpoint y 2 reintentos. El objetivo es notificar rápidamente al cliente de nuevos eventos.
  • Media latencia y media prioridad : tiene un timeout de 10s en la invocación del endpoint y 8 reintentos.
  • Alta latencia y baja prioridad: tiene un timeout de 30s en la invocación del endpoint y 16 reintentos. Para aquellos clientes que no tienen capacidad de procesar rápidamente los eventos de Trake.

Este esquema nos permite notificar rápidamente eventos a aquellos clientes con capacidad de procesamiento y no penalizar a estos con clientes que tengan problemas en sus endpoints al mismo tiempo de evitar la pérdida de notificaciones por el mal funcionamiento esporádico de un endpoint del cliente. Cuando se agotan todos los reintentos, las notificaciones son volcadas a una cola de deadletter y bajadas a una base temporal que puede ser consumida vía la API de notificaciones para tal fin.

graph TD
    high_priority -- error + retry --> high_priority
    high_priority -- error + 2 retries exhausted --> medium_priority
    medium_priority -- error + retry --> medium_priority
    medium_priority -- error + 8 retries exhausted --> low_priority
    low_priority -- error + retry --> low_priority
    low_priority -- error + 16 retries exhausted --> deadletter

El servicio de notificaciones maneja distintos tipos de seguridad:

  • No Auth: pensado para pruebas e integración.
  • Basic Auth: permite configurar user y password que serán enviados en cada invocación.
  • Oauth 2 Client Credentials Flow: permite configurar client_id, client_secret y el scope requerido. El servicio de notificaciones se encarga del flujo de oauth2 y obtención y uso del token.
  • Api Key: permite configura la key de acceso a la api. La key será enviada en el default header X-Api-Key.

15.1 Recursos

Recurso
notification_error
notification_config

API