ABAP is the programming language of SAP. These SAP ABAP interview questions cover data dictionary, internal tables, reports and modularisation for freshers, then BAPIs, BADIs, enhancements, OData, CDS views, performance tuning and ABAP on HANA for experienced ABAP developers.
30 questions · Updated
Fundamentals, definitions and simple scenarios. Good for freshers and warm-ups.
The Data Dictionary (transaction SE11) centrally defines database objects and data types used across SAP: transparent tables, views, data elements (business meaning and labels), domains (technical type and allowed values), structures, table types, search helps and lock objects. Because programs refer to these definitions, a change in one place applies everywhere.
An internal table holds rows of data in memory while a program runs.
Standard tables are accessed by index or linear search and allow duplicates.
Sorted tables are always sorted by a key and use binary search.
Hashed tables use a unique key with constant-time access, which suits large lookups.
I choose the type based on how the table will be read.
Classical reports write a simple list using WRITE statements.
Interactive reports allow drilling down from a basic list into detail lists using events like AT LINE-SELECTION.
ALV (ABAP List Viewer) reports display data in a grid with built-in sorting, filtering, totals and export, using classes such as CL_SALV_TABLE.
Modern apps use Fiori instead.
TYPES defines local types, and DATA declares variables based on built-in types (i, p, c, n, string, d, t), Data Dictionary types (such as a data element or table structure) or local types, for example DATA lv_count TYPE i. Structures group fields, and internal tables are declared with TYPE STANDARD TABLE OF, SORTED or HASHED with a key. Modern ABAP prefers inline declarations such as DATA(lv_total) = ....
ABAP SQL (Open SQL) reads and changes database tables in a database-independent way, for example SELECT matnr, maktx FROM makt WHERE spras = @sy-langu INTO TABLE @DATA(lt_texts). It supports joins, aggregates, subqueries and CASE expressions, and is checked against the Data Dictionary. sy-subrc shows whether rows were found, and sy-dbcnt shows how many.
Includes split source code into separate parts.
Subroutines (FORM ... ENDFORM) are older and now obsolete for new development.
Function modules live in function groups, have defined interfaces and can be called remotely.
Methods in classes are the recommended approach for new code.
Macros exist but should be avoided because they are hard to debug.
LOAD-OF-PROGRAM runs when the program loads, INITIALIZATION sets default values before the selection screen appears, AT SELECTION-SCREEN validates input, START-OF-SELECTION contains the main processing (and is the default event), END-OF-SELECTION runs after processing, and TOP-OF-PAGE and END-OF-PAGE format list headers and footers. Interactive lists add AT LINE-SELECTION.
PARAMETERS creates single input fields, such as a company code or a checkbox, and SELECT-OPTIONS creates ranges with multiple values, intervals and exclusions, stored in a range table used in WHERE clauses with IN. Blocks, frames and text elements organise the screen, and variants save common input combinations.
Development objects belong to packages, which group related objects and determine the transport layer.
Changes are recorded in transport requests (managed in SE09 or SE10): workbench requests for cross-client objects such as programs, and customising requests for client-specific configuration.
Requests are released and imported from development to quality to production through the transport management system.
Set breakpoints in the editor (session or external breakpoints for web and RFC calls), or enter /h before running a transaction.
In the debugger you step through code (F5, F6, F7 and F8), inspect and change variables, view internal tables, set watchpoints that stop when a variable changes, and use layer-aware debugging to skip standard code.
ST22 shows short dumps from runtime errors.
MESSAGE statements use types: E (error, stops processing and lets the user correct input), W (warning, can continue), I (information popup), S (success, shown in the status bar), A (abort, terminates the transaction) and X (exit, causes a short dump). Messages are defined in message classes (SE91) with numbers and placeholders for values.
Applied problems, trade-offs and questions about your own projects.
An RFC-enabled function module can be called remotely from another system.
A BAPI is a standardised RFC function module that represents a method of a business object in the Business Object Repository, such as BAPI_SALESORDER_CREATEFROMDAT2, with a stable interface and a RETURN table for messages.
BAPIs need BAPI_TRANSACTION_COMMIT to save changes.
They let you add custom logic to standard SAP without modifying it.
User exits and customer exits are older include or function-module based hooks.
BADIs (Business Add-Ins) are object-oriented, with an interface you implement, and can have multiple implementations and filters.
The enhancement framework adds implicit and explicit enhancement points and sections in standard code.
I prefer BADIs where available.
All three create printed output such as invoices and purchase orders.
SAPscript is the oldest, client-dependent and harder to maintain.
Smart Forms is client-independent with a graphical designer and generates a function module.
Adobe Forms (Interactive Forms by Adobe) uses Adobe LiveCycle Designer, supports interactive PDFs and is the recommended option, especially in S/4HANA.
I find the problem with SQL Trace (ST05) and runtime analysis (SAT).
Then I select only the fields and rows I need using a proper WHERE clause on indexed fields, avoid SELECT inside loops, use JOINs or FOR ALL ENTRIES (checking the driver table is not empty), read internal tables with sorted or hashed keys, and use field symbols to avoid copying data.
On HANA I push calculations down to the database.
BDC (batch data communication) simulates screen input by recording transactions, which is fragile when screens change.
BAPIs are stable APIs that create business objects directly with full validation and are preferred.
LSMW (Legacy System Migration Workbench) was a tool for migrating data using BDC, BAPIs, IDocs or direct input.
In S/4HANA, the Migration Cockpit replaces LSMW for data migration.
Lock objects, defined in SE11, protect data from being changed by two users at once.
Activating one generates function modules ENQUEUE_<name> to set a lock and DEQUEUE_<name> to release it, managed by the enqueue server.
Programs should lock data before changing it and release it afterwards.
SM12 shows current locks.
Classes are defined with sections for public, protected and private components, with attributes, methods, events and constructors, and can be global (SE24 or Eclipse) or local in a program. ABAP supports inheritance, interfaces, abstract and final classes, polymorphism, and class-based exceptions raised with RAISE EXCEPTION TYPE and handled with TRY ... CATCH ... ENDTRY.
Fill an internal table with the data, call cl_salv_table=>factory to create the ALV object, then configure columns (headings, hiding, optimised widths), functions (toolbar buttons), sorting, aggregations and events through its methods, and call display(). For editable grids, CL_GUI_ALV_GRID is used instead, as SALV is read-only.
The table maintenance generator (SE11 > Utilities) creates screens for maintaining entries of a custom table, so users can add, change and delete records through SM30 without writing a program.
You choose an authorisation group, a function group and one- or two-step screens.
Events can add custom logic, such as filling the user and date when a record is saved.
Database changes inside an SAP logical unit of work can be bundled using update function modules called IN UPDATE TASK, which run when COMMIT WORK is executed.
V1 updates are time-critical and run first, V2 updates are less critical, such as statistics.
ROLLBACK WORK cancels pending changes.
SM13 shows failed updates.
An IDoc (intermediate document) is SAP's standard format for exchanging data asynchronously with other systems through ALE or EDI, such as purchase orders, invoices and master data.
It has a control record, data records based on segments, and status records.
Configuration includes message types, IDoc types, partner profiles (WE20) and ports, and WE02 or WE05 monitors IDocs.
System design, deep internals, leadership and tough follow-ups.
Core Data Services views are defined in ABAP Development Tools (Eclipse) and create database views with rich semantics: joins, associations, calculated fields, annotations for UI and analytics, and access control with DCL. They push logic to the HANA database, are the basis of the virtual data model in S/4HANA, and can be exposed as OData services for Fiori apps.
RAP is the current model for building Fiori apps and APIs in S/4HANA and SAP BTP.
You define data with CDS views, describe behaviour (create, update, delete, validations, determinations and actions) in a behaviour definition, implement it in ABAP classes, and expose it through service definitions and bindings as OData V2 or V4.
It replaces older approaches like SEGW-based gateway services.
Code should push work to the database with CDS views and AMDP, use new Open SQL syntax and inline declarations, and adapt to data model changes such as ACDOCA and Business Partner.
Custom code is checked with the ATC for compatibility.
ABAP Cloud uses only released APIs and a restricted language version, following the clean core principle so upgrades do not break custom code.
ABAP Managed Database Procedures let developers write database procedures in SQLScript inside ABAP class methods, so complex calculations run directly in SAP HANA.
They are managed and transported like ABAP code and can be used as the implementation of CDS table functions.
They suit performance-critical logic that ABAP SQL and CDS cannot express.
The older approach uses the Gateway Service Builder (SEGW) to model entities, generate classes and implement methods such as GET_ENTITYSET.
Another approach exposes CDS views with the @OData.publish annotation.
The current approach is RAP: define CDS views, behaviour definitions, service definitions and service bindings to publish OData V2 or V4 services for Fiori and external consumers.
Inline declarations (DATA(...) and FIELD-SYMBOL(...)), constructor expressions (VALUE, NEW, CONV, CORRESPONDING, COND, SWITCH, REDUCE and FILTER), FOR loops inside expressions, string templates with |...{ variable }...|, table expressions such as lt_tab[ id = 5 ], LINE_EXISTS, and new ABAP SQL syntax with host variables escaped by @ and comma-separated field lists.
ABAP Unit tests are local test classes marked FOR TESTING, with setup and teardown methods and assertions from CL_ABAP_UNIT_ASSERT.
Dependencies are replaced with test doubles using interfaces, the ABAP test double framework, CDS test environments and the SQL test double framework so database access can be simulated.
Tests run from the editor or in ATC checks.
Clean core means keeping the S/4HANA core standard so upgrades are smooth.
Extensions use released APIs and extension points: key user extensibility (custom fields and logic in Fiori apps), developer extensibility on-stack with ABAP Cloud, and side-by-side extensions built on SAP Business Technology Platform that communicate through APIs and events.
Modifications to SAP code are avoided.
See all SAP & CRM Consultant interview questions, covering SAP FICO, SAP MM, SAP SD, SAP ABAP, Salesforce and more.