ABAP OOPS

BY SANJAY KUNAR
Basic OOPS Conecpt:
• Classes
• Methods
(a) Instance method
(b) Static method
• Attributes
(a) Instance attribute
(b) Static attribute
• Constructor
• Polymorphism
• Abstract classes
• Interfaces
• Friend class
Advance OOPS Concept:
• Persistent service
• Transaction service
• RTTS (ABAP Runtime Type service)
RTTF (Runtime Type Identification)
RTTC (Runtime Type Creation)
• Casting
• Event handling
• Design patterns
INTRODUCTION:

Procedure oriented / structured programming / modular

programming languages ---> C, PASCAL, COBOL --> Importance is
given to Functions

Object oriented --> ABAP, C++, JAVA, .Net

---> Importance is given to securing the data

Limitations in Procedural approach:

1. Editing report output and save in database tables is not possible

2. Limited events like at selection-screen, start-of-selection
3. Performance is bit week compare to OOPS
4. FM names wrong, not show any error at compile time. At run time it will go to
dump.
5. Security (Visibility sections)
Features of OOPS Oriented Programming Languages:

1. Encapsulation --> binding data and member functions into single

unit (class)
2. Data abstraction / Data hiding --> hiding the implementation
details
3. Inheritance ---> reusability (inheriting the components of parent
class into child class)
4. Polymorphism--> many forms behavior
Procedure followed for Basic ABAP Report development:

1. Declare variables, work areas, internal tables...

2. Generate selection screen for reading user input
(parameters/select-options)
3. Validate the user input
4. Execute select queries to read data from db into work area /
internal table
5. Process the work area/ internal table to show the content (data) to
the user
Types Declaration Vs class declaration:
types : begin of <type name>, (ty_emp) similar to -------> class declaration
field 1, empno components
field 2, ename
----
end of <type name>. endclass.
ty_emp-empno = 1. (invalid)
data wa_emp1 type ty_emp. similar to --> object1 based on class
wa_emp1-empno = 1.
wa_emp1-ename = 'Raju'.
data wa_emp2 type ty_emp. --> object2 based on class
wa_emp2-empno = 4.
wa_emp2-ename = 'Ramesh'.
Class ---> is a User defined data type which is a collection of components
C++ class ---> data members + member functions
Java class --> instance variables + methods
ABAP class ---> attributes + methods + events + interfaces + aliases + macros
ABAP ---> 2 types of classes
1. Local class--> local to an object (program) ---> ABAP editor (se38)
2. Global class --> global to all objects ----> class builder tool (se24)
---> stored inside class pool
Procedure for creating local class:
1. Definition of class:
Syntax:
class <class name> definition [public] [protected] [private]
[deferred] [final] [load] [abstract].
declaration of components.
endclass.

Note: If the class definition contains method declarations, then we need to implement the
class
2. Implementation of class:

Syntax:
class <class name> implementation.
implementation of methods.
endclass.

Note: Class definition and Class implementation doesn't allocate any memory,it only provides
template of the class

Instantiate the class ---> creating the object for the class--> memory will be allocated
Differences between Local & Global classes:
Object creation --> 2 steps :
1. Declare reference (alias) for the class :
Syntax:
data <ref.name> type ref to <class name>.

Note: reference doesn't allocate any memory, it only provides alias.

2. Create object based on reference:

Syntax:
create object <ref.name>. --> Memory will be allocated based on
components of class
Attribute:
It is like a variable which can be used to store the data.

Instance Attributes:
• In local classes they are declared by using the keyword “Data”.
• They are specific to object i.e. for every object, separate memory will
be allocated for each instance attribute.
• They can be accessed only by using the Object.
Static Attributes:

• In local classes they are declared by using the keyword “class-data”.

• They are also called as “Class Variables / Class attributes”.
• They are not specific to any object.
• The memory for static attributes will be allocated whenever the class is
loaded in to the memory i.e. memory will be allocated only once which
will be shared by all the objects of the class.
• They can be accessed either by using the object or by using the class
name.
Constant Attributes:
• In Local classes, they are declared by using the keyword ‘constants’. They must be
initialized at the time of declaration itself. The value of the constant attribute remains
same throughout the program.
• They are not specific to any object.
• The memory for them will be allocated whenever the class is loaded in to the memory i.e.
memory will be allocated only once which will be shared by all the objects of the class.
• They can be accessed either by using the object or by using the class name.

Note: We go for instance attributes whenever we need to maintain unique (different) values
for each object. We go for static attributes, whenever we need to maintain a common
(same) value for all the objects of the class. We go for constant attributes, whenever we
need to maintain a fixed value for all the objects of the class.
Methods:
• A method is a set of statements which is implemented only once and can be
called any no. of times.
• It is similar to subroutine / function module.
Subroutines: - 2 sections ---> definition ---> form...endform
Calling ---> perform <subroutine>.
Subroutine Parameters keywords used using, changing, tables
F.M's: 2 sections ---> definition --> function..endfunction (source code tab)
calling ---> call function <f.m>
Function Module Parameters -> keywords used -> importing, exporting, changing,
tables
 Local class methods:
There are 3 steps ->
• Declaration (Method prototype declaration) --> Inside Class definition
• Implementation --> Inside Class Implementation
• Calling --> outside class / inside other method implementation

Method Parameters:
• Types of parameters: importing, exporting, changing and returning.
• By Default, Importing parameters are obligatory.
• We can use the keyword ‘optional’ as part of local class method parameters to declare it as
optional parameter and in case of global class methods, select the checkbox ‘optional’
• Exporting parameters are always optional.
Procedure for using Local class methods:
1. Declaration
syntax:
methods/class-methods <method name> [parameters list].
2. Implementation
syntax:
method <method name>.
statements.
endmethod.
3. Calling
syntax 1:
call method <method name> [parameters list]
syntax 2:
<method name>( [parameters list] ).
Method Returning Values:
->In case of ABAP a method can return any no. of values. The no. of return values depends on
no of Exporting/changing Parameters.

Returning Parameters:

• In general, a method can return any no. of parameters.

• To restrict a method to return exactly one value, we must use returning parameter.
• If a method contains returning parameter it cannot contain exporting /changing parameters
at the same time or vice versa (prior EHP7)
• A method can contain only one returning parameter
• Returning parameter is always passed by value.
• Returning parameters are always optional.
Instance methods:
• In local classes they are declared by using the keyword “Methods”.
• They can be accessed only by using the object.
• They can access any kind of components of the class (instance / static / constant / types).
Static methods:
• In local classes they are declared by using the keyword “class-Methods”.
• They can be accessed either by using the object or class name.
• They can access only static components, constant attributes and types attributes. i.e they
cannot access instance components.

