Table Maintenance - Data Method Explained

Using the DATA method, you can customize the select statement to be executed for the given table type and table name. Thus, you can adjust the values shown to the user.

Data shown your way

You can use this method to apply additional filter or check selected filters. You can also change field values read from database on the fly according to your business logic, before displaying them to the user. Furthermore, you could also implement your completely own read logic, skipping the standard read logic altogether.

The modification of the filter can be done in I_STEP 1 (before database access) using infos of parameter C_QUERY_POST-SELECT_OPTIONS. In order to implement your own read logic, set E_SKIP parameter to X in I_STEP 1 (before database access). In this case, no standard read logic is executed. Adjustment of field values before they are shown to the user can be done in I_STEP 2 (after database access), utilizing the values in table CO_TABLE. 

In both steps, you can pass messages using CT_MESSAGES table. You can find the explanation of I_STEPs below.

I_STEP explained

The BAdI is triggered, if values are requested from the database. In the I_STEP 1 you can change the selections before the actual READ access to the database is executed. Afterwards, the standard READ command is executed on the database level. You can skip this step by setting the parameter E_SKIP = ‘X’ in I_STEP 1. After the data is requested from the database, you can adjust certain field values or pass messages to the user.

Master-Item filter propagation
In Master Item scenarios, the framework derives additional item filters after the DATA exit I_STEP = 1 based on the parent context (C_QUERY_POST-PARENT_SELECT_OPTIONS) and its mapping information.
Therefore, it is expected that the derived Master Item filter is not yet visible in C_QUERY_POST-SELECT_OPTIONS while debugging inside I_STEP = 1.

Overview of all parameters

In the table below you can find an overview of all parameters and possible values.

C_QUERY_POST 

The parameter C_QUERY_POST groups all global query settings that are relevant for the Data Method. This includes selected fields, sorting, global filters and select-options from the NextTables UI. The content of C_QUERY_POST can be evaluated and modified in the Data Exit I_STEP = 1 before it is processed.

SELECT_OPTIONS

The field SELECT_OPTIONS in C_QUERY_POST is a table of type /NLY/TT_FIELD_SELECT_OPTIONS with line structure /NLY/TS_FIELD_SELECT_OPTIONS. It contains all global range-based filters in a form that is compatible with the classic ABAP SELECT-OPTIONS concept.

Read and modify C_QUERY_POST-SELECT_OPTIONS in I_STEP = 1 to inject additional filters or to tighten/relax existing conditions before the standard read logic is executed. 

PARENT_SELECT_OPTIONS

The field PARENT_SELECT_OPTIONS in C_QUERY_POST is a table of type /NLY/TT_PARENT_SELECT_OPTIONS with line structure /NLY/TS_PARENT_SELECT_OPTION. It contains select-options that are propagated from a parent (driving) entity to the current table, for example in master-detail scenarios.

Use PARENT_SELECT_OPTIONS when the table is read in a dependent context (e.g. detail table for a selected header). The mapping information can be used to translate parent filters to the child entity. 

How to interpret LEVEL and MAPPINGS (Master Item):
PARENT_SELECT_OPTIONS can contain multiple rows (LEVEL 0…n). Each row represents one parent context level that may contribute to the selection of the current table.
MAPPINGS contains the mapping definitions and the derived select-options that should be applied to the current table based on the selected parent row(s) and the configured Master Item mapping.
Depending on the setup, the relevant mappings may appear on a nested level (LEVEL > 0). This is expected as long as the level that represents the driving master context provides the required mappings.

MAPPINGS

MAPPINGS is not only “join metadata”. Each row of /NLY/TS_MAPPING already represents a field selection criterion that will be used to restrict the current table (item) based on the selected master context.

Code Snippet

You can use the following code snippet as orientation while implementing your own logic.

IF I_STEP = 1.*implement your logic before read access hereELSEIF I_STEP = 2.*implement your logic after read access hereENDIF.

 IF i_step = 1.  IF sy-datum+4(2) = '11'.   e_skip = 'X'.   ct_messages = VALUE #( BASE ct_messages                         ( type = /nly/cl_table_rest_v3=>co_msg_type_error                          visu_type = /nly/cl_table_rest_v3=>co_visu_type_toast                          hdr = 'Planning not allowed'                          msg = 'Planning round is over, no values will be displayed')                        ). ENDIF.   ENDIF.

Which License is needed for this feature Professional ✘ | Enterprise ✔