How to change the “Processing by” property of already used BEx Variable

[Former Member]

1. Description

This document describes non-standard way to change the “Processing by” property of BEx Variable that is already defined and used by BEx (Business Explorer) Query. When you initially create and save Variable in BEx, you cannot change its “Processing by” property any more – at least not via BEx Query Designer. If you do not use respective Variable in any Query, than simple solution would be to delete it and to create new one, which includes new processing properties. However, in most cases the “Processing by” property of already used Variable needs to be changed. This document describes workaround how to perform such change in simple and fast way. However, this document does not provide any code for “Customer Exit” Variable - only the workaround on how to perform quick switch.

2. Business Scenario

You created several reports, such as for logistics and suppliers that contain filtering possibilities on Article. Business users that have access to information about defined set of articles use those reports to evaluate the state of business for specific suppliers. Until today, they needed to type in a list of articles when executing report to make evaluation, and this functionality was enabled by using BEx Variable with “Processing by” option “Manual Input/Default Value”. However, business processes in your company evaluated, and you received a new requirement for “dynamic article filtering” during report execution. In this case, user access rights and settings must be relevant for dynamic article filtering during report execution. This functionality must be implemented in every report that uses existing Variable.

You know you can fulfil this requirement by using “Customer Exit” instead “Manual Input/Default Value” Variable in your Query. However, when you tried to change your “Manual Input/Default Value” Variable by using BEx, you will notice that there is no possibility to change “Processing by” property. You are also in no possibility to delete respective variable as it has been used by many other similar reports.

3. Solution

There are two ways to handle situations like this one.

Creating a new “Customer Exit” Variable
(Standard BEx approach)

Identify every report and relevant query that uses existing “Manual Input/Default Value” Variable. Then, create a new “Customer Exit” Variable for Article with wanted functionality. Further step would be to exchange existing “Manual Input/Default Value” Variable with the newly created “Customer Exit” Variable in every query for identified reports. At the end, you could remove old “Manual Input/Default Value” Variable from every identified and updated query.

In this case, we have to consider several factors, which could be disadvantageous:

• First, we have to identify every query that uses variable, and then, we have to identify the position of variable used: is this in the main filter, is this a filter on specific key-figure, etc. This could be quite problematic when there are numerous queries or reports using Variable;
• Depending on the number of reports using Variable, the action of exchanging variables can be extremely time consuming;
• If used, you have to update relevant Enterprise Data Catalogues regarding newly created “Customer Exit” Variable as it has different technical name;
• Depending on the number of reports that use queries that contain respective Variable, you will have to be extremely careful with transports to Quality Assurance and Production System. This can be time consuming as well;
• Returning to the old state in the case of problems with new “Customer Exit” Variable can be complicated and time consuming as well;
• Depending on the number of queries to be changed, there are always numerous potential problems not covered in this document;

Change of “Processing by“ from “Manual Input/Default Value” to “Customer Exit”
(New unconventional approach)

This option includes changing “Processing by” property of Variable from “Manual Input/Default Value” to “Customer Exit”. It is fast and simple way to make change and has numerous advantages:

• Change is quite fast;
• In the case of the problems with newly created “Customer Exit” variable, it allows almost immediate back to the old state;
• There is no need to identify relevant queries, or objects in queries that use this variable for the purpose of change;
• There is no need to change existing queries;
• The number of exiting queries or reports that use respective Variable is irrelevant;
• It is way less time consuming that the first solution;
• And because of its simplicity it less suitable for possible problems;

So, as assumed and written above, in this document we explain second solution step-by-step.

You initially created “Manual Input/Default Value” Variable on Article InfoObject to enable manual filtering.

Therefore, you made numerous restrictions in queries on Article InfoObject with that Variable.

Now want to change the property “Processing by” for your existing variable from “Manual Input/Default Value” to “Customer Exit”. However, you notice, this is not possible with BEx, as by default, BEx does not allow to make such changes.

To make wanted change fast and easy, you first go to the table that holds information about existing variables in your system. First, use Transaction SE16 to go in table selection environment.

Then, type the RSZGLOBV in Table Name text field and click “Table Contents – F7” button - .

You will have a possibility to filter the content of variables information holding table. At this step, you should filter “VNAM” text field with the name of your variable. In our case, it’s “Z_EXAMPLE_VAR”.

Result set returns available information about respective variable. Initially, there are two records for our variable, on has object version “A” (Active) and one with version “M” (Modified).

As we see, our variable “Z_EXAMPLE_VAR” (field “VNAM”) has value “5” in the field that represent Processing Type for variable (VPROCTP).

Detailed description of this field (VPROCTP) shows us that number 5 represents „Manual Input/Default Value“  variable processing type and that we need to make changes in this to number 3 that represents „Customer Exit“.

We can do that, by using possibilities of “SQL Editor” that can be accessed with DBACOCKPIT Transaction.

After we execute DBACOCKPIT Transaction, we have a possibility to select “SQL Editor” in “Diagnostics” Folder of available tools.

We write a simple update SQL query in “SQL Editor” to make wanted changes in RSZGLOBV table.

In our case, SQL statement looks like:

UPDATE RSZGLOBV
SET VPROCTP = 3
WHERE VNAM = ‘Z_EXAMPLE_VAR’

After SQL statement execution, we can check our results in RSZGLOBV table. As we see, the values for VPROCTP fields are now 3 instead of 5 for variable “Z_EXAMPLE_VAR”.

And, if we open our variable by using BEx, we will see that the “Processing by” property has changed to “Customer Exit”. Now, you can write respective code for your customer exit variable that would enable dynamic article filtering.