Modeling with ADSOs, CompositeProviders, and Open ODS Views in BW/4HANA

Explanation

Once a consultant understands that BW/4HANA replaces classic InfoProviders with a reduced object set, the next skill is actually designing a data flow with these objects. The Advanced DataStore Object (ADSO) is the workhorse: a single object type configured with different property combinations to behave like a staging layer, a corporate-memory/harmonization layer, or a reporting layer. Key ADSO properties include whether it has an inbound table, a table of new/active data, and a change log, and whether it supports overwrite or additive (summation) semantics for key figures. Choosing the right combination is a modeling decision with real performance and semantic consequences: a reporting-layer ADSO typically needs only the active table with reporting flagged on for fast query access, while a corporate-memory ADSO retaining full history may need the change log enabled to support delta extraction to further layers. Data flows into an ADSO through transformations and Data Transfer Processes (DTPs), much as in classic BW. Transformation rules map source fields (from a DataSource, another ADSO, or an Open ODS View) to target InfoObjects, and can include routines, formulas, and lookups similar to classic BW, though the underlying execution is HANA-optimized where possible (for example, certain rule types can push down processing to the database rather than the application server). DTPs control extraction mode (full vs delta), filters, and semantic grouping/error handling, and remain essential for both real-time and scheduled loads. CompositeProviders combine multiple ADSOs, InfoObjects, or Open ODS Views at query time using union or join operations, replacing both classic MultiProviders (which only supported union) and InfoSets (which supported joins). This unification simplifies reporting design because a single object type can express both cross-provider stacking (union, e.g., combining current year and historical ADSOs) and relational joins (e.g., combining a transactional ADSO with a master-data-heavy dimension object) without choosing between two legacy object types. CompositeProviders are typically the primary object exposed to BEx queries or other reporting tools, keeping the underlying ADSOs as pure storage layers. Open ODS Views provide virtual access to source data—often directly to database tables, external sources via smart data access, or other exposed HANA views—without physically staging the data into BW. They are useful for prototyping, ad hoc data exploration, or scenarios where full staging is unnecessary, but because they do not persist data, they are not a substitute for a properly staged corporate-memory layer where auditability, historization, or complex transformation logic is required. From a troubleshooting perspective, common load issues in BW/4HANA data flows mirror classic BW: DTP delta queue inconsistencies, transformation routine errors, and duplicate-record handling in ADSOs governed by the object's key and semantic key settings. Monitoring load performance requires checking whether transformations are running in HANA-pushdown mode versus ABAP-based processing, since pushdown-eligible logic performs far better at scale. Process chains orchestrate the same load-then-activate-then-further-propagate pattern as classic BW, but the target objects in each chain step are now ADSOs and CompositeProviders rather than InfoCubes and classic DSOs. Design decisions here directly affect production support: an over-modeled landscape with excessive ADSO layers reintroduces the redundancy problem BW/4HANA was meant to solve, while an under-modeled landscape (skipping a proper corporate-memory layer in favor of only reporting-layer ADSOs or Open ODS Views) can create historization and reprocessing gaps that are painful to fix later. Consultants should apply a layered-but-lean approach: acquisition ADSO, optional harmonization/corporate-memory ADSO, and reporting ADSO or CompositeProvider, adding layers only when there is a clear business or technical justification such as auditability, reuse across multiple downstream targets, or complex conforming/harmonization logic.

Code example

* Example ABAP-style transformation routine snippet used inside a BW/4HANA transformation rule* (conceptual illustration only; actual syntax depends on transformation rule type and release) METHOD compute_target_field.  " Simple example: derive a fiscal period flag from a posting date field  IF source_fields-posting_date IS NOT INITIAL.    IF source_fields-posting_date(4) = sy-datum(4).      result = 'CURRENT_YEAR'.    ELSE.      result = 'PRIOR_YEAR'.    ENDIF.  ELSE.    result = 'UNKNOWN'.  ENDIF.ENDMETHOD. * Note: many simple mappings (direct assignment, constant, formula)* should be modeled as formula/rule-type transformations rather than* ABAP routines when possible, since these are more likely to be* pushed down for HANA-optimized execution and are easier to maintain.

Real project scenario

A manufacturing client needs a BW/4HANA model to report on production orders sourced from an S/4HANA system. The team designs an acquisition ADSO to stage raw order data with a change log for auditability, a harmonization ADSO to apply plant-specific business rules and conform material master attributes, and a reporting-layer ADSO exposed through a CompositeProvider that joins it with a separate cost-center master-data ADSO. During UAT, users report slow dashboard response; the consultant traces the issue to a transformation routine on the harmonization layer written as ABAP logic that could have been expressed as a formula, preventing HANA pushdown, and reworks it to restore expected performance.

Common mistakes

• Creating excessive ADSO layers 'just in case', recreating the redundancy problem BW/4HANA modeling is meant to avoid. • Using ABAP routines for simple field mappings that could be formulas, losing HANA pushdown performance benefits. • Relying on Open ODS Views for scenarios that actually require historized, auditable staged data. • Misconfiguring ADSO table settings (e.g., omitting the change log) and then discovering delta extraction to downstream layers is not possible. • Building CompositeProviders with unnecessary joins across large ADSOs without checking the performance impact on query runtime.

Best practices

• Configure ADSO settings deliberately based on the object's role (staging vs corporate memory vs reporting), not by default. • Prefer formula and rule-type transformation logic over ABAP routines when performance-sensitive HANA pushdown is desired. • Use CompositeProviders as the primary reporting-facing object, keeping ADSOs as clean storage layers underneath. • Reserve Open ODS Views for exploration or lightweight virtual access, not as a substitute for governed, historized staging. • Periodically review the data flow for unnecessary layers as the model evolves, since scope creep can reintroduce classic BW-style complexity.

Interview angle

Interviewers often probe whether a candidate can explain when to use a union-based CompositeProvider versus a join-based one, and how ADSO type settings (active table only vs including change log) affect delta capability and reporting performance. Being able to describe a concrete layered design (acquisition, harmonization, reporting) rather than a generic answer signals real project experience.