SAP ABAP Developer interview questions and answers

There are three. A standard table has a non-unique key and keeps rows in the order you add them; reading by key is a linear search unless you sort it and use READ TABLE ... BINARY SEARCH. A sorted table is always kept in key order, its key can be unique or non-unique, and reads by key use a binary search automatically. A hashed table must have a unique key and finds a row by hashing it, so a read takes about the same time however large the table is, but you can't access it by index.

Use standard tables for small lists or data you process in sequence, sorted tables for range and partial-key reads, and hashed tables for large lookups by full key, such as material data read inside a loop.

The main ones are subroutines (FORM and PERFORM), function modules, and methods of classes. Include programs split source code into parts but don't modularise logic, and macros exist but are hard to debug, so avoid them. Subroutines are obsolete for new code; SAP recommends methods.

Function modules belong to a function group, are created in SE37, and have a clear interface of importing, exporting, changing and tables parameters with exceptions. You still need them where the technology requires one: a remote-enabled function module for RFC calls from another system, an update function module that runs in the update task, and BAPIs, which are function modules. For new business logic, use classes and methods, which ABAP Unit can test.

With LOOP AT lt_orders INTO ls_order, each row is copied into the work area ls_order. To change the table you change the work area and then MODIFY the table. With LOOP AT lt_orders ASSIGNING <ls_order>, the field symbol points directly at the row inside the table, so nothing is copied and any change you make goes straight into the table without MODIFY.

Field symbols are faster for wide rows and large tables, and they're the usual choice when you update rows in a loop; REFERENCE INTO a data reference behaves similarly. Header lines, from the old OCCURS style, are obsolete and not allowed in classes, so don't use them in new code.

A SELECT inside a loop sends one database call per row, so 50,000 rows means 50,000 round trips. Read the data before the loop instead: one SELECT with a JOIN, or SELECT ... FOR ALL ENTRIES IN lt_orders WHERE vbeln = lt_orders-vbeln into a second table. Then read that table inside the loop as a sorted or hashed table, not a standard table searched line by line.

FOR ALL ENTRIES has two traps. If the driver table is empty, the WHERE condition is ignored and every row is selected, so always check IF lt_orders IS NOT INITIAL first. And it removes duplicate result rows, so select all key fields or you may lose rows. Measure the improvement with ST05 or SAT.

Inline declarations, such as SELECT ... INTO TABLE @DATA(lt_mara) and LOOP AT lt_mara ASSIGNING FIELD-SYMBOL(<ls_mara>), remove separate DATA statements. Constructor expressions build values in one line: VALUE for tables and structures, NEW for objects, CONV for conversions, and COND or SWITCH for conditions. String templates between | characters replace CONCATENATE, and table expressions such as lt_mara[ matnr = lv_matnr ] read a row directly.

The catch: a table expression raises CX_SY_ITAB_LINE_NOT_FOUND if no row matches, so check with line_exists( ) first, catch the exception, or use VALUE #( lt_mara[ matnr = lv_matnr ] OPTIONAL ). In the new Open SQL syntax, host variables are escaped with @. Interviewers often ask you to rewrite an old loop in the new style.

LOAD-OF-PROGRAM runs first, when the program is loaded. INITIALIZATION runs before the selection screen appears and sets defaults, such as today's date. AT SELECTION-SCREEN OUTPUT runs just before the screen is displayed, to change it, and AT SELECTION-SCREEN runs after the user presses Execute, to validate the input. START-OF-SELECTION is where the main data reading happens, followed by END-OF-SELECTION. TOP-OF-PAGE and END-OF-PAGE handle list headers and footers.

In an interactive report, AT LINE-SELECTION and AT USER-COMMAND react to the user's clicks and buttons and create secondary lists. Mention that code written without any event keyword belongs to START-OF-SELECTION by default.

PARAMETERS creates a single input field for one value, such as a company code. SELECT-OPTIONS creates a range input with From and To fields and a multiple-selection button, so the user can enter single values, ranges, exclusions and patterns.

Behind SELECT-OPTIONS is a selection table with four columns: SIGN (I to include, E to exclude), OPTION (EQ, BT, CP, GT and so on), LOW and HIGH. You use it in a query as WHERE vbeln IN s_vbeln. An important point: if a SELECT-OPTIONS field is left empty, the IN condition is true for every row, so all data is selected, while an empty parameter compares with an initial value. Make essential fields OBLIGATORY.

