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.
Solution
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:
*" 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.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
- SAP Managed Tags:
3 Comments