Note: In Local classes, the sequence of visibility sections (access specifiers) for the class
components should be in the order of public, protected, private sections.
Note: It is recommended to define and implement the local class at the beginning of
executable program and explicitly handle the event ‘start-of-selection’ after the class
implementation to indicate the starting point of program execution.
Me keyword:
• “Me” keyword refers to current object in execution i.e. as part of every instance method
execution (runtime), an implicitly created object (created by SAP) will be available and it
refers to the object which is currently executing the method.
• Note: If a class contains both attributes and methods, it is recommended to declare
attributes under protected/private sections and methods under public sections.
• Since we cannot access protected/private components outside the class, we need to access
them through one of the public method and call the public method outside the class.
Friend keyword:
• In General outside the class, A Object can access only public components of the class
directly. i.e protected and private components of the class cannot be accessed outside the
class using an object of a class.
• In order to enable the objects of the class to access all components of the class outside the
class irrespective of the visibility, then we can go for Friend classes.
• In local classes “Friend” is a keyword used as part of class definition to consider another class
as friend.
Deferred Keyword:
• As part of declaring local friend classes, we need to forward declare the friend classes by
using “Deferred” keyword. This deferred keyword indicates that the class definition is
provided somewhere else in the program and not at the beginning of the program.
• Note: In Global classes, we declare friend classes as part of ‘FRIENDS’ tab.

Load keyword:

• It is used to load the global classes or global interfaces explicitly in the executable program.
This is mandatory before the release 6.20 for accessing static components of the global class
or global interface before instantiating them.
• From 6.20, it is not required, but in case, if we get any compilation error while accessing the
static components / any other components of global class or global interface, then we can
load the global class or global interface explicitly from the class library by using load
keyword.
Constructor:
• Whenever an object is created, the attributes should be initialized with some initial values.
• It is special because it is executed/called automatically whenever an object is created
(instance const) or whenever a class is loaded in the memory (static const).
• They are always declared in public section.
• They never return any value.
• There are two types of constructors
1. Instance constructor.
2. Static constructor.

Instance constructor:
• They are declared by using the keyword “Constructor”.
• They can contain only importing parameters and exceptions.
• It is specific to object i.e. whenever a new object is created SAP executes “Instance
constructor”.
• Instance constructor is executed only once in the life time of every object.
Static constructor:
• It is declared by using keyword “class_constructor”.
• It cannot contain any parameters or exceptions.
• It is not specific to any object.
• It is executed only once in the life time of every class. I.e. it is executed in either of the
following cases.
Case 1: When we access any static components of the class before creating any objects for
the class. (or)
Case 2: when we create first object of the class before accessing any static components of the
class.
Note:
If a class contains static and instance Constructor and if we instantiate first object before
accessing any static components, than SAP first executes Static Constructor and then the
Instance Constructor will be executed on behalf of that first object, from the second object
onwards only instance constructor will be executed.
If an instance constructor contains any mandatory importing parameters, we must pass the
values to those parameters while creating objects itself.
Differences between Instance and Static Constructor:
Differences between normal method and s pecial
method (constructor).
NORMAL METHOD CONSTRUCTOR
It can declare any of section (Public, Protected,
It can declare in only public section
Private)

Automatically it will call. Explicit call not

It should call explicitly
required

Instance Constructor will call in life time of

It can any number of times by using the same
object. Static Constructor will call in life time
object
of class

Instance Constructor will allow only import

It can contain any type of parameters (Import,
parameters, Static Constructors will not allow
export, changing, returning)
any parameters

Can return any number of values Never written any value(exporting values)
INHERITANCE:
• It is a process of using the properties (components) of one class inside other
class.
• The main aim of Inheritance is Reusability of the components i.e. a
component declared in one class is accessible inside other class.
• In Inheritance, two classes are involved (super class/base class and sub
class/derived class).
• The class which gives properties is called as super class / base class.
• The class which takes the properties is called as sub-class/derived class.
• Only Public and Protected components can be inherited i.e. Private
Components cannot be inherited.
Types of inheritance:
1. SINGLE INHERITANCE: A Class acquiring properties from only one super class.
2. MULTIPLE INHERITANCE: A class acquiring properties from more than one entity
(interface).
Note: In ABAP, Multiple inheritance can be implemented using the combination of
class and interfaces.
3. MULTILEVEL INHERITANCE: A class acquiring the properties from another sub-
class.

Inheriting from – is a keyword used as part of local class definition for inheriting
another class.
A class declared as Final cannot be inherited i.e. it cannot have subclass. In case of
local classes, we use the keyword ‘final’ as part of class definition to declare a final
class.
Polymorphism:
Poly -> many,
Morph-> forms,
Ism-> behaviour
• It is a process of making an entity behaving in multiple forms.
• In this case, the entity is a method
Example:
Method overloading, Method Overriding.
Method Overloading:
• It is similar to function overloading in C++.
• It is a process of overloading the same method by passing different Number and different
types of parameters.
Eg: methods m1.
Methods m1 importing x type i.
Methods m1 importing x type c.
Methods m1 importing x type I y type i.
Note: ABAP does not support method overloading.
Method Overriding:
• If a subclass redefines a super class method it is called as Method Overriding.
• Whenever a local subclass wants to redefine the super class method, the sub class as to re-
declare super class method by using “redefinition” keyword.
• Whenever the super class method is redefined in subclasses, we cannot change the visibility /
category.
• Only public and protected instance methods can be redefined.
• Whenever a subclass redefines super class method, it is always recommended to call the super
class method implementation in the subclass and this is done by using “super” keyword.
• “Super” keyword is always used in subclass method implementations (inside redefined super
class method) to call the super class method implementation.
• A class declared as final cannot be inherited.
• Static methods cannot be redefined
• Instance public / Instance protected methods declared as final can be inherited but cannot be
redefined.
• A static public/static protected methods cannot be declared as final because by default, static
methods cannot be redefined.
Hierarchy of constructor execution-scenario 1:
If a super class contains static and instance constructor and subclass without any constructors,
and if we instantiate first object of super class/sub class before accessing any static
components of super/sub class ,then SAP first executes static constructor of super class and
then instance constructor of super class and from second object of super class/sub class only
instance constructor of super class will be executed.

Hierarchy of constructor execution-scenario 2:

