Quick Answer
- ABAP interviews test 8 core areas: fundamentals, Data Dictionary, reports/ALV, performance, dialog programming, OOABAP/enhancements, interfaces, and ABAP on HANA (CDS/AMDP).
- Senior roles weight performance optimization and OOABAP heavily — memorized syntax alone won't pass a senior interview.
- ABAP on HANA (CDS Views, AMDP, code pushdown) is now a standard section in almost every 2026 SAP ABAP interview, not just S/4HANA specialist roles.
- Interviewers consistently favor candidates who explain why a technique is used over those who just recite definitions.
- This guide is aligned with the SAP C_ABAPD certification syllabus, so it doubles as exam prep.
Core Concepts
ABAP Fundamentals
15 Questions
The building blocks every ABAP interview starts with — data types, internal tables, control structures, and how ABAP fits into the SAP system landscape.
ABAP stands for Advanced Business Application Programming. It's SAP's proprietary fourth-generation language, originally built for SAP R/2 and R/3, and still the core development language across SAP ECC and SAP S/4HANA for reports, interfaces, enhancements, forms, and custom development.
A table physically stores data in the database and has technical settings — data class, size category, buffering. A structure has the same row/column layout but holds no data of its own; it's used to define a reusable data shape for interfaces, function module parameters, or a work area.
An internal table is a dynamic, memory-resident data structure holding a set of records during runtime. Instead of hitting the database repeatedly in a loop (slow and against SAP best practice), you fetch data once into an internal table, then process it in memory.
Three types: Standard tables (unsorted, accessed by index, fastest to append), Sorted tables (always kept in key order, good for binary search), and Hashed tables (accessed only via a unique key using a hash algorithm — very fast lookups, no index access).
SELECT SINGLE requires the WHERE clause to specify all primary key fields and uses an efficient key lookup. SELECT UP TO 1 ROWS can use a partial WHERE clause and just stops after the first matching row — less predictable and potentially less performant on large unsorted tables.MOVE (or the = assignment) copies data field-by-field in position order, so source and target need matching layouts. MOVE-CORRESPONDING copies by matching field names between two structures, which is safer when layouts differ but field names overlap.A Data Type is an abstract description of how data should look (like a blueprint) — it doesn't occupy memory on its own. A Data Object is an actual instance in memory created based on a data type (e.g. via
DATA), and it's the data object that actually holds a value at runtime.TYPES defines a new data type — a template — without allocating memory. DATA declares an actual variable (data object) with memory allocated, optionally based on a type defined with TYPES or an existing Dictionary type.A field symbol is a symbolic pointer/reference to a data object — it doesn't hold data itself but acts as an alias for another variable's memory location. It's most commonly used with
ASSIGN to loop through internal tables without copying data into a work area each time, improving performance on large tables.Looping into a work area (
LOOP AT itab INTO wa) physically copies each row's data into the work area's memory — an extra copy operation per row. Looping with a field symbol (LOOP AT itab ASSIGNING <fs>) just points directly at the table row's memory, avoiding the copy — noticeably faster on large tables.Conditional:
IF/ELSEIF/ELSE, CASE/WHEN. Loops: DO...ENDDO (fixed/indefinite loop), WHILE...ENDWHILE (condition-based), and LOOP AT...ENDLOOP (iterating over an internal table).A subroutine (FORM) is defined and callable only within the same program (or via explicit external perform, which is discouraged), with simpler parameter passing. A function module is a globally reusable unit stored in a function group, with strictly typed import/export/tables/exceptions interfaces, and can be called remotely (RFC-enabled) from other systems.
Pass by value (
USING value(param)) copies the data into the subroutine/method — changes inside don't affect the original variable unless explicitly passed back. Pass by reference passes the memory address directly, so changes inside the routine immediately affect the original variable's value.The ABAP Editor (SE38/SE80) is where you write and test programs. Key daily transactions:
SE11 (Data Dictionary), SE24 (Class Builder), SE37 (Function Builder), SE80 (Object Navigator/Workbench), and SE24/SE91 for message classes.ECC runs on any database and relies heavily on classic ABAP with the application server doing most data processing. S/4HANA runs specifically on the HANA in-memory database and shifts toward CDS Views, AMDPs, and code pushdown — moving data-intensive logic into the database itself for major performance gains.
SE11 & Data Modeling
Data Dictionary
15 Questions
How SAP centrally defines and manages every table, field, and relationship in the system — and the questions interviewers use to check you actually understand the data model, not just the syntax.
The Data Dictionary is SAP's central repository for all data definitions used across the system — tables, structures, views, data elements, domains, search helps, and lock objects. A single data element change automatically propagates everywhere it's used.
A domain defines technical properties — data type, length, value range (fixed values). A data element sits above the domain and adds business/semantic meaning — field labels, F1 help — while referencing a domain for its technical definition.
A search help provides the F4 value-help dropdown on a screen field. Elementary search helps use a single data source; collective search helps combine several elementary ones into one F4 popup with multiple tabs.
A lock object (SE11, generates ENQUEUE_/DEQUEUE_ function modules) prevents two users editing the same record simultaneously and causing inconsistent updates. Opening a record for edit sets a lock; a second user attempting to edit the same record is blocked with a lock message.
A classic database view (SE11 join syntax) is limited in expressible logic. A CDS view uses a more powerful SQL-like DDL, supports associations, calculated fields, and OData/Fiori annotations — and executes inside HANA rather than the application server.
Technical settings (Data Class, Size Category, Buffering switch) control how a table is physically stored and cached. Getting the size category wrong on a high-volume custom table, for example, causes frequent costly table reorganizations — a real performance interview topic.
Buffering caches table data on the application server to avoid repeated database round-trips for frequently-read, rarely-changed data. Types: Full buffering (entire table cached), Generic buffering (cached by part of the key), and Single-record buffering (only accessed records are cached).
A foreign key links a field in one table (the dependent table) to the key field of another table (the check table), enforcing that only valid, existing values can be entered — for example, ensuring a Customer field only accepts customer numbers that actually exist in the customer master table.
A check table is used at the foreign key level to validate entries against existing records. A value table is assigned at the domain level and is proposed as the default check table for any field built on that domain, unless explicitly overridden.
An include structure is inserted into a table/structure definition and its fields become part of that structure directly — commonly used to add a set of standard fields to multiple tables. An append structure is a customer-specific extension added onto an existing (often SAP-standard) table without modifying the original object, making it upgrade-safe.
A structure defines a single row's layout (field names and types). A table type defines an internal table based on that row type, plus the access type (standard/sorted/hashed) and key — it's what lets you declare internal tables with dictionary-level reusable definitions instead of redefining the same structure everywhere.
Use an append structure (or, on S/4HANA, the Custom Fields app for Fiori-exposed fields) rather than directly modifying the standard table. This keeps the change upgrade-safe since it doesn't touch SAP's original object.
SE11 is where you design the Data Dictionary object — tables, views, structures. SE16/SE16N are data browsers used to view and query the actual data stored in a table, without modifying its structure.
Keep the key as narrow and meaningful as possible (client field first for client-dependent tables), ensure it reflects the actual business uniqueness of a row, and think ahead about whether the table will need buffering — a poorly chosen key makes both integrity and performance harder to fix later.
A client-dependent table includes MANDT (client) as the first key field, so data is isolated per client (e.g. 100, 200, 300 for Dev/QA/Prod-style separation within one system). A client-independent table has no MANDT field and its data is shared and visible across all clients in that system.
Output & Reporting
Reports & ALV
15 Questions
Every ABAP developer builds reports early and often. These questions test whether you understand the report types, selection screens, and the ALV framework that powers most SAP list output.
A classical report produces one static list with no drill-down. An interactive report lets the user click a line on the basic list to trigger a secondary detail list, using events like
AT LINE-SELECTION.ALV (ABAP List Viewer) is a standard set of function modules/classes (e.g.
REUSE_ALV_GRID_DISPLAY, or the modern CL_SALV_TABLE) giving sorting, filtering, subtotals, column reordering, and Excel export automatically — without hand-coding that display logic.The parameter/input screen shown before a report runs, built with
PARAMETERS and SELECT-OPTIONS. Validation happens in AT SELECTION-SCREEN — you can check individual fields with AT SELECTION-SCREEN ON <field> or validate the whole screen before processing begins.PARAMETERS declares a single-value input field. SELECT-OPTIONS declares a range/multi-value input (generating a table with SIGN, OPTION, LOW, HIGH fields), letting the user enter ranges, multiple single values, or exclusions on the selection screen.Use SELECT with a narrow field list instead of
SELECT *; filter as much as possible in the WHERE clause; use appropriate internal table types; avoid SELECT statements inside loops; use FOR ALL ENTRIES or JOINs instead of nested SELECTs; and on S/4HANA, consider pushing logic into a CDS view or AMDP.FOR ALL ENTRIES runs a second SELECT using values from an already-fetched internal table — useful across different database connections, but implicitly removes duplicates and requires the driver table to be non-empty. An INNER JOIN combines both tables in a single SQL statement executed by the database, generally more efficient when both tables share the same database.INITIALIZATION (before selection screen displays), AT SELECTION-SCREEN (validation), START-OF-SELECTION (main processing logic begins), and END-OF-SELECTION (final output/summary logic after all processing).ALV Grid is the modern, interactive display (in-place editing, drag-drop column reorder, more toolbar options) and is the standard choice today. ALV List is the older, simpler read-only list display, occasionally used for very large outputs or print-focused reports.
By defining a custom GUI status/menu and passing it into the ALV via the function exit parameter (classic ALV) or by handling the
TOOLBAR and USER_COMMAND events on the ALV object model (CL_GUI_ALV_GRID), which lets you append your own buttons and respond to their clicks.A logical database is a predefined, hierarchical data-retrieval program (built via SLDB) that reports can attach to via the selection screen, handling authorization checks and standard selection logic automatically. It's used less often in modern development since CDS views and custom SELECTs give more control, but it's still common in older HR and older FI reports.
Either let users use the built-in ALV Excel export button (no code needed), or programmatically generate a file using classes like
CL_GUI_FRONTEND_SERVICES for downloading, or build the data as a proper spreadsheet using the ABAP2XLSX open-source library for more advanced formatting needs.AT LINE-SELECTION triggers when the user double-clicks/selects a specific list line — used for drill-down to detail. AT USER-COMMAND triggers when the user chooses a custom function code from a menu or button you've defined, independent of which line is selected.By populating the ALV's sort table (
lt_sort) with the field name, sort order (ascending/descending), and a subtotal flag per field, then passing that table into the ALV display function/method — the ALV framework then handles grouping and subtotal calculation automatically.A report program (type 1) is designed to select and display data, typically starting with a selection screen and flowing through defined report events. A module pool program (type M) is built around custom screens (via Screen Painter) and PBO/PAI event processing, used for interactive transactions rather than pure reporting.
Build it as an interactive report (or ALV with a defined double-click handler): the initial list shows aggregated/summarized data, and on
AT LINE-SELECTION (or the ALV hotspot click event), you re-query the detail records for the selected key and display a secondary detail list.Optimization
Internal Tables & Performance
15 Questions
Performance questions separate candidates who memorized syntax from those who've actually optimized real code under load — a heavily weighted category in senior ABAP interviews.
Without
BINARY SEARCH, ABAP does a linear scan through the internal table (checking each row in order) — slow on large tables. With BINARY SEARCH, it performs a much faster binary search, but the table must be sorted by the key you're searching on beforehand, or results are unreliable.APPEND adds a row to the end of a standard table (fastest option for standard tables). INSERT can add a row at a specific position, or is required for sorted/hashed tables where the position is determined by the table's own sort/hash logic rather than simply appending at the end.Fetch all needed data in a single SELECT (using JOIN or FOR ALL ENTRIES) before the loop starts, store it in an appropriately-typed internal table (often hashed, for fast key lookup), then use READ TABLE inside the loop instead of hitting the database again for every iteration.
SELECT * retrieves every column even if you only need two or three, increasing network transfer, memory usage, and database read time — especially expensive on wide tables. Explicitly listing needed fields reduces all of that and is considered standard best practice, and is specifically flagged by the SAP Code Inspector.A Hashed table gives near-constant time O(1) lookup by a full unique key via a hash algorithm, but has no meaningful index-based access and cannot be accessed partially by key. A Sorted table maintains key order and supports both fast binary-search lookups (O(log n)) and index-based access, plus range reads.
Use SAT (Runtime Analysis, replacing SE30) to profile execution time by statement/routine, ST05 (SQL Trace) to see actual database calls and their duration, and ST12 (a combined trace) — all standard tools an interviewer expects a candidate to have actually used, not just know by name.
Looping
INTO wa copies each row into the work area's memory on every iteration. Looping ASSIGNING <fs> uses a field symbol to point directly at the row in the table's memory — no copy — which is measurably faster, especially with large or wide tables.Early aggregation means summing/aggregating data as early as possible — ideally at the database level (SUM, GROUP BY in SQL, or in a CDS view) — rather than pulling detailed line-item data into ABAP and aggregating it there. It drastically cuts data transfer and processing volume.
A static code analysis tool (SCI) that scans ABAP code for performance anti-patterns (SELECT * usage, SELECT inside loops), security issues, and coding standard violations, generating a report developers use before transporting code to QA/Production.
Collect all the driver keys from the loop's source table first, run a single bulk SELECT with an IN condition or JOIN against those keys before the loop, store the result in a hashed internal table, then use READ TABLE (not SELECT) inside the loop for each key.
When a table is buffered, application servers cache its data locally; changes made on one server can take a short time to propagate to other servers' buffers. This can cause a developer to update a row and then immediately re-read stale data if buffer invalidation timing isn't accounted for — a subtle bug interviewers ask about to test real production experience.
APPEND LINES OF itab2 TO itab1 appends an entire internal table's contents in a single optimized statement. Looping and calling APPEND row-by-row does the same thing but with more statement overhead — the bulk statement is preferred for performance and cleaner code.Parallel cursors are a manual optimization technique for looping through two sorted internal tables together (instead of using nested LOOP or READ TABLE inside a LOOP) by tracking an index into each table and advancing them in sync — used in performance-critical code where even READ TABLE binary search overhead needs to be avoided.
On HANA, in-memory columnar storage makes aggregation and filtering extremely fast at the database level, so the best-practice shift is toward code pushdown — using CDS views and AMDPs so HANA does the heavy computation — rather than the classic ECC approach of pulling data up and processing it in ABAP.
APPEND always adds a new row. COLLECT checks if a row with matching non-numeric key fields already exists — if so, it adds the numeric fields to that existing row instead of creating a duplicate, effectively aggregating on the fly, which is useful for building totals without a separate aggregation step.Screens & Transactions
Dialog Programming
15 Questions
Building custom transactions means understanding SAP's screen event model — PBO/PAI — and how user interaction flows through a module pool program.
PBO (Process Before Output) runs before the screen displays — used to set field values, hide/show fields, prepare data. PAI (Process After Input) runs after the user submits the screen — validates input, processes function codes, triggers navigation.
A screen element displaying multiple rows of an internal table on a custom screen, with scrolling, letting users edit multiple records inline — similar to a spreadsheet grid. Used for custom entry transactions needing several line items at once.
Raise the error inside the relevant PAI module using a message of type E (error), which keeps the user on the same screen with input intact and cursor positioned on the problem field via
SET CURSOR — rather than navigating away or clearing the screen.A regular PAI module runs field/screen validation normally. A module flagged
AT EXIT-COMMAND runs even when the user presses Back/Exit/Cancel, and skips field validation — used specifically to let users exit a transaction without being blocked by mandatory field checks.The flow logic is the sequence of PBO and PAI modules that get triggered for a given screen, maintained in the Screen Painter (via SE51/SE80) alongside the screen layout itself — it's essentially the screen's own mini-program controlling what happens before and after display.
A screen field that captures which button, menu item, or Enter/function key the user triggered. In PAI, you check its value (often moving it to a local variable and clearing OK_CODE immediately) to branch your logic — e.g. SAVE vs. CANCEL vs. a custom toolbar button.
CALL SCREEN pushes a new screen onto the screen call stack and returns control to the calling screen when the called screen is left. SET SCREEN sets which screen will be shown next after the current PBO/PAI cycle finishes, without pushing a new stack level — control does not automatically return.Using
VRM_SET_VALUES (function module) to populate a value list programmatically in PBO, tied to a screen field defined as a listbox in Screen Painter — commonly used when the dropdown options come from a Z-table or logic rather than a fixed domain value list.A subscreen is a screen area that can dynamically display different embedded screens depending on program logic. A tabstrip control specifically presents that subscreen switching as a tabbed UI — each tab corresponds to a different subscreen being called.
Set the field as required in Screen Painter (adds visual indicator) and, more importantly, explicitly check the field is filled in the PAI module before allowing the SAVE function code to proceed — screen-level 'required' alone doesn't guarantee the value is meaningful, so backend validation is still expected.
A status/information message (type S/I) just informs, doesn't block. A warning (type W) can be bypassed by pressing Enter again. An error (type E) blocks the user on the current screen until the underlying issue is fixed — critical distinction for how strict your validation logic needs to be.
Set a breakpoint in the relevant PAI module (often via /h in the command field to trigger the debugger, or a hard breakpoint in the code), step through the OK_CODE handling logic, and verify at each step whether the expected function code and field values are actually reaching the module.
A GUI status (SE41) defines the menu bar, toolbar buttons, and function keys available on a screen. It's activated in PBO via
SET PF-STATUS, and each button/menu item is tied to a function code that then appears in OK_CODE when the user triggers it.LOOP AT SCREEN iterates over the fields on the current screen itself (useful for dynamically hiding/graying out fields based on conditions). Looping a table control iterates over the rows of an internal table bound to a table control UI element to populate its visible rows.Classic SAP GUI dialog programs are still fully supported but represent an older UX paradigm not well suited to browser/mobile access. For new S/4HANA development, Fiori apps (built on OData services, often backed by CDS views) are SAP's strategic direction and expected UX, though classic dialog programming remains relevant for maintaining existing custom transactions.
Extending SAP Safely
Enhancements & OOABAP
15 Questions
Modifying standard SAP directly creates upgrade risk. This section covers how developers safely extend SAP behavior — and the object-oriented ABAP concepts underlying modern development.
A user exit is an older technique — an empty subroutine/function module SAP placed at a fixed point in a standard program — with only one implementation possible. A BAdI is the newer, object-oriented technique built on interfaces, supporting multiple filter-dependent implementations.
SAP's modern mechanism (ECC 6.0+) for inserting custom code without core modification. Explicit enhancement points are predefined slots SAP deliberately placed. Implicit enhancement points exist automatically at standard locations — start/end of every method, function module, or form — even where SAP didn't plan for one.
Encapsulation (bundling data/methods, hiding internals), Inheritance (a subclass reusing/extending a superclass), Polymorphism (same method call, different behavior by object type at runtime), and Abstraction (interfaces/abstract classes defining a contract without full implementation).
A class defines both structure (attributes) and behavior (method implementations). An interface only defines method signatures — a contract — with no implementation; any implementing class must provide its own method bodies.
Almost always — enhancement preserves changes across support pack and version upgrades, since your code sits alongside standard code rather than inside it. Direct modification (tracked via SPAU/SPDD) creates ongoing upgrade risk and is treated as a last resort.
Inheritance ('is-a' relationship) has a subclass extend a superclass, gaining its attributes/methods. Composition ('has-a' relationship) has one class hold a reference to an instance of another class as an attribute, reusing its functionality without inheriting from it — generally more flexible and preferred where a strict 'is-a' relationship doesn't truly exist.
Overriding lets a subclass provide its own implementation of a method already defined in its superclass (marked with
REDEFINITION in ABAP). At runtime, calling that method on a subclass instance executes the subclass's version — this is polymorphism in action, since the same method call behaves differently depending on the actual object type.A static method (
CLASS-METHODS) belongs to the class itself and can be called without creating an object instance — useful for utility/factory logic. An instance method (METHODS) requires an actual object instance and can access that instance's specific attribute values.The instance
CONSTRUCTOR runs automatically whenever a new object is created, typically to initialize instance attributes. The CLASS_CONSTRUCTOR runs exactly once, the first time the class is accessed at all, used to initialize static/class-level attributes shared across all instances.OOP exception handling uses
TRY...CATCH...ENDTRY blocks with exception classes (inheriting from CX_ROOT), letting errors propagate up the call stack until caught, with structured exception objects carrying context. Classic MESSAGE-based handling is simpler but less structured, typically stopping processing immediately or requiring manual sy-subrc checks after every call.A filter lets a single BAdI definition support multiple different implementations that each only activate for specific filter values (e.g. a specific company code or document type) — meaning multiple teams or customizations can enhance the same standard process point without conflicting with each other.
Customer exits (managed via SMOD/CMOD, using enhancement projects) are the pre-ECC-6.0 technique — function-module-based exits activated by assigning them to a project. The newer enhancement framework (kernel-based, using implicit/explicit enhancement points and BAdIs) is more granular, doesn't require a separate 'project' activation step, and is SAP's current recommended approach.
An abstract class cannot be instantiated directly and typically defines some shared implementation plus one or more abstract methods that subclasses must implement. It's used when you want to enforce a common structure/contract across related subclasses while still sharing some concrete base logic — something a pure interface can't provide.
Prefer a BAdI if SAP explicitly provided one for that business process point — it's the officially supported, documented extension mechanism. Fall back to an implicit enhancement point only when no BAdI or explicit enhancement exists at the exact spot you need, since implicit enhancements are more fragile across SAP note/support pack changes to the underlying standard code.
ABAP Unit lets developers write automated test classes that verify a method's behavior without manual testing through the UI. It matters for enhancements because BAdI implementations and custom classes can be unit-tested in isolation, catching regressions early — increasingly expected in professional ABAP development, especially on S/4HANA projects.
Connecting Systems
Forms & Interfaces
15 Questions
Business documents and system-to-system connectivity — SmartForms, Adobe Forms, BAPIs, RFCs, and IDocs are where ABAP developers connect SAP to the outside world.
SmartForms is SAP's older form technology, generating output for print, fax, and email using SAP's own layout tool. Adobe Forms (Interactive/Print Forms) use Adobe's PDF technology, support interactive fillable PDFs, and are SAP's more modern recommendation, especially where end users need to fill and submit data back.
A BAPI (Business API) is a specific type of RFC-enabled function module that represents a standardized, stable business object method — meant for external systems (or other SAP systems) to call reliably, with SAP committing to backward compatibility. Not every RFC function module is a BAPI, but every BAPI is RFC-enabled.
RFC is SAP's protocol for calling function modules across system boundaries. Types include synchronous RFC (caller waits for response), asynchronous RFC (caller continues without waiting), and transactional/queued RFC (guarantees the call executes exactly once, even across connection failures, useful for reliable interface processing).
An IDoc (Intermediate Document) is SAP's structured data container format for exchanging business documents (like purchase orders or sales orders) asynchronously with external systems, often via ALE or EDI. IDocs are preferred for high-volume, asynchronous, batch-style integration; BAPIs are typically used for synchronous, real-time, transactional calls.
Outbound IDoc processing generates an IDoc from an SAP transaction/event and sends it to an external system. Inbound IDoc processing receives an IDoc from an external system and posts it into SAP, typically triggering a BAPI or standard posting function internally to create the actual business document.
Check transaction WE02/WE05 to view the IDoc's status and any error segments/messages, then use WE19 to reprocess a copy of the failed IDoc in test mode with the debugger attached to the processing function module, which lets you step through exactly where and why it failed.
Synchronous interfaces block the caller until a response is returned — appropriate when the calling process needs an immediate result (e.g. real-time credit check). Asynchronous interfaces let the caller continue immediately and process the response separately or not at all — appropriate for high-volume, non-blocking scenarios like nightly batch order uploads.
A proxy is generated ABAP code (client or server proxy) that represents a web service interface defined in SAP PI/PO or via a service definition, letting ABAP call or receive that structured message without manually building the low-level SOAP/XML handling — the proxy code manages that translation automatically.
BAPIs return standardized structures (like BAPIRET2) listing success/warning/error messages, and typically require an explicit
BAPI_TRANSACTION_COMMIT to persist changes — giving you structured control over rollback on error. Direct table updates via native SQL bypass business logic and validation entirely, which is why BAPIs are the standard, safer approach for creating/changing business data.A classic SOAP-based web service exchanges structured XML messages, typically used for system-to-system integration. An OData service exposes data in a RESTful, resource-based format specifically designed for consumption by Fiori/UI5 apps and mobile clients — OData is the standard for exposing SAP data to modern front-ends.
Add OData annotations (
@OData.publish: true, or explicit service definition/exposure via @UI and service binding objects) to the CDS view, then activate and publish it via the SAP Gateway/service binding tools (SEGW for classic, or the modern RAP — RESTful ABAP Programming model) so it becomes callable as a proper REST/OData endpoint.Extending an IDoc segment adds custom fields to a standard IDoc type without modifying SAP's original segment definition — done via a custom segment linked to the standard IDoc type. It's needed when a standard IDoc (like ORDERS05) doesn't carry a custom field your business process requires for outbound/inbound processing.
BAPI_TRANSACTION_COMMIT is specifically designed to be called after BAPI usage, since BAPIs often use their own internal update logic and this BAPI ensures that update is properly triggered and, optionally, waits for confirmation. A plain COMMIT WORK triggers the standard SAP LUW (logical unit of work) commit but isn't guaranteed to correctly finalize BAPI-specific update processing in all cases.Include an idempotency key (like a unique external document reference) that's checked before processing, log processing status per message so retries can detect 'already processed', and prefer queued/transactional RFC or IDoc mechanisms that have built-in guaranteed-delivery semantics over rolling your own retry logic from scratch.
The ABAP developer typically builds the actual data mapping, business logic, and processing (BAPI wrapper, IDoc processing function, or CDS/OData exposure). The Basis/integration (often PI/PO or middleware) team handles connectivity, adapters, routing, and monitoring of the message flow between systems — understanding this division is itself a common interview question about how you collaborate cross-team.
Modern S/4HANA Development
ABAP on HANA — CDS & AMDP
15 Questions
The current standard for S/4HANA development. Expect these questions in any interview for a company running or migrating to S/4HANA — this is where the field is heading.
A CDS (Core Data Services) View defines a data model at the database layer using SQL-like DDL, supporting associations, calculated fields, aggregations, and OData/Fiori annotations. It matters because CDS is the standard data-modeling layer across S/4HANA and Fiori — most new development starts from a CDS view rather than a classic ABAP report reading raw tables.
AMDP lets you write native SQLScript that executes directly inside the HANA database, called from ABAP like a regular class method, while SAP handles versioning, transport, and lifecycle. Used when you need HANA-native performance for complex, data-heavy calculations too slow for row-by-row classic ABAP.
Code pushdown means moving data-intensive logic — filtering, joins, aggregation — down to the HANA database via CDS Views and AMDPs, instead of pulling large raw datasets up into the application server. It's central to ABAP on HANA because it leverages HANA's in-memory, columnar processing power, dramatically cutting data transfer and processing time.
A CDS association defines a reusable relationship between two CDS entities without immediately executing a join — the join only happens when associated fields are actually exposed or used ('late materialization'). A classic SQL JOIN always executes immediately regardless of whether all joined fields end up being used.
AMDP debugging uses the standard ABAP Debugger, but because logic runs inside the database as SQLScript rather than ABAP bytecode, you need HANA-specific debugger integration enabled plus appropriate authorizations on the HANA side.
Annotations add metadata to a CDS view controlling how it behaves or is exposed — e.g.
@AbapCatalog.sqlViewName (defines the underlying SQL view name), @OData.publish: true (exposes it as an OData service), @Analytics.query: true (marks it for analytical consumption), and @UI.lineItem (controls Fiori list display).A Basic/Interface view sits close to the database table, does minimal transformation, and is meant to be reused as a building block. A Consumption view builds on top of basic views, adding business logic, associations, and UI annotations, and is meant to be directly consumed by an app or report — this layered approach is a core CDS design pattern SAP expects developers to follow.
A CDS table function lets you implement a CDS view's logic using an AMDP (SQLScript) instead of the standard CDS DDL syntax — used when the required logic (complex procedural calculations, certain HANA-specific functions) can't be expressed in plain CDS view syntax alone.
The VDM is SAP's layered structure of standard CDS views (Basic → Composite → Consumption) that make up the official, supported data model across S/4HANA — analogous to how classic ECC had standard tables, the VDM is the standard reusable data layer new development should build on top of rather than querying raw tables directly.
RAP is SAP's current framework for building full transactional Fiori apps — it uses CDS views as the data model foundation, adds behavior definitions (create/update/delete logic) and behavior implementations, and exposes the result as an OData service. It's positioned as the successor to the older BOPF-based approach for new S/4HANA app development.
Using the
@AccessControl annotation linked to a DCL (Data Control Language) source, which defines the authorization logic (e.g. checking against an authorization object) applied automatically whenever the CDS view is accessed — keeping security enforcement centralized at the data layer rather than scattered across every consuming report.Aggregating in a CDS view means HANA computes the sums/groupings in-memory using its columnar engine before any data crosses into the ABAP application server — often orders of magnitude less data transferred and processed. Aggregating in ABAP means pulling every detail row up first, which defeats much of HANA's performance advantage.
Classic
EXEC SQL lets you embed native database SQL directly in an ABAP program but is tied to that specific database and harder to maintain/transport cleanly. AMDP is HANA-specific, but integrates properly with ABAP's class/method model, transport system, and version management — it's the modern, supported replacement for ad hoc native SQL in HANA-based development.Identify where the report pulls large volumes of raw data and aggregates/filters it in ABAP loops, then redesign that logic as a CDS view (or AMDP for complex procedural logic) so HANA does the filtering/aggregation, and have the ABAP report simply consume the already-summarized result — this is the essence of a 'code pushdown' migration.
Yes — CDS views and AMDPs still sit inside a broader ABAP program structure, and the vast majority of a typical S/4HANA landscape's existing custom code, enhancements, and reports remain classic ABAP. Strong classic ABAP fundamentals are still the foundation CDS/AMDP skills are built on top of, which is exactly why interviews test both.
Ready to Practice Out Loud?
Reading the answers helps.
Mock interviews make it stick.
Book a free 30-minute demo class — get personalized guidance on SAP ABAP on HANA interview prep, see live SAP training, and find out if VoiSAP is the right fit. No obligation.
Live SAP System Access
Real hands-on SAP ABAP on HANA training, not slides.
Career Support Included
Resume, LinkedIn, mock interviews, and job search strategy.
86% Placement Outcomes*
Built around the exact topics in this guide.
Canada-Focused
Brampton, Calgary, Mississauga, Kitchener and across Canada.
We received your request!
Our team will reach out within a few hours to schedule your free demo class.
No commitment required · Typically respond within a few hours