Settings for Customer Exit Variables

To support the documentation/analysis of Customer Exit Variables some settings regarding how the coding is implemented need to be set.

These settings will be saved regardless of the settings variants.

Supported Implementation Types

The implementation types can be customized in "Settings" > "Business Warehouse" > "Customer Exit Variables":

1. The code is maintained directly in Include ZXRSRU01 (or in other Includes that are called directly from ZXRSRU01) or BAdI (RSROA_VARIABLES_EXIT_BADI)

2. The code is encapsulated in Function Modules

3. The code is encapsulated in Classes/Methods

In case of two and three, the name of the Class/Method or Function Module per Variable is derived from a mapping table or the Variable's technical name. In variant three it is also supported to use a fixed Class name and the code for each Variable is stored in the respective Methods.

If all three checkboxes are ticked, all three ways are executed to find the coding of the Variable. So in case, you use different ways of implementation please tick several boxes. However, please be aware that as soon as Customer Exit Coding is found, the further search will be terminated!

Please contact support@bluetellience.de in case you are using other implementations that are not supported by the Performer Suite yet. 

Settings for implementations using Include ZXRSU01 or BAdI

In case the coding is maintained directly in the Include ZXRSRU01 or BAdI , there are the following options:

Include ZXRSU01

• First nested includes are identified by parsing the code of ZXRSU01.

• Finally, the coding of all identified includes is read and checked to see whether customer exit variables occur.

BAdI

• First, the Performer Suite determines Classes that inherit the IF_RSROA_VARIABLES_EXIT_BADI interface

• Next, the Methods are identified based on the Class name

• In the last step, the coding of the identified Methods is read and checked to see whether customer exit variables occur.

Settings for implementations using Function Modules

In case the coding is encapsulated in Function Modules, there are the following options:

First, the name of the function modules must be determined. For this, we have two options:

• “Derivce Function Module name from Mapping Table”
  --> The name will be fetched from the provided mapping table: Select <field for function module name> from <mapping table> where <field for variable name>='<the name of variable>' [and <add. sel. criteria>]

• “Derivce Function Module name from Variable tech. name”
  --> Function Module name = Provided prefix + <name of the variable> + provided suffix

In the next steps, the code of the identified Function Modules will be parsed and the coding of the respective Customer Exit Variable will be returned.

For more information regarding the parsing logic, please refer to the last chapter “Logic of Code Parsing”.

Settings for implementations using Classes/Methods 

In case the coding is encapsulated in Classes/Methods, there are the following options:

First, the name of the class is determined. For this, we have three options:

• “Single Class Implementation”:
  --> Name of Class = <class name> and the method name = prefix + <name of the variable> + suffix.

• “Derivce Class Name from Variable tech. Name”:
  --> Name of Class = provided prefix + <name of the variable> + provided suffix

• “Derivce Class Name from Mapping Table”:
  --> The name will be fetched from the provided mapping table: Select <field for class name> from <mapping table> where <field for variable name>='<the name of variable>' [and <add. sel. criteria>]

If the class name was derived from the name of the variable or a mapping table, then you need to give the Performer Suite information to determine the name of the respective methods:

• “All steps are treated in one common Method”:
  --> The common method name will be used

• “Every step is treated in a separate Method”:
  --> The list of the separate methods will be used for each step

Next, the coding of the Class and Method will be parsed and the coding of the Customer Exit Variable will be returned.

For more information regarding the parsing logic, please refer to the last chapter “Logic of Code Parsing”.

Customer Exit Coding in Performer Suite

If the correct implementation option has been selected and set up correctly, the Performer Suite shows the coding in analysis functions and the documentation:

Analysis Functions

The Customer Exit Coding can be opened and displayed via the context menu of a Variable - here are two examples:

Entity Grid:

Variable Analyzer:

Documentation Functions

The coding of the customer exit variable can also be integrated into the documentation.

In the settings, it is possible to specify which sections of the coding should be displayed for customer exit variables:

There are two settings for this in the Query documentation:

• Documentation of Variables within a Query

• Documentation of Variables standalone (out of Query context)

Show entire coding option

The Performer Suite identifies the steps of the coding for Customer Exit Variables and displays the code step by step and only the code that is done in these steps.
With the setting Show entire coding, you can see the entire coding of the Customer Exit Variable. In the screenshot below you can see the difference. The left screenshot shows the coding with the setting Show entire coding, on the right screenshot you can see the coding without this setting.

Logic of Code Parsing

The parsing logic is described in detail in the section below: