Data Exchange API: comparte solo los datos que necesita cada equipo
Planificación necesitaba códigos, tipos, plantas y cantidades de pilares y vigas. Recibió un modelo completo de estructuras con armaduras, familias auxiliares, vistas y cientos de propiedades que no utilizaba. Para actualizar una columna del informe, descargaba otra versión, reconstruía filtros y esperaba a que el archivo terminase de abrir. La colaboración consistía en trasladar mucha información para consumir muy poca.
Una Data Exchange API puede permitir publicar y consumir subconjuntos de datos entre aplicaciones, según las capacidades concretas del producto y su versión. La idea resulta potente: compartir los objetos y propiedades necesarios sin entregar todo el modelo. Pero el recorte necesita alcance, permisos, identidad, versiones y contexto. Si no, solo habremos construido un modelo más pequeño y unas dudas del mismo tamaño.
Tabla de contenidos
El intercambio empezó por la decisión de planificación
El equipo quería vincular elementos estructurales con actividades y comparar cantidades. No necesitaba editar geometría ni conocer cada parámetro de cálculo. Definió entidades, propiedades, relaciones y unidades necesarias.
Los pilares y vigas debían llevar identificador de negocio, nivel, tipo, material, volumen y código de zona. También se necesitaba saber de qué versión procedían. Las propiedades internas sin uso quedaron fuera.
Este contrato permitió evaluar si el mecanismo de intercambio podía representar el alcance. La API no decidía qué necesitaba planificación; ejecutaba una selección que el equipo había acordado.
Un subconjunto no fue una copia improvisada
La publicación definía filtros por categorías, propiedades o selección soportada. El resultado tenía identidad y versión propias, relacionadas con la fuente. No era un archivo exportado con nombre «solo_vigas».
El equipo guardaba quién creó el intercambio, desde qué modelo y para qué consumidor. Los permisos determinaban quién podía verlo o actualizarlo. Una subcontrata no obtenía acceso al modelo completo por consumir una tabla.
La descripción incluía alcance y limitaciones. Quien recibía sabía que no estaban las armaduras ni todas las relaciones. La ausencia era diseño, no error silencioso.
Los identificadores sostuvieron la actualización
Planificación debía reconocer el mismo pilar entre versiones. Los IDs visibles de una aplicación podían cambiar o no ser estables fuera de su contexto. El equipo incluyó un identificador de negocio y probó su persistencia.
Cuando un elemento se eliminaba, dividía o fusionaba, la correspondencia podía romperse. La actualización marcaba altas, bajas y casos ambiguos. No trasladaba automáticamente la actividad del elemento antiguo a dos nuevos.
La identidad era parte del proceso de modelado. Si los códigos se rellenaban tarde o se duplicaban, el intercambio lo detectaba antes de publicar. Una API no fabrica trazabilidad a partir de nombres creativos.
La versión convirtió el dato en una afirmación fechada
Cada conjunto publicado se vinculaba con una versión de origen. Planificación sabía si analizaba la entrega del martes o una edición posterior. El consumidor no consultaba «lo último» sin registrar qué había leído.
Las actualizaciones mostraban diferencias. Una propiedad modificada se distinguía de un elemento nuevo. Los resultados derivados conservaban la versión utilizada.
Si estructuras publicaba mientras planificación procesaba, el trabajo continuaba sobre su instantánea y después notificaba que existía otra. Mezclar datos de dos versiones habría creado una tabla actualizada y no reproducible.
La autenticación no sustituyó los permisos de proyecto
La aplicación consumidora utilizaba el flujo de autorización y scopes adecuado. Los secretos permanecían en backend y los tokens se limitaban. Después se comprobaba que el usuario y el servicio tuvieran acceso al proyecto y al intercambio.
Los permisos del proveedor se alineaban con roles internos. Una credencial técnica no concedía a todos los usuarios del portal los mismos datos. La API propia aplicaba membership y aislamiento.
Las revocaciones y caducidades se probaron. Si el acceso desaparecía, el sistema detenía sincronización y mostraba una acción. No reutilizaba indefinidamente una copia sin avisar de que había perdido la fuente.
El consumidor recibió un esquema, no una sorpresa
Las propiedades se mapeaban a un contrato interno con nombre, tipo y unidad. Un cambio de etiqueta en la fuente no debía alterar silenciosamente una columna. Las propiedades desconocidas se registraban y los campos obligatorios se validaban.
Los nulos, ausentes y no aplicables se distinguían. Un volumen cero podía ser legítimo o error; una propiedad inexistente indicaba otra condición. El consumidor no rellenaba todo con cadenas vacías para facilitar el JSON.
La versión del esquema acompañaba a la sincronización. Los cambios incompatibles necesitaban migración. La flexibilidad del intercambio no eliminaba la necesidad de contratos.
La primera sincronización fue distinta de las siguientes
La carga inicial obtuvo todos los objetos del subconjunto. Las posteriores intentaron recuperar cambios o comparar versiones según las capacidades disponibles. El sistema diseñó paginación, reanudación y límites.
Si una llamada fallaba a mitad, no presentaba el conjunto como actualizado. Guardaba un cursor o estado y reintentaba de forma idempotente. La base de datos aplicaba cambios en una transacción o por lotes controlados.
Los rate limits y errores transitorios utilizaban espera. Los fallos permanentes, como permiso o esquema inválido, se detenían. Sin esta distinción, una credencial revocada podía convertirse en un worker muy perseverante y poco útil.
El contexto perdido se hizo visible
Planificación recibía cantidades y ubicación lógica, pero no toda la geometría. Para algunas decisiones necesitaba abrir el modelo o un visor vinculado. El intercambio conservaba referencias para recuperar contexto cuando era posible.
Una viga sin sus apoyos podía interpretarse mal. Si la relación era necesaria para el uso, se añadía; si no podía representarse, el contrato lo declaraba. Recortar datos exige conocer dependencias.
El equipo evitó presentar el subconjunto como gemelo completo. Era una vista de información diseñada para un consumidor. Su fuerza estaba en esa limitación explícita.
La escritura de vuelta tuvo una frontera estrecha
Planificación quería devolver el código de actividad. Se definió como dato de su autoridad y se validó contra catálogo. La API o mecanismo disponible debía soportar la escritura de forma controlada; si no, otro flujo aplicaba cambios.
Antes de escribir se comprobaban versión, identificador y valor actual. Los conflictos se mostraban. Geometría y propiedades estructurales seguían bajo la autoridad del modelo.
La vista previa enumeraba cambios. El resultado conservaba aplicados y fallidos. La bidireccionalidad no se asumía como objetivo general, sino como permiso por campo.
IFC, exportación y Data Exchange resolvieron preguntas diferentes
| Enfoque | Encaja cuando | Atención |
|---|---|---|
| Data Exchange API | Necesitas subconjuntos conectados y actualizaciones mediante una plataforma compatible | Dependencia de producto, permisos, versiones y capacidades vigentes |
| IFC | Necesitas un intercambio abierto, documentable y consumible por varias herramientas | Configuración, mapeo y alcance del intercambio |
| Exportación tabular | El caso es simple, ocasional y principalmente alfanumérico | Actualización, identidad y copias manuales |
| Acceso al modelo completo | El consumidor necesita geometría y contexto amplio | Peso, permisos y acoplamiento |
La elección dependía de frecuencia, volumen, apertura y gobernanza. El equipo podía utilizar más de un mecanismo sin fingir que eran equivalentes.
El rendimiento se midió en el recorrido completo
Compartir menos datos reducía transferencia y procesamiento, pero la ganancia dependía de filtros, paginación y consumidor. Se midieron publicación, descarga, transformación y actualización.
El sistema evitaba pedir propiedades que no utilizaba y cacheaba catálogos estables. No cacheaba indefinidamente datos sujetos a versión. Los límites de API se incorporaban a capacidad y alertas.
Una mejora local no justificaba perder contexto o añadir soporte excesivo. El objetivo era que planificación recibiese datos fiables antes, no ganar una carrera de payloads.
Las pruebas comprobaron cambios incómodos
Se publicaron pilares nuevos, eliminados, renumerados y divididos. También propiedades ausentes, unidades distintas y permisos retirados. El consumidor debía producir estados esperados.
Las pruebas de contrato utilizaban un proyecto aislado y la API real. Los mocks cubrían transformaciones, pero no demostraban scopes, paginación o comportamiento de versiones.
Los cambios de producto y documentación activaban revisión. La Data Exchange API se trataba como integración versionada, no como estándar inmutable.
La gobernanza evitó intercambios huérfanos
Cada intercambio tenía propietario, consumidores, propósito y fecha de revisión. Los que nadie utilizaba se retiraban. Las propiedades incorporadas se justificaban.
Los logs registraban publicación y consumo sin copiar datos sensibles innecesarios. La retención respondía a auditoría y operación. Los accesos se revisaban al cambiar equipos.
El mantenimiento incluía credenciales, SDK o API, mappings y soporte. Un subconjunto automático también necesita que alguien recuerde por qué existe.
Cuándo no crear otro intercambio
Para una consulta única, una exportación podía ser suficiente. Si el consumidor necesitaba casi todo el modelo, mantener un subconjunto ofrecía poca ventaja. Si no había identificadores estables, primero había que mejorar datos.
También convenía evitarlo cuando la plataforma no soportaba región, formato o permisos requeridos. El nombre de la capacidad no compensaba un contrato que no encajaba.
Un intercambio no sustituía requisitos. Publicar menos información incorrecta sigue siendo publicar información incorrecta, solo que más rápido.
Compartir solo lo necesario exigió saber qué era necesario
Planificación terminó recibiendo pilares y vigas con propiedades versionadas, identidad y cambios. Cuando necesitaba contexto, podía volver al modelo correspondiente. El código de actividad regresaba por un flujo gobernado.
La Data Exchange API aportó valor al convertir una relación amplia entre aplicaciones en un contrato acotado. Para usarla bien, define el consumidor, selecciona datos, conserva identidad y versión, controla permisos y prueba actualizaciones.
Si el primer intercambio se llama «todo menos cosas que no hacen falta», todavía no has reducido el modelo: solo has escrito un filtro con ansiedad. Empieza por una decisión y deja que el alcance se defienda solo.
Respuestas