Migrating BAdIs 

Automatic (Partial) Migration

...

...

       1.      Call the classical BAdI Builder (transaction SE18).

       2.      Enter the name of the BAdI you want to migrate.

       3.      Choose Utilities → Migrate Classic BAdI..

       4.      Create an enhancement spot with the same name as the classic BAdI.

It is also possible to use another name or to choose an existing enhancement spot.

       5.      In the enhancement spot, create one new BAdI which has the same name as the classic BAdI.

       6.      The new BAdI should be defined with a context-dependent instance generation mode.

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.

       7.      If you define a filter for the classic BAdI, copy the components of the related filter structure to the new BAdI as separate filters. Use the name of the component is used as a name of the new filter; its type is always c.

       8.      Copy all existing implementations of the classical BAdI to new BAdI implementations. Create the new BAdI methods within the existing BAdI implementation classes.

       9.      Analogous to the migration of the filter definition, the structure of the filter condition of a classic BAdI implementation should also be dissembled into individual filter conditions.

   10.      Transport the change into a follow-up system:

                            a.      Call transaction SPAU if there is a BAdI implementation for the migrated BAdI.

In this case, a message with identifier 6 will appear in the input log of the transport request.

                            b.      Choose the traffic light in front of the BAdI implementation.

                            c.      Enter an enhancement implementation.

Complete Migration

...

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

...

       1.      Delete the classic BAdI. (Answer the question: Shall the migrated BAdI be deleted, too? with No.)

       2.      Change the new BAdI according to your needs.

In most cases you do not need the context, so change the instantiation mode accordingly.

       3.      Find all calls of the classic BAdI by GET_INSTANCE and reprogram the BAdI call using the new commands GET BADI and CALL BADI

       4.      To improve performance, you can change the context settings for BAdIs called more than once in one program.

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:

●      For all related BAdI implementations, an upgrade flag is set.

●      In the tool for the enhancement comparison, these BAdI implementations are displayed with a green traffic light.

●      By selecting the comparison function, you can start the migration of the individual implementation manually.

Example

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: