Solved: Difference between BADI and User Exits..

Former Member · ‎10-03-2005

Hi all,

Can anyone tell me the difference between BADI and User Exits, I have a interview coming up this week..

I will really appreciate your answers..

Regards,

-Ashok Hansraj

Former Member · ‎10-03-2005

There are several factors, which will influence your choice between a batch input session methods, call transaction or a BAPI. I will try to list out some of them here.

First is to look for a BAPI. The reason is that BAPIs are supposed to be APIs provided by SAP that protect the interfacing with a particular application in SAP (say sales order). They encompass all the business logic of the corresponding online transactions. Advantages are that they are supported by SAP and their call interface is very stable. Disadvantage is that most of them are synchronous calls and if you are doing massive data conversions, this may be a resource drainer. Also, with BAPIs, you not only need to read the return messages for errors and take corrective action, but also, you need to code for storing the source data so that you want to reprocess it. Sometimes BAPIs may not provide all the features of an online transaction and so they may limit to what data they can store, like texts for instance. If your data requires you to store texts along with the object and the BAPI doesn't provide you with the parameters for passing the texts, then you may end up doing it in two steps.

Batch Input session and call transaction are essentially the same in the sense that they both go through screen flows as opposed to direct data updates. But the major difference between the two is that one is done in batches (good for mass uploads like conversions) and the other is not done in batches. Once a batch is submitted for processing, the system processes it just like a call transaction. Batch inputs are good for massive data loads where you want create several small chunks of such call transactions and process those batches when you have system resources available. They may also be good if you want to retain the transaction data for error reprocessing, but this will not be your source data record.

Call transactions are good only if you want to handle the return messages in your code and act accordingly. So, let us say you create a sales order using call transaction method, and as soon as you get the success message with a sales order number, you want to do something else, and then a call transaction is useful. Similarly, if you have an error returned from the call transaction, then you want to report it(error notification), store the source record(may be in an error file or a table), or store the error transaction data(by inserting into a batch input session) for reprocessing. So a call transaction will give you the control after the transaction call is completed. If you want that control, you can use it. But remember that it uses up a lot of resources unless you take care of how it is processed. Also, as Rich pointed out, the latest mySAP enjoy transactions have a lot of controls and may not be suitable for call transaction method.

So what do you look at to decide?

1. Your data volume

2. Your frequency (one time vs. periodic interface)

3. Availability of the functionality you seek with the data you have. Do I have a BAPI that can achieve the desired results I want? Can I record the transaction to do a call transaction or batch input session?

4. Your error handling requirements. Do I need to notify? Do I need to persistently store my source records for any potential reprocessing? Do I need to log the results for audit requirements?

There are others that I can talk about like are their standard SAP programs for the data loads (SXDA, SXDB, LSMW etc)? Or Are there IDOC function modules that suit the purpose? Are there regular function modules that I can use (although not recommended as SAP can change them without notifying you, but again not unsurmountable if you have a good upgrade methodology)

Former Member · ‎10-03-2005

There are several factors, which will influence your choice between a batch input session methods, call transaction or a BAPI. I will try to list out some of them here.

First is to look for a BAPI. The reason is that BAPIs are supposed to be APIs provided by SAP that protect the interfacing with a particular application in SAP (say sales order). They encompass all the business logic of the corresponding online transactions. Advantages are that they are supported by SAP and their call interface is very stable. Disadvantage is that most of them are synchronous calls and if you are doing massive data conversions, this may be a resource drainer. Also, with BAPIs, you not only need to read the return messages for errors and take corrective action, but also, you need to code for storing the source data so that you want to reprocess it. Sometimes BAPIs may not provide all the features of an online transaction and so they may limit to what data they can store, like texts for instance. If your data requires you to store texts along with the object and the BAPI doesn't provide you with the parameters for passing the texts, then you may end up doing it in two steps.

Batch Input session and call transaction are essentially the same in the sense that they both go through screen flows as opposed to direct data updates. But the major difference between the two is that one is done in batches (good for mass uploads like conversions) and the other is not done in batches. Once a batch is submitted for processing, the system processes it just like a call transaction. Batch inputs are good for massive data loads where you want create several small chunks of such call transactions and process those batches when you have system resources available. They may also be good if you want to retain the transaction data for error reprocessing, but this will not be your source data record.

