Analytics Legends The knowledge platform for SAP Analytics
Guide

SAP Datasphere data flows — federate, replicate, or transform

As of 2026-08-14

The first question about a data flow is whether you need one. Datasphere federates as a first-class capability: a live query can pass through to the source with nothing copied, so moving data is a choice you justify rather than a default you inherit from twenty years of warehouse habit. Most flows that cause trouble later were built because loading was assumed, not decided.

Three ways data reaches a model, and what each costs

Federation reads in place. Nothing is copied and there is one version of the truth, but query latency is bounded by the source system's own performance — a federated query is only as fast as the warehouse or lake serving it, and a cold scan adds seconds rather than milliseconds.

Replication moves deltas into Datasphere's own storage. It costs storage and build effort, and it decouples query performance from the source entirely — which is what a live operational dashboard needs when users expect it in under two seconds.

Transformation flows reshape data on the way through: joins, aggregations, cleansing, derived measures. That is where business logic lives, and also where the maintenance sits, because every transformation has to be understood again when the source schema changes.

The delta problem, and the read that silently breaks it

Any flow that claims to keep a target current is making a change-data-capture promise, and on SAP sources that promise rests on plumbing underneath: an extraction framework on the publishing side, and a delta queue that buffers change events until a consumer reads them.

The recurring anti-pattern is bypassing that framework with a direct table read over a database connection. It looks like it works, because the initial load is correct. The deltas silently are not, and the gap surfaces at month-end when actuals do not reconcile — by which point the flow has been trusted for weeks.

For new builds on SAP sources the modern path is a CDS view annotated for data extraction rather than a legacy datasource, with table-level replication reserved for data that has no standard extractor.

Where the logic should live

The reuse test decides it. Anything a second consumer will need belongs in the modelling layer where all of them can read it; anything presentational and local belongs in the consuming tool. A measure defined inside one report is invisible to everything else, and the second consumer re-implements it slightly differently — which is how two dashboards start disagreeing.

The same test applies downstream. A story bound live to a Datasphere analytic model inherits row-level security and lineage automatically. An imported flat model does not: row filters do not follow the copy, so every user with access to the story sees every imported row, and the lineage chain breaks at the import boundary. That is tolerable for a one-off exploratory analysis on non-governed data and disqualifying for regulated reporting.

The maintenance nobody budgets

Three items, all cheap on day one and expensive later.

Lineage on refactor. Datasphere auto-captures lineage for objects inside the platform, but a view refactored without updating its downstream consumers breaks the chain quietly. A quarterly hygiene review catches the drift; without one, the lineage graph slowly becomes wrong and the catalog loses the trust that makes it useful.

External sources. Auto-capture covers what happens inside Datasphere. Legacy systems, third-party feeds and manual file drops need lineage entered deliberately, with a named owner and a refresh commitment per feed. The go-live gate worth holding is that every model traces back to a named source system.

Parallelism. Replication defaults to eight threads per flow, and dozens of concurrently scheduled flows can saturate the throughput allotment while raw compute still has headroom. The symptom reads as a capacity shortfall and is a concurrency setting.

Frequently asked

What is the difference between a data flow and a replication flow?

A replication flow moves data — typically deltas from a source into Datasphere storage — with minimal reshaping. A data flow transforms it: joins, aggregations, cleansing, derived measures.

Should we build a flow or federate?

Federate by default and justify each load with latency, source-system load or source availability. Reverse it past roughly 100 GB of facts or fifty concurrent users.

Why do our deltas go missing?

Usually a direct table read that bypasses the source-side change-tracking framework. The initial load is correct and the deltas silently are not, so the gap surfaces at month-end rather than at build time.

Can transformation logic live in the reporting tool instead?

Only if it is presentational and local. Anything a second consumer will need belongs in the modelling layer, because a measure defined inside one report is invisible to everything else.

What this page is built on

Read next