If a super class contains static and instance constructor and subclass only with static
constructor, and if we instantiate first object of sub class before accessing any static
components of super/sub class and also before creating any objects for super class, then SAP
first executes static constructors from super class to sub class and then instance constructor of
super class and from second object onwards, only instance constructor of super class will be
executed.
Hierarchy of constructor execution-scenario 3:

• If a super class contains static and instance Constructor and subclass also with
static and instance constructor, then it is mandatory for sub class instance
constructor to call the super class instance constructor explicitly by using super
keyword.
• In this case, if we instantiate first object of sub class before accessing any static
components of super/sub class and before creating any objects for super class, then
SAP first executes static constructors from super class to sub class (top to bottom)
and then instance constructors from sub class to super class (bottom to top) and
from second object of sub class onwards, only instance constructors will be
executed from sub class to super class.
Hierarchy of constructor execution-scenario 4:
If a super class contains instance constructor with mandatory parameters and sub class also
contains instance constructor with mandatory parameters and whenever we instantiate the sub
class, make sure that you pass values for the parameters of sub class instance constructors and
from sub class instance constructor implementation we need to call super class instance
constructor by passing values for parameters of super class instance constructor.

Hierarchy of constructor execution-scenario 5:

If a super class contains instance constructor with mandatory parameters and sub class without
any instance constructor and whenever we instantiate the sub class, make sure that you pass
values for the parameters of super class instance constructors while instantiating sub class
object.
Visibility at Class Level - Public (default), protected,
private and abstract:
Public classes:

• The default visibility at class level is public.

• Public class can be instantiated anywhere (within same class/ inside subclasses /outside
classes).
• Public class can be inherited.
• The subclass inheriting the super public class is also created as public by default.
• The sub class inheriting the super public class can be created as explicit protected/private
class.
Protected classes:
• Create protected is the keyword used as part of local class definition to create
the protected classes.
• Protected class can be inherited.
• Protected classes cannot be instantiated outside the classes but they can be
instantiated inside same classes as well as inside subclass methods.
• The subclass inheriting protecting class is also created as protected by default.
• The subclass inheriting protected class can be created as explicit public class
(or) private class.
Private classes:
• Create private is the keyword used for creating the private classes.
• Private class can be inherited.
• Private class cannot be instantiated outside the classes and inside subclasses, but
they can be instantiated within the same class. In order to instantiate private classes
inside subclasses or inside any other independent class, the private super class
should consider sub class / independent class as friend.
• The subclass inheriting the private class is also created as private by default.
• By default, the subclass inheriting the private class cannot be created as explicit
public class / explicit protected class. This can be made possible if the super private
class considers subclass as friend.
ABSTRACT CLASS:
• Abstract is a class which contains one or more Abstract methods.
• An abstract method is a method which is just declared but not implemented.
• We declare a method as abstract when we are not sure about the implementation.
• The implementation for the abstract methods can be provided as part of subclasses.
• In local classes, abstract methods are declared by using a keyword “abstract”.
• If a class contains an abstract method, the class also should be declared as
abstract.
• Abstract methods are declared only in public and protected sections.
• Abstract methods are also called as non-concrete methods.
• Static methods cannot be declared as abstract as they cannot be redefined inside
subclasses
• Constructors cannot be declared as abstract as they cannot be redefined inside
subclasses
• The subclass whichever is inheriting the abstract class must implement all the
abstract methods of the abstract super class otherwise the subclass also should be
declared as abstract.
 Continue.....
• We cannot create the objects for abstract classes because they are not
implemented completely. But once abstract methods are implemented inside
subclass, we can instantiate the subclass and assign subclass object to abstract
super class reference which is called as narrow casting.
• Whenever narrow casting is done, by using super class object we can access
methods of super class only, in order to access direct methods of subclass using
super class object, we need to call the subclass method using dynamic calling
approach.
• Narrow casting is a process of switching the object from more detailed view to
less detailed view.
INTERFACES:
• An interface is a pure abstract class i.e. by default all the methods of interface are abstract.
• Interface components doesn’t contain any explicit visibility section, by default all the
components are public.
• Interfaces cannot contain method implementations, it contains only method declarations.
• A local class whichever want to implement an interface(local/global) , the class must declare
the interface in the public section by using ‘interfaces’ keyword and the class must
implement all the interface methods, Otherwise the class should be declared as “abstract”
and also the methods which are not implemented should be flagged (declared) as abstract.
In these cases, we must consider another class inheriting the abstract class and provide the
implementation for the abstract methods.
• The class which ever implements the interface is called as implementation class.
• Interface is always implemented in public section of local class.
• By using interfaces we can implement the concept of multiple inheritances.
Continue...
• I.e. a class can implement any number of interfaces.
• Whenever we refer to interface components outside the interface, the component of the
interface must be prefixed with the name of the interface.
• Interfaces cannot contain constructors
• If a class implements any interface and if that implemented interface contains any included
interfaces, then class must also implement all the methods of the included interfaces.
• If a global class has to implement one or more global interfaces, then global class must
declare those interfaces in the interfaces tab.
Differences between Abstract class and Interface:
Aliases:
• Aliases are the alternative names provided for interface components .i.e. whenever we
refer to the interface components outside the interface, it must be prefixed with the name
of the interface. This lengthy naming representation can be avoided by declaring “aliases”
for interface components.
• Aliases can be declared in any of the visibility sections inside implementation class
• Aliases declared inside interfaces are always public
• Aliases can be declared either in interfaces / in the implementation class.
• If the aliases as to be declared in the interface it can be declared only for included
interfaces components and that alias will be created as component of interface.
Note: The included interfaces can be referred directly in the implementation class .i.e. the
interface which is included in other interface can be directly referred in the implementation
class.
Note: As Part of global classes, If a global class Includes any interface in the interfaces tab and
the checkbox ‘final’ is selected, it indicates that these interface methods cannot be further
implemented (re-defined) in other classes.
Procedure for Classical Reporting:
1. Generate a selection screen for reading user input
2. Retrieve data from database tables based on user input
3. Process the internal table for display (write)
--> displays the output in L.P.S
Procedure for developing ALV reports using classes:
1. Create a Module pool screen
2. Place custom control component on the module pool screen
3. Create the object for container class 'CL_GUI_CUSTOM_CONTAINER’ linking with custom
control (physical control on module pool screen toolbox)
4. Create the object for grid class 'CL_GUI_ALV_GRID' linking with container object
5. Retrieve the data to be displayed in the ALV grid
6. Generate the field catalog for the fields of ALV grid
7. Generate the layout for the ALV grid (optional)
8. Display the data in the ALV grid using the method 'SET_TABLE_FOR_FIRST_DISPLAY' of the
grid class 'cl_gui_alv_grid'
Field catalog Generation:
• Whenever we display the data in the form of ALV report, we need to provide field catalog
information; otherwise the report execution leads to ABORT error. In case of ALV reporting
using classes, we can generate field catalog in 2 ways.

