Skip to main content

Module 4: BW/4HANA DataStore Objects (aDSO)

Advanced DataStore Objects (aDSOs) are the central persistence objects in BW/4HANA.
In BW/4HANA 2.0, SAP moved from fixed templates to flexible, property-driven aDSO modeling.

This module explains:

  • What an aDSO really is
  • ALL aDSO types & variants in BW/4HANA 2.0
  • Internal tables (Inbound / Active / Change Log)
  • Differences vs BW/4HANA 1.0 & Classic BW
  • Best practices and architectural rules

1. What is an aDSO?​

An aDSO (Advanced DataStore Object) is a table-based persistence object that can act as:

  • Staging layer
  • Corporate memory
  • Harmonization layer
  • Data mart
  • Planning object
  • Inventory object
Key Shift

In BW/4HANA 2.0, an aDSO is defined by behavior (properties), not by rigid templates.

2. Evolution of DSOs → aDSOs​

SAP's persistence objects have evolved significantly across BW versions.

2.1 BW 7.5 (Classic BW)​

Objects Available:

  • Standard DSO
  • Write-Optimized DSO
  • Direct Update DSO
  • InfoCube
  • Inventory InfoCube

Characteristics:

  • Template-driven
  • Fixed behavior patterns
  • Limited flexibility

2.2 BW/4HANA 1.0​

Enhancement:

  • aDSO with Model Templates
  • Still template-driven thinking

Limitation:

  • Legacy mindset retained
Transition Phase

BW/4HANA 1.0 was a bridge solution with limited modernization.

2.3 BW/4HANA 2.0 (Current)​

Innovation:

  • One aDSO object
  • Behavior defined by modeling properties
  • Maximum flexibility
Interview Line

BW/4HANA 2.0 removed templates and introduced property-based aDSO modeling.

3. Core aDSO Categories in BW/4HANA 2.0​

BW/4HANA 2.0 defines four core aDSO categories, each with optional properties.

4. STANDARD aDSO (Most Important & Most Used)​

Purpose​

General-purpose persistent fact storage with delta handling.

Technical Characteristics​

  • Inbound Table ✅
  • Active Table ✅
  • Change Log Table ✅
  • Delta propagation ✅
  • Reporting-enabled ✅

Typical Usage​

  • Corporate Memory
  • Harmonization Layer
  • Delta Calculation Layer
  • Fact persistence

Mapping to Legacy Objects​

BW 7.5BW/4HANA 1.0BW/4HANA 2.0
Standard DSOStandard aDSO (template)Standard aDSO (with Change Log)
Best Practice

Standard aDSO is the default choice unless proven otherwise.

5. STAGING aDSO (Write-Optimized Replacement)​

Purpose​

High-volume data acquisition with minimal overhead.

Technical Characteristics​

  • Inbound Table ✅
  • Active Table ❌
  • Change Log ❌
  • Compression support ✅
  • Reporting ❌

Typical Usage​

  • Acquisition layer
  • PSA replacement
  • Near-source persistence

Mapping to Legacy Objects​

BW 7.5BW/4HANA 1.0BW/4HANA 2.0
Write-Optimized DSOWrite-Optimized aDSOStaging aDSO
Rule

Never report directly from a Staging aDSO.

6. DATA MART aDSO (InfoCube Replacement)​

Purpose​

Reporting-optimized persistent data mart.

Technical Characteristics​

  • Active Table only ✅
  • No Change Log ❌
  • Reporting-enabled ✅
  • Star-schema–like behavior
  • Can be inventory-enabled

Typical Usage​

  • Final reporting layer
  • Performance-critical queries
  • Inventory scenarios

Mapping to Legacy Objects​

BW 7.5BW/4HANA 1.0BW/4HANA 2.0
InfoCubeData Mart aDSOData Mart aDSO
SAP Strategy

Prefer Standard aDSO + CompositeProvider,
but Data Mart aDSO is valid for specific cases.

