Lesson 2 of 6
Replication flows: initial load, delta and failure modes
10 min
Listen to this lesson
A replication flow in SAP Datasphere copies data from a source to a target at scale. SAP Learning lists its sources as ABAP CDS views enabled for extraction, tables with a primary key, and ODP providers (extractors or BW objects), plus SAP HANA views; its targets as Datasphere local tables, SAP HANA data lake files and external targets. Its load types are Initial Only, Initial and Delta and Delta Only. Testers need to know how each part works, because each fails differently.
How delta works from SAP S/4HANA
For CDS views and tables from SAP S/4HANA, delta is mostly trigger-based: database triggers on the underlying tables write changes to logging tables, and the replication picks them up at the delta interval. ODP sources use the ODP delta queue instead. A CDS view supports delta only if it is annotated for change data capture (for example @Analytics.dataExtraction.delta.changeDataCapture.automatic: true), and SAP-delivered views differ: check each one in ADT before assuming it can deliver deltas. SAP Learning also notes that sources without a primary key support only Initial Only. On the target side, a local table with Delta Capture keeps technical change columns so later steps can process changes.
Setting up and monitoring
- In the Datasphere Data Builder, create the replication flow: source connection (an SAP S/4HANA connection through the Cloud Connector for Private Edition), container (for CDS views, the container of views enabled for extraction), source objects, and the target space.
- Set the load type per object, add projections (columns) and filters where needed, and deploy.
- Run it and monitor in the Data Integration Monitor > Flows: status per object, initial load progress, delta runs and record counts.
- On the source side, check change data capture with the monitoring transaction DHCDCMON (CDC jobs and logging tables) and the application log (SLG1) when deltas stop.
- Implement the SAP Notes for replication from SAP S/4HANA (SAP Note 2890171 for prerequisites and supported objects; SAP Note 3297105 for considerations and limitations) and re-check them after each support package.
| Flow type | Purpose | Delta | Test focus |
|---|---|---|---|
| Replication flow | Mass replication from sources to Datasphere or external targets | Initial and Delta supported | Completeness, every change type, recovery |
| Data flow | ETL with transformations into local tables | No delta capability (per SAP Learning) | Full-load correctness, transformation rules, restart |
| Transformation flow | SQL transformations on data already in Datasphere | Initial only, or initial and delta | Rule correctness, delta processing of changed rows |
Wei builds a test data recipe for each delta test, so the same changes can be repeated every cycle: five new billing documents for Great Lakes Fleet Services (17100001) in sales area 1710 / 10 / 00, one quantity change on an open order before billing, one billing cancellation, one credit memo for two pieces at 240.00, and one new document in company code 1810. Each recipe step records the document numbers created, the time, and the expected effect on the target. After two delta intervals, Priya checks every expected effect, and anything missing becomes a defect with the document number attached.
Failure modes testers should provoke
| Failure mode | What you see | Test to run |
|---|---|---|
| Initial load incomplete | Run finished, row count lower than source | Count by company code and period after initial load |
| Filter wrong | Whole company code or document type missing | Count by every filter dimension, not only in total |
| Delta not captured | New postings never arrive; status still green | Post known documents in CMQ, check they arrive within the interval |
| Deletes not replicated | Deleted or archived rows remain in the target | Delete a test record in the source; verify the target change |
| Updates applied twice or out of order | Duplicate keys or old values | Change a document twice quickly; compare final state |
| Flow stopped | Object in error; deltas pile up in logging tables | Stop and restart a flow in test; check resume without gaps |
| Structure change in source | New field missing or flow error after upgrade | Regression after each source release (lesson 5) |
Failure modes and the deliberate tests that expose them. Most can be run in a test cycle with Wei's prepared documents.
What would you do?
In CMQ, Wei posts five test invoices, changes one and cancels one. After two delta intervals, the target shows the five new invoices and the change, but the cancellation still shows the original amount. Noor says the flow is green. What should Priya conclude?
- Replication flows support Initial Only, Initial and Delta, and Delta Only; sources without a primary key are Initial Only.
- Delta from SAP S/4HANA is mostly trigger-based; CDS views need change data capture annotations.
- Monitor in the Data Integration Monitor; check the source with DHCDCMON and SLG1.
- Provoke failure modes deliberately: filters, deletes, double updates, stop and resume, structure changes.
Check your understanding · not graded
Lesson check
1. Which load type does SAP Learning say is the only option for sources without a primary key?
2. Where do you monitor replication flow runs in SAP Datasphere?
3. Which source-side transaction helps check change data capture for replication from SAP S/4HANA?
4. Why does a green flow status not prove delta works?
5. What must a delta test include?