
Es ist auch möglich, einen anderen Namen zu verwenden oder einen vorhandenen Erweiterungsspot zu wählen.
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.
In diesem Fall finden Sie eine Meldung mit der Kennung 6 im Eingangsprotokoll des Transportauftrags.
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.
In den meisten Fällen wird der Kontext nicht benötigt, nehmen Sie also Änderungen am Instanzierungsmodus entsprechend vor.
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:
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: