With BW 7.3 version, SAP delivers the BAdI RSROA_VARIABLES_EXIT_BADI (BADI to fill variables).
The BAdI is the Customer upstream exit, that is, the calls the BAdI customer exit on. The below figure shows the call sequence and using the BAdI’s in combination with Customer Exits and BAdI implementations by the customer.
This BAdI Class calls the PROCESS method of all active BAdI implementations and the interface of the BAdI method PROCESS interface is identical to the interface of the function module EXIT_SAPLRRS0_001 the customer exit. This means that the source code of the customer exit can be fully adopted; this will reduce the migration effort.
The step by step procedure to create an implementation for a customer exit variable using this new BAdI has been discussed in detail in the subsequent section.
Step by Step Procedure:
To create a BAdI implementation of the new technology, there are several ways.
1. About the BAdI definition (transaction SE18)
2. Use the BAdI implementation (transaction SE19)
3. Üsing the ABAP Workbench (transaction SE80)
Go to transaction SE18, give the BAdI name as ‘RSROA_VARIABLES_EXIT_BADI’ and press the ‘Display’ button as shown below.
Now, Click on the ‘Create BAdI Implementation’ button as shown below.
A BAdI implementation cannot be created directly within a BAdI definition. First we have to create an Enhancement Implementation.
The subsequent screen prompts us to select the existing standard ‘CL_RSROA_VAR_SMOD’ implementation or to create a new one. Since we need to create a new one we click on the ‘Create Enhancement Implementation’ button as shown below.
Give the details of the Custom Enhancement Implementation as shown below and proceed.
This creates the new Enhancement Implementation ZRSROA_ENHANCEMENT_IMPL, Select it and proceed further.
Now create the new BAdI implementation ZRSROA_BADI_IMPL by specifying the new implementing class ZCL_ RSROA_VARIABLES_EXIT_BADI as shown below and continue and complete the activation process as shown in the below screenshots.
Once the activation of BAdI Implementation, Enhancement Implementation and Implementing Class is complete we need to specify the info objects for which the customer exit variables are to be defined in the ‘Filter Val.’ Selection of BAdI.
Now, double click upon the ‘Filter Val.’ and Create a new filter combination as shown below.
Change the filter combination value as = blank for IOBJNM. This step is required as for I_STEP = 3 there is no clear variable and no clear info object name. As in I_STEP 3 all variables in the current report are available in the form of a table parameter, for the BAdI implementation to be used for processing in I_STEP 3 the filter value of IOBJNM must be expanded to =” (blank).
Now, the info objects for which customer exit variables are to be processed need to be added separately. For e.g., If a variable on 0CALMONTH needs to be processed in Customer Exit mode then it should be added as shown below.
Note: To extend the above functionality to Formula and Text variables of processing type Customer Exit the IOBJNM filter needs to be populated with the values ‘1FORMULA‘ and ‘1TEXT‘ respectively in new Filter Combinations.
After the completion of above steps double click on the Implementing Class and click the ‘Change Class’ button as highlighted below.
Click to change the ‘Code’ button as shown now.
Change the code in the METHOD as below and activate.
Explanation of Code:
Since each of the individual steps for I_STEP has different meanings we made a generic definition that calls the individual function modules. This improves flexibility w.r.t transport of existing and new variables as and when they are changed/created and also facilitates the modularization of code.
For example If we have a customer exit variable ZCAL_BADI_TEST on the info object 0CALMONTH and if its logic needs to be implemented for I_STEP = 1 we need to create/define a new function module with the naming convention ZVAR_PRE_POPUP_ZCAL_BADI_TEST.
Similarly if the logic needs to be implemented for I_STEP = 2 of the same variable we need to create/define a function module with the naming convention ZVAR_POST_POPUP_ZCAL_BADI_TEST and for I_STEP =0 it has to be ZVAR_AUTHORITY_ZCAL_BADI_TEST.
For I_STEP = 3 since it’s not specific to a clear variable or info object we can use a common function module ZVAR_CHECK_VALIDITY.
All the function modules corresponding to the variables are to be created with the below parameters.
In the next section a test scenario has been explained which incorporates this procedure.
Created a custom InfoCube ZTESTBADI and populated it with data as shown below.
Created a Query on top of it with the structure as shown below.
The current month counter is restricted with an input variable ZTEST_INPUT for 0CALMONTH info object as shown under.
The previous month counter is restricted with a customer exit variable ZCAL_BADI_TEST.
In our scenario the logic needs to be defined such that it takes the input value from ZTEST_INPUT and populates the previous month value for the variable ZCAL_BADI_TEST.
Since the processing needs to be done for I_STEP = 2 we create/define a function module ZVAR_POST_POPUP_ZCAL_BADI_TEST as per the naming convention and with the import/export parameters as mentioned before with the appropriate code and populate the desired output into C_T_RANGE.
Upon executing the Query in debug mode we can observe that the I_STEPs 1, 2 and 3 are successfully accessed and the logic is working as desired.
I_STEP = 1 hit before variable input.
After I_STEP =1 enter the variable input for CALMONTH variable ZTEST_INPUT. E.g., 03/2013.
Now at I_STEP =2 after variable input.
Finally I_STEP = 3 and then the output.
We can observe that the output results are matching with those of InfoCube data for current input month entered and its previous month and the exit variable implemented through the BAdI RSROA_VARIABLES_EXIT_BADI Implementation is working correctly as desired.