Skip to Content
Technical Articles
Author's profile photo Ryan Li

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.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Ginger Chen
      Ginger Chen

      Very useful document.

      Thanks Ryan and Will. 🙂

      Author's profile photo Vamshi Krishna
      Vamshi Krishna

      Hi Ryan&Will,

      This process document is really helpful.

      Here's my requirement, looking forward to some valuable suggestions/recommendations.

      I'm current working on SAP ACS 1.3. To cater to business continuity, when primary system is taken for downtime during system upgrades, security patches, support pack implementations etc we plan to stand up a lighter parallel system/DB (only with definitive set of tables/data copied from primary and not an exact replica of primary) to act and support as primary system for processing of transactions during downtime. To enable this model we need to replicate data from primary DB to secondary DB in sync or async modes based on certain selection criteria. Once primary system comes up post down time delta data from secondary has to be copied over. We would have to replicate Master data, Configuration data and Transactional data before and after the switch over.

      Components installed:

      Component: SAPK-13S02INSAPFRA
      SLES12 SP4 (Linux)/HANA2.0 SPS05

      Author's profile photo Elvis Wen
      Elvis Wen

      Really helpful!

      Thank you very much!

      One more question: If the SOA here works like the PO? If we use PO, SOA is no need to be use?




      Author's profile photo Paul Gendreau
      Paul Gendreau

      Strongly disagree with this statement:  "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."

      Site Master Distribution is Best Practice in S/4HANA because Site Masters are customizing. Creating Site Masters directly in Production creates customizing in Production.

      From a production business process perspective, I created:

      Author's profile photo Juliana Tiagua
      Juliana Tiagua

      Hi Ryan Li,

      I have a problem with my scenario. I did the necessary configurations and it is working perfectly, however we need to send the BPs to more than one target system (QAS and PRD).

      I did the same steps for both targets SOAMANAGER and for the source system I added a new one scenario (now I have 2, one for QAS and one for PRD). So now I have two Logical ports but I can just choose one as default.

      When I run DRFOUT, I see that in SRT_MONI there are two lines created, one for each target system.
      However when I check the the targets systems, I see that just the system where the port was set as default works, and that two lines are created for this system. If I change the default port, the replication will work in the other system.

      Do you have any clue how to make it work correctly for both target systems at the same time?



      Author's profile photo Ryan Li
      Ryan Li
      Blog Post Author

      Hello Juliana,

      During the project, we have same scenario as you mentioned. What we did just manually switch the default target system and distribute the data seperately. Didn't find any information regarding sending site data to more than one system at the same time.

      Sorry for unable to give you more positive answer.




      Author's profile photo Juliana Tiagua
      Juliana Tiagua

      Hi Ryan,


      Thanks for the reply!

      So you have to change the DRFIMG to point the other system and the default port in SOAMANAGER every time?




      Author's profile photo Ryan Li
      Ryan Li
      Blog Post Author

      Yes Juliana.

      Lucky thing is we don't need to change it very frequently.



      Author's profile photo Olli Takala
      Olli Takala

      You don't have to change default logical ports. You can use integration scenario configuration by using service group. With that, you can replicate to multiple target systems. If you creating logical port manually only then you have make logical port as default . If the system are connected using service group system will replicate to all the connected system and do not make any port as default.

      SAP provides the instructions:

      (section 6 Create Integration Scenario Configuration for Point-to-Point Communication using Service Group)

      You have to create integration scenario to both sender and target systems separately. In below figure, you can see how the end result should look like

      Author's profile photo Juliana Tiagua
      Juliana Tiagua

      Hi Olli,


      I followed the last step again and my configuration looks like yours:

      I also have one scenario for each target system.

      I activated both at process the pending task list with success. And the last tasks are related to the port activation for both scenarios.

      However now when I send a BP via DRFOUT no entries are added in the SRT_MONI (not in the source or target systems).

      If I set manually as default the port in the source system for one of the target systems, the messages are sent again. However again just arrive to the system that the port is masked as default.

      I also tried to create just one scenario and mark both profiles and both Service Groups. But also didn't work.


      Any ideas?


      Author's profile photo Olli Takala
      Olli Takala

      Hi Juliana,

      Yes, we had also issues to get this working. I highly recommend that you delete everything and start from the scratch following strictly SAP guidance.

      In my opinion this section 6 for creating integration scenario configuration using service groups, is little unclear but below are some points I could highlight for sake of clearence:

      Sender system:

      • Provider IBC reference for selected service groups (MDG_BS_BP_SEARCH; MDG_BS_SUPPLIERREPLICATECONF; MDG_BS_SUPPLIERREPLICATEREQ) -- This should be the target system
      • Logon data user should be the user for target system

      Target system:

      • Provider IBC reference for selected service groups (MDG_BS_BP_SEARCH; MDG_BS_SUPPLIERREPLICATECONF; MDG_BS_SUPPLIERREPLICATEREQ) -- This should be the sender system
      • Logon data user should be the user for sender system

      Configure first sender system, when the system asks that do you want to activate this integration scenario immediately, answer No

      Then configure target system, activate the integration scenario. Activation of logical ports should end up in error because first the pending tasks needs to be processed in the sender system. For that reason process all pending tasks in sender system to activate the business scenario. This means that once the activation has failed in target system, return to sender system and activate there integration scenario. Afterwards process all pending tasks in the target system where the logical port activation failed.

      Processing may take some time but eventually all the tasks should be completed successfully in both systems.

      Hopefully this helps

      Author's profile photo Ryan Li
      Ryan Li
      Blog Post Author

      Hi Olli,

      Very appreciate you sharing these knowledge!!




      Author's profile photo Former Member
      Former Member

      Hi Olli,

      We did the configuration as suggested in SAP Document but if we trigger anything from DRFOUT, its showing unknown messages like "objects with errors were stored. repeat replication for those objects".

      In that case if i select any dynamic logical port as default, it started sending webservices,. But again problem is its redirecting all webservices to one system instead of multiple.


      How you fixed this issue? Ryna also said he also faced same issue and had to use one Logical Port as Default at a time.




      Author's profile photo Valentina Gamez
      Valentina Gamez

      Hi Ryan, I have followed all your steps but I keep getting this error once I run DRFOUT:

      "Invalid HTTP connection parameters"

      We have checked all SOA Manager Configuration as well as DRF Configuration.


      Do you have any idea of how I could fix this issue?



      Author's profile photo Ryan Li
      Ryan Li
      Blog Post Author

      Sorry Valrtina, from the error message I can only guess still some thing is not fully ready in SOA part.

      Author's profile photo Ahmet Kücük
      Ahmet Kücük

      Hi Ryan Li,


      thanks for the very detailed and famous documentation. I've a question regarding the communication types.

      Is is it possible to communicate via drfout on different communication ways ?

      For example when I design a first replication modell which communicates via point to point communication and a second replication modell in which I define to communicate via SAP PI or SAP CPI ?

      If yes, what have to be done or which customizing activity have top be setup?

      Which functionality support the option communication channel in this screen?