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.

Overview of all parameters

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

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.

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. 

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. 

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 here
ELSEIF I_STEP = 2.
*implement your logic after read access here
ENDIF.

 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 ✔