Test SAP MDG Replication When an Approved Change Isn't in Target

When a business partner change request is approved in SAP Master Data Governance (MDG) but the record never shows up in the target system, test replication as its own chain: replication model, filter, outbound call, target processing and key mapping. Check the DRF log first, then the key mapping, then the target's customizing. Build your test cases around those three checkpoints so the next failure takes minutes to diagnose and not days.

This guide focuses on business partner replication, because it is the object most S/4HANA programs push through MDG first. The same logic applies to other data models. For the full test design across workflows, validations and duplicate checks, go deeper in the free course Testing SAP MDG: Change Request Workflows, Validation Rules, Duplicate Checks and Replication.

Why "approved" does not mean "replicated"

In central governance, the change request workflow ends when the data is activated in the MDG hub. Distribution to the connected systems happens afterward, through DRF. Different people own the two halves. Data stewards and approvers own the workflow. Basis, integration and the MDG technical team own the replication model, the communication channels and the target configuration.

That split is why defects fall between test cycles. The workflow test passes in the MDG sandbox. The replication test needs a connected target, so it gets deferred to SIT, and then a single missing business system assignment stalls the whole cycle.

From ECC to S/4HANA, one thing changes for most programs: business partner is the leading object, with customer and vendor handled through CVI. A customer change that used to be a simple XD02 update becomes a business partner payload. Your replication tests must cover the BP-to-customer/vendor leg too. Our CVI step-by-step guide covers that conversion.

The replication chain you are testing

1. ActivateChange request approved, data active in the hub
2. SelectReplication model and filters decide what goes
3. SendOutbound implementation builds the message
4. ProcessTarget maps keys and updates the record
5. ConfirmLog, key mapping and target values agree

Step 1: Confirm the configuration before you test the data

DRF is configuration-driven. It rests on business systems, a replication model, an outbound implementation, filter objects and a communication channel, according to a DRF overview from ERPVITS. Configuration is maintained in DRFIMG, per the SAP Community write-up.

Before you run a single scenario, capture a configuration snapshot:

• Replication model exists, is active, and names the right target business system.
• The outbound implementation matches the target's inbound service (for example, a web service or IDoc).
• Filters are assigned and documented, including any custom ones.
• The target system's customizing is compatible with the source. SAP's troubleshooting guidance says different customizing can cause errors in the target.

Attach the snapshot to the test cycle. When a result changes between cycles, you will want to know whether the data or the configuration moved.

Step 2: Test manual and automatic replication separately

A change request can trigger replication automatically on save or activation. You can also trigger it manually with DRFOUT. Run both.

SAP's own business partner replication troubleshooting blog gives a clean diagnostic. If direct replication fails, test whether manual replication from DRFOUT works. If manual works and direct does not, check that function module MDG_BS_BP_OUTBOUND_DRF is called in direct mode. That call is activated in table CRMC_BUT_CALL_FU.

That one comparison tells you whether you have a data and mapping problem (both paths fail) or a trigger problem (only the automatic path fails). Put both paths in the regression suite.

Step 3: Read the DRF log as test evidence

DRFLOG shows the application log entries of DRF. According to a SAP Community blog on custom DRF filters, it tells you when the replication ran, which object types were replicated (object type 986 is business partner), which filters executed, how many objects went out, and which objects the filters removed.

The last point matters most for "approved but missing" tickets. A record that was filtered out is a different defect from a record that was sent and rejected. The same community write-up also points to SLG1 and application-specific logs for troubleshooting.

Step 4: Test key mapping explicitly

Key mapping links the identifier in the hub to the identifier in each target. It is a leading root cause in SAP's troubleshooting guidance, which names incorrect key mapping as a possible cause when S/4HANA is the target. A hub record can be replicated cleanly into the wrong target record, or fail because no mapping exists.

Cover these cases:

• New record: the target creates a record and the mapping is written back.
• Existing record: the target updates the mapped record, not a new one. Use a business partner that already exists in both systems.
• Same-number versus different-number landscapes: if the hub and target use different number ranges, prove the mapping at both ends.
• Successful payload, no update: SAP's guidance describes this case, where the payload succeeds but the BP is not updated and the key mapping is correct. It needs debugging on the inbound side, so log it as a distinct defect type.

