Encargo directo
La llamada lleva el texto de la alerta y el plan que debe ejecutarse: pasos, canales, destinatarios, reintentos, esperas y vueltas.
Integraciones
Formas de conectar Nura Alertas
Un sistema puede encargar alertas llamando a la API, o mediante un conector desarrollado por Applinet cuando ese sistema no puede modificarse. Son dos vías distintas, con condiciones distintas.
Vía principal
El sistema de origen llama a la API
Es la forma estándar de conectar. La aplicación que detecta la incidencia encarga la alerta y sigue con lo suyo.
Lanzamiento de perfil
La llamada lleva solo el código de un perfil ya configurado y el texto. El plan y los destinatarios se resuelven en Nura Alertas.
Consulta de estado
Devuelve en qué punto está la alerta y los intentos realizados con su resultado.
Desactivación
Detiene los envíos futuros de esa alerta. Es idempotente: repetirla no produce efectos adicionales ni errores.
Retorno
Nura Alertas informa al sistema de origen
Si el encargo incluye una dirección de retorno, los eventos relevantes se notifican allí sin necesidad de consultar.
Qué se notifica
Los intentos realizados y los cambios de estado de la alerta, con la información de canal, fecha, resultado y evidencia disponible.
Reintentos independientes
El envío de un callback tiene su propio ciclo de reintentos y su propio registro. Si el receptor falla, la alerta sigue su curso con normalidad.
Cuándo no hace falta
Si el sistema receptor no puede exponer un endpoint accesible, el estado se consulta por API cuando convenga.
Control de acceso
Cada integración, con lo justo
Descrito a alto nivel. El detalle operativo está en la guía para integradores.
Una credencial por integración
Cada sistema conectado usa la suya, con su propio token. Así se puede revocar o ajustar una sin afectar al resto.
Permisos por método
Los métodos se habilitan uno a uno. Lo que no está habilitado queda denegado, y el intento denegado queda registrado.
Zona de pruebas por credencial
El integrador se acredita con su credencial y ve exactamente los métodos permitidos, con la posibilidad de ejecutarlos contra la propia API.
Canales
Por dónde salen los avisos
Los canales los aporta la plataforma y se asignan al ámbito de cada cliente. No hay que administrar las credenciales de cada proveedor.
Correo electrónico
Envío por SMTP con remitente visible configurable.
Incluido en todos los planes.
Telegram
Mensajes mediante el bot de la plataforma, con vinculación del destinatario por enlace o por identificador.
Incluido en todos los planes.
Notificaciones push
Envío mediante Firebase Cloud Messaging hacia la aplicación receptora, es decir, la aplicación del cliente que lo integra.
Incluido en todos los planes.
Disponible a partir del plan Pro.
Sujeto a contratación y consumo adicionales, y a las condiciones del proveedor.
Llamadas de voz
Disponible en el plan Pro+.
Sujeto a contratación y consumo adicionales.
Distinción importante
Un canal es por dónde sale el aviso; un conector es de dónde viene
- Canal de comunicación
- El medio por el que Nura Alertas contacta con el destinatario: correo, Telegram, push, WhatsApp o llamada. Forma parte del producto y se asigna al ámbito del cliente.
- Conector personalizado
- La pieza que hace que un sistema concreto encargue alertas. No forma parte del producto: es un desarrollo de Applinet que se valora y presupuesta caso por caso.
- Por qué importa
- Tener un canal incluido no significa tener un conector hacia un sistema. Y contratar un conector no cambia qué canales están incluidos en el plan.
Desarrollo adicional
Cuando el origen no puede llamar a la API
Applinet desarrolla la pieza que lee el sistema de origen y encarga la alerta. Cada conector se estudia, se valora y se presupuesta aparte. Ninguno viene incluido en un plan.
Base de datos
Consulta periódica de una tabla, una vista o una consulta que ya marca las situaciones a avisar.
Buzón de correo
Lectura de un buzón donde otros sistemas ya dejan sus avisos, para convertirlos en alertas con plan propio.
Helpdesk por API
Conexión con una herramienta de tickets para avisar según su estado, prioridad o antigüedad.
ERP
Lectura de eventos de negocio del sistema de gestión: incidencias, bloqueos, pedidos detenidos o validaciones pendientes.
Transporte
Conexión con plataformas de flota, rutas o expediciones para avisar de desviaciones e incidencias.
Monitorización
Recepción de avisos de herramientas de supervisión de sistemas, red o infraestructura.
Sensores
Lectura de umbrales de temperatura, presión, humedad u otras magnitudes desde el equipamiento que ya los mide.
Archivos y procesos
Vigilancia de directorios, ficheros de intercambio o procesos programados que dejan constancia de un fallo.
Proceso orientativo
De la primera conversación a la puesta en marcha
Recorrido orientativo. El alcance y los plazos concretos se acuerdan en cada caso.
- 1
Revisar el origen
Qué sistema detecta la situación, qué información aporta y si puede llamar a la API o necesita un conector.
- 2
Definir el plan
Qué canales, en qué orden, con qué insistencia y hacia qué personas. Se traduce en uno o varios perfiles.
- 3
Preparar el ámbito
Alta de la empresa, usuarios administradores, agendas de destinatarios y asignación de canales.
- 4
Crear la credencial
Con los permisos estrictamente necesarios para lo que el sistema va a hacer.
- 5
Probar
Prueba en vivo del perfil desde la administración y pruebas de los métodos desde la zona de pruebas del integrador.
- 6
Poner en marcha
Conexión del sistema real, revisión del histórico de los primeros días y ajuste del plan si hace falta.
Explicar el origen suele bastar para saber por dónde ir
Con el sistema que detecta la incidencia, el volumen previsto y los canales necesarios, el equipo indica si la integración es directa por API o requiere un conector.