BAdIs migrieren 

Automatische (partielle) Migration

...

...

       1.      Rufen Sie den klassischen BAdI Builder (Transaktion SE18) auf.

       2.      Geben Sie den Namen des zu migrierenden BAdIs an.

       3.      Wählen Sie Hilfsmittel → Migrieren klassischer BAdI.

       4.      Erstellen Sie einen Erweiterungsspot mit demselben Namen wie das klassische BAdI.

Es ist auch möglich, einen anderen Namen zu verwenden oder einen vorhandenen Erweiterungsspot zu wählen.

       5.      Legen Sie im Erweiterungsspot ein neues BAdI an, das den gleichen Namen wie das klassische BAdI hat.

       6.      Das neue BAdI sollte mit einem kontextabhängigen Instanzerzeugungsmodus definiert werden.

Die Eigenschaften des klassischen BAdI (z. B. Mehrfachverwendung, Texte) sowie Screen- und Menüerweiterungen (z. B. Funktionscode-Erweiterungen) werden unverändert übernommen.

Das Tag-Interface IF_BADI_INTERFACEwird in das BAdI-Interface des klassischen BAdI aufgenommen.

       7.      Wenn Sie für das klassische BAdI einen Filter definieren, übernehmen Sie die Komponenten der zugehörigen Filterstruktur als einzelne Filter in das neue BAdI. Verwenden Sie den Namen der Komponente als Namen des neuen Filters; der Typ ist immer c.

       8.      Kopieren Sie alle bestehenden Implementierungen des klassischen BAdI in neue BAdI-Implementierungen. Legen Sie die neuen BAdI-Methoden innerhalb der bestehenden BAdI-Implementierungsklassen an

       9.      Analog zur Migration der Filterdefinition sollte auch die Struktur der Filterbedingung einer klassischen BAdI-Implementierung in einzelne Filterbedingungen zerlegt werden.

   10.      Transportieren Sie die Änderung in ein Folgesystem:

                            a.      Rufen Sie die Transaktion SPAU auf, falls eine BAdI-Implementierung zu einem migrierten BAdI vorhanden ist.

In diesem Fall finden Sie eine Meldung mit der Kennung 6 im Eingangsprotokoll des Transportauftrags.

                            b.      Klicken Sie auf die Ampel vor der BAdI-Implementierung.

                            c.      Geben Sie eine Erweiterungsimplementierung an.

Vollständige Migration

...

Nach Beendigung der (partiellen) Migration können Sie mit der optionalen vollständigen Migration fortfahren, um von allen Vorzügen der neuen BAdIs profitieren zu können.

Hierfür benötigen Sie hervorragende Anwendungskenntnisse. Der Aufwand kann zwischen einigen Minuten bis mehreren Tagen pro BAdI betragen.

...

       1.      Löschen Sie das klassische BAdI. (Beantworten Sie die Frage, ob das migrierte BAdI auch gelöscht werden soll, mit Nein.)

       2.      Ändern Sie das neue BAdI gemäß Ihren Anforderungen.

In den meisten Fällen wird der Kontext nicht benötigt, nehmen Sie also Änderungen am Instanzierungsmodus entsprechend vor.

       3.      Suchen Sie alle Aufrufe des klassischen BAdI durch GET_INSTANCE und programmieren Sie den BAdI-Aufruf mit den neuen Befehlen GET BADI und CALL BADI neu.

       4.      Um die Performance zu verbessern, können Sie die Kontexteinstellungen für BAdIs ändern, die mehr als ein Mal in einem Programm aufgerufen werden.

Weitere Informationen

BAdIs können nur in ihrem jeweiligen Originalentwicklungssystem migriert werden. Die Migration von BAdI-Implementierungen wird in allen Folgesystemen durch den Transport eines migrierten BAdI angestoßen.

Der Aufruf von CL_EXIT_HANDER=>GET_INSTANCE sowie die folgenden Aufrufe der BAdI-Methoden werden nicht automatisch umgesetzt. Die bisherige ABAP-Proxy-Klasse des klassischen BAdI bleibt zur Gewährleistung dieser halbautomatischen Migration erhalten, wird aber neu generiert. Sie implementiert danach das Tag-Interface IF_BADI_CONTEXT für BAdI-Kontextobjekte und verwendet in ihren Proxy-Methoden die neuen Anweisungen GET BADI und CALL BADI, um das migrierte BAdI zu rufen, statt die Implementierungen selbst zu bestimmen.

Screen-Erweiterungen werden bei klassischen BAdIs über die Methode CL_EXITHANDLER=>GET_PROG_AND_DYNP_FOR_SUBSCR aufgerufen. Bei der Migration bleiben Methode und Aufruf erhalten. In der Methode wird nach der Migration aber die Methode CL_ENH_BADI_RUNTIME_FUNCTIONS=>GET_PROG_AND_DYNP_FOR_SUBSCR für die neuen BAdIs aufgerufen.

Die Methode SET_INSTANCE_FOR_SUBSCREEN aus den alten BAdIs ist nicht mehr erforderlich und GET_INSTANCE_FOR_SUBSCREEN kann durch den Befehl GET BADI ersetzt werden, da BAdIs mit Screen-Erweiterungen immer den Instanzierungsmodus wiederverwenden (reuse) haben.

Menüerweiterungen bzw. Funktionscode-Erweiterungen werden bei den neuen wie bei den klassischen BAdIs während der Generierung eines Programms ausgewertet. Die Generierung berücksichtigt gleichermaßen klassische und neue BAdIs.

Nach der Migration darf das resultierende neue BAdI nicht geändert werden, solange das ursprüngliche klassische BAdI noch vorhanden ist. Wird das klassische BAdI nach der Migration nicht gleich gelöscht, sondern noch einmal geändert, wird das resultierende neue BAdI angepasst. Daher dürfen BAdIs nur in ihrem Originalsystem migriert werden.

Es wird empfohlen, möglichst bald alle notwendigen manuellen Umstellungen (Aufrufe) vorzunehmen und dann das klassische BAdI zu löschen.

Einfluss auf Upgrades

BAdI-Implementierungen werden in der Regel in Folgesystemen des Systems angelegt, in dem ein BAdI definiert ist. Die Migration eines BAdI in dessen Originalsystem löst wie folgt die Migration der Implementierungen in allen Folgesystemen aus:

●      Für alle zugehörigen BAdI-Implementierungen wird ein Upgrade-Kennzeichen gesetzt.

●      Im Werkzeug für den Erweiterungsabgleich werden diese BAdI-Implementierungen mit grüner Ampel angezeigt.

●      Durch Auswahl der Abgleichfunktion kann die Migration der jeweiligen Implementierung manuell gestartet werden.

Beispiel

BAdI-Interface nach der 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-Klasse nach der 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.       

Damit ergibt sich folgende Aufrufhierarchie: