SAP ABAP – Questions & Answers

ABAP (Advanced Business Application Programming) is SAP’s programming language for developing reports, interfaces, enhancements, forms and applications on the SAP application server.

• It runs on the SAP ABAP platform (AS ABAP) and works with the ABAP Dictionary and the database.
• Used for custom reports, enhancements, interfaces, conversions and Fiori back-end services.
• Modern ABAP supports object orientation, CDS views and the RESTful Application Programming Model.
• Developed in the ABAP Workbench (SE80) or ABAP Development Tools in Eclipse.

Level: Basic
Key terms: ABAP, AS ABAP, SE80, ADT

Executable programs (reports), module pools, function groups, class pools, include programs, subroutine pools, interface pools and type groups.

• Executable (type 1): reports started with SE38 or F8.
• Module pool (type M): dialog programs run through a transaction code.
• Function group: container for function modules.
• Class pool: global classes.
• Include: reusable source code.
• Subroutine pool: FORM routines called externally.

Level: Basic
Key terms: Report, module pool, function group, include, SE38

Elementary types (C, N, I, P, D, T, F, STRING, XSTRING), structures, internal tables and reference types.

• Complete types: D, T, I, STRING, XSTRING, F.
• Incomplete types: C, N, P, X, which need length.
• Use DATA, CONSTANTS, TYPES and FIELD-SYMBOLS.
• Inline declarations such as DATA(lv_var) = … are available in modern ABAP.
• Reference variables use REF TO.

Level: Basic
Key terms: DATA, TYPES, CONSTANTS, field symbol, inline declaration

Tables, structures, views, data elements, domains, search helps, lock objects and table types.

• Domain: technical attributes such as type and length.
• Data element: semantic meaning and labels.
• Table: database table with fields and keys.
• Structure: field group without database storage.
• Search help: value help.
• Lock object: creates enqueue and dequeue function modules.

Level: Basic
Key terms: SE11, domain, data element, lock object, search help

Standard, sorted and hashed tables.

• Standard: index access, append-based, linear search unless sorted.
• Sorted: always sorted by key, binary search for key access.
• Hashed: access by unique key only, constant access time.
• Choose based on how the data is read and updated.

Level: Basic
Key terms: STANDARD TABLE, SORTED TABLE, HASHED TABLE, READ TABLE

An internal table holds many rows, and a work area holds one row; a header line is an obsolete implicit work area.

• Use explicit work areas or field symbols in modern code.
• Header lines are not allowed in object-oriented contexts.
• LOOP AT itab INTO wa or ASSIGNING <fs> processes rows.
• Field symbols avoid copying data and are faster for large tables.

Level: Basic
Key terms: Work area, header line, field symbol, LOOP AT

Use includes for splitting source, FORM routines for local reuse, function modules for global procedural reuse and class methods for object-oriented reuse.

• Function modules are in function groups and called by CALL FUNCTION.
• Methods are preferred in new development.
• Subroutines (PERFORM) are obsolete for new global use.
• Macros are discouraged because they are harder to debug.

Level: Basic
Key terms: Include, FORM, function module, method, CALL FUNCTION

LOAD-OF-PROGRAM, INITIALIZATION, AT SELECTION-SCREEN, START-OF-SELECTION, END-OF-SELECTION, TOP-OF-PAGE and END-OF-PAGE.

• INITIALIZATION sets default values.
• AT SELECTION-SCREEN validates input.
• START-OF-SELECTION runs the main processing.
• END-OF-SELECTION runs after data selection.
• TOP-OF-PAGE and END-OF-PAGE format page headers and footers in list output.

Level: Basic
Key terms: INITIALIZATION, START-OF-SELECTION, AT SELECTION-SCREEN

Open SQL is database-independent and works with the ABAP buffer; Native SQL sends database-specific statements directly.

• Open SQL statements: SELECT, INSERT, UPDATE, DELETE, MODIFY.
• Native SQL uses EXEC SQL or ADBC and is database-specific.
• Open SQL supports table buffering and authority handling.
• Prefer Open SQL or CDS views unless there is a strong reason.

Level: Basic
Key terms: Open SQL, Native SQL, EXEC SQL, ADBC

Select only needed fields and rows, avoid SELECT inside loops, use indexes and push calculation to the database.

