Designing Analytical CDS Views and Embedded BW Queries

Explanation

Once the decision has been made to use embedded analytics for a given reporting requirement, the implementation work centers on two closely related technical paths: pure ABAP CDS-based analytical queries, and embedded BW queries built on top of CDS-based virtual InfoProviders. Understanding how these fit together is essential for intermediate-level design work. Analytical CDS views are built using CDS annotations that describe analytical semantics on top of a data model. A basic CDS view exposes fields from one or more underlying database tables (often joining several standard S/4HANA tables), and analytical annotations mark certain fields as measures (with aggregation behavior such as SUM) and others as dimensions or characteristics. Additional annotations can define currency/unit conversion, hierarchies, and default aggregation. These CDS views can be layered: a basic interface view exposes raw fields, a composite view adds joins and associations, and a consumption view (often prefixed for analytical use) adds the OData/analytical annotations that make it consumable by Fiori elements, SAP Analysis for Office, or embedded BW. Embedded BW builds on this by allowing a BW query to be defined against a virtual InfoProvider that is generated from an underlying CDS view (rather than against a physically loaded InfoCube or ADSO). This virtual InfoProvider behaves like a standard BW InfoProvider from the BW modeling and query design perspective — you can add restricted/calculated key figures, variables, navigational attributes, and hierarchies in the BW query designer — but at execution time, no BW-owned physical data is read; the query pushes down to the underlying CDS view, which in turn reads live application tables. This gives consultants familiar with BW query design a consistent tool set (BEx-style query definition, now typically done via BW modeling tools in Eclipse) while still achieving real-time, non-replicated reporting. A critical integration point is that these virtual InfoProviders can, in many landscapes, be combined with classic physical InfoProviders in a MultiProvider or CompositeProvider, allowing a single BW query to blend real-time operational data with historically loaded BW content. This is a common design pattern: current-month data comes live from the embedded virtual InfoProvider, while prior periods come from an already-loaded ADSO, giving both freshness and long-term trend analysis in one report. From a runtime perspective, when a user opens a report built on an embedded BW query, the request flows: front-end tool -> BW OLAP engine -> virtual InfoProvider -> underlying CDS view -> SQL pushed to HANA -> aggregation results returned. Because this all happens against live application tables, any locking, authorization, or data volume issue in the source tables directly affects report performance and correctness. This is different from classic BW reporting, where the query reads from data that was already cleansed, transformed and physically staged during load. Security design also differs: end users need not only BW-level authorization (via InfoProvider/query-level authorization concepts) but their access must respect underlying S/4HANA authorization objects surfaced through the CDS view's built-in authorization checks (data control language annotations), so authorization design must be coordinated between the BW/reporting team and the S/4HANA functional/security teams — a coordination point often underestimated in projects. S/4HANA on-premise and private cloud editions generally give more flexibility to extend or create custom analytical CDS views and embedded BW content, while S/4HANA Cloud (public edition) typically restricts custom development to defined extensibility frameworks and delivered extension points, so the same design pattern may need to be implemented differently or may have limited customization options depending on the deployment model; teams must verify current extensibility scope for their specific cloud release rather than assuming on-premise flexibility applies.

Code example

-- Simplified illustrative example of an analytical CDS view definition pattern-- (conceptual syntax, not a guaranteed working snippet)@AbapCatalog.sqlViewName: 'ZSDANLYORDER'@AccessControl.authorizationCheck: #CHECK@Analytics.dataCategory: #CUBE@EndUserText.label: 'Sales Order Analytical View'define view Z_C_SalesOrderAnalytics as select from vbap as OrderItem  association [1..1] to vbak as _Header on $projection.SalesOrder = _Header.Vbeln{  key OrderItem.vbeln as SalesOrder,  key OrderItem.posnr as SalesOrderItem,  _Header.vkorg      as SalesOrganization,  OrderItem.matnr    as Material,  @Semantics.amount.currencyCode: 'Currency'  @DefaultAggregation: #SUM  OrderItem.netwr    as NetAmount,  OrderItem.waerk    as Currency,  _Header}

Real project scenario

A manufacturing company needed a plant-level production variance report combining current week live data with two years of historical variance data already stored in BW/4HANA ADSOs. The team built an analytical CDS view over the current production confirmation tables, exposed it as a virtual InfoProvider in embedded BW, and combined it with the historical ADSO in a CompositeProvider, giving plant managers one query showing trend plus live current-week figures without a nightly load for the current period.

Common mistakes

• Designing analytical CDS views directly on heavily normalized custom tables without considering join performance on large data volumes • Forgetting to define currency/unit conversion annotations, leading to incorrect aggregated amounts • Mixing virtual and physical InfoProviders in a CompositeProvider without validating consistent key figure and characteristic compatibility • Not coordinating S/4HANA CDS authorization (DCL) design with BW query-level authorization, causing users to see unauthorized or missing data • Assuming S/4HANA Cloud extensibility allows the same custom CDS development freedom as on-premise systems

Best practices

• Layer CDS views (interface, composite, consumption) to keep reusable logic separate from analytical-specific annotations • Explicitly define currency and unit conversion annotations on all amount and quantity measures • Use CompositeProviders to blend virtual (live) and physical (historical) InfoProviders when both freshness and trend history are required • Coordinate authorization design between CDS-level DCL checks and BW query authorizations early in the project • Confirm current extensibility and custom CDS development scope for the specific S/4HANA deployment model before committing to a design

Interview angle

Candidates are frequently asked to describe how a BW query can run against live S/4HANA data without extraction; a strong answer explains analytical CDS views, virtual InfoProviders in embedded BW, and how CompositeProviders can blend live and historical data, along with the authorization coordination required.