BAPI - These are published programs which is used to upload data into SAP system.
BAPI is Business Application Programming Interface and has the role as communication plattform for developing applications, e.g. booking material documents from flat files, see more in trx BAPI.
BAPI - Business Application - commonly a function module that is normally RFC enabled as well and acts as a method of a business object. For example, Sales Order as the business object with a method of create - the BAPI is BAPI_SALESORDER_CREATEFROMDAT2.
BAdI is Business Add-In, and it should take the place from the user- exits (trx: SE18, SE19)
BADI - This is a program enhancement technique. SAP provides BADI openings in the standard programs. You need to search for the suitable BADI as ur requirement and then do the coding and plug in the program.
A BADI is a Business Add-in - one of SAP's methods of implementing a user-exit or change to standard SAP code. BADI's are ABAP object based changes instead of the more common subroutines/function modules.
To implement BADI,
Follow the below steps to find out what all BADI's are called when you press any button in any transaction.
1) Goto se24 (Display class cl_exithandler)
2) Double click on the method GET_INSTANCE.
3) Put a break point at Line no.25 (CASE sy-subrc).
4) Execute SAP standard transaction
5) Press the required button for which you need to write an exit logic, the execution will stop at the break point.
6) Check the values of variable 'exit_name', it will give you the BADI name called at that time.
7) This way you will find all the BADIs called on click of any button in any transaction.
Reward if helpful.
badi : Business add-ins are enhancements to the standard version of the system. They can be inserted into the SAP System to accommodate user requirements too specific to be included in the standard delivery. Since specific industries often require special functions, SAP allows you to predefine these points in your software.
You can differentiate between single-use and multiple use Business Add-Ins. The distinction is based on the procedure or event character of an enhancement. In the first case, the program waits for the enhancement to return something, usually a return code. A typical example could be a benefit calculation in HR. Depending on the implementation, alternative calculations can be executed. With multiple use add-ins, an event that may be of interest to other components is processed in program flow. Any number of components could use this event as a hook to hang their own additional actions on to.
In addition to importing parameters, you can also use changing parameters for multiple-use Business Add-Ins. There is no sequence control for multiple-use implementations of BadIs. Therefore, using changing parameters can cause problems. There is no guarantee that implementations will not overwrite the results of previous implementations. Sequence control is technically impossible, since at the time of the definition the interface does not know which implementations there will be and which parameters will be changed by implementations. It is not possible to have a decision as to which implementation should be executed before which other (future) implementation.
In a particular application, you want to be able to continue processing indexes after another component has saved data (in other words, the system should allow you to use an add-in after saving). Since this point in time can be useful for different purposes, you can create an enhancement here that can be used by multiple subscribers.
To create a multiple-use Business Add-In, proceed as follows:
1. Define an add-in and select the Multiple Use checkbox from the Administration tab.
2. Define an interface with the method OBJECT_SAVED'and the importing parameter OBJECTNAME.
Calling your enhancement in the application program:
data exit_obj type ref to if_ex_event.
call method cl_exithandler =>get_instance
changing instance = exit.
form save_object using obj_name type c.
call method exit_obj->object_saved
exporting objectname = obj_name.
For the caller it is irrelevant whether (and how many) subscribers use the event as a starting point for further actions. The active implementations are called in the adapter method.
A remote function call is a call to a function module running in a system different from the caller's.
The remote function can also be called from within the same system (as a remote call), but usually caller and callee will be in different systems.
In the SAP System, the ability to call remote functions is provided by the Remote Function Call interface system (RFC). RFC allows for remote calls between two SAP Systems (R/3 or R/2), or between an SAP System and a non-SAP System.
RFC consists of the following interfaces:-
A calling interface for ABAP programs
Any ABAP program can call a remote function using the CALL FUNCTION...DESTINATION statement. The DESTINATION parameter tells the SAP System that the called function runs in a system other than the caller's.
RFC communication with the remote system happens as part of the CALL FUNCTION statement.
RFC functions running in an SAP System must be actual function modules, and must be registered in the SAP System as "remote".
When both caller and called program are ABAP programs, the RFC interface provides both partners to the communication. The caller may be any ABAP program, while the called program must be a function module registered as remote.
Calling interfaces for non-SAP programs
When either the caller or the called partner is a non-ABAP program, it must be programmed to play the other partner in an RFC communication.
To help implement RFC partner programs in non-SAP Systems, SAP provides-
RFC-based and GUI-based interfaces can be used by external programs to call function modules in SAP R/2 or R/3 systems and execute them in these systems.
Vice versa, ABAP programs in R/2 or R/3 can use the functions provided by external programs via these interfaces.
M<reward if useful>
Edited by: Jagadeshwar Gollapelly on Mar 20, 2008 5:34 AM
-->badi is a term referring to business add-ins.
-->badi stands for bussinesaddings and its for enhancements in the applicaion area .main use of it is reusabilty
-->When the customer needs more functionality than the SAP
standard Program(Functionality)then we can add extra
functionality to standard SAP functionality through Badi.
Badi can't distrub the orginial(standard)code.
Adding extra functionality to the standard is nothing
Badi are not creted in the program itself.
They are created and maintained seperately and called when
we need the Badi.
One of the big plusses for BAPIs is that the interface and function are not supposed to change. This is a big plus when you do upgrades or hot packs because the transaction can change (format, required inputs etc) which means you then need to update the call transaction.
Some of the BAPIs are better documented and easier to use than others.
You usually need to perform the BAPI that actually does the COMMIT after you call your BAPI.
The Program coding for calling a BAPI is usually cleaner than setting up the screen flow etc for the Call Transaction.
You don't need to worry about special data circumstances interrupting the normal data flow of the screens and causing errors because of that.
BAPIs probably have better performance since they don't do the screen flow processing.
In general if the BAPI exists for the transaction you want to perform and you can figure out how to use it the BAPI is probably the best way to go.
This is just from my experience working with both BAPI and Call Transaction. I have had some very good successes with BAPIs, but very occasionally found that I could not get the BAPI to perform the update I needed.
The interface concept of the classic R/3 is based on two different strategies: Remote Function Calls (RFC) and data exchange through IDoc message documents. RFC makes direct and synchronous calls of a program in the remote system. If the caller is an external program it will call an RFC-enabled function in R/3 and if the calling program is the R/3 system it will call an RFC-function in another R/3-system or it will call a non-R/3 program through a gateway-proxy (usually rfcexec.exe).
BAPIs are a subset of the RFC-enabled function modules, especially designed as Application Programming Interface (API) to the SAP business object, or in other words: are function modules officially released by SAP to be called from external programs.
Bapi a function module that is normally RFC enabled as well and acts as a method of a business object.You create business objects and those are then registered in your BOR (Business Object Repository) which can be accessed outside the SAP system by using some other applications (Non-SAP) such as VB or JAVA. in this case u only specify the business object and its method from external system in BAPI there is no direct system call.
A BADI is a Business Add-in - one of SAP's methods of implementing a user-exit or change to standard SAP code.