Sunday, October 7, 2007

Multiple-Use Business Add-Ins

You can differentiate between single-use and multiple use Business Add-Ins. The distinction is based on the procedure or event character of an enhancement. In the first case, the program waits for the enhancement to return something, usually a return code. A typical example could be a benefit calculation in HR. Depending on the implementation, alternative calculations can be executed. With multiple use add-ins, an event that may be of interest to other components is processed in program flow. Any number of components could use this event as a “hook” to hang their own additional actions on to.
Note :
In addition to importing parameters, you can also use changing parameters for multiple-use Business Add-Ins. There is no sequence control for multiple-use implementations of BadIs. Therefore, using changing parameters can cause problems. There is no guarantee that implementations will not overwrite the results of previous implementations. Sequence control is technically impossible, since at the time of the definition the interface does not know which implementations there will be and which parameters will be changed by implementations. It is not possible to have a decision as to which implementation should be executed before which other (future) implementation.
In a particular application, you want to be able to continue processing indexes after another component has saved data (in other words, the system should allow you to use an add-in after saving). Since this point in time can be useful for different purposes, you can create an enhancement here that can be used by multiple subscribers.

To create a multiple-use Business Add-In, proceed as follows:

2. ...
11. 1. Define an add-in and select the Multiple Use checkbox from the Administration tab.
12. 2. Define an interface with the method OBJECT_SAVED'and the importing parameter OBJECTNAME.
Calling your enhancement in the application program:
program event.

data exit_obj type ref to if_ex_event.

call method cl_exithandler =>get_instance
changing instance = exit.

form save_object using obj_name type c.

update …
call method exit_obj->object_saved
exporting objectname = obj_name.
For the caller it is irrelevant whether (and how many) subscribers use the event as a starting point for further actions. The active implementations are called in the adapter method.

No comments: