SAP ABAP BASICS

The Data Dictionary, also known as the ABAP Dictionary

The Data Dictionary is a central place in SAP where all data definitions are
stored. It defines the structure of data that is used throughout your programs,
tables, screens, etc.
Datatype: Define the kind of data a variable can hold, like numbers, text, dates,
or binary data.
Data elements : Define how a field or column will be displayed to the end user.
Domain : information about the fields and columns, including their datatype and
length.

In Tab delivery and maintenance

Delivery class :
Delivery class for controlling data transport of tables for installation, upgrade and
client copy and for transporting between customer system.

Data browser and table view editing.

This means a user can display or change data using SE11, SE16, or SE16N, granting
them access.

We can maintain data within a table using SE11, SE16N, or SE16. However, we
cannot directly add values to a table; instead, we use the table maintenance
generator.

To generate a table maintenance generator, we need to create an TMG without

authorisation group. Once created, we can maintain data using SM30.

Data is primarily classified into three types:

1. Master data: frequently used data that rarely requires changes, such as
employee data.
2. Transaction data: data that always changes and increases, like banking data.
3. Configuration data: data that can be customised, such as employee designations.

There are three types of tables:

- Transparent tables 1:1 relation ship Supports foreign key

relationship
- Pooled tables 1:N relation ship Does not support
foreign key relationship
- Cluster tables 1:N relation ship Supports foreign key
relationship
SAP creates cluster and pool tables when data is frequently retrieved from
multiple tables, as this reduces the number of read statements to the database.

Structure: It is a collection of fields and columns with no data inside.

Include structure: It is a reusable structure that can be inserted at any point. It

is applicable to customer-specific tables.

Append structure: It is not a reusable structure and can only be inserted at the
end. It is applicable to both customer and SAP tables.

View : View is a virtual table, it is logical database, it is don’t have any data.
Brings data from different tables

Types:
- Database view: A combination of multiple views.
- Projection view: A single table view that selects only the required fields.
- Maintenance view: This view maintains the values for multiple views as a single
view. Each entry should only appear once in both the header and item table. The
relationship cardinality needs to be 1:1.
Pre-requirement: Tables must have a relationship between them.
- Help: Used in search assistance. (The relationship cardinality needs to be 1:1.)
In Help View, I can’t display the contents. We can display this view’s contents using
the Search Help feature.

INDEX:
An index is created to provide high performance, always storing data in a sorted
index.
Occupy space in the database. Store in database as ZI~data
Search help
Search help, also known as F4(value help) help, displays the possible values for an
input field.
Search help 2 types
Elementary search help, or single search help, provides information about a
single search term.
Collective search help, or combination search help, combines information from
multiple elementary search terms.

Selection Method: It is the name of the table or the name of the view from
which we are fetching the data.

Dialog Type:
- Display values display: The values are displayed immediately.
- Dialog with values restriction: Before displaying the values, a restriction dialog
will appear.
– Dialog depends on the set of values: If the table has less than 100 values,
it will immediately trigger a dialog box.

Table Buffering:
- Buffer: Temporary storage in the application layer.
- Improves performance: When accessing data records in the table.

Types of Buffering in tables:

- Buffering not allowed: Not permitted.

- Buffering is allowed: Permitted.
- Buffering allowed but switched off: Permitted but disabled.

Buffering Types:
- Single Record Buffered: This type is used when we are performing a filter on a
table with a key field.
- Generic Area Buffered: This type is used for records that match a generic key,
defined by the user. It is used on language-dependent tables. For example, if we
need to retrieve English language record values, we would use this generic area
buffer.
- Full Buffering: This type is used for tables that are frequently accessed and
rarely changed. However, it is important to note that full buffering should not be
activated for transactional data.

Lock objects.
Lock objects are used to synchronise data. If multiple users are trying to change
the data, only one user will be able to change it, while the others will be locked.
Tcode SM12 allows you to view lock attempts. If we lock entries coming from the
enqueue server, these are temporary entries.
Types of lock
Read lock (shared lock): The default value is ’S’. Other users can display the data,
but they cannot change it.

Write lock (exclusive lock, Change lock): The default value is ‘E’. It prevents other
users from displaying, reading, or writing the data. A same user can request this
lock multiple times during the same transaction.

Enhanced write lock (exclusive lock without cumulation): The default value is ‘X’. It
prevents other users from displaying, writing, or reading the data. It also
prevents the user from requesting multiple accesses for the same transaction.

To create lock objects, we must begin with a prefix of either ‘EZ’ or ‘EY’.
Whenever we create an active lock object, it automatically creates two function
modules: ENQUEUE and DEQUEUE.

SY-MSGV1 provided the username.

Message class creation: Tcode SE91

