SAP ABAP Realtime (Scenario based) Interview Questions (1 - 10)
1. In a report, users complain about slow performance when fetching data from large tables. How would you optimize it?
First, I would check whether the program is selecting only the required fields and only the required records. In real projects, performance issues usually come from SELECT *, missing WHERE conditions, nested database calls, or reading unnecessary data. I would also use ST05, SAT/SE30, and check whether proper indexes are being used.
* Bad
SELECT * FROM mara INTO TABLE lt_mara.
* Better
SELECT matnr mtart matkl
FROM mara
INTO TABLE lt_mara
WHERE mtart = 'FERT'.In interview, you can say: “My first step is to reduce database load, then remove unnecessary loops, and finally trace the SQL using ST05.”
2. You need to fetch data from multiple tables like MARA, MARC, and MARD. How would you design the SELECT logic efficiently?
I would first understand the relationship between the tables and fetch only the data I really need. If the join is simple and the data volume is manageable, I would prefer a single JOIN instead of multiple selects, because it reduces database round trips. If the logic is complex, I may split it into steps, but I avoid nested SELECT inside loops.
* Bad
SELECT * FROM mara INTO TABLE lt_mara.
* Better
SELECT matnr mtart matkl
FROM mara
INTO TABLE lt_mara
WHERE mtart = 'FERT'.In interview, you can say: “I prefer JOIN when possible, but I also check if it causes too much data duplication.”
3. A report is timing out in production but works fine in development. How will you analyze and fix it?
This usually happens because production has much larger data volume than development. I would compare selection inputs, check database statistics, trace the SQL in ST05, and see whether the code is doing full table scans or unnecessary repeated reads.
* Avoid broad selection
SELECT matnr ersda
FROM mara
INTO TABLE lt_mara
WHERE ersda BETWEEN p_date1 AND p_date2.In interview, you can say: “I never trust DEV performance alone; I always think about production data volume.”
4. You are asked to improve the performance of nested SELECT statements. What approach will you take?
Nested SELECT is one of the most common real-time performance issues in ABAP. Instead of selecting inside a loop, I would first collect all keys, then fetch related data in one shot using FOR ALL ENTRIES or a proper JOIN. This reduces thousands of database hits into one or two database calls.
* Bad
LOOP AT lt_vbak INTO DATA(ls_vbak).
SELECT * FROM vbap
INTO TABLE lt_vbap
WHERE vbeln = ls_vbak-vbeln.
ENDLOOP.
* Better
SELECT * FROM vbap
INTO TABLE lt_vbap
FOR ALL ENTRIES IN lt_vbak
WHERE vbeln = lt_vbak-vbeln.Always mention that FOR ALL ENTRIES should not be used when the driving internal table is empty.
5. How would you handle duplicate records while fetching data from database tables?
If duplicates are possible because of joins or business data, I would decide whether to remove them at database level or ABAP level.
If possible, I use DISTINCT, but sometimes I fetch the data and then sort and delete duplicates based on business keys.
SELECT DISTINCT matnr
FROM mara
INTO TABLE lt_matnr
WHERE mtart = 'ROH'.
SORT lt_matnr BY matnr.
DELETE ADJACENT DUPLICATES FROM lt_matnr COMPARING matnr.In interview, you can say: “I choose the duplicate-removal method based on performance and business requirement.”
6. You need to display a large dataset in ALV with better performance. What techniques will you use?
For large ALV reports, I avoid loading unnecessary records and I use proper selection filters. I also fetch only required columns, avoid heavy calculations inside loops, and do formatting only after data retrieval. If the dataset is huge, I may also add selection restrictions or pagination-like logic based on business needs.
SELECT vbeln erdat auart vkorg
FROM vbak
INTO TABLE lt_vbak
WHERE erdat BETWEEN p_date1 AND p_date2.In real interviews, mentioning “restrict data before ALV, not after ALV” gives a strong practical impression.
>7. A user wants dynamic selection screen fields based on input. How will you implement it?
This is usually done using AT SELECTION-SCREEN OUTPUT and modifying screen fields dynamically.
For example, if a checkbox is selected, I can enable or disable some fields.
This is very common in real reports where users want one screen to behave differently for different options.
In interview, you can say: “I use AT SELECTION-SCREEN OUTPUT for dynamic UI behavior.”
8. You need to validate user input in selection screen before execution. How will you do it?
In a real-time report, validation should happen before the program starts heavy processing.
I use AT SELECTION-SCREEN to check whether the input is valid, mandatory, or logically correct.
If something is wrong, I raise an error message so the user corrects it immediately.
PARAMETERS: p_matnr TYPE matnr.
AT SELECTION-SCREEN.
IF p_matnr IS INITIAL.
MESSAGE 'Material is mandatory' TYPE 'E'.
ENDIF.9. A report needs to run differently for different user roles. How will you handle authorization checks?
In real projects, I never depend only on front-end hiding logic. I use AUTHORITY-CHECK in the program to control what the user can see or do based on authorization objects. This makes the logic secure even if someone tries to run the program directly.
AUTHORITY-CHECK OBJECT 'M_MATE_WRK'
ID 'ACTVT' FIELD '03'
ID 'WERKS' FIELD p_werks.
IF sy-subrc <> 0.
MESSAGE 'You are not authorized for this plant' TYPE 'E'.
ENDIF.In interview, you can say: “UI restriction is not enough; backend authorization check is mandatory.”
10. You need to schedule a report to run in background daily. What steps will you follow?
I first make sure the report works properly in foreground and handles spool/output correctly. Then I schedule it using SM36, define the variant, choose the execution time, and monitor it in SM37.
IF sy-batch = 'X'.
WRITE: / 'Running in background job'.
ENDIF.In interview, mention SM36 for scheduling and SM37 for monitoring, because that shows practical exposure.