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.
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.
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.
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.
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.
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).
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: *" IMPORTING *" REFERENCE(MESSAGE_TYPE) TYPE EDI_MESTYP *"---------------------------------------------------------------------- INCLUDE: <cntain>. DATA: 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. FIELD-SYMBOLS: <lwa_change_pointer> LIKE LINE OF lit_change_pointers. *-- Step 1.1: Read change pointers CALL FUNCTION 'CHANGE_POINTERS_READ' EXPORTING message_type = 'ZBORDEMO_CREATE' TABLES change_pointers = lit_change_pointers EXCEPTIONS OTHERS = 1. *-- Step 1.2: Read the distribution model attributes CALL FUNCTION 'ALE_ASYNC_BAPI_GET_RECEIVER' EXPORTING object = 'ZBORDEMO' method = 'Replicate' TABLES receivers = lit_receivers filterobject_values = lit_filters EXCEPTIONS 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 CALL FUNCTION 'Z_BAPI_BOR_DEMO_REPLICATE' EXPORTING itp_date = ltp_date TABLES messages = lit_messages return = lit_return. *-- Step 1.4: Distribute the collected data with the generated FM CALL FUNCTION 'ZZ_ALE_BOR_DEMO_REPLICATE' EXPORTING itpdate = ltp_date TABLES messages = lit_messages receivers = lit_receivers. lwa_cp_identifier-cpident = <lwa_change_pointer>-cpident. APPEND lwa_cp_identifier TO lit_cp_identifiers. ENDLOOP. *-- Step 1.5: Mark change pointers as processed CALL FUNCTION 'CHANGE_POINTERS_STATUS_WRITE' EXPORTING message_type = 'ZBORDEMO_CREATE' TABLES change_pointers_idents = lit_cp_identifiers. *-- Step 1.6: Commit work, remove locks and show results message COMMIT WORK AND WAIT. CALL FUNCTION 'DEQUEUE_ALL'. 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. ENDFUNCTION.
Assign the function module from step 5 to the message type from ALE interface, in transaction bd60.
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: