Replication: DRF, key and value mapping
How an activated record reaches 15 receiving systems through the Data Replication Framework, and how to find it when it does not.
The replication path
After activation, the Data Replication Framework (DRF) decides who gets the record and in which format. Configure it in DRFIMG; run it manually with DRFOUT. A replication model ties outbound implementations (one object type, one channel) to business systems; filters decide which records go where.
Models and channels
A model must be active before anything is sent; a model transported but never activated is a classic go-live miss. IDoc receivers still need the ALE basics: logical systems (BD54), RFC destinations (SM59), partner profiles (WE20). SOAP services are monitored in SRT_MONI or your middleware.
Try it: the replication toolbox
Match each transaction to what you use it for.
Filters: who gets what
Filters keep US-only materials away from the Brazil plant system. Explicit filter values are maintained in DRFF; some outbound implementations also filter implicitly, such as sending only relevant plant segments. A filter exclusion leaves no IDoc and no error, so when a receiver says "we never got it", check filters first.
Try it: silence after go-live
Day one after go-live: new receiver ECCBR gets nothing, for any object. WE02 shows no IDocs for it, SLG1 shows no errors, and the RFC connection test in SM59 works. Most likely cause?
Key mapping and value mapping
Key mapping: what is this object called over there? Supplier 100045 may be vendor V-88812 in ECC; the stored pair makes a change update that vendor instead of creating a duplicate. Value mapping: what is this code called over there? A missing value usually comes back as a check-table error that looks like bad data. Both sit under General Settings in MDGIMG.
Try it: key or value?
Which kind of mapping does each pair need?
Where failures cluster
An illustrative first week after go-live, not an SAP statistic. Use it as a checking order.
Triage at scale
With 15 receivers, one bad mapping makes thousands of failed IDocs. Export the status list to CSV and group by receiver and error pattern: you learn whether you have 2,000 problems or one problem 2,000 times. Then hand the top patterns, plus your mapping export, to an assistant and verify what it says.
import pandas as pd
import re
df = pd.read_csv("idoc_errors.csv") # docnum, mestyp, rcvprn, status, text
# Replace record-specific numbers so identical errors group together
df["pattern"] = df["text"].astype(str).map(
lambda t: re.sub(r"\b\d{3,}\b", "<n>", t))
summary = (df.groupby(["rcvprn", "mestyp", "pattern"])
.size()
.reset_index(name="count")
.sort_values("count", ascending=False))
print(summary.head(15).to_string(index=False))Runs on an exported CSV; no SAP connection needed.
Remember
- DRF = replication models + outbound implementations + filters + business systems; configure in DRFIMG, run with DRFOUT.
- Key mapping translates object identities; value mapping translates codes inside records.
- Filter exclusions and inactive models are silent; IDoc and mapping errors show in WE02, BD87 and SLG1.