The SET_DATA_EXIT method in NextTables for SAP BW

You will learn

What the SET_DATA_EXIT method of the Table Maintenance BAdI can do on the read path: tighten or widen the selection before the database is read, change values after it is read, or take the read over completely. It is also the reference for C_QUERY_POST, the structure that carries the query the user's filters produced.

This article is for ABAP developers. It covers reading data; writing it is the Update method, and the shape of the table is the Meta method.

Prerequisites

• A Table Maintenance BAdI implementation for your table. How to implement the table maintenance BAdI covers the enhancement spot, the implementing class and the filter values.
• ABAP development access on the BW system.

The two steps

The exit runs whenever values are requested from the database, and it runs twice per request. I_STEP tells you which pass you are in:

• I_STEP = 1, before the read. Change the selection in C_QUERY_POST-SELECT_OPTIONS, or set E_SKIP = 'X' to suppress the standard read entirely and fill CO_TABLE yourself.
• I_STEP = 2, after the read. CO_TABLE holds the rows that came back. Change values here to present them differently without changing what is stored.

Messages can be raised in both steps through CT_MESSAGES. See Error handling in the table maintenance BAdI for SAP BW.

Parameters

C_QUERY_POST

C_QUERY_POST groups every global query setting the Data method cares about: the requested fields, the sort order, the global filters and the select options from the user interface. Read it and change it in I_STEP = 1, before it is processed.

SELECT_OPTIONS

A table of type /NLY/TT_FIELD_SELECT_OPTIONS with line structure /NLY/TS_FIELD_SELECT_OPTIONS. It holds the global range filters in the classic ABAP select-options shape, so an ABAP developer can read and extend it without a translation step:

PARENT_SELECT_OPTIONS

In a master item scenario the item table is read in the context of a selected master row. PARENT_SELECT_OPTIONS, of type /NLY/TT_PARENT_SELECT_OPTIONS, carries that context:

The table can hold several rows, one per parent level. The mappings that matter may sit on a nested level rather than on level 0; that is expected as long as the level representing the driving master context supplies them.

MAPPINGS

MAPPINGS is more than join metadata. Each row of /NLY/TS_MAPPING is already a selection criterion that will restrict the item table from the selected master context:

Step-by-Step Instructions

1. Branch on the step

Split the method by I_STEP first. The two passes see different data and almost never share logic:

IF i_step = 1.
* your logic before the read access
ELSEIF i_step = 2.
* your logic after the read access
ENDIF.

2. Change the selection, or take the read over

In step 1, add or tighten entries in C_QUERY_POST-SELECT_OPTIONS to restrict what the user sees. To read the data yourself instead, set E_SKIP = 'X' in step 1 and fill CO_TABLE with your own result. Set C_TOTAL_ROWS as well in that case; nothing else knows how many rows your selection found.

3. Adjust values after the read

In step 2, loop CO_TABLE and change field values before they reach the user. This changes the presentation only. Nothing here is written back, so it is the wrong place to correct stored data.

4. Refuse the read when it should not happen, and say why

This example closes planning once the round is over. November is the cut-off: the exit skips the read and raises a toast, so the user sees a reason instead of an empty grid.

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       = 'The planning round is over, no values will be displayed' ) ).

  ENDIF.
ENDIF.

Troubleshooting / FAQs