SAP ABAP Interview Preps

What is Data Dictionary?

ABAP Data Dictionary (DDIC) is the central

repository for data definition in SAP systems. In
the data dictionary, you can create and maintain
objects that are related to the database.

Anything you see in SE11, including tables, data

elements, domains, search helps, views, structures,
table types, lock objects are all DDIC objects.

What are some of the Objects in DDIC?

Database tables: Database tables are made up of

rows and columns. Database tables are the
collection of fields that have technical
attributes as well as the semantic description.
The custom tables (by user) should start with the
naming convention as ‘Z’ or ‘Y.’ All the standard
tables (by SAP) start with other names except Z
or Y.

View: A view is a virtual table, which does not

have any physical existence. It is created by
combining the data of one or more tables. A view
does not occupy any storage space.

Table type: A table type is a global reusable

object, i.e., we declare in SE11 Tcode, which is
used to define the structures and functional
attributes of an internal table in ABAP. To learn
more about the internal table, navigate to ‘Part
3’.

Data type: Data type includes the following list.

Type Group: To encapsulate similar type pools in

one group, we make type group. The inbuilt type
pools provided by SAP are SLIS, SAP.

Domain: Domain describes the technical attributes

such as data types and lengths of a table field.

Data element: Data element in sap ABAP gives the

semantic description of fields such as field
labels and documentation. It describes how the
field can be displayed to the end-user.

Search Help: To enable the list of entries for

one field or many fields, we use the search help
 option. The function key for search help is F4.

Lock Objects: To control the parallel access for

the same data by multiple users, we make use of
the lock objects. Lock objects in the data
dictionary (DDIC) start with ‘E.’

What are tables and it's types?

SAP ABAP tables are a collection of fields that are

in the format of rows and columns. Every field is
made up of a data element and a domain.

While declaring fields in the database table, all

the primary keys should come together in the
beginning.

NOTE: Maximum key fields should be 16. Total

fields in a table can be 294.

Next, the types of table in SAP ABAP are as

follows:

1. Transparent tables

2. Pool tables

3. Cluster tables

Transparent tables: It has a one-to-one

relationship. This type of table is used to store
application data.
Pool tables: It has a many-to-one relationship.
Many pool tables are clubbed and stored in a single
table in a database. This type of table is used to
store control data.

Cluster tables: It has a many-to-one relationship.

Many cluster tables are clubbed and stored in a
single table in a database.

How to create a table in SAP ABAP?

The following are the steps for creating the custom

tables.

Execute the Tcode ‘SE11’.

Once the screen gets loaded, select the ‘database

table’ radio button and provide the name for the
table. Remember, the naming convention should
start from ‘Z’ or ‘Y’ to indicate its the custom
table.

Further, click on the Create button and enter the

short description. Choose the delivery class as
‘A.’ Also, choose the ‘Display/Maintenance
allowed’ from the dropdown.

The delivery class in SAP ABAP determines whether

the data of the table can be transported or not.
Types of the delivery class are as follows:

1. A — Application table (Master and transactional

data)
2. C -Customer table, maintenance only by the
customer, no SAP imports.

3. L -Table for storing temporary data

4. G -Customizing, protected against SAP updates

5. E -Control table

6. S -System table, edited only by SAP

7. W -System table

NOTE: We usually use the delivery class as ‘A’

since it contains both master and transactional
data. Master data is needed a lot but changes
seldomly. Transactional data is also used a lot
and changes frequently.

Navigate to the ‘Fields’ tab to enter the fields

of the table. Now there are two options to
provide data types to each field, mainly by data
element or by predefined data type.

Below is the method via the ‘data element.’

Field: List all the fields which are required for

the table. Primary keys should come at the start.

Key: Tick the checkbox for the fields which are

primary.

Data element: All the data elements will start

with ‘Z’ as the naming convention.
Further, double click on every data element to
provide a short description along with the domain
name. The naming convention of the domain should
start from ‘Z.’
 As discussed, the data element in sap ABAP
provides the semantic description of the fields.
Hence one should always provide the field label.
Hence navigate to the field label tab and provide
4 types of lengths:

1. Short

2. Medium

3. Long

4. Heading
Navigate again to the data type tab and double
click on the domain which you provided. Provide a
short description and data type of the particular
field.
The domain also provides the option of the value
range, which acts as the dropdown list for the
particular field. Provide the ranges and click on
save and hit the activate button.

