Coexistence of BAdI RSROA_VARIABLES_EXIT_BADI and Customer-Exit EXIT_SAPLRRS0_001

[Torsten_]

This blog has been translated with Google Translate. the original blog can be found here: ekessler.de

In the blog BAdI RSROA_VARIABLES_EXIT_BADI I have shown how exit variables using the BAdI RSROA_VARIABLES_EXIT_BADI can be processed.

Now In this blog I want to deal with the coexistence of BAdI and customer exit. First, you should always consider I need the new technical way the SAP me here provides or can I also use the (customer exit) life?

The customer exit for BEx variables has always been a good candidate for unstructured, extensive and historically (often hysterical) grown Coding. This is due to the fact that the exit (Include ZXRSRU01) usually from many different developers (often short-term purchased external consultants) will be processed with different programming views (functional or Objektorientier). Not infrequently, bring this their procedures and approaches to structuring the customer exit (call dynamic function blocks / methods, nesting Includes, ...) from other projects with a.

Another reason that makes a structuring of the customer exits so complicated is the interleaving of two case distinctions. Firstly, it must be distinguished according to the current process step, the I_STEP, and secondly, by the variable to be processed. This nested branching nearly impossible to exit structuring. For this reason, a lot of different methods have been developed for customers all over how to tackle the problem. The following methods can be found in practice (partly slightly modified):

• Nested Includes
  The implementations of the individual departments are hereby outsourced to include and the include ZXRSRU01 only contains the individual department-specific includes.
• Dynamic call of function modules
  For each variable, a function block is created. By means of a fixed naming convention can be derived from the name of the variable and thus dynamically invoked the name of the function block.
• Dynamic invocation of methods of ABAP OO classes
  A method is created for each variable. By means of a fixed naming convention can be derived from the name of the variable and thus dynamically invoked the name of the method. Following the procedure for the function module. In this method the professional belonging together variables / methods are often summarized in a class. This makes the link between the variables with the appropriate method somewhat expensive but has the advantage that helper methods in the class can be reused easily.

Often customers have invested a lot of work into the development of such a concept and a migration towards the BAdI RSROA_VARIABLES_EXIT_BADI is made difficult by this method. It is therefore important that is initially clarified whether the use of the new BAdI also brings much added value that the migration effort worthwhile. To understand where the added value of using the BAdI's against the customer exit is I want to describe the use and the internal processing of exit variables and the interaction of the BAdI RSROA_VARIABLES_EXIT_BADI and the customer exit briefly here.

1.1 Internal processing of exit variables

To understand the internal processing process, it is first necessary to understand how the BAdI RSROA_VARIABLES_EXIT_BADI works. In the BAdI RSROA_VARIABLES_EXIT_BADI is a "new" BAdI. New BAdI are organized in enhancement spot. As known in the rule of the BAdI name, not the enhancement spots I always climb in through the BAdI Builder (transaction SE18) to edit the BAdI implementations. Furthermore, the BAdI RSROA_VARIABLES_EXIT_BADI is a filter-based BADI. As filter the BAdI uses the info object that forms the basis for the BEx variable. Figure 1.1 shows on the left the SAP code to handle variables. If it is in the current variables to be processed by an exit variable by means

      GET BADI variable_exit
        FILTERS
          iobjnm = i_iobjnm.

tested whether an active BAdI implementation exists in the filter settings to the info object names match. That is the calling process within the SAP standard variable processing, checks whether the BAdI Framework is an active BAdI implementation for a filter value.
If an active BAdI implementation found PROCESS method of the class of the BAdI implementation is called:

      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.

The definition of the BAdIs RSROA_VARIABLES_EXIT_BADI allows more than one active implementation (Multible use) to form a filter value. Find the BAdI framework for a filter value several active implementations are all performed sequentially. Here, the order is indeterminate.

Figure 1.1: Processing of exit variables

1.2 Default implementation

In addition to the BAdI definition RSROA_VARIABLES_EXIT_BADI were running SAP in the standard of an active BAdI implementation (SMOD_EXIT_CALL). (= IOBJNM <>'' or IOBJNM'') of the filter value of this implementation is defined so that this implementation will always be used as BAdI active implementation.

The BAdI implementation SMOD_EXIT_CALL is characterized in Release 7:30 as the default implementation. As a result, this implementation is called only if no other active implementation is found. It must be noted that the filter value is taken into account when determining the active implementations.
I will illustrate this with a small example. As part of a migration project, we want to change the processing of the exit variables of the processing in the customer exit to the BAdI based variant. The migration project can not be implemented in a Big Bang but due to the scope. So that some variables in the customer exit and some in the BAdI be processed.
Variables and basic information items:

• ZTKE_TODAY (0CALDAY)
• ZTKE_YESTERDAY (0CALDAY)
• ZTKE_CURWEEK (0CALWEEK)

BAdI implementations for variables and the filter

• SMOD_EXIT_CALL [default implementation]
  • BAdI Impl. SMOD_EXIT_CALL
  • Filter:  IOBJNM <>'' OR'' = IOBJNM
