Performance and Database Access in BAdIs
Avoid performance problems caused by heavy logic inside BAdI methods.
Explanation
BAdIs are often called inside standard transaction processing. If a BAdI runs during save, item processing, pricing, output or posting, bad code can slow down business users and background jobs. SELECT inside LOOP, broad SELECTs, slow RFC calls and repeated configuration reads can create serious performance problems. The solution is to reduce database calls, cache configuration where safe, build driver tables, use internal table lookups and keep BAdI logic focused. Performance should be measured with ST05 or SAT when the BAdI is called frequently.
Code example
* Bad pattern inside BAdI:* SELECT inside item loop can slow down SAVE processing. LOOP AT it_item INTO DATA(ls_item). SELECT SINGLE name1 FROM lfa1 INTO @DATA(lv_name1) WHERE lifnr = @ls_item-lifnr. ENDLOOP. * Better pattern:* Build unique vendor list first and read database once. DATA lt_lifnr TYPE SORTED TABLE OF lifnr WITH UNIQUE KEY table_line. LOOP AT it_item INTO ls_item. INSERT ls_item-lifnr INTO TABLE lt_lifnr.ENDLOOP. IF lt_lifnr IS NOT INITIAL. SELECT lifnr, name1 FROM lfa1 INTO TABLE @DATA(lt_lfa1) FOR ALL ENTRIES IN @lt_lifnr WHERE lifnr = @lt_lifnr-table_line.ENDIF. * Convert result into hashed table for fast lookup inside later processingDATA lt_lfa1_hash TYPE HASHED TABLE OF lfa1 WITH UNIQUE KEY lifnr.lt_lfa1_hash = CORRESPONDING #( lt_lfa1 ).Real project scenario
A purchase order BAdI reads vendor master data inside an item loop. For large POs, save becomes slow. The fix is to read required vendors once and use a hashed lookup table.
Common mistakes
- SELECT inside BAdI item loop. - Calling RFC synchronously during save. - Reading same configuration again and again. - Not measuring performance with real volume.
Best practices
- Avoid repeated database reads. - Use driver tables and hashed lookups. - Cache configuration carefully. - Measure impact with ST05 or SAT.
Interview angle
A strong answer should mention that BAdIs can run in critical paths, so database access must be controlled.