BUSINESS TRANSACTION EVENTS

BUSINESS TRANSACTION EVENTS


Compared with earlier releases, the software delivery process now looks quite different. Previously, only two parties were involved in the delivery: SAP produced the software, and delivered it to its end-customers. Customers could enhance this standard using customer exits.


However, now that the software is more component-oriented, more parties have become involved in the process: SAP provides the R/3 standard to each SAP Industry Solution, which uses it as a basis to add on its own encapsulated functions. The next link in the chain might be a partner firm, which builds its own Complementary Software Program (CSP) solution based on R/3. The last link in the chain is the customer, as before.

All of the parties involved in this process are potential users and providers of enhancements. This requirement cannot be satisfied by customer exits, which can only be used once. Consequently, SAP developed a new enhancement technique in Release 4.0, which allows enhancements to be reused.

Business Transaction Events (BTE) allow you to attach additional components, in the form of a function module, for example, to the R/3 system.

Business Transaction Events use one of the following types of interfaces:
Publish & Subscribe interfaces
These interfaces inform external software that certain events have taken place in an SAP standard application and provide them with the data produced. The external software cannot return any data to the R/3 System.

Process interfaces

These interfaces are used to control a business process differently than the way in which it is handled in the standard R/3 System. They intervene in the standard process, and return data to the SAP application.

You can attach various external developments to the R/3 System. You can create additional developments using the ABAP Workbench.

The example above pertains to Publish & Subscribe interfaces. In this case, data only flows in one direction - from the SAP application to the additional component.

SAP application developers make interfaces available to you at certain callup points in a transaction.

You can deposit additional logic at these points.

In a very basic scenario, SAP partners and customers can use the interfaces themselves. In this case business transaction events function in much the same manner as customer exits (see the unit on "Enhancements using Customer Exits").

The above scenario also pertains solely to Publish & Subscribe interfaces.

In contrast to customer exits, business transaction events allow you to use an interface for multiple types of additional logic.

If this is the case, you must decide which bit of logic you want to execute at what time.

Both of your enhancements exist side by side with out impeding each other; however, at runtime only one of the enhancements can be processed.

Publish & Subscribe interfaces:

Allow you to start one or more (multiple) additional operations when a particular event is triggered. They do not influence the standard R/3 program in any way.

Multiple operations do not interfere with each other.

Add-on components can only import data.

Possible uses: Additional checks (authorizations, existing duplicates, and so on)

Process interfaces:

In contrast to Publish & Subscribe interfaces, data exchange takes place in both directions with process interfaces. This influences the number of additions that can be attached to the interface.

When an event is triggered, a process in the standard program can only be replaced by a single external process using the process interface.

If you are using an add on from an SAP partner that uses a process interface, this enhancement is processed at runtime. If you choose to use this same process interface for one of your own developments, the partner enhancement is dismissed and your own enhancement is processed at runtime instead.

The graphic shows the flow of an SAP program. The program contains an enhancement in the form of a Business Transaction Event. The program calls a service function module, which determines and processes the active implementation of the enhancement. The naming convention for these function modules is OPEN_FI_PERFORM__E (or OPEN_FI_PERFORM__P).

This function module determines the active implementations for each enhancement and stores them in an internal table. The implementing function modules are processed in the sequence defined by the internal table. At this point the system also considers the conditions under which the function module will be processed in the customer namespace - for example, the country or application. These conditions are also shown as filter values.

This graphic shows the syntax used to call a program enhancement using a business transaction event.

In the SAP application program, a function module is called with the name
"OPEN_FI_PERFORM__E" (or, for process interfaces, "OPEN_FI_PERFORM__P").
The application program passes data to the service function module using the interface. SAP developers have already designed the interface.

The service function module searches for active implementations and places them in an internal table. They are then processed in a loop.

Business transaction events allow you to implement additional logic in a task function, similar to function module exits. SAP application programmers determine where to place business transaction events in a task function and what data should be transferred at each point. They also create sample function modules complete with short texts, an interface, and documentation, and describe the functions possible with the enhancement in the accompanying SAP documentation.

First, SAP application programmers assign a business transaction event an eight digit number by which it can be identified. These numbers should observe a particular convention. For example, the fifth and sixth digits should be identical with events in the same program.

The SAP developer registers the event and creates a template function module,
sample_interface_ , which establishes the interface for the user.

To find out directly whether an application transaction offers business transaction events, you can use the procedure described on the left-hand side of the graphic. In the program source text, search for the character string "OPEN_FI_PERFORM". The number that completes the name of the function module is also the name of the event.

In the SAP Customizing Implementation Guide (IMG), you will find the entry "Use business transaction events " under the "Financial Accounting Global Settings" node of the Financial Accounting area. Choosing this entry calls a transaction (FIBF) where you can execute all of the actions necessary for using Business Transaction Events.

Under Environment, you will find search functions that you can use to identify appropriate business transaction events. You can view the documentation for the event from the list.

