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



原文链接：https://blogs.sap.com/2014/11/11/everything-you-always-wanted-to-know-about-the-processing-of-customer-exit-variables-but/

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

November 11, 2014
| 925 Views |

Torsten Kessler


The original blog can be found here:
ekessler.de

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 va
4000
riable 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 background–users.

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 Exit” the 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 entered”
I 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
report–result 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.

Alert Moderator

To report this post you need to
login first.

10 Replies

10 Comments

You must be
Logged on to comment or reply to a post.

Hareesh kumera
February 13, 2015 at 8:51 am

Good document

like
(0) 

Arseny Shilikhin
August 24, 2015 at 3:00 pm

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.

Thanks.

like
(0) 

Torsten
Kessler Post authorSeptember 24, 2015 at 10:12 am

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.

Torsten

like
(0) 

Shwetha Bangera
August 25, 2015 at 8:33 am

Very useful document! Thanks for the examples , they did help in easy understanding of the concepts

like
(0) 

Thomas Kejik
October 22, 2015 at 10:50 am

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,

Thomas

like
(0) 

Torsten
Kessler Post authorNovember 2, 2015 at 1:44 pm

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.

Regards

Torsten

like
(0) 

Dheeraj Lenka
October 13, 2016 at 1:09 am

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 :).

Cheers,

Dheeraj

like
(0) 

Ivan
Bakalov February 21, 2017 at 10:24 am

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.

 

 

 

 

 

 

 

 

like
(0) 

Torsten
Kessler Post authorFebruary 22, 2017 at 8:46 am

Hi Ivan,

I’m not the right/best expert for question related to authorization topics.

And I’d changed my focus a little bit ;-]

Therefore I would say it’s better to post your quest in the Questions & Answers area.

Sorry that I can not immediately help.

Torsten

like
(0) 

Ivan
Bakalov February 22, 2017 at 9:51 am

Thanks anyhow, for the quick response

Visual
Text

Paragraph

 

Insert/edit link

Close

Enter the destination URL
URL
Link Text

Open link in a new tab

Or link to existing content

Search

No search term specified. Showing recent items.Search or use up and down arrow keys to select an item.

Cancel