1. Using the function module ‘LVC_FIELDCATALOG_MERGE’:

As part of this F.M call, we need to provide the dictionary structure containing the required
fields (fields provided as part of internal table) , based on this dictionary structure fields SAP
constructs the fieldcatalog internal table and returns which is of type ‘LVC_T_FCAT’.
2. Manually:
Note: In either of the above 2 process, once the fieldcatalog is generated, we need to pass it
as a value to the parameter ‘IT_FIELDCATALOG’ as part of the method call
‘SET_TABLE_FOR_FIRST_DISPLAY’.
Excluding the standard ALV toolbar pushbuttons:
For this, we need to identify the function codes of the ALV toolbar buttons and prepare an
internal table with those function codes and pass the internal table as a value to the parameter
“IT_TOOLBAR_EXCLUDING” of the method “SET_TABLE_FOR_FIRST_DISPLAY” of the class
‘CL_GUI_ALV_GRID’. All the ALV toolbar buttons function codes exist in the form of constant
public attributes with the naming standard ‘MC_FC…’ of the class ‘CL_GUI_ALV_GRID’.

Note: For excluding entire ALV toolbar in the Report, set the field ‘NO_TOOLBAR’ to ‘X’ as part
of Layout.

ALV Column as pushbutton:

For displaying the entire ALV column as pushbutton, set the field ‘STYLE’ as part of field catalog.
All the styles exist in the form of constant attributes with the naming standard ‘MC_STYL’ as
part of the class ‘CL_GUI_ALV_GRID’.
Displaying ALV cells as pushbutton:
Procedure:
Step1:
Take an additional column in the final internal table which is of table type “LVC_T_STYL”.
Step 2:
Before displaying the final data in the ALV grid, loop the final internal table and set the button
style (MC_STYLE_BUTTON) to ALV cells based on the condition.
As part of layout generation, set the field “stylefname” whose value is name of the additional
field which holds the style.

ALV Column Coloring:

For coloring the entire ALV column, set the field ‘EMPHASIZE’ to a color coding as part of field
catalog.
ALV Row Coloring:

Procedure:
Step1:
Take an additional column in the final internal table which is of type char4.
Step 2:
Before displaying the final data in the ALV grid, loop the final internal table and set the color
coding for the additional field based on the condition.
As part of layout generation, set the field “info_fname” whose value is name of the additional
field which holds the row color coding.
ALV Cell Coloring:

Procedure:
Step1:
Take an additional column in the final internal table which is of type ‘LVC_T_SCOL’.
Step 2:
• Before displaying the final data in the ALV grid, loop the final internal table and set the
color coding for the additional field based on the condition.
• For this, we need to prepare work area of type ‘LVC_S_SCOL’ and append the same to the
additional field and update the internal table.
• As part of layout generation, set the field “ctab_fname” whose value is name of the
additional field which holds the cell color coding.
ALV Traffic Light columns:
• Traffic light columns acts as indicators in the ALV reports.
• These traffic lights by default are displayed as First column of the ALV report.
• Traffic light codes are 3 types (1-Red, 2-Yellow, 3-Green) and also we can refer to the corresponding constant
values in the ICON type-group.
Procedure:
Step 1:
Take an additional column in the final internal table which is of type character of “One”.
Step 2:
Before displaying the final data in the ALV GRID, loop the internal table and set the traffic light code for an
additional column based on a condition.
Step 3:
As part of layout, set the field “EXCP_FNAME”, the value of the field should be “Name of the additional column”
containing traffic light code.
Note: By default, Traffic light column is displayed in first column position. To display traffic light in a specific
column position, declare an additional column of type character with some length, generate field catalog for this
column including required column position and assign traffic light code to its column value along with static text.
In this case, we should not set the field ‘EXCP_FNAME’ in layout.
Splitter control:
• It is used for splitting the container in to “N” no of partitions.
• Each partition is called as a “PANE”.
• Each “PANE” should be associated with a container to hold an object. The object can be ALV
Grid, Image and Tree.
Procedure for displaying images in ALV Reporting using classes:
Step 1:
• Upload the picture by using t-code ‘SMW0’.
• In SMW0, choose the radio button ‘binary data for webrfc applications’, click on ‘FIND’
(appl.toolbar) provide package name(any package), object name (any name, unique id)
description(…), click on execute click on ‘create’ button (appl.toolbar),provide object name
(ZBT), description(…), click on ‘import button’ (status bar of dialog box)
Step 2:
• Call the function module “dp_publish_www_url”.
• This function module takes an image object id as input and returns the “URL” of picture
which is of type “cndp_url”.
Note: “cndp_url” is a types declaration declared in the type group “CNDP”.
Step 3:
Create the object of picture class ‘CL_GUI_PICTURE’ linking with a container.
Step 4:
call the instance method “load_picture_from_url” of the class “cl_gui_picture”. This method
takes URL of the picture as input and displays the picture in the container.
Procedure for tree control:
• A tree control is collection of nodes.
• A node can be a folder / it can be an action item.
• We can add the nodes to the tree control by using the instance method “add_nodes” of the
class “cl_gui_simple_tree”.
• This method contains two mandatory parameters.
1. Structure representing the nodes.
2. Internal table containing the nodes information.
Note: “ABDEMONODE” is one of the standard structure given by SAP which represents simple
tree (or) we can create custom dictionary structure by including std.structure ‘TREEV_NODE’
and a character field ‘text’ of any length.
Displaying ALV columns as Dropdown:
Generally we display ALV column as drop down when we have fixed set of values to be
shown to the user as a drop down so that the user can select the value in the runtime.
Procedure:
Step 1:
Take an additional column in the final internal table, this additional column needs to be
displayed as dropdown.
Step 2:
• Generate the field catalog for the additional column.
• As part of the field catalog, set the field “DRDN_HNDL” to some Numeric value and also
set the edit field to ‘X’ as the column should be editable, so that user can choose value
from the drop down in the runtime.
Step 3:
Prepare an internal table of type ‘LVC_T_DROP’ with drop down handle and dropdown
values and pass this internal table as a parameter to the method ‘SET_DROP_DOWN_TABLE’
of the class ‘CL_GUI_ALV_GRID’.
Custom event handling process:
1. Needs to be declared in custom class definition.
2. Event Business logic needs to be implemented as part of custom class implementation(inside
event handler method).
3. Raised in custom class methods.
4. Register the handlers for execution of event handler methods.