Also, save and activate the data element. Repeat

this procedure for every individual field by
providing data elements, field labels, domains.
 Now click on the ‘Technical settings’ button or
hit ‘Ctrl+shift+F9’. Here, we provide the data
class and size category.

Data class: This is the physical area in the

database where all the data of the table are
stored. With the help of the data class, SAP
segregates and organizes the tables according to
their types of data. It keeps all the master data
together, all transaction data together, all user
data, and all organization data together. This
increases system performance. Following are the
types of data class:

1. APPL0 -Master data ( Data which changes seldomly)

2. APPL1 -Transactional data (Data which changes

frequently)

3. APPL2 -Organization data (Customizing data that

is defined when the system is installed and
seldomly changed.

Size category: This determines the expected size

required for the table. The default size for type
‘0’ is 8 KB.
Save, activate, and hit on the ‘No’ button.

We are done with the creation of a table. Now to

create entries in a table, navigate to Utilities
> Table contents > Create entries.
 Fill the entries one by one and hit the save
button.

Once all the entries are created, go back and hit

the Contents button (Ctrl+shift+F10) and click on
the execute icon (F8).

What is a View in SAP ABAP, it's types, and how do

you create a view in ABAP?
Views are virtual tables, Views does not hold data
by itself.
A view in ABAP is a virtual representation of an
underlying database table in the data dictionary.

It's types...
There are four types of ABAP views.

Database views: This type of view creates a join

between two or more tables based on common
fields. Moreover, Database Views are only meant
for reading purposes.

Projection views: This type of view does not join

any tables. It simply uses one table and shows
the output to the user. This view is meant for
both reading and writing purposes.

Maintenance views: This view is the same as the

Database view. Maintenance views generate the
screen runtime for maintaining and displaying
records.
Help views: This is a special view for use in
search helps (F4).

Steps to create Database View

Navigate to SE11 transaction. Choose the radio

button which says ‘View.’ Give a suitable name
for the same. Ensure the naming convention should
start from ‘Z’ or ‘Y.’ Once done, click on the
create button.
You will get the screen which has various types
of views. Here we will go for the ‘Database
View.’

Give a short description. Next, provide the name

of the master table (KNA1), click on the
relationship button, and select the dependent
table (VBAK). Once we select two tables, we get
the join condition automatically. Here the join
condition is on fields ‘Mandt’ and ‘Kunnr.’
NOTE: Since database view enables joins of 2
tables, hence we have an option of relationship
button.

Further, navigate to view Fields tab and mention

the fields which you want to display to the user
from both the tables. In our example, the two
tables are KNA1 and VBAK.
NOTE: The above screenshot will throw an error
since there is a blank space in the view field
of customer ID. Hence ensure it write as
‘customer_ID’.

Save and hit the activate icon (Ctrl +F3).

Navigate to the Utilities tab located on the menu
bar and click on the contents option. The below
screen gets displayed.

The below output displays the entries for the

fields ‘Customer’ and ‘Name.’ There is no entry
 for the fields ‘City’ and ‘Sales document.’

Steps to create Projection View

Naviagte to SE11 > choose ‘View’ radio-button

>Projection view.

Enter the short description and provide the base

table. Here we are using the ‘KNA1’ table in our
Projection view example. Click on the ‘Table
fields’ button and provide the fields which you
want to display to the user.
 NOTE: There is no word as a ‘relationship’
since the projection view is meant for only one
table.

Further, click on the maintenance status tab and

ensure the selected radio-button is read and
change.
Save and activate and hit the utilities from the
menu bar to view the contents.

Steps to create Maintenance View

Navigate to SE11 > choose ‘View’ radio-button >

Maintenance view.
Provide a short description. Enter the base table
as KNB1 and click on the ‘relationship’ button.

Select the suitable checkbox and click on the

‘copy’ button. Save and hit the activate icon.
Further, go to the Utilities tab > table
maintenance generator.
Add the Authorization group

Maintenance screen — One step > Overview screen >

1.

Click on the ‘create’ icon, which is located to

the extreme left besides ‘Find SCR. Number’

Further, go back and select utilities > contents.

The last step is to select the ‘maintain’ button.
 Lastly, maintain the entries.

What are search helps in SAP ABAP?

There are two types of search helps:

1. Elementary search help: Based on one single

field, we can populate the data for the rest of
the fields in the table.
2. Collective search help: This collects several
elementary search helps. Hence, Collective
search help provides an alternative search path
for a particular field.
What are Lock Objects?

Lock object in SAP ABAP is the feature used to

control access of the same data to multiple
users.

They prevent multiple users or programs from

modifying the same data simultaneously, ensuring
data integrity.

This mechanism helps avoid conflicts and ensures

consistent data updates.

NOTE: When lock objects are enabled, 2 function

gets created namely, ENQUEUE and DEQUEUE.

Lock objects are of three types.

1. Read lock: All of them can only read the data.

2. Write lock: Only one user can write while the

rest can read.

3. Exclusive but not cumulative: Only one lock can

be requested by a transaction. All the other
requests are rejected.

3 Tier architecture of SAP?

SAP stands for Systems Applications and Products.

SAP aims to integrate all the different modules in
a company. It is an ERP (Enterprise Resource
Planning) software that maintains the
centralization of data.
R/3 stands for Real-Time 3 Tier Architecture. The
three layers provided by SAP are namely:

Presentation layer: This layer collects input

from the user and creates process requests to be
passed to the Application layer.

Application layer: This layer collects all the

requests form the Presentation layer and passes
these requests to the ‘Dispatcher’. The
Dispatcher further passes these requests in the
Dispatcher queue. It follows the logic of first-
in-first-out. The ‘Dispatcher queue’ further
passes these requests to the respective ‘Work
Processes’. The Work Process is responsible to
process those requests given by the Presentation
layer. Every Work Process has 2 special small
memory areas namely ‘User Context’ and ‘Program
Roll’. The User Context stores the information
of the user. Program Roll stores the information
of the program execution.
Database layer: This layer is responsible to
store data.

SAP ABAP Data types

Here is the table with complete and incomplete data

types grouped properly:
Type Typical Typical Range Categor
Length

X 1 byte Any byte values (00 to ✅

FF) Complet

D 8 8 characters ✅
characters Complet

T 6 6 characters ✅
characters Complet

I 4 bytes -2147483648 to ✅
2147483647 Complet

F 8 bytes 2.2250738585072014E-308 ✅
to Complet
1.7976931348623157E+308
(positive or negative)

P 8 bytes [-10^(2len -1) +1] to ✅

[+10^(2len -1) -1] Complet
(where len = fixed
length)

C 1 1 to 65535 ❌
character Incompl

N 1 1 to 65535 ❌
character Incompl

STRING Variable Any alphanumeric ❌

characters Incompl

XSTRING Variable Any byte values (00 to ❌

FF) Incompl
How do you take input from a user?

1. Parameters are used when we want to take the

input of the user and display the data
accordingly. We use the keyword ‘PARAMETER’, for
fetching the input from the user.

PARAMETERS : p_carrid TYPE s_carr_id. “parameter

SELECT carrid
connid
fldate
price
FROM sflight UP TO 10 ROWS
INTO TABLE it_sflight
WHERE carrid = p_carrid.

WRITE : /’carrid’, 20 ‘connid’, 30 ‘fldate’, 52 ‘price’.

2. Select-options are used when we want the range of

inputs from the user. We use the keyword ‘SELECT-
OPTIONS’, for fetching the multiple inputs from
the user.

While creating select-options, the system creates

an internal table by default having the following 4
fields.

3. LOW: Lowest range

4. HIGH: Highest range

5. SIGN: I (include) or E (exclude)

6. OPTION: BT, NB, EQ, NE, GT.

SELECT-OPTIONS : p_carrid FOR carrid. “SELECT-OPTIONS

What are Events in SAP ABAP?

Events in ABAP reports are specific points in the

program's execution where predefined actions can
be triggered.
These events allow developers to control the flow
of the report and perform specific tasks at
different stages.
They are triggered by user interactions, system
events, or program logic.
Top of page: This is triggered by the first
‘write’ statement in the report. Acts as the
header of the page. If there is
no ‘write’ statement in the report, by default,
the first event to be triggered is the ‘load-of-
program’.
Load-of-program: This event gets triggered when
the program of type E, M, F or S gets loaded. It
exists only once per program.

Initialization: As the name suggests, this event

is used to initialize the values. This event
gets triggered after the ‘load-of -program’ and
before any selection screen gets displayed.
 At selection-screen output: This event gets
triggered just before the selection screen gets
displayed. This event is used when you want to
change the screen fields at runtime. This will
hide the fields, make them visible, invisible,
or make them intensified.

NOTE: Here modify screen plays a very important

role. With the help of ‘modify screen’, the
screen gets changed accordingly.

At selection-screen: This event gets triggered

when the user processes the selection-screen. The
role of this event is to check and validate the
inputted values.

NOTE: To know more about message types refer

‘Message types in SAP ABAP’.

Start-of-selection: This event gets triggered

when the user clicks on the execute button or
hits F8. It is very good practice to mention this
event in the code.

What are Function Modules and it's types?

Function Modules are encapsulated ABAP procedures

that are grouped in Function Groups. Modules within
the same Function Group belong logically together.
They are globally available and can be called from
any other ABAP program by name which must be
unique.
Function Modules are created with the Function
Builder (transaction SE37 ). The type of function
module depends on the Processing Type.

Regular Function Module

A Regular Function Module is the default option.

This kind of Function Module is executed
immediately and synchronously on your current SAP
system.

CALL FUNCTION func { parameter_list | parameter_tables }.

Remote-Enabled Function Module

Remote Function Modules can be called by other SAP

and non-SAP systems utilizing the RFC protocol.

For example, you can define a Remote Function

Module in an EWM system which then gets called by
your ERP system to get further information about
stock levels or shipment details.

CALL FUNCTION func DESTINATION dest parameter_list.

This statement calls the target system specified

under dest synchronously. Available RFC
destinations are configured using transaction SM59.
Use the unique name of a destination for
parameter dest .

The calling program continues execution once the

RFC has finished. Depending on the connection this
can be a performance issue.

Update Function Module

Update Function Modules are not executed

immediately. They are scheduled for execution in an
update work process. This update process is
triggered by the statement COMMIT WORK . The
statement ROLLBACK WORK deletes all update function
module registrations.

CALL FUNCTION update_function IN UPDATE TASK

[EXPORTING p1 = a1 p2 = a2
...]
[TABLES t1 = itab1 t2 =
itab2 ...].

Using CALL FUNCTION .. IN UPDATE TASK is a way to

bundle database changes into a single database LUW.
It is also beneficial for performance since the
update happens asynchronously.

What is a BAPI?

SAP BAPI stands

for Business Application Programming Interface.
Technically a BAPI is a Function Modules that
offers a standard interface to business objects in
SAP. Most of them are also RFC enabled.

Common use-cases are using a BAPI to

create/read/update/delete business objects like
Sales Orders, Business Partners, or Purchase
Orders.

Those BAPIs behave like the SAP standard

transactions for these business objects. This means
that authorization checks are already in place and
implemented user exits are considered.

Find further information about existing BAPIs and

how to call them by running transaction BAPI .

ABAP Object-Oriented Programming (OOP)

Object-Oriented Programming (OOP) is a programming

paradigm that allows you to model your ABAP
applications using objects, classes, and methods.

Classes

In ABAP OOP, a class is a blueprint for creating

objects. It defines the structure and behavior of
objects belonging to that class.

A class may contain attributes (data members) and

methods (functions) that operate on those
attributes.

Example of defining a class:

 CLASS z_employee DEFINITION.
PUBLIC SECTION.
DATA: employee_id TYPE i,
employee_name TYPE string.

METHODS: constructor,
get_employee_info IMPORTING
i_employee_id TYPE i,
display_employee_info.
ENDCLASS.

Objects

Objects are instances of a class. They represent

real-world entities with their own unique data
and behavior.
Objects are created from classes using
constructors.
Example of creating an object from a class:

DATA: lo_employee TYPE REF TO z_employee.

CREATE OBJECT lo_employee.

Methods

Methods are functions defined within a class.

They define the behavior of objects belonging to
that class.

Methods can access and manipulate the attributes

of an object.
 Example of defining methods in a class:

METHOD constructor.
" Constructor method for initializing object.
ENDMETHOD.

METHOD get_employee_info.
" Method to retrieve employee information.
ENDMETHOD.

METHOD display_employee_info.
" Method to display employee information.
ENDMETHOD.

Inheritance

Inheritance allows you to create a new class

(subclass) based on an existing class
(superclass).
Subclasses inherit attributes and methods from
the superclass.
Subclasses can also add their own attributes and
methods or override inherited methods.
Example of inheritance:

CLASS z_manager DEFINITION INHERITING FROM z_employee.

PUBLIC SECTION.
DATA: department TYPE string.
 METHODS: constructor REDEFINITION.
ENDCLASS.

Encapsulation:

Encapsulation is the principle of bundling data

(attributes) and methods that operate on that
data within a class.
Access to the data is controlled through methods,
providing data hiding and protection.

Polymorphism:

Polymorphism allows objects of different classes

to be treated as objects of a common superclass.

This enables you to write more generic and

flexible code.

Abstraction:

Abstraction involves defining the essential

characteristics of an object while hiding
irrelevant details.
Classes provide an abstract representation of
real-world objects, focusing on what an object
does rather than how it does it.

Interfaces:

Interfaces define a contract for classes. A class

implementing an interface must provide
 implementations for the methods defined in that
interface.
Interfaces allow you to achieve multiple
inheritance-like behavior in ABAP.

Brief through of Enhancements in SAP

There are user exits, customer exits, Business

Add-Ins (BAdIs), and Enhancement Framework. Each
has its own use case and structure.
User exits are older, predefined places in the
code where custom code can be inserted.
Customer exits are similar but more structured,
often created via transactions like CMOD and
SMOD. BAdIs are object-oriented and more
flexible, allowing multiple implementations.

The Enhancement Framework, introduced in later

versions (NetWeaver 7.0 onwards), is more modern
and integrates various enhancement techniques
under one umbrella.

Implicit are those predefined spots in the code,

while explicit are created by developers.

What is Enhancements

Enhancements in SAP ABAP are pivotal for

customizing standard SAP applications to meet
business-specific requirements without altering the
original source code. SAP’s strict adherence to
upgradability and maintenance necessitates non-
invasive customization techniques. Enhancements
allow developers to inject custom logic at
predefined or developer-defined points, ensuring
seamless integration with future SAP updates.

Types of Enhancements:

User Exits

Overview:
User Exits (also called Function Exits) are
predefined hooks in SAP standard programs where
custom code can be inserted. They are tied to
specific application areas (e.g., SD, MM).

Implementation:

Form-Based Exits: Defined using CALL CUSTOMER-

FUNCTION followed by a numeric ID (e.g., 001 ).
Examples:
EXIT_SAPLV60B_001 in Sales Order processing
(VA01/VA02).

Tools: Transaction SMOD (to view exits)

and CMOD (to create projects).

Customer Exits

Overview:
Structured enhancements that include function
modules, screen exits, and menu exits. Managed via
enhancement projects.
Components:

Function Module Exits: Custom code in Z -named

function modules (e.g., ZXVVAU01 ).

Screen Exits: Append fields to standard screens

using APPEND in Screen Painter.

Menu Exits: Add custom menu items to SAP GUI.

Implementation:

1. Use CMOD to create a project.

2. Assign exit components (e.g., V45A0002 for Sales

Document).

3. Write code in the included function module.

Business Add-Ins (BAdIs)

Overview:
Object-oriented enhancements supporting multiple
implementations and filter-dependent execution.
Introduced in SAP R/3 4.6A.

BAdIs are based on ABAP Objects (interfaces and

classes).

Types:

Classic BAdIs: Single or multiple implementations

via SE18 (definition) and SE19 (implementation).

New BAdIs: Enhanced flexibility with instance

generation control and fallback mechanisms.
Implementation:

1. Define BAdI: Create in SE18 with an interface

(e.g., ZIF_BADI_ORDER ).
2. Implement BAdI: Use SE19 to create a class
implementing the interface.

Enhancement Framework (Post-SAP NetWeaver 7.0)

Overview:
Unifies enhancement techniques using explicit
enhancement points, sections, and composite
structures.

Key Concepts:

Enhancement Points: Positions in code where logic

can be inserted.

Enhancement Sections: Replace sections of code

with custom logic.

Composite Enhancements: Group multiple

enhancements into a single unit.

Tools:

Enhancement Builder (SE18/SE19): Manage spots and

implementations.

Switch Framework: Activate/deactivate

enhancements.

Implicit vs. Explicit Enhancements

 Implicit: Predefined by SAP (e.g., BAdIs,
Customer Exits). Limited to SAP’s provided hooks.

Explicit: Developer-defined using the Enhancement

Framework. Offers flexibility to create new
enhancement points.

Step-by-Step Implementation Guides

5.1 Creating a BAdI

1. Define BAdI ( SE18 ): Create Z_BADI_INVOICE with

interface methods.

2. Implement BAdI ( SE19 ): Create

class Z_CL_INVOICE_IMPL .

3. Code: Implement logic in the interface method.

4. Call BAdI: Use GET BADI and CALL BADI in standard
program.

5.2 Using Enhancement Points

1. Identify Spot: Use SE24 to find ENHANCEMENT-

POINT in code.
2. Create Implementation: In SE19 , link to the spot
and add logic.

Debugging: Use ST05 SQL Trace or HAC_DBG for

enhancement breakpoints.

[SAP ABAP Enhancements]

├── User Exits
│ ├── Form-Based Exits (CALL CUSTOMER-FUNCTION)
 │ └── Field Exits (Validation/Substitution)
├── Customer Exits
│ ├── Function Module Exits
│ ├── Screen Exits
│ └── Menu Exits
├── Business Add-Ins (BAdIs)
│ ├── Classic BAdIs
│ └── New BAdIs
└── Enhancement Framework
├── Enhancement Points
├── Enhancement Sections
└── Composite Enhancements

Check Table vs. Value Table in SAP ABAP

First, check tables. A check table is used to

enforce foreign key relationships. When you define
a foreign key in a table field, the check table is
the referenced table. This ensures that the values
entered in the field must exist in the check table.
For example, if you have a field for 'Country' in a
customer table, the check table might be a
'Country' table that lists all valid country codes.
This way, users can't enter a country code that
doesn't exist in the 'Country' table. The system
automatically checks this during data entry. I
think this is done through foreign key constraints
defined in SE11.
Now, value tables. A value table is used for
providing possible entries (F4 help) to a field.
It's assigned at the domain level in the DDIC. When
a domain is used in multiple tables, the value
table associated with that domain provides the list
of valid values for all fields using that domain.
For instance, if a domain 'MATNR_DOM' has a value
table 'MATNR' (Material Number), any field using
this domain will have F4 help showing entries from
'MATNR'. However, unlike check tables, value tables
don't enforce referential integrity automatically.
The actual validation needs to be handled through
additional means like foreign keys or application
logic.

Wait, but sometimes people get confused between the

two because both involve referencing other tables.
The key difference is that check tables enforce
data integrity through foreign keys, while value
tables provide input help. However, if a value
table is assigned to a domain, but no foreign key
is defined, the system doesn't automatically check
if the entered value exists in the value table.
That's why even with a value table, you might still
need a check table via foreign keys to ensure data
consistency.

Check tables are defined at the field level in the

table structure, as part of the foreign key
relationship. Value tables are defined at the
domain level. So, all fields using that domain
inherit the value table for F4 help, but the check
table needs to be explicitly set for each field
where necessary.

[Keynote]
| Check Table
├── Defined at the field level in a table
structure.
├── Uses foreign key constraints
├── values present in the check table can be
entered
├── enforce validation
└── ensure referential integrity

| Value Table

├── Defined at the **domain level**

├── Provides a list of possible values via a
dropdown (F4 help)
├── **No automatic validation**
├── Used for **data consistency** across fields
└── Input Help and suggesting valid entries

Explicit vs. Implicit in ABAP

Explicit usually means something is clearly stated

or defined by the developer, while implicit is
handled automatically by the system without direct
input.
First, I need to think about different areas of
ABAP where these terms apply. The previous
conversation covered enhancements, BAdIs, check
tables, etc. But the user wants all possible
concepts. Let me brainstorm the main ABAP topics
where explicit vs. implicit comes into play.

Memory management comes to mind. In ABAP, there's

explicit and implicit memory management. Explicit
would be using CREATE OBJECT or NEW, while implicit
might be when internal tables are managed
automatically.

Enhancements [1] were discussed before. Explicit

enhancements use Enhancement Framework points
defined by the developer, while implicit are
predefined by SAP like BAdIs or customer exits.

Data type declarations: Using DATA vs. inline

declarations with TYPE. Inline is explicit, but
sometimes types are inferred implicitly.

Type conversions: Using CONV vs. automatic

conversion by the system. CONV is explicit, while
assigning a char to a string is implicit.

Object creation: CREATE OBJECT vs. inline

declarations with NEW. The latter is more explicit
in some contexts.

Method calls: Static vs. dynamic. Dynamic uses CALL

METHOD with variables, which is explicit, while
static calls are implicit.
Parameter passing: Pass by value vs. pass by
reference. Using VALUE is explicit, while default
is by reference implicitly.

Error handling: Using exceptions explicitly with

TRY-CATCH vs. runtime errors handled implicitly.

Field symbols and data references: Assigning

explicitly with ASSIGN vs. implicit assignments in
loops.

Open SQL: Using explicit joins vs. nested selects

which might be implicit.

Wait, maybe some of these need verification. Let me

check each concept to ensure accuracy.

For example, in data types: When you declare DATA

lv_num TYPE i, that's explicit. If you use
DATA(lv_str) = 'Hello', the type is implicitly
inferred as string.

Type conversions: If you assign a character to a

numeric field, ABAP does an implicit conversion.
Using CONV is explicit.

Object creation: CREATE OBJECT is explicit, but if

you use NEW #( ), it's also explicit, but maybe
more modern. Wait, maybe the user considers NEW as
explicit too. Need to clarify.

In method calls: Static method call is explicit

(CALL METHOD or directly), dynamic using a method
name variable is explicit in a different way. Maybe
the user is referring to dynamic vs. static as
explicit vs. implicit, but I need to frame it
correctly.

Error handling: TRY-CATCH is explicit exception

handling, while not handling exceptions and letting
the runtime dump occur is implicit.

Open SQL: Explicit joins are written using JOIN

clauses, while implicit joins are when you use
subqueries or FOR ALL ENTRIES, which might be
considered implicit.

Also, in ALV, explicit field catalog definition vs.

implicit generation using the structure.

BAPI vs. BADI

BAPI stands for Business Application Programming

Interface, and BADI is Business Add-In. Both are
used for enhancements and integrations, but they
serve different purposes.

Starting with BAPI: From what I remember, BAPIs are

standardized interfaces that allow external systems
to access SAP processes and data. They are like
predefined methods that can be called to perform
business tasks, such as creating a sales order or
updating a customer record. BAPIs are typically
used for system-to-system communication, enabling
integration between SAP and non-SAP systems. They
are based on RFC (Remote Function Call) enabled
function modules, which means they can be called
remotely.

Now, BADI: BADIs are enhancement techniques that

allow developers to add custom functionality to SAP
standard programs without modifying the original
code. They are object-oriented and use interfaces.
When a BADI is implemented, it plugs into the
standard SAP program at predefined points, allowing
for custom code execution. BADIs are more about
modifying or enhancing existing SAP functionality
rather than exposing it to external systems.

So the main differences would be in their purposes.

BAPIs are for integration and exposing SAP
functionality externally, while BADIs are for
enhancing existing SAP applications internally.

If the requirement is to integrate with an external

system, BAPI would be the way to go. But if the
need is to add custom logic to an SAP transaction
or report, then BADI is appropriate.

Efficiency-wise, BADIs are part of the SAP

enhancement framework and are designed to be
efficient when adding custom logic. They are
executed within the same SAP system, so there's no
overhead of remote calls. BAPIs, being RFC-based,
involve some overhead due to remote communication,
which might affect performance if used excessively
or in high-volume scenarios. However, BAPIs are
essential when external integration is required, so
their use is justified in those cases.

Another point to consider is maintainability. BADIs

are better for maintaining upgrades since they
don't modify standard code. BAPIs, when used
correctly, also maintain system integrity because
they use standardized interfaces. However, improper
use of BAPIs (like using undocumented or unstable
ones) can lead to issues during upgrades.

Table Operations

1. Declaring Internal Tables

Syntax:

TYPES: BEGIN OF ty_structure,

field1 TYPE datatype,
field2 TYPE datatype,
END OF ty_structure.

DATA: lt_table TYPE TABLE OF ty_structure, "

Standard Table
lt_sorted TYPE SORTED TABLE OF ty_structure "
Sorted Table
WITH UNIQUE KEY field1,
lt_hashed TYPE HASHED TABLE OF ty_structure "
Hashed Table
WITH UNIQUE KEY field1.
2. Filling Tables

a. APPEND : Add a row to the end (standard tables).

DATA: ls_row TYPE ty_structure.

ls_row-field1 = 'A'.
APPEND ls_row TO lt_table.

b. INSERT : Add a row at a specific index or key.

INSERT ls_row INTO lt_table INDEX 2. " Insert at

index 2 (standard tables)
INSERT ls_row INTO TABLE lt_sorted. " Insert into
sorted/hashed tables

c. COLLECT : Sum numeric fields for unique keys.

ls_row-field1 = 'A'.
ls_row-field2 = 10.
COLLECT ls_row INTO lt_table. " Aggregates field2 for
duplicate keys

d. Inline Population (ABAP 7.4+):

DATA(lt_table) = VALUE ty_table(

( field1 = 'A' field2 = 10 )
( field1 = 'B' field2 = 20 )
).

3. Reading Data

a. READ TABLE (by index or key):

 READ TABLE lt_table INTO ls_row INDEX 1. " By index
READ TABLE lt_sorted INTO ls_row WITH KEY field1 = 'A'.
" By key (sorted/hashed)

b. LOOP AT (iterate through rows):

LOOP AT lt_table INTO ls_row WHERE field1 = 'A'.

WRITE: / ls_row-field2.
ENDLOOP.

c. Table Expressions (ABAP 7.4+):

IF line_exists( lt_table[ field1 = 'A' ] ). " Check

existence
ls_row = lt_table[ field1 = 'A' ]. " Direct
access
ENDIF.

4. Modifying Data

a. MODIFY (update by index or key):

ls_row-field2 = 50.
MODIFY lt_table FROM ls_row INDEX 1. " By index
MODIFY TABLE lt_sorted FROM ls_row. " By key
(sorted/hashed)

b. Update in LOOP :

LOOP AT lt_table ASSIGNING FIELD-SYMBOL(<fs_row>).

<fs_row>-field2 = <fs_row>-field2 * 2. " Direct
 modification
ENDLOOP.

5. Deleting Data

a. DELETE (by index, key, or condition):

DELETE lt_table INDEX 1. " By index

DELETE lt_sorted WHERE field1 = 'A'. " By key
(sorted/hashed)
DELETE lt_table WHERE field2 > 100. " By
condition

b. Delete Adjacent Duplicates (after sorting):

SORT lt_table BY field1.

DELETE ADJACENT DUPLICATES FROM lt_table COMPARING
field1.

6. Sorting

a. SORT :

SORT lt_table BY field1 ASCENDING field2 DESCENDING.

b. Predefined Sorted Tables (no explicit sorting

needed):

" Declare as sorted table with key during definition

DATA(lt_sorted) = SORTED TABLE OF ty_structure WITH
 UNIQUE KEY field1.

7. Aggregations

a. SUM , COUNT , etc. in LOOP :

LOOP AT lt_table INTO ls_row GROUP BY ( key = ls_row-

field1 )
ASSIGNING FIELD-SYMBOL(<group>).
WRITE: / <group>-key, 'Total:', REDUCE i( INIT sum = 0
FOR <row> IN
GROUP <group>
NEXT sum =
sum + <row>-field2 ).
ENDLOOP.

8. Table Metadata

a. DESCRIBE TABLE :

DATA lv_lines TYPE i.

DESCRIBE TABLE lt_table LINES lv_lines. " Get row count

9. Copying/Merging Tables

a. MOVE-CORRESPONDING :
 DATA: lt_target TYPE TABLE OF ty_target.
MOVE-CORRESPONDING lt_table TO lt_target. " Copy fields
with matching names

b. Append/Insert Lines:

APPEND LINES OF lt_table1 TO lt_table2. " Append

multiple lines
INSERT LINES OF lt_table1 INTO lt_table2 INDEX 1.

10. Advanced Operations

a. Binary Search (for sorted tables):

SORT lt_table BY field1.

READ TABLE lt_table INTO ls_row
WITH KEY field1 = 'A' BINARY SEARCH. " Faster for
large tables

b. Dynamic Access with Field Symbols:

ASSIGN lt_table[ 1 ] TO FIELD-SYMBOL(<fs_row>). " Access

via index
<fs_row>-field1 = 'Z'.

11. Clearing/Freeing Memory

CLEAR lt_table. " Reset table (keeps memory)

FREE lt_table. " Release memory
1. Enhancements
Explicit Enhancements:
Developer-defined hooks (e.g., Enhancement
Points/Sections) inserted into standard code
using the Enhancement Framework.
Example:

ENHANCEMENT-POINT my_epoint SPOTS my_spot.

Use Case: Add custom validation in a standard SAP
program at a specific point.

Implicit Enhancements:
Predefined by SAP (e.g., BAdIs, Customer
Exits, User Exits).
Example: Implementing a BAdI method for custom
pricing logic.

Use Case: Modify SAP standard behavior without

touching original code.

↩︎