DRF Site and BP Master Data Between S/4HANA Systems

General Scenario Introduction

The site distribution in SAP ERP by means of transaction WBTIMEX, which provides site transfer in push or pull mode, is replaced by the distribution of sites using the Data Replication Framework (DRF) on SAP S/4HANA, which provides push transfer only. Transactions WBTIMEX and WBTIMEX_CUST are not available with SAP S/4HANA.

According to our project working experience, we achieved using data replication function to distribute S/4HANA Retail Site and BP (major part is BP with role BPSITE/Vendor/Customer) master data from one S/4HANA system to several S/4HANA systems. In this article we are trying to put together all the information we found from online help, notes, configuration guide, blogs, Q&A from some discussions, our countless try and testing … in order to provide more comprehensive and detail guide about settings in S/4HAHA and SOA service for DRF site and BP scenario.

Business Partner Data Distribution

The sample setting demonstrated in this blog is distributing data form source system client 100 to target system client 300. Both systems are SAP S/4HANA system with retail solution active (on premise).

A.   Pre-requisites (in source and target system both)

1.    Authorization

Role: SAP_BC_WEBSERVICE_ADMIN_TEC is required to assigned to the data replication user.

2.    POINT to POINT Configuration activate – SPRO

This setting is mandatory to be active.

SAP Customizing Implementation Guide > Cross-Application Components > Processes and Tools for Enterprise Application > Enterprise Services > Point-to-Point Enablement for Asynchronous Enterprise Services > Activate Support for Point2Point Communication


3.    BADI “MDG_IDM_GET_LCL_SYSTEM” implementation – SPRO

Since we didn’t use SLD approach, this BADI should be implemented and active for determine local system ID.

SAP Customizing Implementation Guide > Cross-Application Components > Processes and Tools for Enterprise Application > Master Data Governance > Central Governance > General Settings > Data Replication > Define Custom Settings for Data Replication > Define Technical Settings > BAdI: Determination of local System Name


B.   Business Partner: SOA Configuration (in source and target system both)

1.    SOA function activation – SRT_ADMIN

Run ART_ADMIN auto-generate task in client 000 first, then go with the configuration in other clients.

For detail refer to SAP note 2347013

Perform manual configurations in system A and system B – RFC, Idempotency, Delay Logon User Configuration.

Make sure ART_ADMIN “Check Technical Setting” task give all good status for client100 of source system and client xxx of target system checks.

2.    SOA Connections between source client 100 and target client 300 – SOAMANAGER

Open SOA Management website using TCODE SOAMANAGER.

3.    Create Profiles

This should be performed in both client 100 and client 300.

Go to Technical Administration > Profiles

Create a new Profile by choosing “Create Profile”

💡The profile name and version should be identical in both client 100 and client 300.

Enter Name: MDG, choose next

Mark User ID/Password

Verify that in section Identifiable Business Context the filed IBC Determination has the value No IBC Determination and choose Next.

In the section Transport Security, mark the check box Secure Communication Only.

If necessary, enter proxy settings, choose Finish to save the settings and activate the profile.

4.    Configure Client Setting

This should be performed in both client 100 and client 300.

Go to Technical Administration > SAP Client Settings

Verify there is already one Business Application ID maintained.

This Business Application ID should be generated after the BADI mentioned above has been implemented.

Unmark the “Use PI as default if no Logical Port is used” under PI Usage since we didn’t use any PI here.

Remember to save your settings.

5.    Configure a Provider System

This should be performed in both client 100 and client 300.

The Provider system means the connection application is provided by the provider system.

Go to Technical Administration > Provider Systems and choose Create

Enter a name for the Provider System and choose the Profile Name created before, go next.

Unmark “Use Services Registry” under Services Registry.

Enter the URL for “Access URL for WSIL” and one user with password.

💡When configure in source client 100, this URL should point to target client 300.

💡When configure in target client 300, this URL should point to source client 100.

Mark “use WSIL user” under WSDL Document.

Mark “Tolerant search” under Search Granularity.

Check the WSIL connection then go next.

Choose Create to add a new business application.

💡When configure in source client 100, the Business Application ID should come from target client 300.