Standard Event handling process in ALV Reports using classes:

1. They are declared by SAP itself as part of standard SAP classes.
2. Event Business logic needs to implemented as part of custom class implementation (inside
event handler method).
3. Raised by SAP itself depending on user actions (from. The std. methods).
4. Register the handlers for execution of event handler methods.
Note:

1. To Display ALV column values as link, we need to set the field ‘HOTSPOT’ as part of field
catalog for that particular field.
2. ‘HOTSPOT_CLICK’ is the instance event of the class ‘CL_GUI_ALV_GRID’ which is triggered
by SAP whenever the user clicks on ALV Cell value in the runtime.
3. ‘BUTTON_CLICK’ is the instance event of the class ‘CL_GUI_ALV_GRID’ which is triggered
by SAP whenever the user clicks on ALV Cell displayed as pushbutton
4. ‘DOUBLE_CLICK’ is the instance event of the class ‘CL_GUI_ALV_GRID’ which is triggered by
SAP whenever the user double clicks on ALV Cell value in the runtime.
5. As part of interactive ALV reporting using classes, when the user interacts and navigates
from one screen to another screen, we need to refresh the grid with the corresponding
internal table data using the method ‘REFRESH_TABLE_DISPLAY’ of the class
‘CL_GUI_ALV_GRID’.
TOOLBAR Event:
It is the instance event of the class ‘CL_GUI_ALV_GRID’ which is triggered when the ALV grid
is displayed. This event can be used to manage the ALV Toolbar for Enabling/Disabling
standard ALV Toolbar buttons, Adding custom buttons.

USER_COMMAND Event:
It is the instance event of the class ‘CL_GUI_ALV_GRID’ which is triggered when the user
clicks on custom normal buttons on ALV toolbar. Before this event, SAP Triggers
‘BEFORE_USER_COMMAND’ and then ‘USER_COMMAND’ and after this it triggers
‘AFTER_USER_COMMAND’. These events are also triggered when the user clicks on Menu
items of Menu Buttons of ALV toolbar.

MENU_BUTTON Event:
It is the instance event of the class ‘CL_GUI_ALV_GRID’ which is triggered when the user
clicks on custom MENU buttons on ALV toolbar.
Note:

1. To enable multiple selection of rows on ALV grid, we need to set the field ‘SEL_MODE’ TO ‘A’
as part of layout
2. To identify the selected rows on the ALV grid, we need to use the instance method
‘GET_SELECTED_ROWS’ of the class ‘CL_GUI_ALV_GRID’. This method returns the internal
tables containing the indexes of selected rows.
Editing ALV Cells in runtime and updating to database:
Procedure:
1. For the ALV column to be editable, set the field edit to ‘X’ As part of field catalog
2. Handle the event ‘DATA_CHANGED’ of the class ‘CL_GUI_ALV_GRID’. This event is not triggered by
default as it is not recognized as system event, it requires explicit registration and it is done by calling
the instance method ‘REGISTER_EDIT_EVENT’ of the class ‘CL_GUI_ALV_GRID’. This method takes
event id as a mandatory input parameter. These event ids exist in the form of constant attributes of
the grid class and we can use any of the following attribute event ids.
a) Mc_evt_modified Allows only single cell editing, in this case the event ‘DATA_CHANGED’ is
triggered when the user shifts the focus from the first modified cell or when the user presses enter key in
the first modified cell.
b)Mc_evt_enter -> Allows multi cell editing, in this case the event is triggered when the user
presses enter key in the last modified cell.
3. As part of the event handler method, we need to import the event parameter ‘ER_DATA_CHANGED’
and using this event parameter (object) access the instance attribute (internal table)
‘MT_MODIFIED_CELLS’ which keeps track about the information of the modified cells which includes
row_id and modified value. Based on this, update the grid internal table as well as corresponding
database table.
Tree Control Events:
1. ‘NODE_DOUBLE_CLICK’:
It is the instance event of the class ‘CL_GUI_SIMPLE_TREE’ which is triggered when the user
double clicks on the tree node of the tree control. This event is not triggered by default; it needs
to be registered explicitly by using the instance method ‘SET_REGISTERED_EVENTS’ of the class
‘CL_GUI_SIMPLE_TREE’.

2. ‘NODE_CONTEXT_MENU_REQUEST’:
It is the instance event of the class ‘CL_GUI_SIMPLE_TREE’ which is triggered when the user
right clicks on the tree node of the tree control. This event can be handled to associate the
context menu with the tree node. This event is not triggered by default; it needs to be
registered explicitly by using the instance method ‘SET_REGISTERED_EVENTS’ of the class
‘CL_GUI_SIMPLE_TREE’.
3. ‘NODE_KEYPRESS’:
• It is the instance event of the class ‘CL_GUI_SIMPLE_TREE’ which is triggered when the user
presses a key on the tree node of the tree control. For this, we need to register the keys for
triggering this event. The keys can be registered by calling the method ‘ADD_KEY_STROKE’ of
the class ‘CL_GUI_SIMPLE_TREE’.
• All the keys exist in the form of constant attributes with the naming standard ‘KEY_....’ of the
class ‘CL_GUI_SIMPLE_TREE’. This event is not triggered by default; it needs to be registered
explicitly by using the instance method ‘SET_REGISTERED_EVENTS’ of the class
‘CL_GUI_SIMPLE_TREE’.

4. ‘NODE_CONTEXT_MENU_SELECT’:
It is the instance event of the class ‘CL_GUI_SIMPLE_TREE’ which is triggered when the user
selects a context menu item from the context menu of the node.

Note: For the method ‘SET_REGISTERED_EVENTS’, we need to pass event id as a parameter. All
the event ids exist in the form of constant attributes with the naming standard ‘EVENTID_.....’ of
the class ‘CL_GUI_SIMPLE_TREE’.
Generating TOP OF PAGE content for ALV Grid:
For this, we need to handle the event ‘TOP_OF_PAGE’. It is the instance event of the class
‘CL_GUI_ALV_GRID’ used for generating content in the TOP OF PAGE area of ALV Grid. This
event is not triggered by default; it should be registered explicitly by calling the instance
method ‘LIST_PROCESSING_EVENTS’ of the class ‘CL_GUI_ALV_GRID’.

Layout Variant notes:

