BADI INTRODUCTION:

Traditional way of doing code modifications – Exits.

In three tierr Architecture exits are implemented as explained below.

PRESENTATION :

Field Exits
Screen Exits
Menu Exits

APPLICATION:

Programs -> Program exits -> call customer function -> Include

DATABASE

Table -> SE11 -> Goto -> Append Structure
With BAdIs you can make changes only at the Application Layer.

The traditional way of doing code modifications was via User exits.

As per SAP’s 3 Tier Architecture, at the Presentation layer you had Field Exits, Screen Exits and Menu Exits. At the Application layer you had Program exits, at the Database layer you could Append structures to the existing SAP structures.

Business Add-Ins are a new SAP enhancement technique based on ABAP Objects.

They can be inserted into the SAP system based on specific user requirements.

Business Add-Ins should be considered generalized Business Transaction Events that can be used to bundle program, menu and screen enhancements into a single add-in.

In order to enhance a program a Business Add-In must first be defined and

Subsequently two classes are automatically generated :

An interface with ‘IF_EX_’ inserted between the first and second characters of the BAdI name

An adapter class with ‘CL_EX_’ inserted between the first and second characters of the BAdI name.

The Application developer creates an interface for this Add-In.

Enhancement management generates an adapter class for implementing the interface.

This opens a path for custom implementations to be created by partners or customers.

By instantiating the adapter class in the application program, its corresponding methods can be used.

In Business Add-Ins, all the components of an enhancement option are grouped together.

They are

1. Program Enhancements: Functional enhancement of the program are defined in the form of interface methods and can be used with or without Menu Enhancements or Screen enhancements.

2. Menu Enhancements: Function codes can be entered for a BAdI for the corresponding menu entries in the user interface definition.

3. Screen Enhancements: Subscreen areas can be entered for a Business Add-In.

Screen enhancements can be implemented for these in the form of subscreen screens.

Each Business Add-In has :

1. at least one Business Add-In definition
2. a Business Add-In interface
3. a Business Add-In class that implements the interface

SAP ABAP BADI IMPORTANCE

Business Add-Ins are a new SAP enhancement technique based on ABAP Objects. 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:

1·In the definition view, an application programmer predefines exit points in a Source that allow specific industry sectors, partners, and customers to attach additional software to standard SAP source code without having to modify the original object.

2·In the implementation view, the users of Business Add-Ins can customize the logic they need or use a standard logic 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, 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).

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.

The actual program code is enhanced using ABAP Objects.

COMPARISION OF ENHANCEMENT TECHNIQUES IN SAP ABAP

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 is used to enhance programs.

Enhancements in Transactions SMOD/CMOD

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

1. This enhancement technique assumes a two-tiered system infrastructure (SAP –customers).
2.The naming conventions in effect do not tolerate name extension.

Conclusion:

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 program, menu and screen enhancements into a single add-in. Business Add-Ins
can be created and employed in each of the various software levels.

SAP ABAP BADI DEFINATION

Define an interface for the enhancement in the SAP menu under Tools ® ABAP Workbench ® Utilities ® Business Add-Ins (transaction SE18) and call this interface at the appropriate point in their application program. Customers can then select the add-in and implement it according to their needs.

Example:

You want to be able to convert strings in your application program. You also want users to determine how their strings are converted themselves. As the application developer, you define an enhancement consisting of an interface with a method. A changing parameter is used to transfer strings.

To create an add-in like this, proceed as follows:

1. Choose Tools ® ABAP Workbench ® Utilities ® Business Add-Ins (transaction SE18)
from the SAP menu.

2. Enter a name for your Business Add-In containing a maximum of 20 characters.

3. Choose Create.

4. On the subsequent screen, enter a short description for your Business Add-In.

The option SAP internal is used when a developer at SAP provides a business add-in with implementations. If this flag is set, customers cannot create and use their own implementations for this business add-in. The possible entries help does not display business add-ins carrying this flag.

If this enhancement is going to be used multiple times or if you want its implementation to depend on a specific filter value, select the appropriate checkbox in the category Type.

This example only deals with basic enhancements, therefore neither of these check boxes should be selected.

5. Choose the Interface tab.

The name of the interface, which is generated automatically, now appears. At this time, you can change the name of the interface if you so desire.

7. Confirm that you want to save the entries you have made. Assign your add-in to a
package.

8. Use the Class Builder to assign a method to the interface.

9. Now define a parameter with the following attributes:

10. Save and activate your changes. Use the pushbutton Back to navigate back to Business Add-In definition.

If you do not activate your attributes in the Class Builder, the system will not allow you to proceed with Business Add-In definition.

A table control now appears on the definition screen containing the method you have
assigned to the interface.

Whenever you assign a method to an interface, the corresponding executing class is
generated. The code generated cannot be altered in the initial expansion phase.

11. Save your entries and use the Def.-Docu. pushbutton to create a description for your new Business Add-In. Be aware that this documentation is of great importance in helping end users understand the purpose of your add-in.