💡When configure in target client 300, the Business Application ID should come from source client 100.

Choose Finish to complete the Provider system creation and activate it.

After activation, the business application should be able to be found in Service Administration > Identifiable Business Context Reference.

6.    Logon Data Management

Conduct setting for this in both source system and target system both.

Choose Create

Choose User/Password or X.509 as the Authentication Method, give the user and password then Finish

7.    Logon Data Assignment

Go to the Assignments in Logon Data Management

Choose Create to create one assignment

Choose the Provider IBC Reference just Created in previous step and then go next

Choose the logon data just created and then finish.

8.    Local Integration Scenario Configuration

create integration scenario

Give a name and description here and go next.

Add below web services:






Assign profile to those services and go next.

Add below web service groups:




Assign IBC reference to the added service groups and go next.

Chose the Logon Data and finish.

💡During the business scenario activation, the process is following:

  1. Run the activation in source system first, the first-time activation will be in failed status.
  2. Then go to run the activation in target system, you will see success status of action.
  3. Go back to run the remained step in source system, this time you will see the success status.


Site Data Distribution

A. DRF Site RFC settings

Create RFC connection between source system client 100 and target system client 300 with logon info maintained.

1.   DRF configuration – TCODE: DRFIMG

Source system client 100 configurations:

Set the business system for target system client 300.

Maintain the logical system name and RFC destination

Select target business system and click “Define Bus. Systems BOs” to define BO type

Give BO type 986(for BP replication) and DRF_0021(for site replication).

Select the two BO types separately and click “Define Bus. Systems, BO” to setup replication method.


define replication model

setup a replication model for target system client 300

Choose “Assign Outbound Implementation” to setup outbound method.

For each outbound Implementation, just use the default parameters as below:

Activate the replication model after configuration.

Define business systems for source system client 100 in target system client 300


Additional Remarks

Up to here, actually only complete relevant DRF and SOA settings of DRF site and BP master data. At this stage, a test of sending one BP from source system to target can be conducted. In case of the error message can be seen in the target system via display the SOA logs (via transaction code – SRT_TOOLS > SRT Error Log),

that means the settings of DRF and SOA service are working now. The error might be caused by incorrect customizing in target system or number range setting is not identical in source and target system. If the error message only existed in source system, that means the DRF and SOA service are still not correctly maintained, and the XML message (BP) not passed to target and system, and BP creation service not called.

💡Therefore, successfully distribute BP and site data from source to target also highly rely on the relevant customizing settings and data number range are correctly maintained in source and target both.

No more detail business partner or site master settings will be discussed here as they are more project specific. But still, following are some general points need to highlight again:

  • Business partner related customizing settings and number range must be identical in two clients or systems.
  • Site related customizing settings must be identical in two clients or systems.
  • So the transport TRs related to BP and Site are very critical if using DRF function for this two data objects.
  • Check and implement all the notes which relevant to BP and site replication before starting DRF BP and sites.
  • Business partner with BPSITE role must be DRF first, then second step is DRF site master data.
  • The data from source system can overwrite the data in target system. Therefore, when can freely DRF data from source and when should block DRF from source should be managed carefully.
  • If business partner and site with same number are manually created in source and target system separately at beginning, after a while this business partner/site need be DRF for source to target, transaction code MDG_KM_MAINTAIN is required to do the mapping for this two data object in target system, since system need to map this two data object (with BP and plant number) even if they are using same number (UUID is different?).
  • After site master data transferred, the material ledger need be active in target system for each site.
  • If customer doesn’t have to too much sites required in S4HANA, actually no meaning to use DRF function to distribute site data, I think manually create data will be fine. But if large amount of site master data required be created, especially in different stage of projects, also require large number of sites are required be created in DEV/QAS/PRD systems for unit test, integration test purpose. In this case, build all the sites in DEV first, and distribute to other systems later, will be greatly saving time and effort on site and BP creation task, also easier to control and ensure the data accuracy as one place for centrally manage these data.
  • Merchandise category assign to sites, supplying sites, price list… these data assignment relationship within site master also can be DRF.

💡This blog post was drafted in collaboration with Will Leng.

Original Article:

Related blogs


Please enter your comment!
Please enter your name here