Dear Community, IDoc is the abbreviation for “Intermediate Document”, a widley used SAP standard to exchange business data between systems (mostly SAP software based).
With an implementation of the classic Business Add-in (BAdI) IDOC_DATA_MAPPER, you can change values in outbound and inbound IDocs via ABAP programming. Here are some tips and tricks around implementing this BAdI.
Check use of IDoc Conversion Rules first
Before you implement BAdI IDOC_DATA_MAPPER, check if the SAP standard of “IDoc Conversion Rules” solves your problem as well (transaction BD62, BD55 and BD79. The major advantage is that you easily configure different mapping rules withouth programming, even with mapping in error cases to one “fallback” value.
Think about your architecture
Don’t write the complete source code to fullfill all your requirements into the BAdI implementation. This has various disadvantages. For example, you cannot proof the BAdI implementation with unit tests. As a proposal, think about different classes with a clear scope (Separation of Concerns):
- Class ZCL_<..>_IDOC_DATA_MAPPER: For tasks like extracting values from IDoc, calling business logic to map values, publish changed IDoc values and more.
- Class ZCX_<..>: Exception class to handle technical IDOC_DATA_MAPPER problems.
- Class ZCL_<..>_MAPPING: To fullfill the original business requirements.
- Class ZCX_<..>: Exception class to handle business logic (mapping) problems.
Run only when necessary
Check at least IDOC_CONTROL-DIRECT and IDOC_CONTROL-MESTYP if the IDoc actually being processed fits to your implementation. Background is that BAdI IDOC_DATA_MAPPER can be implemented multiple times for different scopes. Every implementation is executed when an IDoc is received or sent. So don’t interfere with other IDoc processes.
Get data from IDoc
You find the IDoc data in table IDOC_DATA – surprise 😉 Read the wanted table line with IDOC_CONTROL-DOCNUM and SEGNAM. Move the value in SDATA to a corresponding structure of the right data type. Maybe there’s some function module that do that step for you but unfortunately I can’t remember right now 🙁
Publish your changes
Set CHANGING parameter HAVE_TO_CHANGE to ‘X’ (abap_true).
Publish your changes via entries in table MAPPING. You get the right SEGNUM value from reading the IDOC_DATA table.
If you set the SAVE_TYPE to ‘V’ you won’t see the original unmapped value in IDoc status message.
Always fill structure PROTOCOL-STAMID and PROTOCOL-STAMNO. So you will get your own IDOC status messages instead of a SAP standard message. Please note that if you change an IDoc value there will always be an additional IDoc status message.
Publish error situation
Surprisingly, set HAVE_TO_CHANGE to value ‘E’ in error situation. This is the indicator for IDoc processing that something went wrong (compare documentation of interface IF_EX_IDOC_DATA_MAPPER).
Test with IDocs
Use transaction WE19 to do some IDoc test processing in save environment. If your implementation is active, it will be processed.
Debug into SAP standard
Set a breakpoint in your BAdI implementation. When using transaction WE19, ABAP debugger will be executed. Now you can debug into the SAP standard that calls your BAdI implementation. That’s really helpfull if your changes to the IDoc are not processed as expected.
That’s all for now. As a little extra I made a GitHub repository with some example code. Not more than a reminder. Please do not forget to add your experiences with this BAdI and IDocs via comments 🙂