• Avoid SELECT *.
• Use WHERE conditions on key or indexed fields.
• Use joins or CDS instead of nested selects.
• Use SELECT … INTO TABLE rather than SELECT ENDSELECT for large volumes.
• Check performance with SAT and ST05.

Level: Intermediate
Key terms: SELECT, WHERE, index, ST05, SAT

FOR ALL ENTRIES selects based on an internal table and removes duplicates; a JOIN combines tables inside the database in one statement.

• FOR ALL ENTRIES must check that the driver table is not empty, or all rows are read.
• It removes duplicate result rows, so select all key fields.
• JOINs are usually more efficient when tables are in the database.
• Newer ABAP SQL supports joins with internal tables in recent releases.

Level: Intermediate
Key terms: FOR ALL ENTRIES, JOIN, empty driver table

Table buffering stores table data in the application server memory to avoid database reads; types are full, generic and single-record buffering.

• Suited to small, rarely changed tables such as configuration.
• Buffering is set in table technical settings.
• Buffer synchronisation can cause short delays between servers.
• SELECT with BYPASSING BUFFER reads from the database.

Level: Intermediate
Key terms: Table buffering, SE11, BYPASSING BUFFER

Runtime analysis (SAT), SQL trace (ST05), performance trace tools and the ABAP Test Cockpit.

• SAT shows runtime for ABAP statements and calls.
• ST05 records SQL, enqueue and RFC activity.
• ABAP Test Cockpit and Code Inspector check performance and security rules.
• SQL Monitor (SQLM) can show production hot spots.

Level: Intermediate
Key terms: SAT, ST05, ATC, SCI, SQLM

Code pushdown moves data-intensive logic into the database using CDS views and AMDP instead of processing it in ABAP.

• Reduces the data transferred to the application server.
• CDS views handle aggregations, joins and calculations.
• AMDP lets you write SQLScript in an ABAP class when CDS is not enough.
• Always compare performance before and after.

Level: Advanced
Key terms: Code pushdown, CDS, AMDP, SQLScript

Inline declarations, SQL expressions such as CASE, COALESCE and string functions, aggregates, UNION and common table expressions in newer releases.

• Use @ to escape host variables in the new syntax.
• Expressions reduce the need for post-processing in ABAP.
• Availability depends on the ABAP release, so check the documentation.
• Combine with CDS to push calculations down.

Level: Intermediate
Key terms: ABAP SQL, @ host variable, CASE, COALESCE

A class is a blueprint with attributes and methods, and an object is an instance created from it.

• Local classes are defined in a program; global classes are created in SE24 or ADT.
• Objects are created with NEW or CREATE OBJECT.
• Classes support encapsulation, inheritance and polymorphism.

Level: Basic
Key terms: CLASS, SE24, NEW, CREATE OBJECT

PUBLIC, PROTECTED and PRIVATE sections control which code can access components.

• PUBLIC components are available to all.
• PROTECTED components are available to the class and subclasses.
• PRIVATE components are available only inside the class.
• Use private attributes with public methods to encapsulate data.

Level: Basic
Key terms: PUBLIC SECTION, PROTECTED SECTION, PRIVATE SECTION

Inheritance reuses a superclass, polymorphism lets subclasses change behaviour, and interfaces define contracts that classes implement.

• Use INHERITING FROM to create a subclass.
• Redefine methods with REDEFINITION.
• A class can implement several interfaces but inherit from only one class.
• Use the interface type for flexible code and testing.

Level: Intermediate
Key terms: INHERITING FROM, REDEFINITION, INTERFACE, polymorphism

Static components belong to the class and are shared by all instances; instance components belong to each object.

• Declare with CLASS-DATA and CLASS-METHODS for static.
• Static components are called with class=>component.
• Instance components are called with object->component.
• The static constructor runs once before first use.

Level: Basic
Key terms: CLASS-DATA, CLASS-METHODS, =>, ->

Constructors initialise objects, and events let a class notify other classes using RAISE EVENT and handler methods.

• The instance constructor runs when an object is created.
• The static constructor runs once per class.
• Events are declared with EVENTS and handled with FOR EVENT.
• Use SET HANDLER to register handlers.

Level: Intermediate
Key terms: CONSTRUCTOR, CLASS_CONSTRUCTOR, RAISE EVENT, SET HANDLER

