Skip to main content

17.6 Datasphere and BW Bridge Interoperability

1. The boundary​

BW bridge and Datasphere can work together, but they have distinct modeling environments.

The key architectural pattern is:

BW bridge models
      |
      | expose / share / import
      v
SAP Datasphere
      |
      v
Semantic models and data products
      |
      v
Consumers

2. Remote BW bridge objects​

Current Datasphere transformation-flow documentation notes that remote tables located in BW bridge spaces can be used as sources when they are shared with the Datasphere space being used.

This creates an important security and ownership boundary.

3. Import versus access​

There are multiple strategies:

  • access bridge data through supported sharing,
  • import supported metadata,
  • persist selected data into Datasphere,
  • build semantic models on top.

Choose based on:

  • latency,
  • ownership,
  • performance,
  • reuse,
  • lifecycle.

4. Avoid duplicate persistence​

A common modernization mistake is:

BW bridge
   |
   v
Datasphere table
   |
   v
another Datasphere table
   |
   v
semantic model

If each copy adds no architectural value, eliminate it.

5. Semantic responsibility​

Define where business meaning lives.

A practical enterprise approach can be:

  • BW bridge preserves migrated BW acquisition and warehouse semantics,
  • Datasphere provides broader enterprise harmonization and semantic products.

This is a design choice, not a mandatory SAP rule.

Exercise​

A migrated BW model is used by 300 consumers.

Determine whether to:

  • expose it directly,
  • import its metadata,
  • copy its data,
  • rebuild it natively.

Defend the choice using risk and consumer impact.