Call transactions are good only if you want to handle the return messages in your code and act accordingly. So, let us say you create a sales order using call transaction method, and as soon as you get the success message with a sales order number, you want to do something else, and then a call transaction is useful. Similarly, if you have an error returned from the call transaction, then you want to report it(error notification), store the source record(may be in an error file or a table), or store the error transaction data(by inserting into a batch input session) for reprocessing. So a call transaction will give you the control after the transaction call is completed. If you want that control, you can use it. But remember that it uses up a lot of resources unless you take care of how it is processed. Also, as Rich pointed out, the latest mySAP enjoy transactions have a lot of controls and may not be suitable for call transaction method.

So what do you look at to decide?

1. Your data volume

2. Your frequency (one time vs. periodic interface)

3. Availability of the functionality you seek with the data you have. Do I have a BAPI that can achieve the desired results I want? Can I record the transaction to do a call transaction or batch input session?

4. Your error handling requirements. Do I need to notify? Do I need to persistently store my source records for any potential reprocessing? Do I need to log the results for audit requirements?

There are others that I can talk about like are their standard SAP programs for the data loads (SXDA, SXDB, LSMW etc)? Or Are there IDOC function modules that suit the purpose? Are there regular function modules that I can use (although not recommended as SAP can change them without notifying you, but again not unsurmountable if you have a good upgrade methodology)

Former Member · ‎10-03-2005

From the BADI help:

A Comparison of Different Enhancement Techniques

Due to the necessity of adjusting R/3 to meet the specific needs of a variety of customers, several different enhancement techniques were developed in the past. A short description of each of the various enhancement techniques follows.

Business Transaction Events (Open FI)

The Open FI enhancement technique was developed in the Financial Accounting component. Open FI is based upon the following principles:

Application developers must define their interface in a function module, an assignment table is read in the accompanying (generated) code, and the customer modules assigned are called dynamically.

This technique differentiates between enhancements that are only allowed to have one implementation and enhancements that can call multiple implementations in any sequence desired. Both industry-specific and country-specific enhancements may be defined.

The concepts behind the Business Add-Ins enhancement technique and Open FI are basically the same. However, the two enhancement techniques do differ from each other in the following points:

Open FI can only be used to make program enhancements, that is, you can only enhance source code using Open FI. You cannot enhance user interface elements with Open FI like you can with Business Add-Ins.

Open FI assumes that enhancement will only take place on three levels (SAP - partners - customers), whereas with Business Add-Ins you can create and implement enhancements in as many software layers as you like.

Open FI uses function modules for program enhancements. With Business Add-Ins, ABAP Objects are used enhance programs.

Enhancements in Transactions SMOD/CMOD

Making enhancements using the transactions SMOD/CMOD has the following disadvantages:

This enhancement technique assumes a two-tiered system infrastructure (SAP – customers).

The naming conventions in effect do not tolerate name extension.

Taking Stock of Your Options:

None of the techniques mentioned above can easily be extended to fulfill the requirements of a system infrastructure containing country versions, industry solutions, partners, and customers.

Business Add-Ins should be considered generalized Business Transaction Events that can be used to bundle menu and program enhancements into a single add-in (and in the future, screen and table enhancements as well). Business Add-Ins can be created and employed in each of the various software levels.

Rob

suresh_datti · ‎10-03-2005

one Question you might be asked is.. what is the advantage of a BAdI over a User Exit? and the answer lies in Burbanks' reply..

"User Exits -->enhancements that are only allowed to have one implementation

BAdIs--> enhancements that can call multiple implementations in any sequence desired. "

Good Luck,

Suresh Datti

Former Member · ‎10-03-2005

Hello,

I am not sure how to copy and paste the link of a discussion on this forum..hence I am copying a small portion of that column provided by Sanjay.

Here is the link to that thread.

In contrast to user exits, Business Add-Ins no longer assume a two-level infrastructure (SAP and customer solutions), but instead allow for a multi-level system landscape (SAP, partner, and customer solutions, as well as country versions, industry solutions, and the like). Definitions and implementations of Business Add-Ins can be created at each level within such a system infrastructure.

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. You do not have to register Business Add-Ins in SSCR.

The Business Add-In enhancement technique differentiates between enhancements that can only be implemented once and enhancements that can be used actively by any number of customers at the same time. In addition, Business Add-Ins can be defined according to filter values. This allows you to control add-in implementation and make it dependent on specific criteria (on a specific Country value, for example).

Transaction SE19

http://help.sap.com//saphelp_470/helpdata/EN/eb/3e7cf4940e11d295df0000e82de14a/frameset.htm

Regards,

Message was edited by: Naren Somen