Skip to content
Business Data Cloud

BDC system mapping: Datasphere transports with data products

New in SAP Business Data Cloud (October 2026): system mappings that make content transported between Datasphere tenants use the right data products.

By 5 min read
Cover about SAP Business Data Cloud system mappings for transporting content between SAP Datasphere tenants
Table of contents

On 20 October 2026, alongside SAP Datasphere wave 2026.22, SAP Business Data Cloud introduced system mappings: a setting in the BDC cockpit that pairs the data-product provider systems of each environment. The goal is simple: when you transport Datasphere content from development to test or production, the target connects to the right data products on its own. If you run, or plan to run, a three-tier landscape on BDC, this goes straight to the heart of your transport strategy.

The problem it solves

In BDC, when your Datasphere views, flows or analytic models are built on data products, they consume data product entities installed in the space. Those come from a specific provider system (for example, a development SAP S/4HANA). When you export that content and import it into the production tenant, it should point to the data products of the production S/4HANA, not the development one.

According to the BDC What’s New, with system mappings the target space automatically connects to the provider system defined in the mapping, removing the need to reconnect manually after import. The Datasphere documentation on using data product entities in modeling already recommends defining these mappings before you transport.

How it works

A user with the BD Administrator role sets it up in the SAP Business Data Cloud cockpit, under System Landscape → System Mapping tab → Add Mapping. Each mapping has:

Field What it means
Source System The source data-product provider system (e.g. the development S/4HANA)
Target System The provider system the transported package will consume data products from (e.g. production). Only systems of the same type are offered
SAP Datasphere Destination Space ID Optional. The target space that receives the content. If left empty, whoever imports can choose any space

Once created, the mapping is applied automatically in the next transport operation involving those systems. SAP’s own example makes it clear: with DEV mapped to TEST and DEV mapped to PROD, a package exported from the DEV spaces connects to the TEST S/4HANA data products when imported into the test tenant, and to the PROD S/4HANA ones when imported into production. A second example uses the space field to split one source across two ingestion spaces (one per region) in a single target tenant.

Operational details worth knowing

The documentation includes several rules that matter on a real project:

  • Several targets on the same tenant. If you map one source to more than one target connected to the same Datasphere tenant, SAP recommends specifying a target space in each mapping.
  • The space must exist. The Destination Space ID must match a space that already exists in the target tenant at import time.
  • Don’t touch mappings during imports. You can only edit or delete them when no import is in progress.
  • Unavailable systems. If one of the mapped systems becomes unavailable, the tab shows a notification and transports using that mapping fail. If the system comes back within 90 days, the mapping resumes automatically; otherwise it expires, can be deleted, and you need a new one with an operational system.

The rest of the Datasphere transport process stays the same: you still use the Transport app (or SAP Cloud Transport Management, if integrated), with its import privileges, space mapping, and overwrite and deployment options.

How I would plan it on a project

My checklist before the first transport involving data products:

  1. Draw the landscape. Which Datasphere tenant consumes from which provider system in each environment. Check in System Landscape that they are all in their formations and that Test Connection succeeds.
  2. Decide the transport route. Mappings go from source to target. If you always export from DEV, you need DEV→TEST and DEV→PROD, as in SAP’s example. If your rule is to re-export from TEST to PROD, you will need that mapping too. In my view, exporting from a single source is the cleanest option.
  3. Pin the target spaces. I think it is worth filling in the Destination Space ID even when there is only one candidate: it stops anyone importing into the wrong space.
  4. Assign ownership. Mappings belong to the BD Administrator, not the modeling team. Add them to the onboarding procedure for any new provider system.
  5. Test with a small package. One view on a data product entity plus an analytic model. Import, deploy, and check in the preview that the data comes from the target environment, not from development.

Questions I would ask SAP

  • What exactly happens to content transported before mappings existed? Does it need a re-import, or does it adjust itself?
  • Can system mappings be managed via API or command line to automate environment setup?
  • How does a package behave when it mixes objects built on data products from several provider systems?

Conclusion

System mappings look like an admin detail, but they are key to making the DEV → TEST → PROD cycle work with data products in BDC, and the documentation warns that without them the transport fails. If you are building your landscape, configure them before the first transport and run an end-to-end test with a small package. If you already transport content, check this week that every provider system is included in a mapping.

Sources

Keep reading