Skip to Content
Technical Articles
Author's profile photo Michael Keller

tips and tricks around BAdI IDOC_DATA_MAPPER

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):

  1. Class ZCL_<..>_IDOC_DATA_MAPPER: For tasks like extracting values from IDoc, calling business logic to map values, publish changed IDoc values and more.
  2. Class ZCX_<..>: Exception class to handle technical IDOC_DATA_MAPPER problems.
  3. Class ZCL_<..>_MAPPING: To fullfill the original business requirements.
  4. 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 🙂

 

Many thanks for reading and stay healthy

Michael

Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.