BADI – Business Add Ins are enhancements to the standard version of the code of SAP. They can be inserted into the SAP system to accommodate user requirements too specific to be included in the standard delivery. Customers can find the possible enhancements (BADIs) in their SAP system in the Implementation Guide (IMG) and in the component hierarchy. BADI definitions are included in the IMG so that the customer can create suitable, company-specific implementations. SAP guarantees the upward compatibility of all Business Add-In interfaces. Release upgrades do not affect enhancement calls from within the standard software nor do they affect the validity of call interfaces.
Two different views are available:
- In the definition view, an application programmer defines exit points in a source that allow specific industry sectors, partners, and customers to attach additional coding to standard SAP source code without having to modify the original object.
- In the implementation view, the users of Business Add-Ins can customize the logic they need or use a standard solution if one is available.
Definition of A BAdI
SAP application developer actually defines a Business Add-In available to an application program. Tcode SE18 can also be used to see the definition of existing badi .The following are the steps in defining a BADI:
1. Using the SAP BADI builder, the SAP application developer defines an enhancement (BADI). It consists of an interface with a method.
2. The interface name is generated automatically and can be changed. The system branches to the Class Builder.
3. Using the Class Builder, the developer assigns a method to the interface.
4. For each method, he defines parameters. Parameters can either be importing or changing and these are the fields available for customer to use for enhancements. Importing parameters are the fields being passed from the calling program and changing parameters are the fields being passed back to the program.
5. The Business Add-In is then activated in the Class Builder.
Note: Documentation of the BADI usually provides the list of parameters and their definition. For example, for method DETERMINE_EXTPO, the available parameters are:
o ITEM_DATA Item data (is a structure)
o If the field has the value X, the request is subject to the extended classic scenario.
o If the field is empty, the request is not subject to the extended classic scenario.
Implementation of a BAdI
If a customer wishes to use a Business Add-In, he or she first creates an implementation. The customer must implement the methods and the enhancements. You need to program the interface method in such a way that, when the add-in is called from the application program, it will perform the specific action the customer intends. The following are the steps customer can follow in implementing a BADI:
1. In the SAP menu, choose ABAP Workbench ® Utilities ® Business Add-Ins (transaction SE19) or double-click the corresponding activity in the Implementation Guide (IMG).
2. Enter a name for the implementation and then click the Create pushbutton.
3. Enter the name of the add-in for which you want to create an implementation for in the dialog box that appears. Choose the Interface tab.
4. Choose ABAP Code as the implementation type.
5. Navigate to the Class Builder by double-clicking the method. You must first enter a
package before the Class Builder is displayed.
6. Insert the desired source code for the implementation between the method if_ex_businessaddin~method. and endmethod (statements that already exist) You need to use the parameters (importing and changing) as fields within the BADI. You can define additional fields you need in the coding as local data fields.
7. Save your entries and return to the Change Implementation screen.
8. Choose Activate. The enhancement’s active components are then called at runtime.
Definition name BBP_EXTLOCALPO_BADI
Implementation Name ZEXTENDEDCLASSIC
Interface name IF_EX_BBP_EXTLOCALPO_BADI
Name of implementing class: ZCL_IM_EXTENDEDCLASSIC
ABAP Code Determination of Control for Extended
METHOD IF_EX_BBP_EXTLOCALPO_BADI~DETERMINE_EXTPO. DATA: zzecs type zecs. * local data field *extended classic will be activated only for specific product categories IF item_data-category eq '420DD2C2CFDF56478E705E352FEC86CB'. bbp_extpo_gl-bbpexpo = 'X'. ELSE. SELECT single * from zecs into zzecs where product eq item_data-product. IF sy-subrc eq 0. bbp_extpo_gl-bbpexpo = 'X'. ENDIF. ENDIF. ENDMETHOD.
Business Add-Ins may also be implemented on the basis of a filter value. The application program provides the filter value for the enhancement method. The filter parameter is defined within the method when creating the interface. For each method created in the interface of a filter-dependent enhancement, the filter value must be defined as the importing parameter so that the application program can provide the filter value to the enhancement method. The method then selects the active implementation for that value. The filter value is always declared using the parameter flt_val and is predefined in the list of parameters
You can use the Business Add-Ins BBP_DOC_CHANGE_BADI to make changes to the document, after user entry and before saving the document to the database. These changes are subject to the document-specific checks. The parameter FLT_VAL acts as a filter value that assigns the BAdI implementation to a particular document type. You can use the BAdI to change some of these documents:
o Shopping cart (filter value BUS2121 – shopping cart EC)
o Purchase order (filter value BUS2201 – purchase order EC)
o Confirmation (filter value BUS2203 – confirmation of goods/services EC)
o Invoice (filter value BUS2205 – incoming invoice EC)
o Bid invitation (filter value BUS2200 – bid invitation EC)
Calling A BAdI in The Applicat?on Program
When a Business Add-In is created, enhancement management generates a class that implements the interface. The application developer uses a factory method to create an instance of this adapter class in the application program and calls the corresponding method, if necessary.
The adapter class method generated by add-in management decides whether one or several active implementations should be called. If necessary, these implementations are subsequently executed. The application program ensures only that the adapter class method is called. The application program does not know which implementations are called.