• SAP users want to configure ALV grid layout settings and change the standard ABAP report
according to their requirements.
• SAP users want to customize the ALV layout and create custom layouts for own use or for
global use.
• For an ABAP developer this means enabling SAP system users to create User or Global
layout variants for the ALV grid display.
Continue....
• If the ABAP programmer is using method set_table_for_first_display of cl_gui_alv_grid type
ALV grid object, then it is very easy to let SAP users create own layout variants and manage
layout variants.
• To manage this task, ABAP developers can use is_variant and i_save export parameters of
the set_table_for_first_display method call.
• i_save parameter has 4 possible values.
• U: An i_save parameter value "U" means that the user can only save user-specific layouts.
• X: An i_save parameter value "X" means that the users are enabled to save only global
layouts. So other users can also use these global layouts too.
• A: An i_save parameter value "A" means that the SAP user can save both user specific and
global layouts.
• Space: An empty or space i_save parameter value which is default for i_save means users
cannot save own layouts either global or user specific layout.
Introduction:
• The CL_SALV_TABLE class is part of the ALV Object Model which was introduced in
NetWeaver 2004. Basically it is an encapsulation of the pre-existing ALV tools. For example
the class CL_SALV_TABLE actually wraps around the CL_GUI_ALV_GRID class for container
implementation, as well as the REUSE_ALV_GRID_DISPLAY and REUSE_ALV_LIST_DISPLAY
function modules for full screen display.
• It was designed to be a single point of entry when using a specific ALV tool such as the ALV
table display, ALV hierarchical sequential list, and tree ALV. All of these individual ALV tools
have their own base class, for table it is the CL_SALV_TABLE, but all have a common look. A
lot of the methods are the same, with only some differences in the parameters of the
methods depending on the actual tool you are using.
• So to summarize, the ALV Object Model was delivered to give a more collective interface to
the ALV tools. There are limitations in the ALV Object Model, for example, you can NOT
color a line or a cell, but you can color a column. Also, you can NOT have an editable ALV
using the Object Model.
• But for basic lists, it is a very powerful tool.
Following are the restrictions with CL_SALV_TABLE (ALV
Object Model):
• The number of columns is restricted to 90.
• The output length of a column is restricted to 128 characters.
• For sorting and subtotals, you use a total of nine levels or columns.
• For columns that can be aggregated, note that the internal length of the column is
large enough for both single values and the result.
• The output is column-oriented. You are only able to display flat, structured tables.
You are not able to display nested tables.
• Tables displayed with ALV are not ready for input.
• If you insert the table as grid in container, you are not able to use batch mode
(background).

Event handling in ALV Object Model:

For this, we need to handle the events defined in the class ‘CL_SALV_EVENTS_TABLE’.
ALV Reporting using Function Modules:

Function Modules used for display:

a.REUSE_ALV_LIST_DISPLAY
b.REUSE_ALV_GRID_DISPLAY

Procedure for ALV reporting using function modules:

1.Declaration
2.Retrieve data
3.Field catalogue generation
4.Display
• As part of the function module “REUSE_ALV_GRID_DISPLAY” there is only one mandatory
parameter ‘T_OUTTAB’. This parameter holds the internal table containing data.
• If we pass only this parameter, it leads to “Abort Error”. The reason for this error is we must
specify the “field catalog “information.
This information can be specified in two ways.
i. By specifying the dictionary structure name.
ii. By specifying the field catalog directly.

Field catalogue:
It is an object which contains the information’s of the fields display in the “ALV Grid”. This
information includes name of the field, position, label, grid, appearance etc.
Note:
1. To specify the field catalogue information using the dictionary structure we need to use the
importing parameter “I_STRUCTURE_NAME” as part of the function module
“REUSE_ALV_GRID_DISPLAY”. Whenever this parameter is specified all the properties of the
field are taken from dictionary itself.
2. The structure name passed must match with the format of internal table i.e. the no of
fields and sequence of fields in the structure and in the internal table must match
otherwise it leads to runtime error.

GENERATING FIELD CATALOGUE:

1. Using std. F.M ‘REUSE_ALV_FIELDCATALOG_MERGE’

This function module takes the dictionary structure as input, generates the field catalogue
based on structure fields and returns the field catalogue which is of type internal table
“SLIS_T_FIELDCAT_ALV”.
Note:
It is recommended to generate the Field catalog manually, as we have better flexibility and
control of the fields. For this, we need to prepare work area for each field and append the
same to the internal table of type “SLIS_T_FIELDCAT_ALV”.

INTERACTIVE ALV REPORTING:

• This is generated based on the user interaction in the runtime.
• To handle events in ALV reports developed using function module we need to consider the
parameter ‘IT_EVENTS’ as part of the F.M “REUSE_ALV_GRID_DISPLAY”.
• This parameter is an internal table of type “SLIS_T_EVENT”.
• This internal table holds the events information (refer to the document of the parameter
‘IT_EVENTS’ to get the events list).
• This internal table is associated with two fields.
1. Name
2. Form
• Name holds the name of the event.
• Form holds the name of the user defined subroutine.
• As part of this subroutine definition, we need to implement the business logic related to the
event.
• This subroutine will be called by SAP whenever event is Triggered.
• By reading the documentation of the parameter “IT_EVENTS” we can understand what
events are supported in ALV using F.M’s.

USER_COMMAND:
• This event is triggered when the user double clicks on ALV cell value (or) single click on
hotspot cell value.
• This event contains two parameters.
i. Parameter of type – sy-ucomm.
ii. Parameter of type slis_selfield.
Note:
• To handle the events we need to specify the parameter “I_CALLBACK_PROGRAM” as part of
F.M ‘REUSE_ALV_GRID_DISPLAY’ so that whenever the event is triggered SAP will search for
the corresponding event subroutine definition in the specified calling program.
• “REUSE_ALV_COMMENTARY_WRITE” is a function module used for associating text and Logo
to the TOP OF PAGE Area of ALV report developed using F.M. This F.M should be called as
part of user defined subroutine definition associated with the event ‘TOP_OF_PAGE’.

Displaying “LOGO in ALV report using function module:

Upload the logo using the Transaction code “OAER” .
Step 1:
GOTO-> SE93->Enter Transaction-> OAER
Step 2:
In OAER Transaction -> enter the values in following below.
Class name -> pictures.
Class type -> OT.
Object key-> object name (any unique id).
And execute.
Step 3:
In the next screen , in the top pane, choose ‘pictures’, and in bottom pane, ->doctype->expand
->standard doc types->double click on ‘screen’ entry
->choose filename (logo file) from local drive->continue.

