ADSO Fundamentals: What It Is and Why It Replaced Classic BW Objects
Understand what an Advanced DataStore Object (ADSO) is, why SAP introduced it, and the different ADSO types you will configure in real BW/4HANA projects.
Explanation
Before BW/4HANA, SAP BW modelers had to choose between several separate object types for persistence: InfoCubes for reporting-optimized star schemas, standard DataStore Objects for staging and corporate memory, and write-optimized DataStore Objects for fast, unaggregated loads. Each had different tables, different delta handling, and different capabilities, which made modeling decisions complex and migrations painful. The Advanced DataStore Object (ADSO) was introduced to unify these patterns into a single object type built natively on HANA, so that one object can be configured to behave like any of the legacy patterns simply by changing its type and settings. An ADSO is fundamentally a set of HANA database tables (an active table, and depending on type, a change log and/or activation queue table) managed through the BW modeling layer. When you create an ADSO in the BW modeling tools (Eclipse-based ADT or the web-based modeling tools in BW/4HANA), you choose a template type that determines its behavior: 1. Standard DataStore Object (Type: Standard) - has an active data table, a change log, and an activation queue. Data loaded via a request must be activated before it becomes visible in the active table and to queries. This mirrors classic standard DSOs and is typically used for corporate memory or a consolidated staging layer where you need before/after image tracking and delta capability. 2. Write-Optimized (Type: Write-Optimized, sometimes still called write-optimized ADSO) - has only an active table; data is available for reporting or further processing immediately after loading, without a separate activation step. This is the natural choice for the first staging layer (often called the corporate memory or acquisition layer) because loads are fast and technical keys are used instead of a full semantic key, preserving every record exactly as received from the source. 3. Data Mart type / InfoCube-like configuration - an ADSO can be configured with a structure resembling a star schema (key figures and characteristics) to serve reporting needs previously handled by InfoCubes, while still benefiting from HANA push-down processing. 4. All Characteristics / flat structure - used for master-data-like or highly denormalized reporting layers. Each ADSO also has settings controlling whether it supports reporting (BEx/queries can read it directly), whether it supports direct update (via APIs or DTP only), and whether SID generation is immediate or deferred. These settings matter because they affect query performance and the load process design. In a typical layered BW/4HANA architecture (often called LSA++), you will see ADSOs used at every layer: a write-optimized ADSO for the acquisition/corporate memory layer, a standard ADSO for the propagation or harmonization layer where business rules and cleansing happen, and a reporting-optimized ADSO (or CompositeProvider layering on top of ADSOs) at the top for consumption. Understanding which ADSO type belongs at which layer is the first modeling decision a BW consultant makes on any project, and getting it wrong leads to either poor load performance (using standard type everywhere, forcing unnecessary activation steps) or loss of auditability (using write-optimized where change tracking is actually required).
Real project scenario
A retail company migrating from BW-on-HANA standard DSOs to BW/4HANA redesigns its sales staging layer. The consultant creates a write-optimized ADSO to receive raw daily sales extracts from source systems with technical keys (request, packet, record number) so loads never fail due to duplicate semantic keys. Downstream, a standard-type ADSO applies currency conversion and customer master lookups, and exposes the cleansed data for reporting via a CompositeProvider that also blends in a second ADSO holding budget data.
Common mistakes
• Using a standard-type ADSO for the initial staging layer, forcing unnecessary activation steps and slowing daily loads. • Enabling reporting flags on every ADSO layer without a governance reason, which increases query complexity for end users who can now query staging data by mistake. • Assuming ADSO behaves identically across all BW/4HANA versions without checking the specific modeling tool being used (Eclipse ADT vs. web-based tools) for available settings. • Not distinguishing between the active table and change log when troubleshooting missing records in reports; users often look only at the active table.
Best practices
• Match ADSO type to the layer's actual requirement: write-optimized for raw acquisition, standard for staging with change tracking, reporting-enabled for consumption. • Only enable the reporting flag on ADSOs intended for direct business consumption. • Document the chosen ADSO type and rationale in the data model design document for future support teams. • Review naming conventions so ADSO names indicate their layer and type at a glance (e.g., prefix conventions agreed with the project team).
Interview angle
Interviewers commonly ask candidates to explain the difference between a write-optimized and standard ADSO, and to justify layer placement in an LSA++ architecture. Be ready to explain why ADSO replaced InfoCubes and DSOs, what tables underlie each type, and how activation affects data visibility timing.