Performance Risks in User Exits

Explanation

User exits often run during critical transactions such as sales order save, delivery save or billing creation. A small performance mistake can affect many users. SELECT inside LOOP, repeated configuration reads, broad selects and synchronous RFC calls are common problems. If item-level data needs enrichment, collect unique keys first, select data once and use hashed or sorted internal tables for lookup. Performance should be tested with realistic orders, deliveries or billing documents, not just one small test document.

Code example

* Bad pattern:* SELECT inside item loop during sales order save.* This can make VA01/VA02 slow for large orders. LOOP AT xvbap ASSIGNING FIELD-SYMBOL(<ls_item>).   SELECT SINGLE mtart    FROM mara    INTO @DATA(lv_mtart)    WHERE matnr = @<ls_item>-matnr. ENDLOOP. * Better pattern:* Build unique material list, read once, then use lookup. DATA lt_matnr TYPE SORTED TABLE OF matnr WITH UNIQUE KEY table_line. LOOP AT xvbap ASSIGNING <ls_item>.  INSERT <ls_item>-matnr INTO TABLE lt_matnr.ENDLOOP. IF lt_matnr IS NOT INITIAL.  SELECT matnr, mtart    FROM mara    INTO TABLE @DATA(lt_mara)    FOR ALL ENTRIES IN @lt_matnr    WHERE matnr = @lt_matnr-table_line.ENDIF. DATA lt_mara_hash TYPE HASHED TABLE OF mara WITH UNIQUE KEY matnr.lt_mara_hash = CORRESPONDING #( lt_mara ).

Real project scenario

A sales order exit reads MARA for every item. Large orders become slow. The fix is to collect unique materials, read MARA once and use hashed table lookup.

Common mistakes

- SELECT inside item loop. - Calling slow RFC during save. - Reading the same config repeatedly. - Testing only small data volume.

Best practices

- Avoid repeated database reads. - Use driver tables. - Use hashed lookup. - Measure with realistic volume. - Keep save exits fast.

Interview angle

A strong answer should mention critical save flow, repeated execution and preload/lookup optimization.