Use TRY … CATCH … CLEANUP with exception classes derived from CX_ classes, and RAISE EXCEPTION to throw them.

• Exception categories: CX_STATIC_CHECK, CX_DYNAMIC_CHECK and CX_NO_CHECK.
• Methods declare exceptions with RAISING.
• Use custom exception classes for business errors.
• Avoid class-based and classic exceptions mixed in new code.

Level: Intermediate
Key terms: TRY, CATCH, CX_ class, RAISE EXCEPTION

Use ABAP Unit with local test classes, test doubles and patterns such as factory and dependency injection for testable code.

• Test classes use FOR TESTING and run via ADT or SE80.
• Dependency injection and interfaces allow test doubles.
• Singleton and factory patterns are common.
• ABAP Test Cockpit can enforce unit test coverage.

Level: Advanced
Key terms: ABAP Unit, FOR TESTING, test double, factory

CL_SALV_TABLE is the recommended simple approach; CL_GUI_ALV_GRID gives more control; REUSE_ALV_GRID_DISPLAY is the older function module.

• CL_SALV_TABLE needs little code and supports sorting, filtering and layouts.
• CL_GUI_ALV_GRID needs a screen and container but allows full customisation.
• REUSE function modules are obsolete for new development.
• Fiori apps usually replace ALV for user-facing screens.

Level: Basic
Key terms: CL_SALV_TABLE, CL_GUI_ALV_GRID, REUSE_ALV_GRID_DISPLAY

Selection screens collect user input; PARAMETERS takes a single value and SELECT-OPTIONS takes ranges.

• SELECT-OPTIONS creates a table with SIGN, OPTION, LOW and HIGH.
• Use the IN operator in WHERE conditions.
• SELECTION-SCREEN BEGIN OF BLOCK groups fields.
• Validate input in AT SELECTION-SCREEN.

Level: Basic
Key terms: PARAMETERS, SELECT-OPTIONS, SELECTION-SCREEN, IN operator

Classical reports produce a single list; interactive reports let users drill down to detail lists using events.

• Use AT LINE-SELECTION for double click on a line.
• HIDE stores values for the selected line.
• AT USER-COMMAND handles menu buttons.
• Interactive lists can have up to 20 secondary lists.

Level: Basic
Key terms: AT LINE-SELECTION, HIDE, AT USER-COMMAND, sy-lsind

Module pool programs build custom screens with flow logic (PBO and PAI) and ABAP modules, started through a transaction code.

• PBO (Process Before Output) prepares the screen.
• PAI (Process After Input) handles user actions.
• Screens are designed in the Screen Painter (SE51).
• Use screen elements such as table controls and subscreens.

Level: Intermediate
Key terms: SE51, PBO, PAI, flow logic, table control

SAPscript is the oldest form tool, Smart Forms is graphical and function-module based, and Adobe Forms uses Adobe LiveCycle Designer for rich layouts.

• Smart Forms is created with SMARTFORMS and generates a function module.
• Adobe Forms uses an interface and a layout, and is the recommended tool for new output.
• SAPscript is obsolete for new development.
• Adobe Forms integrates with output management in S/4HANA.

Level: Basic
Key terms: SAPscript, SMARTFORMS, Adobe Forms, SFP

ABAP developers build the back-end services (OData, CDS, RAP) that SAPUI5 and Fiori front ends consume.

• Create CDS views and expose them as OData services.
• Implement business logic in RAP behaviours or classes.
• Manage authorisations and error handling.
• Front-end work uses SAPUI5, often built in SAP Business Application Studio.

Level: Intermediate
Key terms: OData, CDS, RAP, SAPUI5, Fiori

User exits, customer exits, BAdIs, enhancement points and sections, implicit enhancements and, as a last resort, modifications.

• User exits are include-based and mostly for SD.
• Customer exits use function modules with CMOD and SMOD.
• BAdIs are the object-oriented enhancement technique.
• The Enhancement Framework supports points and sections.
• Modifications change SAP code and must be avoided.

Level: Basic
Key terms: User exit, customer exit, BAdI, enhancement framework

Classic BAdIs use class-based definitions with SE18 and SE19; new (kernel) BAdIs are part of the Enhancement Framework and offer better performance and switch support.