Check Table:
• Check Table Functionality: Checks field values and restricts possible
values.
• Check Table Definition: Defines the set of all possible entries to a field.
• Input Help: Contents of the check table are automatically offered as
input help.

Value Table :
● Value Table Function: Value table works at domain level and checks table
fields referring to a domain.
● Value Table Definition: A value table is defined in a domain when table fields
need to be checked against a certain table.
● Value Table as Check Table: A value table becomes a check table when a
foreign key is defined.

*************************REPORTS*************************

Classical Reports:
Whenever we display output using the write statement called as classical report.
We can provide input to the programs through parameters(single) and select
options.(multiple or Range )

SQL (Structured Query Language) has two types: open SQL and native SQL.
● Open SQL operates independently of the database.
● Native SQL is dependent on the specific database system.

For all entries.

Selecting items based on a header table internal table means that only the values
present in the header table will be checked in the item table

JOINS
Joins allow us to fetch data from multiple tables.

Inner join: A inner join finds and returns the matching data from tables based
upon the condition.
If no condition is met, no records will be retrieved.

Outer join
An outer join finds and returns matching data from both tables, as well as non-
matching data from the table.

There are two types of outer joins: left outer join (left join) and right outer join
(right join).

- A left outer join takes all the data from the left table and combines it with the
values from the right table to meet the criteria.
- A right outer join takes all the data from the right side table and combines it
with the values from the left side table that meet the criteria.

Column Labels:
Column labels are used to display the names of the columns or fields in the output
screen.

Instead of hardcoding the field names to display in the output screen, we can use
the text elements feature.
Text Elements.
Text symbols are data objects that are not declared within the program and are
part of text elements.(000 to 999)
If we want to translate the English language to German, we need to go to Edit,
Translation, and add the German language in text elements.

Add vertical lines for fields in the output screen using the Sy-vline.
Sy-uline for horizontal line.

Message Classes
The Message class plays a crucial role in displaying messages to the end user. In
ABAP, there are various types of messages, including Abort (A), Error (E),
Information (I), Success (S), Warning (W), and Exit (E).
Transaction code : SE91.
We can declare the message class at the start of the program so we can use it
every time.

The above picture displays an error message as an information message.

TRANSACTION CODE CREATION

Tcode : SE93 Create a transaction code for particular program.

Best performance Guidelines.

- Never use the asterisk (*) in your query; instead, only fetch the required
columns.
- Ensure that the column fetching sequence in your query matches the order of
columns in your data dictionary.
- The where condition column sequence should be as similar as possible to the
data dictionary column sequence.
- Avoid using the corresponding keyword in your query.
- For traditional databases, avoid using joins; instead, use the “for all entries in”
clause. (HANA is not a traditional database, so we can use joins.)
– When retrieving data from foreign key or dependent tables, verify if the
subquery=0 results in 0 or if the internal table remains uninitialised.
– Employ binary search to access the internal table (sorting is mandatory).
– Use Parallel cursor in nested loops.
– Parallel cursor - Improves performance for nested loops.
– Sy-tabix = Current index in loop.

–
– The parallel cursor method works like a nested loop. It checks the condition
of the outer loop and goes inside the inner loop. It loops until it fails, then
comes out of the inner loop and starts from the outer loop, trying different
values.
– Never write a query inside a loop.

Classical report events.

Events are always triggered by a specific action or occurrence, such as reaching

a particular time.

Here are some examples of classical report events:

1. Initialisation
2. At the selection screen
3. The start of the selection
4. The end of the selection
5. The top of the page
6. The end of the page
7. At the selection screen, output data
8. At the selection screen, requesting a value for a field
9. At the selection screen, requesting help for a field
10. At the selection screen, on a field
Example selection screen for below logic.

Initialisation:
This event triggers before (F8) displaying the selection screen. Its purpose is to
provide default values for parameters and options on the selection screen.

At selection screen:
This event is triggered when a user performs an action (such as entering or
clicking any thing on screen include F8 ) on the selection screen. Its purpose is to
validate the input; if the input is incorrect, it throws an error.

Start of selection.
The event occurs when the user presses the “Execute” F8 button on the section
selection screen. The selection logic is part of this event.
***Even after pressing the execute F8 button, the selection screen first validates
the input. If the input is correct, it moves to the start of the selection.
End of selection :
This event is triggered when the selection process ends, helping to identify the
end of records.

Top of Page :
This event is triggered when the first write statement occurs in a program. Its
purpose is to provide a title or header at the beginning of a new page.
SY-PAGENO it will automatically prints page number.

End of Page :
When a last write statement occurs on a page, this event will automatically
trigger.

Lines 10(2) means 2 are reserved for the end of the page

At selection screen output :

