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.