ALV Events and User Commands

Explanation

ALV events allow reports to react to user actions such as double-click, hotspot click, toolbar button, data change or user command. In classic ALV, callbacks are often used. In object-oriented ALV, handler classes are preferred. Event handlers should remain lightweight. They should identify the user action and delegate business processing to separate methods or service classes. Putting heavy business logic directly inside event handlers makes the report hard to maintain and test.

Code example

* Purpose:* Handle ALV double-click event in a clean way.* The event handler should capture the user action and delegate real work. CLASS lcl_event_handler DEFINITION.  PUBLIC SECTION.    METHODS on_double_click      FOR EVENT double_click OF cl_gui_alv_grid      IMPORTING e_row e_column.ENDCLASS. CLASS lcl_event_handler IMPLEMENTATION.  METHOD on_double_click.     * Read selected ALV row using row index from event    READ TABLE gt_output INTO DATA(ls_output) INDEX e_row-index.     IF sy-subrc = 0.      * Keep event handler lightweight.      * Delegate navigation/business logic to another routine/method.      PERFORM navigate_to_detail USING ls_output-vbeln.    ENDIF.   ENDMETHOD.ENDCLASS.

Real project scenario

A logistics cockpit has a custom button 'Block Delivery'. When the user selects deliveries and clicks the button, the ALV event handler validates selection and calls a delivery block service class.

Common mistakes

- Putting full business logic inside event handler. - Not checking selected row. - Not handling authorization before action. - Creating custom buttons without clear business purpose.

Best practices

- Use event handler to capture action only. - Delegate processing to methods/classes. - Validate selected rows. - Handle authorization before update/navigation.

Interview angle

Senior candidates should explain ALV event flow and why event handlers should delegate business logic.