Changes made to the interface and changes made to the Business-Add-In definition are always incompatible!

If implementations already exist for a Business-Add-In definition, they are invalidated if you make changes to the interface. This means that their syntax is no longer correct. No statements can be given on the runtime behavior. Try to absolutely avoid making changes to the interface or the Business-Add-In definition after the transport has taken place.

If changes to the interface are inevitable, clean up the method includes for all implementing classes, that is, all classes for which Business-Add-In implementations are used. To do this, in the Class Builder (using transaction SE19, tab Interface, field Name of implementing class) choose Utilities ® Clean up ® Method includes.

Default and Sample Code

In the BAdI Builder, you can choose the Goto menu entry to create, display, change and delete
default or sample code.

The default implementation is only executed if no other active implementation is available. This
applies also to filter-dependent Business Add-Ins.

When you create default or sample code, do not forget to save your entries to ensure that the link between the class and the implementation can be established.

Calling Add-Ins from Application Programs

When you define a Business Add-In, enhancement management generates a class that implements your interface. Application developers use factory methods to create instances of
these adapter classes in their application programs and call the corresponding method if necessary.

The adapter class methods generated by add-in management decide if multiple active
implementations should be called. If necessary, these implementations are subsequently
executed. The application program itself simply calls the adapter class methods; it does not know
which implementations are actually being called.

ABAP BADI IMPLEMENTAION

This can be taken like a continuation post for ABAP BADI DEFINATION

A list of the Business Add-Ins present in your system can be found either in the IMG or in the component hierarchy. The enhancements' names and corresponding documentation should help you decide which add-in you want to create an implementation for. During implementation creation, a class for implementing the enhancement's interface is also created. Implementations are discrete transport objects and lie within the namespace of the person or organization implementing them.