The "Environment "menu of the service transaction FIBF contains two programs that you can use to search for BTEs. You can restrict the search by using various parameters.

The BTEs that the system finds are displayed in a list. You can then:

Display the model function module (start the Function Builder and copy it, for example)

Display the interface

Display the documentation

The documentation provides a clear explanation of how to use the enhancment and any restrictions that apply to it.

Use service transaction FIBF to create a product. A product groups together a collection of enhancements.

You can create products for various layers in the delivery chain. They define a sequence for processing the implementations of a business transaction event.

You can only switch each product on or off as a whole entity. This allows the user to control which enhancements should be processed and which should not. It also ensures the integrity of the whole enhancement.

You can use the transaction FIBF (called when you selected "Use business transaction events" from the financial accounting hierarchy) to carry out all necessary activities prior to using a business transaction event.

First, you must choose an interface to attach your function module to. The Interface button displays the parameter structure for the interface you have selected. You can also use the documentation to determine what functions each interface allows you to perform.

Use the ABAP Workbench to copy the sample function module sample_interface_ to the customer namespace (z_*) of a customer function group. You must not change the interface. You can fill the module with any source text except COMMIT WORK. Don't forget to activate the function module.

Create a product in transaction FIBF.

Assign a number to your function module and product.
In contrast to customer exits, business transaction events are client-specific. This means that the same event can be used in different clients for different purposes.
Business transaction events may also be used more than once.

With Publish & Subscribe interfaces, you can choose which enhancement you want to use.

With process interfaces, the system executes a single component in the hierarchical sequence SAP application, add on, customer.

BUSINESS ADD INS

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 is 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, takes 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 reimplementation 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.



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.

This graphic contains the syntax with which you call a business add-in. The numbered circles correspond to the calls from the previous page.

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.

Alternatively, you can use the relevant entries in the IMG.

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).

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 uses, 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 consist 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 is 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.

BADI I

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).

BADI II

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 III

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.

BADI Introduction

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.

BADI Defination and Implementaion

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.

Calling a BADI and uses

Calling Badi in the Application

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.

1. 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.

2. 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.

3. 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.

4. 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.

1. 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.

2. 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

1. SXS_ATTRT - BAdi Definition list

2. V_EXT_ACT - Active implementations of an exit

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

4. V_EXT_M - BAdi’s with filters

2. Transaction related to BAdi’s

1. SE18 - Business Add-in builder

2. SE19 – Implementation of Badi

3. SE24 – Class/Interface Builder

SAP ABAP 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.

SAP ABAP Comparison of 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 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 IMPLEMENTATION

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.

ABAP BADI IMPLEMENTATION part two

Here we are going to learn BADI implementation using Formula Bar.

You can use the Formula Builder to implement methods for Business Add-Ins without writing a single line of ABAP code. The methods are implemented by means of so called formulas.

This type of implementation does not require you to have programming knowledge. However, the functions it offers are more restricted than if you implement a method by writing ABAP code. If the
range of functions provided by the Formula Builder is not sufficient, you can change the implementation type of the method at any time.

A formula can consist of the following steps:

1 · Condition

You define a Boolean formula expression whose result can be true or false. This formula expression is a logical condition based on the importing and changing parameters of the method. Depending on whether the condition is true or false, the system triggers different steps. If you do not specify a dependent step for one of these two possibilities, the system continues with the next superior step.

2 · Substitution

The system replaces the value of a specific parameter with another value which you define as a constant value or by means of a ma thematic formula. Substitution is only possible if the method contains changing, exporting or returning parameters.

3 · Message

The system issues a message. All messages issued are collected in a log table. You define the message variables as constant values or by means of ma thematic formulas. The system can only issue a message if you created a log table during method definition.

4 · Exception

The system exits the method. No further steps are executed, and the application program continues in accordance with the exception defined. You can additionally display a message whose variables you define as constant values or by means of ma thematic formulas. An exception can only be triggered if the method contains exceptions.

A formula editor is available which you can use to enter formula expressions. After starting the formula editor, you can display information on how to use it by choosing the pushbutton next to the status display (traffic light).

Activities:

To implement a method as a formula, choose the Formula implementation type on the Interface tab.

Double-clicking the method name takes to to the Formula Builder: BadI Implementation screen.

You can change the implementation type of the method on the Interface tab. You can implement a method both using a formula and using ABAP code. At the runtime of the application program, the system executes the implementation type currently chosen.

You create the necessary steps in the left section of the screen. To do this, choose (Create) and then select the appropriate step type from the dropdown list. Using the other icons available or the context menu (which you can call by clicking the right mouse button), you then determine the arrangement and the descriptions of the steps. You can also copy steps to use them as templates for other steps, or you can delete individual steps.

To specify the parameters for the individual steps, double-click the corresponding entry in the left section of the screen. You then enter the data required in the right section of the screen.

Formulas are transported automatically.