ADSO Design: Keys, Activation, Delta Handling, and Change Log Behavior
Learn how to design ADSO semantic keys, understand the activation process, and configure delta and change-log behavior correctly for reliable production loads.
Explanation
Once a BW consultant understands ADSO types at a basic level, the next critical skill is designing the object's internal structure correctly, because key design and activation settings directly determine data correctness, load performance, and whether downstream delta extraction works at all. Semantic key design: For standard-type ADSOs, you define one or more InfoObjects (or fields) as the semantic key. Every incoming record with the same key value overwrites the previous record's non-key fields once activated, unless the ADSO is configured to accumulate key figures. This means the key must uniquely identify the business entity at the intended granularity - for example, sales document plus item number for order-line-level staging, or customer plus fiscal period for a monthly snapshot. A key that is too coarse causes silent data loss (later records overwrite earlier ones you actually needed), while a key that is too granular can explode table size unnecessarily and break intended aggregation logic. For write-optimized ADSOs, the system instead uses a technical key by default (request ID, data packet, record number), which guarantees every record is preserved even if there are duplicates by business key; you can optionally add semantic key fields for filtering/indexing but they do not enforce overwrite behavior in the same way. Activation process (standard-type only): When a DTP loads data into a standard ADSO, records first land in an inbound/activation queue table, not directly in the active table. Activation is a separate step (either automatic, triggered at the end of the DTP, or manual/scheduled in a process chain) that merges queue records into the active table, applying overwrite or accumulation logic based on the key, and simultaneously writes before/after images to the change log table. The change log is what enables the ADSO to act as a delta source for further DTPs downstream - without activation, there is no delta content to pull. This is a frequent troubleshooting point: if downstream loads show zero delta records, the first check is always whether the source ADSO's load was actually activated. Delta handling and extraction modes: A standard ADSO can serve full or delta extraction to downstream targets. Delta relies on the change log; if the change log is deleted (via housekeeping/archiving) or the request that generated it is deleted, downstream deltas will be broken and typically require a full reload of dependent targets. Write-optimized ADSOs also support delta extraction to downstream objects, but because there is no activation step, the delta is essentially every request loaded since the last successful delta pull. Request handling and rollback: Loads into ADSOs are request-based, similar to classic DSOs. A failed or incorrect load can usually be deleted (for the standard type, this may require deleting both from the active table via a reverse activation-like deletion and from the change log) before it propagates downstream. In production support, understanding whether a problematic request has already been activated and already extracted downstream is essential before deciding to delete-and-reload versus issuing a correction load. Performance considerations: Activation is a HANA-processing-intensive step for large volumes; project teams often schedule activation as a distinct process chain step with monitoring, rather than relying on automatic activation embedded in the DTP, so that large loads do not block subsequent chain steps unpredictably. SID generation timing (immediate vs. deferred) also affects load throughput versus query-time SID lookups, and should be tuned based on whether the ADSO is primarily a staging object or a reporting object.
Real project scenario
A finance BW team notices that a downstream ADSO used for management reporting is missing several days of transactions even though the process chain shows all loads as green. Investigation reveals the upstream standard-type ADSO's DTP loads were completing successfully but the separate activation step in the process chain had been failing silently due to a lock conflict with a parallel master data load. Because activation never ran, the change log had no new delta content for the downstream DTP to extract, even though the active table itself looked fine when queried directly.
Common mistakes
• Choosing a semantic key that is too coarse, causing unintended overwrites and silent loss of transactional detail. • Assuming data is available for delta extraction as soon as the DTP finishes, without verifying the activation step actually ran. • Deleting requests from the active table without also cleaning up the corresponding change log entries, leading to inconsistent delta state downstream. • Relying solely on automatic activation inside the DTP for very large loads, causing unpredictable process chain runtimes and lock contention with other loads. • Forgetting that write-optimized ADSOs do not enforce key uniqueness the way standard ADSOs do, leading to unexpected duplicate business records reaching downstream targets.
Best practices
• Design semantic keys at the exact grain required by downstream consumers, documenting the grain explicitly in the data model. • Run activation as an explicit, monitored process chain step for large-volume standard ADSOs rather than relying only on automatic activation. • Before deleting a request from an ADSO, check whether it has already been extracted downstream to avoid inconsistent delta chains. • Periodically review change log growth and align retention/archiving policy with delta extraction needs so cleanup does not break downstream deltas. • Use write-optimized ADSOs when duplicate preservation and load speed matter more than automatic overwrite semantics.
Interview angle
Expect scenario-based questions such as 'downstream delta shows zero records after a successful load - what do you check first?' The expected reasoning path is: verify activation ran, check change log content, then check DTP delta pointer status. Also be ready to explain the practical difference between semantic key overwrite logic in standard ADSOs versus technical key preservation in write-optimized ADSOs.