Integración de datos telemáticos con HTTP Push en IoT Logic

En distintos sectores, las aplicaciones telemáticas suelen necesitar más contexto del que pueden proporcionar por sí solos los datos del vehículo y del dispositivo. Por ejemplo, puede ser necesario combinar el kilometraje con los registros del último servicio almacenados en un sistema de mantenimiento. Hay varias formas de integrar estos datos, y la elección influye en la cantidad de código, infraestructura y mantenimiento continuo que requiere la integración.

El enriquecimiento mediante HTTP Push, incorporado recientemente a IoT Logic de Navixy, ofrece una forma directa de incorporar datos externos al procesamiento telemático. Veamos con más detalle cómo funciona, qué se puede crear con esta funcionalidad y qué cambia desde el punto de vista de la integración.

Entonces, ¿qué es el enriquecimiento mediante HTTP Push?

El enriquecimiento mediante HTTP Push permite que un sistema externo envíe datos directamente a Navixy IoT Logic, un entorno low-code para procesar y transformar datos telemáticos procedentes de dispositivos IoT y sistemas OEM.

El sistema externo envía una solicitud HTTP con sus datos. Un mapeo configurado asocia los datos entrantes con el rastreador correspondiente y pone los atributos a disposición de IoT Logic para su procesamiento.

La telemetría del rastreador y los datos externos llegan de forma independiente.

Supongamos que un rastreador reporta:

hardware_mileage = 197450

mientras que un sistema de mantenimiento de flotas envía el kilometraje registrado durante el último servicio:

{
  "vehicle_ref": "VEH-318",
  "odometer_at_service": 182300
}

Ambos valores están ahora disponibles en IoT Logic. Un flujo puede calcular que el vehículo ha recorrido 15,150 kilómetros desde el servicio registrado y utilizar el resultado en el procesamiento posterior.

El sistema de mantenimiento no se convierte en otra fuente de telemetría. Proporciona la información que le corresponde, mientras que el rastreador continúa reportando datos del vehículo de forma independiente.

Qué aportan los datos externos a un flujo telemático

Incorporar un valor externo a IoT Logic resulta útil cuando ese valor puede cambiar lo que el flujo calcula, decide o hace. Dos escenarios lo muestran especialmente bien.

Para conocer con más detalle las aplicaciones de negocio de este enfoque, consulta nuestro artículo sobre enriquecimiento de datos de vehículos.

Crear condiciones a partir de dos fuentes de datos

Algunas reglas operativas necesitan tanto telemetría como información almacenada en otros sistemas.

Supongamos que un rastreador reporta que un vehículo refrigerado ha entrado en una geocerca del depósito, mientras que un sistema externo proporciona:

inspection_required = true

IoT Logic puede evaluar ambos datos y utilizar el resultado para activar el siguiente paso del flujo de trabajo.

El mismo patrón permite combinar ubicación, movimiento, kilometraje, lecturas de sensores u otros datos telemáticos con permisos, asignaciones, información de mantenimiento, estados operativos y otros atributos externos.

La aplicación externa proporciona el contexto que le corresponde. IoT Logic utiliza ese contexto junto con los datos del rastreador, por lo que ninguno de los dos sistemas necesita contener por sí solo la regla operativa completa.

Activar una acción telemática desde otro sistema

Los datos externos también pueden iniciar un flujo de trabajo en la dirección opuesta.

Una aplicación puede saber que es necesario realizar una acción en un vehículo, pero no disponer de un canal de comunicación directo con su rastreador. Por ejemplo, otro sistema podría enviar:

immobilization_requested = true

La solicitud puede entrar en IoT Logic mediante HTTP Push. El flujo puede evaluar cualquier condición adicional y, cuando la configuración del flujo y las capacidades del rastreador lo permitan, iniciar la acción correspondiente en el dispositivo.

La aplicación externa no tiene que implementar por sí misma la capa de comunicación con el dispositivo. Proporciona la solicitud a nivel de negocio, mientras Navixy se encarga de la comunicación del lado telemático.