Step 5: Give filters and BAdIs negative tests

Filters are where projects add custom logic: replicate only company code 1000 vendors, or only one partner group. In DRFF-configured custom filters, the filter logic runs in the APPLY_FILTER method, and you can debug it by triggering replication from DRFOUT or from transaction BP, as that community blog explains.

The standard BP replication also exposes BAdIs for custom mapping. For inbound there is MDG_SE_BP_BULK_REPLRQ_IN and for outbound MDG_SE_BP_BULK_REPLRQ_OUT, per the SAP troubleshooting blog. Typical uses are mapping custom fields or preventing a value from being deleted in the target when the field is not in the payload.

Test these:

• A record that should pass the filter does pass.
• A record that should be excluded is excluded, and DRFLOG shows it as filtered.
• A custom field maps correctly in both directions.
• Clearing a field in the hub does not blank a target-only field unexpectedly.
• A change to a non-replicated attribute does not trigger a pointless replication.

Step 6: Connect the test to the change request lifecycle

Replication tests are strongest when they start from a real change request, not a data load. Build four end-to-end scenarios that start at the workflow and end in the target:

Scenario	Start	Replication evidence
Create a new business partner	Change request, approval, activation	New target record, key mapping written
Change an address or bank detail	Change request with approver step	Target values updated, no duplicate created
Block or archive a partner	Change request with block flag	Target block set, open documents unaffected
Rejected change request	Approver rejects	Nothing in DRFLOG, nothing in target

The rejected request is the one teams forget. It proves that nothing leaks out before approval. Also test mass changes and a bulk load, since replication volumes behave differently from single records. Use the monitoring step in your performance plan, and schedule DRFOUT as a batch job if your design depends on it.

For the surrounding checks (validations, derivations, duplicate matching) use the free course SAP Master Data Governance Essentials. For the business side of BP governance, see Business Partner Data Governance and Testing.

Step 7: Decide who signs what

Replication is where the data steward's sign-off and the technical sign-off meet. Use a simple split:

• Data steward or master data lead: values in the target match what was approved, and rejected requests left no trace.
• Integration or Basis lead: channels, models and jobs are configured identically across the transport path and the logs are clean.
• Downstream process owner: a sales order, purchase order or payment run works with the replicated partner. Link this to your integration cycle, as described in the free course End-to-End Integration Testing Across Processes.

Record each in a UAT sign-off form, and keep the target-side evidence with it.

One caveat. Fields, apps and available replication options differ by MDG release and by deployment (MDG on S/4HANA, a standalone hub, or the cloud edition). Verify the object types, BAdI names and monitoring tools against the SAP Help Portal for your exact release before you freeze the test scripts.

Frequently asked questions

Which transaction shows why an MDG record was not replicated?

Start with DRFLOG, which shows when replication ran, what was sent and what the filters removed. Then check SLG1 and any application-specific logs. If the log shows the record went out, move to the target and check key mapping and inbound processing.

What is the difference between DRFOUT and automatic replication?

DRFOUT triggers replication manually or through scheduled jobs. Automatic (direct) replication fires as part of saving or activating the object. If DRFOUT works and the automatic path does not, the problem is in the trigger. For business partners, SAP points to the function module MDG_BS_BP_OUTBOUND_DRF and the CRMC_BUT_CALL_FU setting.

Where do I put custom field mapping for business partner replication?

SAP names two BAdIs for the standard BP replication: MDG_SE_BP_BULK_REPLRQ_OUT for outbound and MDG_SE_BP_BULK_REPLRQ_IN for inbound. Test every custom mapping in both directions, including deletion behavior.

Can I test MDG replication without a connected target system?

You can test the filter and outbound steps, because DRFLOG shows what was selected and sent. You cannot prove key mapping or target updates without a target. Plan for a connected test target before SIT, and do not sign off replication from hub-only evidence.

Sources

1. Troubleshooting for Business Partner Replication issues, SAP Community (blog by SAP)
2. Data Replication Framework (DRF), SAP Community (member blog)
3. DRF Custom ABAP BAdI Filter Implementation, SAP Community (member blog)
4. Data Replication Framework in SAP MDG (DRF): Complete Guide, ERPVITS