The older way is the function module REUSE_ALV_GRID_DISPLAY with a field catalogue: quick, but procedural, and the class-based options are preferred for new work. CL_SALV_TABLE uses a factory method and builds the field catalogue from the internal table, so a full-screen ALV takes a few lines; it's the best choice for display-only reports, but it doesn't support editing cells as standard. CL_GUI_ALV_GRID needs a screen with a custom or docking container, more code and a field catalogue, but gives full control: editable cells, data-change events and toolbar buttons.

So for an editable report I'd use CL_GUI_ALV_GRID, and handle the DATA_CHANGED event to validate the user's entries before saving.

Give the field a MODIF ID, such as gr1, and control it in AT SELECTION-SCREEN OUTPUT: LOOP AT SCREEN, check screen-group1 = 'GR1', set screen-active to 0 to hide it or 1 to show it, then MODIFY SCREEN. Add USER-COMMAND to the radio button group so choosing a button refreshes the screen.

Don't use OBLIGATORY, which would apply whichever button is chosen. Instead validate in AT SELECTION-SCREEN: if the radio button is selected, the user pressed Execute (sscrfields-ucomm = 'ONLI', with TABLES sscrfields declared) and the field is initial, raise an error message. Without the Execute check, the error also fires when the user just clicks the radio button.

With CL_GUI_ALV_GRID, define a local handler class with a method FOR EVENT double_click OF cl_gui_alv_grid, which receives e_row and e_column, and register it with SET HANDLER lo_handler->on_double_click FOR lo_grid. With CL_SALV_TABLE, use its events object and the DOUBLE_CLICK event, or make the column a hotspot and handle LINK_CLICK for a single click.

In the handler, read the clicked row from the output table, then SET PARAMETER ID 'AUN' FIELD ls_row-vbeln and CALL TRANSACTION 'VA03' WITH AUTHORITY-CHECK AND SKIP FIRST SCREEN. Interviewers may ask why CALL TRANSACTION and not LEAVE TO TRANSACTION: CALL brings the user back to the report when they press Back.

A domain holds the technical definition: the data type, length and decimals, plus an optional value range, either fixed values or a value table, and a conversion routine such as ALPHA, which adds leading zeros to numbers. A data element holds the meaning: it refers to a domain or a built-in type and adds field labels, documentation (the F1 help), and optionally a search help and parameter ID.

One domain can serve many data elements. For example, a single domain for a 10-character customer number can be used by data elements for the sold-to party and the payer, each with its own label. Table fields refer to data elements, so labels and F1 help appear automatically on every screen that uses the field.

A transparent table has exactly one table in the database with the same name and fields, and holds most application and custom data. Pooled and cluster tables were older SAP-specific types where several logical tables were stored together in one database table; BSEG, for example, was a cluster table, and such tables couldn't be joined in Open SQL. On SAP HANA, including S/4HANA, they have been converted to transparent tables, so you can join and index them normally.

For a custom table, also choose the delivery class (A for application data, C for customising data) and the technical settings, and generate table maintenance (SE54, or from SE11) so users can maintain entries in SM30.

A search help is the F4 list of possible values for a field. An elementary search help defines one way of searching: a selection method (the table or view it reads), the fields shown in the list, and import and export parameters that pass values between the screen and the list. A collective search help groups several elementary ones as tabs, so a user can find a customer by name, by city or by postal code in one F4 window.

You can attach a search help to a data element, to a table field, or through a check table; on a selection screen, use MATCHCODE OBJECT. For special logic, a search help exit, which is a function module, can change the values shown.

A lock object, created in SE11 with a name starting with EZ or EY, defines a logical lock on one or more tables. Activating it generates two function modules, such as ENQUEUE_EZ_ORDER and DEQUEUE_EZ_ORDER. Before letting a user change a record, call the enqueue module with its key. If someone else already holds the lock, it raises FOREIGN_LOCK and you show a message such as "Record is being edited by [user]". Call dequeue when they save or leave.

