The use of object orientated concepts within SAP has lead to new method of enhancing standard SAP code called Business Add-Ins or BAdI. BAdI are some what similar to user exits catering to the same need.
As an ABAP developer writing code may not be problem however where to write the code is always the point to think of.
The section below describes various ways to find the BAdI. The different ways or alternatives can help the developer to understand which BAdI would serve the purpose/requirement right.
The BAdI’s can be found in the following ways
1. Through SPRO
2. Through ST05 -> SQL Trace and Buffer Trace (Performance Analysis)
3. Through SE24 -> CL_EXITHANDLER.
4. Through function module SXV_GET_CLIF_BY_NAME.
Apart from the above mentioned methods we can also find the BAdI using the two methods below, Though not very effective but it‘s a GOOD-TO-KNOW information.
5. Through SE30 Runtime analysis
6. Through TADIR table entry.
Every method has been illustrated with screen shots and examples, hope this helps anyone for their development.
1 Through SPRO
The most basic method is searching through SPRO.
For example here we are searching for all the BAdI for Purchasing (This includes both PR and PO in the Material management module)
Step1. Execute Transaction SPRO-> SAP Reference IMG-> Material management (As our requirement specific to MM module)-> Purchasing.
Navigate through this node you would find the Node Business Add-In’s for Purchasing NODE.
Read through the Documentation available and check if the BAdI satisfies your requirement and then create an implementation. It is not mandate that the BAdI node will appear in the same manner for other module. We need to navigate through the all the nodes and find the BAdI node. For example In Purchasing we directly get the NODE business add-in however if we navigate through Sales and Distribution we get under the system modification.
Though this gives us all the BAdI that we have for the given module however it‘s not very specific to the transaction we may be looking for.
The Next method is the one through ST05. This answers to our problem, we can find all BAdI that trigger for a given transaction code.
2. Through ST05 -> Performance analysis
This method is based on the fact that all BAdI are registered in SAP database tables and during a transaction execution if any BAdI is called then these tables will surely be accessed. The BAdI database tables are SXS_INTER, SXC_EXIT, SXC_CLASS and SXC_ATTR. These tables are always accessed by the views V_EXT_IMP and V_EXT_ACT. When we create a trace for the given transaction we can filter the trace by these view names to get all BAdI.
Step1. Switch on the TRACE through Transaction ST05 (Performance analysis) and set the flag for ‘BUFFER TRACE’ ‘SQL TRACE’ and activate the trace.
Step2. Execute the transaction for which we need to find the BAdI, in our case it ME52N. Navigate through the transaction like change a data, check the document and save etc doing so the trace would capture all BAdI that would trigger on these events.
Step3. Execute Transaction ST05 and deactivate the Trace -> display trace. This would popup the screen ‘Set Restriction for displaying trace’. Under the field Objects fill values and hit OK.
Step4. Export the trace list to an excel document by hitting on the Trace list option in the MENU OPTIONS and SAVE as LOCAL file.
And save in the desired location.
After the download, excel would look like below.
The BAdI names are in the Statement field under col K.
Delete unwanted cols and then read through the definition documentation to understand if the BAdI will serve our purpose.
The short coming for this method is that though it lists out the BAdI called in specific transaction however it does not specify when the BAdI was called i.e. what triggered the BAdI? Is it the SAVE event or the ENTER or the CHECK or which navigating to any other screen. This becomes even more cumbersome if the documentation for definition is not available in the language you are looking for. The next 2 methods cover these short comings.
3. Through SE24 -> CL_EXITHANDLER.
This is a very simple but efficient method to find the BAdI for a give transaction.
Step1. Execute Transaction SE24 and enter the class name as CL_EXITHANDLER. There would be numerous methods with this class but we are interested only in GET_INSTANCE method.
Step2. Double click on the method name and place a break-point on the ‘CALL METHOD cl_exithandler=>get_class_name_by_interface’.
Step3. Now execute the transaction for which the BAdI is required.
The code processing would stop at the break-point we have applied, click on the EXIT_NAME in the Changing parameter. The parameter EXIT_NAME holds the name of the BAdI. Take a note of the BAdI and hit F8. If for instance we are looking for a BAdI while saving the document then when the SAVE button is hit processing would stop at the breakpoint and would give the name of the BAdI that would trigger at the SAVE event.
The next method is same the above only that instead of putting a breakpoint at CL_EXITHANDLER we can place a breakpoint in the function module SXV_GET_CLIF_BY_NAME atCALL FUNCTION 'SXV_ADD_PREFIX and execute the transaction.
The exporting parameter ‘NAME’ holds the value at the BAdI name.
Take a note of the BAdI that would trigger based on the requirement.
As discussed earlier, there are few methods which may not be as effective as the above mentioned methods however it always good to know that there are other alternatives available.
5 Through SE30 Runtime Analysis.
The Runtime analysis measures the CPU time required by ABAP statements. The most important are the database access, context statements, Modularization units like Perform Call function Call screen Call transaction etc, Internal Table operations like append collect Insert etc, Data transfer like read dataset etc and for our specific requirement the ABAP object statements Though there are many other statements that Runtime Analysis measure, we may not move into details of that.
Once we have the hit list from the SE30, we can search through the HIT LIST for METHOD cl_exithandler.
Execute Transaction SE30 and under the Current session tab enter the transaction ME52N (as used through out this document) and execute. Flow through the transaction and save and exit. So we now have the Runtime analysis available for the transaction we just executed, Search through the HIT LIST for “CL_EXITHANDLER”. Select the line and then in the Menu bar -> Goto -> Display Source code.
This would take us to the code where either the BAdI name is directly passed in the instance or through a variable. if its through a variable double click on the variable for the variable definition. The variable would obviously be TYPE REF to an interface name .
IF_EX_<BAdI name>.
Any thing after the IF_EX is the BAdI name.
In the above case
lc_cacl_character_input type ref to if_ex_cacl_character_input.
Then cacl_character_input is the BAdI name.
Lastly we can find some of the BAdI names from the TADIR table entry. Just as we can find the user exit from TADIR, BADI name can also be retrieved there. Though this is a good method for finding User exits however for BAdI this is just good-to-know information, the reason being that the BAdI name is fetched based on the Development class or the package. It may so happen that the package may contain all the BAdI provided by SAP for that transaction or the BAdI may exist in another Package which is accessed when the transaction is executed.
Consider the Example below.
Execute Transaction Se11 and display table TADIR. Execute TADIR for table entries.
Enter the following values.
Program ID (PGMID) : R3TR.
OBJECT : SXSD (For user exit use ‘SMOD’)
Development Class (DEVCLASS) : MEREQ (for transaction ME52N)
And execute.
Though ME52N has many other BAdI which are called however they exist in the package ME.
Every technique used here has its own advantages; however which technique is best suited depends on the developer and the requirement.