Saltar al contenido
Business Data Cloud

Estados de release en BDC: data products obsoletos y qué hacer

Novedad de octubre de 2026 en SAP BDC: estados Active, Deprecated y Decommissioned de data products e intelligent content, y de vistas en el catálogo.

Por 5 min de lectura
Portada sobre los estados de release de data products e intelligent content en SAP Business Data Cloud
Índice del artículo

El 20 de octubre de 2026, SAP Business Data Cloud empezó a mostrar el estado de release de los data products, los data packages y el intelligent content: Active, Deprecated o Decommissioned. Ese mismo día, con la wave 2026.22 de Datasphere, el catálogo empezó a enseñar también el estado de release de las vistas de Datasphere. Parece un detalle de la interfaz, pero detrás hay un ciclo de vida con plazos que conviene conocer antes de que un data product del que dependen tus informes deje de cargar datos.

Los tres estados de BDC

Según la documentación de BDC, cada data product e intelligent content está en uno de estos tres estados:

Estado Qué significa Qué implica
Active Estable y listo para producción Puede pasar a Deprecated en cualquier momento. Las versiones mayores siguen soportadas un periodo de transición antes de entrar en deprecación
Deprecated Sigue funcionando, pero se va a retirar Normalmente ocurre cuando ya hay un sucesor. Hay que sustituirlo por él. Dura como mínimo 12 meses y se sigue dando soporte (parches y, rara vez, mejoras menores)
Decommissioned Ya no funciona; se conserva solo como referencia histórica SAP deja de dar soporte

SAP fija además un mínimo: desde que un recurso está Active hasta que se da de baja y se retira del sistema tienen que pasar al menos 24 meses.

Hay dos matices que en proyecto importan:

  • El estado del data product no depende del de su data package. Si un data package pasa a Decommissioned, sus data products que sigan Active se pueden seguir usando.
  • El cockpit te deja activar data products Deprecated o Decommissioned, aunque SAP lo desaconseja porque puede que no funcionen como se espera.

Lo que pasa cuando llega a Decommissioned

Esta es la parte que me parece más delicada. Cuando un recurso pasa a Decommissioned:

  • En el cockpit, el intelligent content no instalado y los data packages inactivos dejan de aparecer en la pestaña Available de Intelligent Content and Data Packages, y los data products inactivos ya no se ven dentro de su data package. Lo que ya tienes instalado o activado sigue a la vista, con la etiqueta Decommissioned.
  • En SAP Datasphere, el data product deja de recibir actualizaciones, se paran las cargas de datos y aparece como Inactive.
  • Los artefactos de Datasphere y de SAP Analytics Cloud siguen funcionando, porque puede haber consumidores que dependan de ellos (sistemas conectados, dashboards, pipelines). Para quitarlos hay que desinstalar el intelligent content y desactivar los data products desde el cockpit.

Las vistas de Datasphere tienen su propio ciclo de vida

Los release states de las vistas no son nuevos: existen desde la wave 2024.18 (agosto de 2024). Lo nuevo de la 2026.22 es que el catálogo muestra el estado de release de cada vista y permite filtrar por él. En la ficha del activo aparece en la sección de estados, junto a los estados funcional y de publicación.

Funcionan así:

  • Not Released es el valor por defecto. Es opcional: nadie te obliga a liberar ninguna vista.
  • Released: te comprometes a que la vista siga devolviendo los datos de forma consistente durante al menos dos años. A partir de ahí solo admite cambios que no rompan a sus consumidores: añadir columnas, añadir asociaciones o añadir un parámetro de entrada con valor por defecto (si la vista ya tiene al menos uno). No puedes quitar columnas, parámetros ni asociaciones, y lo que guardas pasa a formar parte de la vista liberada.
  • Deprecated: tienes que indicar una vista sucesora. Una vez guardada, no se puede cambiar el sucesor; para elegir otro hay que volver a Released y deprecarla de nuevo.
  • Decommissioned: solo cuando la vista lleva un año en Deprecated y al menos dos años desde que se liberó. A partir de ahí se puede borrar cuando quieras.

Al marcar una vista como Released, el editor avisa de que el cambio no se puede deshacer, aunque los usuarios con el permiso Spaces.Update (incluido en el rol DW Space Administrator) sí pueden volver al estado anterior. Y en los transportes, la app Transport no importa objetos con un estado de release incoherente con el del objeto que ya existe en el espacio.

Los plazos se parecen mucho a los de SAP: un año como mínimo en deprecación y dos de vida. Con lo nuevo del catálogo, puedes aplicar a tus vistas la misma disciplina que SAP aplica a sus data products.

Cómo lo usaría en un proyecto

Mi checklist después de esta novedad:

  1. Revisa el cockpit. Busca en Intelligent Content and Data Packages si algún recurso instalado lleva la etiqueta Deprecated o Decommissioned.
  2. Por cada Deprecated, abre una tarea de migración con fecha. Tienes 12 meses como mínimo, pero adaptar vistas, modelos y stories a un sucesor lleva su tiempo.
  3. Mide el impacto antes de tocar nada. La ficha de cada activo en el catálogo tiene un diagrama de impacto y linaje, y la parte de impacto muestra los objetos que lo usan como fuente. Es un buen punto de partida para saber qué vistas y modelos tuyos dependen de un data product.
  4. Libera tus vistas de consumo. A mi juicio, merece la pena marcar como Released las vistas que consumen SAP Analytics Cloud u otros espacios. Así el editor limita los cambios y avisa si intentas uno que rompería a sus consumidores.
  5. Depreca con sucesor y comunica. Al sustituir una vista, depréciala apuntando a la nueva y avisa a quienes la consumen.

Preguntas que haría a SAP

  • Además de la etiqueta en el cockpit, ¿cómo se avisa de que un data product pasa a Deprecated? ¿Hay notificación o API para monitorizarlo?
  • ¿Dónde se indica el sucesor de un data product deprecado? No lo he encontrado documentado.

Conclusión

Los estados de release hacen visible el ciclo de vida del contenido de SAP, con plazos: como mínimo 12 meses en Deprecated y 24 meses de vida en total. Trata Deprecated como el inicio de una migración y no esperes a Decommissioned, cuando los datos dejan de cargarse sin dar errores. Y aprovecha para liberar tus vistas de consumo de Datasphere y gestionarlas con el mismo criterio.

Fuentes

Sigue leyendo