SAP ABAP Interview Questions and Answers

The main principle is code-to-data (code pushdown): move data-intensive calculations to the database instead of transferring large datasets to the application server. Use ABAP SQL features such as aggregates, joins and expressions, CDS views for reusable data models, and AMDP only where ABAP SQL and CDS are not enough. Avoid unnecessary SELECT *, nested selects and processing large result sets row by row in ABAP.

Core Data Services (CDS) views are data models defined with an SQL-like DDL in ABAP Development Tools. They support joins, associations, calculations, aggregations, parameters and annotations that add semantics for analytics, UI, OData and access control. CDS views are the basis of the S/4HANA virtual data model, Fiori elements apps, analytical queries and RAP business objects.

DDIC-based CDS views (DEFINE VIEW with @AbapCatalog.sqlViewName) generate an additional SQL view in the Data Dictionary. CDS view entities (DEFINE VIEW ENTITY) do not need a separate SQL view, activate faster and have stricter, improved syntax checks. SAP recommends view entities for new development, and DDIC-based CDS views are considered obsolete.

A join is always executed when the view is read. An association defines a relationship that is only turned into a join when a field of the associated entity is actually requested (path expression) or when the association is exposed and followed by a consumer, such as an OData service. Associations make data models reusable and avoid unnecessary joins.

The VDM is SAP's structured set of CDS views in S/4HANA. Basic/interface views (I_ prefix) model business entities close to the tables, composite views combine them, and consumption views (C_ prefix) are tailored for specific apps or analytics. Released I_ views are the stable interface for custom development under clean core.

With CDS access control, defined in a DCL source with DEFINE ROLE. The role maps fields of the CDS entity to authorisation objects with PFCG_MAPPING (or other conditions). When the entity is read through ABAP SQL, the conditions are added automatically to the query. The annotation @AccessControl.authorizationCheck (#CHECK, #NOT_REQUIRED, etc.) controls whether access control is expected.

ABAP Managed Database Procedures let you implement methods in SQLScript inside an ABAP class marked with IF_AMDP_MARKER_HDB. The procedure is managed and transported with ABAP and created in SAP HANA on first call. Use AMDP for complex logic that ABAP SQL and CDS cannot express efficiently, such as multi-step calculations or HANA-specific functions. Prefer CDS and ABAP SQL first because they are database-independent and easier to maintain.

A CDS table function defines a CDS entity whose result is implemented by an AMDP function. It can be used like a CDS view in other CDS views and ABAP SQL, so complex SQLScript logic becomes part of the CDS data model. It is often used when a calculation cannot be expressed in a CDS view.

RAP is SAP's programming model for building transactional Fiori apps and Web APIs on the ABAP platform, in S/4HANA and the SAP BTP ABAP environment. Its main artefacts are:

• Data model – CDS view entities defining the business object structure (root and child entities).
• Behaviour definition – operations (create, update, delete), actions, determinations, validations, locking, ETags, draft and authorisation.
• Behaviour implementation – ABAP classes with the business logic.
• Projection and service definition – what is exposed to a consumer.
• Service binding – the protocol, such as OData V2 or V4, for a UI or Web API.

In a managed scenario the RAP framework handles standard operations, buffering and saving to the database tables; developers add determinations, validations and actions. In an unmanaged scenario the developer implements the transactional buffer and save logic, often to reuse existing legacy code such as BAPIs. A managed scenario can also use an additional save or unmanaged save for special persistence needs.

Draft lets users save incomplete changes on the server and continue later, with draft data stored in a separate draft table. The behaviour definition declares with draft, a draft table and draft actions such as Edit, Activate, Discard and Resume. Fiori elements apps then provide draft handling automatically, including locking the active instance while it is being edited.

Entity Manipulation Language is the ABAP syntax for accessing RAP business objects: READ ENTITIES, MODIFY ENTITIES (create, update, delete, execute actions) and COMMIT ENTITIES. Inside behaviour implementations, IN LOCAL MODE skips authorisation and feature control checks for the business object's own logic. EML results come back in MAPPED, FAILED and REPORTED structures.

• Determinations calculate or set values automatically when specified triggers occur, on modify or on save.
• Validations check data consistency on save and reject invalid instances through FAILED and REPORTED.
• Actions are custom operations, such as *approve* or *copy*, triggered by a user or API, optionally with parameters and a result.
• Feature control dynamically enables or disables fields and operations.

ABAP Cloud is SAP's development model for cloud-ready, upgrade-stable extensions. It uses a restricted ABAP language version, released APIs only, and RAP and CDS for new applications. It is available in the SAP BTP ABAP environment, in SAP S/4HANA Cloud and, as on-stack extensibility, in S/4HANA private cloud and on-premise.

SAP describes extensions with clean core levels A to D, from A (ABAP Cloud with released APIs, the most upgrade-stable) to D (techniques such as modifications or use of internal objects that create the highest upgrade risk). ATC checks help classify findings. This model replaced the earlier three-tier extensibility explanation, so use current terminology in interviews.

Inline declarations (DATA(...), FIELD-SYMBOL(...)), constructor expressions (VALUE, NEW, CORRESPONDING, CONV, CAST, COND, SWITCH, REDUCE, FILTER), table expressions (itab[ key = value ]) with line_exists and line_index, string templates (|Text { variable }|), FOR loops in constructor expressions, LOOP AT ... GROUP BY, and ABAP SQL with host expressions, CASE, joins and inline result tables.

• ST05 – SQL, buffer, enqueue and RFC trace; identifies expensive and repeated statements.
• SAT – runtime analysis, showing where time is spent in ABAP and database.
• ST12 – combined ABAP and SQL trace, widely used in support.
• SQLM and SWLT – SQL Monitor and SQL Performance Tuning Worklist for production hotspots.
• ATC / Code Inspector – static checks, including performance and S/4HANA readiness checks.
• ST22 and SM50/SM66 – dumps and running work processes.

Push aggregation to the database, read in packages with PACKAGE SIZE or cursors, use appropriate internal table types and secondary keys, avoid unnecessary copies by using field symbols or references, run in background jobs, and parallelise with asynchronous RFC (STARTING NEW TASK) or background RFC within the available work processes. Coordinate with Basis on resource limits.

Classic projects use the SAP Gateway Service Builder (SEGW) to model and implement OData V2 services, or reference CDS views with @OData.publish (obsolete for new development). Modern development uses RAP: define a service definition over projection views and create a service binding for OData V2 or V4, UI or Web API. The service is then published and consumed by Fiori elements or external clients.