Targets

Un target es generalmente un endpoint que sirve como destino para los events generados por un publisher. Un target puede recibir múltiples events del mismo o de diferentes publishers.

Aquí tienes un par de ejemplos de target:

• En aplicaciones de pago basadas en UPI, events como intentos de pago inválidos, actividades inusuales de cuenta y anomalías en patrones de transacción se entregan inmediatamente al software de detección de fraude. Aquí, los datos del event se comparten a un endpoint de webhook (target) que ayuda al software de detección de fraude a actuar en consecuencia.

• En aplicaciones de redes sociales, events relacionados con campañas publicitarias, publicaciones patrocinadas y actividades promocionales se entregan al software de marketing para evaluar el rendimiento de las campañas y optimizar estrategias. En este escenario, los datos del event se comparten a Catalyst Circuits (target) que ayuda al software de marketing a procesar y actuar sin intervención humana.

Aspectos Clave

Los Targets son responsables de procesar los events entrantes según reglas y filtros predefinidos dentro de ellos. Este procesamiento en Signals puede involucrar acciones como extracción y transformación de datos, despacho y activación de un proceso posterior.

Tipos de Target

La plataforma admite los siguientes tipos de targets, que activan procesos posteriores dentro de ellos:

• Los Webhooks son callbacks HTTP que te ayudan a compartir datos en tiempo real entre aplicaciones. Se usan comúnmente para integración basada en events entre sistemas.

• Las Functions se configuran para ejecutarse en respuesta a events recibidos. Consisten en fragmentos de código escritos en los lenguajes de programación Java, Node.js y Python para realizar tareas específicas o ejecutar lógica de negocio en targets.

• Los Circuits automatizan procesos basados en events entrantes usando flujos de trabajo predefinidos. Te permiten diseñar flujos de trabajo complejos basados en events sin necesidad de codificación.

Un único webhook/function/circuit se puede usar múltiples veces en un Proyecto de Catalyst en diferentes configuraciones de nombre de target con variaciones en la política de despacho, política de reintentos o configuración del cuerpo.

Tiempos de Espera del Despacho de Events

Cuando un event se despacha a un target, Signals espera un período especificado para que el target responda. Si el target no responde dentro de este plazo, el event se marca como Failed.

Los siguientes son los intervalos de tiempo para cada tipo de target:

Dispatch Policy

Catalyst Signals ofrece flexibilidad para recibir events individualmente en una cola o colectivamente como un lote. También puedes personalizar cada uno de estos tipos.

• Instant - Los events se reciben instantáneamente cada vez que ocurren en el sistema del publisher. Puedes establecer un período de Time To Live personalizado para que los events permanezcan en Signals antes de enviarlos al target.

• Batch - Los events se entregan colectivamente según varios métodos y frecuencias de despacho. El período de Time To Live para events despachados usando este método se establece en 24 horas de forma predeterminada y no se puede cambiar.

Obtén más información sobre los tipos en la Dispatch Policy.

Retry Policy

Cada vez que un event no logra comunicarse con el target, Signals permite hasta 20 intentos de reintento para que ese event específico llegue al target. Estos reintentos ocurren automáticamente, y puedes personalizar los conteos de reintentos o su frecuencia según tus casos de uso.

• Auto - En el modo de frecuencia automática, el primer intento de reintento ocurre un minuto después del event fallido. Si el primer reintento también fue un fallo, los reintentos posteriores siguen un patrón de intervalo exponencial basado en el tiempo del fallo anterior.

Por ejemplo, si un event no logra llegar al target, el primer reintento ocurre un minuto después del fallo. Si este reintento falla, cada reintento siguiente ocurrirá en intervalos que duplican el tiempo anterior, hasta 10 minutos.

Los intervalos serán los siguientes: segundo reintento - 2 minutos, tercer reintento - 4 minutos, cuarto reintento - 8 minutos, quinto y reintentos posteriores - 10 minutos. Este patrón continúa hasta que el event llegue al target o se alcance el conteo de reintentos configurado.

• Manual - En este modo, puedes establecer manualmente el intervalo de frecuencia para los intentos de reintento. Puedes configurarlo en términos de horas o minutos según tu requerimiento. Esta frecuencia debe ser compatible con el período de Time To Live de los events y no debe excederlo. La frecuencia manual se puede configurar entre un minuto y una hora.

Placeholders

Los placeholders juegan un papel crucial en la definición de los headers o parámetros del webhook asociado con este target. El campo solo es visible cuando has usado valores dinámicos para los headers y parámetros en un webhook y lo has asociado a este target. Para valores estáticos, puedes agregar directamente tus valores según tus casos de uso. Sin embargo, para valores dinámicos, debes especificar el JSON path de la clave en el event schema.

Event Transformation

Los Event Schemas se generan automáticamente junto con los events y se emiten a Signals. En la página de Targets de Rules, puedes personalizar los schemas antes de entregarlos a los targets. Puedes compartir todo el payload al target o realizar extracción y transformación para adaptarlo a tus requerimientos de negocio.

• Extraction - Esta acción te permite recuperar una clave específica del event schema existente y construir un nuevo schema solo con esa propiedad. Esto filtra los detalles innecesarios para tus flujos de trabajo configurados y comparte solo los datos del event optimizados a los targets.

• Transformation - Esto te permite modificar los nombres de claves y valores dentro del event schema para alinearlo con tu formato deseado. Proporciona compatibilidad con tus flujos de trabajo o procesos posteriores en el entorno del target.

Guía paso a paso para extraer y transformar un event schema