Lock modes include E (exclusive, cumulative within the same transaction), X (exclusive, not cumulative), S (shared, for reading) and O (optimistic). These are SAP locks, not database locks: they only work if every program calls the enqueue. Current locks appear in SM12.

User exits are empty subroutines SAP left in its own includes, mainly in SD, such as the USEREXIT forms in MV45AFZZ for sales orders; changing them needs an access key, so technically it's a modification. Customer exits are planned function module exits, called with CALL CUSTOMER-FUNCTION and grouped in enhancements (SMOD) that you activate in a project (CMOD). BAdIs are object-oriented: SAP defines an interface (SE18) and you implement it in your own class (SE19), with no change to SAP code. The enhancement framework adds implicit enhancement points, at the start and end of most routines, and explicit ones SAP placed in the code.

Prefer a BAdI or customer exit, then an enhancement point, and a modification only as a last resort.

For classic BAdIs, set a breakpoint in method GET_INSTANCE of class CL_EXITHANDLER and run the transaction: every BAdI it calls stops there, showing its name. For new BAdIs, search the program's source for GET BADI or CALL BADI, or set a debugger breakpoint on those statements. For customer exits, search for CALL CUSTOMER-FUNCTION, or find enhancements in SMOD by the transaction's package, shown under System, Status. The IMG documentation for the area often lists the BAdIs too.

For purchase orders, ME_PROCESS_PO_CUST is the usual BAdI, with methods such as CHECK and POST. Read its documentation to choose the method that runs at the right moment, and test it in the debugger.

A classic BAdI is called through CL_EXITHANDLER=>GET_INSTANCE, followed by a method call on the returned object. A new BAdI belongs to an enhancement spot in the enhancement framework and is called with the ABAP statements GET BADI and CALL BADI. The kernel handles new BAdIs directly, so they run faster, and they offer a fallback class used when no implementation is active, filter values handled in the call, and implementations grouped in enhancement implementations.

Both kinds can be single-use or multiple-use. For a multiple-use BAdI, all active implementations run, so don't rely on their order unless it has been defined. A single-use BAdI must have only one active implementation. Most BAdIs SAP adds in S/4HANA are new BAdIs.

SAPscript is the oldest: forms are client-dependent, edited in SE71, and the print program controls most of the output with WRITE_FORM calls. SmartForms (transaction SMARTFORMS) are client-independent, built in a graphical editor with windows, tables and conditions, and generate a function module that the print program calls. Adobe Forms, created in SFP, separate the interface and context from the layout, which is designed in Adobe LiveCycle Designer; they produce PDFs, can be interactive, and need Adobe Document Services (ADS) to render.

SAP's direction is Adobe Forms, and S/4HANA's newer output management is built around them, but many companies still maintain SmartForms and even SAPscript, so know all three.

The print program reads the data, calls SSF_FUNCTION_MODULE_NAME with the form name to get the name of the generated function module, and then calls that module dynamically: CALL FUNCTION lv_fm_name, passing control_parameters, output_options and user_settings plus the form's own interface parameters, such as the header structure and the item table. The generated name, something like /1BCDWB/SF00000123, is assigned in each system separately, so hard-coding it would break after a transport.

For standard documents, the print program and form are linked to an output type, through NACE in ECC, and output determination triggers them. In S/4HANA many documents use the newer BRF+-based output management instead, so check which one your system uses.

Use a table node in the main window, since only the main window flows on to the next page. In the table's header section, tick both "At start of table" and "At page break", so the column headings print at the top of every page. Put the grand total in the footer section with "At end of table" set.

To calculate the total, use the table node's Calculations tab to sum the amount field into a global variable, or add it up in a program lines node inside the table. For a subtotal on each page, use a footer with "At page break". Also set the next page of the first page, so the form continues on a follow-up page with its own header.

Instance attributes (DATA) and methods (METHODS) belong to each object: you create an object with NEW or CREATE OBJECT and call its method as lo_order->calculate( ). Each object has its own copy of the instance data. Static attributes (CLASS-DATA) and methods (CLASS-METHODS) belong to the class and are shared by all its objects; you call them with the class name and =>, such as zcl_utils=>format_date( ), without creating an object. A static method can't use instance attributes.