Para quienes desarrollan soluciones, esto establece una separación útil. Una aplicación orientada al cliente puede participar en flujos de trabajo relacionados con dispositivos sin tener que implementar también los protocolos de los rastreadores y la entrega de comandos.

Mapear identificadores externos con rastreadores

El sistema de origen no tiene que identificar un activo de la misma forma que Navixy. Un sistema de mantenimiento de flotas, por ejemplo, puede utilizar sus propias referencias de vehículos:

VEH-318
VEH-319
VEH-320

Al configurar el enriquecimiento mediante HTTP Push, se puede utilizar un parámetro adecuado de los datos entrantes como clave primaria para mapear esos valores con los rastreadores:

VEH-318 → rastreador 12345
VEH-319 → rastreador 12346
VEH-320 → rastreador 12347

De esta forma, el sistema de mantenimiento puede seguir enviando un payload basado en su propio identificador:

{
  "vehicle_ref": "VEH-318",
  "maintenance_due": false,
  "work_order": "WO-98311",
  "odometer_at_service": 182300
}

IoT Logic utiliza el mapeo configurado para vehicle_ref con el fin de asociar los datos entrantes con el rastreador correspondiente. Esto mantiene la traducción de identificadores en el límite de la integración, sin exigir que la aplicación de origen adopte IDs de rastreadores u otro identificador específico de Navixy.

De la infraestructura de integración a la lógica de negocio

Antes del enriquecimiento mediante HTTP Push, los datos externos de negocio no podían incorporarse directamente a IoT Logic de esta manera. Para hacerlo, podía ser necesario implementar un componente de integración entre la aplicación externa y el procesamiento telemático.

Incluso un servicio relativamente sencillo puede tener que recibir un payload, identificar el activo, preparar los datos y transmitirlos. El código es solo una parte del trabajo. El servicio también debe desplegarse, alojarse, protegerse, monitorearse, actualizarse, diagnosticarse, documentarse y mantenerse.

HTTP Push traslada esa parte de la integración a IoT Logic. El sistema externo envía los datos, los mapeos configurados los asocian con los rastreadores y el flujo define qué sucede a continuación.

En una solución donde un componente personalizado existiría principalmente para recibir datos externos y conectarlos con el procesamiento telemático, HTTP Push puede eliminar por completo un componente de infraestructura. Para un TSP o integrador que despliega soluciones similares para varios clientes, esto también significa un servicio menos que desplegar y mantener en cada implementación.

Esto no elimina el trabajo de ingeniería de integración. La estrategia de identificadores, los mapeos, los esquemas de atributos, las credenciales, las pruebas y la gestión del ciclo de vida siguen siendo importantes. Lo que cambia es dónde se realiza gran parte de ese trabajo: en la configuración y la lógica de negocio, en lugar de hacerlo en otro servicio de software y su infraestructura asociada.

HTTP Push y otros mecanismos de integración de Navixy

HTTP Push, Navixy Generic Protocol y la API de Navixy cumplen funciones diferentes.

Mecanismo	Función
Enriquecimiento mediante HTTP Push	Incorporar atributos externos a IoT Logic y asociarlos con un rastreador existente para procesarlos junto con su telemetría
Navixy Generic Protocol	Conectar una fuente que funciona como fuente telemática por derecho propio y proporciona su propia telemetría
API de Navixy	Crear, leer, actualizar y eliminar entidades y configuraciones compatibles de Navixy

La diferencia entre HTTP Push y NGP es especialmente importante.

Con NGP, el sistema conectado es la fuente de telemetría. Con HTTP Push, la telemetría del rastreador ya llega de forma independiente, mientras que otro sistema aporta información adicional relacionada con ese rastreador.

Esta diferencia también establece un límite técnico. Los atributos principales de posicionamiento, como coordenadas, velocidad, rumbo, número de satélites y HDOP, no pueden sobrescribirse mediante el enriquecimiento con HTTP Push. Si otro sistema es la fuente real de esas mediciones, debe conectarse como fuente de telemetría en lugar de tratarse como una fuente de enriquecimiento.