- Event Trigger: This event is triggered before the selection screen is displayed.
– Event Purpose: Modify the selection screen.
– Event Types: Initialisation event (called once) and selection-screen output
event (called every time).
AT Selection-Screen and AT Selection-Screen Output Comparison

● The AT Selection-Screen event is triggered when the user performs an action

on the selection screen.
● This event can be triggered by actions such as entering or clicking.
● The AT Selection-Screen Output event is called before the selection screen is
displayed.
● The AT Selection-Screen event is used to validate the user’s input, while the
AT Selection-Screen Output event is used to modify the selection screen.
● The AT Selection-Screen event is equivalent to the PAl(Process After Input) of
the module pool, while the AT Selection-Screen Output event is equivalent to
the PBO(Process Before Output) of the module pool.

Instead of doing with above method we can use MODIF ID.

The user command below acts as a function code.

At Selection screen on value Request for field :

This event is triggered when the user clicks F4 on a selection screen. Its purpose
is to provide the value help for the input field.
Function module used to create the F4 help for field in selection screen.
F4IF_INT _TABLE _VALUE REQUEST
SY-REPID = Current program Name.
SY_DYNNR = Current screen number.
At the selection screen help request for a field,
At the selection screen help request for a field, when the user clicks on F1 (help
request for a field), this event is called. The purpose of this event is to provide
technical information about the field.
To create documentation in SE61 Tcode, we need to call the function module
“HELP_OBJECT_SHOW”.

Interactive classical report.

- Classical Report Output: Displayed on a basic list without interaction.
- Interactive Classical Report Output: Allows interaction with the basic list,
enabling navigation to secondary lists based on user selection.

Interactive classical report events occur at the following locations:

- At line selection
- At user command
- Top of the page during line selection

At line selection:
When the user double-clicks on a line or selects a line and presses F2(choose), or
when the user selects a line and clicks, the line-selection event triggers.
SY-LISEL: Which returns the contents of the selected row.

Statements at Interactive classical reports.

● HIDE Statement Functionality: Stores line-specific information from a basic
list for use in secondary lists.
● HIDE Statement Syntax: HIDE <f>, where <f> represents the variable whose
contents are hidden.
● HIDE Statement Usage: Used in interactive reporting to manage information
flow between basic and secondary lists.
● HIDE Area Purpose: Stores field names, values, and line numbers.
● HIDE Statement Location: Must be placed after a WRITE statement and
within a loop.
Get cursor statement.
● Function: Creates secondary lists based on cursor position in interactive
classical reports.
● Parameters: `FIELD` specifies the output field name, and `VALUE` provides the
output value.
● Syntax: `GET CURSOR FIELD <lv_field> VALUE <Iv_value>`.

Hide and Get Cursor Camparision

● HIDE Statement Scope: Responds to a specific line.
● GET CURSOR Statement Scope: Responds to a specific field.
● Additionally, GET CURSOR supports displaying secondary lists based on field
name and value, whereas HIDE does not.

AT User Command :

Whenever we create our own function, this event will trigger. The ‘sy-ucomm’
system variable is used to capture the values within the function code.
Example : This event will trigger when the function outputs the order on the
display screen based on a PO number in ascending and descending order.
We need to create a function within our program that will display when we
double-tap on it. We can then create this function in the application toolbar.

Top of the page during the line selection;

• Event Trigger: Occurs on the first WRITE statement for a new page on
the secondary list.
• Event Purpose: To display a title or header at the beginning of a new
page in secondary list.

Field symbol.
• Field Symbol Definition: Placeholders for data objects that don’t reserve
physical memory space.
• Field Symbol Syntax: `FIELD-SYMBOLS <fs>`, where `<fs>` is the name
of the field symbol.
• Generic Field Symbol: Field symbols with generic data types like `ANY`
and `ANY TABLE`, used for dynamic programming.

ALV : Application list viewer;

ALV, also known as Application List Viewer or ABAP List Viewer, offers several
inbuilt features. These include sorting data in ascending or descending order,
filtering data, exporting data, and calculating the sum of amounts in specific
columns.

To create an ALV, follow these steps:

1. **Step 1: Create a Field Catalog**

● - You can use a SAP Function Module (REUSE_ALV_FIELDCATALOG MERGE)
to create a field catalog, or manually create one.
2. **Step 2: Bind Data with the Field Catalog**
- You can use the following SAP Function Modules to bind data with the field
catalog:
 - REUSE_ALV_LIST_DISPLAY : Static output
- REUSE_ALV_GRID_DISPLAY : Dynamic output
- REUSE_ALV_HIERSER LIST_DISPLAY
3. **Non-Event-Based Functionality**
- ALV also offers non-event-based functionality, such as sorting and filtering
data.
4. Event Types: Double clicking, Hotspot clicking.

OOPS ABAP.

