Autodesk Platform Services: el mapa para construir sobre Autodesk
El cliente pidió un portal donde pudiera abrir modelos, consultar propiedades y recibir un aviso cuando una nueva versión estuviese preparada. La primera estimación decía «usar APS» como si Autodesk Platform Services fuese una API única con un botón para construir portales. A la semana, el equipo tenía credenciales, varios ejemplos funcionando por separado y ninguna decisión sobre dónde vivirían los archivos, quién podía verlos o qué ocurría al procesarlos.
Autodesk Platform Services reúne APIs y servicios para trabajar con datos, visualización, automatización y eventos del ecosistema Autodesk. Su utilidad aparece cuando se dibuja el recorrido completo de una aplicación. La plataforma aporta capacidades; tu sistema sigue necesitando usuarios, permisos, estados, almacenamiento de negocio, observabilidad y una forma educada de recuperarse cuando algo falla.
Tabla de contenidos
El proyecto empezó sin un visor
Antes de elegir servicios, la consultora definió el flujo. Un coordinador publicaría una versión; el backend la registraría; el modelo se prepararía para visualización; el cliente lo abriría según sus permisos; y una validación produciría un informe. Cada paso tenía estado y responsable.
También se decidió dónde estaba la fuente de verdad. El portal gestionaría proyectos, membresías, entregas e informes. APS almacenaría o accedería a los artefactos necesarios según la arquitectura. El visor no se convertiría en base de datos editorial.
Esta separación evitó diseñar toda la aplicación alrededor de un tutorial de carga. El modelo era un recurso dentro de un proceso, no el proceso entero.
La autenticación se dividió por identidad y propósito
Las llamadas de servidor que actuaban como aplicación necesitaban credenciales y scopes mínimos. Los flujos en nombre de usuarios requerían autorización apropiada. El equipo no reutilizó un token amplio para navegador, backend y workers.
Los secretos permanecían en servidor. El frontend recibía únicamente credenciales temporales y acotadas cuando el flujo lo exigía. Los tokens se cacheaban durante su vigencia y se renovaban sin exponerlos en logs.
Autenticar ante APS no sustituía autenticar al usuario del portal. La aplicación comprobaba membership y acceso al proyecto antes de entregar cualquier referencia o token. Tener una URL del visor no otorgaba permiso para pasear por todos los modelos de la empresa.
Los datos necesitaron una ruta explícita
El equipo eligió cómo llegaban los archivos y qué identificador persistía en su dominio. Una carga se registraba primero como entrega pendiente. Después el backend obtenía o generaba la referencia APS y guardaba versión, tamaño, checksum y estado.
Los nombres visibles no funcionaban como clave. Podían repetirse y cambiar. El portal mantenía IDs propios relacionados con los IDs externos. Esta capa permitía migrar o reprocesar sin reescribir todas las relaciones de negocio.
Las cargas grandes y las interrupciones se trataron según las capacidades soportadas. El sistema mostraba progreso real y distinguía fallo de red, permiso y formato. «No ha subido» dejó de ser una categoría técnica única.
Model Derivative preparó una representación, no el proyecto
Para mostrar y consultar el modelo, se solicitaba su procesamiento al formato de visualización adecuado. La operación era asíncrona. El backend guardaba el estado y consultaba o recibía cambios hasta completar.
Una traducción correcta indicaba que existía una representación procesada. No demostraba que el modelo cumpliese requisitos BIM ni que todas las propiedades estuvieran presentes. El portal separó «listo para visualizar» de «validado».
Los fallos incluían formato, referencias, archivos compuestos o problemas internos. El usuario veía una explicación útil y podía reintentar de forma controlada. Los workers evitaban iniciar varias traducciones iguales mediante claves idempotentes.
El visor se construyó alrededor de tareas
El cliente necesitaba navegar, aislar disciplinas, consultar propiedades y abrir incidencias. La interfaz cargaba el modelo y añadía herramientas vinculadas al flujo. No intentaba mostrar cada extensión disponible.
Las propiedades se utilizaban con cuidado. Los nombres y estructuras podían variar según autoría y exportación. La aplicación mapeaba únicamente la información necesaria y mostraba el origen. Para consultas masivas o reglas, procesar datos en backend podía ser mejor que recorrer todo desde el navegador.
La posición de cámara y la selección ayudaban a crear contexto, pero una incidencia conservaba modelo, versión y referencias de objeto. Una captura por sí sola seguía siendo una pista frágil.
Los identificadores del visor no se trataron como eternos
Dentro de una traducción, los objetos tenían referencias útiles para selección y propiedades. Al publicar otra versión, esas referencias podían cambiar. El equipo no asumió correspondencia automática.
Cuando necesitaba trazabilidad entre versiones, utilizaba identificadores de negocio, IFC GUID u otras claves presentes y probadas, además de estrategias de comparación. Los casos sin correspondencia quedaban para revisión.
Esta decisión afectaba a incidencias, marcadores y datos externos. Guardar solo un ID interno del visor habría funcionado hasta la siguiente publicación, momento tradicional en que las demos descubren el ciclo de vida.
Automation se reservó para trabajos realmente automatizables
Parte del flujo necesitaba ejecutar tareas sobre aplicaciones Autodesk en un entorno gestionado. Design Automation podía encajar cuando existía una actividad definida, entradas controladas y una salida verificable.
El equipo no trasladó cualquier script de escritorio sin revisar dependencias, versiones, licencias y comportamiento desatendido. Una rutina que muestra un diálogo o espera una ruta local necesita rediseño.
Los trabajos eran asíncronos, idempotentes y observables. La aplicación guardaba actividad, versión, parámetros y resultado. El coste y la capacidad se comparaban con workers propios y ejecución local según frecuencia y necesidad.
Los eventos avisaron; la API confirmó
Un webhook podía informar de que un procesamiento o cambio había ocurrido. El receptor verificaba firma y alcance, persistía el evento y respondía rápido. Después un worker recuperaba el estado exacto mediante API.
Los duplicados se deduplicaban y los huecos se reconciliaban periódicamente. El portal no asumía entrega única ni orden perfecto. Un evento iniciaba trabajo; no era la única prueba de realidad.
La región de los datos, las suscripciones y el endpoint se diseñaron de forma coherente. La consultora verificó capacidades actuales en documentación oficial porque nombres, versiones y disponibilidad pueden cambiar.
Una arquitectura mínima dejó responsabilidades visibles
| Capa | Responsabilidad | No debería asumir |
|---|---|---|
| Frontend y Viewer | Interacción, contexto y visualización | Secretos, autorización final o procesos largos |
| API propia | Usuarios, permisos, proyectos y contratos | Bloquearse esperando traducciones |
| Workers y cola | Procesamiento, reintentos y efectos idempotentes | Decisiones técnicas ambiguas |
| APS | Capacidades Autodesk solicitadas | La lógica completa del negocio |
| Base de datos | Estados, relaciones y trazabilidad | Copiar indiscriminadamente todo el modelo |
La tabla ayudó a revisar el diseño. Si el navegador guardaba secretos o el webhook lanzaba directamente una operación irreversible, había una responsabilidad fuera de sitio.
Los estados evitaron una interfaz optimista
Una entrega podía estar cargando, almacenada, procesando, visible, validando, bloqueada o publicada. El frontend mostraba estos estados y sus acciones. No enseñaba un modelo anterior como si fuese la versión recién subida.
Las operaciones largas tenían identificador y progreso. Un fallo conservaba causa saneada y posibilidad de reintento cuando era seguro. Los usuarios no necesitaban pulsar otra vez por intuición.
La consistencia entre base de datos y APS se reparaba mediante reconciliación. Si una llamada completaba pero la respuesta se perdía, el sistema consultaba y retomaba. La idempotencia cubría ese terreno intermedio.
Los costes se asociaron al uso
La consultora estimó almacenamiento, traducciones, automatizaciones, transferencia y operación propia según escenarios. No tomó un precio puntual de una página como tarifa eterna. Verificó condiciones vigentes y añadió límites internos.
Los modelos se reprocesaban solo cuando cambiaba el artefacto o la configuración. Las representaciones reutilizables se cacheaban dentro del contrato permitido. Los trabajos innecesarios se detectaban.
El coste de desarrollo incluía seguridad, soporte y actualizaciones, no solo llamadas. Una API puede reducir infraestructura y aumentar dependencia; la comparación debía cubrir ambos lados.
Las pruebas atravesaron la frontera externa
Las unidades probaban permisos y estados. Las integraciones utilizaban un proyecto aislado y archivos pequeños conocidos. Se ensayaban carga, traducción, token, visor, evento y recuperación.
También se provocaban duplicados, timeouts, tokens caducados, permisos insuficientes y formatos inválidos. Los mocks ayudaban, pero no demostraban que scopes, regiones y contratos reales coincidieran.
Antes de desplegar, el equipo verificaba cambios de API y versiones del visor. Las dependencias se fijaban y las migraciones tenían una ruta. «Funcionaba con el ejemplo de hace dos años» no era una política de compatibilidad.
Cuándo APS no era la respuesta
Si el objetivo era generar un informe local ocasional, una integración cloud completa podía sobrar. Si los datos no podían salir de un entorno controlado, había que evaluar restricciones antes. Para un visor de IFC abierto, podían existir alternativas con otro coste y dependencia.
APS ganaba sentido cuando la aplicación necesitaba capacidades Autodesk, escala, acceso web o procesamiento gestionado. La elección se hacía por requisitos, formatos, usuarios y ciclo de vida.
Tampoco resolvía una gobernanza BIM inexistente. Puede mostrar propiedades con gran fluidez; no decide cuáles deben existir ni quién responde por ellas.
El mapa terminó en una aplicación, no en una colección de APIs
El portal pudo cargar una versión, procesarla, mostrarla al cliente y generar una validación. Cada paso conservaba estado, permisos e identidad. Un evento duplicado no repetía incidencias y un fallo de traducción no se disfrazaba de modelo aprobado.
Para trabajar con Autodesk Platform Services, dibuja primero el recorrido y asigna responsabilidades. Elige autenticación, datos, derivados, visor, automatización o eventos solo donde resuelvan una etapa. Verifica contratos y precios actuales en documentación oficial.
Si tu arquitectura empieza y termina con «usar APS», todavía tienes un mapa sin carreteras. La buena noticia es que ya sabes dónde no colocar el secreto: jamás en ese JavaScript que alguien inspeccionará cinco minutos después.
Respuestas