Saltar al contenido
SAP Datasphere

Business Builder obsoleto en Datasphere: cómo pasar a Analytic Models

SAP declara obsoleto el Business Builder de Datasphere (wave 2026.21). Qué significa, qué sigue funcionando y cómo migrar consumption models y perspectivas.

Por 5 min de lectura
Portada sobre la obsolescencia del Business Builder de SAP Datasphere y la migración de consumption models y perspectivas a Analytic Models
Índice del artículo

El 7 de octubre de 2026, con la wave 2026.21, SAP publicó en el What’s New de SAP Datasphere una línea que muchos esperábamos: el Business Builder queda obsoleto (deprecated) y no recibirá más actualizaciones. La recomendación oficial es migrar los consumption models a Analytic Models. Si tienes stories de SAP Analytics Cloud sobre perspectivas, esto te afecta. Te cuento qué cambia, qué no y cómo lo planificaría.

Qué ha anunciado SAP exactamente

La nota es breve y conviene leerla al pie de la letra:

  • El Business Builder está obsoleto y no recibirá más actualizaciones.
  • SAP recomienda migrar los consumption models a analytic models, que pasan a ser la forma preferida de exponer datos a SAP Analytics Cloud y a otros clientes, herramientas y aplicaciones.

La misma nota aparece ya en la documentación del Business Builder, cuyo capítulo se titula ahora Modeling Data in the Business Builder (Deprecated), y en la página de inicio del Business Builder.

Hay un precedente que ayuda a leer el mensaje. La semántica Analytical Dataset ya se declaró obsoleta hace tiempo: las vistas existentes siguen funcionando “por ahora” en SAC, pero SAP empuja hacia Fact + Analytic Model. Con el Business Builder pasa lo mismo. Además, en agosto (wave 2026.18) SAP ya alineó su vista previa con la del Analytic Model, y dejó de ofrecer la vista previa de perspectivas, business entities y authorization scenarios. Era una pista clara.

Qué objetos se ven afectados

El Business Builder tenía cuatro piezas. Así es como yo las traslado al mundo del Data Builder:

Objeto del Business Builder Para qué servía Equivalente recomendado
Business entity Capa estable sobre una entidad del Data Builder; fuente cambiable Vista con semántica Fact o Dimension. Para cambiar el origen, Replace Fact Source en el Analytic Model
Fact model Combinar varias business entities en un modelo intermedio Vista Fact que haga la unión o el join antes del Analytic Model
Consumption model Estrella con medidas, atributos, filtros y autorizaciones Analytic Model: medidas calculadas y restringidas, variables, filtro global y DAC
Perspective Subconjunto ligero que consume SAC Un Analytic Model por caso de uso, o un Analytic Model apilado sobre otro

Dos diferencias que conviene tener claras antes de empezar:

  1. Varias fuentes de hechos. Un consumption model podía combinar varias fuentes de hechos; el ejemplo de la propia documentación es COPA con real, presupuesto y forecast. Según la documentación, el Analytic Model parte de una fuente: un fact o un analytic model. En la práctica, esa combinación tienes que resolverla antes, en una vista Fact (unión con una columna de categoría, por ejemplo).
  2. Autorizaciones. Los authorization scenarios del consumption model no pasan solos. En el Analytic Model la protección se hace con data access controls, que puedes aplicar en el propio modelo. Revisa uno a uno que la lógica de filas sea la misma.

Cómo lo planificaría en un proyecto

No he encontrado un convertidor automático de consumption models a analytic models en la documentación, así que cuenta con trabajo de modelado. Mi plan:

  1. Inventario. Lista por espacio los consumption models y perspectivas, y qué stories de SAC consume cada perspectiva. Lo que nadie usa no se migra: se borra.
  2. Congela. A partir de hoy, nada nuevo en el Business Builder. Ponlo en las normas de modelado del equipo.
  3. Prepara la base. Si quedan Analytical Datasets, pásalos a Fact. La documentación tiene un botón Create Analytic Model en la propiedad de semántica que crea el modelo con las mismas medidas, atributos y dimensiones asociadas.
  4. Reconstruye por caso de uso. Un Analytic Model por perspectiva relevante, con nombres técnicos estables y sus variables. Si varias perspectivas comparten base, usa un Analytic Model base y apila otros encima.
  5. Migra las stories sin romperlas. Para los Analytical Datasets, SAP describe un método que yo aplicaría igual aquí: añade el Analytic Model como nueva fuente en la story, copia las páginas, cambia las referencias de medidas y dimensiones, compara resultados y, cuando cuadre, borra la página original.
  6. Valida y retira. Mismos filtros, mismas variables, mismos totales. Después, borra el consumption model y su perspectiva para que nadie vuelva a usarlos.

Preguntas que haría a SAP

  • ¿Hay fecha prevista para que las perspectivas dejen de poder consumirse desde SAC o Excel?
  • ¿Habrá alguna utilidad de conversión de consumption model a Analytic Model?
  • ¿Se mantendrá la generación de consumption models y perspectivas en el model transfer de BW/4HANA, o se quedará solo en el Analytic Model?

Conclusión

El Business Builder llevaba tiempo en segundo plano y ahora es oficial: obsoleto, sin más mejoras y con el Analytic Model como camino. No hay prisa de apagón, pero sí motivos para empezar ya: cada perspectiva nueva es deuda técnica. Haz el inventario este trimestre, congela el Business Builder y migra primero las stories más usadas. Y si tu plataforma va a evolucionar a SAP Business Data Cloud, llegarás con una capa semántica limpia.

Fuentes

Sigue leyendo