RSROA_VARIABLES_EXIT BAdI logs previous Input Variable values when prompt is changed.

[#1]

Hello, Experts.

I implemented custom logging in RSROA_VARIABLES_EXIT to store Input Variable values from I_T_VAR_RANGE into a Z table.

The issue occurs when a user changes a variable value within the same session. For example:

• First execution: user enters A → log = A
• User clicks "Change Variables"
• User changes the value from A to B
• Second execution generates two additional log entries: A and B

As a result, the log history becomes:

A → A → B

instead of the expected:

A → B

During debugging, I found that the BAdI is triggered when the user opens the variable screen, before the new value is confirmed. At that moment, I_T_VAR_RANGE still contains the previous value (A), which is logged again. After the user confirms the new value, the BAdI is called once more and the new value (B) is logged.

My questions are:

• Is this standard behavior of RSROA_VARIABLES_EXIT?
• Is there a reliable way to distinguish between opening the variable screen and confirming variable values?
• Has anyone experienced the same behavior when implementing Input Variable audit logging, especially in Analysis Office?

Any suggestions or best practices would be appreciated. Thanks.

[AleAPassarelli · Accepted solution]

Hi,

Yes, it's standard. I read the caller in an S/4HANA 2023 system (embedded BW, function group RRS0). The BAdI is reached through function module RRS_VAR_EXIT from three places, one per step:

• I_STEP = 1, in RRS_VAR_VALUES_EXIT_BEFORE (include LRRS0U02): before the variable screen opens. I_T_VAR_RANGE is built from the variable values the session already holds, so after "Change Variables" you get A again. That's your extra A.
• I_STEP = 2, in RRS_VAR_VALUES_EXIT_AFTER (LRRS0U07): after the screen, only for customer exit variables.
• I_STEP = 3, in RRS_VAR_VALUES_EXIT_CHECK (LRRS0U10): after the user confirms. It's one call, with I_VNAM and I_IOBJNM empty, and I_T_VAR_RANGE has every variable of the query with the confirmed values, the input-ready ones included.

So the reliable way to tell "screen opened" from "values confirmed" is I_STEP: write the log only in step 3. Then you get A, then B.

Two things that can bite:

1. RRS_VAR_EXIT (LRRS0U01) does GET BADI ... FILTERS iobjnm = i_iobjnm. In step 3 IOBJNM is empty, so an implementation filtered on one InfoObject never gets that call. The logging has to sit in an implementation whose filter accepts an empty IOBJNM.
2. If something in step 3 raises an error, RRS_VAR_VALUES_EXIT_CHECK raises AGAIN, and step 3 runs again on the next confirm. A rejected attempt then lands in your log too. Decide if you want that.

For a query on a CDS view, RRS_VAR_VALUES_EXIT_CHECK takes another branch (RSRTS_CDS_VAR_CHECK). I didn't follow that one.

I read all this in the code. I didn't run a query in Analysis Office, so I haven't seen the call sequence there.

[dongun-kang · Accepted solution]

It helped me greatly in understanding the call flow of RSROA_VARIABLES_EXIT_BADI. However, even when processing only at STEP = 3, the previous prompt values are still being logged. (In Analysis Office) I resolved this issue with an internal table in the private section and comparing the current data with the data from the previous sequence within the same session. If the data is identical, the log is not written. Your assistance was very helpful in solving the problem. Thank you.