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

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 ---> 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 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

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: 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.

Types Attributes

In Local classes, they are declared by using the keyword ‘Types’. Types attribute
declaration only provides template, but doesn’t allocated any memory. To make use of
Types attributes, we need to create references based on types attribute declaration. These
references can be either a normal data attribute / internal table / work area.

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: 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.

- 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 explicitly in the executable program. This is mandatory
before the release 6.20 for accessing static components of the global class 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, then we can load the global
class explicitly from the class library by using load keyword.

Constructor:

- It is special method used for initializing the attributes of the class i.e. 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 case.

- 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.

INHERITANCE
It is a process of using the properties (com ponents) of one class inside other class.

The main aim of Inheritance is Reusability of the components i.e. a component declared in
one class can be accessed by 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 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.

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 refer to 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, 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 and from sub
class instance constructor implementation we need to call super class instance constructor
by passing same values for parameters of super class instance constructor.

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.

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 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.

Friend keyword:

In local classes “Friend” is a keyword used as part of class definition to consider another
class as friend.

In this case friend class should be forward declared by using “Deferred” keyword. This
deferred keyword indicates that the class is defined somewhere else in the program and
not at the beginning of the program.

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.

- 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.

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.

- 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.

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.

ALV (ABAP / ADVANCED LIST VIEWER): is a report

Classical Reporting Procedure:

1. Generate the Selection screen for reading user input (Parameters / select- options)

2. Validate the User Input

3. Retrieve the data from database table/s into internal tables/work areas using Select
Query

4. Process the Retrieved data (sort/modify/append/delete...)

5. Display the processed data on L.P.S

ALV Reports can be developed in 3 ways

1. ALV Reporting using F.M's

2. ALV Reporting using Classes (Recommended)

3. ALV Object Model

ALV Reporting using Function Modules:

As part of this, we use following F.M’s 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 value as part of F.M call, it leads to “Abort Error-
Field Catalog Not Found”. 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. 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.

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 using standard Function Module

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 and 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.

1) Reuse_alv_block_list_init.

2) Reuse_alv_block_list_append.

3) 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.

Hierarchical ALV:

It is used for displaying the report in the form of header and items.

As part of this we can use following function module

“REUSE_ALV_HIERSEQ_LIST_DISPLAY”.

Mandatory Importing parameters

I_TABNAME_HEADER

I_TABNAME_ITEM

IS_KEYINFO

Setting variants:

Variants keeps track of the changes made to the alv layout in the runtime.

To choose the appropriate variant in the runtime we can use the function module
“reuse_alv_variant_f4”.

To get the default variant we can use the function module “reuse_alv_variant_default_get”.

To save the state of the layout in the runtime we need to set the following parameters.

a) I_save and

b) Is_variants  as part of the function module “reuse_alv_grid_display”.

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”.
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’.

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.

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’.

ALV Traffic Light columns:

- Traffic light 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 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, loop the internal table and set the traffic light code for
an additional column.

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. In this case, we should not set
the field ‘EXCP_FNAME’ in layout.
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: 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: 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: 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 a 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
‘MC_EVT_MODIFIED’ 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’: 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’: 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’: 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’: 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’.

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 “style_fname” whose value is name of the
additional field which holds the style.

Exception Handling in Methods

- An exception is a runtime error which is raised during the program execution.

- If the exception is not handled, the program will be terminated.

- Exception handling is a process of handling the Runtime Error’s and continues 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 occur.
- 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 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 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 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.

Singleton class:

It is a class for which only one object can be created. It uses Singleton Design pattern.

Persistence service

It is used for storing the state of object (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.

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: is a friend of persistence class and it is super class of ACTOR class.

Actor class: is a subclass of Base agent class

By Default, Persistence class implements a std. 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 identify.

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 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: z730emp

Fields:

Empno (PK) zempno int4 10

Ename zename char 20

Empdesig zempdesig char 15

2. Create the persistence class.

Persistence class: zcl_emp_pers

Base agent class: zcb_emp_pers

Actor/agent class: zca_emp_pers

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
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.

1. Create _Persistent

2. Delete_Persistent.

3. 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
persistence 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:

Step1: consider a database table with GUID as first field.

Table: Z8AMEMP

Fields:

GUID (PK) os_guid

EMPNO zeMPno

ENAME zename

EMPDESIG zempdesig

Step2: create the persistence class( zcl_8amemp)

 Base agent class  zcb_8amemp

Actor class zca_8amemp

Step3: 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 (zcl_9am_empl) 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 ---> used for managing OO transactions

The main use of this service 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

3. if_os_transaction_manager

Persistence class--> zcl_emp_pers

actor/agent class --> zca_emp_pers

base agent class --> zcb_emp_pers

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.

Note: The above steps are provided by SAP as part of interface documentation
‘IF_OS_TRANSACTION’.