Data Exchange API: comparte el subconjunto que importa

Planificación pide tipos, niveles y cantidades de algunos elementos. Le mandamos el modelo completo para que cargue tres disciplinas, reconstruya los filtros y encuentre lo poco que necesitaba. Una generosidad admirable con el ancho de banda y con el tiempo de los demás. Data Exchange plantea compartir un subconjunto de información. La pregunta interesante no es cuánto podemos enviar, sino qué necesita recibir ese equipo para tomar su decisión sin hacer arqueología digital.

Data Exchange permite plantear otro recorrido: compartir un subconjunto seleccionado de geometría y propiedades para un consumidor concreto. Sus conectores, API y SDK ofrecen distintas vías según la aplicación y las capacidades disponibles. Vamos a utilizar un ejemplo hipotético de planificación para explicar qué conviene acordar antes, cómo conservar identidad y versiones, y por qué un intercambio pequeño también necesita mantenimiento.

El subconjunto empieza por la decisión de quien lo recibe

La pregunta inicial debería ser qué necesita hacer el destinatario. Imagina que planificación quiere relacionar pilares y vigas de ciertas zonas con actividades y comparar cantidades. Puede necesitar identificadores, nivel, tipo, material y una magnitud definida con su unidad. Tal vez requiera geometría para situarse, pero no armaduras, vistas ni todos los parámetros de cálculo. Ese alcance es una decisión de trabajo; la API podrá ayudar a representarlo cuando esté claro.

Un contrato pequeño debería describir entidades, propiedades, unidades y referencias necesarias para interpretar la selección. «Volumen» sin origen ni criterio puede ser ambiguo si una aplicación calcula una cantidad y otra consume una propiedad diferente. Una ausencia tampoco debería convertirse automáticamente en cero. El intercambio debe permitir reconocer si falta un dato, si no se aplica o si el valor es efectivamente nulo. El consumidor merece una explicación mejor que una columna vacía.

La explicación de Data Exchange y sus conectores de Autodesk presenta el trabajo con subconjuntos en lugar de entregar siempre el modelo completo. Esa posibilidad no determina qué selección conviene a planificación. Si una viga solo puede entenderse correctamente junto a sus apoyos o su zona, el recorte debe conservar ese contexto o explicar dónde se consulta. Compartir menos información es útil cuando no obliga a adivinar la que falta.

Por eso conviene acompañar el conjunto con propósito, origen y limitaciones. El destinatario debería saber qué categorías están incluidas y qué decisiones no puede tomar únicamente con esos datos. Un subconjunto preparado para seguimiento de actividades no se convierte por ello en una base suficiente para cualquier cálculo o revisión. Ponerle el nombre «modelo coordinado» sería más rápido que explicar su alcance, aunque bastante menos preciso.

La selección también necesita pruebas de representatividad. Escoge un elemento corriente, otro con una condición especial y uno que deba quedar fuera. Comprueba si el consumidor reconoce los tres casos y puede explicar las propiedades que recibe. Una muestra pequeña puede revelar que sobra casi todo o que falta justamente la relación que justificaba el intercambio. Es un descubrimiento mucho más barato antes de automatizar cada actualización.

Conector, API y aplicación propia resuelven partes diferentes

Un conector acerca el intercambio al entorno en el que trabaja el usuario; una API o un SDK permiten desarrollar comportamientos propios. La presentación del conector de Data Exchange para Revit describe compartir subconjuntos, consumir referencias y actualizar intercambios. Es una referencia para entender sus capacidades, no una garantía de que cualquier versión de cualquier conector trate de igual manera todos los objetos y propiedades.

Antes de programar, comprueba si el conector existente resuelve el recorrido previsto. Si puede publicar y consumir la selección que necesitas, quizá el trabajo esté en preparar datos y acordar el proceso. Una integración propia puede compensar cuando necesitas transformar información, unirla con otro sistema o ofrecer una interacción específica. No hace falta reconstruir una capacidad existente para que el resultado lleve una firma técnica más vistosa.

El uso de un SDK tampoco elimina la traducción entre aplicaciones. La documentación de Data Exchange SDK distingue el modelo de datos del SDK del trabajo que debe realizar un conector para traducir objetos nativos y enlazarse con su aplicación. Al desarrollar, hay que consultar la versión elegida y probar esa conversión. Una viga representada como referencia geométrica no tiene por qué convertirse en el mismo objeto paramétrico editable que existía en origen.

Esa diferencia afecta a la promesa de bidireccionalidad. Consumir datos, crear un nuevo intercambio y modificar el modelo original son acciones distintas. Si planificación quiere devolver el código de actividad, habría que comprobar qué mecanismo soporta ese flujo y qué campos puede gobernar. No debe deducirse que cualquier propiedad recibida se puede escribir de vuelta por el mero hecho de verla en una tabla. La flecha de retorno necesita un contrato propio.

Acceso y compatibilidad también se contrastan en el recorrido real: aplicación, versión, proyecto, identidad y permisos de cada participante. Evita convertir un anuncio general en una conclusión sobre todas las cuentas. Puedes mantener una prueba acotada con el entorno que utilizará el equipo y registrar qué parte funcionó. Para el lector que empieza, la decisión práctica es sencilla: primero verifica la combinación concreta; después estima la integración que de verdad falta.