Blocked ALV:
• It is used for displaying the data in the form of blocks.
• As part of this we use following function modules.
• REUSE_ALV_BLOCK_LIST_INIT
• REUSE_ALV_BLOCK_LIST_APPEND
• REUSE_ALV_BLOCK_LIST_DISPLAY
Procedure:
Step 1:
Initialize the ALV blocked list using the function module REUSE_ALV_BLOCK_LIST_INIT
Step 2:
Generate the field catalog for the block.
Step 3:
• Retrieve the data for the block.
• Append the field catalog and the data to the blocked list using the function module
REUSE_ALV_BLOCK_LIST_APPEND.
Note:
Repeat the steps 2, 3 for each of the block.
Step 4:
Display the ALV blocked list using the function module REUSE_ALV_BLOCK_LIST_DISPLAY.
Note:
REUSE_ALV_EVENTS_GET is the function module which returns list of events supported in ALV
function modules.
Exception Handling:
• An exception is a runtime error which is raised during the program execution.
• If the exception is not handled, the program execution will be terminated.
• Exception handling is a process of handling the Runtime Error’s and continuing the program
execution without termination.
• The exceptions which are raised by SAP are called as Standard Exceptions.
• These standard exceptions are raised from standard exception classes which start with
Naming convention “CX___”.
• We can handle these exceptions by using “TRY” and “CATCH” blocks.
• Inside the “TRY” Block we need to keep those statements where the possible exceptions
might be raised.
• The ‘CATCH’ block is placed immediately after the Try Block; it is responsible for handling the
exceptions by providing appropriate exception handling statements which can be system
defined exception message / user-defined exception message.
• “CX_ROOT” is common for any exceptions i.e it is a super class for all exception classes.
• As part of the catch block we need to provide the exception class name which is responsible
for raising the exception.
• If we are not sure about the exception class, we can give the exception class name as
“CX_ROOT”.
• “CX_ROOT” is super class for all the exception classes..

Note:
• Whenever an exception is raised in a “TRY” block, SAP creates the object of the exception
class which is raising the exception and the control will jump to catch block.
• As part of catch block, we need to receive the exception class object into our local reference
of exception class and using this referenced object we can access the appropriate methods
of Exception class to capture standard exception messages.
• Whenever an exception is raised in try block, SAP ignores the rest of the statements in the
try block and the control will jump to catch block.

Standard Exceptions:
Declared, Raised By SAP
Handling Developer (using try and catch block)
Cleanup block:
• Cleanup block is provided as part of try block to execute certain statements mandatorily
whenever an exception is raised in the try block.
• In general, whenever an exception is raised in the try block, the control jumps to catch
block ignoring the rest of the statements in the try block.
• In these cases, there might be certain statements which we need to execute whenever an
exception is raised, these statements we can provide as part of cleanup block.
• If a try block contains cleanup block, we cannot have catch block, so in order to handle the
exception, catch block should be provided as part of outer try block.
• As part of cleanup block, we can perform cleanup activities. i.e clearing the variables, free
internal tables, close the files…….
• We should not abruptly terminate the execution of cleanup block using the statements
stop, submit and call transaction statements.
User-defined exceptions in local class methods:
These exceptions are declared, raised and handled by developer.

Procedure:
1. Declare the exception in the method declaration by using “exceptions” keyword
Syntax: exceptions <exception name>.

2. Raise the exception in the method implementation at the appropriate place.

Syntax: raise <exception name>.

3. Handle the exception while calling the method by checking the sy-subrc status.

Note: We can use ‘raise’ keyword to raise any exceptions i.e system defined or user-defined.
Raising keyword:
• Raising is a keyword used as part of local class method declaration to indicate that a method
might raise the exception but cannot handle the exception.
• In these cases, the caller of the method should take the responsibility of handling the
exception.
• The advantage of this approach is since a method can be called any no. of times at different
places in the object, at each place, we can handle the same exception in different way
(custom defined exception messages in one place, std.exception messages in another place..)

Custom Exception classes:

We create custom exception classes to store the repository of custom exception messages
Global custom exception classes starts with ‘ZCX_....’ / ‘YCX_....’ and it must be subclass of
‘CX_STATIC_CHECK’ / ‘CX_DYNAMIC_CHECK’ / ‘CX_NO_CHECK’.
These exception classes can be created by referring to
1. OTR (Online text repository) /
2. Message class
• Global Exception classes are associated with ‘Texts’ tab.
• As part of ‘Texts’ tab we need to create exception id’s.
• Whenever exception id is created, SAP creates corresponding constant attribute with the same
name. This attribute needs to be accessed while raising the exception from these exception
classes.
• Each Exception id must be associated either with OTR Text / with message of a message class.
• In case of Exception classes using OTR, each exception id that we create must be associated
with short text / long text / both.
• In case of Exception classes using message class, each exception id that we create must be
associated with message id of a message class which can be static / dynamic message.
• In case of Dynamic message, we need to create corresponding attributes for mapping to the
place holder of dynamic message.
• The values for these attributes associated with placeholders should be passed at the time of
raising the exception.
Note: A Try block can be associated with ‘n’ of catch blocks, but the catch block exception classes
should be in the ascending order of exception classes i.e from sub class to super classes.
Persistence service:
• It is used for storing the state of object (CURRENT values of the object) permanently in the
database.
• By default, the life time of the object is local to the program i.e. once a program execution is
completed, memory allocated for the object will be destroyed by the garbage collector.
• Persistence object means -> permanent object
• Any database operation (CRUD operations) can be achieved by using “persistent service”.
• Persistence service is implemented by creating persistence classes.
• Persistence class is always created globally (class builder).
• The naming standard of persistent class is ‘ZCL_<classname> ‘ / ’YCL_<classname>’.
• Persistence class is always created as protected class.
• Whenever a persistence class is created, SAP creates two more classes internally.
a. Base agent class: (abstract class) i.e. ‘ZCB_<class name>’.
b. Actor /agent class: (Private class) i.e. “ZCA_<class name>”.
Base agent class:
It is a friend of persistence class and it is super class of ACTOR / AGENT class.
Actor class:
It is a subclass of Base agent class.

By Default, Persistence class implements a standard interface ‘IF_OS_STATE’ which is

responsible for storing the state of the object permanently in the database.

Persistence service can be implemented in two ways:

1. Business key identity.
2. GUID (Global Unique Identifier).

Persistence service using business key identity:

• In this, we need to consider a database table in which the primary key field/s of the table is
considered as “Business key identity”.
• This field is used for uniquely identifying the object.
Procedure for using persistence service using Business key :