In order to create an implementation for the string conversion example, the add-in (in this case,the interface's method) needs to be filled with logic that converts the string. This logic will be run through every time the add-in is called from the application program.

To create an implementation, proceed as follows:

1. Choose ABAP Workbench ® Utilities ® Business Add-Ins (transaction SE19) from the SAP menu or double-click on the corresponding activity in the Implementation Guide.

2. Enter a name for the implementation and choose Create.

3. Enter the name of the add-in you want to create an implementation for in the dialog box that appears.

4. Enter a short text describing your implementation on the following screen.

5. Choose the Interface tab.

6. Choose ABAP Code as the implementation type.

Besides ABAP Code, there is also the Formula option. If you choose Formula, the content of a method is determined using the Formula Builder. For more information on this, see Implementing Methods Using the Formula Builder.

7. Navigate to the Class Builder by double-clicking the method. You must first enter a package before the Class Builder is displayed.

8. Insert the desired source code for the implementation between the method if_ex_businessaddin~method. and endmethod. statements automatically provided to you by the system.

Enter the statement translate parameter to upper case. for the string conversion example.

9. Save your entries and return to the Change Implementation screen.

10. Choose Activate. You may now use this implementation when the application program is executed.

Numerous implementations may exist for a Business Add-In that cannot be used on a multiple basis. However, only one implementation can be active for these kinds of Business Add-Ins at any one time.

What is also important is that you must declare the instance generation of the implementing class (Attributes tab) as public and not as private or even abstract. If you do this, the system will return short dumps at runtime.

SAP ABAP BUSINESS ADD-INS IMPLEMENTATION

This concept is in continuation with SAP ABAP BADI FILTER DEPENDENT PART TWO and it may be more convenient if you to go through it before proceeding to this concept.

If you want to use a filter-dependent Business Add-In, you will need an implementation for each relevant filter value. Multiple filter values may use the same implementation, however.

When implementing a filter-dependent Business Add-In, proceed as follows:

1. Create an implementation by referring to the corresponding Business Add-In definition.

2. Enter a characteristic filter value for the implementation, or choose F4 and select a value from the list of possible entries displayed. In principle, it is possible to define multiple characteristic filter values for each implementation.

3. Use the Class Editor to fill the interface method.

In the string conversion example, you would make the following entries for each country:
BRD:
translate parameter to upper case.
Ireland:
translate parameter to lower case.
Italy:
translate ...

4. Repeat steps 1-3 for each implementation that you create.

5. Activate your implementations.

Now, whenever you execute the report program described above, different country-specific implementations are executed.

You can specify generic filter values for the implementation of a Business Add-In, which means that you can use the special character "*". You can use the asterisk to represent any part of a filter value. A generic filter value can be replaced by different values which may be found in the
database.

You can show and hide short texts for filter values by double-clicking the corresponding column.

As far as extendible filter types are concerned, it is also possible to edit short texts.

Extendible Filter Types

If you flag a filter type as being extendible, it is also possible to create implementations for filter values that did not exist so far. When you assign the extendible attribute to a filter type, the Implementation menu option in the BAdI Builder is replaced by Filter value. If you choose Filter value ® Create and enter a filter value that did not yet exist (you do not need to specify the name of the implementation), the system takes you to the transaction for implementing Business Add- Ins. You can also use transaction SE19, as usual.

The assignment of the extendible attribute is subject to the following restrictions:

The domain to which the extendible filter type refers must have the following properties:

1· The domain is linked to a cross-client value table. This value table has exactly one key field which has the data element of the filter type as its field type.

2· The domain has a text table with two key fields. A key field has the filter type as its field type, and a key field is a language field. To mark a field as a text field, a field must exist in this table that contains the string 'TEXT' or 'TXT as a partial string. In the Dictionary, the text table must be assigned to the value table.

3· The delivery class of both tables must be "E" or "S".

All filter values that are created in the context of an extendible filter-dependent Business Add-In must not yet occur in the value table and are added to the value table when the data is saved.

Analogously, the values are removed from the value table when the implementation or the entire Business Add-In is deleted. The same applies to the text table.

Special Characteristics of Country-Specific Business Add-Ins

The standard system contains a Business Add-In which provides an interface for integrating additional postal checks of the address data through external tools. This Business Add-In is called Address-Check.

This example uses the data element INTCA (ISO code of the country). Since SAP recommends complying with the international ISO standard for country-specific queries, you should use the data element INTCA also for Business Add-Ins. The ISO code of a country key would be, for example, US instead of USA, or DE instead of BRD.

Before the Business Add-In is called from within the application program, you must determine the ISO code of the country by submitting a SELECT statement against table T005 (field INTCA).

Then you can pass the filter value as exporting parameter.
15.5

SAP ABAP BADI MENU ENHANCEMENTS

SAP allows you to enhance menus in its user interfaces using function codes. These function codes must adhere to the form /namespace/+<...>, just like in SMOD/CMOD enhancements.

They are assigned to a specific enhancement and only appear in their corresponding menus once an implementation of this enhancement has been activated.

Application developers reserve specific function codes for customers when defining a Business Add-In. They use the Menu Painter to include these codes in the appropriate menu lists.

Application developers must also ensure that these menu options are called in their applications and that the corresponding add-in methods are also retrieved. Customers can take advantage of menu enhancements by creating a new implementation, choosing a text for the menu option, and
then programming the method used to determine what action is performed when the menu enhancement is called.

Menu enhancement is only possible using single use add-ins (not multiple use add-ins) that are not filter-dependent. Currently, menu enhancements can only be created in conjunction with program enhancements (interfaces).

To create a menu enhancement, proceed as follows:

1 . Create an add-in and define its interface.
2 . Choose Fcodes from the tabstrip.
3 . Enter the name of your program, the function code, and a description.

4 . Call the Menu Painter or double-click on your program name or function code to branch to user interface maintenance in the Menu Painter. Enter your function code in the appropriate menu list. If you have accessed the Menu Painter directly during add-in definition, you can call your menu lists by choosing Goto ® Object lists ® Menu list instead.

Calling a Menu Enhancement from an Application Program

You programming should look like this:

(…)
case fcode.
when 'SAP'.
(…)
when '+CUS'
call method …

Implementing a Menu Enhancement

When implementing menu enhancements, proceed as follows:

1. Create an implementation and choose Fcodes. All data adopted from your Business Add-In's definition is displayed here. You can make entries for the implementation on the right.

You can also double-click on the first input field. The following dialog box appears:

Here you may enter a text for your function code, the name of an icon and a text for the icon, and a short informational text.

The actions that you want the system to perform after the pushbutton is chosen must be programmed in the appropriate method, either manually or using default source code that has been provided to you.

Menu enhancements only become visible after the implementation has been activated and the application program that calls the Business Add-In has been executed.

Besides program and menu enhancements, you can also create screen enhancements for business Add-Ins. Screen enhancements are not supported, however, for Business Add-Ins designed for multiple use.

With the old enhancement technique based on customer exits, X function groups were used for data retention and data processing purposes. These tasks are now performed by a user function group or a module pool if you implement a screen enhancement using BAdIs. The instance of the implementing class is only used for data transport.

The name of the function group lies in the namespace of the implementing person/user. The 'X' which was necessary at the beginning of a function group in case of customer exits is now no longer required and therefore eliminated.

An instance of the BAdI class must be passed to the user of the BAdI to allow that user to get the data to be displayed on the screen. For this purpose, the instance is saved in a public static readomly attribute DYNPRO_INSTANCE of the BAdI class. This attribute is generated.

A public static method SET_INSTANCE_FOR_SUBSCREEN sets the attribute on the application side to the parameter passed. Using the method GET_INSTANCE_FOR_SUBSCREEN the parameter is then read on the user side.

Different sub screen states can be represented by different instances.

The relationships shown between the calling program, the classes and the user function group or module pool are illustrated below by means of an example.

Example:

A user wants to display flight data in a transaction and enters the airline carrier, the flight number, and the flight date first.

At the specific request of the customer, you are to enhance this function to allow the user to additionally display the time of departure and arrival as well as the departure and destination airport.

The definition of a Business Add-In containing the functionality required is then delivered to the customer. If the customer creates an implementation, the system displays additional fields.

BADI SCREEN ENHANCEMENTS IMPLEMENTATION

The present post is in continuation with BADI SCREEN ENHANCEMENTS DEFINATION. Going through that post will give you more convenience and comfort in following this topic.

Here is the way of implementing SCREEN ENHANCEMENTS using BADI.

The user of the screen enhancement should perform the following steps:

1. Create a screen of the Subscreen type. Arrange the required fields on the screen.

2. Write the program for the screen by creating either a module pool or a function group. The program could have the following contents,

for example:

Top Include:

DATA: exit TYPE REF TO if_ex_badi_screen,

flight TYPE sflight.

TABLES sflview.

PBO:

MODULE status_0100 OUTPUT.

IF exit IS INITIAL.

CALL METHOD cl_exithandler=>get_instance_for_subscreens

CHANGING

instance = exit

EXCEPTIONS

OTHERS = 6.

...

ENDIF.

CALL METHOD exit->get_data_from_screen

IMPORTING

flight = flight

EXCEPTIONS

reserved = 1

OTHERS = 2.

...

SELECT SINGLE * FROM sflview

WHERE carrid = flight-carrid AND

connid = flight-connid AND

fldate = flight-fldate.

..

ENDMODULE.

PAI:

If data has been changed, the method PUT_DATA_TO_SCREEN is called at PAI.

MODULE user_command_0100 INPUT.

CALL METHOD exit->put_data_to_screen

EXPORTING

flight = flight

EXCEPTIONS

reserved = 1

OTHERS = 2.

IF sy-subrc <> 0.
...
ENDMODULE.

3. Choose the Subscreens tab. Enter the name of the called program and of the subscreen.

4. Choose the Interfaces tab.

If required, add any lines necessary to the sample code.

SAP ABAP BUSINESS ADD-INS FILTER DEPENDENT

The basics of this concept are discussed as BADI IMPLEMENTATION CONCEPTS and you can go through this before proceeding for this.

Business Add-Ins may be implemented depending on a specific filter value. If the standard allows for an enhancement for, for example, country-specific versions, it is likely that various partners will want to implement this enhancement Distinct implementations can then be created and activated according to country.

Enter a filter type when defining your enhancement (a country or industry sector, for example). All methods created in the enhancement's interface have filter value 'FLT_VAL' as their import parameter. The application program provides the filter value to the enhancement method. The method then selects the active implementation for that value.

A description follows of how a filter-dependent Business Add-In works in the context of the string conversion example. In the following example, different implementations will be called using different filter values.

To define a filter-dependent Business Add-In, first create a normal Business Add-In and select the Filter checkbox.

Enter the data element you want as a filter type or select a filter type using the possible entries help. A filter type can be a data element or a structure. A data element must fulfill the following criteria:

1 · The data element's domain may contain a maximum of 30 characters and must be of type Character.

2 · The data element must 1). either have a search help with a search help parameter of the same type as the data element and this parameter must serve as both the import and export parameter or 2). the element's domain must have fixed domain values or a value table containing a column with the same type as the data element.

