SAP MDG · REPLICATION INBOUND
How do I implement an IDoc mapper BAdI in SAP MDG to reconcile inbound data against remote master data?
Implement `IF_EX_IDOC_DATA_MAPPER~PROCESS` as a thin orchestration method: gate by message type, read and validate the inbound segment, resolve the RFC destination from `EDIPOA`, fetch remote and local datasets, reconcile them by business key, and call the remote cleanup API for remaining obsolete records.
SOLUTION SUMMARY · SHORT ANSWER
Implement `IF_EX_IDOC_DATA_MAPPER~PROCESS` as a thin orchestration method: gate by message type, read and validate the inbound segment, resolve the RFC destination from `EDIPOA`, fetch remote and local datasets, reconcile them by business key, and call the remote cleanup API for remaining obsolete records.
The standard pattern is to keep the mapper focused on orchestration: first check the IDoc message type, then read the expected segment, derive the RFC destination from the receiving port, fetch remote and local data, remove matches from the remote candidate list, and process only the records that remain as obsolete or out-of-sync.
Process flow
- Check CONTROL-MESTYP against the target IDoc type
- Read the relevant segment from DATA
- Validate segment name and mandatory key fields
- Resolve RFC destination from CONTROL-RCVPOR via EDIPOA-LOGDES
- Read remote records from the destination system
- Read local records from the current system
- Reconcile local against remote by business key
- Delete or update remaining remote records
CONFIGURATIONSource-backed paths
EDIPOA
Maintain the port-to-RFC destination mapping used to resolve the target system from `CONTROL-RCVPOR`.
Referenced tables
| Object | Purpose |
|---|---|
EDIPOA | Port-to-RFC destination mapping used to resolve the target system. |
LFBK | Local bank data used as the source-side comparison dataset in the example. |
ILLUSTRATIVE ABAP SAMPLE
Source ABAP example: idoc_mapper_complete_generalized_sample.abap
Exact relevant implementation excerpt from the knowledge document set.
1"==============================================================================
2" Complete Generalized IDoc Mapper Sample
3" Purpose:
4" - Demonstrate a full `IF_EX_IDOC_DATA_MAPPER~PROCESS` implementation pattern
5" - Parse inbound IDoc segment
6" - Resolve RFC destination
7" - Reconcile local and remote records
8" - Execute remote cleanup for obsolete entries
9"==============================================================================
10
11CLASS zcl_im_generic_idoc_mapper DEFINITION
12 PUBLIC
13 FINAL
14 CREATE PUBLIC.
15
16 PUBLIC SECTION.
17 INTERFACES if_ex_idoc_data_mapper.
18
19 PRIVATE SECTION.
20 TYPES: BEGIN OF ty_remote_record,
21 account_type TYPE koart,
22 account_id TYPE char20,
23 country TYPE banks,
24 bank_key TYPE bankl,
25 bank_account TYPE bankn,
26 END OF ty_remote_record.
27
28 TYPES tt_remote_record TYPE STANDARD TABLE OF ty_remote_record WITH DEFAULT KEY.
29
30 TYPES: BEGIN OF ty_local_record,
31 account_id TYPE char20,
32 country TYPE banks,
33 bank_key TYPE bankl,
34 bank_account TYPE bankn,
35 END OF ty_local_record.
36
37 TYPES tt_local_record TYPE STANDARD TABLE OF ty_local_record WITH DEFAULT KEY.
38
39 METHODS get_destination_by_port
40 IMPORTING
41 iv_port TYPE edi_rcvpor
42 RETURNING
43 VALUE(rv_destination) TYPE rfcdest.
44
45 METHODS read_remote_records
46 IMPORTING
47 iv_destination TYPE rfcdest
48 iv_account_id TYPE char20
49 RETURNING
50 VALUE(rt_remote) TYPE tt_remote_record.
51
52 METHODS read_local_records
53 IMPORTING
54 iv_account_id TYPE char20
55 RETURNING
56 VALUE(rt_local) TYPE tt_local_record.
57
58 METHODS reconcile_remote_against_local
59 IMPORTING
60 it_local TYPE tt_local_record
61 CHANGING
62 ct_remote TYPE tt_remote_record.
63
64 METHODS delete_remote_record
65 IMPORTING
66 iv_destination TYPE rfcdest
67 is_remote TYPE ty_remote_record.
68ENDCLASS.
69
70CLASS zcl_im_generic_idoc_mapper IMPLEMENTATION.
71
72 METHOD if_ex_idoc_data_mapper~process.
73 "------------------------------------------------------------
74 " 1) Gate by message type so mapper runs only for target IDocs
75 "------------------------------------------------------------
76 CHECK control-mestyp = 'ZCREMAS'.
77
78 "------------------------------------------------------------
79 " 2) Read and validate the first segment payload
80 "------------------------------------------------------------
81 READ TABLE data INTO DATA(ls_data) INDEX 1.
82 CHECK sy-subrc = 0.
83 CHECK ls_data-segnam = 'E1LFA1M'.
84
85 " Parse vendor segment payload. In productive code use the exact segment type.
86 DATA(ls_vendor_seg) = VALUE e1lfa1m( ls_data-sdata ).
87 CHECK ls_vendor_seg-lifnr IS NOT INITIAL.
88
89 "------------------------------------------------------------
90 " 3) Resolve RFC destination from receiving port
91 "------------------------------------------------------------
92 DATA(lv_destination) = get_destination_by_port( control-rcvpor ).
93 CHECK lv_destination IS NOT INITIAL.
94
95 "------------------------------------------------------------
96 " 4) Read remote and local datasets for reconciliation
97 "------------------------------------------------------------
98 DATA(lt_remote) = read_remote_records(
99 iv_destination = lv_destination
100 iv_account_id = ls_vendor_seg-lifnr ).
101
102 DATA(lt_local) = read_local_records( ls_vendor_seg-lifnr ).
103
104 "------------------------------------------------------------
105 " 5) Remove matching records from remote list
106 " Remaining entries are obsolete in remote target
107 "------------------------------------------------------------
108 reconcile_remote_against_local(
109 EXPORTING
110 it_local = lt_local
111 CHANGING
112 ct_remote = lt_remote ).
113
114 "------------------------------------------------------------
115 " 6) Delete obsolete remote records
116 "------------------------------------------------------------
117 LOOP AT lt_remote INTO DATA(ls_remote).
118 delete_remote_record(
119 iv_destination = lv_destination
120 is_remote = ls_remote ).The remaining configuration, implementation details, and testing guidance continue from this answer more…
Related questions and keywords
Alternative questions
- How can I build IF_EX_IDOC_DATA_MAPPER~PROCESS logic for inbound IDocs?
- What is the standard implementation pattern for an IDoc mapper that enriches or cleans inbound data?
- How do I compare local and remote records in an inbound IDoc mapper?
Possible questions
- How do I implement the message-type check in IF_EX_IDOC_DATA_MAPPER~PROCESS?
- Which IDoc segment should be read and parsed in the mapper?
- How do I resolve the RFC destination from the inbound IDoc port?
- How do I structure the compare-and-clean logic for remote records?
- How should remote delete/update calls be handled safely in the mapper?