● Class Definition: A class is a collection of objects.

● Object Definition: An object is an instance of a class.
○ There are two types of classes: global and local.
○ 4 types of Global class: we usually write in SE24 transaction, we can call
in any program.
◆ Usual abap class: purpose is to write the logic(function module)
◆ Exception class: purpose is to raise and handle the exceptions
◆ Persistence class: Purpose is to perform database operations
◆ Unit test class: purpose is to write us=nit test cases
• Local Class : Local classes are dedicated to one program.
• Class Definition: Declaration.
• Class Implementation: Logic.
Methods: internal procedures of a class that determine the behaviour of an
object.
● There are two types of methods: instance and static.
○ a) Instance Method -> We need to create a object to call that method.
◆ -> Instance Method (Methods).
○ b) Static Method -> There is no need to create a object.
◆ => Static Method. (Class-Methods).
● Instance methods must be called with an object, while static methods can be
called with the class name.
● The visibility of a method can be public, private, or protected.

Inheritance.
By inheriting the properties of the parent class, the child class can be created.
The final class cannot be inherited.

Abstract Class.
● Abstract Class Definition: A special type of class with at least one abstract
method.
● Abstract Method: A method with only a definition, lacking implementation.
● Object Creation: Objects of an abstract class cannot be created; only objects
of its subclasses can be created.
Never take an abstract class with a final.
Steps:
1. Create an Abstract class in SE24.
2. Create a subclass for the same by giving the abstract class as a
property(super class) in the subclass.
3. Redefine the Abstract method in the subclass to write the code in the subclass
method using the keyword “Redefinition”.

Polymorphism
(Taking Abstract class for polymorphism example)
Polymorphism is the ability for a single method definition to behave differently
based on the class implementation being called.

Consider we created an abstract class called ZA_abstract and two different

subclasses for it by redefining the methods in those subclasses. One subclass
retrieves sales order details, while the other retrieves bilingual documents.
Despite having a single definition from the abstract class, we are using it in
multiple forms, which is known as polymorphism.

Method overriding:
● The task is performed in two classes with an inheritance relationship
(superclass method and subclass method).
● In method overriding, methods must have the same name and signature.
● The behaviour of the parent class is changed in the subclass.

Interface :
● In interface, all methods are public by default.
● In the interface, all methods are Abstract methods (there is only definition, no
implementation).
Interface is also exhibiting the properties of Polymorphism.

Feature Abstract Class Interface

Abstract Methods At least one abstract All methods are
method abstract
Method Visibility Can be public, private, All methods are
or protected public
Implementation Abstract methods Not required,
must be redefined in implementation
subclasses provided in class
Multiple Inheritance Not possible Possible
 method abstract
Method Visibility Can be public, private, All methods are
or protected public
Implementation Abstract methods Not required,
must be redefined in implementation
subclasses provided in class
Multiple Inheritance Not possible Possible

Multiple inheritance: creating a child class from 2 different parent classes

Class 1 ───── Class 3 Class 2

● Class 1 and Class 2: Represent parent classes with their own attributes and
methods.
● Class 3: Acts as the child class inheriting properties from both Class 1 and
Class 2 (multiple inheritance scenario).

Key Concepts:
. Inheritance: Class 3 inherits features (methods/attributes) from both Class 1
and Class 2.
. Polymorphism: Class 3 can override or redefine methods from parent classes.

This flow shows how Class 3 utilises functionalities from Class 1 and Class 2,
enabling code reusability and efficient object-oriented programming in SAP ABAP.

Events
● Events: Method of one class can call method of another class.
● Triggering Method: which will raise method.
● Event handler method: which will handle the method.
● Register event handler method using set handler method.

Registering the event handler method.

• Constructor Definition: A special method automatically executed when

an object is created.
• Constructor Naming: Predefined name, cannot be called directly.
• Constructor Uniqueness: Only one constructor allowed per class.
A constructor is a special type of method. Whenever we create an object, it
automatically calls the constructor.
. There are two types of constructors: constructor instance and class
constructor (static constructor).
. - **Constructor instance:** This constructor has only importing parameters
and can access both static and instance attributes. It is called every time an
object is created and is used to set default values for a particular instance.
. - **Class constructor (static constructor):** This constructor, which has no
parameters, can only access static attributes. It is called first time when an
object is created. This means that if we have both a static and an instance
constructor, the instance constructor will be called first.
Enhancement and modifications:
Enhancements: We will enhance the SAP functionality in the Customer namespace
Z or Y).

Modifications: We will enhance the SAP functionality in the SAP namespace. The
name of the namespace should not start with Z or Y).

Types of Enhancements and Modifications:

. - Implicit and Explicit Enhancements: Enhancement