• Both are implemented in SE19.
• New BAdIs support filters, multiple use and enhancement spots.
• Definitions are created in SE18 inside an enhancement spot.
• New BAdIs are called with GET BADI and CALL BADI.

Level: Intermediate
Key terms: SE18, SE19, GET BADI, CALL BADI, enhancement spot

Search by application area using SE84, SPRO, SMOD and SE18, or set breakpoints on CALL BADI and CALL CUSTOMER-FUNCTION in debugging.

• Search in SE84 for enhancements.
• Check the SPRO IMG for the module.
• In debug mode, break on statement CALL BADI.
• Use the where-used list on classes like CL_EXITHANDLER.

Level: Intermediate
Key terms: SE84, SMOD, CMOD, CL_EXITHANDLER, debugger

User exits are programmed modifications in SAP includes, mainly in SD; customer exits are function-module based and are managed through SMOD and CMOD.

• User exits need an access key and are less upgrade-safe.
• Customer exits are created in CMOD projects using SMOD enhancements.
• Both are older than BAdIs.
• Use BAdIs where possible.

Level: Intermediate
Key terms: User exit, customer exit, SMOD, CMOD

A modification changes SAP standard objects, and it must be reviewed after upgrades using SPAU and SPDD.

• Modifications require an access key.
• SPDD adjusts dictionary changes and SPAU adjusts repository objects.
• They increase upgrade effort and risk.
• Use enhancements or clean core options instead.

Level: Intermediate
Key terms: SPAU, SPDD, modification, access key

Explicit enhancements are predefined points and sections; implicit enhancements are available at the start and end of procedures without predefinition.

• Implicit enhancement points exist at the end of programs, includes and function modules.
• Explicit enhancement points allow added code at defined spots.
• Enhancement sections let you replace standard code.
• Created in SE80 or ADT within the enhancement framework.

Level: Intermediate
Key terms: Enhancement point, enhancement section, implicit enhancement

Key-user extensibility lets business users add custom fields, logic and UI changes through Fiori apps without writing ABAP.

• The Custom Fields and Logic app handles fields and simple rules.
• Changes are transported through the normal landscape.
• It is upgrade-safe and works in public cloud editions.
• Complex needs still require developer extensibility.

Level: Intermediate
Key terms: Custom Fields and Logic, key user, in-app extensibility

ABAP Cloud is the modern ABAP development model that uses only released APIs and objects, to keep the core clean and upgrade-stable.

• Development is done in ADT with the cloud-ready language version.
• You may only use released objects, such as APIs with a C1 contract.
• It supports RAP for services and extension of SAP apps.
• Classic ABAP remains for existing code, but new extensions should follow ABAP Cloud.

Level: Advanced
Key terms: ABAP Cloud, released API, C1 contract, ADT

BDC (Batch Data Communication) automates data entry by recording screens; call transaction processes immediately and session method stores sessions for later.

• Call transaction is faster and supports modes A, N and E.
• Session method uses BDC_OPEN_GROUP and BDC_INSERT and runs through SM35.
• Session method has better error logging and restart.
• For S/4HANA, prefer migration objects, BAPIs or APIs.

Level: Intermediate
Key terms: BDC, CALL TRANSACTION, SM35, BDCDATA

LSMW (Legacy System Migration Workbench) is a tool for loading data with recording, IDoc or BAPI methods; it is still available but not recommended for new S/4HANA projects.

• Steps include maintaining objects, source structures, field mapping and conversion.
• The Migration Cockpit is preferred for S/4HANA.
• LSMW may still be used in some ECC projects.
• Check release notes.

Level: Intermediate
Key terms: LSMW, migration cockpit, recording, IDoc method

An IDoc is a standard SAP document format for exchanging data, made of a control record, data records and status records.

• WE20 sets partner profiles and WE21 sets ports.
• WE02 and WE05 display IDocs.
• WE19 tests IDocs and BD87 reprocesses them.
• Message types and basic types define structure.

Level: Intermediate
Key terms: WE02, WE05, WE20, WE19, BD87

RFC (Remote Function Call) lets systems call function modules remotely, and a BAPI is a stable, released RFC-enabled function for a business object.

