Mastering SAP Enhancements: Business Add-Ins (BAdIs)

In the world of SAP, adapting standard functionalities to meet unique business requirements is a common challenge. While various enhancement techniques exist, Business Add-Ins (BAdIs) stand out as a powerful and flexible solution. But what exactly are BAdIs, and how do they differ from other enhancement options like user exits or modifications? 

This post will demystify BAdIs, exploring their object-oriented nature, different types, and practical implementation, including how to find and activate them. 

What Exactly is a BAdI? 

A BAdI is an enhancement technique in SAP that allows you to extend standard SAP code without modifying the original core system. This is crucial for maintaining system integrity and simplifying upgrades. When you enhance SAP functionalities using BAdIs, your custom code resides in the customer namespace (typically starting with Y or Z). 

BAdIs vs. Other SAP Enhancement Techniques 

So, what makes BAdIs unique compared to implicit enhancements, explicit enhancements, customer exits, user exits, or even direct modifications? The key differentiator lies in their foundation: 

• Object-Oriented Programming (OOP): BAdIs are built upon OOP concepts, primarily interfaces and classes. This provides a structured, modular, and reusable approach to enhancements, unlike older, more procedural methods. 

• Dedicated Transaction Codes: 

  • SE18 is used for BAdI definition. Think of it as defining the interface where SAP provides a hook for your custom logic. 

  • SE19 is for BAdI implementation. This is where you write your actual ABAP code within a class that implements the BAdI interface. 

The Two Flavors of BAdIs: Classic vs. Kernel 

SAP offers two main types of BAdIs: 

1. Classic BAdIs: These are the original BAdIs, widely used for many years. 

2. Kernel BAdIs (New BAdIs): Introduced later, these offer more advanced features and improved performance. This blog will focus on Classic BAdIs for practical demonstration. 

Practical Example: Restricting Unit of Measure (UOM) in MM01 

Let's illustrate how to use a Classic BAdI with a common business requirement: preventing users from entering "KG" as the Unit of Measure (UOM) when creating a material in transaction MM01. 

Currently, if you go to MM01, select "Pharmaceuticals" as the industry sector and "Raw Materials" as the material type, then enter "KG" for the UOM and save, the system allows it. Our goal is to prevent this. 

Let’s see this in action 

1. Navigate to MM01

   

2. Select "Pharmaceuticals" as the industry sector and "Raw Materials" as the material type and press Enter

   
   

   

3. Select the View as Basic Data1 and Basic Data2 and click on Continue  

   

4. Give the description and UOM as KG and click on the save button.  

   

5. You will see our material is getting saved.  

   

Now let’s use classic BAdI and enhance the standard SAP to prevent saving the data if the Basic Unit of measure is KG. 

These are the 3 tasks we perform 

1. Finding a Classic BAdI 

2. Implementing the Classic BAdI 

3. Cleaning Up Your Implementation (optional) 

Finding a Classic BAdI 

Before implementing, we need to find the right BAdI. Here are the common methods: 

1. Using CL_EXITHANDLER=>GET_INSTANCE (Recommended for ABAPers) 

This is the preferred method for technical users because it allows for debugging, which is invaluable for understanding the flow and identifying suitable BAdIs. 

• Go to transaction SE24 and display class CL_EXITHANDLER. 

  

• Double-click on the GET_INSTANCE method. 

  

• Go to MM01, enter the material data, and before saving, in the other window set a breakpoint at sy-subrc condition within the GET_INSTANCE method. 

  

• Back in MM01, when you press "Save" the debugger will stop at this breakpoint, and you'll see BAdI names populate in the exit_name variable one by one. 

  

• Check each BAdI in SE18 to see if its purpose aligns with your requirement. For our UOM validation, BADI_MATERIAL_CHECK (Enhanced checks for material master tables) is ideal, as it has an interface method CHECK_DATA where we can inspect the UOM.  

  

2. Searching by Package Name in SE18 

• Go to MM01 and find the program's package name (System > Status > Program > Attributes). For MM01, the package is typically MGA. 

  

• In SE18, use F4 help on the BAdI name field and choose new selection. 

  

  

• Select "Classic BAdIs" and enter "MGA" as the package name. This will list all Classic BAdIs within that package. You'll then need to manually check each one in SE18 to find the relevant BAdI. 

  

  

3. Searching by Package Name in SE84 

• Go to transaction SE84. 

  

• Navigate to Enhancement > Business Add-Ins > Definitions. 

  

• Select "Classic BAdIs" and provide the package name (MGA). This yields the same results as searching in SE18, requiring manual checks. 

  

  

While the second and third methods provide a list, the CL_EXITHANDLER=>GET_INSTANCE method with debugging is generally more efficient for pinpointing the exact BAdI you need. 

