Integrating BW Queries with S/4HANA Embedded Analytics via CDS Views

Explanation

Embedded analytics in S/4HANA is built on the principle that transactional tables can be read live, in real time, without extraction, using CDS (Core Data Services) views annotated with analytical semantics. This is architecturally different from classical BW, where data is extracted, transformed, and persisted in InfoProviders before it can be queried. Understanding when to use embedded analytics CDS views versus BW queries is a core skill for any consultant working on S/4HANA or BW/4HANA landscapes. A CDS view intended for analytical consumption carries annotations such as @Analytics.query: true, which tells the system to expose it as an OData analytical service consumable by Fiori analytical apps, Analysis for Office, or SAP Analytics Cloud live connections. These views are built on top of interface views and basic views in a layered virtual data model (VDM), where basic views read directly from underlying transparent tables or database views, composite views combine multiple basic views with joins and unions, and consumption views add aggregation, filtering, and analytical annotations for reporting. The key difference from BW is persistence and latency. Embedded analytics CDS views execute their logic at query runtime against live operational tables in the S/4HANA database, so the data is always current to the second, but every query execution recalculates joins and aggregations on the fly. BW queries, by contrast, run against materialized InfoProviders where data has already been extracted, transformed, and often pre-aggregated, trading data freshness for predictable query performance and the ability to combine years of historical data without stressing the operational system. In practice, most enterprise landscapes use both approaches together. Embedded analytics is well suited to operational, tactical reporting needs such as open sales order monitoring, real-time inventory positions, or exception dashboards where users need current-day accuracy and the data volume is bounded by natural operational limits (open documents, current period). BW/4HANA remains the platform of choice for historical trend analysis, year-over-year comparisons, complex multi-source integration (combining SAP and non-SAP data), and scenarios requiring heavy transformation logic, data quality cleansing, or long-term data retention beyond what the operational system keeps online. Integration between the two is possible through several mechanisms. BW can extract from CDS-based extractors that reuse the same VDM views for consistent semantics between operational and warehouse reporting. Open ODS views in BW can also read directly from HANA database views or CDS views without a full transformation and DTP load, blurring the line between embedded analytics and BW modeling; this is often used for scenarios needing near-real-time integration without full ETL overhead. SAP Analytics Cloud can maintain live connections to both BW queries and embedded analytics CDS views, letting a single dashboard blend data from both worlds, though model design must carefully align dimensions and key figures to avoid confusing users with inconsistent granularity or currency conversion logic between the two data sources. From a technical implementation standpoint, consultants must understand that CDS analytical views inherit authorization checks from the underlying DCL (Data Control Language) role definitions rather than BW's classical authorization objects and analysis authorizations. This means security design is fundamentally different: BW analysis authorizations restrict by InfoObject characteristic values, while CDS views apply ABAP CDS roles or PFCG-based authorization checks that must be explicitly modeled per view. A common project risk is assuming BW authorization concepts transfer automatically to embedded analytics; they do not, and each CDS view's access control must be independently verified. Performance behavior also differs. Embedded analytics queries benefit from HANA's columnar in-memory processing for on-the-fly aggregation, but poorly designed CDS views with excessive nested views, non-equi joins, or currency/unit conversions in the wrong layer can cause serious runtime degradation directly against operational tables, which is riskier than a slow BW query because it can impact transactional system performance. Consultants should use tools like the ABAP CDS view analyzer or SQL trace against the generated database view to identify expensive joins before go-live, and should push filtering as early as possible in the view hierarchy (interface and basic view level) rather than relying on the consumption layer to filter large result sets. Cloud versus on-premise differences matter here too. In S/4HANA Cloud (public edition), extensibility and custom CDS view creation are governed by the released API and extensibility framework, with a more restricted set of extension points compared to on-premise or private cloud editions, where developers have broader access to the underlying VDM layers. Consultants must check the specific edition's extensibility scope before promising custom embedded analytics development, since public cloud customers often need to rely more heavily on SAP-delivered standard analytical apps supplemented by BW/4HANA for custom historical reporting.

Code example

