Skip to Content
Author's profile photo Grzegorz Glowacki

Generating IDocs for BOR Objects – part 2: outbound IDoc and Shared Master Data (SMD) tool

When posting the first part of my description of BOR objects use in IDoc scenarios, I promised a continuation for outbound IDocs, so here it comes. However, I’m not going to focus on the “regular” output procedure, which is described in details in an existing document (see “Asynchronous BAPI-ALE Communication” at the end of this blog). Instead, I wanted to go one step further, to using the generated output procedure with the Shared Master Data tool, to achieve master data distribution with change pointers. You would be surprised how simple it is, and how this process is automated, thanks to the use of BOR objects.

Business Requirement

Let us assume that we have a custom master data object. In case any data is changed within this object, it should be sent out to some receiver system, in form of an IDoc. Thus, the distribution should be based on the change pointers mechanism.


Step 1

First of all, implement an RFC-enabled function module that will collect the data of the master data object. Basically this is nothing but an application logic. Remember that it should:

– take some Importing parameters (at least the object’s primary key),

– collect the data to Exporting or Tables parameters,

– return a structure or table of type BAPIRET2, named RETURN.


Step 2

Create a custom BOR object, containing a method generated based on the function module from Step 1. Generate an outbound ALE interface for your object’s method with transaction BDBG. Refer to the Document linked before for further help, if required.


Step 3

Now that you have a BOR object and a Message Type already generated, you can proceed with regular IDoc scenario specific steps:

  • create partner profile entries,
  • create a distribution model view for your object and method.

Step 4

Prepare the change pointers configuration:

  • make sure change pointers are activated globally in your system (transaction bd61),
  • activate change pointers for your generated message type (transaction bd50),
  • implement change pointers creation when master data is saved (i.e. with user exits, BAdIs or ehnancements, depending on the exact scenario).

Step 5

Implement a function module ZMASTERIDOC_CREATE_SMD_ZBORDEM for evaluating change pointers. Here is an example code for that purpose – note the most important steps, highlighted with comments.

Note: this is just an example created for demonstration purposes, so it omits some important aspects like error handling etc. Make sure to take care of them in real scenarios.

FUNCTION zmasteridoc_create_smd_zbordem.
*"*"Local Interface:
   INCLUDE: <cntain>.
         lit_change_pointers TYPE STANDARD TABLE OF bdcp,
         lit_cp_identifiers  TYPE STANDARD TABLE OF bdicpident,
         lit_messages        TYPE STANDARD TABLE OF zbapi_bor_demo_line,
         lit_return          TYPE STANDARD TABLE OF bapiret2,
         lit_receivers       TYPE STANDARD TABLE OF bdi_logsys,
         lit_filters         TYPE STANDARD TABLE OF bdi_fobj,
         lwa_cp_identifier   LIKE LINE OF lit_cp_identifiers,
         ltp_date            TYPE syst-datum,
         ltp_created_idocs   TYPE i.
        <lwa_change_pointer> LIKE LINE OF lit_change_pointers.
*-- Step 1.1: Read change pointers
       message_type    = 'ZBORDEMO_CREATE'
       change_pointers = lit_change_pointers
       OTHERS          = 1.
*-- Step 1.2: Read the distribution model attributes
       object              = 'ZBORDEMO'
       method              = 'Replicate'
       receivers           = lit_receivers
       filterobject_values = lit_filters
       OTHERS              = 1.
   LOOP AT lit_change_pointers ASSIGNING <lwa_change_pointer>.
     REFRESH lit_messages.
     ltp_date = <lwa_change_pointer>-tabkey.
*-- Step 1.3: Call the BAPI for data collection
         itp_date = ltp_date
         messages = lit_messages
         return   = lit_return.
*-- Step 1.4: Distribute the collected data with the generated FM
         itpdate   = ltp_date
         messages  = lit_messages
         receivers = lit_receivers.
     lwa_cp_identifier-cpident = <lwa_change_pointer>-cpident.
     APPEND lwa_cp_identifier TO lit_cp_identifiers.
*-- Step 1.5: Mark change pointers as processed
       message_type           = 'ZBORDEMO_CREATE'
       change_pointers_idents = lit_cp_identifiers.
*-- Step 1.6: Commit work, remove locks and show results message
   ltp_created_idocs = LINES( lit_change_pointers ).
*-- N master IDocs set up for message type
   MESSAGE ID 'B1' TYPE 'I' NUMBER '038' WITH ltp_created_idocs message_type.
*-- N communication IDoc(s) generated for message type
   MESSAGE ID 'B1' TYPE 'I' NUMBER '039' WITH ltp_created_idocs message_type.

Step 6

Assign the function module from step 5 to the message type from ALE interface, in transaction bd60.


Final result

Once change pointers of your message type get created, you can distribute the IDocs with the standard program RBDMIDOC (transaction bd21):


Here is the final outcome in we02:


Useful links

Generating IDocs for BOR Objects – part 1: inbound IDoc

Asynchronous BAPI-ALE Communication

Distributing Master Data Using the SMD Tool (SAP Help)

Assigned Tags

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

      Nice one!!!

      Author's profile photo Grzegorz Glowacki
      Grzegorz Glowacki
      Blog Post Author


      Thanks for your comment, I'm glad you found it useful.



      Author's profile photo Vinoth Kumar
      Vinoth Kumar
      Thanks Greg for sharing and good information.

      Can you pls. help me in below query. Currently i need to create Vendor in ERP system from SRM-SUS system. Means, we will create new Vendor in SRM-SUS system and need to transfer this data and to create new vendor in ERP system.

      Normally SAP suggest to go with PI/XI to create new Vendor in ERP from SRM-SUS system. We dont have PI/XI in our landscape. So i need to go with Idoc approach. Problem is SRM-SUS system doesnt have Vendor related idoc type (CREMAS04 or 05..).

      If i create a new idoc type in SRM-SUS system (based on CREMAS05) and ERP system receives the idoc and gets failed. Because the idoc type and all segments in SRM-SUS system is in customer namespace whereas in ERP it is standard.

      Instead of creating same idoc type and all segments in ERP (as of SRM-SUS system), is there any approach where can i map idoc type (and all segments) from SRM-SUS system (which is in customer namespace) to ERP's inbound Vendor idoc or where can i change the name of Idoc type and segment type before idoc is created in ERP. We are using tRFC port.

      PS: I have already raised this discussion in SCN

      Thank you Vinoth