Im Blog BAdI RSROA_VARIABLES_EXIT_BADI habe ich aufgezeigt wie Exit-Variablen unter Verwendung des BAdI RSROA_VARIABLES_EXIT_BADI verarbeitet werden können.

In diesem Blog will ich nun auf die Koexistenz von BAdI und Customer-Exit eingehen.

Zunächst sollte man immer überlegen, benötige ich den neuen technischen Weg den SAP mir hier zur Verfügung stellt oder kann ich auch mit dem (Customer-Exit) Leben!?

1.1 Strukturierung des Customer-Exits

Der Customer-Exit für BEx Variablen war schon immer ein guter Kandidat für unstrukturiertes, umfangreiches und historisch (häufig auch hysterisch) gewachsenes Coding. Das liegt zum einen daran, dass der Exit (Include ZXRSRU01) in der Regel von viele unterschiedliche Entwickler (häufig auch kurzfristig eingekaufte externe Berater) mit unterschiedlichen Programmieransichten (Funktional oder Objektorientier) bearbeitet wird. Nicht selten bringen diese ihre Verfahren und Ansätze zur Strukturierung des Customer-Exits (Aufruf dynamischer Funktionsbausteine / Methoden, Schachtelung von Includes, …) aus anderen Projekten mit ein.

Ein weiterer Grund der eine Strukturierung des Customer-Exits so kompliziert macht ist die Verschachtelung von zwei Fallunterscheidungen. Zum einen muss nach dem aktuellen Prozessschritt, dem I_STEP, und zum anderen nach der zu verarbeitenden Variable unterschieden werden. Diese verschachtelte Verzweigung macht nahezu unmöglich den Exit zu strukturieren.

Aus diesem Grunde haben sich bei Kunden inzwischen eine Menge unterschiedlicher Verfahren entwickelt wie man dem Problem begegnen kann. Folgende Verfahren findet man in der Praxis (teilweise leicht modifiziert):

–       Verschachtelte Includes

Die Implementierungen der einzelnen Fachbereiche werden hierbei in Includes ausgelagert und der Include ZXRSRU01 enthält nur noch die einzelnen Fachbereich-spezifischen Includes.

–       Dynamischer Aufruf von Funktionsbausteinen

Für jede Variable wird ein Funktionsbaustein angelegt. Mittels festgelegter Namenskonvention kann der Name des Funktionsbausteins aus dem Namen der Variablen abgeleitet und somit dynamisch aufgerufen werden.

–       Dynamischer Aufruf von Methoden von ABAP-OO Klassen

Für jede Variable wird eine Methode angelegt. Mittels festgelegter Namenskonvention kann der Name der Methode aus dem Namen der Variablen abgeleitet und somit dynamisch aufgerufen werden. Analog zum Verfahren beim Funktionsbaustein. Bei diesem Verfahren werden die fachlich zusammengehörenden Variablen / Methoden häufig in einer Klasse zusammengefasst. Das macht die Verknüpfung der Variablen mit der entsprechenden Methode zwar etwas aufwändiger hat aber den Vorteil, dass Hilfsmethoden in der Klasse leicht wiederverwendet werden können.

Häufig haben Kunden viel Arbeit in die Entwicklung eines solchen Konzeptes investiert und eine Migration in Richtung des BAdI RSROA_VARIABLES_EXIT_BADI wird durch diese Verfahren erschwert. Darum ist es wichtig, dass zunächst geklärt ist ob die Verwendung des neuen BAdI auch soviel Mehrwert bringt, dass sich der Migrationsaufwand lohnt.

Um zu verstehen wo der Mehrwert der Verwendung des BAdI’s gegenüber dem Customer-Exit liegt will ich hier die Verwendung und die interne Verarbeitung von Exit-Variablen und das zusammenspeil von dem BAdI RSROA_VARIABLES_EXIT_BADI und dem Customer-Exit noch einmal kurz beschreiben.

1.2     Interne Verarbeitung von Exit-Variablen

Um den internen Verarbeitungsprozess zu verstehen ist es zunächst notwendig zu verstehen wie der BAdI RSROA_VARIABLES_EXIT_BADI funktioniert.

