Saltar al contenido
Business Data Cloud

System mapping en BDC: transportes de Datasphere con data products

Novedad de octubre de 2026 en SAP BDC: system mappings para que lo que transportas entre tenants de Datasphere use los data products correctos.

Por 5 min de lectura
Portada sobre los system mappings de SAP Business Data Cloud para transportar contenido entre tenants de SAP Datasphere
Índice del artículo

El 20 de octubre de 2026, junto con la wave 2026.22 de SAP Datasphere, SAP Business Data Cloud estrenó los system mappings: una configuración en el BDC cockpit que empareja los sistemas proveedores de data products de cada entorno. Su objetivo es que, al transportar contenido de Datasphere de desarrollo a test o a producción, el destino se conecte solo a los data products correctos. Si tienes (o vas a tener) un landscape de tres niveles en BDC, esto toca de lleno tu estrategia de transportes.

Qué problema resuelve

En BDC, cuando tus vistas, flujos o analytic models de Datasphere se basan en data products, consumen entidades de data products instaladas en el espacio, que vienen de un sistema proveedor concreto (por ejemplo, un SAP S/4HANA de desarrollo). Cuando exportas ese contenido y lo importas en el tenant de producción, debería apuntar a los data products del S/4HANA de producción, no a los de desarrollo.

Según el What’s New de BDC, con los system mappings el espacio de destino se conecta automáticamente al sistema proveedor que corresponde según el mapeo, y deja de ser necesario reconectar a mano tras la importación. La documentación de Datasphere sobre el uso de entidades de data products en modelado ya recomienda definir estos mapeos antes de transportar.

Cómo funciona

La configuración la hace un usuario con el rol BD Administrator en el cockpit de SAP Business Data Cloud, en System Landscape → pestaña System Mapping → Add Mapping. Cada mapeo tiene:

Campo Qué indica
Source System El sistema proveedor de data products de origen (p. ej., el S/4HANA de desarrollo)
Target System El sistema proveedor del que consumirá los data products el paquete transportado (p. ej., el de producción). Solo se ofrecen sistemas del mismo tipo
SAP Datasphere Destination Space ID Opcional. El espacio de destino que recibirá el contenido. Si no lo indicas, quien importa puede elegir cualquier espacio

Una vez creado, el mapeo se aplica automáticamente en la siguiente operación de transporte que implique a esos sistemas. El ejemplo de la documentación es claro: con DEV mapeado a TEST y DEV mapeado a PROD, un paquete exportado desde los espacios de DEV se conecta a los data products del S/4HANA de TEST al importarlo en el tenant de test, y a los del S/4HANA de PROD al importarlo en el de producción. Un segundo ejemplo usa el campo de espacio para repartir un mismo origen entre dos espacios de ingesta (uno por región) en un mismo tenant de destino.

Detalles operativos que conviene saber

La documentación incluye varias reglas que en proyecto marcan la diferencia:

  • Varios destinos en el mismo tenant. Si mapeas un origen a más de un destino conectado al mismo tenant de Datasphere, SAP recomienda indicar un espacio de destino en cada mapeo.
  • El espacio tiene que existir. El Destination Space ID debe corresponder a un espacio que ya exista en el tenant de destino en el momento de la importación.
  • No toques mapeos con importaciones en curso. Solo se pueden editar o borrar cuando no hay ninguna importación en marcha.
  • Sistemas caídos. Si uno de los sistemas del mapeo deja de estar disponible, la pestaña muestra un aviso y los transportes que usen ese mapeo fallan. Si el sistema vuelve en 90 días, el mapeo se reactiva solo; si no, caduca, se puede borrar y hay que crear uno nuevo con un sistema operativo.

Recuerda además que esto no cambia el resto del proceso de transporte de Datasphere: sigues usando la app Transport (o SAP Cloud Transport Management si la tienes integrada), con sus permisos de importación, su mapeo de espacios y sus opciones de sobrescritura y despliegue.

Cómo lo planificaría en un proyecto

Mi checklist antes del primer transporte con data products:

  1. Dibuja el landscape. Qué tenant de Datasphere consume de qué sistema proveedor en cada entorno. Comprueba en System Landscape que todos están en sus formations y que el Test Connection responde.
  2. Decide la ruta de transporte. El mapeo va de origen a destino. Si exportas siempre desde DEV, necesitas DEV→TEST y DEV→PROD, como en el ejemplo de SAP. Si tu norma es reexportar desde TEST a PROD, necesitarás también el mapeo correspondiente. A mi juicio, lo más limpio es exportar siempre desde un único origen.
  3. Fija los espacios de destino. En mi opinión, merece la pena rellenar el Destination Space ID aunque solo haya un candidato: evita que alguien importe en el espacio equivocado.
  4. Documenta quién mantiene los mapeos. Es tarea del BD Administrator, no del equipo de modelado. Añádelo al procedimiento de alta de cualquier sistema proveedor nuevo.
  5. Prueba con un paquete pequeño. Una vista sobre una entidad de data product y un analytic model. Importa, despliega y comprueba en la vista previa que los datos son los del entorno de destino, no los de desarrollo.

Preguntas que haría a SAP

  • ¿Qué ocurre exactamente con el contenido ya transportado antes de que existieran los mapeos? ¿Hay que reimportarlo o se reajusta solo?
  • ¿Se pueden gestionar los system mappings por API o línea de comandos para automatizar el alta de entornos?
  • ¿Cómo se comporta un paquete que mezcla objetos sobre data products de varios sistemas proveedores?

Conclusión

Los system mappings parecen un detalle de administración, pero son una pieza clave para que el ciclo DEV → TEST → PROD funcione con data products en BDC, y la documentación avisa de que, sin ellos, el transporte falla. Si estás montando el landscape, configúralos antes del primer transporte y haz una prueba de punta a punta con un paquete pequeño. Y si ya transportas contenido, revisa esta semana que todos tus sistemas proveedores estén incluidos en algún mapeo.

Fuentes

Sigue leyendo