Monday, April 14, 2008

BADI vs User Exit

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.


As with customer exits, 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.

In contrast to customer 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, country-specific versions, industry solutions, partner, customer, and so on). You can create definitions and implementations of Business Add-Ins at any level of the system landscape.
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 differentiate between Add-In implementations using the filter Country or other criteria.

All ABAP sources, screens, GUIs, and table interfaces created using this enhancement technique are defined in a manner that allows customers to include their own enhancements in the standard. A single Business Add-In contains all of the interfaces necessary to implement a specific task.
In order to enhance a program, you must first define a Business Add-In. The application developer creates an interface for the add-in. From this, enhancement management creates an adapter class that implements the interface and thus provides the interface for implementation by the customer, partner, and so on. The developer then creates an instance of the adapter class in the application program and calls the corresponding method at the appropriate time.

For each Business Add-In you have one interface and an adapter class that implements this. The interface is implemented by the user.
The generated class (Add-In adapter) has the following tasks:
· Control

The adapter class calls the active implementations.
1. · Filtering
If a Business Add-In is to be executed only under certain conditions, the adapter class ensures that only certain implementations will be executed.

This concept ensures mutlple use. Any Business Add-In that has been implemented once already can be implemented again by those groups listed to the right of the software chain shown in the above graphic.
Customers can find the enhancements in their system in the Implementation Guide (IMG) and in the component hierarchy. 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, and afterwards activate the implementation of the enhancement. The enhancement's active components are then called at runtime. Normally, a Business Add-In contains an interface and other additional components such as function codes for menu enhancements. In some cases, Business Add-Ins also include enhancements for screens. The enhancement, interface, and generated classes are all located in the appropriate application development namespace. Business Add-In implementations are created in the respective implementation namespace.

No comments:

Blog Archive