Selecting a specific BADI implementation by customizing


Sometimes we want to implement customer specific logics and to activate them by customizing context sensitively. Most famous examples are checks, calculations or conversations.

In most cases we can implement a SAP standard BADI and filter the context by development or BADI filter conditions. Every time the context changes, we have to change the BADI definition (filter criteria) or the source code of the BADI implementation (if or check statement). A consultant has no chance to change the context without help of a developer. That is very bad.

Solution for Classic BADIs:

To solve this issue, we need to use a bridge in order to connect the business context with the technical BADI implementation. This bridge is normally called „check id“, „condition id“, „filter id“ etc. It is configured in an own customizing table, used in some other customizing table (where we want to assign an implementation) and used as single-value filter id in the BADI implementation of a specific BADI definition. Sometimes we have to define such a filter id first and then create a BADI implementation including assign it to the filter id. Sometimes we don’t need to create the filter id as first step because it will automatically be created resp. added by the BADI when defining it.

This solution is working fine for classic BADIs. One prominent example is BADI EXEC_METHODCALL_PPF which is used to implement processing methods for PPF actions.

Solution for new BADIs:

New BADIs still have the feature to assign a data element (with value table) to a filter criteria. But the feature to specify the filter value as „enhanceable“ got lost.

The good news is, that there exist a very easy way to implement such an „enhanceable“ solution. For this solution we don’t need a customizing table to hold the filter id. Therefore the implementation effort is very lower.

  1. Create a new BADI definition.
  2. Set the flag „Limited Filter Use“ in the „Usability“ area.
  3. Define one filter criteria. (More are not allowed)
  4. Define and implement some BADI implementations. Each BADI implementation needs to be assigned to a filter value using the equal operator (other operators are not allowed). One BADI implementation can still be registered for more than one filter values using the OR operator.
  5. Define or extend a customizing table where you want to select a specific BADI implementation. Here you need a field which is used to store the filter value. Please create an own data element (if not done yet) to use proper names like „check id“ or „condition id“.
  6. To provide a proper value help please use search help /RTF/BADI_IMP_FILTER. Here you have to mention the name of the BADI definition in field „BADI_NAME“. Now this value help will always show all active BADI implementation with their corresponding filter values of the fixed BADI definition.
  7. Please maintain the customizing table and select the requested filter values. In program code you now have to read the customizing table based on the current business context. You have to extract the filter value, to get the BADI based on the filter value and to call the BADI with providing some context data (maybe including filter value).

That’s all. Very simple. It’s working!

Restriction: Search help /RTF/BADI_IMP_FILTER is supporting only filter values up to 4 characters. If you need more, you have to implement your own search help similar to the existing one. Just copy the search help + search help exit and exchange the data element.

That’s all. Very simple. It’s working!