7. INVENTORY-ENABLED aDSO (Specialized)​

Purpose​

Handle non-additive stock data.

Characteristics​

  • Based on Data Mart aDSO
  • Inventory semantics enabled
  • Snapshot & delta logic

Typical Usage​

  • Stock quantities
  • Inventory valuation
  • Logistics reporting

Mapping to Legacy Objects​

BW 7.5BW/4HANA 2.0
Inventory InfoCubeInventory-enabled Data Mart aDSO
warning

Inventory modeling is complex — design carefully.

8. DIRECT UPDATE aDSO​

Purpose​

Allow direct writes without DTP.

Characteristics​

  • No inbound queue
  • No change log
  • Written via API or planning
  • Optional planning enablement

Typical Usage​

  • Manual adjustments
  • Write-back
  • Planning input

Mapping to Legacy Objects​

BW 7.5BW/4HANA 2.0
Direct Update DSODirect Update aDSO

9. PLANNING-ENABLED aDSO​

Purpose​

Support BW Integrated Planning.

Characteristics​

  • Based on Standard or Direct Update aDSO
  • Planning engine integration
  • Version handling

Typical Usage​

  • Budgeting
  • Forecasting
  • What-if scenarios
info

Planning aDSOs are relevant only if BW-IP is used.

10. SNAPSHOT-SUPPORTED aDSO​

Purpose​

Store point-in-time snapshots.

Usage​

  • Month-end balances
  • Slowly changing measures
  • Financial snapshots

Property​

  • Snapshot Support enabled

11. UNIQUE DATA RECORDS aDSO​

Purpose​

Ensure strict record uniqueness.

Usage​

  • Deduplicated facts
  • Master-data–like datasets

12. WRITE INTERFACE–ENABLED aDSO​

Purpose​

Allow external systems to write data.

Usage​

  • External planning tools
  • APIs
  • Hybrid landscapes

13. aDSO Internal Tables (Critical)​

Inbound Table​

  • Initial landing area
  • Write-optimized
  • No keys

Active Table​

  • Current valid state
  • Reporting layer

Change Log Table​

  • Delta storage
  • Downstream propagation
Inbound → Active → Change Log

14. aDSO vs Classic DSO (Summary)​

AspectClassic DSOaDSO (BW/4HANA 2.0)
FlexibilityLowVery High
PerformanceModerateHANA-optimized
TemplatesFixedProperty-based
FutureDeprecatedStrategic

15. Best Practices for aDSO Modeling​

Architecture Rules​

  • Use Staging aDSO only for acquisition
  • Use Standard aDSO for harmonization
  • Use CompositeProvider for reporting
  • Persist only when needed

Performance Rules​

  • Avoid unnecessary change logs
  • Minimize field count
  • Design keys carefully

Anti-Patterns​

Avoid

One aDSO per report
Reporting from Staging aDSO
Overusing Data Mart aDSOs
Mixing layers

16. Interview-Grade Explanation​

Q: Explain aDSOs in BW/4HANA 2.0

Answer: In BW/4HANA 2.0, aDSOs are flexible, property-based persistence objects replacing classic DSOs and InfoCubes. Depending on enabled properties, they can act as staging, standard, data mart, planning, or inventory objects, supporting modern LSA++ architectures with minimal redundancy and maximum HANA pushdown.

17. Summary​

  • aDSOs are the central persistence objects in BW/4HANA
  • BW/4HANA 2.0 uses property-based modeling, not templates
  • Standard aDSO is the default choice for most scenarios
  • Each aDSO type serves specific architectural purposes
  • Internal tables (Inbound, Active, Change Log) control behavior
  • Proper aDSO design is critical for performance and maintainability

18. What's Next?​

➡️ Module 5: InfoProviders & Modeling Objects
(CompositeProviders, Open ODS Views)

Final Learning Tip

In BW/4HANA 2.0, architecture matters more than object count.