Bei dem BAdI RSROA_VARIABLES_EXIT_BADI handelt es sich um einen „neuen“ BAdI. Neue BAdIs sind in Erweiterungsspots organisiert. Da in der Regel der BAdI Name und nicht der Erweiterungsspots bekannt sind steige ich immer über den BAdI Builder (Transaktion SE18) zur Bearbeitung von BAdI Implementierungen ein.

Des Weiteren ist der BAdI RSROA_VARIABLES_EXIT_BADI ist ein Filter basierter BADI. Als Filter verwendet der BAdI das InfoObjekt das die Basis für die BEx Variable bildet.

Figure 1.1 zeigt auf der linken Seite den SAP Code zur Verarbeitung von Variablen. Handelt es sich bei der aktuell zu verarbeitenden Variablen um eine Exit-Variable wird mittels

GET BADI variable_exit
  FILTERS           
    iobjnm = i_iobjnm.

geprüft ob eine aktive BAdI Implementierung existiert bei der die Filtereinstellungen mit dem InfoObjekt-Namen übereinstimmen. Das heißt der aufrufende Prozess, innerhalb der SAP Standard Variablenverarbeitung, prüft über das BAdI Framework ob für einen Filterwert eine aktive BAdI Implementierung existiert.

Wird eine aktive BAdI Implementierung gefunden wird PROCESS Methode der Klasse der BAdI Implementierung aufgerufen:

CALL BADI variable_exit->process         
  EXPORTING           
    i_vnam        = i_vnam           
    i_vartyp      = i_vartyp           
    i_iobjnm      = i_iobjnm           
    i_s_cob_pro   = i_s_cob_pro           
    i_s_rkb1d     = i_s_rkb1d           
    i_periv       = i_periv           
    i_t_var_range = i_t_var_range           
    i_step        = i_step         
  CHANGING           
    c_t_range     = e_t_range           
    c_no_screen   = e_no_screen           
    c_check_again = e_check_again           
    c_s_customer  = c_s_customer.

Die Definition des BAdIs RSROA_VARIABLES_EXIT_BADI erlaubt mehr als eine aktive Implementierung (Multible Use) zu einem Filterwert. Findet das BAdI Framework für einen Filterwert mehrere aktive Implementierungen werden alle nacheinander ausgeführt. Hierbei ist die Reihenfolge unbestimmt.

Figure 1.1: Verarbeitung von Exit-Variablen

1.2      Standard Implementierung

Neben der BAdI RSROA_VARIABLES_EXIT_BADI Definition liefet SAP im Standard auch eine aktive BAdI Implementierung (SMOD_EXIT_CALL) aus. Der Filterwert ( IOBJNM <> ‘‘ OR IOBJNM = ‘‘ ) dieser Implementierung ist so definiert, dass diese BAdI Implementierung immer als aktive Implementierung verwendet wird.

Die BAdI Implementierung SMOD_EXIT_CALL ist in Release 7.30 als Default Implementation gekennzeichnet. Das hat zur Folge, dass diese Implementierung nur aufgerufen wird wenn keine andere aktive Implementierung gefunden wird. Hierbei muss beachtet werden, dass der Filterwert bei der Ermittlung der aktiven Implementierungen berücksichtigt wird.

Ich will das an einem kleinen Beispiel veranschaulichen. Im Rahmen eines Migrationsprojektes wollen wir die Verarbeitung der Exit-Variablen von der Verarbeitung im Customer-Exit auf die BAdI basierte Variante umstellen. Das Migrationsprojekt kann aber auf Grund des Umfangs nicht in einem Big-Bang umgesetzt werden. So dass einige Variablen im Customer-Exit und einige im BAdI verarbeitet werden.

Variablen und Basis InfoObjekte:

–       ZTKE_TODAY (0CALDAY)

–       ZTKE_YESTERDAY (0CALDAY)

–       ZTKE_CURWEEK (0CALWEEK)

BAdI Implementierungen für Variablen und die Filter

–       SMOD_EXIT_CALL [Default Implementierung]

o   BAdI Impl.: SMOD_EXIT_CALL

o   Filter:  IOBJNM <> ‘‘ OR IOBJNM = ‘‘

