Becoming Datasphere savy as a BW developer

As a BW developer venturing into the world of SAP Datasphere, it's often challenging to draw clear parallels between the two systems. In conversations with other professionals, we've frequently heard about the need for a 'cheat sheet' to bridge this understanding gap. Recognizing this common hurdle, we've decided to create and share our own 'cheat sheet' to help map and compare key components between BW and Datasphere.​ 

This guide aims to provide a concise overview of how familiar BW objects, such as InfoObjects, Composite Providers, and Process Chains, correspond to their counterparts in SAP Datasphere, including Business Entities, Analytical Models, and Data Flows. By highlighting these relationships, we hope to facilitate a smoother transition and deeper comprehension for those navigating both environments.

InfoObject as Dimension → Dimension

In SAP BW, InfoObjects represent descriptive data such as customer, product, or region. In SAP Datasphere, the equivalent is called a Dimension, which can be time-dependent. These structures are used in a similar way to provide context to Facts and Measures, but Datasphere's Dimensions are more flexible and are often created using Graphical Views and associated dynamically via Associations.

InfoObject as Key Figure → Measure

Key Figures in BW are numerical values like revenue or quantity. In Datasphere, these are Measures, used for aggregations, filtering, and reporting. The core purpose remains the same, but Measures in SAP Datasphere are integrated more tightly into Analytical Models.

ADSO → Relational Dataset

In SAP BW, an Advanced DataStore Object (ADSO) is used to store harmonized or staged data, often forming part of a layered architecture (e.g., staging, core, and reporting layers). In Datasphere, a Relational Dataset serves a similar role: it’s a persistently stored table that acts as a source for further data modeling. However, unlike BW’s strict layering, SAP Datasphere offers more flexibility. Datasets can be used in both real-time (virtual) and persistent contexts, giving modelers more freedom to define their data flows without rigid separation between layers.

Transformation → Graphical View

Transformations in BW define how data is mapped between source and target. SAP Datasphere uses Graphical Views for this purpose. These views allow you to join, filter, and enrich data in a visual, no-code environment. The big advantage? You can trace and manage data logic more easily with a visual interface compared to rule-based BW transformations.

Composite Provider → Fact/Analytical Model

In SAP BW, a Composite Provider is used to combine data from multiple sources into a single logical view. It acts as a unified semantic layer that allows reporting tools (like BEx or SAC) to access and analyze harmonized data. In SAP Datasphere, this role is taken over by the Analytical Model, which defines a Fact (measurable data like revenue or quantity) and links it to Dimensions (descriptive context such as product, customer, or region). The Analytical Model serves as a semantic layer, exposing business logic and relationships in a form that is directly consumable by SAP Analytics Cloud.

Query (BEx) → Analytical Model

BEx Queries define how data is consumed in BW reports. In SAP Datasphere, this functionality is handled by Analytical Models. These models support filters, input parameters, hierarchies, and measures, just like BW Queries, but with a streamlined experience for both developers and business users.

Process Chain → Replication Flow & Task Chain

SAP BW Process Chains automate sequences of data processing steps. SAP Datasphere replaces this with Replication Flows (for inbound and outbound) and Task Chains (for orchestrating processes).

Variable → Input Parameter

In SAP BW, Variables allow runtime input (e.g., year, region) during reporting. In SAP Datasphere, Input Parameters serve the same purpose and are defined in views or Analytical Models. They can also be used within joins, filters, and calculations, offering broader flexibility than their BW counterparts.

ABAP → SQL

ABAP is used extensively in SAP BW for transformations, exits, and enhancements. In SAP Datasphere, logic is implemented using SQL. Calculated columns, SQL views, and scripted transformations offer powerful alternatives.

Start Routine/End Routine → Join or Calculated Column

BW developers often use ABAP-based routines to apply custom logic. SAP Datasphere handles this by using Joins, Unions, Calculated Columns or SQL Views. While there's no ABAP here, the flexibility is retained through SQL-based logic.

DataSource → Local Table

DataSources in SAP BW are used for extracting and loading data from external systems. In SAP Datasphere, Local Tables or Remote Tables serve this function. One key difference: SAP Datasphere supports real-time federated access, so replication is optional rather than mandatory.

Hierarchy

Hierarchies exist in both environments but are handled differently. In SAP BW, they're often tied to InfoObjects. In SAP Datasphere, Hierarchies are modeled independently and linked to Dimensions via Associations. This makes them more reusable and context-specific. Just like SAP BW, Hierarchy’s can be time-dependent.

Texts

Text tables in SAP BW provide multilingual descriptions and labels. SAP Datasphere also uses Texts, which can be time- and language-dependent, in separate datasets, which are associated with Dimensions. Text logic remains the same, but SAP Datasphere's approach makes localization and semantic layering more consistent.

Conclusion

While SAP BW and SAP Datasphere differ architecturally and technically, their conceptual foundations are aligned. By understanding these object-level parallels, every BW developer can confidently build solutions in SAP Datasphere while leveraging their existing knowledge. Use this cheat sheet as your quick reference to accelerate your transition.

Want to know more about the transition from SAP BW to SAP Datasphere? Please contact Birgit Lardinois - birgit.lardinois@mccoy-partners.com or Li Starmans - li.starmans@mccoy-partners.com.