Implementing the Classic BAdI (BADI_MATERIAL_CHECK) 

Once you've identified BADI_MATERIAL_CHECK as the suitable BAdI: 

• Go to transaction SE19 to create an implementation. 

  

• Select "Classic BAdI" and enter BADI_MATERIAL_CHECK. Click "Create". 

  

• Give your implementation a name (e.g., Z_UOM_CHECK_BADI_IMP – remember the Z prefix for customer namespace). 

  

• Provide a description. You'll notice that the class name (e.g., ZCL_IM_BADI_IMP_UOM_CHECK) is automatically generated. This is a key feature of Classic BAdI implementation.

  

• Double-click on the generated class name. Confirm saving it as a local object. 

  

• Activate the class. 

• Double-click on the CHECK_DATA method within the class. 

  

• Inside the CHECK_DATA method, you'll find importing parameters, including a structure like WMARA which contains the UOM in the MEINS field. Write your ABAP logic here to check if WMARA-MEINS is 'KG'. If it is, raise an error message. ABAP IF im_wmara-meins = 'KG'.   MESSAGE 'Unit of measure KG is not allowed!' TYPE 'E'. ENDIF.  

  

  

• Save and activate the method. 

• Crucially, activate the BAdI implementation itself in SE19. 

Now, if you try to create a material in MM01 with UOM as "KG" and save, you will receive your custom error message! If you use a different UOM, the material will save successfully. 

Cleaning Up Your Implementation 

For practice or when an enhancement is no longer needed, it's good practice to deactivate or delete your BAdI implementation: 

• Go to SE19, enter your BAdI implementation name, and click "Change". You can deactivate it from here. 

  

  

• For complete removal, delete the generated class in SE24 (e.g., ZCL_IM_BADI_IMP_UOM_CHECK) and then delete the BAdI implementation in SE19. 

  

  

  

  

Understanding BAdI Properties: SAP Internal, Multiple Use, and Filter-Dependent 

When defining or examining BAdIs in SE18, you'll encounter several checkboxes that determine their behavior: 

• SAP Internal: If checked, this BAdI is reserved for SAP's internal use and cannot be implemented by customers. 

• Multiple Use: 

• If ticked, you can create and activate multiple implementations for the same BAdI definition. All active implementations will be executed when the BAdI is called, though the order of execution is not guaranteed. Our BADI_MATERIAL_CHECK was a multiple-use BAdI. 

  

• If not ticked, only a single active implementation is allowed. 

• Filter-Dependent BAdI: 

• If ticked, you can activate multiple BAdI implementations simultaneously based on a specific filter value. Without a filter, a classic BAdI (unless it's "Multiple Use") can only have one active implementation at a time. 

  

  

• A filter type (e.g., "Notification Type" for NOTIF_EVENT_SAVE or "Country ISO Code" for BADI_ADDRESS_CHECK) allows you to define different implementations that execute based on a specific data value. This is incredibly useful for multinational companies with varying rules per country or other criteria. 

• When implementing a filter-dependent BAdI in SE19, you must specify a filter value. If you try to activate without one, you'll get an error. You can add multiple filter values to one implementation, but they must be unique across all active implementations of that BAdI. 

• The filter value is passed as a parameter into your BAdI method, allowing you to tailor your ABAP logic based on it. 

• Single-Use BAdIs 

• A BAdI with neither "Multiple Use" nor "Filter-Dependent" checked is a Single-Use BAdI. This means you can only have one active implementation at any given time.  

• If you try to activate a second implementation, the system will prevent it, indicating that another active implementation already exists. 

Pro Tip for Filter-Dependent BAdIs 

When working with multiple filter-dependent BAdIs or switching between BAdI definitions in SE18 or SE19, always exit the transaction completely (e.g., by typing /n in the command field) before opening the next BAdI. This helps prevent filter values from one BAdI from incorrectly appearing in another. 

Conclusion 

BAdIs are a cornerstone of effective SAP enhancement, offering a robust, object-oriented approach to customizing standard functionalities. Understanding their types, how to find them, and their implementation nuances, especially the critical properties like "Multiple Use" and "Filter-Dependent," empowers you to build flexible and maintainable solutions. By embracing BAdIs, you can extend SAP's capabilities precisely to meet your business needs while keeping your system future-proof. 

Use full Links -

1. SAP Blogs: https://www.sastrageek.com/blog

2. SAP ABAP – Consultant (Course Curriculum)

3. Post Your Queries

4. Micro Learning by Sastrageek Solutions

5. Join Free Counselling session with expert      

6. Check Full Training videos

Chandini Sirigirisetti

SAP ABAP Consultant

LINKEDIN- https://www.linkedin.com/in/chandini-sirigirisetti

SAP ABAP