Advanced Embedded Analytics: Architecture, Integration and Production Design (Part 4)

At senior and architect level, Embedded Analytics should be understood as an end-to-end design problem rather than a list of isolated features.

Core design map
What Embedded Analytics Is and Why It Matters: Introduces the concept of embedded analytics in SAP S/4HANA, contrasting it with classic BW extraction-based reporting and explaining the business drivers for real-time, in-app analysis.

Designing Analytical CDS Views and Embedded BW Queries: Explains how to design and build analytical CDS views and embedded BW queries against S/4HANA data, including annotations, virtual InfoProviders, and integration with reporting tools.

Integrating BW Queries with S/4HANA Embedded Analytics via CDS Views: Learn how S/4HANA embedded analytics CDS views expose operational data directly for analytical consumption, how they relate to BW queries and InfoProviders, and how consultants design hybrid reporting architectures that combine live operational data with historical BW data.

Architecture and production criteria

• Clearly communicate data latency differences to business users when both embedded analytics and BW reports coexist for related data
• Confirm current extensibility and custom CDS development scope for the specific S/4HANA deployment model before committing to a design
• Coordinate authorization design between CDS-level DCL checks and BW query authorizations early in the project
• Design and test CDS view authorization (DCL) separately from BW analysis authorizations; do not assume equivalence
• Document the chosen architecture rationale so future teams understand why a given report was built as embedded analytics versus extracted BW content
• Explicitly define currency and unit conversion annotations on all amount and quantity measures
• Keep BW/4HANA or a dedicated warehouse for heavy historical, multi-source, or complex transformation-driven reporting
• Layer CDS views (interface, composite, consumption) to keep reusable logic separate from analytical-specific annotations
• Push filtering and aggregation as early as possible in the VDM layer (interface/basic views) rather than the consumption layer
• Reserve BW/4HANA for historical trend analysis, multi-source integration, and scenarios needing heavy transformation or long-term retention
• Start every reporting requirement discussion by asking about acceptable data latency and historical depth needed
• Use CompositeProviders to blend virtual (live) and physical (historical) InfoProviders when both freshness and trend history are required
• Use embedded analytics CDS views for operational, low-latency reporting needs bounded by current transactional data volumes
• Use embedded analytics for real-time operational reporting on core S/4HANA business objects with moderate complexity
• Use SQL trace or CDS view analysis tools to validate join and aggregation performance before productive go-live
• Validate embedded analytics performance impact on the production system before wide rollout
• Verify extensibility scope for the specific S/4HANA edition (on-premise, private cloud, public cloud) before committing to custom CDS view development

Failure analysis and operational risk

• Applying BW analysis authorization concepts to CDS views and expecting automatic equivalence, when CDS views require separate DCL/PFCG-based authorization design
• Assuming embedded analytics can fully replace BW/4HANA for all reporting, including multi-year trend and cross-system harmonization needs
• 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
• Assuming S/4HANA Cloud extensibility allows the same custom CDS development freedom as on-premise systems
• Building deeply nested custom CDS views with joins and currency conversions in the consumption layer, causing performance problems directly against operational tables
• Building embedded analytics on heavily customized custom tables without proper CDS modeling, causing poor performance
• Designing analytical CDS views directly on heavily normalized custom tables without considering join performance on large data volumes
• Failing to assess data volume and query complexity before choosing embedded analytics over extraction-based BW
• Failing to document to business users which reports are live (embedded analytics) versus latency-bound (BW), causing trust issues when numbers differ
• Forgetting to define currency/unit conversion annotations, leading to incorrect aggregated amounts
• Ignoring that embedded BW still consumes system resources on the same production application server/database as OLTP transactions
• 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
• Not pushing filters early enough in the VDM layer, leading to full table scans before aggregation
• Treating embedded analytics as a purely technical decision without validating it against actual business latency requirements
• Underestimating extensibility restrictions in S/4HANA Cloud public edition and promising custom CDS development that the edition does not support

