🚀 SAP ABAP Mock Interview – Question 9/50

 

Debugging a Slow ALV Report – A Production Support Approach

One of the most common production support scenarios is a performance issue.

Imagine a user reports:

"The custom ALV report was working fine yesterday. Today, it takes more than 15 minutes and eventually times out."

There have been no recent transports, so the problem is likely related to data, system performance, database behavior, or infrastructure rather than code changes.

So, how would you investigate this systematically?

Let's walk through a structured approach.

Scenario

A custom ALV report:

• ✅ Worked fine yesterday
• ❌ Takes more than 15 minutes today
• ❌ Eventually times out
• ✅ No recent transports

1️⃣ How Would You Investigate Step by Step?

Step 1 – Understand the Problem

Before opening the debugger, gather information from the user.

Ask questions like:

• Is the issue affecting all users or only one user?
• Does it occur in Production only, or also in QA?
• Does every report variant run slowly?
• When did the issue start?
• Has the data volume increased recently?
• Are other reports also slow?
• Were there any database maintenance activities or system upgrades?

Understanding the scope often helps eliminate unnecessary investigations.

Step 2 – Check Overall System Health

Determine whether the issue is application-specific or system-wide.

Useful SAP transactions:

Transaction	Purpose
SM50 / SM66	Check work process status and identify long-running processes
SM21	Review system log for errors or resource issues
ST22	Check for ABAP runtime dumps
SM37	Monitor background jobs if the report runs in the background
ST03N	Analyze overall system workload and response times

If multiple applications are slow, the issue may not be in the ABAP program at all.

Step 3 – Identify the Bottleneck

Now focus on performance analysis.

Use SAT (ABAP Runtime Analysis)

SAT shows where execution time is actually being spent.

It helps determine whether the delay is caused by:

• ABAP processing
• Database access
• RFC calls
• Function module execution
• Method calls

Instead of guessing, SAT provides measurable evidence.

Step 4 – Analyze Database Performance

If SAT indicates that database operations consume most of the execution time, move to ST05 (SQL Trace).

ST05 helps identify:

• Frequently executed SQL statements
• Full table scans
• Missing or inefficient indexes
• Number of SQL executions
• Expensive database operations

This allows you to determine whether the issue lies in the SQL statements rather than the ABAP logic.

Step 5 – Debug Only If Necessary

Many developers immediately start debugging.

A better approach is to debug only after identifying the problematic area.

For example:

• If SAT points to a specific method, debug that method.
• If ST05 identifies an expensive SQL statement, inspect why it is executed repeatedly.

Debugging without narrowing the scope often wastes time.

2️⃣ Which SAP Transactions Would You Use?

Transaction	Why Use It?
SM50 / SM66	Monitor active work processes
SM21	Check system logs
ST22	Analyze runtime dumps
SM37	Check background job execution
SAT	Measure ABAP runtime performance
ST05	Trace SQL and database performance
ST12	Combined ABAP + SQL trace
ST03N	Analyze workload and response times
DBACOCKPIT (optional)	Monitor database health and expensive SQL statements

3️⃣ How Would You Determine the Root Cause?

🔹 Database Performance

Indicators:

• Most execution time spent on SQL
• Full table scans
• Missing indexes
• Expensive joins
• High database response time

Tools:

• ST05
• ST12
• DBACOCKPIT

🔹 ABAP Logic

Indicators:

• SAT shows most time spent in ABAP processing
• Excessive nested loops
• SELECT statements inside loops
• Large internal table processing
• Inefficient algorithms

Tools:

• SAT
• Debugger

🔹 Network / RFC Calls

Indicators:

• Delays during remote function calls
• Slow external systems
• Long wait time during RFC execution

Tools:

• SAT
• SM59 (RFC destinations)
• ST03N
• SMGW (Gateway monitoring)

🔹 Data Volume Increase

Indicators:

• Same code but significantly larger datasets
• More records processed than before
• Variants with broader selection criteria

Check:

• Record counts in database tables
• Recently loaded business data
• Report selection parameters

Sometimes the code hasn't changed—only the amount of data has.

4️⃣ ST22 Shows No Dump, But Users Still Get a Timeout. What Next?

If ST22 shows no dump, the timeout may not be caused by an ABAP runtime error.

Investigate:

