Skip to Content

Everything you always wanted to know about the processing of customer exit variables, but …

The original blog can be found here:

In this blog I would like to try some clarity in the processing of exit variables (EXIT_SAPLRRS0_001) to bring. The emerged with BW 7.30 BAdI RSROA_VARIABLES_EXIT_BADI has to deal with Exit variable not exactly simplified. In addition, the BAdI is unfortunately not documented in the SAP Help. Furthermore, it has now also changed 60 with the 7.4 domain RSCHAVL of CHAR to SSTRING.

All exit variables described here are used to the range of values of a report limit or expand the scope of permissions. In addition, the properties described here by Exit variables for Exit variables are to be used as part of the staging in DTP‘s or InfoPackages.

First, however, let us first of all deal with the different types of exit variables and their processing order.

1.1      Variablentypen

If I talk about exit variables I distinguish the following types of use:

  • Ready for input
  • Not ready for input
  • Use for authorization or staging

Ready for input variables come then to use if the user should be given the opportunity to influence the outcome report individually. The basic concept of an input-ready variables provides the user determines the value for the variable, and the value could not be changed by internal processing processes (customer exit). In section 1.3, Overriding input values“, I describe how this concept can be bypassed and the user-entered value of an input-ready variables in the customer exit can be overwritten.

Reday for input variables would be processed in I_STEP = 1 and I_STEP = 3, see Section 1.2 processing steps (I_STEP)”.

Not ready for input variables come then to use if the value is to be determined by rules. Here rules are often defined (implemented) in which the variable values for input-ready variables not depending on ready for input variables are determined.

Not ready for input variables would be processed in I_STEP = 1 and I_STEP = 2, see Section 1.2 processing steps (I_STEP)”.

Exit variables can also be used as part of authorization or to staging. At exit variables that must be considered are used here, that there is no interaction with a user is usually held. This means here is the processing order another.

Therefore, it must be ensured here that combinations as ready for input, mandatory and no default value (Default value) that cause a variable dialog is needed. Process of staging (DTP, InfoPackage) are usually scheduled processes in place that are executed by backgroundusers.

Variables of usage authorization and staging are processed only in I_STEP = 0, see Section 1.2 processing steps (I_STEP)”.

1.2 Processing steps (I_STEP)

Exit variables depending on the usage and purpose in one or more steps, the I_STEP‘s processed. In the section “Dependencies for Variables of Type Customer Exitthe SAP Help the I_STEP‘s are briefly explained. The description in the online help is unfortunately incomplete and omitted entirely on examples. Therefore, I will briefly explain each step again using examples.

1.2.1 Authorization and Staging (I_STEP = 0)

In I_STEP = 0 exit variables are processed in the authorization and are used in staging. Figure 1.1 shows the use of an exit variables within the authorization. For the processing of exit variables within the entitlement only the I_STEP = 0 is traversed.


Figure 1.1: Exit variables within the authorization

Figure 1.2 shows the use of an exit variables in staging the example of selection within an InfoPackage.


Figure 1.2: Exit variables within the Staging

1.2.2 Initialization (I_STEP = 1)

The I_STEP = 1 is used for initialization of variables and exit is run separately for each exit variable. In the first stage the input-ready variables and then not ready for input variables are processed, see Figure 1.7. (The order could be differ, depends on the release (here BW 7.31 SP06)!)

Figure 1.3 shows a typical example of initializing an input-ready variables. The variable is initialized with the current month of last year.


Figure 1.3: Initialization

1.2.3 Derivation of variable values (I_STEP = 2)

The I_STEP = 2 is used to derive the values for the non-input-ready variables Exit. Again, the variables are processed separately analogous to I_STEP = 1. To derive the values for non-input-ready variables Exit all previously detected variable values in the parameter I_T_VAR_RANGE available. In section 1.3, Overriding values enteredI describe as well as input-ready variables can be processed here.

Figure 1.4 shows how the current variable (examination of the variable name is not shown here), the value is derived based on the value of the variable ZTKE_MONTH.


Figure 1.4: Derivation of variables

1.2.4 validation (I_STEP = 3)

The I_STEP = 3 is used to validate all recorded variables. In I_STEP = 3 all previously recorded values in the parameter I_T_VAR_RANGE are testing and validation.

The I_T_VAR_RANGE parameter contains only the variables that contain a value. That is here are the only variables included:

  • value set by default value or
  • value set by an implementation (I_STEP = 1 or I_STEP = 3) or
  • user entered a value in the variable dialog