• TKE_TODAY
  • BAdI Impl. ZTKE_IMPL_CALDAY
  • Filter: IOBJNM = '0 CALDAY 'OR IOBJNM =''
• ZTKE_YESTERDAY
  • Processing takes place in the customer exit!

Query and variable

• ZTKE_Q_DAY (ZTKE_TODAY)
• ZTKE_Q_WEEK (ZTKE_CURWEEK)
• ZTKE_Q_YDAY (ZTKE_YESTERDAY)

Query processing ZTKE_Q_DAY

First, we consider the processing in I_STEP = 1
When you call the query ZTKE_Q_DAY the standard SAP processing determines all active Implementation to the filter 0CALDAY that are not marked as a default implementation.

GET BADI variable_exit
  FILTERS
    iobjnm = i_iobjnm.

Here the BAdI Framework will only find the BAdI implementation ZTKE_IMPL_CALDAY (filter  IOBJNM = '0 CALDAY ').
In I_STEP = 3 BAdI BAdI Implementation Framework only ZTKE_IMPL_CALDAY place again (filter  IOBJNM =''). In I_STEP = 3 all variables for validation (i_t_var_range) are available. I_vnam The parameters and i_iobjnm are I_STEP = 3 initial.

Query processing ZTKE_Q_YESTERDAY

Again, we first consider the processing in I_STEP = 1
When you call the query ZTKE_Q_YESTERDAY the standard SAP processing determines all active implementation to the filter 0CALDAY that are not marked as a default implementation.

GET BADI variable_exit
  FILTERS
    iobjnm = i_iobjnm.

Here the BAdI Framework will only find the BAdI implementation ZTKE_IMPL_CALDAY (filter  IOBJNM = '0 CALDAY ')! But we want to take advantage of the processing in the customer exit. This can be the case if, as have, the processing for this variable is not yet migrated in our example. Below I show how this can be implemented.
In I_STEP = 3 BAdI BAdI Implementation Framework only ZTKE_IMPL_CALDAY place again (filter  IOBJNM =''). Here the same applies as I_STEP = 1

Query processing ZTKE_Q_WEEK

Again, we first consider the processing in I_STEP = 1 When you call the query ZTKE_Q_WEEK the standard SAP processing determines all active implementation to the filter 0CALWEEK that are not marked as a default implementation.

GET BADI variable_exit
  FILTERS
    iobjnm = i_iobjnm.

Here you will find the BAdI Framework no active implementation that is not marked as a default implementation!
The default implementation SMOD_EXIT_CALL is used as the active implementation.
In I_STEP = 3 BAdI BAdI Implementation Framework finds the ZTKE_IMPL_CALDAY (filter  IOBJNM ='').

1.3 Results

The following points should be noted:

• In the various implementations of the I_STEP must be checked and the current variable (Relocated CASE)
  In the example above, the implementation ZTKE_IMPL_CALDAY used as the active implementation for all variables based on the info object 0CALDAY. That within the implementation must be distinguished according to the currently processed variable analogous to the customer exit a case distinction. The case distinction is here implemented instruction usually with the help of CASE.

• I_STEP 0,1,2 and the special case I_STEP = 3
  Similar to the variable name must be distinguished within the implementations of the I_STEP. The I_STEP = 3 provides as a special case here. In I_STEP = 3 all variables are testing and validation, and the parameters I_VNAM and I_IOBJNM are initial. That a case distinction according to the variable name is not possible here. When processing the I_STEP = 3 all BAdI implementations are called as active implementations in the filter IOBJNM = contain''. That it must be here a distinction according to the current query to be processed. The current query can be determined from the component COMPID the structure I_S_RKB1D.

• With Release 7:30 it is not possible without further a BAdI implementation and parallel to use the customer exit.

• From Release 7:40 SPS09 and BAdI customer exit can be used in parallel without further notice. For 7.40er systems from SPS09 the Note 2036773 needs to be implemented

2 Coexistence with Release 7:30

In a SAP BW / .3 system of BAdI RSROA_VARIABLES_EXIT_BADI and the customer exit EXIT_SAPLRRS0_001 can not be operated in parallel without further ado, see example above. To ensure that the customer exit is always run, it is necessary to set up your own BAdI implementation to this. For the BAdI implementation, the filter values are defined analogously to the SAP standard implementation.

Figure 2.1 shows a BAdI implementation to call the customer exits.

Figure 2.1: BAdI definition for Customer Exit

Figure 2.2 shows the filter values of the BAdI implementation.

Figure 2.2: Filter values of the BAdI implementation

Listing 2.1 shows the implementation of the PROCESS method of BAdI implementation. Within the implementation of the call to the customer exit is passed. It should be noted that it must be ensured not be deleted that may have already been determined value. The parameter E_T_RANGE of the function block is a pure export parameters, ie if the parameter C_T_RANGE was already filled in another BAdI implementation, this value must be saved before calling the exit.

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: Implementation of the PROCESS method