It is also possible to use another name or to choose an existing enhancement spot.
The properties of the classic BAdI (such as multiple use, texts) and the screen and menu enhancements (such as function code enhancements) are copied one to one.
The tag interface IF_BADI_INTERFACE is included in the BAdI interface of the classic BAdI.
In this case, a message with identifier 6 will appear in the input log of the transport request.
After finishing the (partial) migration, you may to proceed with the optional full migration to profit from all of the advantages of the new BAdIs.
To perform this procedure you need expert knowledge of the application. The effort may vary from several minutes up to several days per BAdI
In most cases you do not need the context, so change the instantiation mode accordingly.
Additional Information
BAdIs can only be migrated in their original systems. The migration of BAdI implementations is triggered in all follow-up systems by the transport of a migrated BAdI.
The call of CL_EXIT_HANDER=>GET_INSTANCE and the subsequent calls of the BAdI methods are not migrated automatically. The present ABAP proxy class of the classic BAdI is kept in order to guarantee this semi-automatic migration, but it is regenerated. After that, it implements the tag interface IF_BADI_CONTEXT for BAdI context objects and uses the new statements GET BADI and CALL BADI in its proxy methods to call the migrated BAdI instead of determining the implementations itself.
Screen enhancements with classic BAdIs are called using the CL_EXITHANDLER=>GET_PROG_AND_DYNP_FOR_SUBSCR method. During the migration, the method and call are kept. In the method, however, after the migration the method CL_ENH_BADI_RUNTIME_FUNCTIONS=>GET_PROG_AND_DYNP_FOR_SUBSCR is called for the new BAdIs.
The method SET_INSTANCE_FOR_SUBSCREEN from the old BAdIs is no longer necessary and GET_INSTANCE_FOR_SUBSCREEN can be replaced by a GET BADI command due to the fact that BAdIs with screen extensions always have reuse as the instantiation mode
Menu enhancements or function code enhancements are evaluated for classic and new BAdIs during the program generation. The generation considers classic and new BAdIs alike.
After the migration, you are not allowed to change the resulting new BAdI as long as the original classic BAdI still exists. If the classic BAdI is not deleted immediately after the migration, but is changed again, then the resulting new BAdI is adapted. This is the reason why BAdIs must be migrated only in their original system.
We recommend that you make all required manual changes (calls) as soon as possible and then delete the classic BAdI.
Influence on Upgrades
BAdI implementations are usually created in follow-up systems of the system in which a BAdI is defined. The migration of a BAdI in its original system triggers the migration of the implementation in all follow-up systems as follows:
BAdI Interface After the Migration
INTERFACE if_ex_badi_migtest PUBLIC.
INTERFACES if_badi_interface.
METHODS m IMPORTING value(flt_val) TYPE flt_migtest CHANGING test TYPE char1.
ENDINTERFACE.
ABAP proxy class after the migration
CLASS cl_ex_badi_migtest DEFINITION PUBLIC FINAL CREATE PUBLIC.
PUBLIC SECTION. INTERFACES: if_ex_badi_migtest, if_badi_context .
ENDCLASS.
CLASS cl_ex_badi_migtest IMPLEMENTATION.
METHOD if_ex_badi_migtest~m.
DATA l_badi TYPE REF TO badi_migtest.
GET BADI l_badi filter f1 = flt_val-f1 f2 = flt_val-f2 CONTEXT me.
CALL BADI l_badi->m EXPORTING flt_val = flt_val. changing test = test.
ENDMETHOD.
ENDCLASS.
This results in the following call hierarchy: