Lesson 5 of 6
Replication and key mapping verification
10 min
Listen to this lesson
Replication tests answer one question per receiver: after a governed change, does the receiving system hold the right version of the right record, exactly once? "Message sent" is not an answer. The test must look inside the receiver, and it must cover the whole life of a record, not just its creation.
The receiver test matrix
| Case | Action in MDG | Expected in receiver |
|---|---|---|
| Create | New customer for sales area 1710 / 10 / 00 activated | One new record with the receiver's own ID; key mapping stored in MDG |
| Change 1 | Phone number changed | Same record updated; no second record |
| Change 2 | Address changed | Same record updated again; key mapping unchanged |
| Filter in | Customer in company code 1710 | Replicated |
| Filter out | Customer only in company code 1910 | Not replicated |
| Filter boundary | 1910 customer extended to 1710 | Replicated from the moment the 1710 data is activated |
| Block | Customer blocked centrally | Block status reflected as the receiver supports |
| Code value | Customer with a region code the receiver maps differently | Receiver shows its own code (value mapping) |
| Error and resend | Receiver offline during activation | Error visible; resend delivers once; no duplicate |
Replication test matrix for the warranty claims app (illustrative; Contoso's filter sends US company code 1710 customers).
The two consecutive changes case is the single most valuable replication test. If key mapping did not store the receiver's ID after the create, the first change may still look fine in some designs, but by the second change at the latest the receiver creates a duplicate. Always change the same record twice and count the records in the receiver.
Where to look
Initial load reconciliation
Before go-live of a new receiver, DRF initialization sends every record that matches the filters. Treat it like a migration load: reconcile counts by filter group (records in MDG matching the filter versus records received), check a sample of attributes, and list every error with its resolution. The reconciliation ideas from sap-dmg-302 apply directly.
Blocks, deletions and personal data
The end of a record's life needs tests too. When a customer is blocked centrally, the receiver should stop using it; how that is represented depends on the receiver and must be agreed and tested. When a record is marked for deletion, the receiver should not delete history it still needs. And where business partners hold personal data, such as contact persons, the blocking rules for data privacy (covered in sap-xpr-201) must reach the receivers as designed. For the warranty claims app, Contoso tested three end-of-life cases: a blocked customer, a customer marked for deletion, and a contact person blocked after the retention period.
| End-of-life case | Expected in the warranty claims app |
|---|---|
| Customer blocked centrally | No new claims can be created for the customer; existing claims stay visible |
| Customer marked for deletion | Record kept for history; flagged as inactive |
| Contact person blocked (data privacy) | Personal data no longer shown to app users |
End-of-life replication cases for the warranty receiver (illustrative).
Ordering and timing
Two messages for the same record can arrive out of order if the integration path does not preserve sequence, and then an older version overwrites a newer one. Test it deliberately: make two quick changes to the same customer and check that the receiver ends with the second. Also test what users see during the delay between activation in MDG and the update in the receiver, especially if the receiver is used to create documents right away.
Plan the receiver side of each test with its owner. Elena's team prepared a read-only API query that returns the warranty app's record for a given Contoso business partner number through the key mapping, so testers could check the receiver without logging on to the app and without asking the app team for screenshots. Small aids like this make the full matrix cheap enough to run in every regression window.
What goes wrong in testing
| Pitfall | Consequence | Prevention |
|---|---|---|
| Success judged from the sender | Receiver errors never seen | Read the record in the receiver |
| Only creates tested | Duplicates appear after go-live | Two consecutive changes per object type |
| Filters tested only inside | Records leak to the wrong receiver | Test just inside, just outside and boundary cases |
| No outage test | Lost messages after a receiver restart | Test error, monitoring and resend |
Typical replication test failures.
What would you do?
Replication tests to the warranty app pass for all creates. Elena says the app team has no time for further tests and suggests signing now. What should Priya insist on before sign-off?
- Replication is proven in the receiver: right version, right record, exactly once.
- Always change the same record twice to prove key mapping.
- Test filters inside, outside and at the boundary; test block, error and resend.
- Reconcile initial loads like a migration: counts, samples, errors explained.
Check your understanding · not graded
Lesson check
1. Which replication test most reliably exposes missing key mapping?
2. Where is the decisive evidence that replication worked?
3. A 1910-only customer appears in a receiver filtered for 1710. What failed?
4. How should a DRF initial load to a new receiver be accepted?