–       TKE_TODAY

o   BAdI Impl.:      ZTKE_IMPL_CALDAY

o   Filter:  IOBJNM = ‘0CALDAY‘ OR IOBJNM = ‘‘

–       ZTKE_YESTERDAY

o   Verarbeitung findet im Customer-Exit statt!

Query und Variable

–       ZTKE_Q_DAY (ZTKE_TODAY)

–       ZTKE_Q_WEEK (ZTKE_CURWEEK)

–       ZTKE_Q_YDAY (ZTKE_YESTERDAY)

Verarbeitung Query ZTKE_Q_DAY

Zunächst betrachten wir die Verarbeitung im I_STEP = 1.

Beim Aufruf der Query ZTKE_Q_DAY ermittelt die Standard SAP Verarbeitung alle aktiven Implementierung zu dem Filter 0CALDAY die nicht als Default Implementierung gekennzeichnet sind.

GET BADI variable_exit         
  FILTERS           
    iobjnm = i_iobjnm.

Hier findet das BAdI Framework nur die BAdI Implementierung ZTKE_IMPL_CALDAY (Filter: IOBJNM = ‘0CALDAY‘ ).

Im I_STEP = 3 findet das BAdI Framework wieder nur die BAdI Implementierung ZTKE_IMPL_CALDAY (Filter: IOBJNM = ‘‘ ). Im I_STEP = 3 stehen alle Variablen zur Validierung (i_t_var_range) zur Verfügung. Die Parameter i_vnam und i_iobjnm sind im I_STEP = 3 initial.

Verarbeitung Query ZTKE_Q_YESTERDAY

Auch hier betrachten wir zunächst die Verarbeitung im I_STEP = 1.

Beim Aufruf der Query ZTKE_Q_YESTERDAY ermittelt die Standard SAP Verarbeitung alle aktiven Implementierung zu dem Filter 0CALDAY die nicht als Default Implementierung gekennzeichnet sind.

GET BADI variable_exit         
  FILTERS           
    iobjnm = i_iobjnm.

Hier findet das BAdI Framework nur die BAdI Implementierung ZTKE_IMPL_CALDAY (Filter è IOBJNM = ‘0CALDAY‘ )! Wir wollen aber die Verarbeitung im Customer-Exit nutzen. Dies kann der Fall sein wenn, wie in unserem Beispiel, die Verarbeitung für diese Variable noch nicht migriert haben. Weiter unten zeige ich wie dies umgesetzt werden kann.

Im I_STEP = 3 findet das BAdI Framework wieder nur die BAdI Implementierung ZTKE_IMPL_CALDAY (Filter è IOBJNM = ‘‘ ). Hier gilt das gleiche wie im I_STEP = 1.

Verarbeitung Query ZTKE_Q_WEEK

Auch hier betrachten wir zunächst die Verarbeitung im I_STEP = 1.

Beim Aufruf der Query ZTKE_Q_WEEK ermittelt die Standard SAP Verarbeitung alle aktiven Implementierung zu dem Filter 0CALWEEK die nicht als Default Implementierung gekennzeichnet sind.

GET BADI variable_exit         
  FILTERS           
    iobjnm = i_iobjnm.

Hier findet das BAdI Framework keine aktive Implementierung die nicht als Default Implementierung gekennzeichnet ist!

Die Default Implementierung SMOD_EXIT_CALL wird als aktive Implementierung verwendet.

Im I_STEP = 3 findet das BAdI Framework die BAdI Implementierung ZTKE_IMPL_CALDAY (Filter: IOBJNM = ‘‘ ).

1.3      Erkenntnis

Folgende Punkte sind zu beachten:

• In den einzelnen Implementierungen muss der I_STEP und die aktuelle Variable geprüft werden (Verlagerter CASE)

Im Beispiel oben wird für alle Variablen die auf dem InfoObjekt 0CALDAY basieren die Implementierung ZTKE_IMPL_CALDAY als aktive Implementierung herangezogen. D.h. innerhalb der Implementierung muss analog zum Customer-Exit eine Fallunterscheidung nach der aktuell zu verarbeitenden Variable unterschieden werden. Die Fallunterscheidung wird hier in der Regel mit Hilfe der CASE Anweisung umgesetzt.