-- Simplified example of an S/4HANA-style analytical CDS view definition-- (illustrative syntax only; actual field lists and associations vary by release) @AbapCatalog.sqlViewName: 'ZSALESORDERANLYT'@AccessControl.authorizationCheck: #CHECK@EndUserText.label: 'Sales Order Analytics - Consumption View'@Analytics.query: true@OData.publish: truedefine view ZC_SalesOrderAnalytics  as select from ZI_SalesOrderComposite as SalesOrder{      @AnalyticsDetails.query.axis: #ROWS  key SalesOrder.SalesOrganization,      @AnalyticsDetails.query.axis: #ROWS  key SalesOrder.CustomerId,      @AnalyticsDetails.query.axis: #ROWS  key SalesOrder.MaterialGroup,       @DefaultAggregation: #SUM      @Semantics.amount.currencyCode: 'TransactionCurrency'      SalesOrder.NetAmount,       SalesOrder.TransactionCurrency,       @DefaultAggregation: #SUM      SalesOrder.OrderQuantity}where  SalesOrder.DocumentCategory = 'C'  -- filter pushed down to reduce runtime aggregation cost -- Note: This view would sit on top of interface and basic views in a-- layered VDM; filtering here at the consumption layer is shown only-- for illustration. Best practice pushes filters as early as possible.

Real project scenario

A retail customer running S/4HANA on-premise wanted a real-time 'open orders and available stock' dashboard for regional sales managers, while finance continued to rely on BW/4HANA for month-end revenue reporting with full historical trending. The project team built a custom analytical CDS view on top of standard sales order and stock VDM views for the operational dashboard, exposed through a Fiori analytical list page, while BW/4HANA continued extracting the same sales documents nightly into an ADSO for finance's historical reports. During UAT, sales managers complained that the CDS view dashboard numbers didn't match the BW report for the current day, which was expected since BW data was as of the prior night's load; the team documented this latency difference clearly in user training materials and added a 'last refreshed' timestamp to the BW dashboard to avoid recurring confusion.

Common mistakes

• Assuming embedded analytics CDS views and BW queries will always show identical numbers, without accounting for extraction latency in BW versus live data in CDS views • Applying BW analysis authorization concepts to CDS views and expecting automatic equivalence, when CDS views require separate DCL/PFCG-based authorization design • Building deeply nested custom CDS views with joins and currency conversions in the consumption layer, causing performance problems directly against operational tables • Underestimating extensibility restrictions in S/4HANA Cloud public edition and promising custom CDS development that the edition does not support • Not pushing filters early enough in the VDM layer, leading to full table scans before aggregation • Failing to document to business users which reports are live (embedded analytics) versus latency-bound (BW), causing trust issues when numbers differ

Best practices

• Use embedded analytics CDS views for operational, low-latency reporting needs bounded by current transactional data volumes • Reserve BW/4HANA for historical trend analysis, multi-source integration, and scenarios needing heavy transformation or long-term retention • Push filtering and aggregation as early as possible in the VDM layer (interface/basic views) rather than the consumption layer • Design and test CDS view authorization (DCL) separately from BW analysis authorizations; do not assume equivalence • Clearly communicate data latency differences to business users when both embedded analytics and BW reports coexist for related data • Verify extensibility scope for the specific S/4HANA edition (on-premise, private cloud, public cloud) before committing to custom CDS view development • Use SQL trace or CDS view analysis tools to validate join and aggregation performance before productive go-live

Interview angle

Interviewers assess whether a candidate understands the architectural distinction between real-time embedded analytics (CDS-based, live, operational) and classical BW reporting (extracted, persisted, historical), and whether the candidate can explain how the two integrate rather than compete. Strong answers reference the layered VDM (interface, basic, composite, consumption views), the @Analytics.query annotation, differing authorization models between analysis authorizations and CDS DCL roles, and practical decision criteria for when to recommend embedded analytics versus BW/4HANA extraction for a given reporting requirement. Candidates should avoid overstating universal behavior and instead acknowledge differences across on-premise, private cloud, and public cloud editions.