Getting Started
Overview & Simplification
SAP BW/4HANA is SAP's next-generation data warehouse, built entirely and exclusively for the SAP HANA database. It represents a massive simplification over legacy BW systems.
The "Simplification" Philosophy
In traditional SAP BW (BW 7.x), modelers had to choose from over a dozen object types (InfoCubes, standard DSOs, Write-Optimized DSOs, MultiProviders, InfoSets, PSAs). In BW/4HANA, the object model has been drastically reduced and consolidated.
| Legacy BW Object | Replaced by in BW/4HANA |
|---|
| InfoCube | Advanced DSO (aDSO) |
| DataStore Object (Classic, Write-Optimized, Direct Update) | Advanced DSO (aDSO) |
| PSA (Persistent Staging Area) | Advanced DSO (aDSO) or obsolete via ODP |
| MultiProvider & InfoSet | CompositeProvider (HCPR) |
| VirtualProvider / TransientProvider | Open ODS View |
Modeling Interface: SAP GUI (RSA1) is largely retired for modeling. All BW/4HANA data modeling is performed in Eclipse via the SAP BW Modeling Tools (BWMT).
Key Benefits
- HANA Pushdown: Logic is pushed down to the HANA database level (via AMDP) rather than running in the ABAP application server, resulting in exponential performance gains.
- Agile Modeling: Virtualization (Open ODS views) allows connecting to data without physically copying it.
- Modern UI: Administration is handled in the web-based SAP BW/4HANA Cockpit (Fiori).
Getting Started
LSA++ Architecture
Layered Scalable Architecture (LSA++) is the best-practice framework for designing the data warehouse layers in BW/4HANA.
Evolution from LSA to LSA++
Traditional LSA (for non-HANA DBs) required heavy physical data duplication across multiple layers (Staging > Integration > Data Mart) to achieve acceptable query performance. LSA++ leverages HANA's in-memory speed to eliminate unnecessary physical layers and rely heavily on virtualization.
The LSA++ Layers
📥
Open Operational Data Store Layer
Entry point for data. Uses Field-based aDSOs or Open ODS Views to expose source data exactly as it is, without mapping to InfoObjects yet. Highly agile.
🗄️
Core Data Warehouse Layer
The "single version of truth." Data is cleansed, harmonized, and physically stored in InfoObject-based aDSOs. Historical tracking and delta mechanisms occur here.
Replaces physical InfoCubes. This layer is entirely virtual, utilizing CompositeProviders to join and union data from the Core layer for reporting in SAP Analytics Cloud or Analysis for Office.
Data Modeling
InfoObjects
InfoObjects remain the semantic backbone of BW/4HANA, providing shared master data, texts, and hierarchies across the warehouse.
Characteristics vs. Key Figures
- Characteristics: Represent business entities (e.g., Customer, Material, Cost Center). Can contain Attributes (properties), Texts (descriptions), and Hierarchies.
- Key Figures: Represent quantifiable measures (e.g., Revenue, Quantity, Discount). Must be associated with a Currency or Unit of Measure.
BW/4HANA Enhancements to InfoObjects
While the concept of InfoObjects existed in legacy BW, BW/4HANA introduces several optimizations:
- HANA Views: You can automatically generate an external SAP HANA Calculation View for an InfoObject to consume its master data directly in native HANA SQL or third-party tools.
- Enhanced Master Data Update: Master data can now be updated concurrently, removing legacy lock issues.
- XXL Attributes: Support for Extra Extra Large attributes (like strings or raw data up to 2GB) attached to a characteristic.
Field-based vs. InfoObject-based Modeling: In BW/4HANA, you don't *have* to use InfoObjects everywhere. You can model aDSOs using simple database fields (like CHARACT or INTEGER). This allows for rapid prototyping (Open ODS Layer). However, for governed reporting and hierarchy usage, InfoObjects are still required.
Data Modeling
Advanced DSO (aDSO)
The Advanced DataStore Object (aDSO) is the central persistence (storage) object in BW/4HANA, replacing all legacy InfoCubes and classic DSOs.
aDSO Table Architecture
An aDSO consists of three underlying HANA tables (similar to the classic DSO, but highly optimized):
- Inbound Table (/BIC/A...1): Where newly loaded data lands first.
- Active Data Table (/BIC/A...2): The table containing the compressed, harmonized "current state" of the data.
- Change Log (/BIC/A...3): Records the delta (before/after images) during activation, used to supply delta records to downstream targets.
Modeling Properties (Templates)
When creating an aDSO in Eclipse, you select a template property that dictates how the object behaves. This determines which of the 3 tables are used.
| Property Name | Legacy Equivalent | Behavior |
|---|
| Standard DSO | Standard DSO | Data writes to Inbound table. Requires Activation step. Generates a Change Log for downstream deltas. |
| Staging DSO | Write-Optimized DSO / PSA | Data writes directly to Inbound table only. No activation required. Highly performant for initial ingestion. |
| Data Mart DSO | InfoCube | Data is activated, but aggregates directly into the Active table. No Change Log is generated. Used for multidimensional reporting. |
| Direct Update DSO | Direct Update DSO | Data is written directly to the Active table via APIs or planning functions. Used in BW-IP / BPC Embedded. |
Data Modeling
CompositeProvider (HCPR)
The CompositeProvider is the universal virtual modeling object in BW/4HANA, replacing MultiProviders and InfoSets.
Core Functionality
A CompositeProvider (technically HCPR) does not store data. It executes UNION and JOIN operations on underlying physical providers (aDSOs, InfoObjects, or HANA Views) at query runtime using the speed of the HANA database.
JOIN vs. UNION:
• UNION: Appends data sets vertically. (e.g., combining Actuals from aDSO A and Plan data from aDSO B).
• JOIN: Appends data sets horizontally. Supports Inner, Left Outer, and Full Outer joins. (e.g., joining Sales Fact aDSO with a native HANA view containing external customer classifications).
Key Features
- Graphical drag-and-drop editor in Eclipse.
- Allows mapping of field-based data directly to InfoObjects at the virtual layer without writing physical transformation logic.
- The primary consumption object for BW Queries (Analytics Engine).
Data Modeling
Open ODS Views
Open ODS Views enable agile, virtual access to external data sources without the need for physical data extraction (ETL).
Agile Data Warehousing
Traditionally, bringing a new flat file or database table into BW took weeks (create InfoObjects, build DataSource, build DSO, build transformations, load data). With an Open ODS View, you can virtually consume a HANA database table or a remote source (via Smart Data Access) immediately.
Capabilities
- Field-Based: Exposes the raw structure of the source table.
- Semantics: Allows you to define which fields are characteristics and which are key figures, without creating actual InfoObjects.
- Swap Source: You can start virtually (pointing to a remote table), and later seamlessly swap the source to a physical aDSO without breaking the downstream reports.
Data Integration
ODP Framework (Operational Data Provisioning)
ODP is the strategic data extraction and replication framework in BW/4HANA, replacing traditional mechanisms like RSA7 delta queues and InfoPackages.
What is ODP?
ODP acts as a universal buffer (the Operational Delta Queue - ODQ) between source systems and BW/4HANA. It handles full and delta extractions highly efficiently, with built-in compression.
ODP Contexts (Source Types)
When creating a DataSource in BW/4HANA, you select an ODP Context based on the source:
| ODP Context | Used For |
|---|
| ODP-SAPI | Classic SAP Extractors (e.g., 2LIS_02_ITM, 0FI_GL_4) from ECC or S/4HANA. Replaces the old RSA7 setup. |
| ODP-CDS | Extracting data from ABAP Core Data Services (CDS) Views in S/4HANA. The modern way to extract S/4 data. |
| ODP-SLT | Trigger-based real-time replication via SAP Landscape Transformation Replication Server. |
| ODP-BW | Extracting data from another BW or BW/4HANA system. |
InfoPackages are Obsolete: Because the PSA layer is gone, InfoPackages no longer exist in BW/4HANA. Data is loaded directly from the ODP source into the aDSO using a Data Transfer Process (DTP).
Data Integration
Transformations & AMDP
Transformations map and convert data between source and target objects. In BW/4HANA, this logic is pushed down to the HANA database for maximum performance.
HANA Pushdown (AMDP)
In classic BW, transformations ran in the ABAP application server. Data had to be extracted from the DB, moved to the App server, processed row-by-row, and written back to the DB. This was slow.
BW/4HANA utilizes ABAP Managed Database Procedures (AMDP). If a transformation meets certain criteria (no complex ABAP custom logic), the system automatically compiles the transformation into a HANA SQLScript procedure. The entire transformation executes inside the HANA database memory instantly.
Custom Routines
If you need custom logic (Start Routine, Field Routine, End Routine), you have two choices in BW/4HANA:
- ABAP Routines: Classic ABAP. Forces the transformation to run on the ABAP server (slow).
- AMDP Script Routines: Write the routine using HANA SQLScript. Keeps the transformation pushed-down to the DB layer (fast).
Data Integration
DTPs & Process Chains
Data Transfer Processes move the data, and Process Chains orchestrate the automation.
Data Transfer Process (DTP)
In BW/4HANA, the DTP is the only object used to move data. It extracts directly from the ODP source (bypassing the PSA) and loads through the transformation into the aDSO.
- Delta Handling: The DTP communicates with the Operational Delta Queue (ODQ) to request only new/changed records.
- Error Stack: If records fail transformation, they are written to the DTP Error Stack. After fixing the data, an "Error DTP" can be run to process only the failed records.
Process Chains
Process chains are the scheduling and orchestration tool. They string together DTPs, aDSO Activation steps, DTO tiering movements, and attribute change runs into automated nightly batch jobs.
Streaming Process Chains: BW/4HANA introduces "Streaming" chains. Instead of running on a fixed schedule (e.g., 2:00 AM), streaming chains execute continuously in near-real-time as soon as new delta records arrive in the ODP queue.
Reporting & Analytics
BW Queries (Analytic Engine)
BW Queries are built on top of CompositeProviders to define the reporting dataset for end-users, utilizing the powerful SAP BW Analytic Engine.
BW Query Designer in Eclipse
BEx Query Designer is retired. Queries are now built exclusively within the Eclipse BW Modeling Tools.
Key Analytic Engine Capabilities
| Feature | Description |
|---|
| Calculated Key Figures (CKF) | Mathematical formulas executed at query runtime (e.g., Profit = Revenue - Cost). |
| Restricted Key Figures (RKF) | A key figure pre-filtered by a characteristic (e.g., "Revenue" restricted to Year = 2024). |
| Variables | Prompts that ask the user for input (e.g., select a Region) before executing the query. |
| Exceptions & Conditions | Exceptions highlight data (red/green) based on thresholds. Conditions filter the result set (e.g., "Top 10 Customers by Revenue"). |
Consumption: BW Queries are consumed directly by SAP Analytics Cloud (via Live Connection) or SAP Analysis for Microsoft Office.
Administration
Data Tiering Optimization (DTO)
HANA in-memory storage is expensive. DTO is a framework to automatically move older, less frequently accessed data to cheaper storage tiers based on rules.
The Temperature Concept
Storage: SAP HANA In-Memory.
Data: Highly accessed, recent data.
Performance: Maximum.
Storage: SAP HANA Extension Node / Native Storage Extension (NSE - disk).
Data: Less frequently accessed.
Performance: Slightly reduced.
Storage: SAP IQ (Near-line Storage - NLS) or Hadoop.
Data: Historical data required for compliance.
Performance: Slow, read-only.
How DTO Works
In the aDSO settings, you enable DTO and select a partitioning field (usually a Date or Time characteristic). You then define temperature rules (e.g., "Data older than 2 years moves to WARM. Data older than 5 years moves to COLD"). A DTO background job executes these rules, physically moving the partitions behind the scenes. The data remains completely transparent to the BW Query—the Analytic Engine knows where to find it.
Administration
BW/4HANA Cockpit
The web-based SAP Fiori interface used for monitoring and administrating the BW/4HANA system.
Replacing SAP GUI (RSA1)
While modeling moved to Eclipse, administration moved to the Web. The BW/4HANA Cockpit provides Fiori tiles for:
- Process Chain Monitoring: Visual flowcharts of running chains, with error tracking and restart capabilities.
- Data Volume Management: Dashboards showing which aDSOs are consuming the most HANA memory, assisting with DTO strategies.
- Manage aDSOs: Activating data, deleting requests, and managing the active/inbound tables.
- Connections: Managing Source Systems (ODP, HANA, SDA).
Administration
Migration Paths
Moving from a legacy BW system (7.x) to BW/4HANA requires converting legacy objects (InfoCubes) to BW/4HANA optimized objects (aDSOs).
The Three Transition Paths
| Path | Scenario | Process |
|---|
| In-Place Conversion | Current system is already BW on HANA and highly standardized. | System is kept intact. Legacy objects are converted to aDSOs using the Transfer Tool within the same system, step-by-step. |
| Remote Conversion | Current system is messy, but you want to keep existing data and models. | Build a brand new, empty BW/4HANA system. Use the Transfer Tool to import data models and historical data over the network from the old system, converting them on the fly. |
| Shell Conversion | Greenfield approach. | Similar to Remote, but only the metadata (structure) is moved and converted. No historical data is transferred. Data is re-loaded from the source systems. |
SAP Readiness Check: Before any migration, SAP provides a Readiness Check tool that analyzes the legacy BW system and flags custom ABAP code or obsolete objects that will break in BW/4HANA.