If need be, you can create such data elements yourself.

If you want to call the implementation of a Business Add-In depending not only on one filter value but on various values, you can enter the name of a structure into the Filter type field. The
structure can consist of several data elements that fulfull the above conditions for data elements.

Now create an interface with a method. Be aware that for each method you create in the interface of a filter-dependent enhancement, the appropriate filter value must be defined as the import 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.

SAP ABAP BUSINESS ADD-INS FILTER DEPENDENT PART TWO

This post is in continuation with SAP ABAP BUSINESS ADD INS WITH FILTER DEPENDENT

and it is highly advisable to go through it first.

The filter value is declared using parameter flt_val and is preset in the list of parameters.

Calling a Filter-Dependent Business Add-In from an Application Program

The filter value is passed to the method as export parameter.

Report businessaddin.

class cl_exithandler definition load.

data flt type usa_land.

data exit type ref to if_ex_businessaddin.

data word(15) type c value 'Business Add-in'.

start-of-selection.

perform formatlist.

call method cl_exithandler=>get_instance

changing instance = exit.

write:/'Please click here'.

at line-selection.

new-page.

write:/ 'Original word: ',word.

call method exit->method

exporting

flt_val = flt.

Changing

parameter = word.

write:/ 'Changed word: ',word.

The subroutine formatlist looks like this:

form formatlist.

write:/'USA -> Conversion to upper case'.

flt = 'USA'.

hide flt.

write :/'Ireland -> Conversion to lower case'.

flt = 'Ireland'

hide flt.

write :/'Italy -> Conversion to...'

flt = 'Italy'.

hide flt.

endform.

SAP ABAP BUSINESS ADD-INS IMPLEMENTATION

This concept is in continuation with SAP ABAP BADI FILTER DEPENDENT PART TWO
and it may be more convenient if you to go through it before proceeding to this concept.

