Automatizaciones y supervisión

Las automatizaciones constituyen la capa de integración de Aptli: la forma en que tu implementación reacciona a lo que ocurre en su interior y se conecta con sistemas externos. Abarca cuatro aspectos: reglas que activan acciones cuando se producen eventos, ganchos que envían eventos a otros sistemas, ingesta que recoge datos de sensores y dispositivos, y monitorización que convierte esos datos entrantes en lecturas, gráficos y alarmas.

«Automations» está incluido en todos los planes. Lo que se factura es el número de conexiones externas que configures; consulta El límite de conexiones más abajo.

Resumen de las páginas

«Automations» se encuentra en su propio grupo de navegación con cuatro páginas:

Hooks: la forma rápida de enviar eventos

Un hook es un destino firmado suscrito a los eventos que elijas. Es la integración de salida más sencilla: asígnale un Nombre, una URL de destino, los Eventos que se van a enviar, un Secreto de firma (para que el receptor pueda verificar que la carga útil procede de ti) y, opcionalmente, una Plantilla de carga útil. Cada evento que coincida se envía mediante un método POST a esa URL. Sin condiciones, sin ramificaciones; simplemente «envía estos eventos allí».

Utiliza un hook cuando otro sistema solo necesite saber que ha ocurrido algo. Recurre a un desencadenante de eventos (más abajo) cuando necesites condiciones o una acción que no sea un webhook.

Desencadenantes de eventos: reglas que hacen algo

Un desencadenador de eventos es el motor completo desencadenador → condiciones → acciones. Cuando se activa un evento y se cumplen las condiciones, se ejecutan una o más acciones. Crea uno nuevo desde la galería de recetas ¿Qué debería suceder automáticamente?, o accede al editor completo.

Desencadenantes

Los desencadenantes se agrupan según la parte de Aptli de la que proceden. Una selección:

• Trabajo — workOrder.created, workOrder.statusChanged, report.completed, report.validated, report.rejected, validation.statusChanged
• Proyectos y trabajos — project.created, project.statusChanged, job.created, job.removed
• Inventario — inventory.created, stock.adjusted, stock.transferred, stock.low
• Importaciones y versiones — geo.import.completed, geo.import.failed, version.submittedForReview, version.committed
• Usuarios, archivos y solicitudes de ayuda — user.invited, file.uploaded, file.quarantine_failed, helpRequest.created, helpRequest.statusChanged
• Datos de sensores — sensor.reading (se activa una vez por cada lote de ingesta, transportando los agregados de ese lote —el puente entre la ingesta y la automatización)
• Alarmas — alarm.raised y alarm.resolved (§293). A diferencia de sensor.reading, estas incluyen la gama completa de acciones, por lo que una infracción puede crear una orden de trabajo, actualizar un campo o notificar a alguien —no solo activar un gancho
• Programadas — schedule.daily, schedule.weekly, schedule.monthly
• Temporizadores de SLA — timer.threshold, timer.expired, timer.escalated (emitidos por temporizadores del ciclo de vida en ejecución)

Condiciones

Las condiciones delimitan cuándo se activa un disparador; se evalúan en función del contexto del evento y se combinan con el operador «Y» (todas deben cumplirse):

• workOrder.status == 'completed': solo al completarse
• actor.email endsWith '@myorg.com': solo usuarios internos
• job.featureCount > 1000: solo importaciones de gran volumen

Acciones

Cada disparador cuenta con un panel integrado de Prueba de ejecución: un botón que activa la regla en un contexto de muestra sintetizado para su disparador. Hay dos cosas que debes saber antes de utilizarlo: omite las condiciones (ejecuta las acciones directamente) y no es una simulación: las acciones salientes (webhook, Postgres, entrega de artefactos) se ejecutan de verdad en los destinos configurados, aunque aparecen marcadas con una insignia de prueba en «Entregas». Los correos electrónicos se comprueban pero no se envían, y se omiten las acciones que modifican registros (crear/actualizar). Por lo tanto, dirige la prueba a un destino seguro; sirve para confirmar la configuración, no como una vista previa sin efecto.