. - Customer Exit (Function Module Exit, Menu Exit, Screen Exit): Enhancement
. - BADI (Business Add-Ins): Enhancements
. - User Exit: Modification

Implicit Enhancement:
- Implicit point: can be found at the start or end of a line.
- We create an implicit enhancement at those points
Steps: Edit->enhancement operation-> show implicit enhancement.->create
implementation

Explicit Enhancement:
- Explicit point and section are available at any line.
- We create explicit enhancements at those points and sections.

The Customer Exit

Function module Exit allows us to add our code to SAP programs using function
modules.
● Syntax: CALL CUSTOMER-FUNCTION ‘three digit number’.
● The three digit number in the above syntax can vary from 000 to 999.
• Example: CALL CUSTOMER-FUNCTION ‘001’.
How to find an exit?
Put the brake point in the call customer-function, trigger the debugger mode,
check will function is satisfy our requirement.
We can find with the help of package in Tcode SMOD to implement the function
module exit Tcode is CMOD.

Steps to Implement a Function Module Exit

● Project Creation: Go to transaction code CMOD, provide a project name, and
click “Create”.
● Customer Exit Assignment: Click on the “Enhancement Assignment” tab, provide
the customer exit name.
● Function Module Exit Modification: Double click on the required function
module exit in the “Components” tab, write the logic in the Z include, and
activate the project.

Menu Exit.
● Menu Exit Functionality: Allows adding menu items to SAP programs with
function codes starting with “+”.
● Menu Item Purpose: Enables customer-specific functionalities within SAP
programs.
How to find Menu exit?
• Menu Item Check: Check for menu items starting with “+” in the menu
bar.
• Package Name Retrieval: Use SMOD transaction code to find the
package name of the program.
• Customer Exits Access: Use transaction code SE84 to access
enhancements and customer exits.

Screen Exit
● Screen exit allows us to add fields to the screen of SAP programs using the
customer sub screen. SAP provides sub-screen areas within a standard screen.
The customer sub screen is called within the standard screen flow logic.
● To call a customer sub screen into a standard screen, use the syntax:
● CALL CUSTOMER-SUB SCREEN ‘sub screen area’ INCLUDING ‘program name’
‘customer sub screen number’.
● For example, you could call the customer sub screen “custscr2” within the
standard screen “SAPLXT” with the sub screen number “2000”.

Here are some ways to find a screen exit:

● 1. Check the screen flow logic for the statement CALL CUSTOMER-
SUBSCREEN.
● 2. Put the package name of the program in the SMOD transaction code (use
the utilities - find - package name option).
● 3. Go to the transaction code SE84 (enhancements - customer exits).

BADI
● BADI Definition: BADI is an enhancement that enhances SAP functionalities
within the customer namespace.
● BADI Basis: BADI is based on OOPS concepts, including interfaces and classes.
● BADI Transaction Codes: SE18 and SE19 are used for defining and
implementing BADI, respectively.
Two types of BADI.
● Classic BADI: A traditional enhancement technique in SAP that allows for
custom implementations without modifying the standard code. It relies on
interfaces and is widely used in older SAP systems.
● New Kernel BADI: An advanced version of BADI integrated into the kernel,
providing better performance and flexibility. It supports multiple
implementations and is designed for use in modern SAP environments.

To find a classic BADI in SAP, follow these steps:

1. Access the Class: Open the class CL_EXIT_HANDLER in transaction SE24.
2. Set a Breakpoint: Place a breakpoint in the GET_INSTANCE method. This will
help you capture the execution flow when a BADI is triggered.
3. Trigger the Transaction: Execute the transaction where you suspect a BADI
might be implemented.
4. Capture the BADI Name: When the breakpoint hits, inspect the variable values.
The BADI name will be displayed in the debugging session.
. With the help of the package in transaction code SE80.

New Kernel BADI

Key Differences Between Classic and Kernel BADI:
● Classic BADI: Implemented using older enhancement techniques, relying
heavily on interfaces and less flexible in handling multiple implementations.
● Kernel BADI: Integrated into the SAP kernel, offering enhanced performance,
greater flexibility, and supporting multiple implementations seamlessly.
Defining Kernel BADI:
● A BADI associated with an Enhancement Spot is classified as a Kernel BADI.
Enhancement Spot: Acts as a container for Kernel BADIs, providing a framework
where new BADI implementations can be managed efficiently.

Steps to create a New BADI:

1. Navigate to the transaction code SE19.
2. Select the radio button “New BADI”.
3. Enter the name of the enhancement spot.
4. Click “Create”.
5. Provide the name of the enhancement implementation, description, and the
name of the BADI implementation.
6. Choose the implementing class and the corresponding BADI definition.
7. Double-click on the class and write the logic in the relevant method.
8. Activate the class.