COMPARISION OF ENHANCEMENT TECHNIQUES IN SAP(ABAP)

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.

BADI 1

A class is an abstract description of an object. Each object only exists while the program is running. In this unit, when we talk about objects, we may actually mean the abstract description (the class), depending on the context.

An object is described by its class and consists of two layers - an inner and an outer layer.
Public components: The public components are those components of the class (for example, attributes and methods) that are visible externally. All users of the class can use the public components directly. The public components of an object form its interface.

Private components: These components are only visible within an object. Like the public components, the private components can be attributes and methods.

The aim of object orientation is to ensure that a class can guarantee its own consistency. Consequently, the data of an object is normally "internal", that is, represented using private attributes. The internal (private) attributes of a class can only be changed by methods of the class. As a rule, the public components of a class are methods. The methods work with the data in the class and ensure that it is always consistent.

Objects also have an identity to differentiate it from other objects with the same attributes and methods.

Until Release 4.0, the nearest thing to objects were function groups and function modules.

When you call a function module, an instance of its function group - with all of its data definitions - is loaded into the memory area of the internal session. An instance is a real software object. An ABAP program can therefore load instances of different function groups by calling function modules, but only one instance of each function group can exist at a time.

The principle difference between real object orientation and function modules is that a program can work with instances of different function groups, but not with several instances of a single function group. For example, suppose a program wanted to manage several independent counters, or several orders at the same time. If we did this using a function group, we would have to program an instance management to differentiate between the instances (using numbers, for example).

In practice, it is very cumbersome to implement instance management within a function group. Consequently, the data is usually in the calling program, and the function modules work with this data. This causes various problems. For example, all of the users have to work with the same data structures as the function group. If you want to change the internal data structure of a function group, you will affect a lot of users, and the implications of the changes are often hard to predict.

Another problem is that all users have copies of the data, and it is difficult to keep them consistent when changes are made.

Working with global data in function groups is dangerous, because it is almost impossible in a complex transaction to control when each function group is loaded.

These problems have been solved with the introduction of classes. Data and functions are defined in classes instead of function groups. An ABAP program can then work with any number of runtime instances that are based on the same template. Instead of loading a single runtime instance of a function group implicitly when you call a function module, ABAP programs can create runtime instances of classes explicitly. The individual runtime instances are uniquely identifiable objects, and are addressed using object references.

Interfaces are defined independently of classes.

They can contain declarations for elements such as attributes and methods.

Interfaces are implemented by classes

The classes then have a uniform external point of contact. They must provide all of the functions of the interface by implementing its methods.

In a program, you can create reference variables with reference to interfaces. However, you cannot instantiate an interface.

Interface references can, however, point to objects of different classes.

Business add-ins, unlike customer exits, take into account the changes to the software delivery process. The top part of the graphic illustrates the typical delivery process: It no longer merely consists of software provider and end user. Instead, it can now contain a whole chain of intermediate software providers like SAP Industry Solutions (IS) and partners.

Below this is a diagram explaining how business add-ins work. Enhancements are made possible by SAP application programs. This requires at least one interface and an adapter class that implements it. The interface is implemented by the user.

The main advantage of this concept is the capacity for reuse. Once implemented, a business add-in can be reimplemented by other links in the software chain (as shown on the right in the graphic).

Furthermore, an implementation can also offer business add-ins of its own.

A business add-in contains the components of an enhancement. Currently, each business add-in can contain the following components:

Program enhancements
Menu enhancements
In future releases, the other components included in customer exits will also be available as add-in components.

Several components are created when you define a business add-in:
Interface
Generated class (add-in adapter)
The generated class performs the following tasks:
Filtering: If you implement a filter-dependent business add-in, the adapter class ensures that only the relevant implementations are called

Control: The adapter class calls the active implementations.

This graphic shows the process flow of a program that contains a business add-in call. It enables us to see the possibilities and limitations inherent in business add-ins.

Not displayed: You must declare a reference variable in the declaration part.
In the first step, an existing service class, CL_EXITHANDLER, creates an object reference. We will discuss the precise syntax later on. This completes the preparations for using the program enhancement.

When you define a business add-in, the system generates an adapter class, which implements the interface. In call (2), the interface method of the adapter class is called. The adapter class searches for all of the implementations of the Business Add-In and calls the implemented methods.

First, you must define a reference variable with reference to the business add-in interface. The name of the reference variable does not necessarily have to contain the name of the business add-in.

In the first step (1), an object reference is created. This creates an instance of the generated adapter class, restricted to the methods of the interfaces ("narrowing cast").

You can use this object reference to call the required methods (2).

There are various ways of searching for business add-ins:
You can search in a relevant application program for the string "CL_EXITHANDLER". If a business add-in is called from the program, the "GET_INSTANCE" method of this class must be called.

You can then reach the definition of the business add-in using forward navigation. The definition also contains documentation and a guide for implementing the Business Add-In.