In I_STEP = 3 can not be changed, the values of the individual variables. It is possible to generate messages which would be display with the reportresult or the variable dialog. In the event that the validation of the variables means that it makes no sense to run the report by throwing an exception (RAISE EXCEPTION) to prevent the report is run. The exception means that the user re-enters the values in the variables dialog.

Figure 1.5 shows the values for the two variables ZYEARFROM and ZYEARTO determined and then compared as in I_STEP = 3. If the FROM value greater than TO value of a message is issued and using the RAISE statement wrong_value prevents the report is run. The user has the opportunity to correct the value in the variable dialog.


Figure 1.5: Validation Customer Exit

Figure 1.6 shows similar to the example in Figure 1.5, as in the object-oriented context to run the report can be prevented. The exception must be thrown here in the object-oriented context.


Figure 1.6: Validation BAdI

1.3 Execution Order of I_STEP

Figure 1.7 shows the sequence in which the individual‘s I_STEP under a BEx reports. I distinguish the two phases:

  • Präparation (preparation phase) and
  • Validierung (Validation Phase)

The I_STEP‘s the preparation phase are run before the variable dialogue and I_STEP‘s validation phase will only go through if the values of the input-ready variables change in the variables dialog.


Figure 1.7: Processing of exit variables (I_STEP’s)

That is the calling SAP standard processing procedure initially assumes that the user accepts the default values of the variables dialog without changing. In this case, the validation phase is not run again!

The process steps of the validation phase will only go through if the values in the dialog variables were changed by the user.

1.4 Processing of process variables Exit

With BW 7.3 the BAdI RSROA_VARIABLES_EXIT_BADI was introduced and presented to the customer exit EXIT_SAPLRRS0_001. The blog Coexistence of BAdI RSROA_VARIABLES_EXIT_BADI and Customer-Exit EXIT_SAPLRRS0_001 shows how the BAdI and the customer exit behave in a BW 7.3 system.

Figure 1.8 shows the individual processing blocks which are executed as part of the variable processing of exit variables.


Figure 1.8: Variables processing

The standard processing process first checks whether an active BAdI implementation by Type RSROA_VARIABLES_EXIT_BADI is available. As a filter value here, the technical name of the InfoObject is used on the exit variable based currently being processed. From a technical perspective, this test is performed within the function block RRS_VAR_EXIT via GET BADI.

The blog New BAdI RSROA_VARIABLES_EXIT_BADI describes the manufacturing process of the BAdI‘s in the details.

1.5 Overriding input values

The basic principle for input-ready variables was initially that user entered values can not be overwritten. An input-ready variable is not processed by default after the variable dialog as a single variable.

In I_STEP = 3, the variable can indeed be validated but not be changed. If it is determined during validation that the user entered value is not meaningful, in the I_STEP = 3 is a message that the user generated informed. In addition, an exception will be thrown. The exception ensures that the variables dialog appears again.

With the introduction of the parameter E_CHECK_AGAIN (see Note 1272242 Renewed Variablenverprobung in I_STEP = 2), the concept was canceled. The parameter allows the developer to the user-entered value of an input-ready variables after the variable dialog in I_STEP = 2 to overwrite as needed.

As described in Section 1.2 processing steps (I_STEP)” input-ready variables only in I_TEP = 1 and I_STEP = 3 processed, the value only in I_STEP = 1 changes (initialiesiert) can be. To ensure that an input-ready variables in I_STEP = 2 is again processed must be in I_STEP = 1 for this variable is the export parameters E_CHECK_AGAIN (E_CHECK_AGAIN = X’) are set. If the parameter is set E_CHECK_AGAIN so this is ready for input variable is processed into a not ready for input variables in I_STEP = 2 analogous to the variables dialog.

