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

Explanation

BW/4HANA modeling centers on three primary object types that together replace the entire classic BW object landscape: Advanced DataStore Objects (ADSOs), Open ODS Views, and CompositeProviders. Understanding how to combine these correctly is the core modeling skill for intermediate BW/4HANA work. An ADSO is a flexible container that can be configured with different property combinations to behave like a classic DataStore Object (with change log and activation), like a classic write-optimized DSO (fast loading without activation queue), or in a way suitable for direct reporting without further transformation. This flexibility means a modeler chooses ADSO properties - such as whether to enable the change log, whether records overwrite or accumulate, and how activation should occur - rather than picking between entirely separate object types as in classic BW. A typical layered model still follows a similar logical structure to classic BW's LSA++ (Layered Scalable Architecture): a corporate memory or acquisition layer ADSO staging raw data close to source format, a harmonization/propagation layer where cleansing and business rules are applied through transformations, and a reporting layer ADSO or CompositeProvider optimized for query consumption. Open ODS Views are a distinguishing BW/4HANA capability: they allow virtual modeling directly against HANA-native tables, HANA calculation views, or even external tables without physically loading data into BW at all. This is valuable when data already resides in HANA (for example, from an S/4HANA source or a data lake accessible via HANA) and duplicating it through a full ETL cycle would waste time and storage. Open ODS Views can participate as source data for transformations or be exposed directly in CompositeProviders, giving architects flexibility to blend virtual and physical data. CompositeProviders are the union/join layer, replacing both classic MultiProviders (union) and InfoSets (join) with a single object supporting both operations in one definition, executed in-memory in HANA. This matters for performance because joins that used to happen at the OLAP engine level in classic InfoSets, often less efficiently, now push down to HANA's optimized join processing. When designing a CompositeProvider, modelers must be careful about join cardinality, since incorrect join types (inner vs left outer) between ADSOs of different granularities can silently drop or duplicate records, a very common source of query discrepancies. Transformations and DTPs remain the mechanism for moving data between ADSOs, largely unchanged conceptually from classic BW, but with encouragement to push more transformation logic (formulas, lookups) into HANA-optimized routines rather than ABAP-based routines wherever feasible, since AMDP (ABAP Managed Database Procedures) based transformations execute inside HANA and avoid moving data to the application server for row-by-row processing. When migrating from classic BW, a classic standard DataStore Object typically converts to an ADSO with comparable settings, and classic InfoCubes are generally remodeled into ADSOs with characteristics for what were dimensions and key figures for what were fact table measures, since a physical star schema with separate dimension tables is no longer required for storage - HANA's columnar engine and CompositeProvider joins handle this differently. InfoSets and MultiProviders must be redesigned as CompositeProviders, and this redesign is often the most labor-intensive part of migration because InfoSet join logic and MultiProvider constant selection rules do not map one-to-one and require manual re-validation against expected report output. On the query side, BEx queries generally continue to function against converted objects, but architects should re-test navigational attributes, hierarchies, and any object relying on aggregates, since classic aggregates are not part of the BW/4HANA model - performance is instead handled through HANA's native processing, so any performance tuning after migration should focus on model simplification and appropriate indexing rather than recreating aggregate-like structures.

Code example

-- Simplified illustration of push-down logic for an AMDP-based transformation-- (represented conceptually, not a full ABAP class)-- METHOD execute.--   lt_result = SELECT--                 sales_order_id,--                 customer_id,--                 SUM( net_value ) AS total_net_value--               FROM /bic/aadso_sales_stg--               GROUP BY sales_order_id, customer_id.--   -- result set is aggregated inside HANA before being written to target ADSO-- ENDMETHOD.-- Key point: aggregation happens in the HANA database layer via AMDP,-- avoiding row-by-row ABAP processing during the transformation step.

Real project scenario

During a migration project, a classic InfoSet joining a sales DSO with a customer master DSO is converted into a CompositeProvider. The original InfoSet used a left outer join to always show sales records even without matching customer master data. The migration team initially recreates it as an inner join by default, causing sales figures in test reports to drop compared to the legacy system. Root cause analysis traces the discrepancy to the join type mismatch, and the fix involves explicitly configuring the CompositeProvider join as left outer and re-validating totals against the legacy BEx query output.

Common mistakes

• Defaulting to inner joins in CompositeProviders without validating against the original InfoSet or MultiProvider logic • Overusing Open ODS Views for high-volume, frequently-queried data without considering the performance impact of repeated virtual access versus physical staging • Recreating ABAP routine-heavy transformations unchanged instead of evaluating AMDP-based alternatives for performance-critical loads • Not revalidating navigational attributes and hierarchies after converting classic InfoProviders to ADSOs • Assuming ADSO activation settings from a converted classic DSO are automatically optimal rather than reviewing them against actual reporting requirements

Best practices

• Map every classic InfoSet join type and MultiProvider selection rule explicitly before building the corresponding CompositeProvider • Use Open ODS Views selectively for genuinely volatile or low-latency-required source data, not as a default replacement for physical staging • Prefer HANA-optimized transformation logic (AMDP) over ABAP routines for high-volume or computation-heavy transformations • Re-test all BEx queries against converted objects with representative data volumes, not just sample records • Maintain a mapping document from legacy objects to new BW/4HANA objects for audit and support handover purposes

Interview angle

Interviewers frequently probe whether a candidate understands the practical difference between a CompositeProvider join and union, and why InfoSet-to-CompositeProvider migration is considered higher risk than simple DSO-to-ADSO conversion. Being able to describe a real join cardinality issue and how it was diagnosed demonstrates hands-on modeling competence rather than only textbook knowledge.