You can also use search tools: Since SAP provided fewer than 50 Business Add-Ins in Release 4.6A, even a list of them all is still manageable.

However, you can also use the application hierarchy to restrict the components in which you want to search. Start the Repository Information System, then choose Environment -> EXIT techniques -> Business Add-Ins" to start the relevant search program.

To implement business add-ins, use transaction SE19 (Tools -> ABAP Workbench -> Utilities -> Business Add-Ins ->Implementation).

Enter a name for the implementation and choose Create. A dialog box appears. Enter the name of the business add-in. The maintenance screen for the business add-in then appears.

Alternatively, you can use the Business Add-In definition transaction to reach its implementations. The menu contains an entry "Implementation", which you can use to get an overview of the existing implementations. You can also create new implementations from here.

You can assign any name to the implementing class. However, it is a good idea to observe the proposed naming convention. The suggested name is constructed as follows:
Namespace prefix, Y, or Z
CL_ (for class)
IM_ (for implementation)
Name of the implementation
To implement the method, double-click its name. The system starts the Class Builder editor.

When you have finished, you must activate your objects.

In the implementing class, you can create your own methods that you then call from the interface method.

You cannot create them using forward navigation. Instead, you must define a regular method in the Class Builder (along with its interface). Specify a visibility for the method, and implement it.

Use the "Activate" icon to activate the implementation of a Business Add-In. From now on, the methods of the implementation will be executed when the relevant calling program is executed.

If you deactivate the implementation, the methods will no longer be called. However, the corresponding calls in the application program are still processed. The difference is that the instance of the adapter class will no longer find any active implementations. Unlike the "CALL CUSTOMER-FUNCTION" call, the "CALL METHOD CL_EXITHANDLER=>GET_INSTANCE" call is still executed even if there are no implementations. The same applies to the statement calling the method of the adapter class.

You can only activate or deactivate an implementation in its original system. Changing it anywhere else constitutes a modification. The activation or deactivation must be transported into subsequent systems.

If a business add-in can only have one implementation, there can still be more than one implementation in the same system. However, only one can be active at any time.

As with customer exits, you can use menu enhancements with Business Add-Ins. However, the following conditions must be met:

The developer of the program you want to enhance must have planned for the enhancement.
The menu enhancement must be implemented in a BAdI implementation.

Function codes of menu enhancements begin with a plus sign '+'.
The menu entry will only appear if there is an active business add-in implementation containing the corresponding enhancement.

You can only create function codes for business add-ins that can only be used once. Moreover, the business add-in cannot be filter-dependent.
These restrictions are necessary to ensure that there are no conflicts between two or more implementations.

If the user chooses the menu entry in the program to which the function code "+" is assigned, the system processes the relevant method call.

The method call and the menu enhancement belong inseparably to one another. Having the former without the latter would make no sense. For this reason, it is important that the two enhancement components are combined in a single enhancement - the business add-in.

To create a BAdI, use the BAdI Builder (Tools -> ABAP Workbench -> Utilities -> Business Add-Ins -> Definition).

BADI 3

A business add-in has two important attributes that you must define:

Reusable
Filter-dependent
If you want the business add-in to support multiple parallel implementations, select Reusable. The sequence in which the implementations will be processed is not defined. Even if the business add-in does not support multiple use, you can still have more than one implementation for it. However, only one implementation can be active at a time.

If you make a business add-in filter-dependent, you can make calls to it depending on certain conditions. You must specify the filter type in the form of a data element. The value table of the domain used by the data element contains the valid values for the implementation.

When the enhancement method is called, a filter value must be passed to the interface.

You can include function codes in a Business Add-In definition (similarly to menu exits in customer exits). To do this, enter the program name and function code, and a short description in the relevant fields.

Restrictions:

It is not currently possible to create BAdIs that consits only of menu enhancements (function codes).

If you use menu enhancements, you cannot reuse a BAdI or make it filter-dependent.

The system proposes a name for the interface and the generated class. You can, in principle, change the name of the interface to anything you like. However, your BAdI will be easier to understand if you retain the proposed name.

The name of the generated class is composed as follows:
Namespace prefix
CL_ (to signify a class in general)
EX_ (stands for "exit")
Name of Business Add-In

If you double-click on the interface name, the system switches to the Class Builder, where you can define the interface methods.
A BAdI interface can have several interface methods.

You can use all of the normal functions of the Class Builder. For example, you can:
Define interface methods
Define interface parameters for the methods
Declare the attributes of the interface
If the business add-in is filter-dependent, you must define an import parameter flt_val for each method. Otherwise, you define the interface parameters you need for the enhancement.

Once you have finished working on your interface, you must activate it. This generates the adapter class for the Business Add-In.

If you change the interface, the adapter class is automatically regenerated.
You can also generate the adapter class explicitly at any time by choosing Utilities -> Regenerate from the initial screen of the Business Add-In maintenance transaction.