Las actualizaciones dependen de identidad y contexto

Volvamos a planificación. Si una actividad se relaciona con un pilar, el consumidor necesita reconocerlo entre actualizaciones o saber cuándo ya no puede hacerlo. Guarda referencias de origen y un identificador de negocio si el proceso lo utiliza, comprobando su unicidad y estabilidad. No confundas un nombre legible con una identidad suficiente ni supongas que cualquier identificador interno sigue siendo válido fuera del contexto que lo generó.

Los cambios difíciles son precisamente los que merecen ensayo: un pilar eliminado, otro dividido en dos, una viga sustituida o un código renumerado. En esos casos puede no existir una correspondencia automática correcta. La aplicación debería distinguir altas, bajas y situaciones que requieren revisión. Repartir la actividad del elemento antiguo entre dos nuevos porque «parecen la continuación» introduce una decisión de planificación que el intercambio quizá no tenga autoridad para tomar.

Conserva qué versión o estado del intercambio ha utilizado cada proceso, y la referencia de fuente disponible. Consultar siempre lo más reciente sin registrar lo leído dificulta reproducir un informe. Si llega una actualización durante el cálculo, el consumidor debe evitar mezclar silenciosamente datos de dos estados. La implementación dependerá del mecanismo disponible; el requisito es poder explicar con qué conjunto se produjo el resultado.

También interesa acordar cómo se muestran las diferencias. Un dato modificado no debería parecer un elemento nuevo, y un elemento ausente del subconjunto no demuestra por sí solo que haya sido demolido. Puede haber cambiado el filtro, el alcance o el acceso. Registrar esos factores evita que una selección más estrecha se interprete como una reducción real de cantidades. Los gráficos agradecen cualquier bajada; el proyecto suele exigir más contexto.

Si una sincronización se interrumpe, conserva un estado pendiente y una forma de reanudar o reconstruir el conjunto sin duplicar efectos. No presentes como completo lo que solo ha recuperado una parte. Las pruebas de transformación pueden hacerse con datos de ejemplo, pero paginación, permisos, identidad entre versiones y actualización de referencias necesitan contrastarse con la API o los conectores reales. El ejemplo de planificación describe qué revisar; no relata una implantación ejecutada.

Cuando quieras devolver información al origen, limita el alcance por campo y responsabilidad. El código de actividad puede pertenecer a planificación, mientras otras propiedades siguen bajo la autoridad del modelo estructural. Comprueba referencia, versión relevante y valor actual antes de proponer una escritura, y explica conflictos. La colaboración no mejora porque dos aplicaciones puedan corregirse mutuamente sin enterarse: eso también lo hacen dos hojas de Excel, con resultados conocidos.

Compartir menos compensa cuando simplifica el trabajo completo

Data Exchange es una opción dentro de un intercambio más amplio entre equipos. Una entrega IFC puede responder a una necesidad de interoperabilidad y conservación de un modelo bajo un esquema abierto; una exportación tabular puede bastar para una consulta puntual; un intercambio conectado puede servir cuando el subconjunto se actualiza con frecuencia y el ecosistema elegido encaja. La decisión depende del uso y de las capacidades que hayas comprobado, no de declarar un vencedor para todos los proyectos.

En planificación, mide preparación, publicación, recuperación, transformación y revisión del resultado. Un conjunto más pequeño puede reducir transferencia o esfuerzo de manejo, pero no conviene convertir esa expectativa en un porcentaje de ahorro sin medirlo. Si cada actualización obliga a reparar manualmente correspondencias, el coste puede estar en la identidad de los datos y no en el tamaño del archivo. Ahí el siguiente paso será mejorar el contrato, aunque un nuevo conector parezca más entretenido.

Mantén una persona responsable, una descripción del alcance y una revisión de consumidores y accesos. Las propiedades añadidas deberían tener un uso claro; de lo contrario el subconjunto tenderá a convertirse otra vez en «todo, por si acaso». Es una evolución muy natural: cada columna parece barata hasta que alguien debe conservar su significado, sus permisos y su compatibilidad durante varias entregas.

Revisa también si el intercambio sigue siendo necesario. Una consulta única quizá se resuelva mejor con una entrega controlada, y un consumidor que necesita prácticamente el modelo completo puede no beneficiarse de mantener muchos filtros. Retirar un intercambio huérfano evita que una tabla antigua siga circulando con apariencia de conexión activa. La integración más sencilla de mantener a veces es la que hemos dejado de necesitar y sabemos cerrar.

El resultado útil sería que planificación recibiese datos suficientes para su decisión y pudiera volver al contexto correcto cuando hiciese falta. El modelo completo dejaría de viajar por costumbre y el subconjunto tendría una explicación que resistiese la siguiente versión. Si nadie puede decir para qué necesita una propiedad, quizá no haya que enviarla todavía. La palabra «granular» no merece que acabemos compartiendo hasta el historial emocional de la familia.

Describe primero la decisión del receptor y después el subconjunto que permite tomarla. Acordad identidad, unidades, revisión y qué ocurre al actualizar. Enviar menos ayuda cuando lo enviado conserva ese significado; amputar columnas al azar no es una estrategia de intercambio. ¿Qué equipo recibe hoy un edificio entero para utilizar cuatro datos? Ahí tienes un candidato bastante más concreto que «conectar todas las aplicaciones».