• SM50 / SM66 – Is the work process still active or waiting?
• SM21 – Any system-level issues?
• ST03N – High workload or resource contention?
• SAT / ST12 – Where is the execution time spent?
• ST05 – Is the database the bottleneck?
• SM59 – Are RFC destinations responding slowly?
• Profile parameters such as rdisp/max_wprun_time, which define the maximum dialog work process runtime.

This helps distinguish between an application issue and an infrastructure or configuration issue.

🎯 Interview Tip

Many candidates immediately say:

"I'll debug the report."

A stronger answer is:

"First, I'll determine whether the issue is system-wide or application-specific. Then I'll use SAT and ST05 to identify the actual bottleneck. Only after collecting evidence will I debug or optimize the code."

Interviewers value a methodical troubleshooting approach more than simply listing SAP transactions.

💡 Bonus Question

Suppose SAT shows that 90% of the execution time is spent in ABAP processing, while database time is negligible.

Should you still use ST05?

Not immediately.

Since the database is not the bottleneck, ST05 is unlikely to provide additional insights. The next step should be to investigate the ABAP logic.

Look for:

• Nested loops with large internal tables
• SELECT SINGLE or SELECT ... ENDSELECT inside loops
• Inefficient internal table searches (use hashed or sorted tables where appropriate)
• Expensive string operations or unnecessary object creation
• Recursive method calls or repeated calculations

Optimize the ABAP logic first, then rerun SAT to verify the improvement.

📌 Key Takeaways

• Never assume the issue is in the code—gather facts first.
• Start with system health, then move to performance analysis.
• Use SAT to identify whether the bottleneck is in ABAP, the database, or RFC calls.
• Use ST05 only when database operations appear to be the problem.
• Debug only after narrowing down the root cause.
• Always validate your optimization by measuring performance before and after the change.

💬 Interview Challenge

During performance analysis, you discover that a SELECT SINGLE statement is executed 100,000 times inside a loop.

How would you prove this is the bottleneck, and what ABAP techniques would you use to optimize it without changing the business logic?

Share your approach in the comments! 👇

🚀 SAP ABAP Mock Interview – Question 8/50

 
Interface vs Abstract Class in ABAP – Which One Should You Choose?

One of the most frequently asked Object-Oriented ABAP interview questions is the difference between an Interface and an Abstract Class.

Many developers answer with definitions, but interviewers usually want to know when to use each in real-world scenarios.

Let's understand it with a practical example.

Scenario

You are designing a payment framework in SAP that supports multiple payment methods:

• 💳 Credit Card
• 🏦 Bank Transfer
• 📱 UPI

Every payment method must implement:

process_payment( ).

Some payment methods also share common validation logic.

Which design would you choose?

Option 1 – Using an Interface

INTERFACE lif_payment.

  METHODS process_payment.

ENDINTERFACE.

CLASS lcl_credit_card DEFINITION.

  PUBLIC SECTION.
    INTERFACES lif_payment.

ENDCLASS.

Characteristics

• Defines a contract (what must be implemented)
• No shared state or reusable implementation
• Each implementing class provides its own logic
• Best when classes are unrelated but should expose the same behavior

Option 2 – Using an Abstract Class

CLASS lcl_payment DEFINITION ABSTRACT.

  PUBLIC SECTION.

    METHODS validate_amount.
    METHODS process_payment ABSTRACT.

ENDCLASS.

CLASS lcl_credit_card DEFINITION
  INHERITING FROM lcl_payment.

  PUBLIC SECTION.

    METHODS process_payment REDEFINITION.

ENDCLASS.

Characteristics

• Defines both what and how
• Can contain:
  • Concrete methods
  • Abstract methods
  • Attributes
• Promotes code reuse through inheritance
• Best when child classes share common behavior or data
  
  

1️⃣ Interface vs Abstract Class

Both provide abstraction, but they solve different design problems.

✅ Choose an Interface when:

• Classes only need to follow the same contract
• Implementations are completely different
• There is no shared code
• A class may need to support multiple behaviors

Example:

INTERFACE lif_payment.

  METHODS process_payment.

ENDINTERFACE.

Each payment type implements its own business logic independently.

✅ Choose an Abstract Class when:

• Child classes share common functionality
• You want to avoid duplicate code
• Common attributes or helper methods are required