To call a business add-in method in an application program, you must include three statements in the program:
Declare a reference variable (1) with reference to the business add-in interface (in our example, "exit_ref").
Call the static method GET_INSTANCE of the service class CL_EXITHANDLER (2). This returns an instance of the required object. This involves an implicit narrow cast, so that only the interface methods of the object with the reference variable "exit_ref" can be addressed.
You can now call all of the methods of the business add-in. Make sure you specify the method interfaces correctly.

If your Business Add-In is filter-specific, you must pass an appropriate value to the parameter flt_val.

Business add-ins are a natural extension of the conventional enhancement technique. They have taken over the administration layer from customer exits, along with the availability of the various enhancement components.
They adopted the idea of reusability from Business Transaction Events, and have been implemented using a consistent object-oriented approach.
The object-oriented implementation provides previously unavailable opportunities. For example, it would be possible to enhance the object "Document". It would be possible to provide a new instance of the enhancement for each individual document.

The components in parentheses in the graphic have not yet been implemented:
Screen enhancements
Table enhancements

These enhancement components are planned for later releases. There will then also be a migration tool for converting previous enhancements into the new form.

Basic concept

SAP has introduced new enhancement technique Business Add-ins from release 4.6A.
Business Add-in is the new enhancement technique based on ABAP Objects. BADI is an exit point in a source that allows specific industry sectors, partners, and customers to attach additional software to standard SAP source code with out modifying the original object.
The users of Business Add-ins can customize the logic according to requirement or they can use the standard logic one available.
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.

Basic skills required

· Work Experience/Knowledge on ABAP Objects (Object orientation of ABAP) is mandatory.

· Experience on SAP enhancement technique.

BADI in detail

Business Add-ins infrastructure is multi-level system landscape (SAP, partner, customer solutions, as well as country versions, and industry solutions). Definitions and implementations of Business Add-ins at each level within system infrastructure.

Different Views

a) The different views of the BADI’s are:

i. Definition view, Application Programmer can predefine the exit points in the source in which specific industry sector customers can attach additional software to standard SAP source code with out having to modify the original object.

ii. Implementation view, the users of Business Add-ins can customize the logic they need or use a standard logic if available.

Architecture

a) User defined BADI’s:

i. First define a Business Add-In, application developer creates an interface for the add-in.

ii. Enhancement management creates an adapter class that implements the interface and thus provides the interface for implementation by the customer, partner and so on.

iii. The programmer/developer creates an instance of the adapter class in the application program and calls the corresponding method at the appropriate time.

b) Standard BADI’s:

i. For Standard Business Add-ins, the interface and adapter class will be predefined by SAP. The adapter class that implements the interface and provides the interface for implementation by the customer, partner specific to business.

d) Each Business Add-in will have one interface and an adapter class that implements interface. Depending on the business requirement user will implement the interface. The generated class (Adapter class) has the following tasks.

i. Control, the adapter class calls the active implementations.

Filtering, If the Add-in has to be executed under certain conditions, then the adapter class ensures that only certain implementations will be executed.

Technical Details

1. BAdIs are contained in the system and are fully operational as of Release 4.6B. SAP creates Add-ins for specific programs, menus, and screen enhancements for standard R/3 applications. This Add-ins doesn’t contain any functionality. Instead you can add-on functionality onto these hooks.

2. Customers can find the enhancements in their system in the implementation guide and in the component hierarchy. If customer wishes to use a Business Add-in, he has to first create 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.

3. Business Add-in contains an interface and other additional components such as function codes for menu enhancements. Business Add-ins also includes 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.

Defining a Business Add-in

SAP provides the Badi’s where are applicable in the standard applications. Application programmer who ever wishes to have a Business Add-ins in a particular program can define the interface for an enhancement in the Business Add-in builder. Programmer has to program the interface call in the program at the appropriate place. Customers can select the add-in and implement it accordingly to their business needs.

1. From SAP menu, choose Tools -> ABAP Workbench -> Utilities -> Business Add-ins or transaction code SE18. The example, which is illustrated, is the string conversion in the program. And giving the provision to the users to determine themselves how their strings are to be converted. Application developer define an enhancement, consists of interface with a method with changing parameter used to pass the string.

2. Enter the Badi name and choose create.

DEFINITION:

And the next screen shot is here.

1. Save and activate the interface and navigate back to the Business Add-in definition. Now in the Badi screen, displays the method you have created for the interface. When you maintain the interface methods, corresponding executing class (Adapter class) is generated.

2. Save your entries and document the description of the Business Add-in. Documentation is important for the users to understand the purpose of the Add-in.

Implementation of Badi

1. The list of Business Add-ins available in the system can be found through SAP Reference Implementation guide (IMG) or in component hierarchy. Badi’s definition is included in IMG so that the customer/partner can create suitable, company-specific implementations.

2. In the SAP menu, choose ABAP Workbench -> Utilities -> Business Add-ins or transaction code SE19.

3. Enter the implementation name and click on the create button.

