Construya un modelo de datos a la medida de su negocio de telemática con Business Data Repository

Una plataforma de telemática casi siempre arranca con el mismo conjunto de objetos: vehículos, dispositivos, conductores y geocercas.

La operación real de un cliente rara vez se queda ahí.

Una empresa de logística puede necesitar además remolques, contratos, depósitos, tipos de carga y registros de mantenimiento. Un negocio de renta puede trabajar con sucursales, categorías de equipo, clientes y unidades en arrendamiento. Un integrador de sistemas puede necesitar conectar información de varios sistemas de negocio con un mismo activo físico.

Ahí es donde un modelo de datos rígido de la plataforma empieza a estorbar.

Puede montar una segunda base de datos junto a la plataforma de telemática. Puede meter los datos de negocio en notas y etiquetas. O puede construir una capa de sincronización que traduzca sin parar entre el modelo del cliente y el modelo de la plataforma.

Las tres opciones funcionan. Ninguna envejece bien.

Tome un caso común en logística: un camión puede trabajar con distintos remolques, y cada remolque puede traer sus propios equipos de rastreo y sensores. La empresa necesita saber no solo dónde está el camión, sino qué remolque lleva enganchado, qué dispositivos pertenecen a ese remolque y qué datos operativos corresponden a cada parte del conjunto.

En un modelo de datos rígido, representar esas relaciones suele implicar tablas extra, identificadores duplicados o lógica de sincronización fuera de la plataforma de telemática.

Business Data Repository se está construyendo para modelar esa estructura de forma directa. Un integrador puede definir camiones, remolques, equipos, contratos u otros objetos de negocio, conectarlos mediante relaciones explícitas y extender cada tipo con los atributos que su operación exige. El mismo enfoque se puede aplicar después a una flotilla de construcción, a una operación de renta, a un negocio de cadena de frío o a casi cualquier otro modelo específico de un cliente.

La GraphQL Repository API es el contrato detrás de esa flexibilidad. Les da a los integradores una forma consistente de definir esas entidades de negocio conectadas y de trabajar con ellas sin esperar cambios en el esquema de la plataforma. Están planeados SDK para Kotlin, TypeScript y Python, para que el mismo modelo sea más fácil de usar desde los lenguajes en los que los integradores ya entregan software, y también un servidor MCP sobre esas mismas entidades, para trabajar con ellas desde Navixy y desde herramientas externas.

Un contexto importante antes de seguir: Business Data Repository API y el SDK todavía no se publican. La documentación actual es documentación de vista previa, y las estructuras o los comportamientos aún pueden cambiar antes del lanzamiento. Conviene leer lo que sigue como la dirección del modelo y por qué importa, no como una guía de implementación en producción para hoy.

El modelo de operaciones conectadas

Una forma útil de entender Business Data Repository API es este modelo de cinco capas:

1. Tipo — defina la forma del objeto que su negocio realmente usa.
2. Vínculo — conecte los registros entre sí como relaciones, no como texto suelto.
3. Validación — exija calidad de datos desde el tipo de campo.
4. Catálogo — estandarice los vocabularios controlados una sola vez y reutilícelos en todas partes.
5. Trazabilidad — conserve el historial de cambios para que el contexto operativo no se pierda con el tiempo.

Los campos personalizados son parte de esto, pero son solo una capa.

Empiece por los objetos de negocio, no solo por los predeterminados de la plataforma

Los campos personalizados son útiles, pero resuelven solo una parte del problema.

A veces no necesita un atributo más en el vehículo. Necesita otro tipo de objeto dentro de su modelo operativo.

Por ejemplo, un integrador puede necesitar representar remolques, embarques, contratos de servicio, unidades en renta o equipos auxiliares como entidades de negocio de pleno derecho dentro del mismo entorno de datos.

Business Data Repository API está diseñada para que un espacio de trabajo defina sus propios tipos en dos familias de objetos: tipos de activo y tipos de geo-objeto. Todo lo de la lista anterior —un remolque, un embarque, un contrato de servicio, una unidad en renta, una pieza de equipo— se modela como un tipo de activo propio, con sus propios atributos; las zonas, los sitios y las áreas de servicio son tipos de geo-objeto.

En lugar de forzar un «contrato de servicio» dentro de una nota del vehículo o de mantenerlo solo en una tabla externa, puede modelarlo directamente en una sola capa conectada.

Eso no significa que cada cuenta empiece con un modelo en blanco. Al crear una cuenta, el cliente también puede precrear tipos de entidad listos para usar, como Vehicle y Cargo. Esos tipos llegan con un conjunto básico de campos, y ese conjunto se puede extender igual que cualquier otro tipo: la idea es arrancar más rápido, no quedar amarrado a un esquema fijo.

Si integra para varias industrias, esto pesa todavía más. Una constructora, un operador de cadena de frío y una arrendadora de equipo pueden usar la misma plataforma de telemática y mantener encima modelos de negocio muy distintos.

Para ver cómo modela Navixy hoy los activos tipados, consulte la guía de trabajo con activos.

Conecte registros en lugar de guardar identificadores como texto

Crear registros solo sirve si esos registros se pueden conectar con sentido.

En muchos sistemas, un campo como remolque termina guardando un valor de texto como TR-1048. Ese valor parece útil, pero sigue siendo una simple cadena. La plataforma no sabe por sí sola si ese remolque existe, qué es, ni qué más está ligado a él.

Repository API está diseñada alrededor de relaciones por referencia entre registros.

Eso cambia lo que los integradores pueden construir:

• vehículo -> remolque
• equipo -> contrato de servicio
• embarque -> vehículo
• activo -> cliente, representado como una entrada de catálogo o como un tipo de activo propio