La API de Navixy cumple otra función. Proporciona operaciones CRUD programáticas para las entidades y configuraciones compatibles de la plataforma, en lugar de funcionar como una entrada alternativa para procesar datos externos arbitrarios dentro de un flujo de IoT Logic.

El código de integración personalizado puede seguir siendo necesario en casos excepcionales donde los mecanismos disponibles en la plataforma no cubran los requisitos de integración. Sin embargo, no debería ser necesario simplemente porque un sistema de terceros tenga datos que deban participar en el procesamiento de IoT Logic.

La configuración también requiere ingeniería

Trasladar la capa de transporte y mapeo a la configuración no elimina el contrato de integración.

Tomemos un mapeo como este:

VEH-318 → rastreador 12345

Si se reemplaza el rastreador o cambia el identificador externo, también debe cambiar el mapeo. Por eso, contar con identificadores estables se vuelve cada vez más importante a medida que crece el despliegue.

Los nombres y tipos de atributos requieren la misma disciplina. Nombres como:

maintenance_due
maintenance_work_order
odometer_at_service

son más fáciles de mantener que campos genéricos como status, id o value. Y si un flujo espera:

{
  "maintenance_due": true
}

cambiar el valor a "yes" modifica el contrato de la lógica que consume esos datos.

HTTP Push utiliza una clave API, por lo que la aplicación emisora también debe proteger esa credencial como un secreto de integración.

Durante la puesta en marcha, Data Stream Analyzer puede ayudar a comprobar que el identificador, el mapeo, los atributos y el procesamiento posterior esperados lleguen correctamente al flujo.

En despliegues de mayor escala, conviene abordar la gestión del ciclo de vida de los mapeos, el manejo de fallos, los límites de solicitudes, la gestión de credenciales y el monitoreo antes del lanzamiento. Cuando la documentación actual no especifique un límite o comportamiento concreto, es mejor verificarlo para el despliegue en cuestión en lugar de diseñar la solución basándose en una suposición.

Configurar el enriquecimiento mediante HTTP Push

El enriquecimiento mediante HTTP Push se configura en el nodo Data Source de IoT Logic.

Selecciona los rastreadores que deben recibir los datos externos y configura HTTP Push como fuente de datos de software. Después de guardar el flujo, IoT Logic proporciona la URL de HTTP Push que utilizará la aplicación externa. Las solicitudes se autentican mediante una clave API.

A continuación, selecciona el parámetro entrante que se utilizará como clave primaria y configura sus mapeos con los rastreadores correspondientes:

VEH-318 → rastreador 12345
VEH-319 → rastreador 12346
VEH-320 → rastreador 12347

La aplicación externa puede entonces enviar:

{
  "vehicle_ref": "VEH-318",
  "maintenance_due": false,
  "work_order": "WO-98311",
  "odometer_at_service": 182300
}

IoT Logic resuelve VEH-318 mediante el mapeo configurado y pone los atributos enviados a disposición del procesamiento junto con los datos que llegan de forma independiente desde el rastreador.

Para consultar los campos exactos de configuración y los requisitos actuales de HTTP Push, revisa la documentación sobre enriquecimiento mediante HTTP Push.

El contexto externo pasa a formar parte de la lógica telemática

HTTP Push proporciona a los datos externos de negocio una entrada directa a IoT Logic. Estos datos pueden participar en condiciones junto con la telemetría del rastreador o iniciar flujos de trabajo que continúan del lado telemático.

Para integradores y desarrolladores de soluciones, esto también puede eliminar infraestructura cuya única función sería incorporar esos atributos externos al procesamiento telemático. El trabajo de ingeniería se mantiene enfocado en los mapeos, las condiciones y las acciones que hacen útiles los datos combinados.

¿Tienes un escenario que combine datos externos con telemetría? Contacta a nuestro equipo para hablar sobre cómo desarrollarlo con IoT Logic.