Use static members for helpers and shared settings, and instance members for anything with its own state, such as an order. The static constructor, CLASS_CONSTRUCTOR, runs once, before the class is first used.

An interface declares methods without implementing them. A class lists it with INTERFACES zif_payment in its definition and implements each method as zif_payment~pay. You can declare a reference of the interface type, DATA lo_pay TYPE REF TO zif_payment, assign an object of any class that implements it, and call lo_pay->pay( ); each class runs its own logic. That's polymorphism.

It lets you add a new payment type or output channel without changing the calling code, and it's how BAdIs work: SAP defines an interface and your class implements it. ALIASES can give interface methods shorter names inside the class.

You raise an exception with RAISE EXCEPTION TYPE zcx_order_error and handle it with TRY ... CATCH zcx_order_error INTO lx_error ... ENDTRY, where lx_error->get_text( ) gives the message. A CLEANUP block runs when an exception leaves the TRY block uncaught, so you can tidy up.

The superclass decides the checking. For CX_STATIC_CHECK, the syntax check warns if a method can raise it without declaring it in RAISING, so callers know to handle it; use it for expected business errors. CX_DYNAMIC_CHECK is checked only at runtime, for errors the caller can usually prevent, such as division by zero. CX_NO_CHECK need not be declared, for things like resource shortages. Classic EXCEPTIONS with sy-subrc in function modules are the older approach.

A global class, created in SE24 or in ADT in Eclipse, is a repository object any program can use, so use it for reusable logic, such as a pricing or validation routine shared by several reports and interfaces. A local class is defined inside one program, or in a class's local include, and is visible only there; it's good for structuring a single report, such as an lcl_report class with methods to get and display data.

ABAP Unit tests are local classes defined FOR TESTING, usually with RISK LEVEL HARMLESS and DURATION SHORT, whose methods call your code and check results with cl_abap_unit_assert=>assert_equals. Keep business logic separate from database access so tests don't depend on data in the system.

Keep it to a minute, link your background to ABAP, and be honest about training versus project work. For example: "I'm a [degree] graduate from [college]. I trained in SAP ABAP at [institute] for [months], and in my training project I built an ALV report of sales orders with a drill-down to VA03, a SmartForm for an invoice, and a BAdI for a purchase order check. I've also started learning CDS views, since most new work is on S/4HANA. I enjoy finding out why a program behaves as it does, and I'd like to start as an ABAP developer on a support or implementation project."

Don't present training as client project experience; interviewers find out within two questions.

Show that you know where SAP is going: "Many large companies in India run finance, supply chain and HR on SAP, and they're moving to S/4HANA, which still runs on ABAP. The language has grown with it: CDS views, AMDP, the ABAP RESTful Application Programming Model and ABAP Cloud on SAP BTP are where new development is happening. I want a strong base in classic ABAP for support work, and then to move into these areas."

Naming one modern topic you've actually tried, such as building a CDS view, makes this answer much stronger.

Show that you understand support work and are ready for it: "Yes. In a support project I'd work on tickets with priorities and SLAs, such as fixing a failed interface or changing a report, and some clients need cover in shifts or during month-end. It's a good way to learn many areas of a real system quickly, and I'd like to grow from there into enhancements and new development."

If you have a real constraint on shifts, mention it politely now. Don't say you only want implementation projects: most freshers start in support.

Show that you clarify early instead of guessing: "I'd go through the specification and list exactly what's unclear, such as which tables to read, what happens when a field is blank, or the expected output. Then I'd ask the functional consultant for a short call with test data examples, rather than a long email chain, and record the answers in the specification or ticket so the logic is agreed. If the deadline is at risk, I'd tell my lead early and suggest delivering the agreed part first."

Mention that coding on assumptions is a common reason objects fail testing and come back.

Pick a real example and show your method. For example: "Users reported a dump in a custom billing report (situation). In ST22 it was an uncaught CX_SY_ITAB_LINE_NOT_FOUND from a table expression reading customer data (task). In the debugger I found that one-time customers had no row in that table, so the code assumed data that didn't always exist. I added a line_exists check with a default, retested with the user's selection in quality and moved the fix through transport (action). The report ran cleanly, and I checked other programs using the same pattern (result)."

Interviewers often ask which dumps you know, so have two or three ready.