Calling a Business Add-In in the Application Program

When you define a Business Add-In, enhancement management generates a class that implements your interface. The application developer uses a factory method to create an instance of this adapter class in the application program and calls the corresponding method, if necessary.
The adapter class method generated by add-in management decides whether one or several active implementations should be called. If necessary, these implementations are subsequently executed. The application program ensures only that the adapter class method is called. The application program does not know which implementations are called.

Example:

Having created a string conversion Business Add-In, you would program the call of the Business Add-In into your ABAP source code as follows:

1 Report businessaddin.
2 class cl_exithandler definition load. "Declaration
3 data exit type ref to if_ex_businessaddin. "Interface reference
4 data word(15) type c value 'Business Add-in'. "String to change

5 start-of-selection.
6 call method cl_exithandler=>get_instance "Factory method call
7 exporting "Method
exit name =’BUSINESSADDIN’
8 null instance accepted =’X’
9 changing instance = exit.
10 write:/'Please click here'.

11 at line-selection.
12 write:/ 'Original word: ',word.

13 if not exit is initial.
14 call method exit->method "Add-In call
15 changing parameter = word.
16 endif.
17 write:/ 'Original word: ',word.

In order to be able to call static methods, you must declare the corresponding class in ABAP Objects. This is why the class … definition load statement is necessary for the factory class.
A variable for object reference is also necessary when calling the method. Use data to create it and type it to the interface.

During initialization (line 6), the application developer creates an adapter class instance using the factory method. The instance methods are then called at the time specified.

To improve performance during creation of the instances, you should specify additional parameters for the call in the method GET_INSTANCE of the class CL_EXITHANDLER.

EXIT_NAME: The name of the BAdI definition is assigned to this parameter.

NULL_INSTANCE_ACCEPTED: Whenever the value X is assigned to this parameter, no instance is created if there are no active implementations for this BAdI definition. In this case, the INSTANCE parameter has the value NULL. Using this parameter implies that the method calls of this BAdI may only be called under the condition that this instance is not NULL. The query if not is initial. is necessary in this case.

Notes on Usage
The instance generated through the factory method should be declared as globally as possible or generally be passed as a parameter to ensure that the initialization process must be run as rarely as possible – just once would be best. In no case should you discard the instance as soon as it is generated or repeatedly run the initialization process in a loop.

Within the adapter class interface, required database accesses are buffered locally, so that each access is executed once only. However, repeated initialization makes the buffer useless and dramatically reduces performance.

Due to the local buffering, you can call Business-Add-In methods without having to expect considerable performance restrictions, even if no active implementations exist.

Also, if the definition of the Business-Add-In is filter-dependent, a single instance is sufficient.
However, you should not do without initialization altogether. Even if you could call static methods of the implementing class of the Business-Add-In implementation without an instance, you would lose the benefit of performance improvement through the Business-Add-Ins and the possibility of multiple use. If you switch the method type in the interface from the static method to the instance method at any time in the future, many code adjustments are required. In addition, you can no longer use default code that is provided