Example:

CLASS lcl_payment DEFINITION ABSTRACT.

  PUBLIC SECTION.

    METHODS validate_amount.
    METHODS process_payment ABSTRACT.

ENDCLASS.

Every payment method automatically inherits:

• Shared validation logic
• Common attributes
• Reusable utility methods

while still providing its own implementation of process_payment().

2️⃣ What is the Difference?

Interface	Abstract Class
Defines what a class must do	Defines what and how
Focuses on behavior (contract)	Focuses on behavior and shared implementation
No instance attributes for shared state	Can contain attributes and implemented methods
Supports multiple interface implementation	A class can inherit from only one abstract (or concrete) superclass
Best for unrelated classes	Best for related classes sharing common logic

3️⃣ Can an Abstract Class Be Instantiated?

No.

The following code will fail:

DATA lo_payment TYPE REF TO lcl_payment.

CREATE OBJECT lo_payment.

Since lcl_payment is declared as ABSTRACT, ABAP does not allow object creation.

Only a concrete subclass can be instantiated.

Example:

DATA lo_payment TYPE REF TO lcl_payment.

CREATE OBJECT lo_payment TYPE lcl_credit_card.

This is perfectly valid.

4️⃣ Can a Class Implement Multiple Interfaces?

Yes.

A class can implement multiple interfaces.

Example:

CLASS lcl_credit_card DEFINITION.

  PUBLIC SECTION.

    INTERFACES:
      lif_payment,
      lif_loggable,
      lif_auditable.

ENDCLASS.

However, a class can inherit from only one superclass.

This is how ABAP supports multiple behaviors without allowing multiple inheritance.

🎯 Interview Tip

A basic answer is:

"Interfaces have only methods, while abstract classes can have methods and attributes."

A stronger interview answer is:

"Choose an Interface to define a common contract across unrelated classes. Choose an Abstract Class when related classes should share common state, reusable logic, or helper methods."

This demonstrates design thinking rather than just language syntax.

💡 Bonus Question

Sppose every payment method requires:

• ✅ The same validation logic
• ✅ Different payment processing logic

Would you choose:

• Only an Interface?
• Only an Abstract Class?
• A combination of both?

✔️ Recommended Answer: A Combination of Both

A common enterprise design is to combine the strengths of both.

INTERFACE lif_payment.

  METHODS process_payment.

ENDINTERFACE.

CLASS lcl_payment_base DEFINITION ABSTRACT.

  PUBLIC SECTION.

    INTERFACES lif_payment.

    METHODS validate_amount.
    METHODS lif_payment~process_payment ABSTRACT.

ENDCLASS.

Concrete classes inherit from the abstract class:

CLASS lcl_credit_card DEFINITION
  INHERITING FROM lcl_payment_base.

  PUBLIC SECTION.

    METHODS lif_payment~process_payment REDEFINITION.

ENDCLASS.

Why is this the best design?

• The interface defines the contract (process_payment()), allowing loose coupling and polymorphism.
• The abstract class provides shared validation logic, common attributes, and reusable code.
• New payment methods can be added easily without duplicating common functionality.

This approach follows the Interface Segregation and Open/Closed principles, making the solution scalable and maintainable.

📌 Key Takeaways

• Use an Interface when you need a common contract across unrelated classes.
• Use an Abstract Class when child classes share common data or implementation.
• An Abstract Class cannot be instantiated.
• A class can implement multiple interfaces but inherit from only one superclass.
• In real-world enterprise applications, combining an Interface with an Abstract Class is often the most flexible and maintainable solution.

💬 Interview Challenge

You have a class hierarchy where all payment methods share the same validation logic, logging, and audit functionality, but each has a different payment process.

How would you design this using Interfaces and Abstract Classes while keeping the solution extensible and following SOLID principles?

Share your approach in the comments! 👇

