Input help (F4 values) for Bex queries on Calculation Views

In some cases, it is impossible to consume the result of a "Calculation View" directly in the reporting layer (Webi, Analysis for office, etc.). For licensing reasons, for example, we are obliged to use BW and a BEx request.

By respecting the "best practices" one should find an architecture of this type:

Major drawback The " D" input help reading mode is not supported.

For more details on the behaviour of the D-mode in the composite provider, please refer to the note 2094816.

As a reminder, here are the existing modes for listing the possible values of a Bex query prompt at runtime:

Mode M: the values in the master data tables (P, Q tables) are retrieved
Mode D: the values of the characteristics in the dimensions of the infoprovider are retrieved

Note: Q mode ("Values posted for browsing") is not valid for the user prompt selection screen. It is only valid for the filter walkthrough once the query result has been calculated.

In the architecture presented above, if mode M is not selected by default for a feature, it automatically replaces it when the query is executed.

Automatic conversion of input help mode at runtime

To get around this, we can implement the standard BAdI RSR_VARIABLE_F4_RESTRICT_BADI of the extension point RSR_VARIABLE_F4_RESTRICT (se19).

Architecture of the BAdI RSR_VARIABLE_F4_RESTRICT_BADI and a user implementation

In a few words, this BAdI allows to customise the list of input help values, it is composed of an interface with the following three methods:

GET_RESTRICTION_FLAT: restricts the values of variables to characteristic values
GET_RESTRICTION_NODE: restricts values of variables on hierarchy node
GET_RESTRICTION_HIERrestricts the values of the variables on the hierarchy
- Please note that it is not possible to restrict the display of hierarchies according to their name/ID but only according to their validity dates and version.

Methods of the class implementing the BAdI interface RSR_VARIABLE_F4_RESTRICT_BADI

Note: In order to trigger the execution of these methods, the 4XXX "InfoObject" or "field" to which the BEx variable refers must be present in the filter value list.

The variables on the ENTSO1 IO or the 4CP_DASS-GARDIEN field will trigger the execution of the BAdI methods

The principle is then broadly the same for each method. The developer must fill in different tables with the list of values he wants to propose to the user:

Table C_T_RANGE for FLAT
Table C_T_NODE for NODE
Tables C_T_DATE & C_T_VERSION for YESTERDAY.

The advantage of being on a hybrid architecture is that you can use the computational speed of the HANA DB to build up these data sets. For this, best practices recommend two methods:

ABAP CDS views. Their use depends on the choices made in terms of modelling the existing data. Indeed, CDS views are designed to produce data models in their own right, and it would be counterintuitive to mix several modelling methodologies (CDS view vs. HANA information view). For more information on CDS see https://www.bilinksolutions.com/blog-sap-hana/sap-hana-core-data-services/

AMDP classes. These are not designed to model but to provide the ABAP world with the computing power of HANA by allowing the execution of database functions and procedures. The objects in the ABAP data dictionary (tables or views) as well as the HANA view information are accessible to it. This makes it the right object for our case, regardless of the modelling technology.

These two objects have the advantage of being easily manipulated via ABAP instructions and at the same time benefiting from "push down" code. This means that heavy processing (select etc.) can be delegated to the database.

Note: A third technique is to use " external views ". Like ABAP CDS views, these allow views to be created in the ABAP data dictionary, but executed via an "information view" and not via CDS code.

On paper the functionality looks interesting but is nevertheless not recommended by SAP as it is specific to HANA XSC objects (developments on SAP HANA Studio), and will be obsolete during a HANA XSA migration (developments on SAP Web IDE).

Moreover, external views are not able to manage the input parameters of the information views from which they are derived. This makes them less efficient candidates than a CDS view or an AMDP if one wishes to develop cascading filters, for example.

The concept of cascading filters is well explained on this blog: https://sapinsider.wispubs.com/Assets/Articles/2017/September/SPJ-Cascading-Prompts-The-Next-Generation-of-F4-Value-Help-Filtering

Putting it into practice

BAdI side

We propose below a way of understanding the use of the BAdI RSR_VARIABLE_F4_RESTRICT_BADI with AMDP for database querying.

Our architecture is designed around an abstract master class. Each new variable (which must restrict its input help) will have to be matched by a subclass which will inherit its properties.

Solution architecture

The advantage is that you can declare an object with reference to the master class and instantiate it dynamically according to the name of the variable.

Example for the FLAT method:

METHOD IF_RSR_VARIABLE_F4_RESTRICT~GET_RESTRICTION_FLAT.

data lv_classname type c length 30.

Declaration of an object with reference to the master class

data lr_instance type ref to ZCL_RESTRICT_VAR_MASTER.

*Constructing the dynamic typing of instantiation

concatenate ZCL_' i_vnam into lv_classname.

translate lv_classname to upper case.

try.

*Instantiation as a class (ZCL_Variable_Name)

create object lr_instance type (lv_classname)

exporting " Calling the constructor
i_src = 'FLAT' " Identifies type of variable
i_vnam = i_vnam " Name of the variable
i_iobjnm = i_iobjnm " Name of the infoObject
i_t_var_range = i_t_var_range " Values of the prompts entered
i_t_compid = i_t_compid. "Query that initiated the call

call method lr_instance->process_subclass
importing e_result_flat = c_t_range.

If the class does not exist, the "CX_SY_CREATE_OBJECT_ERROR" exception is thrown.
The handling of this exception is essential to avoid system errors.

catch CX_SY_CREATE_OBJECT_ERROR.
endtry.

free lr_instance.

ENDMETHOD.

Framework specific

Regarding our master class, it is defined as abstract (only its children must be instantiated) and implements the "if_amdp_marker_hdb" interface (allowing the use of AMDP methods to it and its children).

For each new variable to be restricted, the aim is to simplify the tasks to be performed as much as possible. To do this, all the methods to be called are defined in the master class, and each subclass will redefine only the bare minimum.

Global view of the master class and a subclass

Only the "SET_QUERYLIST" and "GET_LISTF4" methods need to be processed specifically for each variable.

Conclusion

Once this mini Framework is in place, this solution allows a simple and efficient use of the input restriction functionalities. Duplicating an existing subclass makes it very quick to take into account a new variable and requires almost no ABAP knowledge.

Below is an example of a subclass to be completed by a developer:

class ZCL_NAME_VARIABLE definition public

inheriting from zcl_restrict_var_master

create public.

protected section.

methods get_list_f4 redefinition.

methods set_querylist redefinition.

ENDCLASS.

CLASS ZCL_VARIABLE_NAME IMPLEMENTATION.

method set_querylist.

"List of eligible requests for value restriction

data: ls_compid type ts_compid.

ls_compid = TECH_NAME_QUERY_1.

append ls_compid to e_t_compid.

ls_compid = N_TECH_NAME'..

append ls_compid to e_t_compid.

endmethod.

method get_list_f4 by database procedure for hdb language sqlscript.

/* To be filled in only if the variable is of type "characteristic value" */

e_result_flat = select " as iobjnm,

" as sign,

" as an option,

" as low,

" as high

from dummy;

/* To be filled in only if the variable is of type "Hierarchy node" */

e_result_node = select " as NODENAME,

" as NIOBJNM