Custom BADI to replace User/Customer-exits

[former_member224371]

I have decided to write this blog after I saw there are some old-school user- exits still being used while enhancing standard SAP functionalities with some customer specific requirements. The idea behind this blog is to avoid keeping so many ‘IF’ conditions inside the user-exits for calling different requirements based on certain conditions. Instead, we can create our own BADI definition with required filter combination and also we can create multiple implementations based on different filter combination. So that it will be easy to separate the implementations and maintenance will be easy if any problem occurs in any of the implementations.  The defined BADI can be called from user-exit by passing runtime filter values, so that system determines the corresponding implementation for execution.

Introduction:  The common meaning extracted from this saying is that too many people working on a single task tend to make a mess of it. Let’s think of situation where too many developers working on a single piece of ABAP code.  What will happen in that case??? Yes... it will go for a big mess. This issue is especially difficult to deal with when there are multiple functional requirements leveraging the same custom code object, form-based user-exit, or function-based user-exit.

While current releases of SAP have good control of doing enhancements and customizations via BADI’s, Implicit and explicit enhancement points, there still exists many user-exits (Form based / Function based) For customer specific requirements especially in case of IDOC extensions.

Standard SAP solution for latest IDOC’s:  In case of latest IDOC’s for few cases SAP provided BADI definition’s (With / without filters) for making different implementations specific to different customer specific requirements. For example in case of IDOC ‘SHP_OBDLV_CONFIRM_DECENTRAL04 ‘SAP provided BADI ‘SMOD_V50B0001‘. But still there are many IDOC’S available without BADI functionality for making IDOC extensions.

      

Note: Please note that this blog provides a simple roadmap of how to handle such situations to use BADI functionality instead of using user exits.  I am not trying to rule out the possibility of doing it through Standard BADI’S (If any during the same process), if they are available please use them. In this blog I am using IDOC example since at many places for standard IDOC’s still SAP is using Function based user exits for customer specific requirements.

Requirement: So let’s say multiple developers were creating different integrations based on the shipment inbound IDOC.  Each integration requires a separate set of custom functionality and therefore, its own IDOC extension.

The problem is SAP has provided only one customer exit for doing this functionality and all developers needed to be developing in it at the same time.

How to solve:  I decided to create a custom BADI definition with attributes multiple-use, filtered and create the implementations for each different requirement and use the filters to separate the implementations.  Actually you can implement your own BADI almost anywhere you need alternate logic execution.

As an example i have demonstrated here how to replace the customer-exit ‘EXIT_SAPLV55K_020’ with BADI.  This particular exit gets called during inbound shipment IDOC processing (IDOC_INPUT_SHPMNT) to modify the IDOC data record before shipment processing.So, I have created below steps for achieving the same.

1.       Use SE18 transaction to create new enhancement spot definition.  In the below example the name is given as ‘Z_EXIT_SAPLV55K_020‘since this enhancement spot will be used in customer exit function ‘EXIT_SAPLV55K_020’.

2.       Choose BADI definition for Technology

  

3.       Now create a new BADI definition and specify that new BADI definition will be multiple uses.

      

4.       Create new filter and specify filter combination.  In this example we are using BADI definition to modify IDOC shipment data.Each integration has its    

          own control record and out of that Message type, Message code, Message function, IDOC Type and extension will be always unique. So it is good to

          define the filter combination accordingly to separate the implementations for different requirements.

          

5.       Create the BADI interface that will be inherited by each implementing class.  Define the method and maintain the parameters exactly similar to   

         customer-exit function, since the BADI we are creating is the replication of customer-exit function.

            Here is the function interface for ‘EXIT_SAPLV55K_020’.

      

The same parameters (data) are being passed via the interface method as well.     

6.       Create the BADI Implementation with required filters and add the code to the method just like you would in customer-exit function.

7.       As a final step, the BADI has to be called from the customer-exit. Define the global BADI object with reference to BADI definition. The idea behind

         defining global BADI object is to prevent instantiations unnecessarily inside IDOC data loop.