Entering content frameProcedure documentation Calling Add-Ins from Application Programs Locate the document in its SAP Library structure

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.

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 wort(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         changing instance = exit.               
8   write:/'Please click here'.

9 at line-selection.
10   write:/ 'Original word: ',word.

11   call method exit->methode                    "Add-In call
12         changing parameter = word.

13   write:/ 'Changed 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.

Application developers use factory methods to create instances of adapter classes during initialization in lines 6 and 7. The instance methods are then called at the appropriate time.

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 through as rarely as possible - one time 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.

Note

Within the instance of the adapter class, required database accesses are buffered locally, so that each access is executed only once. 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.

In particular, you are not required to use a function module to verify if active implementations exist at all.

Also, if the definition of the Business-Add-In is filter-dependent, a single instance is sufficient.

However, you should not do without initialization at all. Although it would be possible to call static methods of the implementing class of the Business-Add-In implementation without an instance, you loose the benefit of performance improvement through the Business-Add-Ins and the possibility of repeated use. Also, if you switch the method type in the interface from static to instantiatable at any time in the future, many code adjustments are required. In addition, you can no longer use default code provided.

 

 

 

Leaving content frame