Lesson 5 of 6
Replication to connected systems
10 min
Listen to this lesson
Governing a record is half the job. The other half is getting the activated record to every system that needs it, in the right format and with the right identifiers. In MDG on SAP S/4HANA this is done by the Data Replication Framework (DRF). DRF decides what goes where, when and how. Even with co-deployment, where the operational record in SAP S/4HANA is updated directly, other systems still need the data: at Contoso, the warranty claims app on SAP BTP needs customers and products.
The DRF building blocks
| Mode | When | Tool |
|---|---|---|
| Initialization | First load of a receiver, or re-sending everything that matches the filters | DRFOUT, replication mode initialization |
| Change replication | Ongoing: changed records are collected and sent | Change pointers processed by DRFOUT, often scheduled |
| Direct replication | Immediately after activation, triggered by the process | Configured per replication model |
| Manual | Resend selected records after an error is fixed | DRFOUT for selected keys, or from the MDG UI |
Replication modes. For MDG-F (financials), SAP recommends starting replication from the MDG UI rather than DRFOUT, because DRFOUT does not handle the edition logic properly.
Key mapping and value mapping
If a receiver uses the same keys as MDG, no key mapping is needed. If it assigns its own numbers, MDG must remember which key in the receiver belongs to which record. A receiver can send its new number back, and MDG stores it in the key mapping. Value mapping translates code values, such as a country code or a payment term, where the receiver uses different codes. Both must be set up during the project and are a frequent source of replication errors.
| Contoso receiver | Objects | Channel | Keys |
|---|---|---|---|
| Warranty claims app (SAP BTP) | Customers (sold-to and ship-to), products CMC-ALT-100 and CMC-ALT-240 | SOAP via SAP Integration Suite in CMC_PROD | App assigns its own IDs; key mapping kept in MDG |
| Data warehouse extract (planned) | Customers and suppliers | File or API, to be decided | Same keys as MDG; no key mapping |
Contoso's replication targets (illustrative course data).
Formats you will meet
Business partners are commonly replicated with SOAP services, and with ALE IDocs where receivers expect them: DEBMAS for customers, CREMAS for suppliers and MATMAS for materials. RFC and file channels exist for special cases. Each receiver gets the format it can process, so one activation can produce several messages in different formats. With co-deployment, remember that the operational record is updated by activation itself; DRF is only needed for systems outside CMP. For the warranty claims app, Theo's team maps the SOAP message in SAP Integration Suite to the app's own API, and the app returns its identifier in a confirmation.
| Question to ask per receiver | Why it matters |
|---|---|
| Which objects and which parts of each object? | Defines the outbound implementation and any segment filters |
| Which records? | Defines object filters, for example by company code or sales area |
| How quickly? | Direct replication or scheduled change replication |
| Whose keys and codes? | Defines key mapping and value mapping |
| Who watches errors? | Defines monitoring and the resend process |
Five questions that make up the replication design for one receiver.
Monitoring replication
- DRFRSD (Display Object Replication Status) gives an overview of what was sent where and whether it succeeded.
- SLG1 with object
DRF_OUTBOUNDshows detailed application logs for replication errors. - For IDoc channels, the IDoc monitors show the message status; for SOAP, the service monitoring in the sending system and in SAP Integration Suite.
- In the MDG UI, a replication status function on a record shows its replication logs.
- A "no key mapping found" warning in the log usually means the receiver never confirmed a key, or key mapping was not maintained.
What goes wrong in testing
| Pitfall | Consequence | Prevention |
|---|---|---|
| Only the create case tested | Changes and blocks never reach the receiver | Test create, change, block and mark for deletion |
| Filters unchecked | Monterrey customers leak to a US-only receiver | Test records just inside and just outside each filter |
| Key mapping not verified | Duplicates in the receiver after the next change | Change the record twice and check the receiver has one record |
| Receiver down during test | Errors never retried | Test the resend path after an outage |
Typical replication test failures.
What would you do?
After go-live of MDG, the warranty claims app shows two records for Great Lakes Fleet Services. The DRF log for the second message has a "no key mapping found" warning. What is the most likely cause?
- DRF sends governed records to receivers: replication model, outbound implementations, filters, channels.
- Modes: initialization, change replication, direct and manual resend (DRFOUT).
- Key mapping and value mapping are needed when receivers use different keys or codes.
- Monitor with DRFRSD, SLG1 (DRF_OUTBOUND) and the integration layer.
Check your understanding · not graded
Lesson check
1. Which transaction triggers outbound replication runs, for example an initialization?
2. When is key mapping needed for a receiving system?
3. Where do you look for detailed replication error logs?
4. Why test changes twice for a receiver with its own keys?