Ingestión: importación de datos de sensores y dispositivos

Un conector de ingesta es una fuente de datos externa que introduce lecturas en Aptli. Cada conector tiene un modo:

• Pull (sondeo programado): Aptli sondea la API REST de un proveedor en un intervalo (mínimo 30 segundos). Debes configurar la URL, una credencial y una pequeña asignación de respuesta (ruta de lecturas, clave de marca de tiempo, clave de valor, clave de métrica) para que Aptli pueda leer el JSON del proveedor.
• Push (envíos del remitente): el remitente envía lotes JSON mediante POST al propio punto final de entrada del conector (que se muestra una vez guardado el conector), autenticado con una clave de API de ingesta. No hay que realizar ninguna consulta; el dispositivo o la pasarela envía los datos según su propio horario.

En cualquier caso, cada conector especifica un ID de característica de estación (la característica del mapa a la que pertenecen las lecturas; véase Monitorización y alarmas) y una Unidad, y cada lote que ingiere activa el disparador sensor.reading. La pestaña Ingestión también muestra una vista en tiempo real de las consultas programadas (cuántas están activas, retrasadas o han fallado).

Credenciales, claves y límite de conexiones

Credenciales de salida

Las acciones de salida que llegan a un sistema externo (webhooks, Postgres, entrega de artefactos a S3/SFTP) se autentican mediante una credencial almacenada en lugar de secretos en línea. Crea una una sola vez en la página Credenciales y haz referencia a ella por su nombre. Los secretos se cifran en reposo y nunca se vuelven a mostrar tras guardarlos; la configuración no secreta (URL base, nombres de host, regiones) sigue siendo legible. Tipos: bearer / basic / clave API para HTTP, S3, SFTP y Postgres.

Claves de ingesta entrante

Claves «bearer» de máquina que permiten a un remitente enviar datos a Aptli. Son solo para ingesta, con un ámbito limitado a lo que se les permite hacer (enviar lecturas o extraer envíos del portal), y la clave sin cifrar se muestra una sola vez al crearla; cópiala en ese momento.

El límite de conexiones

El contador comercial corresponde al número de conexiones externas, no a la función en sí. Cada conector de ingesta, clave API y gancho de salida reutilizable consume una unidad de un fondo común compartido (las reglas internas de activación por eventos no se contabilizan). Un indicador en las páginas de Automatizaciones y Credenciales muestra «{utilizados} de {total} conectores/claves» con un desglose de conectores, claves API y hooks. El límite predeterminado es 3; cuando se alcanza este límite, al crear otro se te pedirá que revokes uno que no estés utilizando o que te pongas en contacto con el servicio de asistencia para añadir más. Las conexiones que ya tengas seguirán funcionando aunque el límite se reduzca posteriormente.

Supervisión y alarmas

La ingesta recibe los datos de los sensores; la supervisión es lo que ves y sobre lo que se te avisa.

Estaciones y lecturas

Una estación es simplemente un elemento cartográfico sobre el que informa un sensor. Por defecto, el ID de elemento de la estación de un conector es el propio ID del elemento, por lo que las lecturas se asocian directamente a él; los emisores que utilizan sus propios códigos de estación pueden vincularse de forma explícita.

Una vez que las lecturas empiezan a llegar, el registro del elemento se amplía con una sección de Lecturas del sensor: para cada métrica, el valor más reciente y la unidad, además de una gráfica de tendencia de 7 días. Si una estación deja de enviar datos pero su fuente sigue enviando bajo otros identificadores (se ha cambiado el nombre de un sensor en la fuente), Aptli lo señala y ofrece una opción de Volver a vincular con un solo clic para que no pierdas el historial.

