In my previous blog “How to debug the transfer flow for the replication between CRM and ECC“, I summarized how to debug the transfer flow in general including which queue you need to stop. In this blog, I will take the delta load for customer as an example to introduce the detailed steps to debug the download process and the involved function modules.

1. Run tcode XD02, and perform change to trigger the delta load. In my case, I change the name of my customer. Then put /h to activate the debugger, and press save.


2. PI_BP_CUSTOMER_BTE_1321: For customer delta load, the transaction event 1321 is raised. This function module can be found in table TBE31 for object BC-MID and event 1321.

3. PI_BP_MAP_CUST_TO_BUPA: This function module mapped the complex structure data into the BAPIMTCS structure. You could check the local table LT_MAIN_EXTERN (for central data) and LT_REL_EXTERN (for relationship) for complex structure data.

4. PI_BP_REL_TO_BAPIMTCS/PI_BP_REL_TO_BAPIMTCS: convert the complex data into the BAPIMTCS structure.



5. CRS_SEND_TO_SERVER: This function module send the BAPIMTCS structure into the middleware.

    • It calls function module CRM_FILTER_DOWNLOAD_DATA to do filter as per the setting in R3AC1 of CRM system.
    • It determines the RFC destination as per the setting in table CRMRFCPAR.
    • It determines the queue name as R3AD_CUSTOME* as per the setting in table CRMQNAMES.

You could stop the CRM inbound queue in SMQR to debug the CRM side. Here I stop the queue with name R3AD_CUSTOME*. Then the queue stops in SMQ2.


6. BAPI_CRM_SAVE: The qRFC calls function module BAPI_CRM_SAVE.

7. BUPA_MWX_BDOC_DOWNLOAD_R3A: The XML data is transferred to application. The bdoc is created here. This function module can be checked in tab “Mapping modules: R/3 to CRM” in Tcode R3AC1 for the corresponding object. After creation of the bdoc, it is handed over to MW flow again.

8. CRM_BUPA_BAPIMTCS_TO_MAIN / CRM_BUPA_BAPIMTCS_TO_REL: unpack the BAPIMTCS structure to the complex structure.

9. CRM_BUPA_MAIN_VAL/ CRM_BUPA_REL_VAL: validation function module. This can be checked in table SMW3BDOCIF of CRM system. The modules BUPA_MWX_BDOC_MAP_MAIN and BUPA_MWX_BDOC_MAP_REL are called for processing.

If you are facing the validation bdoc error, you could debug from here. Please read my blog “How to deal with the E04 bdoc errors?” for more details.

10. BUPA_INBOUND_MAP_MAIN/BUPA_INBOUND_MAP_REL: call the function module with event CRMIN in table CRMC_BUT_CALL_FU.


11. BAPI_TRANSACTION_COMMIT/BAPI_TRANSACTION_ROLLBACK: If no error occurred, the MW performs a commit work, otherwise a ROLLBACK.

12. Afterwards, the BP outbound processing creates a new BDoc (notification bdoc), triggered by BADIs that have been registered during the BAPI calls.

13. In the end, there are two bdocs (validation and notification) generated at the same time for the customer delta load.


To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Daniel Ganea

    Excellent article. Thanks!
    I have a question for you: we don’t seem to add the suffix customer number to the R3AD queue like in your example. Anything you can direct me? Our queue name is always R3AD_CUSTOME and gets huge when we do massive initial loads.
    Thank you in advance,

    1. Julin Xin Post author

      Hello Daniel,

      Where do you see the R3AD_CUSTOME queue?

      1. If it appears in ECC outbound queue for the initial load, it actually a standard design. This has been addressed in my blog

      2. If it appears in CRM inbound queue for the delta load, you need to check the queue name setting in ECC table CRMQNAMES by SM30.

      From you description, I think you are talking about scenario 1. Please read my blog for more information.

      Thank you.
      Best regards,
      Julin Xin


Leave a Reply