You must be Logged on to comment or reply to a post.
  • Hi Torsten,

    A great and very detailed blog!

    I have a question to point 1.5 "Overriding Input Variables" - is it possible to include "E_CHECK_AGAIN = 'X'" in i_step = 3? I have two variables which are both input-ready. The entered value in VAR1 is checked in i_step = 3 - if the entered value is not valid according to a simple condition, the entered value for VAR2, should be overwritten in i_step = 2.


    • Hi,

      sorry for the delay.

      there is no way to get access to more than one variable and be alowe to change a value.

      Only step 3 provides all variable values but here you can not change any value. You're only able to step back to step 2.

      But try this workareound:

      Ensure in step 1 that for both variable the flag E_CHECK_AGAIN is set.

      Than both variale would be processed in step 2.

      Ensure that VAR1 would be processed before VAR2 (I'm not 100% sure but I blieve you can reach out this by the variable order in the dialog)

      Than store the result of your check in a static attribute of a ABAP class.

      Now if VAR2 would be processed you can check the attribute and set the value for VAR2 if necessary.


  • Hello Torsten,

    we have got an Input ready variable that we would like to validate. As far as we understand this should be possible in I_STEP 3.

    As seen in our debugging-process the process never gets to step 3.

    In another SCN-entry there was a short note, that STEP 3 is only executed for NON-Input ready variables.

    So we would like to ask you:

    is Validation of Input - ready variables possible in STEP3?

    + If YES, what to do to make the code execute STEP 3 as well?

    - If NO, is there a possibility to validate input-ready variables at all? Which one?

    Thx a lot for your help,


    • Hi,

      STEP 2 would only be called for non-Input ready variable.

      STEP_3 is responsible for all exit variable (input ready or not), it's the validation step.

      But you will not found your variable in the import parameter I_VNAM. In step 3 this parameter is always empty.

      Step 3 would called for all variables together. You will find them in the importing table parameter I_T_VAR_RANGE.

      Figure 1.7 shows the call order for the difference steps.

      To prepare the system step 3 would be called before the variable dialog comes up.

      Keep in mind that step 3 only would be called again after the variable dialog in case the value of at least one variable had been changed.

      Also ensure that your break point is an external break point or you'll use RSRT to test your query.



  • Hi Torsten,

    Good document !  Currently I am working on some time dependent master data selection scree variables and facing issues to determine the key date.

    Here it is :

    1. We have a fiscal year period variable - V1 in istep=1, this basically returns (current period -1 ) by default but it is input ready & can be changed by user.
    2. We have a key date variable - V2 which is filled in istep=2, which basically picks the last date of the period entered in fiscal year period variable V1.
    3. Now the issue is when the user tries to access the list of values (LOVs) from F4 help of time dependent master data in the input screen the key date is still not filled & probably picks the system date & in the master data the DATETO updated (validity) is always last day of previous period. So we get # values in prompt selection - LOVs for the attributes which are time dependent.

    So I need to determine the key date based on V1 within input screen before execution. I am planning to code V2 in istep=1 and probably handle the sequencing through variable sequence. Not sure if it will work, any ideas or suggestion will help :).


  • Hi Torsten and thanks for the great article!! I have one note and some questions in the context of authorizations.

    The note:

    In Figure 1.7. "i_step = 0" is depicted at the beginning of the preparation phase. For me it gets executed always at the very end and it seems t it is not part of the preparation but part of the validation phase.

    The questions (with some context):

    I want to develop a dynamic authorization concept, based on authorization table (1) and on user selection (2). The idea is, that different user groups use the same query and receive different authorizations based on their business roles. The authorizations of the business roles are maintained in the authorization table. So far so good.

    The crux is in one particular case, where the user should receive dynamically either full '*' or aggregation ':' authorizations, based on dynamic query selection.

    For example: We have a query with 3 InfoObjects (IO): SALES, COUNTRY, REVENUE. For both SALES and COUNTRY we have authorization objects filled with 2 customer exit variables. The authorization objects are not ready for input, as those should be filled in the customer exit, based on his authorizations.

    A sales representative in Germany should see the REVENUE and all SALES '*' for COUNTRY "Germany", thus in the initial query selection screen the user receives all 3 InfoObjects, filtered for Germany.

    When the user removes IO COUNTRY and IO SALES in the Query Navigation, the combined REVENUE for all COUNTRIES should be displayed, e.g. SALES and COUNTRY authorizations should be ':'.

    If the user wants to see all SALES without the country, nothing should be displayed for missing authorizations, SALES = ':'.

    If the user then takes again COUNTRY in the Query Navigation, the initial results should be displayed.

    Do You know, if this kind of dynamic authorizations is even possible?

    After the initial execution all STEPS 1, 2, 3 and 0 are processed in that order. This is the case, for we restrict the query selection based on COUNTRY in step 2. After every following user navigation, only i_step = 0 is executed. And as You have pointed out the execution works per variable, thus it is not always clear, which one will be processed first. Moreover, even if the processing of the variables can be controlled, i have not found a way to get the current selection of the user in the exit.









  • Hi Torsten,


    Can you tell me if we can call istep 1 and 2 both for a single variable which is not ready for input?

    We want to set a default value first and then dynamically populate also while query executes.


    Please check this below link.


    Also,is there a way we can set a variable as to it does not ask for a default value?


    Kindly help.




  • Hello Torsten,

    Can you please explain how can we implement i_step =1 with not ready for input variable.

    Is it the same process of implementing  i_step =1 with ready for input variable? Only difference it will not show the variable selection pop-up screen?




    • Why do you need an initialization for a  variable that is not shown in the user dialog?

      A "not ready for input" variable is not shown in the variable screen, therefore an initialization is not neccessry, or?

      I'm not sure but I assume you'll not stop in I_STEP = 1 for this kind of variable.


      I_STEP = 2 can be used to handle  "not ready for input" variables.

      Or is there a requirement that you can not handle in I_STEP=2?



  • Hello Torsten,

    I only need to show the result of the query for 0CALMONTH=current month+next 3 months, the value of the 0CALMONTH will be populated with my customer exit variable and I want the variable as not ready for input .variable values should be populated automatically by customer exit and does not require user input.

    I think in this case I need to use i_step =1 and variable should be not ready for input.Am I correct??




    • Hi,

      that's exactly the use case for I_STEP = 2.

      • Variable is not shown in the variable dialog and
      • no dependence to other variables


  • Hello Torsten,

    As per my understanding ,for I_step=2 we calculate value of a variable depending on the value of another variable.

    you have also showed an example of i_step=2 , the value of 0CALMONTH is derived based on the value of the variable ZTKE_MONTH.

    But here in my case, I think 1_step=1 should be used.



  • Hallo Torsten,

    would it be somehow possible to incorporate a validation of two variables in user exits before the OK button is pressed on the Variable entry in a query? To explain further, I have two Dates, DateFrom and Date To and what I would need is that right after I enter the DateFrom (lets say 1.1.2018) the DateTo would offer only Dates after 1.1.2018. As a testing scenario have I something like this: 
    IF loc_var_range-high > loc_var_range-low.
    RAISE no_processing.

    It works, but only after I enter all variables and press OK. Can you think about a way how to do this kind of check right then when I enter the DateTo (when possible with a message that the value for DateTo is wrong).



    • Hi,

      I left the topic some time ago, but as far as I remember there is no round trip  on a enter or leave event on a input field.

      But you can use the validate button to trigger a round trip.

      That means you can check this in STEP 3 and educate the customer to use the validate button.


  • Hi Torsten,


    Your document is very help full. Thanks for you, I have solved my problem about customer exit in BW/4HANA

    You are a Master!!



  • Hi Torsten,


    Very usefull information! Thank you. especially the part in the chapter about: Overriding input values. 


    Thanks again

  • Hi Torsten,

    Very well written blog and extremely helpful.

    Below is a scenario in which i am facing an issue with the variables exit:

    I have one workbook needs to show the KPI index trend for 12 months. Workbook structure details:

    The workbook calls ONE query 12 times in 12 different sheets with different month values.
    The user enters one month and the KPI index needs to be calculated for previous 12 months (inclusive of month entered).
    The first query call is made with the input month and then using the variables BADI we keep substracting 1 month for each subsequent query call.
    Ready for input variable - 1, Not-ready for input variable - 2

    In figure 1.7 you explained the call order of i_step. In Preparation phase, step 2 & 3 are getting called  ONCE.
    If the E_CHECK_AGAIN flag is switched ON, then in Preparation phase how many times is step 2 & 3 expected to be called?

    In our case E_CHECK_AGAIN flag is switched ON and in preparation phase, step 2 & 3 are called TWICE.
    -- In first cycle of step 2 & 3 calling step 2 is called 36 times (12 query calls * 3 variables) and step 3 is called 12 times (12 query calls).
    -- In second cycle of step 2 & 3 calling step 2 is called 33 times and step 3 is called 11 times owing to which counters set are not resetting correctly and therefore we are getting erroneous results. I expect the calls to be same as in the first cycle of step 2 & 3 calls.

    This does not seem to be expected behavior. Kindly share your views on the same.



    • Hi,

      I didn't work couple of years with queries ;-(

      So I'm not up to date with the current behavior here.

      Please post your question here


      • Thanks Torsten.

        Will do the needful.

        Additionally we are on SAP BW 7.4 SP6 which is an old version, so behaviour would not have changed much i guess.