Una referencia resuelve a un registro dentro de su propio modelo, así que el cliente, el proveedor o el equipo responsable de ese último ejemplo es uno que usted mismo modeló —una entrada de catálogo o un tipo de activo—, no un usuario de la plataforma. Conviene decidirlo desde temprano, porque define cómo representa a las personas y a las organizaciones en todo el modelo.

Es una distinción técnica con consecuencias prácticas. Cuando los vínculos se modelan como relaciones y no como texto libre, sus pantallas operativas, sus reglas y sus API trabajan con contexto conectado en lugar de fragmentos sueltos.

Agregue atributos acordes a la función de cada objeto

Cuando ya existen los tipos de objeto, los campos personalizados valen mucho más.

Cada tipo puede llevar sus propios atributos relevantes en vez de compartir una bolsa universal de «campos extra».

Un remolque puede necesitar VIN, límites de carga y fechas de inspección. Un contrato de servicio puede necesitar número de contrato, vigencia y estatus. Una unidad en renta puede necesitar campos de utilización y de entrega-recepción.

El contrato actual de vista previa define un sistema de campos tipados con comportamiento de validación (por ejemplo, límites de longitud para cadenas, restricciones numéricas para decimales y valores restringidos para opciones y referencias). Así el modelo se hace cargo de parte de la lógica de negocio, en lugar de empujar toda la validación a cada aplicación cliente.

Una decisión de ese diseño es permanente y vale la pena planearla: el tipo de un campo queda fijo en el momento en que se crea el campo. Los títulos, los límites de validación y la obligatoriedad se pueden seguir editando, y un campo que dejó de usar se puede archivar y restaurar.

El tipo es la excepción: pasar un campo de texto a referencia, o de número a lista de opciones, implica borrar la definición y crear una nueva, y los valores que ya se escribieron bajo la definición anterior se quedan en los datos almacenados sin nada que los respalde. Elija el tipo con el mismo cuidado con el que elegiría el tipo de una columna en un esquema que no puede migrar: para un integrador que diseña un modelo que sus clientes van a llenar con registros reales, es la decisión más cara de toda esta página.

Para los detalles más recientes conforme avanza la vista previa, consulte Implementación de campos personalizados.

Use catálogos para mantener un lenguaje de negocio consistente

Muchos atributos de negocio vienen de vocabularios controlados: fabricantes, categorías de servicio, clases de carga, estructuras de sucursales, centros de costo.

Sin catálogos, los equipos terminan con variantes del mismo texto:

• Bosch
• BOSCH
• Bosch GmbH

Business Data Repository API incluye estructuras de catálogo definidas por el usuario, para que esos valores se normalicen una sola vez y se reutilicen en los objetos relacionados.

Conforme crece el modelado específico por cliente, este es uno de los mayores multiplicadores de calidad: menos limpieza, menos discrepancias y menos errores de integración del tipo «la misma cosa escrita de tres formas».

Conserve el contexto del cambio, no solo el estado actual

En los flujos de trabajo operativos, el valor actual muchas veces no alcanza.

La pregunta frecuente no es «¿qué valor tiene este objeto ahora?», sino «¿qué valor tenía cuando ocurrió este evento?».

Business Data Repository API incluye contexto de cambios orientado al historial y a la auditoría de cada entidad, para que los integradores construyan interfaces donde importan la línea de tiempo y la procedencia, no solo el último estado.

Para operaciones internas, procesos regulados, investigación de incidentes y herramientas de administración de cara al cliente, esto puede ser mucho más útil que un conjunto plano de campos editables.

Resuelva operaciones comunes de telemática con menos código de pegamento

Los integradores dedican mucho tiempo a tareas operativas repetitivas que quedan entre el «CRUD simple» y un motor completo de flujos de trabajo.

Un buen ejemplo es el reemplazo de dispositivos. Cuando un rastreador GPS pasa de un activo a otro, el modelo de datos debería soportar ese cambio de relación de forma limpia, en vez de obligar a una lógica de sincronización frágil y de varios pasos alrededor de identificadores sueltos.

Lo mismo aplica cuando hay varios dispositivos en un mismo activo y uno de ellos debe quedar marcado con claridad como principal.

Por sí solos, estos detalles no son promesas de titular. Pero reflejan la misma dirección de diseño: modelar las relaciones operativas de forma directa, en lugar de que cada integrador las vuelva a armar alrededor de identificadores desconectados.

Por qué GraphQL encaja con este modelo

Business Data Repository API usa GraphQL, que encaja bien con el modelado de datos conectados.

Los integradores pueden pedir exactamente los campos y los objetos relacionados que necesita una interfaz, en vez de juntar cargas completas desde varios puntos de acceso (endpoints) fijos y unirlas después.

Para productos interactivos —consolas de operación, portales para clientes, herramientas internas, interfaces de administración— eso suele significar menos sobrecarga de transporte y una lógica de aplicación más limpia.

La conclusión de fondo

Los sistemas de telemática viven dentro de operaciones de negocio más amplias. Los vehículos se conectan con remolques. El equipo pertenece a sitios. Los activos están ligados a contratos y a estructuras de clientes. Esas relaciones son propias de cada empresa.

Business Data Repository API se está construyendo para que ese contexto de negocio se pueda modelar: defina las estructuras que necesita, conéctelas, valídelas y siga cómo evolucionan.

Para los integradores, la ventaja práctica es sencilla: menos tiempo peleando con el esquema fijo de un proveedor y más libertad para modelar la forma en que el cliente realmente opera.

Si quiere seguir la evolución de este modelo antes del lanzamiento, comience por el índice de documentación de Business Data Repository API y siga las actualizaciones en las guías de vista previa, incluido el comportamiento de filtrado y ordenamiento de campos personalizados en la referencia de filtrado de campos personalizados.