User Exits.
• Definition: Modifications enhancing SAP functionalities within the SAP
namespace.
• Availability: Only available in the SAP SD module and presented as
subroutines.
• Sales Order User Exits: Most important ones are available in program
MV45AFZZ.

Core Data Services (CDS) in ABAP

Core Data Services (CDS) expands ABAP's data modelling capabilities by allowing
the definition of semantically rich, database-independent data models. Here are
more core data services in ABAP beyond basic CDS Views:

1. CDS Views Enhancements

● Annotations: Add metadata to enhance the usability of CDS Views in UI,
analytics, and services. Examples include @AbapCatalog.sqlViewName,
@OData.publish, @UI.lineItem, etc.
● Associations: Define relationships between tables or views, replacing traditional
joins with more readable syntax.
● Path Expressions: Navigate through associations directly in queries.

2. CDS Table Functions

● Definition: Enables custom SQL logic in CDS by integrating ABAP Managed
Database Procedures (AMDP).
● Usage: Suitable for complex calculations that are not achievable with standard
CDS Views.
● Example:
● DEFINE TABLE FUNCTION ZTF_SALES_DATA
● RETURNS { client_id: abap.int4; sales_total: abap.dec(15,2) }
● IMPLEMENTED BY METHOD ZCL_SALES_DATA=>GET_DATA;
●
3. CDS Hierarchies
● Used to model hierarchical data structures like organisational charts or
product categories.
● Simplifies the representation of parent-child relationships.

4. CDS View Types

● Basic Views: Directly built on database tables for simple data extraction.
● Composite Views: Built on top of basic views, allowing data aggregation and
joining.
● Consumption Views: Designed for front-end consumption, optimised for
analytics and UI5 apps.

5. CDS Authorisation Checks

● Inline authorisation can be handled using @AbapCatalog.authCheck.
● Example:
● @AbapCatalog.authCheck: #CHECK
● DEFINE VIEW ZEMPLOYEE_DATA AS SELECT FROM zemployee
● { id, name, department }
● WHERE department = 'IT';
●
6. Analytical CDS Views
● Support analytical queries with annotations like @Analytics.query: true.
 ● Enable integration with SAP Fiori and SAP Analytics Cloud.

7. CDS with OData Services

● Expose CDS Views as OData services using @OData.publish: true, enabling
easy consumption in SAP Fiori applications.

8. ABAP Managed Database Procedures (AMDP)

● AMDP methods are written in SQLScript and embedded in ABAP classes.
● Used within CDS Table Functions for advanced database operations.

Benefits of Core Data Services in ABAP

● Simplified data modelling
● Improved performance through database optimisations
● Enhanced security with integrated authorisation checks
● Seamless integration with SAP Fiori and analytics tools

Table Functions:
• Additional Functionalities which is not supported in the CDS.
• Write SQL statements for the requirement.
• SQL Script functions and methodologies.
Table Function Technical Design
● Has optional input parameters.
● Has return parameters (multiple records).
● Needs Class and Methods to define. - Class: Public, Method: Static.
● Interface: IF_AMDP_MARKER_HDB.

VDM type and data Category.

## Basic View:
● - Constructed atop DDIC tables or views.
● - Interacts with the database to retrieve data.
● - Source: Table or view.
● - Syntax: @VDM.Viewtype: #BASIC

## Composite View:
● - Created atop the BASIC view.
 ● - Does not engage with the database to retrieve data.
● - Multiple fundamental views can serve as sources.
● - Source: BASIC view.
- Syntax: @VDM.Viewtype: #COMPOSITE

## Consumption View:
● - Constructed atop the COMPOSITE view.
● - Excludes direct interaction with the database or fundamental views.
● - Provides users with data in diverse formats, including U15, HTML, Excel, BO,
and Lumira.
● - Source: COMPOSITE view.
● - Syntax: @VDM.Viewtype: #CONSUMPTION

Data Categories:

● Define your data based on your business requirements.

● - Dimension: Represents Master Data.

● - @Analytics.dataCategory: #DIMENSION.

● Fact:
● Represents Transaction Data.
● - Contains measures.
● - Should not be joined with Master data views.
● - @Analytics.dataCategory: #FACT.

