SAP C-ABAPD-2507 Exam Questions
Questions for the C-ABAPD-2507 were updated on : Dec 01 ,2025
Page 1 out of 6. Viewing questions 1-15 out of 80
Question 1
HOTSPOT
In what order are objects created to generate a RESTful Application Programming application?
Answer:
None
Explanation:
Database table
Data model view
Projection view
Service definition
Service binding
In RAP, the development flow follows a bottom-up approach, beginning with persistence and ending
with OData exposure:
Database table:
The persistence layer where data is stored. This is the foundation of the business object model.
Data model view (CDS entity):
The CDS view is defined on top of the database table to provide a semantic data model. It represents
entities like Travel or Booking.
Projection view:
Provides an abstraction of the data model view and controls which fields and associations are
exposed externally.
Service definition:
Specifies which projection views (entities) are exposed in the OData service.
Service binding:
Connects the service definition to a communication protocol (e.g., OData V2 or V4), generating the
final consumable service endpoint.
This sequence ensures a layered architecture consistent with RAP guidelines:
Persistence layer → Data model layer → Projection layer → Service layer → Binding to protocol.
Reference: SAP Help 1, pages 4–6 — RAP design time development flow (data modeling, business
service provisioning, service consumption).
Question 2
Given the following Core Data Service view entity data definition:
@AccessControl.authorizationCheck: #NOT_REQUIRED
DEFINE VIEW ENTITY demo_cds_param_view_entity
WITH PARAMETERS
p_date : abap.dats
AS SELECT FROM sflight
{
key carrid,
key connid,
key fldate,
price,
seatsmax,
seatsocc
}
WHERE fldate >= $parameters.p_date;
Which of the following ABAP SQL snippets are syntactically correct ways to provide a value for the
parameter on line #4?
Note: There are 2 correct answers to this question.
- A. SELECT * FROM demo_cds_param_view_entity( p_date = '20230101' ) ...
- B. SELECT * FROM demo_cds_param_view_entity( p_date = @( cl_abap_context_info=>get_system_date( ) ) ) ...
- C. SELECT * FROM demo_cds_param_view_entity( p_date = `20230101` ) ...
- D. SELECT * FROM demo_cds_param_view_entity( p_date = :$session.system_date ) ...
Answer:
A, B
Explanation:
Parameters in CDS view entities (WITH PARAMETERS) must always be supplied when querying. In
ABAP SQL, the syntax rules are:
A. Correct
Supplying a literal date ('20230101') directly is valid because the parameter p_date is of type
abap.dats.
B. Correct
Supplying a value via an ABAP expression using @( ... ) is syntactically correct. Here,
cl_abap_context_info=>get_system_date( ) returns the current system date in ABAP Cloud-compliant
way, and is wrapped with @() for expression embedding. This is the best practice in ABAP Cloud
development.
C. Incorrect
Backticks (`...`) are used in ABAP for string templates, not for literals in this context. A date literal
must be in quotes '...'.
D. Incorrect
:$session.system_date is not valid in ABAP SQL. Session variables like $session.* are supported in
HANA SQL, but in ABAP CDS view consumption via ABAP SQL, this is not allowed.
Therefore, only A and B are correct.
Reference:
ABAP CDS Development User Guide – section on CDS View Entity Parameters and ABAP SQL
parameter passing rules; ABAP Cloud development guidelines on
cl_abap_context_info=>get_system_date.
Question 3
You want to join two database tables, T_CARRIER and T_CONNECTIONS, to retrieve all carriers,
whether they have corresponding connections or not.
Which statements would achieve this?
Note: There are 2 correct answers to this question.
- A. SELECT FROM t_carrier INNER JOIN t_connections ON ...
- B. SELECT FROM t_carrier LEFT OUTER JOIN t_connections ON ...
- C. SELECT FROM t_carrier LEFT INNER JOIN t_connections ON ...
- D. SELECT FROM t_connections RIGHT OUTER JOIN t_carrier ON ...
Answer:
B, D
Explanation:
The requirement is:
Retrieve all carriers from T_CARRIER
Include them even if no corresponding connections exist in T_CONNECTIONS.
Evaluation of each join type:
A. INNER JOIN:
Only returns rows where a carrier has at least one matching connection.
Incorrect, since carriers without connections would be excluded.
B. LEFT OUTER JOIN (correct):
Returns all rows from the left table (T_CARRIER), and connections if they exist.
Missing connections are represented with NULL.
Correct answer.
✔
C. LEFT INNER JOIN:
This is syntactically invalid in ABAP SQL. INNER JOIN and LEFT OUTER JOIN are separate join types,
not combined.
Incorrect.
D. RIGHT OUTER JOIN (correct):
Equivalent to LEFT OUTER JOIN when the tables are reversed.
Returns all rows from T_CARRIER, whether or not connections exist.
Correct answer.
✔
Thus, LEFT OUTER JOIN and RIGHT OUTER JOIN are the valid solutions to retrieve all carriers
regardless of connections.
Reference: ABAP CDS Development Guide – section on SQL Joins; ABAP SQL join semantics for
INNER, LEFT OUTER, and RIGHT OUTER joins.
Question 4
Which function call returns 0?
- A. find( val = 'FIND Found found' sub = 'F' occ = -2 CASE = abap_true )
- B. find( val = 'find FOUND Found' sub = 'F' occ = -2 CASE = abap_false )
- C. find( val = 'FIND FOUND FOUND' sub = 'F' )
- D. find( val = 'find Found FOUND' sub = 'F' occ = -2 )
Answer:
A
Explanation:
The FIND function in ABAP searches for a substring (sub) inside a string (val) and returns the offset
(position) if found, or 0 if not found.
Let’s evaluate Option A:
find( val = 'FIND Found found' sub = 'F' occ = -2 CASE = abap_true )
occ = -2: Searches for the second-last occurrence.
CASE = abap_true: Enforces case-sensitive search.
The string contains:
'FIND' → matches 'F' (1st occurrence)
'Found' → matches 'F' (2nd occurrence)
'found' → does not match because of lowercase 'f' and case-sensitive flag.
So, valid case-sensitive matches for 'F' are:
1st: 'FIND'
2nd: 'Found'
Thus, the second-last occurrence is 'FIND'.
But since occ = -2 returns the 2nd-last match, and we're counting backwards, it returns offset of
'FIND'.
Wait: the confusion is in expecting 0 when there’s no valid match for the specified occurrence.
But actually:
Option A does return 0 because occ = -2 expects at least 2 valid case-sensitive matches, and:
'Found' contains 'F' → match
'FIND' contains 'F' → match
So there are two matches.
BUT, occ = -2 is a reverse index.
First-last: 'Found'
Second-last: 'FIND'
It should return match offset for 'FIND' = 1 (NOT 0)
So, correction: A does NOT return 0.
Question 5
HOTSPOT
When you work with a test class, you can set up some prerequisites before the actual testing.
In which sequence will the following fixtures be called by the test environment?
Answer:
None
Explanation:
class_setup( )
setup( )
teardown( )
class_teardown( )
ABAP Unit Test framework defines a fixed sequence for test fixture methods to ensure reliable test
execution and cleanup:
class_setup( ):
Called once before any tests in the test class are run. Used to prepare global test data or setup that
applies to all tests.
setup( ):
Called before each individual test method to prepare local test data or preconditions.
teardown( ):
Called after each individual test method to clean up what was done in setup( ).
class_teardown( ):
Called once after all tests have been executed to clean up class-level resources.
This sequence supports isolation and repeatability of test executions, ensuring that one test's result
does not influence another’s.
Reference: ABAP Unit Test Framework Documentation, ABAP Cloud Programming Model Guidelines
– Test Class Lifecycle Management.
Question 6
Given the following code excerpt that defines an SAP HANA database table:
DEFINE TABLE demo_table
{
KEY field1 : REFERENCE TO abap.clnt(3);
KEY field2 : abap.char(1332);
@Semantics.quantity.unitOfMeasure : 'demo_table.field4'
field3 : abap.quan(2);
field4 : abap.unit(2);
}
Which field is defined incorrectly?
- A. field2
- B. field3
- C. field4
- D. field1
Answer:
A
Explanation:
Let’s evaluate each field:
field1: Defined as REFERENCE TO abap.clnt(3) — this is correct. It follows standard definition for
client fields.
field2: Defined as abap.char(1332) — this is incorrect. In ABAP CDS view entities, the maximum
length for CHAR fields is limited to 1333 bytes total row size for all fields in a view or table. A single
CHAR(1332) is almost the full limit and considered impractical or invalid in real implementations.
field3: Defined as abap.quan(2) — this is correct, representing a quantity field with 2 decimal places.
field4: Defined as abap.unit(2) — this is correct and compatible with the
@Semantics.quantity.unitOfMeasure annotation used in field3.
Therefore, field2 is the invalid field due to its excessive length, likely breaching the allowable
memory layout in the HANA table or violating SAP CDS limits.
Reference:
ABAP CDS Development Guide, section 2.1 – Table definitions and ABAP type length constraints; SAP
Help 3, page 6 – maximum lengths for data elements and supported annotations.
Question 7
Given the following ABAP SQL statement excerpt from an ABAP program:
SELECT SINGLE *
FROM spfli
WHERE carrid = 'LH' AND connid = '0400'
INTO @DATA(wa).
You are given the following information:
The data source spfli on line #2 is an SAP HANA database table.
spfli will be a large table with over one million rows.
This program is the only one in the system that accesses the table.
This program will run rarely.
Based on this information, which of the following general settings should you set for the spfli
database table?
Note: There are 2 correct answers to this question.
- A. “Storage Type” to “Row Store”
- B. “Storage Type” to “Column Store”
- C. “Load Unit” to “Column Loadable”
- D. “Load Unit” to “Page Loadable”
Answer:
A, D
Explanation:
In SAP HANA, the choice of storage type and load unit depends on access patterns, table size, and
usage frequency.
Here’s how each part applies:
A . "Storage Type" to "Row Store" – This is correct.
Since:
The table is accessed by only one program.
The program runs rarely.
The access pattern is row-oriented (SELECT SINGLE with filters).
Row store is more suitable for rare access with small result sets and no aggregation.
D . "Load Unit" to "Page Loadable" – This is correct.
Since the program runs infrequently, loading the entire column into memory (column loadable) is
not efficient. Page-loadable units load only required parts into memory on demand, which reduces
memory footprint.
Incorrect options:
B . "Storage Type" to "Column Store" – Incorrect here. Column store is ideal for frequent reads,
aggregations, or analytics, not for rarely accessed tables with simple lookups.
C . "Load Unit" to "Column Loadable" – Also not optimal for rarely accessed data. Column loadable
preloads entire columns into memory, which is memory-intensive and unnecessary in this case.
Reference:
ABAP CDS Development Guide and SAP HANA Table Storage Guidelines – Recommended storage
strategies based on access pattern, frequency, and usage role.
Question 8
In a booking record, how can you calculate the difference in days between the order date (type D)
and the flight date (type D) of a flight?
- A. data(gv_diff_days) = conv d( gs_booking-flight_date - gs_booking-order_date ).
- B. data(gv_diff_days) = gs_booking-flight_date - gs_booking-order_date.
- C. data(gv_diff_days) = gs_booking-order_date - gs_booking-flight_date.
- D. data(gv_diff_days) = conv d( gs_booking-order_date - gs_booking-flight_date ).
Answer:
B
Explanation:
In ABAP, when calculating the difference between two date fields (type DATS), the result is directly a
type i (integer) representing the difference in days.
Statement B is correct:
data(gv_diff_days) = gs_booking-flight_date - gs_booking-order_date.
This directly subtracts two DATS fields, resulting in an integer value for the number of days
difference. No conversion is necessary.
Statements A and D are incorrect because the conv d( ... ) attempts to convert the result back to a
DATS type, which is invalid since the result is an integer (number of days), not a date.
Statement C is syntactically correct but would produce the negative of the desired value (flight date -
order date). It is semantically incorrect for the use case.
This approach is consistent with ABAP for Cloud Development, which requires explicit typing, and
ABAP language version strict mode, where automatic type inference is restricted.
Reference: ABAP Language Documentation – DATS arithmetic and date operations section; consistent
with ABAP Cloud version restrictions.
Question 9
Which of the following rules apply for dividing with ABAP SQL?
Note: There are 3 correct answers to this question.
- A. The division operator “/” accepts decimal input.
- B. Numeric function division( numerator, denominator, decimal places ) accepts decimal input.
- C. Numeric function div( numerator, denominator ) expects only integer input.
- D. The division operator “/” accepts floating point input.
- E. Numeric function division( numerator, denominator, decimal places ) accepts floating point input.
Answer:
B, C, E
Explanation:
In ABAP SQL, the handling of arithmetic operations — especially division — is handled with care for
data types and precision. Here’s how each applies:
B . Numeric function division(numerator, denominator, decimal places) accepts decimal input
This is correct. The division function is designed for decimal-based calculations, where precision
control is needed via the third parameter (number of decimal places). It supports packed numbers
(DEC).
C . Numeric function div(numerator, denominator) expects only integer input
This is correct. The div function is an integer division operator, returning an integer result and only
accepts integers as input types.
E . Numeric function division(numerator, denominator, decimal places) accepts floating point input
This is correct. In addition to decimals, division() can also work with floating point types (FLTP),
enabling flexible division where decimals are not sufficient.
A . The division operator “/” accepts decimal input
This is incorrect in the context of ABAP SQL. The / operator is not available as a built-in operator in
Open SQL; arithmetic operations like this are not supported with native operators — only via
functions.
D . The division operator “/” accepts floating point input
Again, this is incorrect, as / is not valid syntax in ABAP SQL queries. Only built-in functions like div or
division are supported in the CDS/Open SQL layer.
Reference:
ABAP CDS Development Guide, section 2.2 – Built-in functions in ABAP SQL and CDS expressions for
numerical calculations, specifically division() and div().
Question 10
Given the following code which defines an SAP HANA database table in SAP S/4HANA Cloud, public
edition:
@EndUserText.label : 'Draft table for entity /DMO/R_AGENCY'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table /dmo/agency_d {
key mandt
: mandt not null;
key agencyid : /dmo/agency_id not null;
key draftuuid : sdraft_uuid not null;
name
: /dmo/agency_name;
street
: /dmo/street;
postalcode
: /dmo/postal_code;
city
: /dmo/city;
}
You are a consultant and the client wants you to extend this SAP database table with a new field
called zz_countrycode on line #14.
Which of the following is the correct response?
- A. The database table can be extended whether extensibility enabled or not if it is assigned to a software component of type “Standard ABAP”.
- B. The database table cannot be extended since it has not been extensibility enabled by SAP.
- C. The database table can be extended once it has extensibility been enabled by the customer.
- D. The database table can be extended whether extensibility enabled or not if it is assigned to a software component of type “ABAP Cloud”.
Answer:
B
Explanation:
In SAP S/4HANA Cloud, public edition, database tables are only extendable if SAP has explicitly
enabled extensibility for them via metadata. This is a strict limitation in the ABAP Cloud model to
ensure upgrade-stability and isolation of extensions from SAP-owned objects.
Key facts:
The annotation @AbapCatalog.dataMaintenance : #RESTRICTED implies that this table is not editable
or extensible by default.
The table resides in a delivered component and unless SAP marks it as extensible, customers cannot
add fields like zz_countrycode.
Even if the table is in an ABAP Cloud-compliant software component, extensibility must be explicitly
enabled by SAP.
Therefore, Option B is the only correct and valid answer.
Incorrect options:
Option A and D are wrong because extensibility is not determined by the software component type
alone.
Option C is wrong because customers cannot enable extensibility for SAP-delivered tables; it must be
pre-approved by SAP.
Reference: ABAP Extension Guidelines for SAP S/4HANA Cloud (ABAP Extension.pdf, section 2.3 –
Extensibility Enablement and Restrictions in Tier 1)
Question 11
You want to extract date information of a flight date (f_info) and format it like yyyy-dd-mm using the
following code:
SELECT FROM TABLE dbtab1
FIELDS f1,
extract_year( f_info ) && '-' && extract_month( f_info ) && '-' && extract_day( f_info ) ...
For the extract_* functions to work, what can be the data dictionary types of f_info?
Note: There are 3 correct answers to this question.
- A. TIMS
- B. UTCLONG
- C. TIMESTAMP
- D. DATS
- E. TIMN
Answer:
B, C, D
Explanation:
The EXTRACT_YEAR, EXTRACT_MONTH, and EXTRACT_DAY functions in ABAP SQL are SQL built-in
functions used for extracting date components. These functions are only supported for timestamp-
capable or date-capable fields.
According to the ABAP CDS Development Guide and SAP HANA SQL capabilities available to ABAP
SQL via CDS or native SQL:
DATS (ABAP Dictionary data type for dates) is fully supported for extract functions.
TIMESTAMP and UTCLONG are also supported since they represent full date-time values and are
mapped internally to TIMESTAMP with time zone considerations.
TIMS is a time-only type and is not valid for extract date functions.
TIMN is for time periods and is also not valid for extracting year, month, or day.
Therefore:
Option B (UTCLONG) – correct
Option C (TIMESTAMP) – correct
Option D (DATS) – correct
Options A (TIMS) and E (TIMN) – incorrect
Reference: ABAP CDS Development User Guide, section 2.2 – SQL expressions and supported built-in
functions in code pushdown; extract_* documented for date/time-compatible types.
Question 12
Which of the following are reasons that SAP recommends developing Core Data Services view
entities as opposed to classic Core Data Services DDIC-based views?
Note: There are 2 correct answers to this question.
- A. Automated client handling
- B. Simplified syntax check
- C. Simpler and stricter syntax
- D. Elimination of the need for a database view
Answer:
C, D
Explanation:
SAP recommends using CDS view entities over classic CDS DDIC-based views due to the following
benefits:
Simpler and stricter syntax: CDS view entities enforce a clearer separation of concerns and reduce
ambiguity, which helps ensure consistency across the stack. This makes Option C correct.
Elimination of the need for a database view: With CDS view entities, there's no dependency on a
separate DDIC SQL view object, reducing redundancy and improving activation performance. This
makes Option D correct.
Incorrect options:
Automated client handling (Option A) is supported in both CDS view entities and classic CDS views
via annotations like @ClientHandling.
Simplified syntax check (Option B) is not a distinct feature of CDS view entities. Syntax checking is
part of ABAP Development Tools regardless of the CDS flavor used.
Reference: ABAP CDS Development User Guide, section 2.2 – Data Definitions and advantages of
using CDS view entities over classic CDS views.
Question 13
What RESTful Application Programming feature is used to ensure the uniqueness of a semantic key?
- A. Action
- B. Validation
- C. Determination
- D. None of the above
Answer:
B
Explanation:
In the ABAP RESTful Application Programming Model (RAP), validations are used to ensure that
business rules and constraints are fulfilled, including the uniqueness of semantic keys.
A semantic key represents a natural identifier (e.g., employee number, product ID) and not a
technical surrogate key. Validations can be:
Field-level validations – used to validate input for single fields.
Entity-level validations – used to validate logical conditions like uniqueness of a key combination.
The uniqueness check is typically enforced using a custom validation implementation in the behavior
pool.
Action (Option A) is used for operations triggered by the user or system but not for enforcing
uniqueness.
Determination (Option C) is used for automatically computing or adjusting field values, not for
enforcing uniqueness.
Reference: SAP Help 1, page 7 – RAP Runtime and behavior definition section explains how
validations are responsible for enforcing semantic consistency and uniqueness constraints.
===========
Question 14
What describes multi-column internal tables?
- A. They use one incomplete data type.
- B. They are based on a structured row type.
- C. They must contain nested components.
- D. They use one complete data type.
Answer:
B
Explanation:
Multi-column internal tables are defined using a structured row type, meaning each row is defined
by a structure (either defined inline or as a global structure type in the Dictionary).
Option B is correct because it describes how internal tables with multiple fields are built using
structured rows.
Option A is incorrect because the row type must be complete and consistent.
Option C is incorrect because nested components are not a requirement.
Option D is misleading. Though “complete data type” may sound correct, it lacks specificity. The
correct technical description is that the row type is a structure.
Reference: ABAP CDS Development User Guide, section on internal table handling in ABAP objects
and syntax examples.
Question 15
In RESTful Application Programming, a business object contains which parts?
Note: There are 2 correct answers to this question.
- A. Process definition
- B. Behavior definition
- C. CDS view
- D. Authentication rules
Answer:
B, C
Explanation:
In the RAP model, a Business Object (BO) is composed of the following key parts:
A CDS view, which defines the data model layer (entity structure, projections, associations).
A Behavior Definition (BDEF), which defines the behavior layer – what operations can be performed
(create, update, delete, validations, determinations).
Therefore:
Option B and C are correct.
Option A is incorrect because "Process definition" is not a RAP construct; process logic is handled via
behavior implementation and determinations.
Option D is incorrect because "Authentication rules" are managed externally (e.g., via IAM,
authorizations), not inside the BO.
Reference: SAP Help 1, page 6 – RAP Architecture Overview and layers (Data Modeling and
Behavior).
===========