SAP Datasphere replication flow — the plumbing underneath it
As of 2026-08-14
A replication flow moves data from a source into Datasphere and keeps it current. Configuring one is straightforward; keeping it honest is not, because the flow depends on machinery it does not own. On SAP sources that machinery is the change-data-capture framework and its delta queue, and the difference between a flow that works and a flow you can explain at 23:47 on a Saturday is whether you monitor that layer or only the flow.
What sits underneath the flow
Two components, and they do different jobs. The extraction framework is the publishing surface: source systems expose data through enabled extractors — classic datasources, CDS views annotated for data extraction, Business Suite extractors, or table-level replication for data with no standard extractor — and consumers subscribe to them.
The delta queue is the buffer. Change events sit there until a consumer reads them, and multiple consumers can read the same queue independently. Persistence, sequencing and resilience to a consumer being down all live in the queue, not in the flow.
This is why a replication flow can complete successfully and deliver nothing. It read the queue; the queue was empty; it reported success. Flow status tells you the flow executed, never that the source published.
The one thing never to do
Do not read source tables directly over a database connection to avoid the extraction framework. It is the single most persistent anti-pattern on this platform and it fails in the most expensive possible way: the initial load is correct, so the flow is trusted and moves into production, and only the deltas are silently missing.
The discovery point is month-end close, when actuals do not match. By then the model has been feeding reports for weeks and the reconciliation is not a technical exercise but a credibility one.
The cost of doing it correctly is queue monitoring overhead. That is the honest trade: the framework adds an operational surface — queue depth, error rate, subscription hygiene — and it is the only path that gives resilient, multi-consumer, delta-safe replication.
The three signals worth alerting on
Queue depth. Below roughly a thousand pending events is healthy. Growth past ten thousand without a consumer pulling means an upstream backlog or a consumer that is down — visible days before anyone notices a wrong number.
Extraction error rate. Under about 0.01 percent is the working band. Above it something is failing intermittently, and intermittent failures are the ones that surface at reconciliation rather than in an alert.
Subscription hygiene. A consumer deliberately de-registered and a consumer simply forgotten look identical from the queue's side, and only one of those is fine. A quarterly audit stops the queue bloating on behalf of something nobody has run since a project ended.
When not to replicate at all
Replication is a choice, not a default. Datasphere federates as a first-class capability — a live query passes through with nothing copied — so the case for moving data is made per object: latency, source-system load, or source availability.
Our working break-even is around 100 gigabytes of facts, or more than fifty concurrent business-intelligence users. Below that, federation usually wins on total cost and freshness; above it, repeatedly paying the source's live-query cost adds up in money and in patience.
One cost hides on the federation side: querying an external platform in place consumes compute on that platform's bill. A federation-heavy architecture can be cheaper in SAP capacity units and more expensive overall, and nothing in the capacity-unit conversation surfaces it.
In a hybrid estate — ECC and S/4HANA side by side for the three to five years a transition takes — replication into one analytic-model layer is often what makes cross-system reporting possible at all. Write that down as the reason.
What we cannot assert
The queue-depth and error-rate bands above are working field guidance from our own corpus, not SAP-published service levels — calibrate them against your estate's own baseline rather than treating them as supported limits.
Frequently asked
Why did my replication flow succeed but load nothing?
It read an empty delta queue. The flow depends on the source-side framework publishing change events; if an extractor failed or a source job did not run, the flow pulls zero rows and correctly reports success.
Can I replicate a table with no standard extractor?
Yes — table-level replication exists for that case and plugs into the same change-tracking framework. What you should not do is read the table directly over a database connection, which silently misses every delta.
What should we monitor on a replication flow?
The source side more than the flow: queue depth (healthy below about a thousand pending events), extraction error rate below roughly 0.01 percent, and a quarterly audit of which consumers are still subscribed.
Should we replicate or federate?
Federate by default and justify each replication. Past roughly 100 GB of facts or fifty concurrent business-intelligence users, replication is usually cheaper overall.
What this page is built on
- ODP & ODQ Extraction (C031)
- BDC Connect (C015)
- BDC Capacity Units (C012)
- Hybrid Architecture Patterns (C035)
- Live vs Import Connections (C022)