- Cube:
● - Represents Transaction Data (similar to #FACT).
● - Can be joined with Master data views.
● - Consumption views are constructed atop the Cube.
● - @Analytics.dataCategory: #CUBE.

AMDP

ABAP Managed Database Procedures (AMDP) is a feature that enables the direct
implementation of database procedures within ABAP classes using SQLScript.

● AMDP offers several key features, including a technical design similar to Table
Functions, support for importing and exporting parameters, the ability to
return multiple values, and the option to invoke it from ABAP objects.

Aspect Table Function Procedure (AMDP)

Return Type Single return Multiple return types
parameter with possible
multiple records
Class Public Public,private,protecte
 Aspect Table Function Procedure (AMDP)
Return Type Single return Multiple return types
parameter with possible
multiple records
Class Public Public,private,protecte
d
Method Static Static & Instance
Parameter Handling Passed by value Passed by value (not
by reference)
Common Interface Implements Implements
IF_AMDP_MARKER_H IF_AMDP_MARKER_H
DB DB
Return Requirement Must return from the Must return from the
relevant method relevant method
Best Practices Use static methods Use static methods
for consistency. for consistency.
Ensure method Ensure method
parameters are parameters are
passed by value to passed by value to
avoid runtime issues. avoid runtime issues.
Always implement the Always implement the
IF_AMDP_MARKER_H IF_AMDP_MARKER_H
DB interface for DB interface for
AMDP classes. AMDP classes.

Annotations: a Note of explanation or Information.

Classifications:
ABAP Annotations -> evaluated in the abap runtime environment
Component annotations -> evaluated by the frameworks of the software
components
Annotation Array ;More than on field .

Authorisation check:
@Analytics.query: true means the query needs to hit the view, not a table.

IDOC (Intermediate Document)

IDOC is a standard data structure used in SAP for transferring data between
SAP systems and external systems. It facilitates seamless communication in
distributed environments.

Segments (Tcode: WE31):

● Segments are the basic building blocks of an IDOC, defining individual data
structures.
● Each segment consists of multiple fields that hold the actual data.
● Segments can be reusable across different IDOC types.

IDOC Types or Basic Types (e.g., MATMAS05):

● The basic type defines the structure and format of the IDOC.
● It maps IDOC types with corresponding segments.
● Specifies the hierarchical relationship between segments, indicating parent-
child relationships.
● Defines mandatory and optional segments with minimum and maximum
occurrences.

Message Type (Tcode: WE81):

● Message types determine the business context of the data being transferred
(e.g., MATMAS for material master data).
● A single message type can be associated with multiple IDOC types.
● Message types are assigned to basic types and IDOC types, facilitating
correct data mapping.

IDOC Processing and Configuration:

● Partner Profile (Tcode: WE20): Defines how IDOCs are processed for specific
communication partners.
● Port Definition (Tcode: WE21): Configures the technical communication settings
for IDOC transmission.
● Distribution Model (Tcode: BD64): Manages the logical flow of data between
systems.

IDOC Lifecycle:
. Creation: Triggered by an event, transaction, or program.
. Outbound Processing: IDOC is populated with data and sent to the external
system.
. Inbound Processing: Received by the target system and processed based on
configuration.
. Monitoring: IDOC status can be monitored using Tcodes WE02 and WE05.

IDOC Status Codes:

● Status 03: Data passed to the port OK (Outbound).
● Status 12: IDOC successfully processed (Inbound).
● Status 51: Error in inbound processing.

Release Number:
● The IDOC’s release number indicates the SAP version compatibility.
 ● Ensures that the IDOC structure aligns with system version requirements.

IDOCs play a critical role in enabling integration and data exchange across SAP
modules and external applications, ensuring efficient business process automation.

SAP IDOC Configuration Chart

Transaction Code (Tcode)
Definition
WE31
Create Segment – Defines the basic data structure for an IDOC with specific
fields.
WE30
Create Basic Type – Designs the structure and format of the IDOC, mapping it
with segments.
WE81
Create Message Type – Determines the business context of the data being
transferred.
WE82
Link Message Type and Basic Type – Associates message types with IDOC basic
types.
WE20
Configure Partner Profile – Sets up communication partners and adds process
codes with function modules for data exchange.
WE42
Add Process Code to Inbound Delivery – Assigns process codes to handle inbound
IDOC processing.

ODATA in SAP ABAP

OData (Open Data Protocol) is a protocol designed to facilitate the creation and
consumption of RESTful APIs, enabling seamless data exchange between SAP
systems and external applications. In SAP ABAP, OData services are primarily
used to expose data for use in UI5 applications, Fiori apps, or any external
system.

Key Components of OData in SAP ABAP:

. Entity Type:
○ An Entity Type represents a data model or structure, similar to a table in
the SAP backend.
○ It defines the properties (fields) of an entity, such as employee ID, name,
department, etc.
○ Each entity type has a key property that uniquely identifies each record
 ○
(like a primary key in a database).
○ Example: EMPLOYEE Entity Type with properties like EMP_ID, NAME,
DEPARTMENT, SALARY.
. Entity Set:
○ An Entity Set is a collection of entities of the same type, similar to rows
in a database table.
○ It allows operations such as Create, Read, Update, and Delete (CRUD)
on the data.
○ Example: EMPLOYEES Entity Set representing a list of all employee
records.

OData Service Creation in SAP ABAP:

. Define a Data Model:
○ Use transaction SEGW (SAP Gateway Service Builder).
○ Create a new project defining Entity Types and Entity Sets.
. Generate Runtime Artifacts:
○ After defining the data model, SEGW generates runtime artifacts:
◆ Model Provider Class (MPC): Defines the data structure.
◆ Data Provider Class (DPC): Defines how data will be fetched,
updated, deleted, etc.
. Implement CRUD Operations:
○ Use methods in the DPC_EXT class to implement logic:
◆ GET_ENTITY – Retrieve single records.
◆ GET_ENTITYSET – Retrieve multiple records.
◆ CREATE_ENTITY – Insert new data.
◆ UPDATE_ENTITY – Update existing data.
◆ DELETE_ENTITY – Delete data.
. Service Registration:
○ Register the OData service using transaction /IWFND/MAINT_SERVICE.
○ Assign system aliases and activate the service.

Navigation in OData:
● Associations and Navigation Properties are used to define relationships
between different entity types.
● Example: An Order entity may have a relationship with an Item entity.
○ Association: Links the two entities.
○ Navigation Property: Allows navigation from Order to Items.

OData Query Options:

OData supports various URL query options for efficient data handling:
● $filter: Filter data based on conditions.
○ Example: /sap/opu/odata/SERVICE/EMPLOYEES?$filter=DEPARTMENT eq
'IT'
● $select: Select specific fields.
○ Example: /sap/opu/odata/SERVICE/EMPLOYEES?$select=EMP_ID,NAME
● $expand: Load related entities.
○ Example: /sap/opu/odata/SERVICE/ORDERS?$expand=ITEMS
 ● $orderby: Sort data.
○ Example: /sap/opu/odata/SERVICE/EMPLOYEES?$orderby=NAME desc
● $top and $skip: Pagination control.
○ Example: /sap/opu/odata/SERVICE/EMPLOYEES?$top=10&$skip=5

OData Annotations:
Annotations enhance the metadata and functionality of OData services:
● @UI.lineItem: Defines how data should be displayed in Fiori apps.
● @Consumption.filter: Enables filters on fields.
● @Analytics.query: Defines analytical queries for reporting.

Security Considerations:
● Implement authorization checks within DPC methods.
● Use SAP Gateway roles to manage service access.

Gateway Methods in SAP OData Services

SAP Gateway methods facilitate communication and data manipulation via OData
services. These methods correspond to various HTTP verbs used in RESTful APIs,
allowing CRUD (Create, Read, Update, Delete) operations on data. Here’s an
elaboration:
. GET Method:
○ Purpose: Retrieve data from the server.
○ Usage: Used to fetch records from SAP systems.
○ Example: Reading employee details, sales orders, or material data.
○ Implementation: Defined in the GET_ENTITY or GET_ENTITYSET methods
within the service.
. POST Method:
○ Purpose: Create new data entries on the server.
○ Usage: Used for operations like creating a new sales order, customer, or
purchase requisition.
○ Example: Submitting a new leave request in an HR application.
○ Implementation: Handled in the CREATE_ENTITY method.
. PUT Method:
○ Purpose: Fully update an existing resource.
○ Usage: Replaces the entire resource with the provided data.
○ Example: Updating all details of an employee record.
○ Implementation: Defined in the UPDATE_ENTITY method.
. DELETE Method:
○ Purpose: Delete an existing resource from the server.
○ Usage: Removes entries like sales orders, customer records, etc.
○ Example: Deleting a cancelled purchase order.
 ○ Implementation: Managed through the DELETE_ENTITY method.
. PATCH Method:
○ Purpose: Partially update an existing resource.
○ Usage: Updates specific fields without affecting the entire resource.
○ Example: Changing only the phone number of an employee without
altering other personal details.
○ Implementation: Similar to the UPDATE_ENTITY method but processes
only the fields that are provided.
. MERGE Method:
○ Purpose: An older HTTP method similar to PATCH, used for partial
updates.
○ Usage: Less common; primarily used in earlier OData versions.
○ Example: Updating specific fields in legacy systems.
○ Implementation: Works similarly to PATCH but may vary depending on
system configurations.

Aspect CDS View (Core Data Classical View (SE11)

Services)
Where Created In Eclipse/ADT (code- In SE11 (SAP GUI,
based) GUI-based)
Features Supports annotations, Only basic joins and
associations, fields; no advanced
expressions, etc. features
Performance Optimized for SAP Not HANA-optimized;
HANA (code limited performance
pushdown)
Usage Used in OData, Fiori Used in classical
apps, analytical ABAP reports or
scenarios function modules
Extendibility Easily extendable Hard to extend once
with CDS View created
Enhancements