Alarmas

Las reglas de alarma se definen en el conector de ingesta. Activa Generar alarmas y configura:

• Alarma cuando el valor sea — superior o inferior a un umbral
• Margen de anulación: cuánto debe alejarse una lectura del umbral antes de que la alarma se anule automáticamente (histéresis, para que un valor que oscila en torno al umbral no active la alarma constantemente)
• Silenciar la alarma tras (minutos): activa una alarma de silenciamiento si no llegan datos durante ese tiempo (detección de sensor inactivo)
• Destinatarios de la alarma: a quién se notifica
• Escalar si no se confirma tras (minutos) + Destinatarios de la escalación: un segundo nivel si nadie confirma a tiempo

La página Alarmas es el registro en tiempo real. Cada alarma puede estar Activa, Confirmada o Resuelta; se confirma para indicar que alguien se está ocupando de ella y se resuelve cuando se ha solucionado (las alarmas también se borran automáticamente cuando la lectura se recupera y supera el margen de seguridad). Las alarmas de umbral y las de silencio («no se han recibido datos») se muestran de forma diferenciada, y cada alarma incluye su valor, umbral y pico, quién la ha confirmado y —si se ha escalado— una línea «Escalada {fecha}» con un indicador de estado de entrega. Una ficha del panel de control principal muestra las alarmas activas para que no pasen desapercibidas. La página de Alarmas es visible para cualquier supervisor que haya iniciado sesión, no solo para los administradores de automatizaciones, de modo que las personas que supervisan el trabajo puedan ver las alarmas.

Ciclo bidireccional de tickets

Un hook puede incluir una URL de respuesta con cada alarma: tu sistema externo de gestión de tickets envía los cambios de estado mediante un POST para confirmar o resolver la alarma, y la referencia del ticket aparece en la alarma como un enlace. Esto cierra el ciclo cuando las alarmas se gestionan en otra herramienta.

Resultados y enlaces para compartir

En un proyecto, la pestaña Resultados representa gráficamente las series de métricas supervisadas en relación con los hitos de trabajo completado —véase Proyectos. Puedes publicar un enlace para compartir de solo lectura y tokenizado de esos gráficos para personas externas, y revocarlo en cualquier momento. Las lecturas se muestran a modo de contexto junto con las fechas de trabajo; Aptli no establece ninguna relación causal y la página no contiene, de forma explícita, datos de medición certificados.

Entregas: el registro de actividad

La página Entregas es un historial de solo lectura, dividido en dos pestañas:

• Entregas salientes: una fila por cada intento de entrega saliente: fecha, flujo de trabajo, acción, destino, resultado (Éxito / Fallo / Reintentando / Mensaje perdido), número de intentos, duración y cualquier error. Las ejecuciones de prueba se identifican con una insignia.
• Ejecuciones entrantes: el historial de ingesta: origen, resultado, fecha, duración, filas y error.

Conexión rápida

Para integraciones habituales, el asistente de Conexión rápida te guía a través de una receta en lugar de utilizar el editor sin formato; por ejemplo: «Enviar nuevos envíos del portal a mi sistema», «Avisar a mi sistema cuando las existencias se estén agotando», «Crear un ticket cuando se active una alarma» o «Recibir lecturas de mis sensores o pasarela». Se encarga de configurar el conector, el hook o la regla por ti.

Permisos

Las automatizaciones no utilizan la matriz global de derechos de administrador. Las tres páginas de configuración (Automatizaciones, Credenciales, Entregas) están restringidas por una lista de permitidos de visores/modificadores en la configuración de las automatizaciones, por lo que el acceso se concede de forma explícita. La página Alarmas está abierta intencionadamente a cualquier usuario que haya iniciado sesión: supervisar las alarmas es una tarea de operaciones, no de configuración. Los titulares del derecho de configuración de la aplicación siempre disponen de una vía de recuperación si las listas están vacías.