• I_STEP 0,1,2 und dem Sonderfall I_STEP = 3

Analog zum Variablennamen muss innerhalb der Implementierungen der I_STEP unterschieden werden.

Der I_STEP = 3 stellt hier einen Sonderfall da. Im I_STEP = 3 stehen alle Variablen zur Validierung zur Verfügung und die Parameter I_VNAM und I_IOBJNM sind initial. D.h. eine Fallunterscheidung nach dem Variablennamen ist hier nicht möglich.

Bei der Verarbeitung des I_STEP = 3 werden alle BAdI Implementierungen als aktive Implementierungen aufgerufen die im Filter IOBJNM = ‘‘ enthalten. D.h. es muss hier eine Unterscheidung nach der aktuell zu verarbeitenden Query erfolgen. Die aktuelle Query kann aus der Komponente COMPID der Struktur I_S_RKB1D ermittelt werden.

• Mit Release 7.30 ist es nicht ohne weiteres Möglich eine BAdI Implementierung und parallel den Customer-Exit zu nutzen
• Ab Release 7.40 SPS09 können BAdI und Customer-Exit ohne weiteres parallel verwendet werden. Für 7.40er Systeme vor SPS09 muss der Hinweis 2036773 implementiert werden

2      Koexistenz mit Release 7.30

In einem SAP BW /.3 System können der BAdI RSROA_VARIABLES_EXIT_BADI und der Customer-Exit EXIT_SAPLRRS0_001 nicht ohne weiteres parallel betrieben werden, siehe Beispiel oben. Um sicher zu stellen, dass der Customer-Exit immer durchlaufen wird ist es notwendig hierfür eine eigene BAdI Implementierung an zu legen. Für die BAdI Implementierung werden die Filterwerte analog zur SAP Standard Implementierung festgelegt.

Figure 2.1 zeigt eine BAdI Implementierung zum aufrufen des Customer-Exits.

Figure 2.1: BAdI Definition für Customer-Exit

Figure 2.2 zeigt die Filterwerte der BAdI IMplementierung.

Figure 2.2: Filterwerte der BAdI Implementierung

Listing 2.1 zeigt die Implementierung der PROCESS Methode der BAdI Implementierung. Innerhalb der Implementierung wird der Aufruf an den Customer-Exit weitergereicht. Hierbei ist zu beachten dass sichergestellt werden muss dass eventuell bereits ermittelte Wert nicht wieder gelöscht werden.

Der Parameter E_T_RANGE des Funktionsbausteins ist ein reiner Export Parameter, d.h. wenn der Parameter C_T_RANGE bereits in einer anderen BAdI Implementierung gefüllt wurde muss dieser Wert vor dem Aufruf des Exits gesichert werden.

METHOD if_rsroa_variables_exit_badi~process.   
  DATA: lt_range_tmp TYPE rsr_t_rangesid.   

  IF c_t_range IS NOT INITIAL.     
    APPEND LINES OF c_t_range TO lt_range_tmp.   
  ENDIF.   

  CALL FUNCTION 'EXIT_SAPLRRS0_001'     
    EXPORTING       
      i_vnam        = i_vnam       
      i_vartyp      = i_vartyp       
      i_iobjnm      = i_iobjnm       
      i_s_cob_pro   = i_s_cob_pro       
      i_s_rkb1d     = i_s_rkb1d       
      i_periv       = i_periv       
      i_t_var_range = i_t_var_range       
      i_step        = i_step     
    IMPORTING       
      e_t_range     = c_t_range 
*  E_MEEHT       =
*     E_MEFAC       =
*     E_WAERS       =
*     E_WHFAC       =       
     e_no_screen   = c_no_screen       
     e_check_again = c_check_again     
   CHANGING       
     c_s_customer  = c_s_customer.   
   
  IF lt_range_tmp IS NOT INITIAL.     
    APPEND LINES OF lt_range_tmp TO c_t_range.   
  ENDIF.

ENDMETHOD.

Listing 2.1: Implementierung der PROCESS Methode