1. Consider a db table
Table: z1130emp
Fields:
Empno (PK) zempno int4 10
Ename zename char 20
Empdesig zempdesig char 20

2. Create the persistence class.

Persistence class: zcl_1130_persistence_key
Base agent class: zcb_1130_persistence_key
Actor/agent class: zca_1130_persistence_key

Note: By default, Persistence class implements the interface ‘if_os_state’ which is responsible
for storing the state of the object permanently.
3. Map the Persistence class with the Corresponding data base table. (‘goto’ menu persistence
representation)
Note: We must map all the fields of the db table to the persistence class (double click on each
field and click on ‘set attribute values’ button)
Note: Once the mapping is done, all the fields of the table will be added as attributes of the
persistence class.
• Apart from this, SAP GENERATES “GET_” Methods for all attributes and “SET_” methods for
non-primary key fields.
• Getter method is used for reading the value of the attribute and Setter method is used for
setting the value to the attribute.
4. Activate the persistence class so that dependent classes also get activated.
5. As part of this activation, SAP generates the following methods as part of base agent class.
i. Create _Persistent
ii. Delete_Persistent.
iii. Get_Persistent
To interact with the Persistent object we need to access above 3 methods:

• To access the above 3 instance Methods we require object of base agent class, but the base
agent class is created as “Abstract class”. So, it cannot be instantiated directly.
• The above 3 methods are public and they are inherited to sub class which is Actor Class or
Agent class.
• But, Actor class IS created as “Private Class”, so, it cannot be instantiated directly outside.
• Actor class is created as Singleton class, so there is a possibility of creating one and only one
object. So in order to get the object of the Actor class we must follow the following
Procedure.
• As part of every Actor class, SAP Provides Static Public Attribute “Agent”. This attribute is
marked as ‘Read only’ i.e this attribute will return a value whenever it is accessed.
• Whenever this attribute is accessed by using Actor class name , internally SAP Executes Static
Constructor of Actor class which is Responsible for creating singleton (single object) of actor
class, This object will be returned back to the static attribute agent, we need to receive this
returned object so that we can access the above 3 methods.
• “COMMIT WORK” statement will save changes permanently in the database.
Persistence Service Using GUID (global unique identifier):

• In this we need to consider a database table whose first field is GUID and the corresponding
data element should be “OS_GUID”. The value for this field “GUID” will be dynamically
generated by SAP itself.
• We need to map the persistence class with this database table. After Mapping, except
“GUID” field all the remaining fields will be added as attributes of the class.
• Apart from this, SAP Generates “Getter” &”Setter” methods as part of persistence class for
all the fields except “GUID”.
• When we activate the persistence class, SAP generates the following 3 Methods as part of
“BASE AGENT CLASS”.
1. Create_Persistent.
2. IF_OS_CA_PERSISTENCY~GET_PERSISTENT_BY_OID
3. IF_OS_FACTORY~DELETE_PERSISTENT.
Procedure for creating Persistence service using GUID:
Step 1: Consider a database table with GUID as first field.
Table: y745emp
Fields: Data element
GUID os_guid (Primary Key)
EMPNO zeMPno
ENAME zename
EMPDESIG zempdesig
Step 2: Create the persistence class( ycl_815emp)
Base agent class ycb_815emp
Actor class yca_815emp
Step 3: Map the persistence class with the above table.
In persistence service using GUID the uniqueness of the object is controlled based on the GUID
field.
GET_PERSISTENT_BY_OID:
This method takes GUID as input and returns the object of the object class. This object class in
the runtime points to persistence class, so we need to type cast the object class object to
persistence class object. Using the persistence class object access the required getter methods.
DELETE_PERSISTENT:

• This method takes the object of the interface ‘if_os_state’ as input value, but we cannot
directly create objects for interfaces, so we need to analyze what is the implementation
class which is implementing this particular interface.
• As per the analysis, it is the persistence class (ycl_emp) which is implementing the
interface ‘if_os_state’, so we can pass the object of this persistence class as a parameter
value. In order to get the object of persistence class, first of all we have to check
whether the “GUID” is existing or not this is done by calling the instance method
“Get_Persistence_By_Oid” .This method returns object of the object class, this object
class object needs to be type cast to persistence class object and pass that object as
parameter to “Delete_Persistent”.
TRANSACTION SERVICE :

• It is used for managing OO transactions.

• The main use of this is, we can mark the begin of and end of OO transaction, so that we can
either save (commit) the complete transaction or cancel (rollback) the complete transaction.
• As part of this transaction service, we use the following class and interfaces.
1. cl_os_system --> class
2. if_os_transaction (check the documentation)
3. if_os_transaction_manager

Persistence class--> zcl_815emp

actor/agent class --> zca_815emp
base agent class --> zcb_815emp.
Procedure for using Transaction service:
1. Get the transaction manager object: This is done by calling the static method
'get_transaction_manager' of the class 'cl_os_system'
2. Using the above transaction manager object, get the transaction object. This is done by calling
the instance method 'create_transaction' of the interface 'if_os_transaction_manager'
3. Using the above transaction object, mark the start of OO Transaction. This is done by calling
the 'start' method of the interface 'if_os_transaction'
4. Perform the Operation (Create / Delete / Update persistent object)
5. Try to end the transaction by calling the instance method 'end' of the interface
'if_os_transaction'. If the transaction fails, cancel the transaction by calling the method 'undo'
of the interface 'if_os_transaction.
RTTS(Runtime Type Services):
• We can create dynamic internal table and dynamic workarea.
• It consists of two components:
1. Runtime Type Identification(RTTI)
2. Runtime Type Creation(RTTC)

Runtime Type Identification(RTTI):

It provides the methods to get the type defintion of data objects at runtime.

Runtime Type Creation(RTTC):

• It provides the methods to create the data objects at runtime with any type defintion.
• Basically ABAP RTTS provides a set of classes, whose methods can be used for runtime type
identification and runtime creation.
Narrow Casting & Widening Casting:
1. Narrow Casting:
If we want to access child class method from a parent class object is called narrow casting.

Syntax:
obj1 = obj2
call method obj1->(‘Adding’)
//Adding method is belong obj2

2. Widening Casting:
If we want to access parent class method from an child class object is called widening casting.

Syntax:
obj2 = obj1
call method obj2->Get Data
// Get data method is belong obj1
 Thank You
Created By - Sanjaya Kunar
Follow Me - http://www.linkedin.com/in/sanjaya-kunar-aa9351254
Any Queries?
Connect - kanhasanjayk@gmail.com