Migrating Classical BAdIs 

Purpose

Since the use of ABAP statements makes the call of new BAdIs visibly faster than the call of classic BAdIs, as of release 7.0 you must define only new BAdIs and migrate all classic BAdIs and their calls into new BAdIs.

The ideal solution could be a completely automated migration of all existing classic BAdIs. However, due to some differences between classic and new BAdIs this is not feasible. For more information, see Differences Between Classic and New BAdIs.

Process Flow

A feasible solution is a semi-automatic migration of the classic BAdIs with the following functionality:

       1.      For a classic BAdI a (simple) enhancement spot is created with the same name as the classic BAdI.

       2.      In the enhancement spot, exactly one new BAdI is created, which also carries the same name as the classic BAdI.

       3.      The new BAdI is defined with context-dependent instance generation mode.

       4.      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.

       5.      The tag interface IF_BADI_INTERFACE is included in the BAdI interface of the classic BAdI.

       6.      If a filter is defined for the classic BAdI, the components of the related filter structure are copied to the new BAdI as separate filters. The name of the component is used as the name of a new filter; its type is always c.

       7.      All existing implementations of the classical BAdI are copied to new BAdI implementations. The new BAdI methods are created within the existing BAdI implementation classes.

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

Additional Information

BAdIs can only be migrated in their original systems. The migration of the 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.

The responsible developers are informed of the migration and should change the old call of the factory method and the old call of a BAdI method in their programs to the statements GET BADI and CALL BADI. They can specify the self-reference me for the BAdI context object with GET BADI. After the migration of all calls, the classic BAdI can be deleted. The BAdI interface and the BAdI implementation classes, however, are kept.

Screen enhancements with classic BAdIs are called using the CL_EXITHANDLER=>GET_PROG_AND_DYNP_FOR_SUBSCR method. During the migration, 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.

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, however, the classic BAdI is not deleted immediately after the migration, but 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:

 

See also:

Migrating BAdIs