• RFC types: synchronous, asynchronous, transactional and queued.
• BAPIs return messages in BAPIRET2.
• After write BAPIs, call BAPI_TRANSACTION_COMMIT.
• BAPIs are found in transaction BAPI.

Level: Intermediate
Key terms: RFC, BAPI, BAPIRET2, BAPI_TRANSACTION_COMMIT

Use the SAP Gateway Service Builder (SEGW) or expose a CDS view or RAP service binding.

• SEGW lets you define entities and implement CRUD methods.
• CDS-based services use annotations like @OData.publish or service definitions.
• Services are registered and tested in the gateway maintenance transactions.
• RAP service bindings are the modern choice.

Level: Intermediate
Key terms: SEGW, CDS, RAP service binding, /IWFND/MAINT_SERVICE

An SAP LUW groups database changes that are committed together; update function modules and locks make sure changes are consistent.

• COMMIT WORK triggers update function modules and ends the LUW.
• ROLLBACK WORK cancels changes.
• Lock objects create enqueue and dequeue function modules.
• Check locks in SM12 and update failures in SM13.

Level: Intermediate
Key terms: COMMIT WORK, update task, ENQUEUE, SM12, SM13

CDS (Core Data Services) views define data models in the database layer with annotations that add semantics, UI and OData behaviour.

• Defined with DEFINE VIEW ENTITY in current releases.
• Associations replace many joins.
• Annotations include @AbapCatalog, @UI, @OData and @Analytics.
• Access control is defined using DCL.

Level: Intermediate

Key terms: CDS, DEFINE VIEW ENTITY, association, annotation, DCL

ABAP Managed Database Procedures let you write SQLScript inside an ABAP class method when CDS cannot express the logic.

• Implemented with the interface IF_AMDP_MARKER_HDB.
• Runs in the HANA database.
• Good for complex calculations over big data sets.
• Harder to test and tied to the database.

Level: Advanced

Key terms: AMDP, SQLScript, IF_AMDP_MARKER_HDB

RAP is the modern framework for building OData services and Fiori apps, based on CDS views and behaviour definitions.

• Layers: data model (CDS), behaviour definition and implementation, service definition and binding.
• Scenarios: managed (framework handles persistence) and unmanaged (you implement).
• Supports draft handling, validations and determinations.
• Used for both new apps and extensions.

Level: Advanced

Key terms: RAP, behavior definition, managed, unmanaged, draft

SE80 is the classic SAP GUI workbench, and ADT is the Eclipse-based development environment needed for CDS, RAP and ABAP Cloud.

• ADT offers code completion, refactoring, quick fixes and integrated tests.
• New objects such as CDS and RAP are developed in ADT.
• SE80 is still used for classic objects.
• Many teams use both.

Level: Intermediate

Key terms: SE80, ADT, Eclipse, quick fix

Inline declarations, string templates, table expressions, constructor expressions such as VALUE, NEW, REDUCE and COND, and FOR loops.

• DATA(var) = … declares variables inline.
• String templates use |text { var }|.
• Table expressions read rows as itab[ key = value ].
• VALUE, REDUCE and COND build data in one statement.
• Availability depends on the ABAP release.

Level: Intermediate

Key terms: Inline declaration, string template, VALUE, REDUCE, COND

Use the ABAP debugger with breakpoints and watchpoints, and analyse runtime errors in ST22.

• Enter /h in the command field to start debugging.
• Breakpoints can be session or external in ADT.
• Watchpoints stop when a variable changes.
• ST22 shows short dumps and SM21 shows the system log.

Level: Intermediate

Key terms: /h, breakpoint, watchpoint, ST22, SM21

Changes are collected in transport requests (workbench for repository objects, customizing for configuration) and moved through the landscape using STMS.

• Create and release requests in SE09 or SE10.
• Import into QA and production through STMS.
• Workbench requests are client-independent and customizing requests are client-specific.
• Run ATC checks before release.

Level: Intermediate

Key terms: SE09, SE10, STMS, workbench request, customizing request

ATC runs static checks for quality, performance, security and S/4HANA readiness on ABAP code.

• Checks are configured as check variants.
• Run from ADT or SE80 and during transport release.
• Findings can be exempted with approvals.
• Supports custom code migration and clean core checks.

Level: Advanced

Key terms: ATC, check variant, SCI, readiness check