💡 SAP ABAP Tip - Backticks (`) vs Single Quotes (') in ABAP – A Small Syntax Difference with a Big Impact

 Modern ABAP introduced several features that make code cleaner and more expressive. One subtle but important difference is the choice between backticks (`) and single quotes (').

Although both represent text literals, they result in different data types, especially when using inline declarations.

Let's understand the difference.

Scenario

Consider the following inline declaration:

Using Backticks

DATA(lv_text) = `123`.

Result

lv_text is inferred as:

TYPE string

A dynamic-length string is created.

Using Single Quotes

DATA(lv_text) = '123'.

Result

lv_text is inferred as:

TYPE c LENGTH 3

A fixed-length character field is created.

1️⃣ What is the Difference?

✅ Backticks (`)

DATA(lv_text) = `SAP ABAP`.

Characteristics:

• Creates a STRING data type
• Dynamic length
• No predefined size limit (other than system limits)
• Ideal for modern ABAP development
• Preferred when working with dynamic text

✅ Single Quotes (')

DATA(lv_text) = 'SAP ABAP'.

Characteristics:

• Creates a fixed-length character field (TYPE C)
• Length is inferred from the literal
• Suitable for short, fixed-size values
• Traditional ABAP syntax

2️⃣ Why Does This Matter?

When using inline declarations, ABAP automatically determines the variable type based on the literal.

For example:

DATA(lv_string) = `Hello`.

Result:

TYPE string

Whereas:

DATA(lv_char) = 'Hello'.

Result:

TYPE c LENGTH 5

The syntax you choose directly affects the inferred data type.

3️⃣ Practical Differences

Backticks (`)	Single Quotes (')
Creates STRING	Creates TYPE C
Dynamic length	Fixed length
Modern ABAP style	Classic ABAP style
Best for variable-length text	Best for fixed values
Ideal for long text and concatenation	Useful for constants and short literals

4️⃣ When Should You Use Each?

✅ Use Backticks When

• Working with dynamic text
• Using string templates
• Concatenating large strings
• Building JSON or XML payloads
• Writing modern ABAP code

Example:

DATA(lv_message) = `Order created successfully`.

✅ Use Single Quotes When

• Defining fixed character literals
• Comparing short constant values
• Working with legacy code
• Assigning values to TYPE C fields

Example:

IF lv_status = 'A'.
  " Active
ENDIF.

5️⃣ Does Assignment Still Work Between STRING and TYPE C?

Yes.

ABAP performs implicit conversions where appropriate.

Example:

DATA lv_char   TYPE c LENGTH 10.
DATA lv_string TYPE string.

lv_string = 'SAP'.
lv_char   = `ABAP`.

The assignments are valid, but remember that TYPE C fields have a fixed length and may be padded with trailing spaces.

⚠️ Important Note About Trailing Spaces

One key difference is how trailing spaces are handled.

DATA(lv_char)   = 'ABC'.
DATA(lv_string) = `ABC`.

While both display the same value, a TYPE C field always has a fixed length and pads unused positions with spaces. A STRING stores only the actual content.

This distinction becomes important when performing string operations, comparisons, or interfacing with APIs.

🎯 Interview Tip

If an interviewer asks:

"What is the difference between backticks and single quotes in ABAP?"

A basic answer is:

"Backticks create a STRING, while single quotes create a character field."

A stronger answer is:

"In inline declarations, backticks infer a STRING (dynamic-length text), whereas single quotes infer a fixed-length TYPE C. Choosing the appropriate literal improves readability and avoids unnecessary type conversions in Modern ABAP."

This shows that you understand both the syntax and its impact on data types.

📌 Key Takeaways

• Backticks ()** create a **STRING` (dynamic-length text).
• Single quotes (') create a TYPE C (fixed-length character field).
• Inline declarations infer the variable type from the literal you use.
• Prefer backticks for modern ABAP, dynamic text, JSON/XML payloads, and string manipulation.
• Use single quotes when working with fixed character values or legacy code.

💬 Interview Challenge

What will be the inferred data type of the following variables?

DATA(lv_a) = `100`.
DATA(lv_b) = '100'.
DATA(lv_c) = |100|.

Can you identify the type of each variable and explain the difference?

Share your answer in the comments! 👇

🚀 SAP ABAP Mock Interview – Question 7/50

 

Downcasting in ABAP: ?= vs CAST

One of the most common interview questions in Modern ABAP is about downcasting. Many developers know the syntax, but interviewers often look for your understanding of how and why each approach works.

Let's break it down.

Scenario

Consider the following class hierarchy:

lcl_vehicle    (Super Class)
      ↑
lcl_car        (Sub Class)

Assume we have a reference of the parent type:

DATA lo_vehicle TYPE REF TO lcl_vehicle.

At runtime, this reference may point to an object of lcl_car (or any subclass).

There are two ways to downcast it.

Approach 1 – Using ?=

DATA lo_vehicle TYPE REF TO lcl_vehicle.
DATA lo_car     TYPE REF TO lcl_car.

lo_car ?= lo_vehicle.

Characteristics

• Statement-based syntax
• Available since Classic ABAP
• Requires an existing reference variable
• Commonly seen in legacy code

Approach 2 – Using CAST

DATA(lo_car) = CAST lcl_car( lo_vehicle ).

Characteristics

• Expression-based syntax
• Supports inline declarations
• Can be nested inside larger expressions
• Preferred in Modern ABAP

Example:

DATA(lv_name) =
    CAST lcl_employee( lo_object )->name.

This kind of expression chaining is not possible with ?=.

1️⃣ What is the Difference Between ?= and CAST?

A common interview answer is:

"Use CAST when the hierarchy is known."

❌ This is not the real difference.

Both ?= and CAST require a valid inheritance hierarchy.

The actual difference is how the cast is expressed in ABAP.

?=	CAST
Statement	Expression
Classic ABAP syntax	Modern ABAP syntax
Needs an existing variable	Supports inline declaration
Cannot be embedded in expressions	Can be used inside larger expressions
Mostly used in older code	Recommended for Modern ABAP

2️⃣ Do Both Perform Runtime Type Checking?

Yes.

Both

lo_car ?= lo_vehicle.

and

CAST lcl_car( lo_vehicle )

perform exactly the same runtime type validation.

If the runtime object is not actually an instance of lcl_car (or one of its subclasses), the cast fails.

There is:

• ✅ No performance difference
• ✅ No difference in runtime validation

The difference is purely syntactical and stylistic.

3️⃣ Which Exception Can Occur?

If the runtime object cannot be converted to the requested type, ABAP raises:

CX_SY_MOVE_CAST_ERROR

This happens when the runtime object is not compatible with the target type.

4️⃣ How Would You Handle It?

Wrap the cast inside a TRY...CATCH block.

TRY.

    DATA(lo_car) =
        CAST lcl_car( lo_vehicle ).

  CATCH cx_sy_move_cast_error
        INTO DATA(lx_cast).

    "Handle invalid cast
    "Log the error, skip processing,
    "or notify the user

ENDTRY.

This prevents a runtime dump and allows your program to handle invalid casts gracefully.

🎯 Interview Tip

A basic answer is:

"CAST is the new syntax."

A stronger answer is:

"CAST is an expression operator, whereas ?= is an assignment statement. Both perform identical runtime type checking, but CAST integrates naturally with Modern ABAP features such as inline declarations and expression chaining."

That answer demonstrates a deeper understanding of Modern ABAP.

💡 Bonus Question

What will happen here?

DATA lo_vehicle TYPE REF TO lcl_vehicle.

CREATE OBJECT lo_vehicle TYPE lcl_vehicle.

DATA(lo_car) =
    CAST lcl_car( lo_vehicle ).

Will the cast succeed?

❌ No.

lo_vehicle actually refers to an object of type lcl_vehicle, not lcl_car.

Although lcl_car inherits from lcl_vehicle, the reverse is not true.

At runtime, ABAP checks the actual object type, not the reference type.

Since the object is not an instance of lcl_car (or its subclass), the cast fails and raises:

CX_SY_MOVE_CAST_ERROR

📌 Key Takeaways

• ?= and CAST perform the same runtime type checking.
• The difference is statement-based (?=) vs expression-based (CAST) syntax.
• CAST is preferred in Modern ABAP because it supports:
  • Inline declarations
  • Expression chaining
  • Cleaner and more readable code
• Invalid downcasting raises CX_SY_MOVE_CAST_ERROR.
• Always use TRY...CATCH when the runtime type is uncertain.

💬 Interview Question for You

Suppose the following code executes:

DATA lo_vehicle TYPE REF TO lcl_vehicle.

CREATE OBJECT lo_vehicle TYPE lcl_car.

DATA(lo_car) = CAST lcl_car( lo_vehicle ).

Will the cast succeed? Why?

Share your answer in the comments! 👇