1. Double click on the implementation class and insert the desired source code for the implementation between the method ZIF_EX_BUSINESSADDIN~CONVERSION. And Method. In this particular example enter the statement translate parameter to upper case. Save and activate your entries and return to the change implemention screen.

2. Choose Activate, now you can use this implementation when the application program is executed. Several implementations may exist for a Business Add-in but that is not used in multiple use basis. However only one implementation can be activate at any one time. But in case of multiple use of the BAdi, we can have multiple implementations activate. The instance generation of the implementing class must set the attribute as public and not as private, protected or abstract. System will give dump if you do so.

1. Following is the code for the class ZCL_CONVERSION_BADI_IMPL method CONVERSION

Method ZIF_EX_BUSINESSADDIN~CONVERSION.

translate parameter to upper case.

endmethod.

This is how we define and implement business add in sap abap.

1. When we define BAdi, enhancement management generates a class that implements the interface. The application developer uses a factory method to create an instance of adapter class in the application program and calls corresponding method. The adapter class method generated by the enhancement management decide by checking the entries in the table whether one or several active implementations need to be called. If required, the implementations are subsequently executed. The application program ensures only the adapter class method is called. The application program doesn’t know which implementations are called.

2. Call the string conversion Business Add-in, the program calling the Business Add-in. Following is the ABAP source code

REPORT ZMPTEST_BADI.

* Declaring the handler

class: cl_exithandler definition load.

* Interface Reference

data: badi_interface type ref to ZIF_EX_BUSINESSADDIN.

* String

data: w_str(15) type c value 'baddi test'.

*************************************************

****Start of Selection Event.....................

************************************************

start-of-selection.

call method cl_exithandler=>get_instance

changing

instance = badi_interface.

write: / 'Please click here'.

*************************************************

****At line-selection Event.....................

************************************************

at line-selection.

write: / 'original word', w_str.

if not badi_interface is initial.

call method badi_interface->conversion

changing parameter = w_str.

endif.

write: / 'Converted word', w_str.

Filter dependent Badi

1. Business Add-in definition level (for example a country, industry sector) we can have filter dependent option. If an enhancement for country specific versions then it is likely that different partners can implement this enhancement. The individual countries can create and activate their own implementation.

2. In the enhancement definition, all the methods created in the enhancement’s interface need to have filter value as their importing parameter. The application program provides the filter values for the implementation method.

3. Filter dependent BAdi is called using one filter value only, it is possible to check active implementation for the filter value using the function module SXC_EXIT_CHECK_ACTIVE.

Multiple use Badi

1. There are multiple use and single use Business Add-ins. This option can be choose at Business Add-in definition.

2. The distinction is base on the procedure or event character of an enhancement. In the first case the program waits for the enhancement to return a return code. Typical example is benefit calculation in HR depending on the implementation, alternative calculations can be executed. In case of multiple use add-ins, an event that may be interest to other components in program flow. Any number of components could use this event as a hook to hang their own additional actions on to.

3. There is no sequence control for multiple-use implementations of BAdi’s. Sequence control is technically impossible, at the time of the definition the interface does not know which implementations parameters will be change the implementations.

4. The concept of multiple use of the Business Add-in is that has been implemented once already can be implemented again by right of the software chain.

Difference between different enhancement technique with BADI

1. Difference between Business Transaction Events and BADI’s.

i. The concept of the BADI is similar to Business Transaction Events (Open FI). BTE’s was developed specific to Financial Accounting module. But were as BADI’s was developed in generalised to all modules.

ii. BTE’s can only be used to make the program enhancements. You cannot enhance user interface with Open FI, but you can with Business Add-ins.

iii. Open FI assumes that enhancement can only take place on three levels i.e. SAP- partners – customers, but in case of BAdi’s you can create and implement enhancements in as many software layers as you like.

iv. Function modules are used for program enhancements in Open FI. With BAdi’s, ABAP Objects is used to enhance programs.

2. Difference between customer exits and BAdi’s.

i. Customer exits assume a two-tiered system infrastructure (SAP - Customers). Where as in case of BAdi’s you can created and implement enhancements in as many software layers as you like.

ii. BAdi’s are considered as generalized BTE’s that can be used to bundle program, menu and screen enhancements into a single add-in. BAdi’s can be created and employed in each of the various software levels.

Advantages of BADI’s

1. This enhancement technique has the advantage of being based on a multi-level system landscape (SAP, country versions, IS solutions, partner, customer and so on).

2. We can create definitions and implementations of business add-ins at any level of the system landscape.TRE

1. Following are the Tables which are relevant to BAdi’s

SOME IMPORTENT BADI'S

i. SXS_ATTRT - BAdi Definition list

ii. V_EXT_ACT - Active implementations of an exit

iii. V_EXT_ IMP - Implementation class for an interface+filter

iv. V_EXT_M - BAdi’s with filters

2. Transaction related to BAdi’s

i. SE18 - Business Add-in builder

ii. SE19 – Implementation of Badi

iii. SE24 – Class/Interface Builder

Friday, 13 January 2012