CompositeProvider Fundamentals: Purpose and Architecture
Understand what a CompositeProvider is, why SAP introduced it, and how it replaces legacy MultiProvider and InfoSet objects in HANA-based BW modeling.
Explanation
A CompositeProvider is a HANA-optimized modeling object introduced in BW-on-HANA and made the standard combination InfoProvider in BW/4HANA. It lets a modeler combine data from multiple sources - InfoCubes, DataStore Objects (advanced), InfoObjects, HANA-native views (calculation views, analytic views), and even other CompositeProviders - into a single reporting-ready object without necessarily persisting data physically. Why it matters: before CompositeProvider, BW modelers used two separate objects for combination logic - the MultiProvider (union-only, executed at OLAP engine level) and the InfoSet (join-only, also OLAP engine level). Both had performance limitations because the combination logic ran outside HANA, pulling large result sets into the BW application server or OLAP engine for further processing. CompositeProvider pushes union and join operations down into the HANA database calculation engine, which means joins and unions execute close to the data, significantly reducing data transfer and improving query runtime, especially on large fact tables. Architecturally, a CompositeProvider is defined using two node types: UNION nodes, which stack rows from multiple providers into one result set (similar to MultiProvider logic), and JOIN nodes, which combine columns from different providers based on matching characteristics (similar to InfoSet logic, but now including inner, left outer, and referential joins with more flexibility). You can mix these operations in the same CompositeProvider by nesting union and join steps, something InfoSets and MultiProviders never allowed simultaneously. CompositeProvider also acts as a bridge in hybrid landscapes: it can directly consume HANA calculation views or analytic views (exposed as InfoProviders through HANA modeling integration), enabling BW to report on native HANA models alongside classic BW InfoProviders. This is essential in scenarios combining SAP-delivered extraction content with custom HANA-side data marts. In terms of persistence, a CompositeProvider itself does not usually store data - it is a virtual view (though a persisted local variant exists in some scenarios, called a CompositeProvider with data persistency, which snapshots data into an underlying table for performance predictability at the cost of data currency). Most implementations use the virtual variant so queries always reflect the latest data in underlying providers. From a lifecycle perspective, CompositeProvider is created and maintained in BW modeling tools (Eclipse-based BW/4HANA Modeling perspective or SAP BW/4HANA Cockpit in later releases), not in the classical Data Warehousing Workbench transaction used for older objects. In BW/4HANA, CompositeProvider is effectively mandatory for any multi-source reporting scenario since MultiProvider and InfoSet do not exist as native objects there; in BW-on-HANA (i.e., classic BW running on the HANA database), all three objects (MultiProvider, InfoSet, CompositeProvider) can coexist, giving migration flexibility. Beginners should understand CompositeProvider first as a reporting-layer construct: it sits above the data acquisition and transformation layers (source systems, DSOs, InfoCubes) and is typically the object exposed to BEx queries or reporting tools like SAP Analytics Cloud. Getting the underlying granularity, key figures, and characteristics correctly aligned across combined providers is the foundation for accurate results - mismatched aggregation levels or unmatched characteristics between joined providers are the most common source of confusing query output for newcomers.
Real project scenario
A retail client migrating from BW7.5 on HANA to BW/4HANA had a sales reporting MultiProvider that unioned three InfoCubes (POS sales, online sales, returns) plus an InfoSet joining sales data to a customer master DSO for CRM segment attributes. During migration, the team consolidated this into a single CompositeProvider using a UNION node for the three sales sources and a JOIN node bringing in the CRM segment DSO, eliminating two separate objects and reducing query response time by pushing the join logic into HANA instead of the OLAP engine.
Common mistakes
• Assuming CompositeProvider always physically stores data, when in most designs it is virtual and reads live from underlying providers • Mixing incompatible granularities in a UNION node (e.g., daily vs monthly aggregated cubes) without a common time characteristic, causing double-counting or gaps • Using INNER JOIN when LEFT OUTER JOIN is needed, silently dropping fact rows that lack a matching master data or attribute record • Not checking that combined InfoProviders share consistent InfoObjects (same characteristic, not just same technical name) before wiring a join • Treating CompositeProvider modeling in Eclipse the same as legacy MultiProvider maintenance in the old transaction-based workbench, missing new node-based UI concepts
Best practices
• Use CompositeProvider as the standard combination object for any new BW-on-HANA or BW/4HANA development, even if legacy objects still exist • Confirm characteristic compatibility (same InfoObject, same master data source) before designing a JOIN node • Prefer virtual (non-persisted) CompositeProviders unless there is a documented performance or stability reason to persist • Document which underlying providers feed each CompositeProvider to simplify impact analysis during future changes • Validate output row counts against source providers after building a UNION node to catch unintended duplication
Interview angle
Interviewers commonly ask candidates to explain the difference between MultiProvider, InfoSet, and CompositeProvider, and why CompositeProvider is mandatory in BW/4HANA. A strong answer highlights that CompositeProvider unifies union and join capability in one object, pushes processing into the HANA calculation engine instead of the BW OLAP engine, and can directly consume HANA-native views - none of which the legacy objects could do together.