Explain Embedded Analytics in S/4HANA in SAP

35 / 65

S/4HANAintermediate

Embedded Analytics in S/4HANA

Real-time operational reporting directly on transactional data using CDS-based analytical queries, without a separate BW extraction.

Classic SAP reporting extracted data overnight into BW and reported there. S/4HANA reports directly on the transactional tables, live.

Classic BW reporting is like reading yesterday's printed sales summary that someone compiled overnight; embedded analytics is like watching a live dashboard update in real time as each sale happens, because HANA's engine is fast enough to compute the summary on the spot instead of needing to prepare it in advance.

Key Concepts

Why the old way existed. On a row-store database, an aggregation over millions of rows locks and saturates the machine the business is transacting on. So reporting had to happen elsewhere:

    ECC (OLTP)  --overnight extract-->  BW (OLAP)  -->  reports
                                        data is a day old

The latency was not a design goal. It was the price of not crippling the transactional system.

What changed. HANA's column store aggregates fast enough that analytical queries can run against the live tables without hurting transactions. The separate copy stops being necessary for operational reporting.

So a manager's dashboard shows this morning's orders, not last night's extract.

How it is built: annotations again. An analytical query is a CDS view marked as one:

    @Analytics.query: true
    define view entity C_SalesRevenueQuery as select from I_SalesOrderItem
    {
      @AnalyticsDetails.query.axis: #ROWS
      Customer,
      @DefaultAggregation: #SUM
      NetAmount
    }

Measures are the numbers you aggregate; dimensions are what you slice by. Both are declared on the same CDS layer that serves transactional apps.

That is the architectural neatness worth stating: one data model serves the app and the report. There is no second model to keep aligned.

Where the query is consumed. An Analytical List Page in Fiori, a KPI tile on the Launchpad, a card on an Overview Page, or SAP Analytics Cloud over a live connection — querying S/4HANA directly rather than importing from it.

What it is not for. Embedded analytics reports on this system's live data. It is not a data warehouse:

    embedded analytics    one system, live, operational.
                          "which orders are blocked right now?"
    BW/4HANA, Datasphere  many systems, harmonised, historical.
                          "revenue by region across five years and
                           three source systems"

Years of history, data from non-SAP systems, and heavy modelling still belong in a warehouse. Most real landscapes run both, and the answer that lands frames them as complementary rather than one replacing the other.

What the interviewer is probing.1. "What does embedded analytics change for users?" Probing: the value. Stalls: "Better reports." Moves up: reporting on live transactional data in the same system, so there is no extraction delay and the figures match what the clerk just posted.

2. "When do you still need a separate warehouse?" Probing: honest limits. Stalls: "Never." Moves up: cross-system reporting, long history, heavy analytical load that would compete with transactions, and non-SAP data.

3. "What technically powers it?" Probing: the stack. Stalls: "HANA." Moves up: analytical CDS views with cube and dimension annotations, consumed by Fiori analytical apps, Query Browser and Analysis for Office.

4. "What is a KPI tile built from?" Probing: the mechanics. Stalls: "A report." Moves up: a CDS-based query with an evaluation and thresholds defined in the KPI modeler, surfaced on the launchpad.