A strong production design connects functional or analytical semantics to integration boundaries, security, performance, transport/change control, observability, recovery and ownership. Trade-offs should be justified with evidence such as volume, latency, data quality, user behavior, operational SLA and downstream dependencies. Avoid treating a technically successful configuration or interface as complete until the business result is reconciled end to end.

A retail customer running S/4HANA on-premise wanted a live 'open deliveries by plant' dashboard for warehouse managers. The BW team initially proposed extracting delivery data nightly into BW/4HANA, but the business needed intraday visibility. The team instead built an analytical CDS view directly on the delivery item and header tables, exposed it as a Fiori analytical list page, and avoided both the latency and the extra data replication effort, while still using the existing BW/4HANA system for month-end consolidated financial reporting.

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.

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.

• Applying BW analysis authorization concepts to CDS views and expecting automatic equivalence, when CDS views require separate DCL/PFCG-based authorization design
• Assuming embedded analytics can fully replace BW/4HANA for all reporting, including multi-year trend and cross-system harmonization needs
• 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
• Assuming S/4HANA Cloud extensibility allows the same custom CDS development freedom as on-premise systems
• Building deeply nested custom CDS views with joins and currency conversions in the consumption layer, causing performance problems directly against operational tables
• Building embedded analytics on heavily customized custom tables without proper CDS modeling, causing poor performance
• Designing analytical CDS views directly on heavily normalized custom tables without considering join performance on large data volumes
• Failing to assess data volume and query complexity before choosing embedded analytics over extraction-based BW
• Failing to document to business users which reports are live (embedded analytics) versus latency-bound (BW), causing trust issues when numbers differ
• Forgetting to define currency/unit conversion annotations, leading to incorrect aggregated amounts
• Ignoring that embedded BW still consumes system resources on the same production application server/database as OLTP transactions
• 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
• Not pushing filters early enough in the VDM layer, leading to full table scans before aggregation
• Treating embedded analytics as a purely technical decision without validating it against actual business latency requirements
• Underestimating extensibility restrictions in S/4HANA Cloud public edition and promising custom CDS development that the edition does not support

• Clearly communicate data latency differences to business users when both embedded analytics and BW reports coexist for related data
• Confirm current extensibility and custom CDS development scope for the specific S/4HANA deployment model before committing to a design
• Coordinate authorization design between CDS-level DCL checks and BW query authorizations early in the project
• Design and test CDS view authorization (DCL) separately from BW analysis authorizations; do not assume equivalence
• Document the chosen architecture rationale so future teams understand why a given report was built as embedded analytics versus extracted BW content
• Explicitly define currency and unit conversion annotations on all amount and quantity measures
• Keep BW/4HANA or a dedicated warehouse for heavy historical, multi-source, or complex transformation-driven reporting
• Layer CDS views (interface, composite, consumption) to keep reusable logic separate from analytical-specific annotations
• Push filtering and aggregation as early as possible in the VDM layer (interface/basic views) rather than the consumption layer
• Reserve BW/4HANA for historical trend analysis, multi-source integration, and scenarios needing heavy transformation or long-term retention
• Start every reporting requirement discussion by asking about acceptable data latency and historical depth needed
• Use CompositeProviders to blend virtual (live) and physical (historical) InfoProviders when both freshness and trend history are required
• Use embedded analytics CDS views for operational, low-latency reporting needs bounded by current transactional data volumes
• Use embedded analytics for real-time operational reporting on core S/4HANA business objects with moderate complexity
• Use SQL trace or CDS view analysis tools to validate join and aggregation performance before productive go-live
• Validate embedded analytics performance impact on the production system before wide rollout
• Verify extensibility scope for the specific S/4HANA edition (on-premise, private cloud, public cloud) before committing to custom CDS view development

Senior interviews should test whether the candidate can connect the individual lesson areas, diagnose cross-layer failures, explain trade-offs and design a supportable production operating model.

Interviewers often ask candidates to explain the difference between embedded analytics and classic BW extraction, and to describe criteria for choosing one over the other for a given reporting requirement; strong answers reference data latency needs, data volume/complexity, and impact on the production OLTP system.

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.

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.