Migration klassischer BAdIs
Einsatzmöglichkeiten
Da der Aufruf neuer BAdIs erheblich schneller erfolgt als der Aufruf klassischer BAdIs, empfiehlt es sich, nur neue BAdIs zu definieren und alle klassischen BAdIs und ihre Aufrufe in neue BAdIs zu migrieren. Stellen Sie sicher, dass Sie nur Ihre eigenen BAdIs migrieren. Kunden sollten niemals die von SAP bereitgestellten BAdIs migrieren.
Eine vollständig automatisierte Migration aller vorhandenen klassischen BAdIs ist aufgrund der bestehenden Unterschiede zwischen klassischen und neuen BAdIs nicht möglich. Aus diesem Grund empfiehlt SAP, dass Sie den unten beschriebenen Prozess für eine halbautomatische Migration befolgen.
Weitere Informationen finden Sie unter Unterschiede zwischen klassischen und neuen BAdIs.
Ablauf
1. Für ein klassisches BAdI wird ein (einfacher) Erweiterungsspot mit dem Namen des klassischen BAdI angelegt.
Es ist auch möglich, einen anderen Namen zu verwenden oder einen vorhandenen Erweiterungsspot zu wählen.
2. Im Erweiterungsspot wird genau ein neues BAdI angelegt, das den gleichen Namen wie das klassische BAdI hat. (Der Name kann geändert werden.)
3. Das neue BAdI wird mit einem kontextabhängigen Instanzerzeugungsmodus.
4. Die Eigenschaften des klassischen BAdI (z. B. Mehrfachverwendung, Texte) sowie Screen- und Menüerweiterungen (z. B. Funktionscode-Erweiterungen) werden 1:1 übernommen.
5. Das Tag-Interface IF_BADI_INTERFACE wird in das BAdI-Interface des klassischen BAdI aufgenommen.
6. Wenn für das klassische BAdI ein Filter definiert ist, werden die Komponenten der zugehörigen Filterstruktur als einzelne Filter in das neue BAdI übernommen. Als Name eines neuen Filters wird der Name der Komponente übernommen und sein Typ ist immer c.
7. Alle bestehenden Implementierungen des klassischen BAdI werden in neue BAdI-Implementierungen kopiert. Die neuen BAdI-Methoden werden innerhalb der bestehenden BAdI-Implementierungsklassen angelegt.
8. Analog zur Migration der Filterdefinition wird auch die Struktur der Filterbedingung einer klassischen BAdI-Implementierung in einzelne Filterbedingungen zerlegt.
Nach Beendigung der (partiellen) Migration ist es von Vorteil mit der optionalen vollständigen Migration fortzufahren, um von allen Vorzügen der neuen BAdIs profitieren zu können.
...
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. Ändern Sie die Instanzierung und den Aufruf des BAdI über GET BADI/CALL BADI.
Nutzen Sie den Verwendungsnachweis des BAdI-Interface, um alle alten BAdI-Aufrufe ausfindig zu machen.
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 zu machen (Aufrufe) 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:
Siehe auch: