Abap Notes PDF

ABAP Notes
Table of Contents
1 SAP Portfolio......................................................................................................................................... 3
2 SAP architecture ................................................................................................................................... 7
3 Communication and Integration.......................................................................................................... 19
4 Program Flow ..................................................................................................................................... 30
5 ABAP Workbench................................................................................................................................ 37
6 ABAP DATA TYPES ............................................................................................................................... 60
7 MODULARIZATION .............................................................................................................................. 78
7.1 SAP- ABAP Macro ........................................................................................................................ 78
7.2 Include Programs ........................................................................................................................ 79
7.3 Subroutines ................................................................................................................................. 79
7.4 Function Modules ....................................................................................................................... 80
7.5 Function Groups .......................................................................................................................... 81
8 Object Oriented Programming .......................................................................................................... 103
9 COMPLEX DATA OBJECTS .................................................................................................................. 118
10 Internal Tables .............................................................................................................................. 128
10.1.1 Reading contents of internal table: .................................................................................... 129
10.1.2 Reading multiple lines in Internal table. ............................................................................. 130
10.1.3 Modifying contents of internal table : ................................................................................ 130
10.2 Deleting contents of internal table: ........................................................................................... 131
10.3 Append command: .................................................................................................................... 131
10.4 Insert command: ....................................................................................................................... 131
10.5 Collect command: ..................................................................................................................... 132
11 DATA MODELING .......................................................................................................................... 140
12 ABAP Events.................................................................................................................................. 164
13 NEW TEST TOOLS .......................................................................................................................... 166
14 DYNAMIC DATA OBJECTS .............................................................................................................. 181
15 ABAP Open SQL............................................................................................................................. 184
16 ABAP Dictionary ............................................................................................................................ 195
16.1 INTRODUCTION TO THE DICTIONARY......................................................................................... 195
16.2 DATA OBJECTS IN ABAP DICTIONARY ......................................................................................... 197
17 INPUT CHECKS............................................................................................................................... 220
18 OBJECT DEPENDENCIES ................................................................................................................. 226
19 views and maintenance dialog ...................................................................................................... 238
20 Subscreens .................................................................................................................................... 328
21 INTRODUCTION TO OBJECT-ORIENTED PROGRAMMING ............................................................... 342
22 ALV Grid Control ........................................................................................................................... 407
Page 2 of 580 Pages

1 SAP Portfolio
Orchestration Layer ensures that all software and components fit perfectly in customer landscape. This
includes life cycle management, mdm and process orchestration.
Goal of investment:
 Reduce cost of ownership
 Ensure data consistency
 Process management across multiple layers of applications
On demand is synonymous with by design
Page 3 of 580 Pages

SAP Business One
 Comprehensive ERP application with interface similar to windows
 Suited for small or midsize companies (100 employees)
 Caters for core functionality
 Best Fit for companies that have outgrown packaged accounting only software and need to
replace multiple non integrated solutions
SAP Business By Design

 Aimed at mid market, 100 to 500 employees
 Integrated end to end application
 On demand solution – therefore lower entry costs
 Also supports regional and local legal requirements
 Customisable ui based on roles
 Best fit for companies that need to replace point to point solutions, manual processing using
spreadsheets
SAP Business All in One

 CRM + ERP + applications from Business Objects portfolio
 All in one – vertical solution (solutions that are industry specific or country specific)
 Pre configured business scenarios and implementation accelerators
 Up to 2500 employees
 On premise or hosted by parent
 Not on demand
 Best Fit for companies that have outgrown packaged accounting only software and need to
replace multiple non integrated solutions
 Best Fit for companies that have solutions that may not meet industry specific requirements or
lack of cross border functionality
 Best Fit for companies that have increased business process complexity
EIM – enterprise information management, it is the business activity of creating, cleansing, integrating,
managing, governing and archiving the structured and unstructured data used by an organisation.
 Portal – nw java stack

 Pi – java stack
 Solman – dual stack
Page 4 of 580 Pages

The beta shipment phase occurs before the restricted shipment phase (or the release-to-customer date),
mostly for testing purposes.
The restricted shipment phase is flagged off by the release to customer date. The new software release is
subjected to the standardized ramp-up process, during this phase. This is to introduce new products in the
market. Hence, only a limited number of customers have access to the software. A ramp-up usually takes
about 6 months.
The unrestricted shipment phase begins after the SAP ramp-up program is successfully concluded. This
phase is flagged off by the default release date. The Default Release is the available version of the SAP
software.
Page 5 of 580 Pages

The three phases of maintenance are mainstream maintenance, extended maintenance, and customer-
specific maintenance.
Mainstream maintenance starts from the release to customer date and generally ends after 7 years (that
is, after covering the restricted and unrestricted shipment phases).
Extended maintenance kicks in when customers extend the support period (in which corrections or legal
changes are taken into account) for an increased maintenance fee. The scope of support remains the same
as mainstream maintenance.
Customer-specific maintenance starts after the extended maintenance or mainstream maintenance period
ends. All releases enter this phase automatically. During this phase, customers receive support services
similar to those offered in the mainstream maintenance phase but with some restrictions. No support
packaged but customers specific enhancements released. Customers are charged for this.
Netweaver business client – uniform look and feel
Page 6 of 580 Pages

2 SAP architecture
An instance combines SAP system components providing one or more services. These services can be
started or stopped simultaneously. You can install and operate the database for an SAP system on a
physical computer, separately from the instances of the SAP system.
The central instance of the SAP system offers services that no other instance of the system offers.
Examples of central instance services are the Message Server and the Enqueue work process for AS ABAP
and the Software Deployment Manager (SDM) for AS Java.
The central services instance provides the central services of the AS Java, the Message Service, and the
Enqueue Service.
Dialog instances constitute the other instances of the system.
If the same computer constitutes both the central instance and the database, it becomes a central system.
Lock = Enqueue
Page 7 of 580 Pages

AS ABAP PROCESSES
On every application server, a number of parallel work processes are possible in the runtime environment
for ABAP.
Requests to run the work processes are distributed by the dispatcher.
Requests for the execution of dialog steps are handled by dialog work processes. Each dispatcher must
handle at least two dialog work processes.
Spool work processes pass on the sequential data flows to printers.
Each SAP system should have at least one spool work process.
Requests to execute updates are handled by update work processes. At least one update work process is
required for each SAP system.
Background work processes execute programs that run without interacting with the user. Every SAP system
needs at least two background work processes.
The enqueue work process administers the lock table in the shared memory.
Only one enqueue work process is needed for each system.
Apart from these work processes, the AS ABAP provides additional services (these are not work processes)
for internal and external communication:
The Message Server (MS) handles communication between the distributed dispatchers. The message
server is configured only once per SAP system.
Communication between multiple SAP systems, or between SAP systems and external application systems,
is possible through the Gateway reader (GW). You only need one Gateway reader for every dispatcher.
The Internet Communication Manager (ICM) is used for communicating with the SAP system using web
protocols such as HTTP. It receives requests from the client and forwards them to the SAP system for
processing. You can configure a maximum of one ICM process per application server.
 Dialog – min 2 per disp
 Update - > 1
 Lock management – only 1
 Background = > 1, during transport 2
 Spool = >1
Page 8 of 580 Pages

AS JAVA PROCESSES
Various processes exist in AS Java:

The server processes receive incoming requests through the dispatcher.
Every dispatcher handles 1 to 16 server processes.
The server process executes the Java applications.
A list of Java dispatchers and server processes is managed by the Java Message Service (MS), which
communicates within the Java runtime environment.
Logical locks set (by the executed Java application program) in a server process fall under the purview of
the Java Enqueue Service.
You can install Java software components on the SAP Web AS Java using the Software Deployment
Manager (SDM).
Sdm resides on java central instance
Page 9 of 580 Pages

AS ABAP+JAVA ARCHITECTURE
In AS ABAP+Java, the central instance can be recognized by processes like ABAP MS, enqueue work process,
and SDM. The Java central services instance provides the central services of the Java runtime environment
(Java MS and Java ES). Dialog instances refer to all other instances.
The Internet Communication Manager decides whether the request should be forwarded to the ABAP or
the Java runtime environment. Depending on the URL the ICM forwards the request to the respective
dispatchers. The work processes respond to the requests accordingly. The ABAP and Java runtime
environments communicate with each other using SAP Java Connector (JCo).
PROCESSING A USER REQUEST
The processing of a user request in AS ABAP involves the presentation layer, the application layer, and the
database layer. The screen entries of a user are accepted by the SAP GUI and are forwarded to AS ABAP.
The ABAP dispatcher distributes the requests one by one to the available work processes for processing of
data. You must read data from the ABAP schema of the database or write to it, to process user requests.
Page 10 of 580 Pages

The ABAP schema of the database has direct links with every work process. Once the process is complete,
the dispatcher sends back the end result of the work process to the SAP GUI.
The buffers help to speed up the processing of user requests by reducing the number of database hits for
data processing. Each instance has its own buffers.
PROCESS FLOW FOR REQUEST
Work processes:
 Abap interpreter
 Dynpro interpreter – screen flow logic
 Screen processor – informs abap about sub program that needs to be executed
 Database interface
 Task handler
 Internal memory
Application programs include process logic, which is executed by work processes.

A work process includes
 internal memory
 a task handler that coordinates the actions within a work process
 software processors; and
 a database interface.
The database interface translates the OPEN SQL statements from ABAP into the corresponding SQL
statements for the specific database used (Native SQL). The ABAP interpreter executes the actual
processing logic of ABAP application programs. The screen processor tells the ABAP processor which
subprogram to execute, depending on the processing status of the screen flow logic.
The dialog work process is selected by the dispatcher. It involves a roll-in of the user context first. The work
process then processes the user request. This may be a request for data from the database or from the
buffers in the shared memory. The dialog work process processes the dialog step, after which the work
process rolls out the user context back to the shared memory. The user sees the result after it has been
transferred to the SAP GUI on the new screen.
DATABASE QUERY FLOW
In ABAP, you can access the application data in the database using ABAP Open SQL (or Structured Query
Language, which is a database query language), regardless of the Relational Database Management System
(RDBMS) used. The database interface that interprets the OPEN SQL into Native SQL thus allows the
programs to be database-independent. The buffer stores data that are frequently needed. Thus the system
is spared the trouble of retrieving this data from the database. Furthermore, native SQL commands used
directly in ABAP can fetch data. This eliminates the need for local buffers or interpretation of commands by
a database interface.
PROCESSING DIALOG REQUEST
A program with individual dialog steps may consist of several screens.

Each dialog step in a program is assigned to one specific dialog work process.
A dialog work process sequentially processes the dialog steps for various users and programs. Work
process multiplexing uses different dialog work processes during program runtime.

DIALOG WORK PROCESS MULTIPLEXING
Process Before Output or PBO refers to the processing before the screen image is sent. Process After Input
or PAI refers to the processing after a user interaction on the screen. The PAI part of a dialog step logically
belongs to the preceding screen image; whereas the PBO part logically belongs to the subsequent screen
image.
PRINCIPAL CHARACTERISTIC: TRANSACTION
Transactions are processing units grouped to provide specific modules.

The four principal characteristics of transactions can be summed up in the acronym ACID:
Atomic
Consistent
Isolated
Durable
An atomic transaction either succeeds fully or does not have any effects at all. This ensures that
inconsistent, partial results are not stored.
A consistent transaction is one in which the system status always reflects one that is accurate and
consistent in business terms and will not change otherwise.
Changes made within a transaction are isolated, as they cannot be seen by any other transaction, unless
the confirmation Commit is executed.

The results of a transaction are durable because after the final confirmation they are stored permanently in
the database.
RELATIONSHIP BETWEEN DATABASE TRANSACTION AND SAP TRANSACTIONS
SAP transactions need not be executed within one single dialog work process. For requests that change
data on the database, database transactions are initiated. Applications whose dialog steps are sequentially
executed by the same work process cannot run within the same database transaction if they are not related
to each other. Therefore, a work process must start a new database transaction for each dialog step.
LOCK MANAGEMENT IN AS ABAP
The SAP lock principle is that SAP programs should make lock entries in a lock table. The lock table is
located in the main memory of the instance with the enqueue work process. If a user wants to change the
access to data, the executing dialog work process requests a lock. A dialog request processed on the
enqueue server results in a dialog work process that can access the lock table directly; else, the work
processes communicate through the MS.
The application developer can choose between different lock modes, such as at most read
access and change access.
The application developer can choose between various lock modes.
Write locks – in the lock mode Exclusive – can be edited only by one user. Any read / write locks are
rejected
Read locks – in the lock mode Shared – allows concurrent read access to the locked data for several
users. Write is rejected
Enhanced write locks – in the lock mode exclusive noncumulative – allow write locks to be successively
requested and released by the same transaction. This is same as write lock + same transaction can
successfully request and release write locks.
Optimistic locks – in the lock mode Optimistic – respond like read locks at first; can be changed to write
locks; and can be set if the user displays the data in change mode. Read lock, but can be changed to write
lock. When saving, read lock changes to write lock
Sm12 – display current locks

Remove lock – by either ending user session or deleting manually
THE PRINCIPLE OF ASYCHRONOUS UPDATES
SAP transactions can off-load time-intensive database changes by using the updating system. During a
dialog work process, the data temporarily stored for processing may be passed to an update work process
for further processing. The dialog work process, in that case, does not wait for the update request to be
completed. This type of update is asynchronous.
With the ABAP command COMMIT WORK, you complete the dialog part. Each dialog step corresponds to a
database transaction, which is executed either completely or not at all in the database. It is duly completed
with a COMMIT command.
THE ASYNCHRONOUS UPDATE PROCESS
An asynchronous update process triggers several steps:

The program first locks the data record for other users by addressing the enqueue work process.
If the lock entry to the lock table is successful, the program passes the lock key to the user. The program
then reads the record to be changed from the database
In the active dialog work process, the program calls a function module using CALL FUNCTION ... IN UPDATE
TASK. It then writes the change request to database update tables. These are called VB* tables; they act as
temporary memory; and store the data to be changed. Later on this data can be collected and written to
the application tables in the database.
After the dialog part of the transaction ends, the program initiates the close of the transaction with the
COMMIT WORK statement.
The update work process reads the log records that belong to this SAP transaction from the VB* tables. This
is based on the information (key of the update order, lock key) transferred from the dialog work process.
The changes are marked and collected in the VB* tables.
The lock entries in the lock table must be reset.
PRINTING IN AS ABAP
A spool request contains information on the output data requested; the formatting of this data; and the
printer model used. The spool request is stored in the TemSe (temporary sequential file). A spool work
process formats the data specified in the spool request and creates an output request. The data in the
output request is in an appropriate format for the printer. You can pass on this data to an appropriate
operating system spool process locally (on the same computer) or remotely (over a network connection).
The operating system then performs all remaining tasks, such as queuing and data transfer to the selected
printer.
SCHEDULING BACKGROUND TASKS (JOBS)

As an end user, you can schedule the program to be started in the background as a job from the application
transaction. The job then “waits” for the planned execution time in the job scheduling table. This
scheduling is facilitated by the background scheduler and the job is executed.
GATEWAY COMMUNICATION
Each instance of an AS ABAP system contains a gateway.

A gateway enables communication between the instances of a system or between various systems using
RFC.
The gateway reader is the main process of the gateway system. The dispatcher starts the gateway reader
and checks it periodically. The gateway forwards the request to the gateway of the remote system. The
remote gateway transfers the request to the dispatcher. This in turn forwards the request to one of its
work processes, which then communicates directly with its gateway.

PROCESSING A WEB REQUEST
The Internet Communication Manager (ICM) receives Web requests. The ICM then uses the URL to decide
where it should forward the request.
Any request to the Java runtime environment goes to the Java dispatcher (2b), which then forwards it to a
Java server process (3b). The Java server process then refers to the Java schema of the database (if
applicable) and sends the response back to the ICM using the Java dispatcher process. The ICM reroutes
this response from the SAP system to the user who sent the request (5).
Any request to the ABAP runtime environment is forwarded by the ICM to the ABAP dispatcher (2a), which
then handles it like a typical SAP GUI request and forwards it to the work process (3a).The relevant work
process now communicates directly with the ICM (4a). The ICM forwards this response to the user who
sent the request (5).

3 Communication and Integration
 Rfc – describes an interface, not the programming language

 rfc interface is bi directional
 rfcs manage communication process, transfer of params and error handling
 before u can call rfc, u need to setup rfc destination
CALL FUNCTION <fun name>

DESTINATION <dest>
EXPORTING
IMPORTING
A Bapi is a standard programming interface that facilitates internal and external access to business
processes and data in SAP systems.
BAPI's are basically function modules only. ALL BAPI's are remote enabled function modules which enables
to access via non SAP systems.
A remote function enabled FM (Function Module) will be attached to BOR (Business Object Repository),
then only it is termed as BAPI. Using BAPIs you can develop applications without detailed knowledge of the
underlying R/3 System.
Each BAPI is having its own business application and area. The integration between R/3 and third-party
software, legacy systems, and custom-developed software can be achieved via BAPI.
BAPI explorer with TCODE 'BAPI'.
BAPI explorer
All BAPI's are arranged according to the business area. Details documentation is also available for some
BAPI's to show the usage of the BAPI

Documentation of each BAPI
BAPI since its RFC enabled FM, has no exceptions. There are BAPI return tables which can be used to
analyse the success/failure of the process.
Since BAPI's are basically FM only, we call BAPI the same way we call a normal FM.
It is very important to select appropriate BAPI and also to pass the data in a way required by BAPI. Go
through all I/O structures for the BAPI selected to understand this better. We can also call BAPI of other
SAP systems. Just mention destination and you are good to go.
Ex:
call function 'BAPI_SALESORDER_GETSTATUS'
destination 'PW2'
exporting
salesdocument = order
importing
return = return
tables
statusinfo = statusinfo.
We need to call BAPI_TRANSACTION_COMMIT after each BAPI call to finalize or commit the change or if
some error occurs and we have identified the errors we need to use BAPI_TRANSACTION_ROLLBACK to
rollback the changes made if any.
Steps in using BAPI :
1) Find out which BAPI to be used.

Example: To create material found out that BAPI_MATERIAL_SAVEDATA can be used
2) Go to function builder SE37 and see the BAPI. See import and export parameters. Double click on the
structure or table type to know whether the fields involved in your program/report are present or not.

3) find out which are fields you require and accordingly create variables of that type only.
Avoid 'like' and use 'type' and' type table of' in case of tables.
4) Pass the values to the BAPI function. Tables parameters requires variables with Header line. All others
are just work area.
5) Always after calling BAPI call , BAPI_TRANSACTION_COMMIT to commit the changes (After each BAPI call
this has to be done )
6) Keep a breakpoint and look at BAPI return. IF success it shows success message also if problem it lists the
problem clearly.
BAPI RETURN TABLE
7) In case of long text . See the function documentation of BAPI. Use accordingly. Just append each
text_line and there you go it will pass long text.
BUSSINESS PROCESS DISTRIBUTION USING ALE
Application Link Enabling (ALE) enables you to create and operate distributed applications. ALE basically
enables the practical operation of a distributed, yet integrated system landscape. ALE links different
systems in business terms through secure and consistent data transfer.

IMPLEMENTING ALE
This slide shows you an example of how the data within the SAP system is synchronized in the business
process.
The IDoc format describes the structure of the intermediate documents.
You can transfer data by Remote Function Call (RFC), HTTP, or HTTPS.
Transfer type can be either synchronous transfer or asynchronous transfer.
Synchronous transfer implies that the data is transferred at the time of creation or change. An
asynchronous transfer can happen at intervals of your choice.
Ale:
 Format; idoc or xml
 Technology: rfc, http, https
 Type of transfer: sync or async
 SAP systems of different releases can be linked using ale
 Bapi vs. rfc – bapi is oo and registered in bor
INTERFACES TECHNOLOGIES USED IN SAP SYSTEMS
SAP systems have interfaces at different communication levels.

Many interface technologies are used by the SAP system:
Application Link Enabling or ALE
Business Application Programming Interface or BAPI
Common Program Interface Communication or CPI-C
Electronic Data Interchange or EDI
HyperText Transfer Protocol or HTTP

Logical Unit Type 6.2 or LU 6.2
Remote Function Call or RFC
Object Linking and Embedding or OLE
Simple Mail Transfer Protocol or SMTP
Simple Object Access Protocol or SOAP
Transmission Control Protocol/Internet Protocol or TCP/IP
Extensible Markup Language or XML
RFC CONNECTION POSSIBILITIES
The Remote Function Call interface is an SAP interface protocol based on CPI-C and TCP/IP. With an RFC,
you can call and execute predefined functions either in a remote system or within the same system. You
can also call functions in non-SAP systems. During RFC communication between two SAP systems, the
calling system uses an RFC definition to access a specific function. ABAP programs use RFCs to access
functions in SAP systems.
To start external programs remotely, you need an RFC interface outside the SAP system. As all RFC
interfaces are bidirectional, external programs can also use RFCs to access functions in SAP systems.

REMOTE FUNCTION CALL IN DETAIL
To access an RFC module from an SAP system, you need to know the import and export parameters, as
defined in the Function Builder. The two systems must have a technical connection. This is called an RFC
connection or an RFC destination.
You can create an RFC destination named DEST in the calling system. In ABAP, RFCs can call a function
module in another system if you key in the relevant code:
CALL FUNCTION <Name>

DESTINATION <Ziel>
EXPORTING ...
IMPORTING ...
You can name the function to be executed in the target system. Next, reference the name of the target to
one of the RFC connections available. Exporting and Importing are the functions used to pass on the
parameters to the target function and also to receive the returned parameters.
If you need a bidirectional RFC connection between two systems, you need to set up a similar second RFC
connection in the system called.

BOR AND BAPIs
A Business Application Programming Interface (BAPI) is a standardized programming interface. It enables

internal and external access to business processes and data in SAP systems. BAPIs are defined in the
Business Object Repository (BOR) as methods that facilitate an object-oriented view of business data in an
SAP system.
BAPI USES
BAPIs are used in several ways:
They link business processes across system boundaries, such as when using ALE.
They integrate various solutions in the framework of the SAP Business Suite.
They connect an SAP system to the Internet.
They can be used in conjunction with the SAP Business Workflow.
They also help to connect to external programs.

SAP R/2 AND R/3
SAP R/2 and SAP R/3 have these common features:
Real-time processing of business processes
Use of ABAP as a programming language
Constantly increasing features (during the maintenance period) by functions newly created by SAP
Adjustability of mapped processes to company-specific activities
All information is stored in a central database
The primary difference is host-based system on client-server-based system. The change from SAP R/2 to
SAP R/3 basically means a change in the technical infrastructure and in the design of the user interface.
CLIENT-SERVER ARCHITECTURE VERSUS ENTERPRISE SOA
In the usual Client Server Architecture, the system database holds the business process data. The
application processes, which run on application servers, are made available through predefined interfaces.
Also, different business applications exchange data directly through the database.
In the Enterprise SOA, on the other hand, role-based user interfaces function as central entry points for the
employees of the company, who carry out their work using different applications in different systems. New
process steps are provided as Enterprise Services. These enable the users to save the data in totally
different databases, as well as to integrate the data using general standards.
For example, Client Server Architecture enables a financial transaction to access an HR-related table in
which data was updated from an HR transaction earlier.
In contrast, in Enterprise SOA, the financial application would request the HR data through a specific
application-to-application (A2A) interface and not simply retrieve the data from the database with an SQL
access.
ENTERPRISE SOA VS WEB SERVICES
An Enterprise Service is a complete industry-specific process, which comprises many small individual steps.
All the actions together form the Enterprise Service, thus constituting the overall context-oriented business
process logic.
In contrast, Web Services are smaller modular applications which run within the framework of Internet
technologies and address detail functions within applications or Enterprise Services.
Diff between es and web services
 Business semantics: es are structured according to enterprise model based on bo, process
components and global data types rather than SAP specific implementation
 Quality and stability: es guarantee backwards compatibility
 Standards: gdt are based on un / ccts ( core component tech spec)
CHARACTERISTICS OF ENTERPRISE SOA

An Enterprise SOA application
is implemented across systems;
is created in ABAP or in Java; and
generally does not have its own database.
New functions are entered outside the existing systems for Enterprise SOA applications.
ENTERPRISE SERCIVES: ADVANTAGES
The availability of Enterprise Services enables the efficient creation of new applications without having to
modify the underlying system. It also provides flexibility in the configuration of business processes and
simplifies the creation of applications that use the functions of several systems.
SAP NETWEAVER: WEB SERVICES STANDARD
A Web service is a module that can be used flexibly in different applications.

In the SAP Netweaver Application Server, some basic standards for Web services are implemented, such as
extensible Markup Language (XML);

Simple Object Access Protocol (SOAP);
Web Service Description Language (WSDL); and
Universal Description, Discovery, and Integration (UDDI).
OUTLINE OF A WEB SERVICE SCENARIO
A Web service defined can be called up from an ABAP program or from a Business Server Page.
The steps to create a Web service scenario are quite distinct:
The Web service provider publishes the service in a publicly accessible UDDI directory. A URL is
generated, as are the WSDL files.
The Web service user creates a proxy object that refers to the URL of the Web service .The Web service
user then searches directly for Web services in the UDDI directory.
The proxy object is written to and integrated into an executable program (for example, in ABAP) and
called up there.
Composite business processes

 Human centric: human involved, bpm or brm
 System centric: b2b using SAP pi

4 Program Flow
The software-oriented client/server principle powers the modular architecture of the SAP Netweaver
Application Server.
A relational database management system or RDBMS is used for managing data at the lowest level, called
the database level.
The ABAP programs run at the application server level. They read data from the database; process it; and
store the new data if necessary.
The third level or the presentation server level contains the user interface. Here each user can access the
program; enter new data; and receive the results of a work process.
The assignments of these different levels to different systems serve as the basis for the scalability of the
system.
EXCERPT FOR AN ABAP PROGRAM
ABAP programs are processed on the application server. When writing application programs, the design
of user dialogs and database accesses is of particular importance.
This simplified graphic does not explicitly show the dispatcher and the work process. However, interaction
between one user and one ABAP program will be the area of interest.

VIEW FOR THE USER
The average user has a practical interest in the business process and how data can be entered or displayed.
This does not include knowledge of the precise process flow of an ABAP program. Thus the SAP system is
like a "black box" to them.
INTERPLAY BETWEEN SERVER LEVELS AND PROGRAM FLOW
If a user performs a user action, such as choosing Enter or a function key, the control is passed from the
presentation server to the application server.
If a further user dialog is triggered from within the ABAP program, the system transmits the screen and
control back to the presentation server.
A program normally comprises not just a single block, but several reusable “modularization units.” In a
good program, the database accesses will be encapsulated in such reuse units. This creates a division
between the design of the user dialog and the database accesses.

PROGRAM START
Whenever a user logs on to the system, a screen is displayed. This screen helps the user start an ABAP
program through the menu path.
SYSTEM LOADS PROGRAM CONTEXT
The system first loads the program context onto the application server. The Repository, which is a special
part of the database, passes on all this program information to the runtime system.
The sample program has a selection screen as the user dialog; a variable and a structure as data objects;
and one ABAP processing block.
The ABAP runtime system controls the subsequent program flow.

RUNTIME SYSTEM SENDS SELECTION SCREEN
As the program contains a selection screen, the ABAP runtime system sends it to the presentation server.
The presentation server controls the program flow until the user finishes entering data in the input fields.
INPUT VALUES ARE INSERTED INTO DATA OBJECTS
After you finish entering the data on the selection screen, you can trigger further processing of the program
by choosing Execute. The entered data are automatically placed in their corresponding data objects in the
program and the ABAP runtime system resumes control of processing.
If your entries do not have the correct type, you will get an automatically triggered error message. You
must then correct the entries.

REUSE UNIT LOADING
A reusable unit is called in the processing block that encapsulates the database access. With this, the
program in which it is contained is also read from the Repository and loaded to the application server.
REUSE UNIT IS CALLED
The required data is transferred to the called program and the reuse unit is executed. As the execution is
synchronous, you know that the calling program waits until the reuse unit is processed completely.

PROGRAM REQUESTS DATA RECORD FROM THE DATABASE
Information about the database table to be accessed and the row in the table to be read is passed on to the
database.
DATABASE SUPPLIES THE DATA RECORD
The database returns the requested data record to the program and the runtime system ensures that this
data is placed in the appropriate data objects.

REUSE UNIT RETURNS THE DATA
The processing of the reuse unit ends and the control is returned to the calling program, which resumes
immediately after the call. The data that was read from the database is written to a corresponding data
object for the calling program.
RUNTIME SYSTEM SENDS THE LIST
The ABAP processing block receives statements for structuring the list with which the result is to be
displayed. After the execution of the processing block, the runtime system sends the list as a screen to the
presentation server.

5 ABAP Workbench
The Repository holds all system development objects, such as programs, function modules, and definitions
of database tables. It is in the database; is always independent of the client; and thus its objects are
accessible from any client.
The database not only comprises the Repository, but also contains application and Customizing data, which
are normally client-dependent. In short, every data record is assigned to a particular client: only users who
have logged on to that particular client can read it or change data in it.
STRUCTURE OF THE REPOSITORY
The Repository is subdivided according to application components such as MM, HR, FI, and SD. An
application component can contain several packages with relevant objects for a more detailed logical
subdivision.
Whenever a Repository object is created, it must be assigned to a package.

THE REPOSITORY INFORMATION SYSTEM
You might want to perform a random search of Repository objects; for example, all programs by a certain
developer or all function modules that were changed after a certain date. You should access the Repository
Information System from the SAP Easy Access Menu path:
Tools → ABAP Workbench → Overview → Information System.
When you double-click a certain object type, a selection screen appears allowing you to limit your search.
SAP APPLICATION HIERARCHY
The SAP application hierarchy is used for the application-specific search of Repository objects. You can see
these objects listed in a hierarchical tree structure. When you expand a component node, for example FI,
you will see a display of all the packages that are assigned to that component (for example, FI-GL).
Choose Select to specify the sub tree; then navigate directly to the Repository Information System by
clicking Information System.
ABAP WORKBENCH TOOLS

The ABAP Workbench includes all the tools required for creating and editing Repository objects.
These tools cover the entire software development cycle:
The ABAP Editor is used for editing the source code.
The ABAP Dictionary is needed when editing database table definitions, central data types, and so on.
The Screen Painter helps configure screens (together with functions for user dialogs).
The Menu Painter helps in designing user interfaces (menu bar, standard toolbar, application toolbar,
and function key settings).
The Function Builder is used for maintaining function modules.
The Class Builder is used for maintaining global classes and interfaces.
The ABAP Debugger is used to locate semantic errors in your program and also to analyse program flows.
The Object Navigator is a central development tool where you can have the requested Repository objects
listed.
SCREEN LAYOUT IN THE OBJECT NAVIGATOR
The Object Navigator screen can be split into a navigation area for displaying a hierarchical object list and
a tool area for displaying and editing a development object using the appropriate tool.
You can display or hide the navigation area with the Full screen on/off option.
The context menu helps you to choose only those functions that are designed for the respective object.

WORKING WITH THE NAVIGATION AREA
If you choose to display a package in the navigation area, then all of the Repository objects belonging to
this package are listed. You can double-click a listed object to display or edit it.
You can also navigate between the object lists that were previously displayed in the current Object
Navigator session.
You can add frequently used object lists to your favourites.
You can also display the list of higher-level objects. The refresh option helps you to refresh the object list.
FUNCTIONS IN THE TOOL AREA
In the tool area a Repository object is displayed in the corresponding tool.

You can also navigate between the objects that were previously displayed in the current Object Navigator
session (blue arrows).
You can display a sub window with the previous navigation history. You then double-click an object in the
navigation history to display it in the tool area.

SYNCHRONIZING THE NAVIGATION AND TOOL AREAS
Navigation in the navigation area is independent of navigation in the tool area.

However, you can synchronize both areas using one of two methods:
You can display an object in the tool area either by double-clicking in the navigation area or by using the
corresponding context menu function of the object.
If you are currently editing an object in the tool area, you can display the object list of that object by
choosing Display Object List.
TRANSPORTING DEVELOPMENT
Development projects are carried out in a development system.

The project manager starts the development project by creating a change request, which includes the
names of the assigned employees, in the Transport Organizer.
The Transport Organizer then creates a task for each project employee in the change request.
The employee who has to create or edit a development object assigns this to the change request and it is
entered into the task of the employee.
The development objects that are edited or created in a project are then transported to the subsequent
systems (test system, production system, or both) on project completion.

What is a Transport Request?
Transport Requests (TRs) – are also known as Change Requests. It is a kind of 'Container / Collection' of
changes that are made in the development system . It also records the information regarding the type of
change, purpose of transport, request category and the target system.
Each TR contains one or more change jobs, also known as change Tasks (minimum unit of transportable
change) . Tasks are stored inside a TR, just like multiple files are stored in some folder. TR can be released
only once all the tasks inside a TR are completed, released or deleted.
Change Task is actually a list of objects that are modified by a particular user. Each task can be assigned to
(and released by) only one user, however multiple users can be assigned to each Transport Request (as it
can contain multiple tasks). Tasks are not transportable by themselves, but only as a part of TR.
Change requests are named in a standard format as: <SID>K<Number> [Not modifiable by system
administrators]
SID – System ID
K – Is fixed keyword/alphabet
Number – can be anything from a range starting with 900001
Example: DEVK900030
Tasks also use the same naming convention, with 'numbers' consecutive to the number used in TR
containing them.
For Example, Tasks in the above mentioned TR Example can be named as: DEVK900031, DEVK900032 …
The project manager or designated lead is responsible to create a TR and assign the project members to the
TR by creating task/s for each project member.

Hence, she/he is the owner with control of all the changes that are recorded in that TR and therefore,
she/he can only release that TR.
However, assigned project members can release their respective change tasks, once completed.
Workbench Request – contains repository objects and also 'cross-client' customizing objects. These
requests are responsible for making changes in the ABAP workbench objects.
Customizing Request – contains objects that belong to 'client-specific' customizing. As per client
settings these requests are automatically recorded as per when users perform customizing settings
and a target system is automatically assigned as per the transport layer (if defined).

SE01 – Transport Organizer – Extended View
Create a Change Request
Change Request can be created in two ways:

Automatic – Whenever creating or modifying an object, or when performing customizing settings, system
itself displays the 'Dialog box' for creating a change request or mention name of an already created
request, if available.
Manually – Create the change request from the Transport Organizer, and then enter required attributes
and insert objects.

>
Release the Transport Request (Export Process)
Position the cursor on the TR name or a Task name & choose the Release icon (Truck), a record of the TR is
automatically added to the appropriate import queues of the systems defined in the TMS.
Releasing and importing a request generates export & import logs.

The Import Process
Importing TRs into the target system
After the request owner releases the Transport Requests from Source system, changes should appear in
quality and production system; however this is not an automatic process.
As soon as the export process completes (releasing of TRs), relevant files (Cofiles and Data files) are created
in the common transport directory at OS level and the entry is made in the Import Buffer (OS View)
/ Import Queue (SAP App. View) of the QAS and PRD.
Now to perform the import, we need to access the import queue and for that we need to execute
transaction code STMS -> Import Button OR select Overview -> Imports
It will show the list of systems in the current domain, description and number of requests available in
Import Queue and the status.

Import Queue -> is the list of TRs available in the common directory and are ready to be imported in
the target system, this is the SAP Application View, at the OS level it is also known as Import
Buffer.
The Import status

Import Queue shows some standard 'status icons' in the last column, here are the icons with their
meanings, as defined by SAP:

In case, a request is not added automatically in the import queue/buffer, even though the OS level files are
present, then we can add such requests by the following method, however, we should know the name of
intended TR:
Import History
We can also check the previous imports that happened in the system as follows:
Transport logs and return codes

After the transport has been performed, system administrator must check whether it was performed
properly or not, for that SAP has provided us with the following type of logs (SE01 -> GOTO -> Transport
Logs) :
Action Log – which displays actions that have taken place: exports, test import, import and so forth.

Transport Logs – which keep a record of the transport log files.
One of the important information provided by logs are the return codes:
 0: The export was successful.
 4: Warning was issued but all objects were transported successfully.
 8: A warning was issued and at least one object could not be transported successfully.
 12 or higher: A critical error had occurred, generally not caused by the objects in the request.
ORGANIZATION OF A DEVELOPMENT PROJECT IN THE CHANGE REQUEST
Organizing a development project using a change request has several advantages:

Individual employees can track and check their project-specific activities.
All the project employees can process the respective development objects. The Repository objects
remain locked for developers who do not belong to the project team until the project is completed.
By assigning the objects to the change request, you can automatically ensure the joint transport of the
development objects processed at the time of project completion (or release of the change request).
SETTING PACKAGE ATTRIBUTES (EXAMPLE)
This slide depicts a dialog box for creating a package.

You can set various attributes for the package:
Specify the Package Type.
In the field Application Component, specify the location of the package within the application hierarchy.
In the field Software component for customer development, enter the value HOME.

In the Transport Layer you can determine whether the objects of this package are to be transported to a
subsequent system and, if so, to which system.
You then have to assign the package to a change request.

SPECIFIYING A TRANSPORT ROUTE
If you are executing your own developments, then you must set up a transport layer for customer
developments.
The customer developments and modifications to SAP objects, which are carried out in the Development
System (DEV), are transported to the Test and Translation System (QAS) for testing and then moved to the
Production System (PRD).
ASSINGMENT TO A CHANGE REQUEST
The package created must be assigned to a change request.

You can display all change requests in which you have a task using the My Tasks option. You can simply
select the relevant request by double-clicking it.

CREATING AN ABAP PROGRAM
The screenshot shows you the dialog box that lets you create a program.
Make sure you comply with the customer namespace conventions.
In this training course, remove the flag for With TOP Include, otherwise the source code will get distributed
to several programs.
Change the title to a self-explanatory short text and always choose Executable Program as the program
type for this training course.
All other program attributes are optional.
ABAP PROGRAMMING LANGUAGE: PROPERTIES
The ABAP Programming Language is especially designed for dialog-based business applications. Type-
specific processing of data is possible using type conversions and type casting. You can also develop
multilanguage applications using translatable text elements. The Open SQL standard embedded in ABAP
allows direct database accesses.
ABAP Objects is the object-oriented enhancement of the ABAP programming language.
The ABAP syntax is independent of the platform, the relational database system, and the operating system
for the application and presentation server.
Applications implemented in ABAP can run in future releases. Hence, ABAP has upward compatibility.

GENERAL ABAP SYNTAX I
You follow certain rules for ABAP syntax:

ABAP programs comprise individual sentences (statements).
The first word in a statement is called an ABAP keyword.
Each statement ends with a period.
Words must always be separated by at least one space.
You can indent statements as you wish.
With keywords, additions, and operands, the ABAP runtime system does not differentiate between
upper and lowercase.
GENERAL ABAP SYNTAX II
You have to keep in mind certain rules for ABAP syntax:
Statements can extend beyond one line.
You can have several statements in a single line (though this is not recommended).
Lines that begin with an asterisk (*) in the first column are comment lines (whole lines) and are ignored
by the ABAP runtime system.
Double quotations marks (") indicate that the remainder of a line is a comment.
You can combine consecutive statements with an identical beginning into a chained statement.
In this case, place a colon after the identical beginning parts of the records.
KEYWORD DOCUMENTATION IN THE ABAP EDITOR
You can use more than one method to navigate to the documentation for an ABAP statement:
The F1 key takes you directly to the documentation for the statement on which the cursor is positioned.
The “I” icon with the description Help on … takes you to a dialog box where you can enter the required
ABAP statement.
THE PREVIOUS ABAP EDITOR
The previous ABAP editor is known as the classic editor or the Front-End Editor (Old).
NEW ABAP EDITOR

The New ABAP Editor was developed for SAP Netweaver 7.0.
The new editor provides a number of important options:
Different objects in the source code can have different display colours.
You can set fonts and font sizes for each individual user.
A better overview is possible if blocks of source code (loops and conditional branches) are compressed
for display.
You can use bookmarks to find relevant points in the source code faster.
The display of line numbers and the current nesting facilitates improved orientation.
Once you have typed a few characters, the editor automatically suggests complete words for ABAP
keywords and data objects. This considerably reduces the actual amount of typing required.
When pressing STRG + SPACE together, the new editor generates a small dropdown list menu with
suggestions suitable for the current cursor position (AS ABAP 7.02).
INACTIVE AND ACTIVE DEVELOPMENT OBJECTS

Whenever you create or change a development object and then save it, the system first stores only
one inactive version in the Repository.
You then have an active version as well as an inactive version of the object. At the end of your object
development you have to activate the inactive “editing version” of the object, which now becomes the new
active version of the object.
Note that the request release and hence the transport of the developed objects are only possible if all
objects in the request are activated.
GENERATING RUNTIME OBJECTS
When you generate a development object, the system creates a separate runtime object (LOAD
compilation) and stores it in the Repository. This generated version is the version that is executed
(interpreted) at runtime.
You can execute the inactive and the active versions of a program in more than one way:
The active version is used if you start your program using the context menu of the navigation area or by
means of a transaction. This means that the LOAD generated for the last activation is executed.
Conversely, if you start the inactive version loaded to the editor using the F8 function, you can generate
and execute a temporary runtime object from it.
This way you can continue to develop a Repository object without changing the current system status.

CREATING A TRANSACTION
Creating a transaction involves a series of consecutive steps:

Display the object list for your program in the Object Navigator.
In the navigation area, using the context menu of the program, choose Create →Transaction.
Enter the required transaction code.
Assign a short text and choose the label Program and Selection Screen (Report Transaction).
On the next screen, enter the name of the program and choose Professional User Transaction.
Set the indicator SAP GUI for Windows under GUI enabled.
Save the transaction.
As each transaction is a Repository object, you must assign it to a package and then to a change request
on the subsequent screens.
INSERTING A TRANSACTION CODE INTO THE PERSONAL FAVORITES
In the SAP Easy Access menu, choose Favourites.

In the resulting context menu, choose Insert Transaction.

The dialog box Enter Transaction Manually is displayed.
Enter the required transaction code in this dialog box.
The short text of the transaction is now included under Favourites and you can start the relevant program
by double-clicking it.
THE DEVELOPER RELEASES HIS/HER TASK
After completing the required development task, the project employee has to perform a quality check and
release the task within the change request.
Once all the tasks in a change request are released, the project manager carries out the final check for the
objects and releases the change request. This concludes the project.
CLOSING THE PROJECT BY RELEASING THE REQUEST (PROJECT MANAGER)
When the request is released

all the object locks that belong to it are removed;
copies of the developed objects are exported to the system’s own transport directory (where they stay
until the system administrator imports them to their intended target system); and
another copy of the exported development objects is stored in the system’s own version database.
The abap repository is subdivided based on application components (fi, co, mm etc)

Project manager
 Creates change request
 Names employees in transport organiser
 Creates task for each employee in change request
 When employee checks out, object is added to the task
 Package – to organise
 Change request - ownership of objects for a time
Package attributes:
 Name
 Description
 Application component – fi, co etc
 Software component – for customer development, enter “HOME”
 Transport layer – where do you want to transport the deve objects (ZDEV)
 Package type
 Standard package – can contain rep objects and other packages
 Main package – contains only other packages
 Structure package – only main package

6 ABAP DATA TYPES
A formal description of a variable is called a data type.

When you define a variable or constant concretely by means of a data type, you define a data object.
The type of a data object defines its technical (and possibly also semantic) properties.
The type of an interface parameter is essential for determining the type of the actual parameter that is
transferred when the modularization unit is called.
An input or output field should also be assigned a type. Only then can it provide information in addition to
the technical characteristics, such as the field and value input help.
ABAP STANDARD TYPES: COMPLETE
The ABAP standard types predefined by SAP are divided into two groups: complete and incomplete types.
Complete types are type-specific and have a fixed-length specification:
Type D is used for date with format YYYYMMDD and fixed length 8.
T is used for time with format HHMMSS and fixed length 6.
I is used for integer and has a fixed length of 4.
F is used for floating point number and has a fixed length of 8.
DECFLOAT16 or DECimal FLOATing point number has a fixed length of 8 and is available as of AS ABAP 7.02.
DECFLOAT34 or DECimal FLOATing point number has a fixed length of 16 and is available as of AS ABAP
7.02.
STRING is the type used for dynamic length character strings.
XSTRING or hexadecimal string is the type used for dynamic length byte sequence.
ABAP STANDARD TYPES: INCOMPLETE
For some ABAP standard types, you have to specify a fixed length of the variable while defining a data
object.
These incomplete ABAP standard types do not contain a fixed length:
C is used for the character string (Character).
N is used for the numerical character string (Numerical character).
X is used for byte sequence (HeXadecimal string).
P is used for packed number (Packed number). In the definition of a packed number, the number of decimal
points may also be specified.
Integer Data Type occupies 4 bytes of memory and we can store up to 10 digits in an integer.
Float data type stores 8 bytes of memory. This stores decimal data also. It is defined with 16 decimal places
by default.
Packed data type is same as Float data type except that by default, there are no decimal places and ABAPER
has to specify the required no. of decimal places.
Character data type can accept all ASCII characters and it occupies 1 byte of memory.
Number accepts only numbers but treats them as characters. i.e., string operations can be executed
Date data type is of 8 bytes long and stores date in YYYYMMDD format.
Time data type is of 6 bytes long and stores time in HHMMSS format.
String data type has variable size and it adjusts based on the data in the string. It can read only .txt files
Xstring is the hexadecimal formatted and similar to String type. i.e., it can read all files like .doc, .ppt, .xcs,
.jpg, .bmp etc.
We can also create our own Data Types using "Types" or by creating custom objects like Structures, Classes,
Interfaces etc.
Differences between Float and Packed data types:

FLOAT has default decimal places of 16 & PACKED data type has 0.
FLOAT decimal places are fixed whereas can be decided by the ABAP for PACKED.
PARAMETER, which creates GUI for data type is not supported by FLOAT while it is supported by PACKED
type.
DATA TYPE DESCRIPTION DEFAULT LENGTH DEFAULT VALUE
C Character 1 ‘‘
N Numeric 1 0
D Date 8 00000000
T Time 6 000000
X Hexa Decimal 1 X’0′
I Integer 4 0
P Packed 8 0
F Float 8 0
User defined data types
Use TYPES keyword to define the data types.

TYPES: name(10) TYPE c,
length TYPE p DECIMALS 2,
counter TYPE i,
id(5) TYPE n.
Structured data types
Structured data type is grouping of several simple data types under one name.
Use the keywords BEGIN OF and END OF to create a structured data type.
TYPES: BEGIN OF student,

id(5) TYPE n,
name(10) TYPE c,
dob TYPE d,
place(10) TYPE c,

END OF student.
Constants
Constants are used to store a value under a name. We must specify the value when we declare a constant
and the value cannot be changed later in the program.
Use CONSTANTS keyword to declare a constant.
CONSTANTS: pi TYPE p DECIMALS 2 VALUE '3.14',

yes TYPE c VALUE 'X'.
ABAP Variables are instances of data types. Variables are created during program execution and
destroyed after program execution.
Use keyword DATA to declare a variable.
DATA: firstname(10) TYPE c,

index TYPE i,
student_id(5) TYPE n.
While declaring a variable we can also refer to an existing variable instead of data type. For that
use LIKE instead of TYPE keyword while declaring a variable.
DATA: firstname(10) TYPE c,

lastname(10) LIKE firstname. " Observe LIKE keyword
Structured Variable
Similar to structured data type, structured variable can be declared using BEGIN OF and END
OF keywords.
DATA: BEGIN OF student,

id(5) TYPE n,
name(10) TYPE c,
dob TYPE d,
place(10) TYPE c,
END OF student.
We can also declare a structured variable by referring to an existing structured data type.
TYPES: BEGIN OF address,
name(10) TYPE c,
street(10) TYPE c,
place(10) TYPE c,
pincode(6) type n,
phone(10) type n,
END OF address.
Data: house_address type address,

office_address like house_address.
Each individual field of the structured variable can be accessed using hyphen (-). For example, name field of
the house_address structure can be accessed using housing_address-name.
Character is the default data type.

DATA: true. " By default it will take C as data type
DECLARING LOCAL TYPES
The local data type “gty_c_type” is declared with a TYPES statement and is defined with an incomplete
standard type ‘c’ of length 8.
GLOBAL TYPES IN THE DICTIONARY
A data type defined in the ABAP Dictionary is called global and can be used throughout the SAP
system. Global Types include Data Element, Structure, and Table Type. Data Elements define Field
Types. Structure and Table Type are used to define a structure type and a type for internal tables,
respectively.

DEFINING DATA OBJECTS
Data objects are always defined with the DATA keyword. You can use an ABAP standard type, a local type,
or a global type to define a type for the data object.
You can refer to an already defined data object when defining additional variables by using the keyword
LIKE.

EXAMPLE OF THE DEFINITION OF ELEMENTARY DATA OBJECTS
You can use the VALUE addition to pre assign the value of an elementary data object.
If the length is not specified in the variable definition, a default length for the incomplete standard type is
used. The default length is 1 for types C, N, and X, and 8 for type P.
A data object without a type and length specification takes a default type C with length 1.
LITERALS AND CONSTANTS (FIXED DATA OBJECTS)
Fixed data objects have a fixed value and cannot be changed at runtime. Literals and constants belong to
the fixed data objects.
You can use literals to specify fixed values in your programs.
Numeric literals are specified without quotation marks.
Text literals are specified with quotation marks.
You define constants using the CONSTANTS statement.
Their type is defined similarly to the definition of elementary data objects. The VALUE addition
is mandatory for constants.

TEXT SYMBOLS
Text symbols are used for productive programs that should be executable with different logon languages.
If the program accesses a text symbol when it is executed, the system automatically takes account of the
logon language of the user and supplies the text in this language.
A text symbol is identified by means of a three-character alphanumeric ID xxx.
To use a text symbol in your program, you need to address it as TEXT-xxx, where xxx stands for the three-
character text symbol ID.
You can also use the syntax '...'(xxx) where, '...' is the text of the text symbol in the original language of the
program.
LOCAL VERSUS GLOBAL DATA TYPES
Global data types have at least three advantages over local data types:
You can use global types system wide, thereby enhancing the system’s consistency. As global types are
reusable, you spend fewer resources on maintenance.
In the ABAP Dictionary you can generate a where-used list for a global data type. This list names the
Repository objects that use that data type.
In addition to the technical information, global data types can also contain semantic information
corresponding to the business descriptions of the objects being defined.
Local data types should be used only if the semantic information does not matter for the definition of the
corresponding data objects.
VALUE ASSINGMENTS
Every elementary data object has a preassigned type-specific initial value, except if the VALUE addition was
used to set a different value.
The MOVE statement helps transfer the contents of a data object to another data object.
The same effect is achieved by two different syntax variants:
MOVE variable1 TO variable2.
variable2 = variable1.
The CLEAR statement resets the contents of a data object to the type-related initial value.
CALCULATIONS
In ABAP you can program arithmetic expressions nested to any depth.

You can list some of the valid operations:
+ indicates addition.
- indicates subtraction.
* indicates multiplication.
/ indicates division.

** indicates exponentiation.
DIV indicates integral division without remainder.
MOD indicates remainder after integral division.
You can use the optional COMPUTE keyword for calculations that use these arithmetic expressions.
CONDITIONAL BRANCHES
There are two ways to execute different sequences of statements, depending on certain conditions.
In the IF construct you can define logical expressions as check conditions. If the condition is met, the
system executes the relevant statement block. Otherwise, the condition specified in the next ELSEIF branch
is checked. If none of the specified conditions are fulfilled, the ELSE branch is executed. ELSEIF and ELSE
branches are optional.
The CASE construct is used to clearly distinguish cases. The content of the field specified in the CASE part is
checked against the data objects listed in the WHEN branches to see whether they match. If the field
contents match, the statement block is processed. If there are no successful matches, the system executes
the OTHERS branch if it is available.
The IF and CASE constructs should be concluded with an ENDIF and an ENDCASE statement, respectively.
EXAMPLES: IF STATEMENTS
You can nest the IF and CASE structures in any way you wish: just keep the logic of every structure correct.
You can formulate negations by placing the NOT operator before the logical expression. When negating the
IS INITIAL query, you can use the special IS NOT INITIAL query.
LOOPS
You can use four loop constructs in ABAP:

The statement block between DO and ENDDO is executed continuously until the loop is left using
termination statements such as EXIT. This is an unconditional or index-controlled loop.
The statement block between WHILE and ENDWHILE is continuously executed until the specified
condition is no longer met. The condition is always checked before executing the statement block. This is
a header-controlled loop.
You can use the SELECT loop to read several entries of a database table in succession.
In an internal table, the same read function is implemented with the LOOP loop. This is a read loop.
In the DO and WHILE loops, the system field SY-INDEX contains the number of the current loop pass.

SOME INTRESTING SYSTEM FIELDS
The runtime system uses system fields to provide the application program with information about the
actual system status. This slide depicts some interesting system fields and their meanings.
RETURN CODE OF AN ABAP STATEMENT
One of the most important system fields is the field sy-subrc. It is filled with the corresponding return code
to indicate whether the statement was executed successfully. The value zero means that the statement was
executed successfully.

DIALOG MESSAGES
You can send dialog messages to the users of your program by using the MESSAGE statement. You must
specify the three-digit message number and the message class, which clearly identify the message to be
displayed. The message type specifies where the message is to be displayed.
If the specified message contains placeholders, you can use the WITH addition to supply them with values
from your program. Instead of the placeholders, the transferred values then appear in the displayed
message text.
A Termination The message appears in a dialog box, and the program terminates. When
the user has confirmed the message, control returns to the next-highest
area menu.
E Error Depending on the program context, an error dialog appears or the

program terminates.
I Status The message appears in a dialog box. Once the user has confirmed the
message, the program continues immediately after
the MESSAGE statement.
S Error The program continues normally after the MESSAGE statement, and the
message is displayed in the status bar of the next screen.
W Warning Depending on the program context, an error dialog appears or the

program terminates.
X Exit No message is displayed, and the program terminates with a short dump.
Program terminations with a short dump normally only occur when a
runtime error occurs.
The syntax for issuing a message is as follows.

MESSAGE <message> TYPE <message type>.

We can issue a status message as follows. Status message will be displayed in the status bar. After the
message is displayed the program continues after the MESSAGE statement.
MESSAGE 'This is a status message' TYPE 'S'.
In the text symbols screen we can maintain the messages with a 3 character identifier.
Then use the following message statement.

MESSAGE text-001 TYPE 'I'.
EXECUTE A PROGRAM IN DEBUGGING MODE
You have different options for starting a program in debugging mode from within the Object Navigator:
In the navigation area for the selected program, choose the context menu and then the

path: Execute → Debugging.
In the editor area, select the requested program line from which you wish to debug. Choose
the Set/Delete Breakpoint icon and start the program by choosing F8; otherwise, in the navigation area,
choose the context menu and follow the path: Execute → Direct.
SWITCH TO DEBUGGING MODE AT RUNTIME
In order to debug a certain function of a program, you must first start the program without
the Debugger and then switch to debug mode immediately before executing the function.
There are two ways of doing this:
Choose System → Utilities → Debugging ABAP (or Debugging screen).
Enter /h in the command field in the standard toolbar and click Enter.
ABAP DEBUGGER: SINGLE STEP AND FIELD CONTENTS
You can choose the option Single Step, to execute the program statement by statement. Furthermore, you
can display data objects and their current content in the variable by double-clicking the corresponding data
objects in the source code or by simply entering the name of the data object.
ABAP DEBUGGER: BREAKPOINTS

You can set a breakpoint in the new debugger with a single click before the line in the source code.
You can also set a breakpoint for specific ABAP statements by choosing: Breakpoints → Breakpoint
at → Statement.
If you click Continue, the program is executed up to the next breakpoint.
The set breakpoints are only valid for the current debugger session. However, if you press Save, the
breakpoints will stay in place for the duration of your current SAP session.
ABAP DEBUGGER: TRACING DATA CHANGES
Watchpoints are breakpoints that depend on the field content.

If you set a watchpoint without specifying a relational operator or comparative value on a field and
choose Continue, then the program is executed until the content of the field changes.
However, if you specify the relational operator and comparative value and choose Continue, then the
program will be executed until the specified condition is met.
ABAP DEBUGGER: CHANGING FIELD CONTENTS

To change the content of a field during debugging, double-click Change in the variable display: now the
value is ready for input.
You can now change the field value and confirm the change by choosing ENTER. The value is now changed
while the debugger is running.
ADDITIONAL FUNCTIONS OF THE NEW DEBUGGER
A number of useful functions have been added in the new debugger with the release of SAP Netweaver
7.0.
In the Object Navigator you can determine which debugger you want to use as standard by following the
path:
Utilities → Settings → ABAP Editor → Debugging.
Comment
* whole line
“ rest of line

When you create or change dev object and save it, system stores only one inactive version in repo. You can
have 1 active and 1 inactive version.
Transaction – can only be used in role menu or user favourite

You can create tx code for your program e.g. zoogs
Dev releases task

Finally pm releases change request
Text symbols are special text constants that you enter and maintain independently of the program
code. In the final versions of your programs, you should use text symbols instead of hard-coded
texts. This makes the programs language-independent and easier to maintain.
PROGRAM TEXT_ELEMENTS_2.
WRITE: TEXT-010,
/ TEXT-AAA,
/ TEXT-020,
/ 'Default Text 030'(030),
/ 'Default Text 040'(040).
Procedure
From the ABAP Editor:
Enter your WRITE statement with the three-character ID and default texts.
Double-click one of the entries in the WRITE statement.
If the text symbol does not yet exist, a dialog box appears. Confirm that you want to create the text
symbol.
The text symbol maintenance screen appears.
Enter the text.
It may be up to 132 characters long.
Save the text symbol.

The maximum length mLen is automatically set to the defined length dlen (actual length of the text).

7 MODULARIZATION
When you modularize source code, you place a sequence of ABAP statements in a module. Then, instead of
placing all of the statements in your main program, you just call the module. When the program is
generated, the source code in the modularization unit is treated as though it were actually physically
present in the main program.
Need of Modularization
 Improve the structure of the program.
 Easy to read the code
 Easy to maintain the code
 Avoid redundancy and promotes code reuse
Various Modularization Techniques
 Use of Macros
 Use of include files
 Subroutines
 Function Modules
Let’s look into each of them in detail :
7.1 SAP- ABAP Macro
If you want to reuse the same set of statements more than once in a program, you can include them in a
macro.
You can only use a macro within the program in which it is defined, and it can only be called in lines of the
program following its definition.
Macros can be useful for long calculations or complex WRITE statements.
Syntax
DEFINE <macro_name>
'Macro Statements
END-OF-DEFINITION
Macros can use Parameters &N where N = 1,2,3...

Example:-
DATA: number1 TYPE I VALUE 1.
DEFINE increment.
ADD 1 to &1.
WRITE &1.
END-OF-DEFINITION.

Increment number1.
WRITE number1.
Output: 2
7.2 Include Programs
Include Programs are solely for modularizing source code, and have no parameter interface. Include
programs allow you to use the same source code in different programs. They can be useful if you have
lengthy data declarations that you want to use in different programs.
Points to Note
Include programs cannot call themselves.
Include programs must contain complete statements.
Example:
INCLUDE ZILX0004.
WRITE: / 'User', SY-UNAME,/ 'Date', SY-DATUM.
================================
PROGRAM ZRPM0001.
INCLUDE ZILX0004.
7.3 Subroutines
Subroutines are procedures that you can define in any ABAP program and also call from any program.
Subroutines are normally called internally, that is, they contain sections of code or algorithms that are used
frequently locally. If you want a function to be reusable throughout the system, use a function module.
Syntax-
FORM <Subroutine> [<pass>].
<Statement block>.
ENDFORM.
<Subroutine> = Name of the subroutine
<pass> = Parameters being passed
Types of Subroutines
Internal
Subroutine defined in same program being called.
Can access all the data objects declared in the main ABAP/4 program.
External
Subroutine defined outside the program being called.
Need to use the <pass> option or declare data objects in common parts of memory.

Calling a Subroutine Internal Subroutines
PERFORM <subroutine> [<pass>]
<subroutine> = Name of the subroutine
<pass> = Parameters being passed
Data declared in main program is automatically available.
External Subroutines
PERFORM <subroutine>(<Program>) [<pass>].
PERFORM <subroutine> (<Program>) [<pass>] [IF FOUND].
PERFORM (<subroutine>) IN PROGRAM (<Program>) [<pass>] [IF FOUND].
PERFORM <index> OF <subroutine1> <subroutine2> <subroutine3> [<pass>].

Points to Note
Nested calls are allowed in subroutines (i.e. PERFORM within a FORM ... ENDFORM ).
Recursive calls are also possible.
To define local data, use the DATA statement after FORM . Each time you enter the subroutine, the data is
recreated (with an initial value) and released at the end (from the stack).
To define global data used within a subroutine, use the LOCAL statement after FORM . The values are saved
when you enter the subroutine and then released at the end (from the stack)
7.4 Function Modules
Function Modules are general purpose ABAP/4 routines that anyone can use. In fact, there are a large
number of standard function Modules available.
Function Modules are organized into Function Groups: Collections of logically related functions. A Function
module always belongs to a Function Group.
Syntax-
FUNCTION <function module>
<Statements>
ENDFUNCTION.
Important information Associated with Function Module
Administration
Import/Changing/Export parameters.
Table Parameters/Exceptions.
Documentation
Source code - L<fgrp>U01 . <fgrp> is the Function Group
Global Data - L<fgrp>TOP .Global data for the function group- Accessible across function modules in the
function group.
Main Program - SAPL<fgrp> . Contains the list of all the include files for that function group

Call a Function Module
To call a function module, use the CALL FUNCTION statement:

CALL FUNCTION <module>
[EXPORTING f1 = a 1.... f n = a n]
[IMPORTING f1 = a 1.... f n = a n]
[CHANGING f1 = a 1.... f n = a n]
[TABLES f1 = a 1.... f n = a n]
[EXCEPTIONS e1 = r 1.... e n = r n [ERROR_MESSAGE = r E]
[OTHERS = ro]].
7.5 Function Groups
Function groups are containers for function modules. Infact, there are a large number of standard Function
Groups. All of the function modules in a function group can access the global data of the group.
Like executable programs (type 1) and module pools (type M), function groups can contain screens,
selection screens, and lists.
Points to Note
Function Groups cannot be executed.
The name of a function group can be up to 26 characters long.
When you create a function group or function module, the main program and include programs are
generated automatically.
Function groups encapsulate data.
How to create a Function Group
Goto Transaction SE80.
Select Program in the DropDown.
Write the name of the Function Group That you want to create. Generally User made Function groups start
with "Z". e.g. - <Z_FUNCTION_GROUP_NAME> . Hit Enter Key.
Note that The TOP Include is create by default if the user checks the option of creating a TOP include.
How to create a Function Module

Create a function Group (say "ZCAL").
Create a function module, set the attributes like (Function group, Application, Short Text and Process Type)
and Save.
Include file "LZCALU01" will have source code of first function module.
Include file "LZCALTOP" will have global data.
Main program "SAPLZCAL" contains
Global data Include file "LZCALTOP"
Function modules include file "LZCALUXX"
User defined Include files "LZCALF..", "LZCALO.." and "LZCALI.."
Define interface parameters and Exceptions
Write the source code
Activate Function Module
Testing the Function Module - Single Test & Debugging
Documenting and Releasing a Function Module
That's all to Modularity in ABAP.
OPTIONS FOR USING MODULARIZATION UNITS
A modularization unit is a part of a program, which encapsulates a particular function.

Storing a part of the source code in a module
improves the transparency of the program, as the program is now more function-oriented;
enables the encapsulated function in the program to be reused several times; and
saves the trouble of reimplementing the entire source code on each occasion.
Modularization also makes it easier to maintain programs, as you do not need to make changes to the
function at various points in the main program, but only in the particular modularization units.
LOCAL PROGRAM MODULARIZATION

You can carry out local program modularization in two ways:
Performing subroutines, also known as form routines
Calling methods in local classes

These modularization units are only available in the program in which they are implemented and no other
program must be loaded to the user context at runtime. Local classes, methods, and subroutines can have
the same name in different programs. This will not result in any conflicts, as the source code for the
programs is handled separately in the main memory of the application server.
GLOBAL MODULARIZATION
The two techniques of global modularization in the ABAP programming language involve the use of
function modules that are organized in function groups; and
methods in global classes.

A function group is a collection of function modules, which have similar functions and process the same
data.
Any number of programs can use these globally defined modularization units at the same time. The
units are stored centrally in the Repository and loaded when called into the context of the calling
program.

SEPARATING DATA
The modularization units that are called should not use the data objects of the calling program directly.
Conversely, the data in the modularization units should also not be changed directly by the calling program.
This principle is known as data encapsulation.
Data encapsulation is an important aid in developing a transparent and maintainable source code.
DATA TRANSPORT BETWEEN THE PROGRAM AND THE MODULARIZATION UNIT
Parameters are used to exchange data between the program and the module.
The total number of parameters in a modularization unit is termed interface or signature.
Parameters can be of three types:
Importing parameters are used to pass data to the modularization unit. Exporting parameters return data
from the modularization unit to the caller. Changing parameters are used not only to pass data to the
modularization unit, but also to return the data after it is changed.

SIMPLE EXAMPLE OF A SUBROUTINE
A subroutine is a modularization unit within a program. It normally uses values from data objects and
returns values too. A subroutine is introduced within a FORM and an ENDFORM statement. The PERFORM
statement is used for calling a subroutine.
PASSING PARAMETERS - VISIBILITY OF GLOBAL VARIABLES
The variables defined in the main program are visible globally within the program and can be changed at
any point during the entire program. This means that subroutines that are defined within the main program
can change them too.

PASSING PARAMETERS - DEFINING AN INTERFACE
Placeholders – called formal parameters – are used to call a subroutine with different data objects for each
situation.
When the subroutine is called, the required global variables replace these placeholders, which together
form the subroutine interface.
When the subroutine is called, its processing must be referenced to real variables. Therefore, the formal
parameters must be specialized by means of the corresponding global variables, which are called actual
parameters. This assignment of actual parameters to formal parameters when calling a subroutine is
called parameter passing.
WAYS OF PASSING INTERFACE PARAMETERS
The way in which main program variables are passed to the formal parameters of the subroutine is called
the pass type.
There are three pass types for subroutines:
Call by value is the pass type you use to make the value of a global variable available to the subroutine in
the form of a variable copy.
However, creating copies especially for large internal tables can be time-consuming.

Call by value and result is the pass type you use to transfer the value of a global variable to the subroutine.
You then write the result or the fully processed final value of the copy back to the original. However, it can
be time-consuming to create copies and write back values especially for large internal tables.
Call by reference is the pass type you use if you want to run subroutine processing directly on the specified
actual parameter. It is a useful way of avoiding the time-consuming creation of copies for large internal
tables.
DEFINING AND CALLING SUBROUTINES
A subroutine is structured within a FORM and an ENDFORM statement.

You specify the name and the interface of the subroutine after FORM, after which the statements of the
subroutine follow.
In the interface definition, you list the formal parameters of the subroutine, such as f1, f2, and f3 and the
required pass type is specified for each parameter.
For call by value, list each of the formal parameters with the VALUE prefix under USING.
For call by value and result, list each of the formal parameters with the VALUE prefix under CHANGING.
For call by reference, list each of the formal parameters without the VALUE prefix under CHANGING.
The order of specification determines the assignment of the actual parameters to the formal parameters. In
the graphic, a is passed to f1; b to f2; and c to f3.

TYPING THE INTERFACE PARAMETERS
Generic typing of a parameter occurs when a formal parameter is either typed using TYPE ANY or not typed
at all.
Actual parameters of any type can be transferred to such a parameter.
At runtime, the type of the actual parameter is determined and assigned to the formal parameter when the
subroutine is called. This is called type inheritance. However, there is danger of atype conflict, and
a runtime error may occur.
Concrete or exact typing of a formal parameter involves specifying a global or built-in type in the TYPE
addition. You use this typing method to determine that only actual parameters of the specified type can be
passed to the subroutine.
TYPING THE INTERFACE PARAMETER FOR STRUCTURE AND INTERNAL TABLES
Formal parameters for data objects, such as structures and internal tables, must always be typed. This
ensures that their components can be accessed within the subroutine.

VISIBILITY OF GLOBAL AND LOCAL DATA OBJECTS
Global data objects

are the variables defined in the main program called; and
are visible in the entire main program and in every subroutine called;
In contrast, local data objects are the local variables defined within a subroutine: they exist only in that
subroutine, just like the formal parameters.
SYNTAX EXAMPLE: LOCAL AUXILARY VARIABLES FOR ROUNDING
In the syntax example, you should round off the result of the percentage calculation internally to the
nearest whole number with one decimal place. However, it should be returned with two decimal places.

IMPLEMENTING A SUBROUTINE CALL
You must generate the PERFORM-statement for calling a subroutine into your source code.
You define the subroutine and then save your main program.
The newly defined subroutine appears in the navigation area.
You can now move it to the required call point in your program by drag and drop.
In the final step, replace the formal parameters in the generated source code with corresponding actual
parameters.
SUBROUTINE IN DEBUGGING MODE
You can execute the entire subroutine without stopping by choosing Execute.

Alternatively, you can use Single Step to stop at the first statement of the subroutine and trace its
operations in more detail.
You can execute the rest of the subroutine (if the current statement is located in a subroutine) without
stopping by choosing Return. Processing only stops after the subroutine is complete.
DEBUGGING - CALL STACK
Under the Standard tab page in the Debugger you can see from which programs the subroutine was
called. The tool for this is the Call Stack.
FUNCTION GROUP

A function module is a subroutine, which has a corresponding function stored centrally in the Function
Library of the SAP system. It has an interface with parameters for importing or exporting data.
A function group is a collection of function modules that have similar functions or process the same data.
A function group can contain the same components as an executable program:
Data objects, for example, are global in relation to the function group and can be changed by all function
modules within the group. Subroutines and Screens are also examples of components, which can also be
called from all function modules in the group.
FUNCTION MODULE
The main advantage of function modules is their reusability.

Here we examine the components of a function module:
The properties of a function module include a short description and the function group it belongs to.

Like subroutines, a function module contains its own local type and data object definitions within
itself.
The third component – interface – of a function module itself comprises more components or elements:
Import parameters, which are optional, need not be supplied with data during the call. Values or
variables of the calling program can be transferred to these when the function module is called.
Export parameters are also always optional. The calling program accepts the output of the function
module by assigning a “receiving variable” to an export parameter.
Changing parameters enable you to transfer the variables of the calling program, which were changed
by the function module, to these parameters.
Exceptions are raised by the function module when errors occur. They provide information on the
relevant processing error in the function module. Exceptions should be handled by the calling program.

DATA OBJECTS WITHIN A FUNCTION GROUP
If a program calls a function module, the entire function group containing that module is loaded. This
function group remains loaded in the working memory until the calling program is closed.
Consequently, if another function module of this group is called, it is processed at once. There is no need to
reload this module, as the same global data can be accessed from the function group. Thus if a function
module that writes values to the global data of the function group is called, then the other function
modules in the group can also access this data when they are called in the same program run.
SEARCHING FOR FUNCTION MODULES
You can search for function modules in many ways:

The application-related search through the application hierarchy helps you search for function modules
within one or more application components.
The application-independent search or free search through the Repository Information System helps

you locate function modules that are independent of application components.
The program-related search enables you to search for a function module that is called within an existing
program.
FUNCTION MODULE INTERFACE
The interface of the function module comprises the import, export, and changing parameters, and the
exceptions. It is mandatory for the nonoptional parameters to be supplied with data when the function
module is called.
DOCUMENTATION AND TEST ENVIRONMENT
Function modules that are intended and released for use in other programs should be documented.
Function module documentation describes the function of the module. Parameter documentation tells
you how individual parameters or exceptions are used.
You can access the function module documentation by choosing Module Documentation.
You can test the output of the function module in the test environment prior to installing it in your
program. An input template allows you to specify values for the import and changing parameters. If the
function module triggers an exception due to an error situation, it is displayed with its message text.
CALLING A FUNCTION MODULE
Function modules are called using the CALL FUNCTION statement.

In the EXPORTING block, the system passes values to the import parameters of the function module.
In the IMPORTING block of the call, actual parameters are assigned to the export parameters and can be
used to access the results of the call.
In the call syntax you always specify the name of the interface parameter (formal parameter) on the left
side of the parameter assignment and the data object or the value of the calling program (actual
parameter) on the right side.
CREATING SOURCE CODE FOR A FUNCTION MODULE CALL
You can choose Pattern to generate a function module call in the source code. Alternatively, you can
display the function group in the navigation area and drag and drop into the editor area to generate the call
in the source code. You must then fill in the actual parameters and, if necessary, implement exception
handling.

HANDLING EXCEPTIONS
The function module raises the corresponding exceptions in case of any application error. This causes the
processing of the function module to be cancelled and the system returns to the calling program.
If the exception is listed in the EXCEPTIONS block of the call, the specified return code is entered in the sy-
subrc system field of the calling program.
CREATING A FUNCTION GROUP
Some steps are involved in the creation of a function group:

Select the object list for a function group in the Object Navigator.
Enter the name of the new function group; choose ENTER or Display; and confirm the creation of the
new function group in the resulting dialog box.
Next, a dialog box with the attributes of the function group appears.
Enter a short text and choose Save.

Assign the function group to a package.
CREATING A FUNCTION MODULE
Creating a function module involves several steps:

Choose the function group where you want to create the new function module.
Display the object list for the function group in the navigation area of the Object Navigator.
In the hierarchical tree structure, open the context menu for the function group and
choose Create → Function Module.
In the resulting Create Function Module dialog box, enter a name and a short text for the function
module.
Click Save.
Assign the function module to a package.
EDITING THE SOURCE CODE

You can switch to the Source Code tab page in order to implement the functions of the function module
after defining the corresponding IMPORTING and EXPORTING parameters.
BUSSINESS OBJECTS AND BAPIs
The Business Object Repository (BOR) in the SAP system contains business objects.
A business object is a class and corresponds to an SAP table or a table hierarchy. It has BAPIs (Business
Application Programming Interfaces) as methods to access the data in the SAP system.
BAPIs are used for basic functions of a business object, such as
creating an object;
retrieving the attributes of an object;
changing the attributes of an object; and
listing the objects.
USING BAPIs

The functions of a BAPI are encapsulated in a function module that can be called remotely by ABAP
programs of the same SAP system, as well as by external programs.
STANDARD BAPIs
You can access standard methods in the form of BAPIs with standardized names:
GetList returns a list of available objects that meet the specified selection criteria.
GetDetail returns the detailed information or attributes for an object. Note that you must specify the
complete key.
Create, Change, Delete, Cancel is a BAPI that allows you to create, change, and delete objects.
AddItem, RemoveItem is another example of a BAPI. This helps you to add and remove subobjects.
BAPIs EXPLORER
You can use the BAPI Explorer to list business objects and their BAPIs with reference to the application.
You can call the BAPI Explorer using the path:
SAP Easy Access menu → Tools → Business Framework→ BAPI Explorer.
You can display the relevant details of the required business object or BAPI in the work area by selecting
the BAPI. You can then navigate to the Function Builder by double-clicking the displayed function
module.

PROPERTIES OF A BAPI FUNCTION MODULE
BAPI function modules have certain technical requirements:

The naming convention should beBAPI_<business_object_name>_<method_name>.
It should be remote enabled.
It cannot contain any user dialogs or messages.
The interface parameters are typed with components of structures from the ABAP Dictionary that
were created for this BAPI. The name prefix for such structures should be BAPI_.
It must not contain any changing parameters until release 4.6.
The special export parameter RETURN helps report the errors to the user.
BAPI CALL IN AN ABAP PROGRAM

In order to use a BAPI within the same SAP system, you call the relevant function module directly.
Conversion or reconversion is done by using the function modules from the BACV function group
(package SBF_BAPI).

8 Object Oriented Programming
The object-oriented enhancements to ABAP include global classes that make functions available in the form
of methods.
The methods have an interface, which is known as a signature. The signature comprises import, export, and
changing parameters and exceptions.
Classes also have other components, such as global data objects known as attributes. All the methods of a
class can access the attributes of that class.
EXAMPLE OF THE ACCESS OPTIONS FOR A GLOBAL CLASS
Attributes are normally encapsulated in the class and can only be read or changed by using the methods of
the same class. In contrast to function modules, classes allow you to make specific attributes visible to the
users of the class by defining public and private attributes. This distinction can also be applied to

methods. The public methods are available outside the class and the private methods can only be
called by other methods of the same class.
CLASSSES AND OBJECTS
We can pinpoint the major differences between global classes and function groups:
A function group with its global data objects can only be loaded once to the program context.
A global class can be loaded many times. This describes the multiple instantiation of the class.
The values in the global data objects of a function group are the same for all function module calls.
Because of multiple instantiation, a global class can have several instances known as objects, as
well as different attribute values. Consequently, a method can access different values in the attributes,
depending on the instance for which it was called.
DEFINITION OF ATTRIBUTES
Attributes that can have a different value for each instance are known as instance attributes.

In contrast, static attributes exist only once for each program context, regardless of how many class
instances are generated.
You can choose the Attributes tab to open the list of the attribute definitions in the class.
DEFINITION OF METHODS
A static method can be called directly without generating an instance of the class. In contrast, with the
instance method, you first generate an instance and then call the method specifically for this instance. You
can choose the Methods tab to open the list of all method definitions in the class.
METHOD PARAMETERS
The parameters for a method can be accessed from the method list by placing the cursor on the required
method and selecting the Parameter option. Unlike in function modules, there is no separate list for
export, import, and changing parameters. Hence, the parameter type is entered in the Type column
instead.

METHOD EXCEPTIONS
You can display the exceptions for a method by placing the cursor on the required method and selecting
the Exceptions option. Class-based exceptions were introduced with Basis release 6.10. A method can
either raise new class-based exceptions or classic exceptions, but not both together. The new exception
concept requires that you specify the names of the exception classes in it; whereas, the classic exception
concept allows you to choose any exception identifier.
THE CLASS BUILDER TESTING ENVIRONMENT
Methods can be tested by selecting the Execute Method option. You need not generate an instance to
test a static method – you can execute a static method immediately. After you choose the Execute option,
the importing parameters if any, appear on the screen. You should supply the parameters with values. On
testing the method, the result of the exporting parameter will be displayed.

METHOD CALLS USING DRAG AND DROP
The CALL METHOD statement is used to call methods. You can select a method name in the navigation
area and drag it to the editing area. For static methods, you then specify the name of the class and method,
separated by the so-called static component selector the “=>”. The parameters are then passed in an
EXPORTING block and an IMPORTING block. You can, alternatively, select the Pattern option to find
the Call Method option under ABAP Objects Pattern.
HANDLING EXCEPTIONS: CLASSIC EXCEPTIONS

A return code is assigned to the exception in the EXCEPTIONS block of the method call. This return code is
placed in the system field sy-subrc when the method terminates with this classic exception. The calling
program can then react to the exception by querying sy-subrc.
HANDLING EXCEPTIONS: CLASS BASED EXCEPTIONS
In class-based exceptions, the call must be bound between the TRY and ENDTRY statements. The processing
block that begins with the CATCH <exception class> statement handles the actual exception. The exception
class that is to be handled is denoted by <exception class> The processing is terminated and the system
branches directly to the relevant CATCH block if the corresponding exception is raised somewhere within
the TRY–ENDTRY block.
HANDLING EXCEPTIONS WITH EXCEPTION CLASSES
The statements for handling the class-based exceptions are generated when a method is called by drag and
drop or by using Pattern, You can then remove the comments and implement the CATCH blocks.

CREATING OBJECTS AND CALLING METHODS
Reference variables are defined to generate and address instances of classes. They act as pointers that can
be directed to corresponding instances. They are defined by the statement, DATA gr_ref_name TYPE REF
TO class_name.
Once the reference variable is used to create an instance, it no longer holds the initial value and points to
that instance.
An instance of the class specified in the definition of the reference variables can be generated by the
statement, CREATE OBJECT gr_ref_name.
You can call the methods of an instance using the statement, CALL METHOD gr_ref_name->method_name.
CREATING GLOBAL CLASSES IN THE OBJECT NAVIGATOR
To create a global class, you can open the context menu for your package in the navigation area and
choose Create → Class Library → Class.
You then enter a short description and several other properties, along with the name of the class in the
resulting dialog box.

You can also choose Class/Interface from the dropdown list in the navigation area, to enter the name of
the new class. When you click Display, you confirm that you want to create this new class.
CALLING THE SOURCE CODE EDITOR
You can implement the source code for a method by selecting the method in the method list and choosing
the Source Code option. It is usually written between the METHOD <method_name> and the ENDMETHOD
statements.
SHOWING THE SIGNATURE IN THE SOURCE CODE EDITOR
The signature for the method can be displayed while editing the source code by selecting
the Signature option.

DEFINING A LOCAL CLASS
A class consists of the definition and the implementation blocks. The definition block comprises the
attributes and the signatures of the methods; whereas, the implementation block contains the source code
of the methods. The CLASS ...ENDCLASS statement defines local object types. The visibility sections, such as
PUBLIC SECTION and PRIVATE SECTION, are mentioned in the definition block.
SYNTAX FOR STATIC METHODS
When methods are called by a program, they can receive values from it – as well as pass the values back to
it – using a signature. There can be any number of IMPORTING, EXPORTING, and CHANGING parameters.
All parameters can be passed as values or as references.
You can define a return value using the RETURNING parameter; whereas, you cannot define any
EXPORTING and CHANGING parameter.

IMPLEMENTING AND USING STATIC METHOD
You can define a local class lcl_compute with a static method get_percentage in the definition block. The
method is then implemented in the implementation block. The static method call from the main program is
identical to a static method call in a global class.
Abap data dictionary:
SQL can be divided into following 2 parts.

 DML – Data Manipulation Language
 DDL – Data Definition Language
DML part consists of query and update commands like SELECT, UPDATE, DELETE, INSERT etc. ABAP
programs handle DML part of SQL.
DDL part consist of commands like CREATE TABLE, ALTER TABLE, DROP TABLE, CREATE INDEX etc. ABAP
Dictionary handles DDL part of SQL.
So ABAP Dictionary is used to create and manage data definitions (metadata). ABAP Dictionary is used to
create Tables, Data Elements, Domains, Views, and Lock Objects etc.
While creating a table in data dictionary each table field is assigned to a data element. Each data element is
in turn assigned to a domain.
Domain describes the technical attributes such as data type and length of a table field.
Data Element gives the field labels and documentation for the table field.
Consider the following code. PARAMETERS is the keyword to create input fields.
PARAMETERS: p_matnr TYPE matnr.

Output
In order to get the field labels use the menu in the ABAP editor GOTO->Text Elements->Selection Texts.

All the input fields will be displayed in a table.
Just check the Dictionary Ref checkbox and press enter.
The Text ( Field Label ) will be automatically read from the Data Element. Now save, activate, go back and
run the program again.
Now place the cursor on the input field and press F1 key to get the documentation from the data element.

Actually this field label and documentation are maintained in the Data Element MATNR.
So if we want to create a table with two fields as “FirstName” and “SecondName”, then only one domain is
sufficient with data type as “CHAR” and length say 20. But we need two different data elements in order to
display different field labels and documentation for both the fields.
Subroutines are procedures that we define in an ABAP program and can be called from any program.
Subroutines are normally called internally, i.e. called from the same program in which it is defined. But it is
also possible to call a subroutine from an external program. Subroutines cannot be nested and are usually
defined at the end of the program.
A subroutine can be defined using FORM and ENDFORM statements.
FORM <subroutine name>.

...
ENDFORM.
A subroutine can be called using PERFORM statement.
PERFORM <subroutine name>.
Example Program.
PERFORM sub_display.
WRITE:/ 'After Perform'.
*&---------------------------------------------------------------------*
*& Form sub_display

*&---------------------------------------------------------------------*
FORM sub_display.
WRITE:/ 'Inside Subroutine'.
ENDFORM. " sub_display
Output
Subroutines can call other subroutines and may also call themselves. Once a subroutine has
finished running, the control returns to the next statement after the PERFORM statement.
We can terminate a subroutine by using the EXIT or CHECK statement.
EXIT statement can be used to terminate a subroutine unconditionally. The control returns to the
next statement after the PERFORM statement.
WRITE:/ 'After Perform Statement'.
*&---------------------------------------------------------------------*
*& Form sub_display
*&---------------------------------------------------------------------*
FORM sub_display.
WRITE:/ 'Before Exit Statement'.
EXIT.
WRITE:/ 'After Exit Statement'. " This will not be executed
Output
CHECK statement can be used to terminate a subroutine conditionally. If the logical expression in
the CHECK statement is untrue, the subroutine is terminated, and the control returns to the next
statement after the PERFORM statement.
DATA: flag TYPE c.

DO 2 TIMES.

ENDDO.
WRITE:/ 'After Perform Statement'.
*&---------------------------------------------------------------------*
*& Form sub_display
*&---------------------------------------------------------------------*
FORM sub_display.
WRITE:/ 'Before Check Statement'.
CHECK flag NE 'X'.

WRITE:/ 'Check Passed'.
flag = 'X'.
Include programs are not standalone programs and cannot be executed independently. They can
be used as a container for ABAP source code. They are used to organize the ABAP source code into
small editable units which can be inserted at any place in other ABAP programs using the INCLUDE
statement. Include programs can be used in different programs. The include statement copies the
contents of the include program into the main program.
Include programs have no parameter interface and they cannot call themselves.
While creating the INCLUDE program using the ABAP editor choose program type as "I" i.e.
INCLUDE program in the program attributes.

Syntax for Include program is as follows.
INCLUDE <Include Program Name>
Source code of ZINCLUDE_DATA.
DATA: g_name(10) TYPE c.
Source code of ZINCLUDE_WRITE.
WRITE:/ 'Inside include program'.
Source code of main program.
REPORT zmain_program.
INCLUDE zinclude_data.
WRITE:/ 'Main Program'.
INCLUDE zinclude_write.
Output
Function module – assigned to a function group

f.g can have many f.m

9 COMPLEX DATA OBJECTS
DEFINITION OF STRUCTURES WITH GLOBAL TYPES
You can define structured data objects in ABAP. They are also called structure variables or
simply structures. Structures allow you to combine values that belong together logically into one data
object.
Structures can be nested. Consequently, components can comprise more structures or even internal tables.
In the program, structure variables are defined with the DATA statement, in the same way as elementary
data objects.
When you set the types, you can refer either to
a Dictionary structure; or
a structure type that is locally declared in the program.
An Internal table is a temporary table gets created in the memory of application server during program
execution and gets destroyed once the program ends. It is used to hold data temporarily or manipulate the
data. It contains one or more rows with same structure.
An internal table can be defined using the keyword TABLE OF in the DATA statement. Internal table can be
defined by the following ways.
TYPES: BEGIN OF ty_student,
id(5) TYPE n,
name(10) TYPE c,
END OF ty_student.
DATA: gwa_student TYPE ty_student.
"Referring to local data type

DATA: it1 TYPE TABLE OF ty_student.
"Referring to local data object
DATA: it2 LIKE TABLE OF gwa_student.
"Referring to data type in ABAP dictionary
DATA: it3 TYPE TABLE OF mara.

Use the APPEND statement to add data to internal table. First define the work area i.e. define a field string
with a structure similar to row of the internal table. Then place the data in the work area and use the
APPEND statement to add the data from work area to internal table.
*--------------------------------------------------------------*
*Data Types
*--------------------------------------------------------------*
TYPES: BEGIN OF ty_student,
id(5) TYPE n,
name(10) TYPE c,
END OF ty_student.
DATA: gwa_student TYPE ty_student.
*--------------------------------------------------------------*
*Data Declaration
*--------------------------------------------------------------*
"Referring to local data type
DATA: it TYPE TABLE OF ty_student.
gwa_student-id = 1.
gwa_student-name = 'JOHN'.
APPEND gwa_student TO it.
gwa_student-id = 2.
gwa_student-name = 'JIM'.
gwa_student-id = 3.
gwa_student-name = 'JACK'.
After the last APPEND statement in the above program, internal table ‘IT’ has the following 3 entries. But
the internal table values are not persistent i.e. the internal table and its values are discarded once the
program ends.
ID NAME
1 JOHN
2 JIM
3 JACK
Usually internal tables are used to hold data from database tables temporarily for displaying on the screen
or further processing. To fill the internal table with database values, use SELECT statement to read the
records from the database one by one, place it in the work area and then APPEND the values in the work
area to internal table.

DATA: gwa_employee TYPE zemployee,
gt_employee TYPE TABLE OF zemployee.
SELECT * FROM zemployee INTO gwa_employee.

APPEND gwa_employee TO gt_employee.
ENDSELECT.
After ENDSELECT the internal table GT_EMPLOYEE contains all the records that are present in table
ZEMPLOYEE.
Using INTO TABLE addition to SELECT statement we can also read multiple records directly into the internal
table directly. No work area used in this case. This select statement will not work in loop, so no ENDSELECT
is required.
SELECT * FROM zemployee INTO TABLE gt_employee.
We can insert one or more lines to ABAP internal tables using the INSERT statement. To insert a
single line, first place the values we want to insert in a work area and use the INSERT statement to
insert the values in the work area to internal table.
Syntax to insert a line to internal table
INSERT <work area> INTO TABLE <internal table>.

OR
INSERT <work area> INTO <internal table> INDEX <index>.
The first INSERT statement without INDEX addition will simply add the record to the end of the internal
table. But if we want to insert the line to specific location i.e. if we want to insert it as second record then
we need to specify 2 as the index in the INSERT statement.
MODIFY is the statement to change single or multiple lines in an internal table. Use the INDEX addition to
change a single line. If we use the INDEX addition and the operation is successful, SY-SUBRC will be set to
zero and the contents of the work area overwrites the contents of the line with the corresponding index.
Instead of changing all the values of a row we can specify the fields we want to change by specifying the
fieldnames in the TRANSPORTING addition.
MODIFY <internal table> FROM <work area> [INDEX <index>]

[TRANSPORTING <f1> <f2> ... ].
We can also use the above MODIFY statement without INDEX addition inside LOOP. Inside LOOP if we do
not specify the INDEX, then the current loop line will be modified.
We can use the WHERE clause to change single or multiple lines. All the lines that meet the logical
condition will be processed. If at least one line is changed, the system sets SY-SUBRC to 0, otherwise to 4.
MODIFY <internal table> FROM <work area>

TRANSPORTING <f1> <f2> ... WHERE <condition>.
DELETE is the statement to delete one or more lines from an ABAP Internal Table. Use the INDEX addition
to delete a single line. If we use the INDEX addition and the operation is successful, SY-SUBRC will be set to
zero, the line with the corresponding index in the internal table will be deleted and the indexes of the
subsequent lines will be reduced by one.

DELETE <internal table> [INDEX <index>].
We can also use the above DELETE statement without INDEX addition inside LOOP. Inside
LOOP if we do not specify the INDEX, then the current loop line will be deleted.
We can use the WHERE clause to delete single or multiple lines. All the lines that meet the logical
condition will be deleted. If at least one line is deleted, the system sets SY-SUBRC to 0, otherwise
to 4.
DELETE <internal table> [FROM <n1>] [TO <n2>] [WHERE <condition>].
With WHERE clause we can also specify the lines between certain indices that we want to delete by
specifying indexes in FROM and TO additions.
DESCRIBE TABLE is the statement to get the attributes like number of lines, line width of each
row etc. of the internal table. DESCRIBE TABLE statement also fills the system fields SY-TFILL
(Current no. of lines in internal table), SY-TLENG (line width of internal table) etc.
DESCRIBE TABLE <internal table> [LINES <lines>].
SORT is the statement to sort an ABAP internal table. We can specify the direction of the sort using
the additions ASCENDING and DESCENDING. The default is ascending.
SORT <internal table> [ASCENDING|DESCENDING]
We can also delete the adjacent duplicates from an internal table by using the following statement.
DELETE ADJACENT DUPLICATE ENTRIES FROM <internal table>

[COMPARING <f1> <f2> ... |ALL FIELDS].
COMPARING ALL FIELDS is the default. If we do not specify the COMPARING addition, then
the system compares all the fields of both the lines. If we specify fields in the COMPARING
clause, then the system compares only the fields specified after COMPARING of both the lines. If
at least one line is deleted, the system sets SY-SUBRC to 0, otherwise to 4.
Control break processing is used to execute a piece of code whenever a specific condition in the
data is detected during the processing of internal table loop.
The following control break statements are available within LOOP and ENDLOOP.
AT FIRST / ENDAT
AT LAST / ENDAT
AT NEW / ENDAT
AT END OF / ENDAT
SUM
ON CHANGE OF / ENDON
The code between AT NEW and ENDAT is executed only during the first loop pass. So it is used to
write the headers or some other initialization processing.
The code between AT LAST and ENDAT is executed only during the last loop pass. So it is used to
write the totals or some report footers.
*————————————————————–* *Data Declaration *——————————
——————————–*
DATA: gwa_spfli TYPE spfli.

DATA: gt_spfli TYPE TABLE OF spfli.
*UP TO 5 ROWS addition selects only 5 rows from table SPFLI
SELECT * UP TO 5 ROWS FROM spfli INTO TABLE gt_spfli.
LOOP AT gt_spfli INTO gwa_spfli.
AT FIRST.
WRITE:/ 'Start of Loop'.

WRITE:/ 'Flight Details'.
WRITE:/ 'Airline Code' COLOR 5,14 'Connection No.' COLOR 5,
29 'Departure City' COLOR 5, 44 'Arival City' COLOR 5.
ULINE.
ENDAT.
WRITE:/ gwa_spfli-carrid,14 gwa_spfli-connid,

29 gwa_spfli-cityfrom,44 gwa_spfli-cityto.
AT LAST.
ULINE.
WRITE:/ 'End of Loop'.
ENDAT.
ENDLOOP.
In AT FIRST and AT LAST event blocks the numeric values in the work area contains zeros. SUM statement
calculates the totals of numeric fields and places the totals in the corresponding fields of work area.
In AT NEW and AT END OF event blocks SUM statement finds all the rows within the control level and
calculates the totals of numeric fields that are right to the control level and places the totals in the
corresponding fields of work area.
*————————————————————–* *Data Declaration *—————————————————
———–*

AT FIRST.
29 'Departure City' COLOR 5, 44 'Arival City' COLOR 5,

58 'Distance' COLOR 5.
ULINE.
ENDAT.
AT NEW carrid.
WRITE:/ gwa_spfli-carrid, ' : New Airline'.
ULINE.
ENDAT.
WRITE:/14 gwa_spfli-connid,29 gwa_spfli-cityfrom,
44 gwa_spfli-cityto,58 gwa_spfli-distance.
AT END OF carrid.
ULINE.
SUM.
WRITE:/ gwa_spfli-carrid,58 gwa_spfli-distance.
ULINE.
ENDAT.
AT LAST.
SUM.
WRITE:/ 'Total',58 gwa_spfli-distance.
WRITE:/ 'End of Loop'.
ENDAT.
ENDLOOP.
Output
ON CHANGE OF behaves similar to AT NEW. The syntax is as follows.

ON CHANGE OF <control level1> [or <control level2> . .].
[ELSE.]

ENDON.
*————————————————————–* *Data Declaration *—————————————————
———–*

AT FIRST.
29 'Departure City' COLOR 5, 44 'Arival City' COLOR 5,
58 'Distance' COLOR 5.
ULINE.
ENDAT.
ON CHANGE OF gwa_spfli-carrid. WRITE:/ gwa_spfli-carrid, ‘ : New Airline’. ULINE. ENDON.
WRITE:/14 gwa_spfli-connid,29 gwa_spfli-cityfrom,
44 gwa_spfli-cityto,58 gwa_spfli-distance.
ENDLOOP.
Output
Below table summarizes the differences between AT NEW and ON CHANGE OF statements.
AT NEW ON CHANGE OF
It can be used only in AT It can be used in any loop like

LOOP statement. SELECT, DO etc..
Only one control field can be Multiple control fields

used. separated by OR can be used.

AT NEW is triggered when a ON CHANGE OF is not
field left to control level triggered when a field left to
changes. control level changes.
Values in the fields to the Values in the fields to the

right of control level contains right of control level contains
asterisks and zeros. original values.
ELSE addition cannot be ELSE addition can be used.

used.
Changes to work area with Changes to work area with

AT NEW will be lost. ON CHANGE OF will not be
lost.
Internal tables:
Three properties
1. Line type – usually a structure
2. Primary key – can be unique or non uniquye, but unique preferred
3. Table kind – standard or sorted or hashed
4. standard is accessed by index, key is non unique
5. sorted is accessed by index or key, key is either unique or non unique
6. hashed is accessed only by key, key is unique
7. hashed is used when internal table is very large and you want to access by key only
8. table types can be defied globally in abap dictionary or locally within the program
DEFINING STRUCTURES WITH LOCAL TYPES
The TYPES statement can be used to define local structure types.

The statement begins with the TYPES keyword and includes the components within the respective start and
end phrases:
TYPES: BEGIN OF and END OF .
You can also define a structured data object directly by replacing the leading key word TYPES with DATA.
The statement now begins with the DATA keyword and includes the relevant components within the

respective start and end phrases:
DATA: BEGIN OF and END OF .
ACESS TO STRUCTURE COMPONENT
This slide depicts how you should always address the components of a structure by using a hyphen, as
in structure_name-component_name.
COPYING STRUCTURE COMPONENTS WITH THE SAME NAME
By using the MOVE-CORRESPONDING statement, you can copy structure components with the same
name from the source structure to the target structure, one component at a time. All the other
components of the structures remain unchanged.
STRUCTURES IN DEBUGGING MODE

To trace the field contents of a structure in the Debugger, first enter the structure name in the Variables
1 area. Conversely, you can copy it from the source code by double-clicking it. You can then display the
components of the structure by double-clicking the structure name in the Variable area.

10 Internal Tables
An internal table is a data object that can hold several identically structured data records at runtime. In
other words, internal tables are a simple way of processing large data sets in a structured manner.
The ABAP runtime system dynamically manages the size of the internal table.
Table rows or table entries are the individual data sets in an internal table. The individual components
in a row are referred to as fields or columns of the internal table.
An internal table is mainly used for
retaining data from database tables or sequential files for future processing;
formatting data for the screen or printer output (for example, sorting); and
formatting data for use in subroutines, function modules, or methods.
ATTRIBUTES OF INTERNAL TABLES
An internal table has three main attributes:

Line Type describes the structure of the table rows. Usually a structure type is used but other data
types are also possible.
Key consists of the key fields, including the order in which they are used. The key can be defined
as unique or nonunique, depending on the access type. Uniqueness means that a particular combination
of key fields can only appear once within the table.

Table Kind can be standard, sorted, and hashed. The use of table kind is based on the
appropriate access type.
ATTRIBUTES AND USE OF THE TABLE KINDS
Index access is used when a table entry is accessed by specifying the corresponding row number.
Key access is used when it is accessed by entering a key value.
With standard tables, the row numbering (or index) is maintained internally. Hence, the index and key
accesses are both possible.
With sorted tables, the data records are automatically sorted in the ascending order of the key fields.
Again, this means that the index is maintained internally and that both index and key accesses are possible.
With hashed tables, fast key access of the data records is enabled by using the hashing procedure.
Therefore, with hashed tables, only key access is possible, using a unique key.
You can consider internal tables like a multi dimensional array in SAP ABAP. It’s a temporary table
created and filled by program execution, ends with Program completion. Internal table contents
are stored in RAM of application server.
Standard internal tables can be accessed via index or key. Index means row number(s). Non unique entries
can be present in the Internal table. Linear search by default is applied when searching/accessing via key.
Standard table declaration:
DATA: it_ekpo type standard table of ty_ekpo.
Sorted internal table contents are sorted and contents can be accessed via index or key, Binary search is
employed when searching via key. Non unique entries can be present.
Sorted Table Declaration
DATA: it_ekpo type sorted table of ty_ekpo with unique key ebeln.
Hashed internal table contents are always unique. Table can be accessed only via key. Hash algorithm is
used to organize the contents .
Hashed Table Declaration
DATA: it_ekpo type hashed table of ty_ekpo with unique key ebeln.
10.1.1 Reading contents of internal table:

Read statement is used to read a single row of internal table. Using this statement alters the value of sy-
subrc and sy-tabix.

Syntax : read <internal_table> into <workarea> <condition>.
Ex: read it_mara into wa_mara with key matnr = 100 binary search.
read it_mara into wa_mara index 2.
After read statement , sy-tabix value will be the row number read and sy-subrc will be 0 if fetching is done.
Index 2 means read the 2nd row of internal table it_mara.
10.1.2 Reading multiple lines in Internal table.

We can use loop to do the same.
10.1.2.1 Loop with Index.

LOOP AT it_mara INTO wa_mara FROM lv_index.
... <processing statements>.....
ENDLOOP.
Loop from row number lv_index.
10.1.2.2 Loop with Where condition.
LOOP AT it_mara INTO wa_mara where matnr = ‘123‘.
ENDLOOP.
Loop in it_mara where matnr value = 123
10.1.2.3 Loop without any index or Where condition
LOOP AT it_mara INTO wa_mara.
ENDLOOP.
sy-tabix holds the current row number being processed .
sy-index is the loop counter.
When the loop is exited with ENDLOOP, sy-tabix is reset to the value it had before the loop was entered. sy-
subrc is 0 (Implying the loop was run at least once) or 4(the loop was not run at all).
10.1.3 Modifying contents of internal table :

'MODIFY' statement changes the content of one or several internal table lines that can be specified using
the table key or the table index
Ex : MODIFY TABLE itab FROM wa TRANSPORTING field1.

Only change field1 taken from work area wa in internal table itab
MODIFY itab INDEX idx FROM wa TRANSPORTING field1.

Mentioning the line number for modification.
MODIFY itab FROM wa TRANSPORTING field2 WHERE field1 = ‘ ‘.

Additional condition apart from the primary fields of wa.
If you are looping through the internal table and modifying the contents , its recommended to use field
symbols instead of work area.
In case of field symbols just use ASSIGNING <fieldsymbolname> instead of into.

EX:
LOOP AT it_mara ASSIGNING <wa_mara> FROM lv_index.

ENDLOOP.
Any changes done on <wa_mara> will be reflected back into the internal table
10.2 Deleting contents of internal table:

DELETE : This statement either deletes one or more rows in internal table, specified with the table key or
table index, or it deletes neighbouring duplicate rows.
DELETE itab INDEX sy-tabix.

Delete the row number specified by sy-tabix
DELETE TABLE itab FROM wa.

Delete all occurrences of row specified by workarea wa from internal table
DELETE TABLE itab WITH TABLE KEY field1 = ‘123 ‘.

Delete all occurrences of row where table key field1='123'
DELETE itab FROM idx.

Delete all rows from line number idx
DELETE itab TO idx.

Delete all rows to line number idx
DELETE itab where field1 = ‘321 ‘.

Delete all occurrences of row where field1='321 '
DELETE ADJACENT DUPLICATES FROM itab COMPARING field1 field2.

Remove duplicates from itab (provided that itab is sorted)
Addition of rows can be done either by using append or insert command. Collect command can also be
used for the same. So what’s the difference between all 3 ? This post will cover it up.
10.3 Append command:

Append is used to add entries to end of the internal table. Append will not work for Hashed tables.
Append will lead to dump in case you try to add entries in improper sort manner in case of sorted tables.
Ex: append wa_mara TO it_mara.

"Append lines of" can be used to append another internal table contents having same structure to the
other internal table.
Ex: APPEND LINES OF it_mara2 to it_mara.
10.4 Insert command:

Insert is used to add entries to internal table in the index(line number) specified. Be careful to use this in
sorted table else exception/dump will occur if you don’t specify the exact line number according to the
sort.
Ex: INSERT wa_mara INTO it_mara INDEX 3.

Insert lines of can be used to copy another internal table contents having same structure to the internal
table. We need to mention the line number also from where it will be copied. The existing entries will be
shifted accordingly.
Ex: INSERT LINES OF it_mara2 INTO it_mara index 1.

If you don’t want to specify line position explicitly , then you can use insert ... into table.
Ex: INSERT wa_mara INTO TABLE it_mara.

Similarly :
Ex: INSERT LINES OF it_mara2 INTO TABLE it_mara.

The line number will be automatically determined based on table type:
Standard tables: The line is appended to the end of the internal table. This has the same effect as the
APPEND statement.
Sorted tables : The line is inserted into the table automatically according to the sorting of the table key.
Hashed tables : The table is inserted into the internal hash administration according to the table key.
Accessing internal table via index is only available in standard and sorted tables
10.5 Collect command:

Collect is used for summation purpose. If there is no record with that key , then it will create a entry
If a entry with same key is already present , then it will add the numeric values of the new record to the
existing record without changing the non numeric values..
wa_itab-material = '00001'.
wa_itab-qty = 50.
COLLECT wa_itab into it_itab.
wa_itab-qty = 100.
Now the contents of IT_ITAB is
material => qty
00001 => 50
00002 => 100
wa_itab-qty = 100.

A entry with key material 00001 is already present having qty as 50. qty 100 will be added to it and the
value will become 150
Itab contents after collect is

material => qty
00001 => 150
00002 => 100
Sy-subrc will be zero if the insertion/collection/appending operation is performed successfully.
DEFINING INTERNAL TABLES WITH GLOBAL TYPES
The type of an internal table is called table type.

Table types can be defined locally in a program, thereby making them accessible only to that program.
Table types can be defined globally in the ABAP Dictionary.
DEFINING INTERNAL TABLES WITH LOCAL TYPES
You can declare table types locally in a program. When listing the key fields in the table type, their order
matters for certain processing types, such as the sort by key. You can also define an internal
table directly, using DATA instead of TYPES, to declare a local table type.

INDEPENDENT DEFINITION OF INTERNAL TABLES
You can independently define internal tables using

the TYPES: BEGIN OF …. END OF statement, or
the DATA keyword with TYPE, referring to a table name in the dictionary and using the words
STANDARD, SORTED, or HASHED to describe the table type.
POSSIBLE DEFINITIONS OF INTERNAL TABLES
This slide shows you some possible definitions of internal tables:

The first example defines a standard definition.
The second example defines the table type as standard, sorted, or hashed.
The third example is a shortened version with a nonunique key.

ACCESSING SINGLE RECORD (OVERVIEW)
A structure variable known as the work area, with the same type as the line type of the internal table,
is used for single record processing of an internal table.
PROCESSING SETS OF RECORDS (OVERVIEW)
Sets of records can be processed using the ABAP statements, such as

LOOP AT ENDLOOP, where the LOOP places the rows of an internal table one by one into the structure
specified in the INTO clause;
DELETE, which deletes the rows of the internal table that satisfy the condition;
INSERT LINES OF, which copies the contents of several rows of an internal table to another internal table;
and
APPEND LINES OF, which appends the contents of several rows of an internal table to another standard
table.

SYNTAX EXAMPLE: INSERTING A ROW
You can insert a row into an internal table by writing the required record into the prepared work area, and
then inserting it into the internal table with an INSERT statement.
SYNTAX EXAMPLE: OUTPUTTING AN INTERNAL TABLE ROW BY ROW
To read and edit the contents of an internal table row by row, you use a LOOP statement. The system
field sy-tabix contains the row number of the current table entry.
This slide depicts how you can process all the rows of the internal table consecutively and use the WRITE
statement to provide the output.

SYNTAX EXAMPLE: READING BY INDEX
You can use the FROM–TO addition to restrict the access to certain rows in the loop. The access in this
example is restricted to the first five rows. Hence, only those rows of the internal table are processed
consecutively.
The READ TABLE statement can be used to read a single record, and the INDEX addition specifies the row
number of the required record.
SYNTAX EXAMPLE: READING BY KEY
In the loop, you can use the WHERE addition to restrict access to certain rows. In our example, the system
only processes those internal table rows, in which the CARRID field has the value LH.
The READ TABLE syntax can be used to read a specific row of an internal table. In this case, you must
assign values to all the key fields after the WITH TABLE KEY addition. The return code sy-subrc is set to
zero if a corresponding row is in the internal table.

SYNTAX EXAMPLE: SORTING AND DELETING CONTENT
You can sort standard and hashed tables in an ascending or a descending order, by using either the table
key, or columns that use the SORT statement. The field is sorted in ascending order by default.
SORT itab [STABLE]
{ { [ASCENDING|DESCENDING]
[AS TEXT]
[BY {comp1 [ASCENDING|DESCENDING] [AS TEXT]}
{comp2 [ASCENDING|DESCENDING] [AS TEXT]}
... ] }
| { [BY (otab)] } }.
STABLE is used to perform stable sorting, which means that the relative sequence of lines that does not
change in the sort key remains unchanged in the sort. Without the STABLE addition, the sequence is not
retained and multiple sorting of a table using the same sort key results in a different sequence each time
the table is sorted.
The addition AS TEXT specified that text-type components are sorted according to the locale of the
current text environment. If AS TEXT is not specified, text-type components are sorted according to the
encoding in the code page of the current text environment. This specification can be overwritten after
the BY addition for the components that are individually listed there. The text environment is set when an
internal session is opened or by using the statement SET LOCALE.
You use the REFRESH and CLEAR statements for deleting the table contents.
You use FREE to delete the entire contents of an internal table and release the previously used memory.

INTERNAL TABLES IN DEBUGGING MODE
In the Debugger, you can monitor the contents of an internal table by

entering the table name in the Variables 1 area; and
branching off to the table display by double-clicking.
Alternatively, use the table tab page; specify the table name in the internal table field; and press Enter,
to display the table contents.
COMPARISON: INTERNAL TABLES WITH AND WITHOUT HEADER LINES
To create a table with header line, use the WITH HEADER LINE addition in the definition of an internal
table. A work area that suits the table is created automatically, thus simplifying the syntax of the table
command.
The automatically generated work area has the same name as the internal table.
Whenever you loop through the internal table, the current record is kept in the temporary work area
DATA gt_itab
TYPE STANDARD TABLE OF gty
WITH NON-UNIQUE KEY carrid
WITH HEADER LINE.
The headerline is not preferred as

 Automatically generated headerline has same name as internal table name – confusing

 Not allowed in nested data objects
11 DATA MODELING
A business unit is represented as an entity. An entity relationship model (ERM) is used to map the
relationships that these entities have with each other. This data model is the basis for implementing
appropriate table definitions (transparent tables), including their relationships with each other, in the ABAP
Dictionary. The corresponding database tables are automatically created in the database with the
activation of the table definitions.
FLIGHT DATA MODEL FOR ABAP TRAINING COURSE
The package SAPBC_DATAMODEL contains the Repository objects for the flight data model used in ABAP
training courses. A customer of a travel agency might enquire about suitable airports, flight connections,
timings, and so on.

RELATIONAL DATA MODEL
Entities logically connect business information. The flight data model comprises the entities that logically
connect flight information:
IMPLEMENTATION USING TRANSPARANT TABLES
The developer creates a platform-independent description of a database table, known as transparent

table in the ABAP Dictionary, for each entity fixed in the data model. A transparent table allows you to
store and manage data records in a structured way. Table fields – declared as key fields – help in the
unique identification of data records within the database table. The key of a table (table key or primary
key) consists of key fields.

TECHNICAL STRUCTURE OF A TRANSPARENT TABLE
A transparent table defined in the ABAP dictionary contains the actual application data. A table of same
name is automatically created on the database when the transparent table is activated. The fields of the
transparent table form the identically-named columns of the corresponding database table. The data
elements are normally used to describe the individual fields, which then refer to domains for their technical
properties.
TRANSPARENT TABLES IN ABAP DICTIONARY
For creating a table of the same name on the database, the transparent table, in addition to the list of
fields, contains other information:

The determination of the key for the database table (key fields)
The technical properties required to create the database table, such as expected size and expected
frequency of access
Settings for technologies to speed up the access to database table, such as secondary indexes and
buffering
STRUCTURES IN THE ABAP DICTIONARY
Transparent tables can be used in the same way as structure types. They can, for instance, be used for
defining a structured data object (structure variable); for typing an interface parameter; or as the line type
of a global or local table type. The list of fields is of major importance, whereas properties such as the key
definition or the technical properties are irrelevant.
TRANSPARENT TABLES AS AN ABAP DATA TYPE

Transparent tables were used as data types in older programs. Nowadays, the advice is to use them directly
only in connection with access to the database.
A transparent table is always a list of elementary fields. In contrast, the components of a structure type can
themselves be structured again (nested structures). If the component of a structure is typed with a table
type, it becomes a deep structure.
DATABASE ACCESS (ARCHITECTURE)
Structured Query Language or SQL enables you to define, change, and read access to database tables.
Let us now understand the difference between native SQL and Open SQL.
Every relational database system has a native SQL, which is database-specific. It cannot be used in all SAP
systems, because different SAP systems may have different database systems.
In contrast, open SQL is an SAP-defined, database-independent SQL, standard for the ABAP language.
Open SQL statements are dynamically converted to the corresponding native SQL statements of the
database system in use. Thus, open SQL allows uniform access to data, regardless of the database system
installed.
SEARCHING FOR DATABASE TABLES
There are different ways of searching in a database table:

An application-specific search is indicated if the search is within a particular component, such as
an Application Hierarchy.
A program-specific search relates to a search that uses a program, which can access the relevant database
table.
This search involves three steps:

The source code search tries to locate the specific code in the program, such as the SELECT statement in
the program editor.
Function debugging is carried out, to set a break point at the SELECT statement. Before executing a
program with this kind of search, you must change to debugging mode using /h.
Using the screen field information, you can display a structure field by F1 and then display the technical
information. You can query a Where-Used List in Table Fields after navigating to the relevant data element.
REUSE COMPONENTS FOR DATA RETRIEVAL
Four types of reuse components encapsulate database accesses:

Logical databases, in which data retrieval programs belong together hierarchically
Function modules, which comprise encapsulated functions, such as reading from hierarchically related
tables
BAPIs, which act as methods of Business Objects with, for example, read function
Methods of global classes

DATABASE READ ACCESS (OVERVIEW)
The SELECT statement in the Open SQL allows for read access from a program database, which will fetch or
read the required data.
The SELECT statement contains a series of clauses, each of which has a different task:
SELECT describes which fields of the table are to be read.
FROM names the source (database table or view) from which the data is to be selected.
INTO determines the target variable, into which the selected data is to be placed. The target area must
be structured like the table row or like the specified fields of the row. In other words, it has to be left-
justified.
WHERE specifies the rows of the table that are to be selected.
READING SINGLE RECORDS
You can use a SELECT SINGLE statement for retrieving a single record. All key fields must be filled in the
WHERE clause, to ensure unique access. The current client is taken into consideration if the client field is
not specified. You can use an asterisk (*), to specify that all the fields of the table row are to be selected.
If the system finds a suitable record, the return value sy-subrc equals 0.

CORRESPONDING TARGET STRUCTURE FOR THE FIELD LIST
You can retrieve a certain selection of fields from the table row by specifying a field list within the SELECT
statement.
In the INTO clause, you must then name a target structure variable that has the same structure as the field
list. The names in the target structure do not matter. It should contain the fields of the field list in the same
order. Only the corresponding field types match.
Alternatively, you can list the corresponding target fields in the INTO clause:INTO (field_1, …, field_n).
FIELDS IN THE TARGET STRUCTURE WITH THE SAME NAMES AS IN THE FIELD LIST
You can use the CORRESPONDING FIELDS OF addition for retrieving the records in a structure variable that
has fields with the same names as those in the target list, but with a different structure, such as additional
fields or a different order of fields. The effect is that only fields of the same name are filled in the target
area.

READING SEVERAL ROWS USING A LOOP
The SELECT–ENDSELECT loop can be used to read several rows of a database table into the program in
succession.
The lines to be read into the target structure – and processed using the statement block specified in the
loop body – are determined by the WHERE clause. Multiple logical conditions can also be defined within the
WHERE clause, by using AND or OR.
The database delivers the data to the Database Interface of the application server in packages, after which
the specified processing block copies the records to the target area, row by row, for processing.
You should query the return value after the SELECT–ENDSELECT statement by usingsy-subrc. The sy-
dbcnt contains the number of records read.
READING SEVERAL ROWS USING AN ARRAY FETCH
Instead of copying the selected part of the database into an internal table row by row, you can use the
INTO TABLE clause to copy it directly. This technique is called an array fetch.
The ENDSELECT statement is neither required nor allowed, as array fetch is not a type of loop processing.
The internal table that is specified as the target in the array fetch must be structured left-justified in the
same way as the field list.

READING DATA FROM CLIENT-SPECIFIC TABLES
A database table is called client-specific, if it has a client field (data type CLNT) as the first key column and
contains client-specific entries.
If you select data from client-specific tables without specifying the client, then only data records from the
current client are read. This is because the current client is transferred to the database system, where the
data retrieval takes place.
To read data from an explicitly specified client, you specify this client in the WHERE clause, and use the
CLIENT SPECIFIED addition after the FROM clause.
ACCESS THROUGH KEY FIELDS
The data records are managed within a database table, which is based on the content of the key fields. If
access to the table is restricted to all the key fields, or at least the first few, then the required data records
can be accessed very quickly and effectively.

ACCESS THROUGH NON-KEYFIELDS
If the fields to be accessed do not belong to the table key (non-key fields), then the internal ordering
principle cannot be used for rapid access. In the worst-case scenario, the entire table – or at least a very
large part of it – may be searched for the required entries. This type of sequential search can increase the
waiting time for database access.
ACCESS THROUGH SECONDARY INDEX
If a database table is frequently accessed using a certain selection, a secondary index is defined for the
fields contained in the selection. This speeds up the corresponding accesses.
A secondary index is a separate, small table that contains the content of the index fields, as well as a
reference to the relevant data records in the actual database table. The required fields should match the
fields in the secondary index, at least by being left-aligned and gap-free. This prerequisite enables the
database to first search within the secondary index, and then read the corresponding data records through
the reference.
You can create a secondary index in the ABAP Dictionary by choosing Indexes and then activating it. The
index is not manually specified in the SELECT statement.

ACCESS THROUGH THE SAP TABLE BUFFER
You can reduce runtime by buffering the data on the application server. The database interface first tries to
get the required data from the SAP Table Buffer, thus speeding up the access by a factor of 10 to 100. This
is much faster than reading data from the database, particularly if the data is needed frequently but seldom
changed.
If the required data is not yet in the SAP Table Buffer, then the entire database is accessed.
The read data is then transferred from the database interface and stored in the SAP Table Buffer.
EXAMPLE OF A TABLE JOIN
You can use the JOIN statement in the SELECT query to select fields from more than one table.

ENTRIES FOR DEFINING A TABLE JOIN
When defining a Table Join, you first decide three criteria:

Join Tables, which specifies which tables should be accessed
Join Condition, which determines the condition under which the relevant records from the join tables
are summarized to a join record
Join Columns, which identifies the columns from the join tables that should be available in the table join
IMPLEMENTATION OPTIONS FOR TABLE JOINS
You can use two options for implementing a table join:

You can create a database view in the ABAP Dictionary, which corresponds to a table join, and select it
in your program.
You can select from a join that is defined in your program (ABAP join).

DATABASE CHANGE ACCESSES
In addition to the SELECT statement, Open SQL also contains change accesses, such as the UPDATE, INSERT,
DELETE, and MODIFY statements.
SAP AUTHORIZATION CONCEPT
Authorization objects can be defined within object classes.

This authorization can be integrated into the required user master records by means of an authorization
profile.
Several different authorizations can be created for an authorization object.
AUTHORIZATION OBJECTS AND AUTHORIZATIONS (EXAMPLE)

You specify appropriate fields without values while defining an authorization object.
To create an actual authorization, you subsequently assign values to these fields.
AUTHORIZATION CHECK (PRINCIPLE)
You use AUTHORITY-CHECK statements to check whether the current users have the authorization
required, in their user master records, for executing the function. You use the system field sy-subrc to
validate the current user. If the return value is 0, then the user is authorized to view the data. Otherwise
the user receives an error message.
In addition, you can also protect programs and transactions by means of authorization checks.
DISPLAYING AUTHORIZATION OBJECT

To use the required authorization check in your program, you must first define the structure of the
respective authorization concept.
An object usually consists of the ACTVT (activity) field and one other field, which specifies the data type to
be protected. The values of these authorization fields specify what the user is authorized to do.
AUTHORIZATION CHECK (SYNTAX EXAMPLE)
You can use the AUTHORITY-CHECK statement to specify the authorization object, its fields, as well as the
appropriate field values. You also check the return code sy-subrc, to control the subsequent processing of
your program.
In the example, we check the authorization of the user for the S_CARRID object.
This object has the CARRID field; while the ACTVT field has 03 as its value. This check is performed against
the master record of the current object.
IMPLEMENTING AUTHORIZATION CHECK IN PROGRAMS
The AUTHORITY-CHECK statement can be generated into your source code by choosing Pattern. This way
you can avoid spelling errors in object and field names. Thereafter, you can maintain the field values and
implement the sy-subrc check.
To create a domain go to t-code SE11.

Select the Domain radio button, enter the name of the domain that you want to create and press create.
Enter the short description. Place the cursor in the data type and press F4 to get the list of SAP data types.

In the popup window select the correct data type.
Enter the number of characters. Enter the decimal places if it applicable to data type that you have
selected. Save and activate the domain.

To create a data element go to t-code SE11.
Select the Data type radio button, enter the name of the data element and press create.
Select the Data Element radio button and press continue.

Enter short description. Assign a domain to the data element. Press field label tab to maintain the field
labels for the data element.
Enter the field labels, Save and activate the data element.
ABAP list
Can be outputted to
 Screen
 Printer
 Internet
 Save as xls
Use menu painter to adapt the default list interface to your own needs.
Selection screen has the following standard functions:

Text can be maintained in several languages
System automatically performs type check. If user inputs something wrong, gui will ignore it
You can implement complex selections (SELECT OPTIONS) on the selection screen in addition to single value
entries (PARAMETERS)
The user can display field documentation by pressing f1 if the developer defines the input field using a
dictionary element such as data element
The user can call search help attached to the dictionary type to display possible inputs using f4
The user can save completed selection screen as variants for reuse

Only if no error message is sent at selection screen block, then the start-of-selection is triggered.
Event block characteristics
Introduced with an event keyword
Ends by beginning the next processing block
Cannot be nested
Existence is not absolutely necessary
Sequence of event block is not important
If no blocks defined, system assigns all statements to start-of-selection
The initialization block is used to setup the default values.
At-selection-screen is triggered by pressing enter or f8 (execute)
At-selection-screen, you do authorisation checks and raise errors

12 ABAP Events
ABAP report programs are event driven programs. The different events in a report Program are:
Load-of-program
Triggers the associated event in an internal session after loading a program of type 1, M, F, or S.
Also runs the associated processing block once and once only for each program and internal session.
The processing block LOAD-OF-PROGRAM has roughly the same function for an ABAP program of type 1, M,
F or S as a constructor has for classes in ABAP Objects
Initialization.
This event is executed before the selection screen is displayed .
Initialization of all the values.
You can assign different values other than the values defaulted on the selection screen .
You can fill your selection screen with some values at runtime.
At Selection-Screen.
The event is processed when the selection screen has been processed (at the end of PAI ).
Validation & Checks of inputted values happen here
Start-of-Selection.
Here the program starts selecting values from tables.
End-of-selection.
After all the data has been selected this event writes the data to the screen.
Interactive Events
Used for interactive reporting. It is used to create a detailed list from a basic list.

13 NEW TEST TOOLS
CALLING THE CODE INSPECTOR DIRECTLY FROM THE ABAP EDITOR
The Code Inspector enables you to check your programs for performance, security, and typical semantic
errors. There are various ways of calling this tool. As shown here, one method is to choose Program, select
Check, and then select Code Inspector. After this, you can commence a standard inspection for your
programs.
You can also call the Code Inspector from the context menu in the object list.
Performance – are indexes uses? Are select statements embedded in loop?
Security – is data read from client instead of logged in client? Where clause dynamically specified?
Semantic - is sy-subrc checked after each authority-check statement? Is a client specified for client
specified? Are sever messages of type E sent in direct succession?
To hide code inspector results, add the comment #EC* - suppress
When you start code inspector, it starts with default unless you overwrite with a new check variant.
INSPECTION RESULTS

After carrying out an inspection, you get a list of errors and warning messages. If you select the information
button that is next to a message, it gives a detailed description of the error, along with the suggested
improvements. If you double-click the error text, it shows the corresponding program statement.
CHECK VARIANT
The Code Inspector uses a default check variant with predefined checks. This default check variant contains
extended syntax check;
check of critical statements (such as C calls or Native SQL); and
selected performance checks.
To overwrite this default check variant, create a new check variant with the name DEFAULT. However, the
new check variant will override the standard variant for the users.
The standard variant is used automatically for any future checks in the absence of the default check variant.
DEFINING COMPLEX INSPECTIONS IN TRANSACTION SCI
You can define a custom check by calling the Code Inspector with either the transaction code SCI or by
choosing Tools, then ABAP Workbench, then Test, and finally Code Inspector.
The initial screen where you describe custom checks consists of three areas:
The Inspection field contains the name of the actual check. If the name is not specified, the results will
not be saved.
The Object Set field defines the Repository objects that will be checked.

The Check variant field defines the checks that will be performed.
CREATING A CHECK VARIANT
A check variant contains one or more check categories, which in turn consists of one or more single checks.
These single checks pertain to various check categories:
General Checks contain the checks for data formatting, such as the list of table names from the SELECT
statements.
Performance Checks contain the checks for performance and resource usage, such as the analysis of the
WHERE condition for SELECT or UPDATE and DELETE.
Security Checks contain the checks of critical statements, cross-client queries, and insufficient authority
checks.
The Syntax Check or Generation contains the ABAP syntax check, an extended program check, and
generation.
Programming Conventions contain the checks of naming conventions.
Search Functions contain the searches for words and the statements in ABAP source code.
PROGRAM CALLS AND DATA STORAGE MANAGEMENT
SYNCHRONOUS PROGRAM

Two options in ABAP for executing a program within a program are the SUBMIT and the CALL
TRANSACTION (or LEAVE TO TRANSACTION) statements.
These statements can differ in their effects:
In case one – Insert – the process flow of the calling program pauses while the called program is executed
and inserted. After this, the calling program is continued.
In case two – New start – the calling program is terminated as soon as the called program is initiated. When
the called program is started, the command in Working memory is Start new program 2.
CALLING AN EXECUTABLE PROGRAM
Let us designate Program 1 as the calling program and Program 2 as the called program, facilitated by the
SUBMIT statement.
You can use the SUBMIT statement to start an executable (type 1) program and exercise some options:
If you use VIA SELECTION-SCREEN, the standard selection screen of the called program (if any) is
displayed.
If you use AND RETURN, the system resumes processing with the first statement of the calling program
after the SUBMIT statement once the called program is finished.

CALLING A TRANSACTION
The system terminates the current program and starts the transaction with the transaction code T_CODE
when you use the LEAVE TO TRANSACTION ‘T_CODE’ statement.
This statement is equivalent to entering /NT_CODE in the command field.
The CALL TRANSACTION ‘T_CODE’ statement allows you to insert a program with a transaction code into
the call chain.
The LEAVE PROGRAM statement is used to force the termination of a program. The system does not display
the contents of the first screen in the transaction with AND SKIP FIRST SCREEN addition.
LOGICAL MEMORY MODEL

When you generate a dev object, system generates a runtime object called LOAD containing byte code. The
system generates the LOAD automatically when:
 The program is called and no LOAD exists
 The LOAD in the database or program buffer is obsolete
 When the developed version of the program is changed
 The object that the program uses is changed in data dictionary
The following steps occur when you activate an object
 The object is saved, that is a new inactive version is created. This is subject to syntax check
 The system overwrites the current active version. There is no longer an inactive version.
 The system creates a new runtime version and updates the LOAD
ABAP program contains modifiable and non modifiable parts.
Modified parts are stored in the Roll area, working memory of the app server. This includes data objects
(variables)
Non modifiable parts are stored in PXA (program execution area – this is shared by all users on the app
server and exists only once per server). This includes
 Byte code for statements
 Values for constants and methods
 Program texts
 Screen definitions
The difference between external session and internal session is as follows
External session corresponds to a SAP gui window. The max number of sessions available in a given system
is defined by the system parameter rdisp/max_alt_modes, which defaults to 6. External sessions are
subdivided into internal sessions (placed in a stack). Each call of an ABAP program generates a new internal
session. A maximum of 9 internal sessions can exist in each external session. Internal session must belong
to the same call stack. The programs within an internal session form program groups. When the system
opens an internal session with a program call, the system always creates the main program group. There
can be one or more additional program groups.
There is a distinction between internal and external sessions:

Generally, an external session corresponds to an SAP GUI window.
External sessions are subdivided into internal sessions placed in a stack.
Each program that is started occupies its own internal session.
Data for input fields can be passed in two ways:

 By specifying a variant for the selection screen when you call the program
 By specifying specific values for the input fields when you call the program
BEFORE INSERTING A PROGRAM
This slide illustrates how a stack inside an external session changes with various program calls. The starting
point can be executed by a SUBMIT ... AND RETURN or CALL TRANSACTION statement within a program.

THE INSERTED PROGRAM RUNS
The system creates a new internal session containing the new program context whenever a program is
inserted. The new session along with the program context of the calling program remains in the stack.
AFTER THE INSERTED PROGRAM ENDS
The internal session from the top of the stack is deleted with the end of the called program. The processing
is resumed in the next highest internal session in the stack.
BEFORE STARTING A NEW EXECUTABLE PROGRAM

While ending a program and starting a new one, keep in mind the distinction between calling an executable
program and calling a transaction, with respect to memory areas.
The starting point for the second case (calling a transaction) is the execution of a SUBMIT statement within
a program.
THE NEW EXECUTABLE PROGRAM RUNS
If you call an executable program using its program name, you automatically end the calling program.
Therefore, the system destroys the internal session of the program that you are terminating, which is the
top one from the stack. The system creates a new internal session in the stack, which contains the program
context of the called program.
Program contexts created before are retained.
BEFORE STARTING A NEW TRANSACTION
The starting point for a new transaction is the execution of a LEAVE TO TRANSACTION statement within a
program.

THE NEW TRANSACTION RUNS
The system creates a new internal session when a transaction code is used to start a program. This internal
session contains the program context of the called program. As all the previous internal sessions in the
stack are destroyed, the complete stack of internal sessions is initialized, which also means that the ABAP
memory is initialized after the call.
PROGRAM GROUPS WITHIN AN INTERNAL SESSION
Let us see how the system responds when a program calls a subroutine of another program.
The system starts an internal session with the creation of a main program group.
It can create any number of additional program groups in the same internal session. Each program group
has exactly one main program.
The main program of the subroutine is loaded into the program group of the calling program with the call
of an external subroutine.

MAIN/ADDITIONAL PROGRAM
An additional program group is created when a function module or a method is called. This happens when
neither the relevant function group nor the class definition is loaded.
DATA TRANSFER BETWEEN PROGRAMS: OVERVIEW
There are various ways of exchanging data between programs that are running in separate program
contexts or internal sessions.
Some platform-independent methods can transfer data transiently:
Using the interface of the called program (usually a standard selection screen)
By means of the ABAP memory
Using the SAP memory
Using database tables
By means of local files on the presentation server

PASSING DATA USING THE PROGRAM INTERFACE
You can pass data for the input fields when ABAP programs with standard selection screen are called.
You can do so by specifying
a variant for the selection screen; or
specific values for the input fields.
PREASSIGNMENT OF INPUT FIELDS
Using WITH in the SUBMIT statement allows you to assign values to the fields on a standard selection
screen.
You can also use the RANGE type instead of individual WITH additions to set several choices for a selection
option. You can fill the resulting selection table and then pass the whole table to the executable program.
You can use VIA SELECTION-SCREEN to display the standard selection screen when you call the program.
When you use the SUBMIT statement, use the Pattern function in the ABAP Editor to insert an appropriate
statement pattern for the program you want to call.
The pattern automatically supplies the names of the parameters and selection options that are available on
the standard selection screen.

PASSING DATA USING AN INTERNAL TABLE
You can call a transaction using the CALL TRANSACTION 'T_CODE' USING bi_itab. This helps you access the
values from the internal table bi_itab in the screen fields.
This internal table should have the structure BDCDATA. You fill it accordingly.
The return code (sy-subrc) tells you whether the transaction was executed successfully.
FIELDS IN THE GLOBAL TYPE BDCDATA
You can fill an internal table in the batch input format:
You identify each screen in a transaction by a line in which only the PROGRAM, DYNPRO, and DYNBEGIN
fields are filled. Only then can you fill in the screens and process them automatically.
You also use a new BDCDATA record for each field you want to fill, after a record identifies the screen.
These records use the FNAM and FVAL fields.
DATA class_name TYPE c LENGTH 30 VALUE 'CL_SPFLI_PERSISTENT'.
DATA: bdcdata_wa TYPE bdcdata,

bdcdata_tab TYPE TABLE OF bdcdata.
DATA opt TYPE ctu_params.
CLEAR bdcdata_wa.
bdcdata_wa-program = 'SAPLSEOD'.
bdcdata_wa-dynpro = '1000'.
bdcdata_wa-dynbegin = 'X'.

APPEND bdcdata_wa TO bdcdata_tab.
CLEAR bdcdata_wa.
bdcdata_wa-fnam = 'BDC_CURSOR'.
bdcdata_wa-fval = 'SEOCLASS-CLSNAME'.
CLEAR bdcdata_wa.
bdcdata_wa-fnam = 'SEOCLASS-CLSNAME'.
bdcdata_wa-fval = class_name.
CLEAR bdcdata_wa.
bdcdata_wa-fnam = 'BDC_OKCODE'.
bdcdata_wa-fval = '=CIDI'.
opt-dismode = 'E'.
opt-defsize = 'X'.
CALL TRANSACTION 'SE24' USING bdcdata_tab OPTIONS FROM opt.
DATA TRANSFER USING AN INTERNAL TABLE: APPLICATION SAMPLE
The program calls the transaction with the creation of a new customer entry.
If the operation is successful, the new customer record can be entered in the waiting list.
At runtime, you enter the customer name from the input field in CURRENT_NAME and the relevant city in
CURRENT_CITY.
To address the command field, use BDC_OKCODE.

RANGE OF ABAP MEMORY AND SAP MEMORY
You can use both the SAP memory and the ABAP memory when you cannot always specify the data to be
transferred between two programs:
The SAP memory is a user-specific memory area for storing field values.
It can be used between external sessions in the same user session.
All external sessions of a user session can access the SAP memory.
The ABAP memory is also user-specific.
There is a local ABAP memory for each external session.
It helps exchange ABAP data objects between the internal sessions in the same external session.
PASSING DATA USING THE ABAP MEMORY
You use the EXPORT ... TO MEMORY statement to copy any number of ABAP data objects with their current
values to a data cluster in the ABAP memory. With the ID addition, you can identify different clusters.
To copy data from ABAP memory to the corresponding fields of your ABAP program , you use the IMPORT
... FROM MEMORY ID ... statement.

PASSING PARAMETERS USING SAP MEMORY
The memory areas or parameters can be defined in the SAP memory in various ways.
The SET PARAMETER ID statement helps you fill the memory areas directly, and the GET PARAMETER ID
statement to read from them.

14 DYNAMIC DATA OBJECTS
Strings and internal tables are dynamic data objects. Also called as deep data objects with memory
requirements that can change during the program runtime. The system manages the working data of these
data objects internally, using references. This is handled in a different manner from the flat data objects
with fixed length (also structures that include only flat components).
When you create a string, the static memory requirement is 8 bytes. When you assign an value, say lv = “t”.,
additional working memory is requested. This working memory includes (a) administration information –
100 bytes (b) data object itself.
Additional memory is allocated if not sufficient, max is 2gb. When you use CLEAR or FREE, the system
deletes the data but the reference variable and header are retained and reused for the next memory
request.
Memory management of itab is different from string in the following manner:
 The headers of internal tables require more memory than other headers as the itab can be
distributed among several blocks.
 CLEAR and REFRESH delete the data, where as FREE deletes data and table header too
 Amount of memory allocated is specified when you created itab (Optional parameter; INITIAL
SIZE)

Boxed components
Large static data objects can use large amount of memory even when they are initial. to reduce the
memory consumption, use boxed components.
Boxed components can be
 Substructures of nested structures
 Structured attributes of classes and interfaces
These components are also called static boxes. A static box declared with BOXED addition.
CLASS c1 DEFINITION.
PUBLIC SECTION.
TYPES: BEGIN OF t_struc,

comp1 TYPE c LENGTH 100,
comp2 TYPE n LENGTH 100,
END OF t_struc.
PRIVATE SECTION.
CLASS-DATA struc1 TYPE t_struc BOXED.
DATA struc2 TYPE t100 BOXED.
ENDCLASS.
Static boxes support initial value sharing. The structure is not saved in the higher-level context itself. Instead, an
internal reference that points to the actual structure is stored in place of the component. A static box is
therefore a deep component.
A boxed component can have two statuses:

Initial value sharing
As long as none of the actions listed in the following point were executed, initial value sharing applies for a
static box. The internal reference points to an appropriate initial value for the structure type, which is
stored exactly once for each application server in the PXA. The memory requirement of the internal session is
determined only by the internal reference and its administration.
Revoked initial value sharing
The following actions revoke initial value sharing for a static box:
Write access to the static box or one of its components
Assigning the static box or one of its components to a field symbol using ASSIGN
Addressing the static box or one of its components using a data reference
Using a static box or one of its components as an actual parameter for procedure calls

15 ABAP Open SQL
WHERE CONDITION: POSSIBLE OPTIONS
This slide depicts a table listing operators that Open SQL accepts in WHERE conditions.
OPERATORS IN WHERE CONDITIONS
You select the country, using the list of values in the WHERE condition. An AND operator is used to
determine the range for discount as well as the postal code with five places and number 5 in position 4.
The selection of name, which contains a substring ra in any position, is also mentioned with the AND
operator.
The AND operators are evaluated before the OR operators when the conditions are linked.
The “_” and “%” placeholders correspond to the SQL standard in delimitation with LIKE.

COMPARING TABLE FIELDS
You can compare two database fields with each other by mentioning the fields from the same database
tables after the comparison operators (=, EQ, <>, NE, <, LT, and so on), in the WHERE conditions of the
Open SQL statements.
Alternatively, you can also use an alias for the table name in the FROM clause with the AS addition after the
table name.
AGGREGATE FUNCTIONS
An aggregate determines values from multiple lines in a column of a database table and the calculation is
performed in the database system. An aggregate expression uses an aggregate function to
specify a column in the SELECT statement.
The data object in the INTO clause must provide a structure component or table column with the suitable
type (see table) for each aggregate expression after SELECT.
SELECT STATEMENT WITH AGGREGATE EXPRESSION

The result of the field list in a SELECT statement, which contains only aggregate expressions, is a single data
set. Just as in the SELECT SINGLE statement, you can specify a structure as the target.
THE GROUP BY ADDITION
A group contains all the records that have the same contents in the columns, which are specified after
GROUP BY.
With the GROUP BY addition, the database first sorts the records into groups, instead of applying the
aggregate functions to all the records found. The aggregate functions are evaluated separately for each
group. Each group is represented as one line in the selection result.

THE HAVING ADDITION
While using GROUP BY, you can also specify a logical expression after the HAVING addition, to restrict the
result set further. The logical expression after HAVING can contain aggregate functions, as well as the fields
that are specified after GROUP BY.
THE ORDER BY ADDITION - VARIANTS
In Open SQL, you can use the ORDER BY addition for the SELECT statement to sort the data by specific
criteria directly.
To sort the table by its complete primary key in ascending order, you use the ORDER BY PRIMARY KEY,
subject to certain conditions:
The FROM clause must only contain a single database table, with no views or joins.
The field list after SELECT must contain all the key fields of the table, including the client.
You can sort the data by any existing columns by using the syntax ORDER BY col1 col2... The priority of
sorting is determined by the sequence of the specified column.

THE ORDER BY ADDITION
You can define the direction of sorting by using the optional DESCENDING and ASCENDING additions after a
given field. The result set is sorted in ascending order by default.
Pre req for using ORDER BY PRIMARY KEY

9. The FROM clause contains a single database table, no views or joins
10. The field list after SELECT contains all the table’s key fields. Including the client
NESTED SELECTS
Nested SELECT statements are used to access the secondary tables in a loop over the records from the
primary table.
This results in a high load on the database and the network.
This is due to at least two reasons:
Many partially filled data packages are transferred.
Identical accesses can take place for the same data several times.

EXAMPLE: INNER/OUTER JOIN
When using an INNER JOIN, the result set consists of records from the outer table, for which suitable data
records exist in the inner table.
A LEFT OUTER JOIN results in a set that contains all the records from the outer table, regardless of whether
or not suitable records exist in the inner table.
The fields of the inner table are set to ZERO values in the result set, if no suitable records exist in the inner
table.
EXAMPLE: ABAP INNER JOIN
This slide depicts the syntax you can use while implementing an INNER JOIN. This enables you to read data,
distributed across multiple functionally dependent tables.

READ ON DEMAND AND BUFFERING
This example shows how matching data from STRAVELAG (travel agency master data) within a loop for the
bookings from table SBOOK can be read. You should encapsulate the reading of STRAVELAG records in a
read routine, as using a SELECT SINGLE will lead to identical SQL statements. The table contents read from
STRAVELAG are buffered in a static internal table. Before each database access, the system checks whether
the corresponding table entry is already read.
SELECT WITH FOR ALL ENTRIES ADDITION
SELECT … FOR ALL ENTRIES is for additional data from the database, to augment the already available data
in an internal table.
The content of the internal table is used as a restriction for the database access. The database interface
takes a certain number of entries and sends one native SQL for each group. The results of the individual
native SQL statements are combined to form the result of the Open SQL statement. The duplicate entries
are removed automatically.

Multi line target area

16 ABAP Dictionary
16.1 INTRODUCTION TO THE DICTIONARY
FUNCTION OF THE ABAP DICTIONARY
The ABAP Dictionary performs three key functions:

Type Definitions – create user defined types, such as data elements, structures
DB Objects – create tables, index and views
Services that support program development – ex setting and releasing locks, defining input help and
attaching a field help to a screen field.
The ABAP Dictionary enables central management of all the type definitions used in the R/3 System. You
can use this tool to create data types, such as data elements, structures, and table types, either for ABAP
programs or for applications, such as function modules and object methods.
The ABAP Dictionary also defines database objects such as tables, indexes, and views.
It also provides numerous services that support program development, such as setting and releasing locks,
defining an input help, and attaching a field help to a screen field.
DATABASE OBJECTS IN THE ABAP DICTIONARY

You can define a table and a database view in the ABAP Dictionary independent of the database. On the
basis of this definition, objects are created in the database shown here. Therefore, any further change in
these definitions gets automatically reflected in the database.
You can also define indexes in the ABAP Dictionary to speed up access to data in a table. These indexes are
created in the database.
TYPE DEFINITION IN THE ABAP DICTIONARY
The ABAP Dictionary contains three distinct type categories:

Data elements describe an elementary type by its characteristics, such as the data type, length, and
decimal places.
Structures consist of components that can have any type.
Table types determine the structure of an internal table.
Let us assume that the data of an employee is stored in a structure called EMPLOYEE, which has the
components NAME, ADDRESS, and TELEPHONE.
The component “NAME” is again a structure with components “FIRST NAME” and “LAST NAME”.
Similarly, the component “ADDRESS” is also a structure with the components STREET and HOUSE NO.
However, the component “TELEPHONE” is defined by a table type as an employee can have multiple
telephone numbers.
SERVICES OF THE ABAP DICTIONARY
The ABAP Dictionary offers various services in support of program development. These services include
input helps (or F4 helps) for screen fields that can be defined with search helps;
field helps (or F1 helps) for screen fields by creating documentation for the data element; and
input checks that ensure that the values entered are consistent.
LINKING TO THE DEVELOPMENT AND RUNTIME ENVIRONMENT
The ABAP Dictionary is well integrated in the development and runtime environments. Therefore, any
change in the ABAP dictionary gets automatically reflected in the relevant ABAP programs and screens.
Let us discuss this concept with the examples shown here:
ABAP Tools and the Screen Painter use the information stored in the ABAP Dictionary to provide support
services during program development. The Get from Dictionary function, which is defined in the ABAP
Dictionary, is used in the Screen Painter to place fields of a table or structure.
ABAP Interpreter and the Screen Interpreter retrieve the type definitions from the ABAP Dictionary soon
after a program or a screen is generated.
Database Interface utilizes table and database-related information stored in the ABAP Dictionary to
access the data in these objects.
16.2 DATA OBJECTS IN ABAP DICTIONARY

DATA DICTIONARY INITIAL SCREEN (SE11)

The globally known data types are defined using the Data Type field.
You can define the type group for creating global constants using the Type Group field.
The Domain field is where the technical properties of data objects can be defined.
DATA TYPES IN THE ABAP DICTIONARY
You can generate data objects in the ABAP programs using the data types declared in the ABAP dictionary.
However, an ABAP program cannot access domains for defining data objects. The data elements get their
data types from domains.
The components of a structure can be elementary fields, tables, as well as structures.
A structured type or an elementary type can be the line type of a table type (ITAB).
DOMAIN
Domains cannot be used directly in programs or tables.

Therefore, data element is used as a bridge from the technical properties to the different data types or data
objects.
You can define technical attributes and value ranges.
The most frequently used data types are CHAR, DATS, DEC, and NUMC. CHAR, the character string, can
have a maximum length of 255 in tables. DATS defines the date and the length is set at eight characters.

DEC is used for the calculation of an amount in a field, and contains operators, such as the point, the plus or
minus (+/-) sign, and thousand-separator commas. It can have a maximum of 31 characters.
NUMC is used for character strings that comprise only numbers. It is restricted to a maximum of 255
characters.
Domain has the following settings:
 Format – decimal places
 Data type
 Output characteristics = display format
 Valid value range, max length etc
DATA ELEMENT
Data elements not only constitute the link between domains and the data objects, but also contain
semantic or technical information about the data objects created from these.
You can translate the field labels into other languages by choosing the transaction SE63 or the menu
path: Goto → Translation.
You can append F4 or input help to a data element.
You can assign the SET or GET parameter to the data element, if an input field based on the same data
element exists on a subsequent screen. This helps you read the value from the parameter and enter it in
the screen field.
Domains manage technical properties of data elements centrally. Data elements define the data types
which can be used on screen or program etc.
Data elements also allows to maintain field labels. SET/GET parameter allows to pass values between
screens automatically so that the user does not have to re enter them

STRUCTURES
Structure components can be data elements, integrated types, structure definitions of internal tables, DB
table views, or other existing structure definitions. The data object, generated by including the fields of an
actual two-dimensional object like a view or DB tables, remains flat or one-dimensional.
USING SIMPLE STRUCTURES IN ABAP
A flat structure is formed by the sequence of fields through the use of data elements. A one-dimensional
data object is formed with this structure type. The individual elements or components of the structure can
be addressed by using the name of the structure, a hyphen, and the name of the components.

NESTED STRUCTURE
A nested structure is formed by including another structured object in the structure and assigning it to a
component.
You can nest structures like these into one another in any way.
INTERNAL TABLES
Internal tables can be defined using an existing line structure. You can use database tables, structure
definitions, views, data elements, direct type definitions, or existing table types as line types.
A two-dimensional array is created in the main memory by declaring an internal table in an ABAP program.

DEEP STRUCTURE
A deep structure is formed by inserting an internal table as a structure component. It contains at least one
table. The component of such a table has its own name and can be addressed like a normal internal table
(LOOP AT..., INSERT... INTO TABLE, ...).
An internal table can have a deep structure as a line type. Thus multidimensional data types can be created
as you can inter-nest internal tables and structures several times.
A dictionary structure combining one or more fields using a table type is called DEEP structure.
Simple
Deep
Shaded is a table type

table type three things:
 Line type - structure
 Table type – standard / sorted / hashed
 Key

Two methods:
Select … into … where ….
Write
End select
(or)
Select ….. into table it_flight
Where …..
Loop at it_flight into wa_sflight
Write
End loop
Second method is called array fetch – and it does not have end select
TYPE GROUP
type group used to define global, complex data types and global constants
You declare the type group using the TYPE POOL statement. This enables you to use the types of a type
group in a program.
All names of these data types and constants must begin with the name of the type group and an
underscore.
You define global constants using a type group, which should have a name not more than five characters

long.
In the type group, you use the CONSTANTS statement to define constants, as well as to declare cross-
program constants.
TABLES AND FIELDS
A table consists of
columns (fields) and rows (entries);
a unique table name and certain general attributes, such as delivery class and maintenance
authorization; and
certain key fields called the primary keys, whose values uniquely identify each entry of the table.
you must specify a reference table for fields containing a currency (data type CURR) or quantity (data type
QUAN). A reference table must contain a field (reference field) with the format for currency keys (data type
CUKY) or the format for units (data type UNIT). The field is only assigned to the reference field at program
runtime.
BASIC OBJECT OF THE ABAP DICTIONARY
The basic objects for defining data in the ABAP Dictionary are
tables
data elements, and
domains.

Business data is stored in database tables. A field is not an independent object, it is always dependent on
table.
Domains are used for technical definition of table fields, such as field type and length. One domain may be
used by more than one data element.
Data elements, on the other hand, are used for semantic definitions, such as short descriptions. One data
element may be used by more than one field of one or more tables.
A field in a table is not an independent object. It is table-dependent and can only be maintained within a
table.
TWO-LEVEL DOMAIN CONCEPT: EXAMPLE
A single domain can be used for different data elements.

Let us assume that flight schedules are stored in a table SPFLI. The table contains the fields AIRPFROM
(departure airport) and AIRPTO (arrival airport). These fields have the same domain S_AIRPID because both
fields contain airport IDs and therefore have the same technical attributes.
They have a different semantic meaning, however, and use different data elements to document this. The
field AIRPFROM uses data element S_FROMAIRP while field AIRPTO uses data element S_TOAIRP.
TRANSPARENT TABLES AND STRUCTURES

A transparent table is automatically created on the database when it is activated in the ABAP Dictionary.
When this happens, the database-independent description of the table from the ABAP Dictionary is
translated into the language of the corresponding database system.
The database table thus created, along with its fields, has the same name as the table in the ABAP
Dictionary. The data types in the ABAP Dictionary are converted to the corresponding data types of the
database system.
The order of the fields in the ABAP Dictionary can differ from the order of the fields on the database.
Transparent tables can be accessed by ABAP programs in two ways:

Access the data in the table with the OPEN SQL or the EXEC SQL command.
Access a structured type defined in the table, only when variables or more complex types are defined. A
structured type, for which there is no corresponding object in the database, can also be created in the
ABAP Dictionary. Such types are called structures. Structures can also be used to define the types of
variables.
INCLUDE STRUCTURES
To avoid redundant structure definitions, you can include structures in tables or within other structures. A
table can only be included in its entirety.
A chain of includes may only contain one database table.
An include can contain other includes.
Structure can be included in many tables, but table cannot include another table.

TECHINCAL SETTINGS
Technical settings help determine how to manage the tables once they are created on the database;
whether they should be buffered; and whether modifications to the entries should be logged.
Once a table is activated in the ABAP Dictionary, it is automatically created in the database. You can deduce
the information on storage area and expected table size from the settings for the data class and size
category. The buffer settings specify how the table should be buffered, if necessary. You can also define
whether modifications to the table entries should be logged.
Table settings optimize storage requirements and access behaviour of database tables
 Storage area (table size)
 Expected table size
 Buffering – how to buffer
 What updates are to be logged
FRAGMENTING THE TABLES IN THE DATABASE
One way to defragment the indexes is to simply delete and re-enter them. The database once again
calculates the content and structure of the index, and creates a single memory space, where possible, in
the storage medium. During this process, you can still use the database tables.
You can reduce fragmentation in fragmented tables by converting them. All the data is first transferred to a
new table created by the SAP system. The old table is deleted and replaced by the new one. If the new
table grows unexpectedly and quickly, it is also checked again, before being converted.

DATA CLASS
A data class logically defines the physical area of the database in which your table should be stored. If
defined correctly, tables will automatically be created in the right areas on the database, when they are
activated in the ABAP Dictionary.
The four main data classes are
master data,
transaction data,
organizational data, and
system data.
Master data is rarely modified. One example of master data is an address file, with a name, an address, and
a telephone number.
Transaction data, on the other hand, is frequently modified. An example of transaction data is the material
stock of a warehouse, which can change after every purchase order.
The third main data class, organizational data, is defined during Customizing when the system is installed. It
is rarely modified after that. Country keys are examples of organizational data.
The last data class, system data, is the data required by the SAP System itself. Program sources are
examples of system data.

SIZE CATEGORY
The size category describes the expected storage requirements for a table in a database.
When a table is initially created in the database, a fixed extent is reserved for it, irrespective of its size
category. If more space is required later, additional extents can be added. The sizes of these additional
extents are fixed and are determined by the size category specified in the ABAP Dictionary.
Size categories range from 0 to 4.
LOGGING
Logging is used to record and store modifications to the entries of a table.

However, this option is available only if the SAP System contains the parameter rec/client, which can be set
to different values to define which clients have log access.
Data modifications are logged independently of the update.
Rec/client=ALL log all clients

Rec/client=012 log client 012
Rec/client=off logging is deactivated

OVERVIEW OF THE DB TABLES TYPE
Pooled and cluster tables are other database table types.

The definition of transparent tables is identical in both the ABAP Dictionary and the database. In contrast,
pooled and cluster tables comprise several tables, which are logically defined in the ABAP Dictionary, but
are combined into a single physical database table.
CLUSTER TABLES
Cluster tables store functionally dependent data, divided among different tables, in a single database table.
The intersection of the key fields of the cluster tables, or the key of the table cluster, is called the cluster
key.
Data dependent on a single cluster key is stored in the VARDATA field of the table cluster.
The database interface also compresses the contents of the VARDATA field. The latter, therefore, includes a
description for decompressing its data.
The PAGNO field of the cluster table ensures that all entries are unique; while the TIMESTAMP and PAGELG
fields contain administrative information.
POOLED TABLES

Table pools, unlike the table clusters, store data records from independent tables defined in the ABAP
Dictionary.
This example depicts the intersection of the key fields of TABA and TABB, which is empty. Despite this
difference, the data records from TABA and TABB are stored in a single database table, the TABAB table
pool.
The key for a data record of the TABAB table pool consists of a combination of the fields TABNAME and
VARKEY.
The TABNAME field assumes the name of the pooled table.
The VARKEY field comprises the key fields of the pooled table.
The VARDATA field contains the non-key fields of the pooled tables, stored in an unstructured way. These
are also compressed by the database interface. The length of the VARDATA field is stored in the DATALN
field.
DESCRIBE THE ADVANTAGES AND DISADVANTAGES OF POOLED AND CLUSTER TABLES
Pooled and cluster tables contain far fewer tables, as a direct result of the combination of tables and of
data compression.
This translates into fewer different SQL statements.
The main disadvantage of pool and cluster tables is the limited database functionality. There is no support
for primary or secondary indices, database views, ABAP JOINs, or Table Appends. Moreover, the data in
these tables can only be accessed through OPEN SQL .

STRUCTURE OF AN INDEX
An index is a copy of the database table containing only the key fields. As data in an index is sorted, it can
be accessed and retrieved instantly. Indexes also contain a pointer from the index entry to the
corresponding table entry.
When index is used for data retrieval, all fields constituting the index will participate in the WHERE clause.
In the example shown in the slide, the SELECT * statement is used to fetch data from the SCARR table
where the value of CARRID is LH. Therefore, binary search is used to locate the records in data table. LH is
in the first position in the WHERE clause as it has the maximum number of selections, 14.
 Index should be as small as possible – use only fields that are frequently used in where clause
 Order matters – where clause match the index fields order
 Contain significant fields only
 Index resorted upon +, -, edit. Hence too many indexes on a table updated frequently slows
things
 Indexes on table are as disjunct as possible
ACCESSES WITH INDEXES
The function of the database optimizer is to determine which index should be used by the database for
accessing data records. When you use the SELECT * statement with carname as Lufthansa, the database
optimizer selects the SCARR NAM index table to fetch data from the SCARR table.
There are two types of indexes: Primary and Secondary. The index type of a particular index can be
determined by its three-place index ID. If the index ID is zero, it denotes a primary index.
Customers can also create their own indexes on SAP tables. The index IDs for such indexes always begin
with either Y or Z.
Database optimiser decides which index on the table should be used
Each tale has 1 primary index and o…* secondary index
Primary index is created automatically based on key fields
Secondary index is mostly non-unique, but unique is possible.
Table index has a three character id. 0 is reserved for primary index, the ids of customer indexes must begin
with Y or Z.
DATA ACCESS USING THE BUFFER
You can use table buffers to increase performance when reading records from a table. The buffers reside
locally on the application servers. During the initial access, data is read from the database. Thereafter, data
remains loaded into the buffer and is accessed directly from it. This speeds up the whole process.
Table buffering increases performance when the records of the table are read.
 Full buffering – when a record is accessed, all the records of the table are loaded into the buffer
 Generic buffering – when a record of the table is accessed, all the records whose left justified
part of the key is same are loaded into the buffer
 Single record buffering – only the record that was accessed is loaded into the buffer
FULL BUFFERING
Full buffering means that a table is either completely buffered or not buffered at all. In full buffering, when
a single record is accessed, all the records of that table are also loaded into the buffer. There are three
points to be kept in mind while using full buffering. These are
the size of the table to be buffered;
the number of read accesses; and

the number of write accesses.
It is commonly observed that the smaller the table is; the more frequently it is read and the less frequently
it is written. This makes it ideal for full buffering. It is also recommended for tables that have frequent
accesses to records that do not exist.
This is suited for small tables. Also used for tables that have frequently access to records that do not exists.
GENERIC BUFFERING
With generic buffering, when you access a particular record, all other records whose generic key fields
match this record are loaded into the buffer. The generic key for a table is the left-justified part of a
primary key that is specified when the buffering type is selected.
Use only if certain generic areas of table are used for processing. Client dependent, fully buffered tables are
automatically generically buffered. The client field is the generic key.
SINGLE-RECORD BUFFERING
Single-record buffering is preferred for

records that are accessed with SELECT SINGLE command; and
tables in which the individual entries are repeatedly accessed.
In single-record buffering, only those records that are actually accessed are loaded into the buffer. This can

save a lot of storage space in the buffer compared to generic and full buffering. However, in this case, the
overhead for buffer administration is higher than that for generic or full buffering.
Single record buffering is recommended particularly for large tables in which only a few records are
accessed repeatedly with SELECT SINGLE. All the access to the table that do not use SELECT SINGLE bypass
the buffer and directly access the database.
TABLE BUFFERING
The buffers reside locally on the application servers. During initial access, data is read from the database.
Thereafter, data remains loaded into the buffer and are accessed directly from it, making the data access
easier and faster. However, another program can change this data in the database. Therefore, data must be
synchronized.
BUFFER SYNCHRONIZATION 1
As the buffers reside locally on the application servers, they must be synchronized after any data has been
modified in a buffered table. This synchronization occurs at periodic intervals laid down in the system
profile.
Let us understand this process with an example.
As shown here, two application servers need to access Table SCARR in the database. Server 1 first reads the
records from Table SCARR on the database. This table is then loaded into a local buffer on server 1. This
local buffer is subsequently used by server 1 to access the data.
BUFFER SYNCHORIZATION 2
Here, Server 2 accesses the records from Table SCARR in the database and loads it into its local buffer.
If a user on Server 1 deletes certain records from the SCARR table and updates the database, then Server 1
writes an entry in the synchronization table and updates its local buffer.

A user on Server 2 can still access the deleted records because the records reside in his local buffer, even
though they no longer exist in the database table. If the same access had been made through an application
program to Server 1, it would have replied stating that the records no longer exist.
The synchronization of the servers takes place at fixed time intervals. During synchronization, both servers
check the synchronization table to look for any modifications.
Server 2 now realizes that the SCARR table has been modified by server 1 and immediately invalidates the
table in its local buffer. Server 1, on the other hand, does not need to invalidate the table in its buffer, since
it had made the modification initially. Therefore, it continues to use the table in its buffer to access the
SCARR table.

After the table in its buffer is invalidated during the synchronization process, Server 2 accesses the SCARR
table again. It does this through the database. The SCARR table from the database is now reloaded into the
local buffer of Server 2.
DECISION TREE FOR BUFFERING
This slide illustrates a decision-making tree for buffering tables. It illustrates the decision-making process
involved in buffering tables. It is seen that buffering significantly increases performance. This is because
table buffers reside locally on an application server and are refreshed at regular intervals. However, it is
important to select the right type of buffering. Another crucial point is that the more frequently a table is
read; and the less frequently its contents are changed, the better it is to buffer the table.

17 INPUT CHECKS
FIXED VALUES
If you can input only a limited set of values while creating a domain, then these values are defined as fixed
values. These can either be listed individually or defined as an interval. Moreover, fixed values generate F4
Help. As soon as screen entries are made, the fixed values are immediately used as check values.
When fixed values are specified, the value range of the domain gets limited by these values. The value
range of a field is determined by its data type and field length.
Fixed values can be either listed individually or as an interval
VALUE TABLE
The value range of a field can be defined using a value table. You can define the value range of a field by
specifying a value table in the domain. Validation occurs only after a foreign key is defined for a field or
component. In such cases, the system proposes the value table as a check table.
Value table has a short description.

INSERTING A DATA RECORD
This slide illustrates the flight booking details of a customer with American Airlines (AA). The user places an
inquiry whether the booking can be made at counter 8. While Table SBOOK mentions all the flight bookings
of the airlines, Table SCOUNTER contains all the valid counters of the airlines. If an entry is made in field
COUNTER of table SBOOK, you must ensure that only valid counters are entered. Therefore, these counters
must be stored in table SCOUNTER.
VIOLATION OF THE FOREIGN KEY CHECK
The booking entries made in table SBOOK are rejected as no corresponding data record for COUNTER is
selected from table SCOUNTER. The customer’s request for booking this particular flight at counter 8 is
rejected as the counter for American Airlines (AA) is 1 rather than 8. Such relationships between two tables
are defined in the ABAP Dictionary using foreign keys which must be defined explicitly for the fields. By
using foreign keys, consistency of data is ensured as data that is entered is matched against the existing
data.

FOREIGN KEY FIELDS/CHECK FIELDS
Let us understand how to use foreign key fields using two tables, SBOOK and SCOUNTER. Here, Table
SBOOK is the foreign key table. Its purpose is to ensure that only valid carrier counters can be assigned to a
booking.
On the other hand, Table SCOUNTER is the check table and contains exactly the same information. Each
counter in this table has three key fields; namely MANDT, CARRID, and COUNTNUM.
You can define the foreign key by assigning these three fields to the fields of the foreign key table which is
used to enter the input on the screen. The entry is accepted only if the entry represents a valid counter.
The COUNTER field is called the check field for this foreign key defined for field SBOOK-COUNTER. This
means that the entry in this field is checked.
In the example shown here, a foreign key is defined for field COUNTER leading to three check tables,
SCOUNTER-CLIENT, SCOUNTER-CARRID, and SCOUNTER-COUNTNUM; and three foreign key tables, SBOOK-
MANDT, SBOOK-CARRID, and SBOOK-COUNTER.
Foreign key is only checked during screen input or screen value help. ABAP programs can ignore this and
modify table.
DATA CONSISTENCY THROUGH FOREIGN KEYS
The check table is a table whose key fields are checked. This table is also called as the referenced table.
The check field is the field of the foreign key table that is to be checked. A foreign key is a group of fields of
a table that is also the primary key for another table. Therefore, a foreign key links two tables, the check
table and the foreign key table. The check table, also known as the referenced table, is the table whose key
fields are checked. The foreign key table contains entries which must be consistent with the key fields of
the check table.

FOREIGN KEY DEFINITIONS IN THE CHECK FIELD
Domain equality between the check field and the referenced key field of the check table is a mandatory
requirement in the ABAP Dictionary. By using the same domain for the check field and the referenced key
field of the check table, there will not be any need to compare fields with different data types and field
lengths. While you can use different data elements, they must always refer to the same domain. If domains
are not equal, the foreign key will not be consistent. If the domain of the check field contains a value table,
the value table can act as check table, if the value table does not have any foreign key. Similar to check
constraint.
Specifying a value table does not automatically provide value help and input validation. To make the entire
value help and validation functions available, you must also define an appropriate foreign key.
However, for all other foreign key fields, only the data type and the field length are required to be equal.
CHECK TABLE NOT EQUAL TO VALUE TABLE
This slide illustrates an example of a foreign key definition. It shows the system proposal for the field
AGENCYNUM in SBOOK, on the basis of the value table in the domain.

Let us assume that SBUSPART is the check table. For check table SBUSPART-CLIENT, the foreign key table is
SBOOK-CLIENT, while for check table SBUSPART-BUSPARTNUM, the foreign key table is SBOOK-
AGENCYNUM.
However, this proposal is not correct. The SBUSPART table contains all the business partners of airline
carriers. However, only agencies are allowed for field SBOOK-AGENCYNUM. Table SBUSPART, therefore,
contains invalid data for this field. In fact, table STRAVELAG is the correct check table. It is a subset of table
SBUSPART owing to its foreign key definition on field AGENCYNUM.
SEMANTIC ATTRIBUTES
Cardinality is a semantic attribute that describes the foreign key relationship with regard to the number of
records of the check table that are assigned to records of the foreign key table. The cardinality must be
defined with regards to the check table.
Cardinality is always defined from the check table.
A foreign key field can identify a table entry based on its type. There are four types of foreign key fields:
Not specified means that there is no information about the kind of foreign key field.
No key fields or candidates suggests that the foreign key fields are neither primary key fields of the foreign key
table nor do they uniquely identify a record of the foreign key table.
Key fields or candidates indicates that the foreign key fields are either primary key fields of the foreign key
table or they uniquely identify a record of the foreign key table.
Key fields of a text table means that the foreign key table acts as a text table in the check table in cases where
the key of the foreign key table only differs from the key of the check table in an additional language key
field.
 1:1
 1:N (many)
 1:C (atmost one, some check entries are not used)
 1:CN (many, some check entries are not used)

TEXT TABLE
Table SMEAL depicts information about in-flight meals provided to the passengers. The meal names are
maintained in another table, SMEALT. Table SMEALT is the text table for table SMEAL as the key of SMEALT
comprises the key of SMEAL and an additional language key field. An explanatory text for all the key entries
of SMEAL can also be given in Table SMEALT.
You must link the text table SMEALT with table SMEAL using a foreign key to link the key entries with the
text. Key Fields of a text table must be selected for the type of the foreign key fields.
Text table has all key fields of normal table plus an extra key which is the language key field.
For each table, you can define one foreign key of type text-table only. This means that each table can have
a maximum of one text table assigned to it.

18 OBJECT DEPENDENCIES
ACTIVE AND INACTIVE VERSION
The active version of an ABAP Dictionary object is the one that is accessed by the components of the
runtime environment, such as the ABAP processor and database interface.
On the other hand, the inactive version is created when an active object is changed. It does not affect the
runtime system. The inactive version can be changed into an active version through a process called
activation.
The slide here illustrates change in the status of an object. Initially, an active structure contains three fields.
When an additional field is added to this structure in the ABAP Dictionary, it results in two versions of the
same structure. One is an active version containing the original fields and the other is an inactive version
containing the additional field. During the activation process, the inactive version replaces the active
version. Thus, the inactive version becomes the active version resulting in only a single active version with
the four fields.
RUNTIME OBJECTS
In the ABAP Dictionary, information about a structure or table is stored in data elements and structure
definitions. The runtime object combines this information into a structure which is so designed that it can
be easily accessed from ABAP programs.
You can create runtime objects for all ABAP Dictionary objects that can be used as types in ABAP programs,
such as data elements, table types, and views. These objects hold varied information about the overall
structure, the individual structure fields, as well as additional information regarding client dependence,
buffering, and key fields required for accessing the table data.
the runtime object has the following information:

 Information about the overall structure, for example number of fields
 Information about the individual structure fields such as field name, position etc
 Information required by the db interface to access the table data such as client dependence,
buffering, key fields and so on.
WHERE-USED LIST
When some change occurs in a domain, then all the data elements, structures, and tables referring to this
domain must be reactivated. This is done so that all affected runtime objects adjust to the changed type
information.
Each object in the ABAP Dictionary maintains a ‘where-used list’ that provides information about all the
other objects that refer to it.
Using this list, you can determine the direct and indirect usages of the ABAP Dictionary object. For this, you
need to define the usage object types that have to be included in the search; for example, all structures and
tables using a data element.
You can also search the usages of objects that are not part of the ABAP Dictionary, such as all programs,
using a table.
Object usage search can also be limited by the development class or user namespace.
If an object that is already active is modified, this can affect other objects that use it directly or indirectly.
Objects that use another object either directly or indirectly are called dependent objects.
THE REPOSITORY INFORMATION SYSTEM ABAP DICTIONARY

This slide illustrates how to conduct search for ABAP Dictionary objects and their users with the help of the
general Repository Information System which includes Repository Information System ABAP Dictionary. You
can call the Where-used lists for Repository objects from the information system to search for objects by
their attributes. Additionally, you can search for all objects by development class, author, and date of last
change.
The active version of an ABAP Dictionary object is the one that is accessed by the components of the
runtime environment, such as the ABAP processor and database interface.
On the other hand, the inactive version is created when an active object is changed. It does not affect the
runtime system. The inactive version can be changed into an active version through a process called
activation.
The slide here illustrates change in the status of an object. Initially, an active structure contains three fields.
When an additional field is added to this structure in the ABAP Dictionary, it results in two versions of the
same structure. One is an active version containing the original fields and the other is an inactive version
containing the additional field. During the activation process, the inactive version replaces the active
version. Thus, the inactive version becomes the active version resulting in only a single active version with
the four fields.
CHANGE TO TABLES
An ABAP program can correctly access a database table only when the runtime object of the table and its
structure in the database are mutually consistent. Changes in tables must be reflected in the database
structure of the table.
However, the database structures need not be modified for certain changes to the ABAP Dictionary, such as
changes in the order of the non-key fields in the ABAP Dictionary. In such cases, the changed structure is
simply activated in the ABAP Dictionary and the database structure remains unchanged.

HOW IS THE STRUCTURED ADJUSTED?
Any change in definition in the ABAP Dictionary should evoke a matching adjustment to the database
tables. You can do this by
deleting the database table and re-creating it;
changing the database catalog; or
converting the table.
In the first method, the database table is first deleted. Next, the inactive table in the ABAP Dictionary is
activated and re-created on the database.
The second method involves changing the definition of the database table. It does not result in any loss of
data.
The third method requires the maximum time for adjusting a structure as it deals with the conversion of
tables. If the table does not contain any data, it is deleted on the database and created afresh. However, if
data exists in the table, the table structure is adjusted with ALTER TABLE. If the database system fails to
make any adjustments, the structure is adjusted by converting the table.

CONVERSION PROCESS 1
Let us assume that the table TAB in the ABAP Dictionary is so modified that the length of its Field 3 reduces
from 60 to 30 places. This results in an active table version where field 3 still has a length of 60 places and
an inactive table version where field 3 has 30 places.
As the active version of the table was created on the database, the field 3 in the database table still has 60
places. A secondary index with the ID A11, which was also generated in the database, is specified for the
table in the ABAP Dictionary. This disparity between the tables can be removed through conversion.
The first step is to lock the table against further structure changes. This is because any such changes would
result in loss of data. Additionally, all views dependent on the table are inactivated.
The next step is to rename the table in the database and delete all the indexes on the table. The name of
the temporary table that is newly created is assigned the prefix QCM, followed by the table name.
Therefore, in the example here, the name for the temporary table is QCMTAB.

The third step involves activating the inactive version of table TAB in the ABAP Dictionary. This table is then
created in the database with the new structure and the name QCM8TAB. The primary index on the table is
also generated in the database.
However, the newly created database table does not contain any data. As a result, it does not exist in the
database under its original name during conversion. If a program were to access the table, it would not be
able to execute. Therefore, it is essential that applications do not access the tables during conversion. The
third step involves activating the inactive version of table TAB in the ABAP Dictionary. This table is then
created in the database with the new structure and the name QCM8TAB. The primary index on the table is
also generated in the database.
However, the newly created database table does not contain any data. As a result, it does not exist in the
database under its original name during conversion. If a program were to access the table, it would not be
able to execute. Therefore, it is essential that applications do not access the tables during conversion.
In the fourth step, data is copied back from table QCMTAB into table QCM8TAB so that both tables have
the same data. This duplication necessitates more storage space.
When data is copied from one table to another, the system faces a database commit after 16 MB. As a
result, the conversion process inevitably requires 16 MB resources in the rollback segment. This ensures
that the existing database lock is released with the Commit and then requested again before the next data
area to be converted is edited.

In the fifth step, table QCMTAB is deleted from the database.

Next, table QCM8TAB is renamed as TAB, the secondary indexes defined in the ABAP Dictionary for the
table are re-created, and the views on the table deleted in the first step of the conversion are also activated
again in the database.
Finally, the lock that was set at the beginning of the conversion is deleted. If the conversion ceases, the
table remains locked and a restart log is written.
Steps
 Lock TAB
 Rename TAB to QCMTAB (prefix)
 All secondary indexes deleted
 Inactive versions activated as QCM8TAB with new structure and primary index
 QCMTAB – old structure, data, no 2ry, only 1ry
 QCM8TAB – new structure, no data, no 2ry, only 1ry
 Load data from QCMTAB to 8 using MOVE-CORRESPONDING
 Db commit after 16mb during commit
 Delete QCMTAB
 Rename 8 as QCMTAB
 Create 2ry indexes
 Remove lock
POSSIBLE PROBLEM DURING CONVERSION
You can face three kinds of problems during conversions. If there is excess data in tablespace during the
conversion process, such that it overflows, the process of conversion will cease.
Another problem is that if you shorten the key of a table, you will be unable to distinguish between the
new keys of the existing records of the table. When you reload the data from the temporary table, only one
of these records can be accessible.

The third problem deals with invalid change of type. As the ABAP statement MOVE-CORRESPONDING is
used during the conversion process, only those type changes that can be executed with MOVE-
CORRESPONDING are feasible.
RESUMING TERMINATED CONVERSION
If a conversion terminates midway, the table cannot be edited with the maintenance tools of the ABAP
Dictionary. You require transaction SE14 to resume the process. You can use analysis tools such as the
object log and the syslog to determine the cause of the error and the present state of all the tables involved
in the process. When conversions are terminated, you can use either of the two options in the database
utility, Continue adjustment or the Unlock table.
The Continue adjustment option allows you to resume the conversion from where it was terminated.
However, the Unlock table option only deletes the existing lock entry for the table. You must not use this
option if the conversion gets terminated in step 3 or step 4 when the data only exists in the temporary
table.
Failed conversions
 Cannot use se11 to edit table as lock still exists
 Analyse using db utility se14
Precise reason can be found in object log. If not enough info in object log, check sys log (sm21) or dump
analysis (st22).
Two options available are continue adjustment or unlock table
APPEND STRUCTURES 1

Append structures allow you to append fields to an SAP standard table without the need to modify the
table definition.
A single append structure is always assigned to exactly one table. A table, however, can have several
append structures.
When a table is activated, the active append structures for that table are located and their fields appended
to the table.
If an append structure is created or changed, the table to which it is assigned is activated and the changes
take effect in the table. Like all structures, the append structure also defines a type that can be used in
ABAP programs.
APPEND STRUCTURES 2
Append structures are created by customers in their own namespace. As a result, they are protected
against overwriting during an upgrade.
A conversion is not essential when you add an append structure or insert fields into an existing one. This is
because, following Release 3.0, the order of the fields in the ABAP Dictionary can differ from that on the
database. The structure is adjusted according to changes made in the database catalog. Therefore, when
the table is activated in the ABAP Dictionary, its definition is changed and the new field is appended to the
database table. You can import new versions of the standard tables during the upgrade.
APPEND STRUCTURES 3
After activating the new version of the SAP standard table, the new field is appended to the database table.

ENHANCEMENT OF TABLES
This slide illustrates how a customer can enhance the structures and tables defined by SAP in the ABAP
Dictionary.
One method is Customizing includes.
With this variant, certain places within a structure or tables are already reserved for enhancements.
However, you need to create the associated Includes first.
The second method is the use of Appends.

With this method, any field without previous reservation can be appended to the end of structures or
tables.
Customers create append structures in their namespace. The append structures are thus protected against
overwriting during an upgrade.
No append structure for pooled or clustered table.
Tables containing long field (data type LCHR or LRAW) cannot be extended with appends, as long fields are
the last field in the db.
The fields in the append structure must be in the customer namespace beginning with YY or ZZ.

19 views and maintenance dialog
WHY DO YOU NEED VIEWS?
You typically find data for an application object distributed on several database tables. Therefore, you need
database systems to define application-specific views on data in several tables. These are known as views.
You can combine data from several tables in a meaningful way with the help of a view or join. Further, you
can hide irrelevant information through projection. Alternatively, you can implement selection to display
only those data records that satisfy certain conditions. You can display the data in a view in a format that is
similar to the one used in the extended table maintenance.

STRUCTURE OF A VIEW - STARTING SITUATION
Let us understand the structure of a view and how to select data using this view. As shown here, table
SCARR contains two entries while there are four entries in table SFLIGHT.
These tables are first appended to one another. This creates a cross product of the two tables, in which
each record in SCARR is combined with each record in SFLIGHT.
STRUCTURE OF A VIEW - JOIN CONDITION
The result in the cross product of the two tables needs to be limited with a join condition. This condition
defines the relationship between the records of the two tables. Here, CARRID field for SCARR is compared
with the CARRID field for SFLIGHT. The join condition is then: SCARR-CARRID = SFLIGHT-CARRID.
Hence, all the records whose entry in Field 1 is not identical to the entry in Field 3 are removed from the
cross product. Therefore, the column for Field 3 is not required in the view.

STRUCTURE OF A VIEW - FIELD SELECTION(PROJECTION)
Sometimes certain fields of a table involved in a view may not be relevant.

You can specifically define the set of fields to be included in the view or projection. As shown here, the
PLANETYPE field is not relevant and can, therefore, be hidden.
please note projection involves one table only, you are interested in a subset of fields in a table
STRUCTURE OF A VIEW - SELECTION CONDITION
You can use a selection condition to restrict the set of records that can be displayed with the view. As
shown here, only those records with value DL in the CARRID field are required with the view. Therefore, a
selection condition can also be formulated with a field that is not contained in the view.

HOW ARE TABLES (BASIS TABLES) LINKED TO VIEWS?
This slide depicts three different tables consisting of booking details of in-flight passengers that are relevant
to travel agencies. Table SCUSTOM contains customer-related data, such as name and address of the
customers. Table SBOOK includes booking data, such as the airline, flight number, and passenger number.
Table SPFLI holds flight data, such as the city of departure and the city of arrival.
These tables contain different fields which are used to create a view that presents booking data. These are
the join conditions:
SBOOK- CLIENT = SCUSTOM- CLIENT
SBOOK-CUSTOMID = SCUSTOM-ID
SPFLI- CLIENT= SBOOK- CLIENT
SPFLI-CARRID = SBOOK-CARRID
SPFLI-CONNID = SBOOK-CONNID
STRUCTURE OF THE VIEW
Here, you have the final view with the fields selected from different tables. If you want to obtain the
booking details for an individual customer, then select the respective records for keys MANDT and
CUSTOMID in Table SBOOK. You can also obtain the flight data from Table SPFLI by choosing the available
records for the keys MANDT, CARRID, and CONNID.

DATA SELECTION WITH VIEWS
The ABAP program shown here illustrates how to use the SELECT statement to fetch data from the view
‘sv_flights’.
SQL: INNER JOIN SYNTAX
You can formulate the join condition directly in OPEN SQL. However, you can also get the same result using
an Inner Join, as shown in the example.

INNER AND OUTER JOIN
The group of data that is selected with a view depends on whether the view implements an inner join or an
outer join. An inner join consists of only those records which have an entry in all the tables included in the
view. However, an outer join includes even those records for which there are no matching entries in some
of the tables. Therefore, an inner join can be considered as a subset of the outer join. While database views
always implement an inner join, maintenance views implement outer join.
DATABASE VIEWS
A database view is created on the database during activation after it is defined in the ABAP Dictionary.
Database interface directly passes access to the database view. If the definition of a database view is
changed in the ABAP Dictionary, the corresponding view created on the database must also be adjusted
accordingly. The adjustment is made by deleting the old view definition and re-creating another on the
database with a new definition. This is possible because a view does not contain any data.
DB views can be used in abap program as it exists in abap dictionary.
Db views implement inner join. Maintenance views implement outer join. Result of inner join is always a
subset the result of outer join.

DYNAMIC ATTACHMENT OF TABLE FIELDS IN DATABASE VIEWS
If you include an entire table in a database view, then all the fields of the included table become the fields
of the view. This allows you to explicitly exclude certain fields. Any changes made in the table are
automatically reflected in the view. Therefore, if an append structure is added to a table included in a view,
the fields added with the append structure also appear automatically in the view.
To include all fields in view, use * as field name. If you do not want to insert a field of the table in the view,
you must enter a – in the view field.
Using an append view is similar to enhancing the table with an append structure. An append view is
assigned to one database view. More than one append view can be created for one database view.
COLLECTING DATA WITH GENERATED MAINTENANCE MASK
An application object is the logical unit of data that is spread across multiple tables. The user can create,
display, and edit the data for such an application object as a whole. By using a maintenance view, you can
automatically allocate data on the underlying database tables. You must link all the tables used in a
maintenance view with a foreign key to form the join conditions from the foreign key in the maintenance
view. Additionally, you require a maintenance interface to generate the function modules that distribute
the data maintained in the view on the underlying tables.
Maintenance view provides the ability to maintain application objects. All tables in the view are linked by a
foreign key. You cannot specify join conditions unlike db view.

MAINTENANCE VIEW FROM A MAINTENANCE VIEW
The first screen shows a one-step maintenance view which depicts the data of the table lines as Table
Control. In this view, while you can change the function fields with a white background, you cannot do so
for the fields having a gray background.
The second screen displays a two-step maintenance view which opens by double-clicking a table line in
which the selected data record is presented clearly.
DEFINE MAINTENANCE VIEW 1
While creating maintenance views, you should

 select maintenance view as the view type;
 mention all the key fields of the primary table in the view definition;
 include the client field for client-dependent tables or views; and
 distinguish between the key fields and the function keys.

You can define the maintenance status for the entire table or view as
 read only;
 read, change, delete and insert (default setting);
 read and change; and
 read and change (with time-dependent views).
First define the key fields, then define the function fields. Don’t mix the order.
DEFINE MAINTENACE VIEW 2
This slide illustrates how to copy tables and view fields; apply selection conditions; define the maintenance
status; and activate the view.
To copy tables, you must first specify the primary table of the view, under the field Tables, on the tab page
Tables or Join Conditions. Next, place the cursor on the primary table and click Relationships. Select the
desired foreign key, and then choose Copy.
To copy the view fields, select the fields that you want to copy into the view on the View field tab page.
Activate Table fields to display all tables contained in the view; then select a table. As a result, the fields of
the selected table are displayed in a dialog box.
The selection conditions determine which data records can be selected via the view. For this, you need to
formulate restrictions to the data records on the Selection conditions tab page.
Similarly, the maintenance status defines how you can access the view data via the standard view
maintenance. You can define the maintenance status of the view on the Maintenance status tab page.
Finally, an activation log automatically shows up when errors or warnings occur during the activation of the
view

.
DEFINE MAINTENANCE VIEW
You can arrive at the generation environment for maintenance views in the SE11 screen in the view for
Tables/Views. To reach the initial screen of the maintenance transaction, select Utilities, then Table
maintenance generator, then choose Development, followed by Other tools, and finally select Table
maintenance view.
Here, enter the name of the table or the view. Next, select generated objects and choose Create/Change.
Subsequently, a prompt appears where you need to confirm that the maintenance modules should be
created.
This commences the process of generating the maintenance view. For this, you first need to start the
transaction SM30 and enter the table or view in the Table or View field for which you have generated the
maintenance view. Lastly, activate the Maintenance button.

ADVANTAGES AND DISADVANTAGES OF A MAINTENANCE VIEW
Let us look at some of the positive and negative aspects of using maintenance views.
A key advantage of using these views is that maintenance dialogs can be built better and faster than
otherwise possible. However, using maintenance views for data maintenance in standard operations may
lead to data inconsistencies. Therefore, it should be specifically used for entering that data in customer
tables or customizing tables for which there is no overlapping.
VIEW CLUSTERS AND MAINTENANCE VIEW
View clusters are a collection of maintenance views, which have been combined in one maintenance unit
for either business or technical reasons. This enables the maintenance of data that are similar from the
content point of view. You can navigate within the view cluster using the hierarchy of the tables or views
underlying the individual views. It is necessary to generate a maintenance view for every table or view
involved, which can in turn be combined in SE54 in a view cluster. The associated data can be maintained
by specifying the cluster name with transaction SM34.

ADVANTAGES
One major advantage of view clusters is the ease of navigation. By using view clusters, you can easily
navigate to each component of the object. This improves the maintenance of the data of a view cluster.
Another advantage of view clusters is the consistency attained while deleting, copying, saving, retrieving, or
manually transporting data. In fact, when an entry is deleted in a superior view, this is reflected in all the
dependent entries in the subordinate view.
Maximum 14 maintenance dialogs can be combined into 1 view cluster.
While maintenance views can be used to maintain only database tables that have 1:1 relationship with one
another, view clusters can be used for n:m relationships.
SAP STANDARD FUNCTION: INPUT HELP
By using F4 help or the input help, the flight maintenance personnel obtains a list of flights belonging to
airline LH along with their respective destinations and flight numbers. This example shows that the basic
purpose of F4 help is to display a list of possible values for a screen field. You can activate the input help
option either by selecting on the corresponding screen field or with F4 function key.

INPUT HELP REQUIREMENT
The input help of a screen field (or a search field) can function after certain requirements are met:
You must program the system to consider (in the input help) the information about the context. This
should include the user entries in the current input template and the information obtained in the dialog
steps earlier.
The input help must provide the user with a set of values for selection. It should also specify the data that
is to be displayed in that list of possible values.
The input help option must be interactive in a way which enables the user to select a value from the list
of possible values displayed.
The input help must send the value back to the search field when the user selects a value.
ABAP DICTIONARY OBJECT SEARCH HELP
The search help object in the ABAP Dictionary is used to define an input help. The exchange of data
between the input template to the F4 help and back is controlled by the interface of the search help. When
a user selects a value, the interface determines the context data to be used, as well as the data to be
returned to the input template.
The internal behaviour of the search help comprises the selection method which determines the values to
be displayed, as well as the dialog behaviour that describes the interaction with the user.

SELECTION METHOD OF A SEARCH HELP
It is important to define a selection method for a search help when the data relevant for input help are
distributed on several objects. For this, you need to specify a database object from which you can select the
data for the input help by defining a table or a view as selection method.
Both tables and views can be used as a selection method. You can use a view for this purpose if the search-
related data are distributed on several tables.
On the other hand, you can use the table as a selection method if the data is placed in one table or in the
corresponding text table.
Maintenance views are not used for search help. A database view is used instead. However db uses inner
join, if you want outer join then choose a help view as the selection method.
DESCRIPTION OF THE DIALOG BEHAVIOUR
The dialog box for displaying the hit list presents the possible values in list format from which the user can
select the required entry. If the hit list is huge, the user can shrink it by setting additional restrictions for the
attributes of the entry in the dialog box for restricting values. This not only improves the clarity of the list
but also reduces the system load.
In addition, the dialog type of a search help determines whether the system displays the dialog box for
restricting values before presenting the hit list.

INTERFACE OF A SEARCH FILE
Both the IMPORT and EXPORT parameters of a search help constitute your interface. While defining the
parameters of a search help, you must specify whether these are IMPORT parameters, which means they
can copy data to the input help; or whether they are EXPORT parameters, meaning that they can return
data from the input help. The search help attachment defines the location from which the IMPORT
parameters of a search help get their values, as well as the screen fields in which the contents of the
EXPORT parameters of the search help are returned.
HOW DO YOU USE SEARCH HELP?
When the input template is defined, the semantic and technical attributes of a screen field, such as the
type, length, F1 help, and others are often not defined directly. Therefore, a reference to an ABAP
Dictionary field is specified in the Screen Painter and the screen field takes on the attributes of this field
from the ABAP Dictionary. Similarly, you can also define the input help of a screen field. The search help
attachment mechanism assigns the search help to the field.

SEARCH HELP ATTACHMENT IN THE ABAP DICTIONARY
You can attach a search help to a field of the ABAP Dictionary in three ways:
You can attach a search help directly to a field of a structure or table, if the definition of the search help
that is to be attached is analogous to that of a foreign key. Then the system proposes to define the
assignment.
The system automatically offers a list of possible values in the input help and displays the key fields if a
field has a check table.
You can attach a search help to a data element so that it is available for all the relevant fields. It is also
important to define an EXPORT parameter of the search help in the attachment for data transfer.
OVERVIEW:MECHANISM FOR THE INPUT HELP
The R/3 System uses numerous mechanisms for offering meaningful input help for as many screen fields as
possible. If there is more than one such mechanism available for a field, then the one that is furthest left or
at the top of the above hierarchy is used.

PERFORMANCE OF AN INPUT HELP
If the system has to search vast amount of data in the selections for an input help, then its performance
may get adversely affected if it takes huge amount of time. Therefore, you need to take measures to
optimize the accessing behaviour for the selection method, especially when the selection uses a view.
You can do this by restricting the hit list with additional conditions, if the number of entries in the selection
method is very large. This also helps increase the clarity of the hit list.
Additionally, you can create an index on the fields which are used to formulate the restrictions.
However, you should always check whether the selection method can be buffered, if the number of entries
in the selection method is relatively small.
ALTERNATIVE SEARCH PATHS.
As shown here, a customer obtains the booking number for her flight and a travel agent finds out the
number of bookings made at his agency by following alternative search paths. This indicates that the
entities in the relational data model in a real world scenario are identified by their attributes. These
attributes can vary from one user to another and from one situation to another. Therefore, you need
search paths that permit access to the data using non-key fields. There can be several search paths for one
field.
As a developer, you can merge a set of search helps into a new object in the R/3 System so that there are
multiple alternative search paths for describing an input help. Such search helps that combine several
search paths are called collective search helps.

COLLECTIVE SEARCH HELP AND ELEMENTARY SEARCH HELP
A collective search help can be attached to fields, tables, and data elements through an interface of
IMPORT and EXPORT parameters. This is similar to how an elementary search help executes exchange of
data with an interface.
Only one search help can be attached to a field, table, or data element. Therefore, several search paths are
attached with a collective search help. The elementary search helps are included as the parallel tab pages in
a collective search help.
You must assign the collective search help parameters to the interface parameters of each included search
help.
APPEND SEARCH HELP
You may need to enhance the standard SAP collective search helps with your own elementary search helps.
In such cases, you can make use of an append search help, which is a collective search help that is assigned
to another collective search help. The append search help is positioned in the customer’s namespace and it
utilizes the interface of its appending objects. Typically, the user can create the search helps included in the
append search help.
If SAP has already provided the required elementary search help, then the customer is only required to add
it to his own append search help.

VIEW AS SELECTION METHOD OF A SEARCH HELP
You can define the set of possible entries for an input help by the entries in a primary table, which can be
supplemented by entries from secondary tables. You can implement this view on the data with a help
view.
The outer join logic used for maintenance views is also used for the help views. Although help view is
defined similarly to a maintenance view, help views can only be used as selection methods in search helps.
Help views start with H_Y or H_Z
FURTHER OPTIONS OF SEARCH HELPS
This slide illustrates the various search help options available to the user:
Default values are values which are preassigned to a parameter. You can use a default value to create a
simple selection condition for a field of the selection method.
Hot keys are keys with a single letter or a digit assigned to an elementary search help.
Another option is to hide individual search help inclusions in a collective search help. This helps in
deactivating individual search paths that are not wanted in a system.
Additionally, you can use parameters of an elementary search help as display fields in the dialog box for

restricting values.
DEVIATION FROM STANDARD: SEARCH HELP EXIT
Generally, a search help defines the system-wide standard for an input help.
However, in some cases, the user may deviate from this standard. A search help exit is used for such
purposes. A search help exit is a function module having a standardized interface. If it occurs in a search
help, it is called before each step of the process.
The administrative data of the help processor is passed via the interface. The search help exit can
manipulate this data. The administrative data also includes the information about the next step to be
executed.
ALTERNATIVE DISPLAYS OF AN INPUT HELP
There are three presentation forms for input helps in the SAP System:
List box
Control
SAP Dialog
The list box is the user-friendly input help for clear one-column lists.
As an application developer, you can offer a field as list box and store this information in the Screen Painter
for the corresponding field. Alternatively, you can show input help as a list box with modeless control or
with a modal dialog implemented with SAP screen technology.

SAP-ABAP supports two types of programs - Report Program and Dialog Program.
If your ABAP program demands user input , Dialog programming is used.
A user dialog is any form of interaction between the user and the program and could be any of the
following
 Entering data
 Choosing a menu item
 Clicking a button
 Clicking or double clicking an entry
Dialog program is also used when we need to navigate back and forth between screens
Dialog programs are created with type as 'M' - Module Pool. They cannot be executed independently and
must be attached to at least one transaction code in which you specify an initial screen.
Difference between Report and Dialog Programs
Report Program:
A report is a program that typically reads and analyses data in database tables without changing the
database.
Dialog Program:
A dialog program allows you to work interactively with the system and to change the contents of the
database tables. Each dialog program has a certain sequence of screens that are processed by the system
one after the other.

A Sample transaction processing in Dialog Programming
Components of Dialog Program

Unlike report which generally entails the creation of one autonomous program which can be executed
independently of other objects, dialog program development entails development of multiple objects none
of which can be executed on its own. Instead all objects are linked hierarchically to the main program
and are executed in a sequence dictated by the Dialog Main Program .
The components of a dialog program are:
Transaction code
The transaction code starts a screen sequence.
You create transaction codes in the Repository Browser in the ABAP Workbench or using Transaction SE93.
A transaction code is linked to an ABAP program and an initial screen.
You can start a screen sequence from any ABAP program using the CALL SCREEN statement.
Screens
Each dialog in an SAP system is controlled by one or more screens.
You create screens using the Screen Painter in the ABAP Workbench through transaction SE51
Each screen belongs to an ABAP program.
These screens consist of a "screen mask" or "layout" and its flow logic. The screen has a layout that
determines the positions of input/output fields and other graphical elements such as checkboxes and radio
buttons. A flow logic determines the logical processing within screen.
GUI status
Each screen has a GUI status(es) which are independent components of a program.
This controls the menu bars, standard toolbar, application toolbar , with which the user can choose
functions in the application.
You create them in the ABAP Workbench using the Menu Painter.
ABAP Program
Each screen and GUI status in the R/3 System belongs to one ABAP program.
The ABAP program contains the dialog modules that are called by the screen flow logic, and also process
the user input from the GUI status.
ABAP programs that use screens are also known as dialog programs.
In a module pool (type M program); the first processing block to be called is always a dialog module.
However, you can also use screens in other ABAP programs, such as executable programs or function
modules. The first processing block is then called differently; for example, by the runtime environment or a
procedure call. The screen sequence is then started using the CALL SCREEN statement.
Screen Flow Logic
Screen Flow logic is primarily divided into four components.

Process Before Output (PBO) event: which is processed before the screen is displayed
Process After Input (PAI) event: which is processed after a user action on the screen
Process on help request (POH): which is processed when F1 is pressed
Process on value request (POV):which is processed when F4 is pressed
Dynpro
A screen together with its Flow logic is called a Dynpro ("Dynamic Program" since the screen flow logic
influences the program flow)
Each dynpro controls exactly one step of your Dialog Program.
The screens belonging to a program are numbered. The screen flow sequence can be either linear or
cyclic. From within a screen chain, you can even call another screen chain and, after processing it, return to
the original chain. You can also override the statically-defined next screen from within the dialog modules
of the ABAP program.
ABAP Module Pool

On a PBO or PAI event a Dynpro calls an ABAP dialog program. Collection of such programs is called the
ABAP module pool.
For example modules called at the PAI event are used to check the user input and to trigger appropriate
dialog steps, such as the update task.
All dynpros to be called from within one transaction refer to a common module pool.

Structure of a Dialog Program
Process Flow for a Dialog Program
What is Customer Exits ?
Customer exits are "hooks" provided by SAP within many standard programs, screens and menus on which
customers may "hang"custom functionality to meet business requirements. More on this in a moment...
Types of Customer Exits
There are three main types of customer exits:
 Function Module Exits
 Screen Exits
 Menu exits
Function Module Exit: It allows customer to add code via a function module at a specific location in an
SAP application program
Syntax: CALL CUSTOMER-FUNCTION '004'
Menu Exit: It allows customer to add items to a pull down menu in a standard SAP program. These items
may be used to call add-on programs or custom screens.
Format: +CUS ( additional item in GUI status )
Screen Exit: It allows customer to add fields to a screen in an SAP program via a subscreen. The subscreen
is called within the standard screen's flow logic.
Format: CALL CUSTOMER-SUBSCREEN CUSTSCR2
Example of a Screen Exit:
In transaction CAT2 - Time Sheet Entry, HR wishes to include an interactive acknowledgment that knowingly
submitting incorrect data is grounds for dismissal.
Example of a Menu Exit:

In transaction SE38 - ABAP Editor, the development team wishes to include a menu link to transaction SE80
- Object Navigator for ease of use.
BEFORE

AFTER
Example of a Function Module Exit :

The company wants the bank details of the Vendors in the Vendor creation to be mandatory event .So it
must flash a error message that 'Please Enter the bank details'
BEFORE

AFTER
Locating Customer Exits

In transaction SMOD and look into the details-

Or in transaction SE81 you can use the appropriate application area
Create a Customer Exit

To create a customer exit you first need to create a project in transaction CMOD

Later you assign the Customer Exit to your project.
What is a USER EXIT?
User Exit serve the same purpose as Customer Exits but they are available only for the SD module. The exit
is implemented as a call to a Function Module. The code is written by the developer.
Selection Screen
"Selection screen" is the screen where one specifies the input values for which the program should run.
The selection screen is normally generated from the

Parameters
Select-Options
Syntax
Selection-screen begin of screen <screen #>
selection-screen begin of block <#> with frame title <text>
.........
.........
selection-screen end of block <#>
selection-screen end of screen <screen #>
Parameters
Parameters helps one to do dynamic selection. They can accommodate only one value for one cycle of
execution of the program.
Syntax
Defining parameters as a data type

Parameters p_id(30) type c.

Defining parameters like a table field.
Parameter p_id like <table name>-<field name>.
Parameters can be Checkboxes as well as Radio buttons.

Parameters p_id as checkbox.Parameters p_id1 radiobutton group <group name>.
Parameters p_id2 radiobutton group <group name>.
Parameters can be listbox.

Parameter p_id like <table name>-<field name> as listbox
Select Options
A Select-Option is used to input a range of values or a set of values to a program
select-options s_vbeln for vbak-vbeln.
You can also define a select option like a variable

select-options s_vbeln for vbak-vbeln no intervals no-extension
SELECTION SCREEN: OVERVIEW
Selection screens – the interface between the program and the user – help limit the amount of data to be
read from the database.
You can generate a default selection screen, such as screen 1000, with input-ready fields. You use the
declarative language elements, PARAMETERS and SELECT-OPTIONS, to do so.
The concrete appearance of the selection screens, supplied by logical databases, is dependent on the
specified node name (NODES <name>).
You can create additional selection screens using SELECTION-SCREEN BEGIN OF and call them using CALL
SELECTION-SCREEN.
You can create variants to save selection screen values that are used repeatedly. A variant is required if a
report with a selection screen runs in the background. It can be recalled for use whenever it is needed.

DECLARING FIELDS WITH PARAMETERS
The PARAMETERS keyword is a declarative language element. Just as in the DATA statement, you can
declare parameters with TYPE or LIKE. The input-ready fields on the selection screen are then generated.
The names of the PARAMETERS fields can be up to eight characters long. You can maintain selection texts
by choosing the Goto menu and selecting Text Elements → Selection Texts.
Let us look at some options that you can use with the PARAMETERS keyword:
DEFAULT addition enables you to set values for a PARAMETERS keyword with the addition of a default
value.
MEMORY ID, when assigned, enables the system to automatically retrieve and display the current value
from the SAP memory.
OBLIGATORY is an addition where you declare mandatory fields. The user cannot leave the selection
screen until entries are made into these fields.
VALUE CHECK ensures that entries are checked for validity, but only if there is a reference to a dictionary
object that has a foreign key relationship.
AS CHECKBOX is a parameter in which you create a one-character field that contains a “ ” (space) or “X”.
You can evaluate the contents of the checkboxes in IF/ENDIF structures.
RADIOBUTTON GROUP is a group of radio buttons for the selection screen. Only one radio button in a
group can be active. You can evaluate the contents of radio buttons, using a CASE/ENDCASE control
structure. The selected radio button has the value “X” and all others have the value “ ” (space).
MODIF ID is an addition that simplifies dynamic modifications to the selection screen.

SELECTION WITH SELECT-OPTIONS
The SELECT-OPTIONS keyword is a declarative language element. It has the same eight-character naming
restriction as PARAMETERS.
Unlike the PARAMETERS keyword, SELECT-OPTIONS permits a range of values and complex selections,
instead of just a single input-ready field.
The SELECT-OPTIONS keyword generates an internal table with a standard structure and a header line.
This table has four columns:
Sign, which is an indicator meaning including or only
Option, which is a relational operator
Low, which specifies the lower limit
High, which specifies the upper limit

The use of FOR with your statement helps specify the field against which the system should check selection
entries.
Each line of the selection table formulates a condition using relational operators from Sign and Options.

SELECT-OPTIONS: POSSIBLE VALUES FOR SIGN AND OPTION
The internal table <seltab>, which is generated by using SELECT-OPTIONS, lists possible values for the
columns SIGN and OPTION.
SELECT-OPTIONS WITH MULTIPLE SELECTION CRITERIA
The internal table is automatically populated when the user makes entries in a SELECT-OPTIONS object.
There is an (I)nclusive in the Sign column if the traffic signal icon is green during Select. A red light
indicates (E)xclude.

SYNTAX OF THE SELECT-OPTIONS STATEMENT
The SELECT-OPTIONS statements include many additions:

DEFAULT enables you to set default values for the low, or low and high parameters.
OPTION and SIGN can be used to set default values for Option and Sign, which differ from the normal
default values added.
MEMORY ID, if assigned, facilitates the retrieval and automatic display of the current value from the SAP
system memory by the system.
LOWER CASE suppresses conversion of the entry to upper case. This addition is not permitted for
Dictionary fields, because the attribute set in the Dictionary takes precedence.
OBLIGATORY generates a mandatory field. A checkmark is displayed in the entry field in the selection
screen and the user should enter a value.
NO-EXTENSION suppresses multiple range selections.
NO INTERVALS suppresses the upper interval limit entry on the selection screen. You can use
the Multiple selection screen to specify ranges or intervals.

ABAP EVENTS IN THE SELECTION SCREEN ENVIRONMENT
The event LOAD-OF-PROGRAM runs at the beginning of the program execution when the machine code is
loaded to the main memory. The dynamic preassignment of input fields is not recommended at this point.
The event AT SELECTION-SCREEN OUTPUT runs immediately before the selection screen is displayed.
AT SELECTION-SCREEN runs immediately after the selection screen is displayed.
Since you can display the selection screen multiple times, the system can process these event blocks
multiple times.
INITIALIZING THE SELECTION SCREEN
The INITIALIZATION event is processed once in each executable program. You can supply the default values
for both the selection screen fields of a report and a logical database, during this event.

FILLING INTERNAL TABLES WITH HEADER LINES
The internal table with a header line generated by using the SELECT-OPTIONS actually creates two data
objects: a table body named <sel_opt> and a work area (the header line), also named <sel_opt>. You can fill
the work area with suitable values and then use the APPEND <sel_opt> command to add it to the table
body as a separate line.
DESIGING THE SELECTION SCREEN I
You use the statement SELECTION-SCREEN BEGIN OF BLOCK and SELECTION-SCREEN END OF BLOCK to
define the SELECTION SCREEN.
Screen elements that logically belong together can be grouped using the extension BEGIN OF BLOCK.
The WITH FRAME statement places a frame around the screen elements. Frames can be nested to a
maximum depth of five.
The title can be declared as either text-<xxx> or as a field name of up to eight characters.
The text can be set at runtime in the INITIALIZATION event.

DESIGNING THE SELECTION SCREEN II
Multiple parameters and comments can be displayed in the same line on the screen.
To do this, enclose the parameters between the SELECTION-SCREEN BEGIN OF LINE and SELECTION-SCREEN
END OF LINE statements. To include text in the line, use the COMMENT addition.
Comment text must always have a format consisting of position and output length. To set the position, you
use an integer literal or pos_low and pos_high. The latter two are the low and high positions for the
SELECT-OPTIONS field on the selection screen.
Adding COMMENT FOR FIELD ensures that F1 Help for the field is displayed for the comment text and the
parameter.
The keyword POSITION is used to set the cursor for the next output position. It can only be used within
BEGIN OF LINE and END OF LINE statements.
CALL SELECTION-SCREEN
The standard selection screen always has the number 1000.

To define additional selection screens, you use SELECTION-SCREEN BEGIN OF SCREEN <nnnn> and
SELECTION-SCREEN END OF SCREEN <nnnn>.
CALL SELECTION-SCREEN <nnnn> is used to call this selection screen.
The event AT SELECTION-SCREEN is processed completely if there is any user action on the screen.

The system field sy-subrc contains 0 if the user chooses Execute or F8and the value 4 if the user
chooses Cancel or Exit.
You can also call a selection screen as a modal dialog box, using
CALL SELECTION-SCREEN <nnnn>
STARTING AT <left_col> <upper_row>
ENDING AT <right_col> <lower_row>.
The coordinates of the top left corner of the screen are <left_col> and <upper_row>.
The coordinates of the bottom right corner are <right_col> and <lower_row>.
You can supply the additional selection screens with default values at INITIALIZATION. Use the system field
sy-dnnr in the selection screen events to determine which screen is processed.
TABSTRIP CONTROLS ON THE SELECTION SCREEN
You must define three sections to include tabstrip controls:

A subscreen area on the selection screen to accommodate the tabstrip control
The individual tab titles
Selection screens as subscreens for individual tab titles
SELECTION SCREENS AS SUBSCREENS

Selection screens can be defined as subscreens, especially on tab pages. The system processes the ABAP
events AT SELECTION-SCREEN OUTPUT and AT SELECTION-SCREEN for each subscreen, in addition to
processing the surrounding selection screen.
A selection screen as a subscreen can be defined by
SELECTION-SCREEN BEGIN OF SCREEN <dynnr> AS SUBSCREEN [NESTING LEVEL <m> ][NO INTERVALS].
SELECTION-SCREEN END OF SCREEN <dynnr>.
The size of the subscreen can be further reduced by using NESTING LEVEL, to prevent scrollbars from
appearing in a tabstrip control on the selection screen.
DEFINING TABSTRIPS ON THE SELECTION SCREEN
A subscreen area for a tabstrip control on a selection screen can be defined by SELECTION-SCREEN BEGIN
OF TABBED BLOCK <blockname>FOR<n>LINES and SELECTION-SCREEN END OF BLOCK <blockname> .
The height of the subscreen area in lines is defined by <n>.
For individual tab pages, you can use more specific definitions:
SELECTION-SCREEN TAB (max_length) <name>
USER-COMMAND <ucomm>
[DEFAULT [PROGRAM <prog>] SCREEN <dynnr>]
TAB is the name of a variable containing the text to be displayed. You do not have to declare it, as it is a
part of the tabstrip control.
You must also use the SCREEN addition while using the DEFAULT addition.
A <blockname>structure containing the fields, prog, dynnr, and activetab is created automatically. It has
the same name as the tabstrip block.

INPUT CHECKS: AT SELECTION SCREEN
The AT SELECTION-SCREEN event is where the screen input is evaluated. The system makes all the selection
screen fields ready for input in case any error message or warning message is displayed during this event.
You can refer to specific selections by using the ON <f> bzw. ON <seltab> addition.
The event AT SELECTION-SCREEN ON BLOCK <block> is available for you to check entry combinations of a
logical group.
GENERAL HELP AND INPUT HELP (F1 AND F4)
You can include the F1 Help (field help) and F4 Help (input help) for the events AT SELECTION-SCREEN ON
HELP-REQUEST and AT SELECTION-SCREEN ON VALUE-REQUEST.
The F1 Help can refer to individual parameters or a selection table (seltab).
If you add ON VALUE-REQUEST, the button for the F4 input help for the corresponding field is displayed.
As a reference for an F4 Help, you specify either the lower interval field or the upper interval field.

SELECTION SCREEN: VARIANTS I
Variants are useful when you either start a program frequently with the same selection set, or execute it in
the background. You can create any number of selection screen variants for a program, and it cannot be
shared with other programs.
If the program uses several selection screens, you have the option of creating a variant for all the selection
screens, or individually for each selection screen.
SELECTION SCREEN: VARIANTS II
You assign a name and a description to each variant. The variants are available – by default – for both
online and background processing. You can also protect the variant itself, the individual selection criteria,
and the parameters, against unauthorized changes.
By choosing Only Display in Catalog, the variant will only be displayed in the catalog and not in the general
value help (F4).
The type of a selection is determined in its declaration (type S for SELECT-OPTIONS and type P for
PARAMETERS). The field(s) will not be ready for input with the Selections protected option. The hide
attribute does not display selections that are not required, resulting in a less cluttered selection screen.
You can supply values to your selection at runtime by using selection variables.

USER DIALOGS
A user dialog is a form of interaction between the user and the program.
User dialogs include actions, such as
entering data;
choosing a menu item;
clicking a button; or
selecting or double-clicking a list entry.
SAP PROGRAMMING MODEL
The SAP programming single-screen transaction combines the input screen and the data screen in a single
window.
You can also switch between the three modes, Create, Change, and Display. You can directly access the
objects to be edited, which is also an added advantage with the single-screen transaction feature. Another
advantage is that the system retains the context after you save the data to the database.
EXAMPLE SCREEN LAYOUT: TRANSACTION FB60

The example screen layout depicts SAP Transaction FB60.
The screen consists of four divisions, and it is important to note that all the four divisions have different
sets of functions:
Object Selection is the field where the user can edit the object by selecting the required object from the
tree structure.
Object ID is the field in which you edit object attributes.
Details of Object is the area where you can select the subobjects for editing.
Application Functions is the field in which options are listed. You can choose options like Display (for
showing and hiding screen areas), Create new object (with the templates), or Change session (to toggle
between different sessions of a program).
EXCERCISE: SCREEN PROGRAMMING
This slide depicts various screens represented by numbers such as 100, 110, and 120.

In the SAP system, a screen is handled by the number by which it is represented.
Let us now look at the features of screen programming.
The Process flight screen consists of

two input fields;
radio buttons for the selection of the required criteria, based on which the required screen or data is
processed or retrieved; and
a tabstrip, which has three tabs.
You can list the functions of each of the three tabs:

Selection of the tab Connection calls the screen 110 (View flight data).
Selection of the tab Aircraft calls the screen 120 (View technical details for aircraft).
Selection of the tab Bookings calls the screen 130 (Maintain bookings).
ABAP PROGRAM TYPES
ABAP has several program types, such as complete and incomplete. Types 1 and M, which can be executed,
are of the former type. Incomplete types can be used within other programs, but they cannot be executed
as such.
Type 1, the Executable program, runs directly from the ABAP Editor – SE38. A set of processing blocks is
processed in a predefined chronological order. These programs usually create and display lists or output.
Type M, the Module pool program, is executed by means of a transaction code, in which you specify an
initial screen or selection. You handle the subsequent screens, either statically in the screen attributes or
dynamically in the program.
Some ABAP programs cannot be executed independently. They serve as containers for modularization
units, which are called from other programs. Let us familiarize ourselves with these exceptions:
Type F, the Function group, contains function modules, local data declarations, and screens.
Type I, the Include program, contains any of the ABAP statements or declarations.
Type J, the Interface pool, contains global interfaces and local declarations.
Type K, the Class pool, contains global classes and local data declarations.

PROGRAM ORGANIZATION
While creating programs, you should keep certain points in mind, as they can affect program creation:
In the simplest of cases, your program consists of a single source that contains all the necessary
processing blocks. However, you must use include programs. With these, your program code is easier to
understand, and you can reuse parts of it in other programs, such as data declarations.
Whenever you create a program from the Object Navigator, the system proposes to create it With Top
include, in order to create clearly structured programs.
When you create processing blocks, the system automatically asks you to name the
specific Include program, in which it should place the corresponding source code.
If you specify an Include program that does not yet exist, the system creates it and inserts a
corresponding INCLUDE statement in the main program.

TABLE OF FLIGHT DATA MODEL
The slide, Tables of the Flight Data Model, presents you with a view of the tables and fields, which share
primary key and foreign key relationships.
All the columns in the table include the primary key MANDT, which is the client login.
The connection table – SPFLI – contains the connection data, listing some primary keys:
CARRID identifies the airline.
CONNID shows the connection code.
AIRFROM and AIRPTO identify the departure and arrival airports.
The field also contains other keys:

CITY TO and CITY FROM refer to the arrival and departure cities.
COUNTRYTO specifies the destination country.
COUNTRYFR indicates the country of origin of the flight.
FLTIME depicts the time of the flight.
The flight table – SFLIGHT – contains the flight data and lists primary keys, as well as other keys:
CARRID and CONNID
FLDATE
SEATSMAX and SEATSOCC (for maximum seating capacity and number of seats occupied, respectively)
PRICE
CURRENCY
PLANETYPE (for specifying the type of plane)
The table SBOOK lists important fields:

CARRID, CONNID, and FLDATE
BOOKID (for specifying the reservation number)
CUSTOMID (for indicating the customer number)
The last table – SAPLANE – lists apart from the primary key, PLANETYPE, technical data in other fields, such
as SEATSMAX and WEIGHT.
SCREEN
Screens
are freely definable objects;
can be used to display or enter information through input and output fields, lists, and so on; and
are a form of dialog between the user and the ABAP program.
STRENGTHS OF SCREEN
Screens are one of the primary elements of module pool programming.

Screens allow you to Input and output data.
You can perform validation and consistency checks for the input data (referring the ABAP Dictionary), using
screens.
You can also create user-friendly dialogs with push buttons, tabstrip controls, table controls, and other
graphical elements, with the help of screens.
SCREEN IN DIALOG PROGRAM
This slide depicts the various screens that are available in a module pool program. It also shows the order
in which the screens are processed.
We take the example of a dialog program with a selection screen as its initial screen and another screen for
displaying the information, which is the output for a selected data record.
When the program is run through a transaction, the system loads its program context and prepares
memory space for the program data objects. The selection screen is then displayed.
After giving the input on the selection screen, the user chooses the Execute option. The respective code,
which is the processing block, reads the selection screen input data. Then the program, instructed by the
input data, reads the data from the database based on the input data. Once this is done, based on the user
input, the required structure is populated with the required data.
Subsequently, a screen is called by the processing logic. This triggers the PBO or Process Before Output
event. After the processing of the PBO, the data is transferred to the structure that serves as the interface
to the screen. From the structure the data is then transferred to the display screen.
Any user action performed on the screen, such as entering data, choosing a menu entry, or clicking a
pushbutton, returns control to the run time. The screen fields are then transported into the structure that
serves as the interface between the screen and the program. The runtime then triggers another processing
block belonging to the screen, which is called PAI (Process After Input).
The PAI event is always processed after a user interaction.
ATTRIBUTE OF SCREEN ELEMENT (KEY)
The attributes of screen elements are derived from General, Dictionary, Program, or Display attributes.
The attributes of elements can be divided into three types:
Statically definable attributes that cannot be changed dynamically
Statically definable attributes that can be changed dynamically
Attributes that can only be changed dynamically
SCREEN: ATTRIBUTE
A screen has Administrative, Type, Size, Sequence, and Settings attributes.

Each of these attributes imparts a different functionality:
Admin attributes, such as Program and Screen number, identify screens by their numbers and the
programs they belong to.
Examples of other admin attributes are Short description, Screen groups (sometimes certain screens are
grouped together), Status, and Original language.
Type attributes, such as Normal, Subscreen, Modal Dialog Box, and Selection screen, describe the
purpose of the screen.
Size is an attribute that defines whether the screen is Static or Dynamic.
Sequence defines the sequence in which the screen is meant to appear.
Settings attributes may be listed as Cursor position (which determines where the cursor should be on
the screen), Hold data (which specifies whether the data is to be held or not), Runtime
compression, Context menu, and so on.
DEFINING AND MANAGING SCREEN

You must keep some points in mind while using screens:
A screen consists of a screen image and its flow logic.
The flow logic controls the way the screen image is processed.
Screens have four components – screen masks, screen attributes, the element list, and the flow logic.
The flow logic contains the flow logic code and not ABAP statements.
Screens are containers for other screen elements.
CREATING SCREEN
Creating screens involves a specific process, as depicted in this slide:

A screen is created in the screen painter.
In the first step, you define the screen attributes.
Next, you can design the screen layout in the layout editor.
Use the field list to set the field attributes.
Finally, you write the flow logic in the flow logic editor.

CREATING SCREEN: SCREEN ATTRIBUTE
You can create a screen from the object list in the Object Navigator. You begin by creating a new
development object with the type Screen.
Next, position the cursor on Screens and right-click.
The Object Navigator automatically opens the Screen Painter.
On creating the screen, enter the attributes, such as a screen number, short text, and a screen type.
You can specify the number of the next screen in the Next screen field.
CREATING SCREEN: LAYOUT
Field descriptions from the ABAP Dictionary Screen are the basis for defining screen elements.
However, you can also use the field descriptions that you defined in your program.
In the graphical layout editor, you can define the various screen elements (such as input/output fields,
keyword texts, and boxes). You simply choose the element you require, and position it on the screen using
the mouse.
You can choose Delete to delete a screen element.
You can drag and drop elements on the screen, using the mouse.

CREATING SCREEN: THE ELEMENT LIST
The Screen Painter contains an element list with six views to set the attributes of all the screen elements.
You can also display all the attributes for a single element from any of the lists, using the
Attributes function.
CREATING SCREEN: FLOW LOGIC
Flow logic consists of module calls. The modules are components of the same ABAP program, which
contains the ABAP statements that you want to execute.
A module can be created by double-clicking the module name in the flow logic editor. Then you can place
your piece of code in the module that was created.
If you are using the Object Navigator – Transaction SE 80 for the application development – you can choose
the PAI module or PBO module or both.

DATA VISIBILITY
The program flow within a module is handled by the ABAP processor.

The DYNP processor controls the flow logic and prepares the data to be displayed on the screen.
During this process, you see two sets of data. You can create global fields in the TOP include, using
declaration statements such as TABLE or DATA.
The system recognizes fields from the element list, which help retrieve data to display on the screen, as
well as to transport your changed data. This occurs automatically, when you get fields from the ABAP
Dictionary or from the program in the layout editor.
A system program copies the data, generated from different sets of data fields. The system also compares
the identically named fields of DYNP and ABAP.
DATA EXCHANGE: SCREEN - ABAP PROGRAMS
For a screen and its ABAP program to be able to communicate during dialog programming, the field names
should be identical in the screen fields and the program fields.
After the processing of all the modules in the PBO, the contents of the fields in the ABAP work area are
moved to the corresponding fields in the screen work area.
Before the first module in the PAI processing block, the data in screen fields is moved to the corresponding
fields in the ABAP work area.
This ensures that the data being transported from the screen to the program and vice versa is exactly the
data that you want.
MODIFYING ATTRIBUTE DYNAMICALY: EXAMPLE
The technique to dynamically modify the attributes of a screen element helps you to replace long
sequences of separate screens. For example, you can change the attribute of a screen element to decide
whether an input/output field is ready for input.
DYNAMICALY MODIFIABLE STATIC ATRIBUTES
This slide depicts the fields or attributes of the screen table.

These screen attributes have their own individual meanings:
Screen-Name is the unique identifier for a screen element on one screen.
Screen-Groups 1, 2, 3, and 4 refer to a group of fields related logically and grouped together. You can set
this attribute dynamically.
Screen-Length defines the length of the field on the screen.
Screen-Input and Screen-Output are program attributes that assign the input and output fields on the
screen.
Screen-Required defines a mandatory field on the screen.
Screen-Intensified is for intensifying the display of any field on the screen.
Screen-Invisible is also a display attribute, used when certain fields are made visible only under certain
conditions, or after entering the correct input in some logically related fields.

Screen-Active enables the screen to be active or inactive on the basis of requisite inputs or certain
conditional requirements.
THE SCREEN SYSTEM TABLE
The SCREEN system table is the system table with line type SCREEN. It contains an entry for each element
created in the Screen Painter while the screen was being processed.
INITIALIZING SCREEN SYSTEM TABLES
As a first step, a system program copies the statically defined attributes of the individual screen elements
into the SCREEN system table.
As a result, the SCREEN system table is initialized at the start of the event PBO for the current screen.
You can change the dynamically modifiable attributes on the screen in a module at the event PBO, using
the requisite statements.

MODIFICATION GROUP ATTRIBUTE
The Screen Painter helps you group the screen elements (whose attributes you want to change) together in
a modification group.
You can change the attributes of these elements simultaneously at runtime.
In the Screen Painter, you can group together the elements that you want to change within a single
processing step.
You enter a group name for each of the relevant elements in one of the fields, Group 1 to Group 4.
Choose any three-character sequence for the group name.
Assign the elements to a modification group either in the element list or in the layout editor of the Screen
Painter.
Each element can belong to four modification groups at the most.
MODIFYING ATTRIBUTES DYNAMICALY: PROGRAM
You can code for screen modifications in a module of the PBO processing block.
To change the attributes of an element or a group of elements, you use a loop through the table screen.

Assign the value 1 to activate and the value 0 to deactivate a particular attribute for a screen element.
You save the changes using the MODIFY SCREEN statement.
DETERMINING THE NEXT SCREEN
Complex applications may involve multiple screens. The initial screen is defined when the transaction code
is created.
The next screen is usually dynamically determined, depending upon the user input.
STATIC SCREEN SEQUENCES
To maintain a static sequence of screens, you enter a value in the Next screen field onscreen Attributes.

SETTING THE NEXT SCREEN DYNAMICALY
To set the sequence dynamically, you use specific statements or commands:

SET SCREEN temporarily overwrites the Next screen attribute.
LEAVE SCREEN helps you terminate a program, after which the next screen is processed.
LEAVE TO SCREEN enables you to specify the next screen and leave the current screen in a single step.
INSERTING THE SCREEN SEQUENCE
You use a CALL SCREEN statement, to insert a screen sequence.

This will add another layer to the stack.

INSERTING A SEQUENCE OF SCREEN DYNAMICALLY
The statement CALL SCREEN helps you to branch into a new screen from the current screen without
processing the current screen.
To recover control after the CALL SCREEN statement, you use the statements SET SCREEN 0, LEAVE SCREEN,
or LEAVE SCREEN 0.
This ensures that the screen that called the other screen is processed further.
The latter three statements, outside the call chain, terminate the program.
Control returns to the point at which you used the CALL SCREEN statement.
The statement LEAVE PROGRAM will also terminate the program.
CALLING DIALOG BOX DINAMICALLY
You set the Screen Attributes for type in the Modal dialog box, while creating the screen in the Screen
Painter.
To specify the position and the size of the screen called in the CALL SCREEN statement, you use the
additions STARTING AT and ENDING AT.
If you do not use the ENDING AT addition, the size of the dialog box is determined by Used size or Occupied
size in its screen attributes.

WINDOW COORDINATES
The starting position or origin of every SAP system window is its top left-hand corner. This screenshot
depicts the statement,
CALL SCREEN <screen 101>
STARTING AT left_col upper_row.
ENDING AT right_col lower_row.
The values that are used for the variables left_col, upper_row, right_col, and lower_row in the statement
relate to the R/3 system screen (100 in this case), from which you display the second screen (101) with the
statement CALL SCREEN.
SETTING THE CURSOR POSITION DYNAMICALLY
One method to set cursor position dynamically is by instructing the system in the PBO event to position the
cursor in a particular field.
This makes your application easier to use.
A specific ABAP statement also serves the same purpose:
SET CURSOR FIELD <object_name> OFFSET <position>
Choose a unique name (in quotation marks) for <field_name>. You can also use a variable containing the
object name.

GUI INTERFACE
A GUI status comprises different components including

a menu bar;
a standard toolbar;
an application toolbar; and
certain function key settings.
A screen can have more than one status. For instance, an editor program can have one status for display
mode and another for the change mode. The GUI titles and statuses for a program together constitute the
user interface.
Menus are control elements which enable a user to choose one or many functions for processing. Each
screen of the R/3 system contains both system menus and help menus. These menus perform similar
functions and can neither be modified nor hidden.
The standard toolbar is uniform across every screen in the SAP R/3 system. It contains a set of icons, each
of which is assigned to a corresponding function key. If a function icon is greyed out, it means that it is not
available on a current screen.
An application toolbar contains a set of icons for frequently used functions. You can use these functions by
clicking the corresponding button in the application tool bar.
In addition, you can use the function key settings to allocate functions, such as Find, Replace, or Cut to the
function keys.

GUI TITLE
To create a GUI title, uncomment the SET TITLEBAR statement in the module output. You can specify a
name for the title as shown here. Double-click this title to get a confirmation dialog box. You can mention
the title code and title in the Create Title dialog box.
A GUI title name cannot consist of more than 20 characters. However, each screen in your application
should have an appropriate title.
Titles can contain variables that are set dynamically at runtime by inserting the ampersand character (&) as
a placeholder. The title should not contain more than nine variables.
STATUS: TECHNICAL VIEW (1)
Technically speaking, a status can be defined as a reference to a menu bar, to certain key assignments, and
to an application toolbar. You can display a single component of the status on screens and lists. In fact, a
GUI status can also be described as an ABAP program object that can be displayed on screens and lists.

STATUS: TECHNICAL VIEW (2)
As shown here, the menu bar consists of individual menus. On the other hand, the key assignments and the
application toolbars are subobjects of the function key settings.
There is an application toolbar in each status. You can set functions within a status as either active or
inactive. Additionally, all program menus and key assignments are related to all interface functions which
can be accessed using the F4 help.
FUNCTION
All functions are described by their function codes. You can create functions with either static or dynamic
text. If a static text is used, then that function is given an icon using the Icon name attribute. Similarly, you
can display both text and icon by entering the text in the Icon text attributes.
The attribute, (F type) function type, defines the purpose of the function. Function types such as E and P
are meant for the users, while the function types S and H can only be used by the SAP developers. When
you use the function type T, the system leaves the calling program and calls the new program.
Moreover, by using the Fastpath attributes, you can choose a function from the menu bar without using a
mouse by specifying a single letter to select that particular function.
FUNCTION KEY SETTING
Function key settings comprise a key assignment and an application toolbar pushbutton. You can assign
functions to individual function keys and buttons. Different types of function key settings, such as for a
screen and dialog box, have different technical purposes.
Key assignments consist of
reserved function keys;
recommended function keys; and
freely assigned function keys.
Reserved function keys are those that have assigned values which cannot be changed in the SAP system.
Recommended function keys contain proposals, which comply with SAP System’s ergonomic standards.
The buttons in the application toolbar can also be used for functions that are assigned to the function keys.

MENUS AND MENU BAR
Menu entries can include functions, separators, and other menus such as cascading menus. A menu can
have as many as three levels. Each level, however, can contain only functions and separators.
You can create menus with either static or dynamic text. If a static text is used, the Fastpath attributes
allow you to choose a function from the menu bar without using a mouse by specifying a single letter to
select that particular function.
If dynamic text is to be used, you should assign a menu field to the menu. The contents of this field will
then be displayed as the menu text. The menu type Include Menu allows you to relate to menus in other
programs. Include menus can be accessed only by using the menu bar. You must specify the name of the
program and status from which you want to include the menu next to the Short documentation field.
CREATING A GUI STATUS

The GUI status is created by using the SET PF-STATUS statement. You can double-click the name given in
this statement, which is, BASE, as shown here, to create the object.
You can set status type as any of these – full screen, dialog box, and context menu. A status can be created
by creating links to existing components or by creating a new blank status. In case the status is entirely
new, you should also design a menu bar, menu functions, and other elements. Any changes made to this
status only affect that particular status.
However, if you use the reference technique, the menu bars, application toolbars, and function key
assignments are created independently. The references to the menu bars are stored and maintained
separately. Therefore, any changes in the menu bar, application toolbar, or function key assignments get
automatically reflected in all statuses referring to them.
CREATING A GUI STATUS: FUNCTION KEY ASSIGNMENT
The function key settings consist of a key assignment and a set of application toolbars.
There are two types of functions, static texts and dynamic texts, each of which have specific attributes.
You can attach functions to reserved function keys, recommended function keys, and freely assigned
function keys.
Reserved function keys appear in the standard toolbar on screens and lists.
STANDARD TOOLBAR: AUTOMATIC ASSIGNMENT
When a function key is assigned to the standard toolbar, it is also automatically assigned to a reserved
function key. You can find the function keys for these functions by selecting Information in the Menu
painter.

CREATING A GUI STATUS: APPLICATION TOOLBAR
The functions in an application toolbar can be used only if they are already assigned to a function key. F4
help allows you to select the functions. When an icon is assigned to a function with a static text, the system
displays the icon rather than the static text in the application toolbar. You can use the function text
belonging to the function as a quick info text.
CREATING GUI STATUS: MENU BAR
A menu entry includes a function, a separator, or another menu, such as a cascading menu. You can add a
function to a menu by entering its function code in the left-hand column. If a function already exists in the
function list and has text assigned to it, it is automatically entered in the text field. Otherwise, you need to
enter text by double-clicking the right-hand field.
You can create a submenu by entering the name in the right field of the menu entry.

DISPLAYING STANDARD
The reserved function keys appear in the standard toolbar on screens and lists. The user should reuse the
existing menu bars, application toolbars, and key settings to ensure consistency. You can use the Menu
Painter so that changes made in objects can reflect in statuses which use them.
The reserved function keys in the standard toolbar should be used according to the SAP standards to keep
the program user-friendly.
INCLUDING EXISTING ELEMENTS
You can use the Menu Painter, working from the bottom upward, to include key settings and application
toolbars or menu bars in a status. If there are multiple application toolbars for your key setting, you can
choose the most relevant one.
All functions are inactive at the beginning of the program. You need to activate only those functions that
are required in the current status. After creating a new function, you can also opt to change all statuses
which refer to the same object.

PROCESSING THE FUNCTION CODE
When you call a function with type ‘ ‘ (space) using a button, menu entry or function key, the system inserts
the required function code in the OK_CODE field of the screen. You must assign a name to this field for
processing it in the PAI event. Additionally, you should enter this name in the element list in the Screen
Painter and create a field in your ABAP program with the same name.
At the beginning of the PAI event, the function code passes from the screen to the corresponding field in
the program as part of the automatic field transport. At this point, function code may lead to unexpected
processing steps on the subsequent screen.
SCREEN ELEMENT FOR OUTPUT

TEXT FIELDS
A text field is a rectangular screen area where text is displayed. As a developer, you can assign labels or
keywords to other elements in text fields. These keywords are only for display and cannot be changed at
runtime. Additionally, text fields can contain lines, icons, and other static elements.

TEXT FIELDS: ATTRIBUTE
This slide illustrates four text field attributes:

General
Dictionary
Program
Display
General attribute consists of Name, Text, Icon Display, Start Position, Size, Modification groups, and
Context menu.
The Dictionary attribute allows you to get information from the ABAP Dictionary, while the Program
attribute contains Output options and manages the various output options.
The Display attribute allows you to display font as bright or invisible. It can be a label or a web display
property.
CREATING TEXT FIELDS
To create a text field, you can

insert a text object in the work area and enter the text in the Text attribute in the Layout Editor directly;
or
use the accompanying text of a data element from the ABAP Dictionary.
When you use fields from the ABAP Dictionary structures on the screen, the system by default exhibits the
data element and the template for the Input and Output fields on the screen.
STATUS ICON
A status Icon is an output field that contains an icon. As shown here, either of the two icons will be relevant
at run time.
Icons allow you to indicate a status in your application. They are predefined in the system and consist of
two to four characters.
STATUS ICON: ATTRIBUTE
Status icons are special output fields that display icons. Attributes such as Visible length, Intensified, and
Invisible can be changed dynamically.
CREATING STATUS ICON

You can create a status field only in the graphical Layout Editor. This is because a status field is defined as
an output field with an icon.
Now let us go through the steps for creating a status field:
In the ABAP program, place a field with the same name as the screen field using the Text Field from the
ICONS structure.
Use ICON_CREATE function module to assign the required icon to this field.
At runtime, this file contains the name of the icon you wish to display.
FILLING A STATUS ICON
The option for filling the Status Icons is also available in the ABAP program. You can select the icon you
want to display from this program. It is important to first determine the technical name of the icon before
the screen is displayed by calling a module in the PBO event. You can also recover the technical name of an
icon using the ICON_CREATE function module in the PBO event. You must transfer the name of the icon
along with a text to be displayed with the icon to the function module. It then returns the technical name
of the icon.
GROUP BOXES
Group boxes encircle a selection of elements that belong together including a group of fields or a radio
button group. They only serve as display elements by which the user can associate elements on the screen.
Group boxes contain a title.

GROUP BOX :ATTRIBUTE
The screen system table helps you change Visible length and Invisible attributes.
A group box may also possess other screen elements. If you set the screen attribute runtime compression,
then the system does not display group box when it only contains invisible elements.
CREATING GROUP BOXES
You can define group box in the Layout Editor with a name and a heading. Its text can be changed
dynamically by activating the output field attribute and creating a global data field in the ABAP program
with the same name. Any changes to the field content will automatically reflect on the screens, as is the
case with input or output fields.
INPUT/OUTPUT FIELDS
An input field is a rectangular screen element in which you can enter data, whereas an output field is a
rectangular screen element in which the system displays text or other data.
Automatic field input checks relate to the data type of the input fields.
For example, you can only enter a valid date in a date field.
Input fields that are congruent with the ABAP Dictionary fields may have built-in data consistency checks,
such as foreign key checks and value sets.
Input fields can hold possible help values.
INPUT/OUTPUT FIELDS: ATTRIBUTE
The four attributes for input or output fields are General, Dictionary, Program, and Display.
Each attribute consists of several elements:
General attributes may include elements, such as Name, Text, Dropdown, Icon display, Start
position, Size, and Context menu.
Dictionary attributes may be listed as Data format, Memory ID, Foreign key check, Conversion
exit, Search help, and so on.
Program attributes include Dialog behaviour, Input help, Output options, and Input options, among
others.
Display attributes relate to the display features, such as Font, Bright, Invisible, Two-dimensional,
and Web display properties.
Using the SCREEN system table, you can temporarily change the relevant object attributes.
CREATING INPUT/OUTPUT FIELDS
You can use two methods to create input or output fields:

You can enter the field directly in the layout editor. The number of underscore characters in the object
text attribute determines the size of the field.
You use a template from the ABAP Dictionary, which you access by selecting Dict/Program fields.

You must declare the field globally using the DATA or TABLES statement for using the contents of an input
or output field in your program.
DEFAULT MEMORI IN SAP MEMORY
The SAP system enables you to save default values in the SAP memory, using parameter IDs.
In the PAI processing block, Set parameter copies the corresponding field contents into the SAP system
memory.
At the end of the PBO, after the data is transferred from the program, the screen field might still retain its
initial value. In this case, Get parameter copies the corresponding field contents from the SAP memory.
DEFINING SET AND GET ATTRIBUTE
In the ABAP Dictionary, you can link an input or output field to an area of the SAP memory. The Parameter
ID is displayed in the Dictionary attribute Parameter ID of the Screen Painter.
The SET and GET parameter attributes (SPA and GPA in the table displayed) allow you to enable the
relevant parameter functions separately.

DIALOG MESSAGE CATEGORY
The dialog messages are divided into six categories: A, X, E, W, I, and S.

The message type A is for termination of the process and the user must restart the transaction.
The type X message works like the type A message, except that it includes short dump MESSAGE_TYPE_X.
The type E message interrupts the processing with an error, and the user must correct the entry.
The type W message interrupts the processing with a warning, and the user can correct the entries.
The type I message interrupts the processing with information, but the user can continue by confirming the
message.
The type S message denotes success, which is the information displayed on the next screen.
AUTOMATIC FIELD INPUT CHECKS
The first check ensures that all the required fields are filled.
This is supplemented by a field format check.
The fixed values defined in the domain are also checked.
For a foreign key check to happen, the screen field should refer back to an ABAP Dictionary field, for which
a check table is defined.
Thus, the system automatically checks the values you enter after the screen is displayed, but before the PAI
modules are processed.

FIELD INPUT CHECKS WITH ERROR DIALOG
You can program your own field checks in the PAI event by using the FIELD statement with MODULE
addition. This instructs the system to process that specific module only for the field statement that you
specify.
The system sends the screen again if an error or warning message occurs during the module, but without
processing the PBO module. The message is displayed and the field to which the check was applied is ready
for input.
CHECKING GROUPS OF FLIEDS
To ensure that more than one field is ready for input following an error dialog, you list the relevant fields in
the FIELD statement. You include both the FIELD and the MODULE statement in a CHAIN … ENDCHAIN
block.
You can include individual fields in more than one CHAIN … ENDCHAIN block.
The FIELD statement makes the field ready for input again.

CONTROLLING ERROR DIALOG
The current screen is sent again if the system sends an error or warning message, but the PBO is not
processed again.
When this happens, only the fields to which the module is assigned are ready for input again.
The PAI module after user input is not completely reprocessed, but restarted somewhere within the
processing block.
The system finds out which fields the user has changed and resumes processing at the first corresponding
FIELD statement.
THE FIELD STATEMENT AND DATA TRANSPORT
The data is transported from the screen fields into the ABAP fields with the same name in the PAI
processing block.
First, the system transports the fields not contained in FIELD statements. The remaining fields are
transported when the system processes the relevant FIELD statement.

CONDITIONAL MODULE CALLS
Avoiding field input checks wherever possible improves the performance of your program, as frequent
access to the database may slow down the system.
If you leave the screen by mistake, you might make inconsistent entries to satisfy the input checks.
Therefore, you should be able to get back to the program, without these field checks taking place.
A program security prompt warns you if you leave the screen unintentionally, so that you can avoid losing
the data that you entered.
EXECUTION IF THE VALUE IS NOT INITIAL
You can use the ON INPUT addition in a MODULE statement after FIELD, to ensure that the module is called
only if the field contents change from their initial value.
The ON CHAIN-INPUT addition defined within a CHAIN block ensures that the module is called if the
contents of at least one screen field within the CHAIN BLOCK do not equal their initial value.

EXECUTION ON CHANGE
The module is called only if you enter a new value in the relevant field with the ON REQUEST addition in a
MODULE statement after FIELD.
The ON CHAIN-REQUEST addition defined within a CHAIN block ensures that the module is called if you
change the contents of at least one screen field within the CHAIN block.
AVOIDING FIELD INPUT CHECKS
The module with the AT EXIT-COMMAND addition is processed not only before the automatic field input
checks, but also before all the other PAI modules. It is executed when the function has a type E.

SWITCH DEPENDING MODULE CALL
When you specify a SWITCH, it should also have the state ON. Otherwise, the dialog module will not be
called.
You cannot specify the addition together with the statement FIELD.
NAVIGATION TARGET
You use the Back and Cancel functions to take you back one logical level.
If the screens are on the same level as the initial screen, they lead back to the initial screen.
If the screens contain detailed information, they lead back to the screen that called the current screen.
The Exit function returns to where the processing unit was called.
All the three functions (Back, Exit, and Cancel), when selected on the initial screen of a program, lead back
to the screen from which the current program was called.

SINGLE SCREEN TRANSACTION
By clicking Back, you can exit the current transaction and return to the calling program, which may be
the Workplace.
This function works like the Exit function.
The Cancel function displays the screen again with initialized data fields and allows the user to select a new
object.
NAVIGATION: DIALOG
If you enter data on the screen – SY-DATAR = X or your own flag – you can avoid accidental loss of data by
using a predefined security prompt.
For the Exit and Cancel functions, a dialog box is first sent to the user. The system checks the input on the
screen for the Exit function.
The Exit and Cancel functions must have a function type E.
The input check precedes the dialog in the case of the Back function.
Switching from the Change to the Display mode can result in unsaved data being lost. If the user chooses
not to save, the system will display the original data stored in the database.
The SAP system contains a series of function modules that you can use for the user dialogs.

INPUT HELP
Input help or F4 help is a standard function in the R/3 system, which allows you to display a list of possible
entries for a screen field.
A dropdown list with possible entries appears on the right side of the field. It is visible whenever the cursor
is placed in the field.
DROPDOWN BOXES
Dropdown boxes contain possible entries in a pick list, from which you can choose an entry.
You execute a series of steps in the Screen Painter, to create a dropdown box for an input field:
Set the Dropdown attribute to List box.
Change the Visible length attribute to the displayed length of the descriptive text.
Set the Value list attribute to ' ' (space), so that you can access value help from the ABAP Dictionary.
If required, set the function code for the selection.
The search help assigned to the ABAP Dictionary field is in the form of a check table with two columns or a
table of fixed values.
The values are filled automatically from here.

CHECKBOXES AND RADIO BUTTON GROUP
When you can choose only a single element from a group of fields, you use a radio button. On selecting one
option, all the others are ruled out, as they are automatically deselected.
To choose one or more elements from a group of fields, you use checkboxes, which can indicate multiple
choices.
RADIO BUTTON AND CHECKBOXES: ATTRIBUTE
Checkboxes and radio buttons possess four attributes, General, Dictionary, Program, and Display.
Examples of General attributes are Name, Text, Icon display, Start position, Size, Function code, Function
type, and so on.
Dictionary attributes list features, such as Data format, Memory ID, and From ABAP Dictionary.
The Program attribute has the Dialog behaviour feature, whereas the Display attribute enables
the Invisible mode.
Certain points are worth noting in the context of checkboxes and radio buttons:
You must attach a name to checkboxes and radio buttons.
The text is contained in the Text field of the attributes.
You must enter the name in the Icon name attribute, to display an icon. A quick info for the icon then
appears in the appropriate field.
You can change the Input field and Invisible attributes dynamically using the SCREEN system table.

CREATING A CHECK BOX
Checkboxes are created in the full screen editor of the Screen Painter.
You create them by selecting the checkbox object from the object list; placing it on the screen; and
assigning a name to each checkbox.
In the ABAP program, create a field with the same name; type, c; and length, 1.
CREATING A RADIO BUTTON GROUP
First, you create the radio buttons as individual elements.

Next, choose radio button from the object list and place it on the screen. Ensure that you assign a name to
each radio button.
In the ABAP program, create a field with the same name; type, c; and length, 1. You can find out the radio
button chosen by the user, by querying the field contents in the ABAP program. If a radio button is not
selected, the initial field value remains.

PROGRAM FLOW FOR RADIO BUTTONS AND CHECKBOXES
The program flow for radio buttons and checkboxes is similar.

When you select the field, a PAI event might or might not be triggered off. This depends on whether or not
you assign a function code to a checkbox or radio button.
You can assign a function code to a radio button after you define a radio button group. The system then
assigns the same function code to all radio buttons of the group.
PUSHBUTTONS
Pushbuttons are the input fields for the OK_CODE command field.
You can quickly access functions that relate to individual screen elements or groups of screen elements,
using the mouse.
You can use pushbuttons in the data area of your screen to show or hide further information.

PUSHBUTTON: ATTRIBUTE
The attributes of pushbuttons are General, Dictionary, Program, and Display.

Pushbuttons may contain a Text attribute, an Icon, or both. You use the function module ICON_CREATE, to
specify an icon statically or dynamically.
You can change the Visible length, Output field, and Invisible attributes dynamically, using the system
table SCREEN.
CREATING AND PROCESSING PUSHBUTTON
To create a pushbutton, choose the pushbutton object from the Screen Painter Element List and place it on
the screen. Now assign a name to it. You can enter a static text in the Text attribute. Ensure that you enter
a function code for the pushbutton in the Function code attribute.
Your second step is to activate the command field or the OK_CODE field. You must give the field a name in
the Element List of the Screen Painter and then declare an identically named field in the ABAP program
with reference to the system field sy-ucomm.

When using the on input addition, the system calls a module only if the fields contents have changed from
the initial value. In a chain block, you use the on chain-input addition. The module is again called if the
contents of at least one screen field in the chain block has changed from their initial value.

If you use the on request addition, the module is called only if the user enters a new value in that field.
In a chain block, you use the on chain-request addition, the module is called if the user changes the
contents of at least one of the fields in the chain block. You use the on request addition only if a field
statement contains the module statement.

20 Subscreens
A subscreen is an independent screen that is displayed in an area of another ("main") screen.
Subscreens allow you to embed one screen within another at runtime. You can include multiple sub-
screens on main screen.
The term subscreen applies both to the screen that you embed, and the area on the main screen in which
you place it. This tutorial is about subscreen areas. The actual screens created through SE51 transaction,
are called subscreen screens if defined in screen attributes.
When you use a subscreen, the flow logic of the embedded screen is also embedded in the flow logic of the
main screen. Hence, Using subscreens on screens is like using includes in ABAP programs.
To use a subscreen, you must follow three simple steps
 Define the subscreen area(s) on a screen
 Define suitable subscreen screens
 Include the subscreen screen in the subscreen area.
Also, you need to adjust the frame of sub-screen and main screen. You need to name it in the field name
field.
Further, you also need to adjust the fields within the subscreen to make them appear in main screen. In
case the sub-screen is defined to be larger than the available area in the main screen, only the part of
subscreen will be visible that fits in the area available. The area is always measured from the top left corner
of screen. Hence you should take adequate care while defining sub-screen areas and creating sub-screens.
EXAMPLE
For instance here we have defined two sub-screen areas on main screen and have attached two different
Sub-screen to corresponding areas. Whenever main screen is called, the PBO of main screen is called. But
before display, the PBO's of each screen attached with sub-screen areas on main screen are also called.
You can include a subscreen screen using the CALL SUBSCREEN statement in the flow logic of the main
screen.

To include a subscreen screen in the subscreen area of the main screen and call its PBO flow logic, use the
following statement in the PBO event of the main screen:
PROCESS BEFORE OUTPUT.
CALL SUBSCREEN <area> INCLUDING [<prog>] <dynp>.
This statement assigns the subscreen screen with number <dynp> to the subscreen area called <area>. You
can also specify the program in which the subscreen screen is defined (optional). If you do not specify the
program explicitly, the system looks for the subscreen screen in the same ABAP program as the main
program. If it does not find a corresponding subscreen screen, a runtime error occurs. The PBO flow logic of
the subscreen screen is also included at the same point. This can call PBO modules of the ABAP program in
which the subscreen screen is defined. At the end of the subscreen PBO, the global fields from the program
are passed to any identically-named screen fields in the subscreen screen. The PBO flow logic of the
subscreen screen can itself include further subscreens.
The name <area> of the subscreen area must be entered directly without inverted commas. You can specify
the names <prog> and <dynp> either as literals or variables. If you use variables, you must declare and fill
identically-named variables in the ABAP program. The screen number <dynp> must be 4 characters long. If
you do not assign a subscreen screen to an area, it remains empty.
To call the PAI flow logic of the subscreen screen, use the following statement in the PAI flow logic of the
main screen:
PROCESS AFTER INPUT.
CALL SUBSCREEN <area>.

This statement includes the PAI flow logic of the subscreen screen included in the subscreen area <area> in
the PBO event. This can call PAI modules of the ABAP program in which the subscreen screen is defined.
Data is transported between identically-named fields in the subscreen screen and the ABAP program either
when the PAI event is triggered, or at the corresponding FIELD statements in the PAI flow logic of the
subscreen screen.
Points to Remember
Names of elements of sub-screens within a screen should be unique
You should not have OK_CODE or FCODE attached with sub-screen. The OK_CODE of main screen itself is
OK_CODE of sub-screen
Sub-screens cannot have any dialog modules containing SET TITLEBAR, SET PF-STATUS, SET SCREEN, LEAVE
SCREEN or LEAVE TO SCREEN. This will cause runtime error.
You need to call it in the flow logic (both PBO and PAI) of the main screen.
CALL SUBSCREEN is not allowed in CHAIN..ENDCHAIN and LOOP ENDLOOP statements
Can not have an AT EXIT-COMMAND module
The fields that you use are the global fields. They must be declared in the top include
If using subscreens from another dialog program the data transfer will not happen unless you add specific
code.

SUBSCREEN (1)
A subscreen area is a reserved rectangular area on a screen, in which you add another screen during run
time.
A second screen with the type subscreen must be created and then displayed in the subscreen area defined
on the main screen. In other words, a subscreen is an independent screen displayed within another screen.

SUBSCREEN (2)
You can include multiple subscreens within a main screen. From a usability perspective, subscreens are
highly attractive as different programs can use the same subscreens. You can also define the subscreens
dynamically at run time.
SUBSCREEN AREA: ATTRIBUTE
The general attributes of the subscreen area include its name, position, and size.
You can use the resizing attributes to determine whether the size of a subscreen area can be changed
vertically and horizontally. If a subscreen is bigger than the subscreen area in which it is called, then only
that part of the subscreen which can fit in the subscreen area is shown.
You can also use the minimum size attribute to set the lowest possible limit to which the subscreen area
can be resized.
Similarly, by using the scrollable attribute, the system displays scrollbars for large screen sizes.

CREATING A SUBSCREEN AREA
For creating a subscreen area, you need to

select a subscreen from the object list in the Screen Painter;
enter a name for the Subscreen area in the Object text field and position it on the screen;
adjust the top-left corner of the table control area; and
modify the size of the object.
CALLING A SUBSCREEN
It is essential to call a subscreen in both the PBO and PAI sections of the flow logic of the main screen. For
this purpose, the ABAP modules for subscreens are programmed similarly as normal screens.
The CALL SUBSCREEN <subarea> statement executes the PBO and PAI processing blocks for the Subscreen
as components of the PBO and PAI of the main screen.
SPESIAL CASE: VISIBILITY OF DATA
You must use the global fields of your ABAP program for the fields within the flow logic. These fields must
be declared in the TOP include of your program.
SUBSCREEN FROM EXTERNAL PROGRAM
You cannot access the global data of the main program in the subscreen if it is not in the same module pool
as the main program. In this case, data transfer from the screen to the program does not occur.
Therefore, you must implement data transfer through a function module that exports and imports data
with an appropriate MOVE statement in the subscreen coding.

SUBSCREENS: ENCAPSULATION IN FUNCTION GROUP
There may be instances when you may need to use a single subscreen in the screens of several different
programs. In such cases, you can encapsulate the subscreen in a function group and use function modules
to transport data between the programs in which you want to use the subscreen and the function group.
The interfaces of the function modules are used to pass the data between the calling program and the
function group.
SUBSCREEN IN FUNCTION GROUP: CALL SEQUENCE
You should use a module prior to the subscreen call to exchange data between the calling program and the
function group. A function module is called for this purpose. It must be called before the subscreen call so
that data is known in the function group before the PROCESS BEFORE OUTPUT processing block of the
subscreen is called.
The PROCESS AFTER INPUT processing block of the subscreen is called before the function module call to
transport the data back from the function group to the calling program.

SUBSCREEN IN FUNCTION GROUP: DATA TRANSPORT
You can access the data of the calling program globally in the function group by transferring the interface
parameters from the function module into global data fields of the function group. In order to transfer data
from the function group to the calling program, the corresponding data from the global data of the function
group must be copied into the interface parameters of the function module.
SCREEN ELEMENT: TABSTRIP CONTROLS
Tabstrip controls serve as a container for other screen objects. They also provide an intuitive way of
navigating between different components of an application shown on a single screen.
You can use tabstrip controls to depict different components of an application that form a logical unit.

TABSTRIP ELEMENTS
A tabstrip control comprises individual pages with a tab page and a tab title.
If the tabstrip control contains multiple pages, a scrollbar allows you to scroll through the different tab
pages when it is not possible to display all the tab titles simultaneously. You can also use a pushbutton to
display a list of all of the tab titles with a checkmark next to the active tab title.
A tabstrip control also contains a border.
PAGE ELEMENT: TECHNICAL VIEW
A page element consists of a tab title, a subscreen area, and a subscreen. A tab title functions similar to a
pushbutton. The subscreen technique is used to display the contents of the page elements. A subscreen
area is assigned to each page element for which you can then call the subscreen.

TABSTRIP CONTROLS: ATTRIBUTE
The general attributes, such as Object name, Starting position, and Static size, determine the name,
position, and size of the tabstrip control, respectively. The resizable attributes can be used to check
whether the size can be changed vertically and horizontally. You can also use the minimum size attribute to
set a lower limit beyond which the size cannot be changed.
CREATING A TABSTRIB CONTROL
A tabstrip control can be created by first defining the tab area. Then, a tab title is defined and additional tab
titles can be added when required. A subscreen area is finally assigned to each page element.

CREATING A TABSTRIP CONTROL: TABSTRIP AREA
The first step in creating a Tabstrip Control is to define a tab area. You should first select Tabstrip Control
from the object list in the screen painter and then place it on the screen.
You should then assign a name to the Tabstrip Control in the Object name attribute.
Next, in the ABAP program use the CONTROLS statement to declare an object with the same name with
TABSTRIP as the type.
The type TABSTRIP is defined in the type pool CXTAB. The ACTIVETAB field holds the functions code of the
tab title of the currently active Tabstrip.
CREATING A TABSTRIP CONTROL: TAB TITLE
Tab titles possess a name, a text, a function code, and a function type, which are entered in the Name,
Text, FctCode, and FctType fields of the object attributes respectively.
A tab title either has the function type ‘ ’(space) or function type P. If the function type is a “(space)”, then
the PAI processing block is called with user selection of tab and the function code is placed in the command
field. On the other hand, the function type P allows the user to scroll between the different tab pages of
the same type without triggering the PAI processing block.

CREATING TABSTRIP CONTROL: TABSTRIP SUBSCREEN
You must assign a Subscreen area to each screen element. The Subscreen area assigned to a tab page is
automatically entered as the Reference object in the Dictionary attributes for the tab title of that page.
You can also assign a subscreen area to multiple tab pages. For this, select the relevant tab title in the full
screen editor, and then place the Subscreen object on the tab page.
SCROLLING LOCALLY IN TABSTRIP CONTROL
You can scroll between the pages locally at the front end, if a different subscreen area is assigned to each
page element in a tabstrip control. It is essential to send all the subscreens to the front end when you send
the main screen. You must also ensure that all the tab titles in the tabstrip control have the function type P,
so that the user can scroll between the different tab pages without triggering the PAI processing block.

SCROLLING IN LOCALLY TABSTRIP CONTROLS: PROGRAMMING
You must call all the subscreens from the flow logic and assign function type P to all the tab titles. The ABAP
program uses the CONTROLS statement to declare an object with TYPE TABSTRIP.
PAI SCROLLING IN TABSTRIP CONTROLS
The program analyses the function code of the chosen tab title to determine which screen is displayed
when the page elements share a single subscreen area.
There are two steps in this process:
The program determines which page element should be active on the basis of the tab title chosen by the
user in the PAI processing block.
The program displays the corresponding screen during the processing of the PBO block.

TABSTRIP CONTROLS: PROGRAMMING
The application program can process scrolling in a tabstrip control when

all the tab pages share a common subscreen area;
all the tab titles have the function code type ‘ ‘ (space);
a variable is used in the flow logic to call the screen for display in the subscreen area; and
the PAI block is used to call a module containing the function code of the active tab title placed in the
ACTIVETAB field of the structure my_tab_strip created with type TABSTRIP.
It is also mandatory that the PBO processing block contains a module in which the name of the subscreen is
placed in the corresponding variable.
TABSTRIP CONTROLS USING THE WIZARD
You can insert the tabstrip control on screens in a program using the Tabstrip Control Wizard. The wizard
also creates the respective statements in the flow logic, along with the required modules, subroutines, and
the data definitions.

Moreover, you can use the wizard to generate empty subscreens for the individual Tabstrip Control pages
and Includes for data definition, PBO modules, PAI modules, and INCLUDE statements for these includes.
21 INTRODUCTION TO OBJECT-ORIENTED PROGRAMMING

HISTORY OF SELECTED PROGRAMMING
ABAP was initially developed as an in-house programming language with reporting as the primary purpose.
It was influenced by other programming languages such as PASCAL and COBOL. Over the period of time, the
need to equip ABAP with several other functionalities was realized. This led to the introduction of concepts
such as OOPS or Object Oriented Programming and Structure. Only those OOPS concepts, which had been
successfully applied in developing other languages, such as C, C++, and Java were included. ABAP/4 was
extended to form ABAP Objects. Hence, ABAP has evolved as a combination of both procedural and object-
oriented elements.
CHARACTERISTIC OF THE PROSEDURAL PROGRAMMING MODEL
In a procedural programming model, data and the functions that work on the data are stored separately.
Data is available in the form of global variables, while functions can be the subroutines. However, in this
programming model, the access to global data is nonencapsulated. This means that any subprogram can
access the global data. Therefore, data access is not consistent.
TYPICAL PROSEDURAL ABAP PROGRAM

The structure of a typical ABAP program begins with type definitions and data declarations, which provide
information about the structure of data that the program will work on. The main program includes the
functions which perform certain actions on that data. The main consists of your modularization unit calls,
such as call of a subroutine or a function module call, followed by the corresponding definition of
subroutines. The definition of a subroutine starts with the keyword FORM and ends with the keyword
ENDFORM.
ENCAPSULATING DATA USING FUNCTION
When a function module is called in the program, the corresponding function group is loaded in the
internal session. The function group remains active until the program execution is finished. Function
modules of a function group can only be called from the main program. These have access to the global
data of a function group. In other words, a main program cannot directly access the global data of a
function group.
Thus, we can define a function group as a collection of data, and the functions that manage this data.
Therefore, encapsulation – one of the many concepts of OOPS – is realized in procedural model with the
help of function groups.

EXAMPLE OF A FUNCTION GROUP
Let us take the function group S_VEHICLE as an example. This function group contains services, such as
inc_speed, dec_speed, and get_speed.
These services form the interface of the function group, and access the global data object, speed, which
belongs to the whole function group.
The main program cannot access the function group’s data object speed directly.

SEVERAL INSTANCES OF ONE FUNCTION
If a main program requires several vehicles to work with, this would require extra programming effort.
Most importantly, a specific vehicle cannot be represented by a whole function group.
MULTIPLE INSTATIATION IN OBJECT-ORIENTED PROGRAMMING
The example shown in this slide contains four vehicles with different characteristic instances. However, all
these instances share the same data structure, range of functions, and have the ability to protect the data
against access from outside. This suggests that one of the key characteristics of object-oriented
programming is the creation of several runtime instances for a program context.

ABAP MAIN MEMORY AND ENCAPSULATION
Like Modularization units, which encapsulate the functions and work with the global data of the main
program, object-oriented programming makes use of objects for encapsulating data and functions
together. Multiple instantiation is supported. Like the function groups, the objects are also stored in the
same internal session of the program. All data areas are separated from one another to ensure the data is
protected.
DATA MANAGEMENT IN PROCEDURAL AND OBJECT - ORIENTED MODELS - SUMMARY
Unlike Procedural programming, object-oriented programming allows you to create a direct abstraction of
a real object. This is possible with the help of multiple instantiation, the concept of which is systematically
extended in the process.

ABAP OBJECT AS AN COMPATIBLE
ABAP differs from other object-oriented languages in the software development environment. The entire
range of functions of the ABAP Workbench can be used with ABAP Objects. ABAP Objects statements can
be used in procedural programs, and classes can contain procedural statements.
ABAP Objects is not a new language, but a systematic extension of ABAP. All the extensions including the
procedural parts are upwardly compatible.
Type checks in ABAP Objects are stricter than in procedural context.
All obsolete statements are cleared in the ABAP Objects context. Therefore, the use of such statements
may lead to syntax errors.
CLIENT/SERVER RELATIONSHIPS BETWEEN
In a generic way, a client can be defined as someone who procures certain services or asks for some
services; while server is someone who provides those services. In an object-oriented model, objects can
behave both as client or server depending on their role. In general, objects can perform both roles
simultaneously: They can provide services to other objects while requesting services at the same time. In
addition, the services are distributed amongst the objects in a manner which can avoid redundancies. This
ensures that each object offers only those services that are within its area of responsibility.
ADDITIONAL CONCEPT OF THE OBJECT - ORIENTED PROGRAMMING MODEL

ABAP object-oriented programming model or ABAP Objects also includes features, such as Inheritance,
Polymorphism, and Event controlling.
Inheritance defines the relationship between classes. It allows one class to not only adopt the structure or
behaviour of another class, but also to extend it.
Polymorphism is realized when instances of different classes respond differently to same messages.
Event controlling means that events are triggered by objects, if, at the time of development, it is not known
how objects will react.
OBJECT-ORIENTED PROGRAMMING MODEL: CHARACTERISTICS
To summarize, ABAP Objects has these key characteristics:

Objects are a direct abstraction of the real world.
Objects are collections of data and the functions belonging to that data.
Processes can be executed realistically.
OBJECT-ORIENTED PROGRAMMING MODEL: ADVANTAGES
The object-oriented programming model has various advantages:

Better software structure and more consistency in development
Reduced maintenance effort and lower incidence of errors
Integration of the customer and the user into the analysis, design, and maintenance process
Simpler and more secure software development process

THE SOFTWARE DEVELOPMENT PROCESS
The software development process is an iteration of four stages which constitute the whole development
cycle:
The first stage is requirement and idea.
The second stage is analysis and design.
The third stage is implementation.
The final stage is testing.
CLASSIFICATION ON OBJECTS
With object-oriented programming, the whole world can be realized as a collection of objects, for example
a class of different cars, airplanes, and people. All those objects which exhibit similar characteristics and
behaviour can be grouped together in a class. Thus, a class can be defined as a collection of objects with
similar characteristics and behaviour. For example, lcl_vehicle is an object of a class ‘car’. This object is a
concrete instance of a class.
CLASSES AS ABSTRACTION FORMS
In software development, abstractions are rudimentary models of the complex real world scenario.
Consider a car as an example. Different people can have different perspectives about the same car.
A car enthusiast is specifically interested in properties like price, features, and colour. Similarly, a scrap
merchant pays particular attention to properties like weight, and scrap value. However, both these
perspectives share some common features such as make, type, doors, wheels, and horse power. In
software context, a car enthusiast and a scrap merchant can be considered as two different classes.
Depending on the type of abstraction, a class can contain different aspects of an object.
COMPARISON OF CLASSES AND OBJECT
Let us put together the points to clearly understand the relationship between a Class and an Object.
Class gives the general description of objects.
It specifies status data or attributes and behaviour or methods.
On the other hand, Object is a real time representation of the real world. It is a concrete form or specimen
or instance of a class.
UML MODELING: DIAGRAM TYPES
Unified Modelling Language (or UML) is a globally standardized modelling language used for the
specification, construction, visualization, and documentation of models for software systems. It enables
uniform communication between users.
UML describes different diagram types to represent different views of a system. These three diagram types
are of particular significance:
Class diagrams represent the classes and the relationships between these in a static view of a model.
Behaviour diagrams describe the sequence in which the objects are related to each other.
Component diagrams depict the organization and dependencies of components.
REPRETATION OF A CLASS
A class is represented by a rectangle in UML notation.

You first specify the name of the class, then its attributes, and finally its methods. However, you can either
omit both the attribute part and the method part, or just one of the two.
Attributes define the data that can be stored in the objects of a class. They also determine the status of an
object.
Methods define the functions that an object can perform.
EXAMPLE OF A CLASS DIAGRAM

A class diagram illustrates all static relationships between the classes as shown here. There are two basic
types of static relationships:
Association
Generalization or Specialization
You can understand association relationship through an example where a customer books a car at a rental
car company.
You can understand generalization or specialization relationship through an example where a car, a bus,
and a truck are all vehicles.
ASSOCIATION
An association defines a semantic relationship between classes.

An association is represented by a line between the class symbols.
The cardinality, also referred to as multiplicity of the relationship, can be specified at each end of the line.
The cardinalities generally used are
0…* which means any number;
1 which means exactly one;
1…* which means at least one; and
0…1 which means at most one.

Arrows indicate the navigation options, that is, the accessibility of the association partner.
An association can have a name, and is written in italics above the line. It may contain an arrow to show the
direction in which it is to be read.
Each association has two roles, one for each direction of the association.
If roles are defined for both partners, role names can be entered at the end of the lines. Each role has a
cardinality that shows how many instances can participate in this relationship. The multiplicity or cardinality
is the number of participating objects in one class that have a relationship to an object in the other class.
In this example, a cardinality of “at least one” indicates that, only a person who actually makes a booking
becomes a customer of the rental car company.

ASSOCIATION WITH ROLES-EXMPLE
An example of multiple associations is shown here. lcl_person and lcl_company are two classes involved.
Employee and employer are role names used at the end of the association lines. This gives a more detailed
description of the relationships between the classes involved. A person can either appear in the role of
‘employee’ or ‘boss’ here.
Recursive association depicts two instances of the lcl_person class using role names: “child” and “parent”.
ASSOCIATION CLASSES
If association is used to link two classes, this relationship can be better represented by a special class. The
various characteristics of the relationship are described using the attributes of the association class. A
dotted line connects this additional class to the association line.

AGGREGATION AND COMPOSITION
Aggregation and composition are displayed as a line between two classes that is labelled with a small
rhombus.
Aggregation is a special case of association, a whole-part relationship.
An empty rhombus is a symbol of aggregation.
Composition is a special case of aggregation, based on whole-part relationship. Composition means that
the contained object cannot exist without the aggregate. Therefore, the cardinality of the aggregate can
only be one.
In UML notation, composition is denoted by a filled-in rhombus.
GENERALIZATION AND SPECIALIZATION
Generalization and specialization are specific relationships that exist between classes. These are always
bidirectional.
Generalization or specialization relationships are indicated by a triangular arrow. However, this arrow
always points towards the more general class. The extent of generalization increases in the direction of the
arrow.

OBJECT DIAGRAM
An object diagram illustrates the instances of the classes and the relationships between them. It can be
defined as a variant of a class diagram which shows or depicts one section of the class diagram. It is useful
for representing a complex class diagram.
In this example, an object diagram is represented as a “snapshot” of class diagram lcl_rental_booking with
three instances Booking Car 1, Booking Car 2, and Booking Truck 1. All the three bookings here refer to a
particular customer Mr. Smith of class lcl_customer. Attributes associated with the individual instances are
also shown.
SEQUENCE DIAGRAM
Sequence diagrams are used to display certain processes or situations which are a part of the lifeline of the
object. An object during its lifetime may create or delete objects or may exchange messages with other
objects. Sequence diagrams focus on the time sequence of their behaviour. In UML notation, the object
lifeline is depicted by dotted vertical lines with a box containing the object name at the top. An ’X’ is placed
at the point where the lifeline ends.
The control focus represented as a vertical rectangle on the object lifeline shows the object’s “active”
period.

Messages are depicted as horizontal arrows between the object lines. The message is written above the
arrow in the form of parameter as shown. The reply can be shown as a returning arrow.
DELEGATION PRINCIPLE IN A SEQUENCE DIAGRAM
Delegation involves two objects in a request handling process. The recipient of the request delegates the
execution of the request to a delegate.
In this slide, the driver sends the message get_fuel_level to the car. When car receives this message, it
sends a message to the tank to find out the tank details. In fact, the car delegates this task to the tank. If
required, the car modifies the information containing the current value of the tank contents before it
passes it back to the driver.
EXAMPLE OF A CLASS
This slide shows a vehicle as an example of a class. The name of the class is lcl_vehicle. The class lcl_vehicle
consists of Public components, Private components, and methods for implementation. The public
components are get_make and set_make. The private components are make and model. The keywords
public and private describe the visibility or accessibility of the components in that section. Public
components can be accessed outside the class. However, private attributes of the class are not accessible
“from outside.”

DEFINING CLASSES
A class is a collection of objects that have similar structure and behaviour. In other words, a class acts as a
blueprint on which all objects in that class are created. You can define a class using the keyword
‘DEFINITION’. Generally, the syntax followed is CLASS class_name DEFINITION. Every class definition should
end with keyword ENDCLASS.
All components of the class including attributes, methods, events, constants, and types are defined in the
definition part.
A class also has an implementation part described by the keyword IMPLEMENTATION. Syntax is similar to
that of definition part. Class implementation should also end with the keyword ENDCLASS. Only methods
are implemented in the implementation part.
EXAMPLE OF ATTRIBUTE
This slide shows make as an example of attribute for the class lcl_vehicle. Attributes contain the data that
can be stored in the objects of a class. Class attributes can be one of three types: elementary, structured, or
table-type. They can consist of local or global data types or reference types.
Objects can be pointers to another object as shown.

DEFINITION OF ATTRIBUTES, TYPES, CONSTANTS
In the definition part of a class, you can define local data structures, constants, and data objects which can
refer to local types or classes or interfaces.
Keyword TYPES is used to define the local data structures. Statement CONSTANTS is used within the class
definition to describe data objects that have a constant value. You can refer to data types by only using the
TYPE addition in DATA statements in classes. Similarly, the LIKE addition can only be used to define local
data objects or SY fields, for example SY-DATE and SY-UNAME. The READ-ONLY addition indicates that,
while a public attribute declared with DATA can be read from outside, it can only be changed by methods in
the same class.
You can type an attribute as a reference with TYPE REF TO.
VISIBILITY SECTIONS OF ATTRIBUTES

Public and Private visibility sections define whether an attribute can be accessed outside the class or not.
Public attributes of a class are generally visible and changeable. However, the read-only addition is an
exception to this.
Private attributes, on the other hand, are only visible within the class and are changeable only within the
class.
You can mark attributes as private attributes to protect these against access from outside. The private
components of the class are invisible to the outside user.
Here, r_veh which belongs to lcl_rental can only refer to public attributes of the class lcl_vehicle.
ACCESSING PRIVATE ATTRIBUTES
PUBLIC SECTION and PRIVATE SECTION of a class define the corresponding public and private attributes of
that class. It is syntactically impossible to access private attributes directly from outside. However, you can
do so by using public methods that change the attributes.
COMPARISON OF INSTANCE ATTRIBUTE WITH STATIC ATTRIBUTE

You can define two kinds of attributes:
Instance attributes exist once per object, which means, once per runtime instance of the class. They are
defined with the syntax element DATA.
Static attributes exist once for each class and appear for all runtime instances in that class. They are
defined with the syntax element CLASS-DATA.
INSTANCE ATTRIBUTES AND STATIC ATTRIBUTES IN THE PROGRAM
For example, let us consider n_o_vehicles to be the static attribute of the class. It exists only once. The
instances r_vehicle1, r_vehicle2, and r_vehicle3 are instances of the class lcl_vehicle. All these instances or
any number of instances can refer to the static attribute n_o_vehicles. Therefore, instances share their
common attributes.
SYNTAX FOR METHODS
Methods are internal procedures in classes that define the behaviour of the objects. They can change the
state of other elements by accessing all attributes in their class.
Methods have a signature that allows them to receive values when they are called, and in turn, send values
back to the calling program.
Methods can have any number of IMPORTING, EXPORTING, and CHANGING parameters. All parameters can
be passed by value or reference.
You can use the RETURNING parameter to define functional methods. Methods also support EXCEPTIONS;
but only if the signature exceptions are defined using EXCEPTIONS. You can use the RAISING addition to
propagate class-based exceptions. However, a combination of both cannot be used. The implementation of
the method is defined in the class implementation part as shown.
VISIBILTY SECTIONS OF METHODS
Object r_veh can access only the public attribute set_type of the lcl_vehicle class. Methods also have to be
assigned to a visibility section. This determines whether the methods are called from outside the class or
only from within the class.
Public methods can be accessed from anywhere; whereas Private methods can only be called within the
class.
ACCESSING PRIVATE METHODS
Private methods are defined in the PRIVATE SECTION of a class, whereas public attributes are defined in the
PUBLIC SECTION.

It is not possible to directly access private methods from outside. However, a private method can be called
by a public method.
In this example, INIT_TYPE is a private method that is called by the public method set_type.
COMPARISON OF STATIC METHOD AND INSTANCE METHOD
There are two types of methods, instance methods and static methods.
An instance method can access both static and instance components. Instance methods are defined using
the syntax keyword METHODS.
Static methods are defined at class level. Only static components can be accessed by a static method. These
methods are defined using the syntax keyword CLASS-METHODS.
In this example, only the static attribute gv_n_o_vehicles is accessible within the static method
get_n_o_vehicles. All other attributes of the class are instance attributes that can only be accessed within
instance methods.
VISIBILITY SECTIONS AND UML NOTATION

In a UML class diagram, a class is represented as a rectangular box with the class name first, and class
attributes and methods below it. The visibility of components of a class are shown in UML using the
characters + and -.
‘+’ indicates that the components are of type Public, while ‘-’ indicates that the components are of type
Private. Static components are represented with an underscore.
OVERVIEW OF INSTANCE OF CLASSES
During the program runtime, the class is used to create discrete objects or instances in the memory. This
process is called instantiation.
CREATE OBJECT statement is used to create objects. They can only be created and addressed using
reference variables. CREATE OBJECT r_vehicle statement creates an instance of the class lcl_vehicle at
runtime.
DEFINITION OF REFERENCE VARIABLE
The statement DATA go_vehicle1 TYPE REF TO lcl_vehicle is used to define a reference variable, which is
defined as a pointer to objects of type lcl_vehicle. The statement go_vehicle2 is also syntactically correct,
and therefore, creates another reference variable which refers to the class lcl_vehicle.

CREATING OBJECTS
The statement CREATE OBJECT creates an object in the memory.

Here, the CREATE OBJECT statement is used to create two objects go_vehicle1 and go_vehicle2.
REVERENCE SEMANTICS OF OBJECT REFERENCES
Reference variables can also be allotted to each other. Here, go_vehicle1, go_vehicle2,and go_vehicle3 are
reference variables of the class lcl_vehicle.
The statement go_vehicle2 = go_vehicle1 is syntactically correct. It means that after assignment both the
object references would point to the same object.

GARBAGE COLLECTOR
Independent references are those references that are not defined within a class. You cannot access an
object if there are no independent references that point to it. Hence, all those objects that cannot be
accessed syntactically are deleted by the Garbage Collector.
The Garbage Collector is a routine job that is performed whenever the runtime system does not have any
other important tasks to execute.
In this example, the reference to object (2)lcl_object is initialized. Later, as there are no references pointing
towards this object, Garbage Collector deletes it. As there are no references pointing to object (4)lcl_object,
it is deleted as well.
REFERENCE ADMINISTRATION WITH MULTIPLE INSTANTIATION
If there are several objects that refer to the same class in a program, then it is possible to store all objects
together. This can be done by defining an internal table that contains one column with the object
references for this class. These objects can be put in the internal table with the usual statements for
internal tables, such as APPEND, READ, or LOOP.

EXAMPLE OF AGGREGATION
Any number of objects to the class lcl_vehicle can be created as shown in the slide. Each object in the class
lcl_wheel has its own identity. Objects can exist irrespective of the existence of any other object in the class
lcl_vehicle.
The desired association appears after references are transferred to the objects of the class lcl_vehicle.
CALLING METHOD
A class consists of attributes and methods. In this example, let us call motor_on method of the class
lcl_vehicle. An object reference to the class, go_vehicle uses the data statement. The syntax to call the
method motor_on consists of reference variable, followed by object component selector, followed by the
method name. The name of the method must be followed by open and close parentheses with a space in-
between.

CALLING INSTANCE METHOD - SYNTAX
The syntax for calling instance methods is CALL method ref → method_name. The interface parameters:
EXPORTING, IMPORTING, CHANGING, RECEIVING, and EXCEPTIONS can be specified in the method call.
A shorter syntax is also supported. In this case, CALL METHOD is omitted, and the parameters are listed in
parentheses. There must be no space before the parentheses, but there must be at least one after the
parentheses.
In this example, method call also has RECEIVING parameters which specify that the method is a functional
method.
FUNCTIONAL METHODS
Functional methods are defined as methods that have exactly one RETURNING parameter. They can only
have IMPORTING parameters and exceptions.
A functional method call will have explicit assignment of RECEIVING parameter. Functional methods can be
called implicitly within various expressions such as

MOVE, CASE, LOOP;
Logical expressions, such as IF, ELSEIF, WHILE, CHECK, WAIT; and
Arithmetic expressions and bit expressions, such as COMPUTE.
FUNCTIONAL METHODS - EXAMPLE
In this example, the call of a functional method is shown supplying all the necessary parameters. The
second example shows the call of a functional static method in the short form.
RETURNING VALUE(r) blah

Instead of the additions EXPORTING and CHANGING, a functional method has an addition RETURNING, which
defines precisely one formal parameter r as a return code. The return code must be passed by value
using VALUE
EXPORTING or CHANGING is not allowed in this form. Exceptions are ok.
ACCESSING PUBLIC ATTRIBUTES
The public attributes of a class can be accessed from outside the same way as method calls.
Static attributes are accessed using classname=>static_attribute.
Instance attributes are accessed with ref → instance_attribute.

However, the instance method call is possible only if the attributes are public.
(INSTANCE) CONSTRUCTOR
Constructor is a special method of a class which is automatically called by the runtime system when an
object of the class is created. The constructor is automatically called at runtime with the CREATE OBJECT
statement. A constructor can only have IMPORTING parameters and exceptions.
CONSTRUCTOR - EXAMPLE
This example shows how a CONSTRUCTOR is called and implemented. The parameter values are passed to
the constructor in the method definition.

EXAMPLE OF STATIC CONSTRUCTOR
Static constructor is a special static method in a class. It is defined as class_constructor. It is executed only
once per program (and class). It cannot have parameters or exceptions. The static constructor is called
automatically at the first access of the class during the program run.
SELF REFERENCE
An object can address itself by using the predefined reference variable ME within its instance methods. In
general, you do not need to use the prefix
me → . However, it can be used to improve readability.
EXAMPLE OF GENERALIZATION / SPECIALIZATION

As shown here, lcl_vehicle is a superclass; and lcl_car, lcl_truck, and lcl_bus are subclasses of the
superclass. All the common properties of these subclasses are defined and implemented in the superclass.
Therefore, from the perspective of a superclass, each subclass is a special part of a superclass containing
properties that are both common as well as specific to it.
Specialization is often described as an “is a” relationship. In this example, you can say that “A truck is a
specific vehicle.”
However, if we look at the same relationship from the perspective of a subclass, it is termed as
generalization. This is because all subclasses contain the common properties defined in the superclass.
CHARACTERISTIC OF GENERALIZATION / SPECIALIZATION
Generalization or specialization offers an improved structure to the software, as commonly used elements
are stored only once in a central location known as superclass. Components in a superclass are then
automatically available to all the subclasses. You must know how to implement a superclass in order to
determine whether the inherited components from the superclass are sufficient for the subclass, or if they
need to be extended.
However, subclasses can be extended or changed as per the requirement.
Thus, there are very strong links between the superclass and the subclass, which are dependent on the
superclass.

INHERITANCE - SYNTAX
Inheritance relationship is defined syntactically using the INHERITING FROM addition in the definition of a
subclass, followed by the superclass name as shown in the slide. Superclass definition is the prerequisite for
an inheritance relationship to be established. A subclass can access some of the properties of a superclass
through inheritance. In this example, the subclass lcl_truck will also contain the superclass method
set_type.
you cannot have multiple inheritance, but u can achieve it using interfaces.
REDEFINING METHOD
Keyword REDEFINITION is used when the inherited methods from the superclass needs to be extended.
However, the signature of the inherited method should not change.
If the keyword REDEFINITION is used, a new implementation part for that method must be specified. As
shown here, in a redefined method’s implementation part, the keyword “super” can be used to access the
components of the superclass.

PRESERVING SEMANTICS DURING REDEFINITION
As shown in the slide, the class lcl_bus and class lcl_truck both contain the method display_attributes; but
the output of the method is different. Most importantly, the semantics of the method have not changed.
DEFINITION OF THE CONSTRUCTOR IN SUBCLASSES
Constructors in inheritance do not follow the same rules as the other instance methods when they are
redefined. The constructor of the superclass can be used as it is or changed in the subclass, which means
that the signature of the constructor can change.
However, it is compulsory to call the superclass constructor during its implementation in subclass.
RULES FOR CALLING THE CONSTRUCTOR

Let us look at the classes: lcl_1, lcl_2, and lcl_3. Objects go_2 and go_3 refer to the classes lcl_2 and lcl_3,
respectively as shown. The class lcl_3 has a constructor with two parameters. Values to the constructor
parameters can be supplied directly through the object as shown in case 1. However, if the constructor is
an inherited one as in case 2, then you need to search the superclass constructor in the hierarchy.
Subsequently, the values are supplied to the parameters.
INHERITANCE AND VISIBILITY
The visibility of the components of a class, which was restricted to Public or Private, is extended using
inheritance. We now have protected components whose visibility lies between public and private.
Components that are categorized as protected are visible to the class and all its subclasses.
However, when local classes are defined, the syntactical sequence followed for the visibility sections is:
PUBLIC SECTION, PROTECTED SECTION, and PRIVATE SECTION.

PROTECTED VERSUS PRIVATE SECTION
We already know that the public components of a class can be accessed from outside; whereas the private
components can only be accessed from within the class. Consider the class lcl_bus which inherits from the
superclass lcl_vehicle. Here, mv_make and mv_model are private attributes of the class. Although they are
inherited, they cannot be accessed directly. Therefore, lcl_bus only has public methods, constructor and
display_attributes, as well as the protected attribute mv_color. These can only be accessed from inside.
STATIC COMPONENT : PROPERTIES
All subclasses of a superclass can access its public or protected static attributes.
Redefinition of static methods is not possible.
When the superclass or one of its subclasses is accessed for the first time, the static constructor of a
superclass is executed.
A subclass can define a static constructor of its own irrespective of whether the superclass has one or
not.
If both subclass and superclass contain a static constructor, then both will be executed whenever the
class is accessed for the first time.

UP-CAST (WIDENING CAST) WITH OBJECT REFERENCES
Let us say that the class lcl_truck is a subclass of the superclass lcl_vehicle. Object reference variables to
both the classes are defined using the data statement. Using the statement go_vehicle = go_truck, we are
assigning an object reference of type subclass to a superclass reference variable. After assignment,
go_vehicle can access the inherited components in the subclass as shown. This is up-cast or widening cast.
STATIC AND DYNAMIC TYPE OF REFERENCES
The statement DATA go_vehicle TYPE REF TO lcl_vehicle creates a static reference variable. So a static
reference variable
is defined using the TYPE REF TO addition;
remains same throughout; and
specifies what attributes and methods can be accessed.
On the other hand, go_vehicle in the second diagram is a dynamic reference variable which
is created by assignment;
can change during the execution of a program; and
specifies which attributes and methods can be implemented.

GENERIC ACCESS AFTER UP-CAST
With the help of cast assignments, generic access to the subclass components by a reference variable of
type superclass is possible.
When a user is not at all interested in the finer points of the instances of the subclasses but simply wants to
address the shared components, the user can make use of a superclass reference for this access.
ROLE TYPE IN THE INTERNAL TABLE IN THE APPLICATION EXAMPLE
In this example, objects of different classes, lcl_bus, lcl_truck, and lcl_car, have references of type
superclass lcl_rental. Here, it is possible to store all these object references in an internal table.
UP-CAST AND GENERIC ACCESS IN THE APPLICATION EXAMPLE

This slide explains that up-cast assignment occurs when the vehicle reference is passed to the formal
parameter of the add_vehicle method. Shared components can be accessed using the loop at the internal
table containing all the vehicle references.
POLYMORPHISM: GENERIC ACCESS USING THE SUPER-CLASS REFERENCE
The output of the method display_attributes depends on the object to which the superclass reference
variable – go_vehicle – points. As shown in the slide, the output of the method display_attributes is
different in the two method calls.
GENERIC CALLS IN THE PROCEDURAL PROGRAMMING MODEL

As shown here, gt_vehicles is a collection of vehicles in an internal table. The CALL FUNCTION statement
inside the loop displays the properties of individual objects. This can also be done using a function group
which contains different function modules.
DOWN CAST (NARROWING CAST) WITH OBJECT REFERENCES
In this example, the superclass reference variable go_vehicle is assigned to the subclass reference
go_truck2. After this assignment, go_truck2 can access all the public components of lcl_truck as shown.
This is defined as narrowing cast or down cast. The down-cast operator (?=) used in the process is shown in
the example.

SPECIFIC ACCESS AFTER DOWN CAST ASSIGNMENT
All vehicle reference types are stored in an internal table that is typed as lcl_vehicle. You require down-cast
assignment to address specific components of instances. It is also needed for keeping references of these
instances in variables which are typed on the superclass.
DOWN CAST AND EXCEPTION HANDLING IN APPLICATION EXAMPLE
In down-cast assignment, if the static target reference is not type compatible with the source reference,
exceptions can be raised. As shown in this example, the exception class – cx_sy_move_cast_error – which
can raise the exception is caught using the CATCH statement within the TRY-ENDTRY block.

USAGE OF CLASS HIERARCHIES
If a generalization or specialization relationship is observed between certain classes, then inheritance can
be used to represent this in ABAP Objects. There are various advantages of linking classes through
inheritance concept:
It allows for centralized maintenance.
It enables safe and generic method of access. The software component can be easily extended.
EXAMPLE: MISUSE OF INHERITANCE
If the concept of “is a (specific)” is not understood properly, then the direction of inheritance could be
easily misunderstood, which can be risky. For example, the class, car, has two subclasses, red and blue.
The statement “A red car is a specific car” may seem correct initially. This means every car must have the
attribute Colour, assuming that it is relevant to the application. Thus, the attribute has to be predefined in
the superclass; otherwise, the authorizations for subclasses of this type are no longer possible. This may
sound contradictory in a real life scenario.

CENTRAL DEFINITION OF SHARED COMPONENTS
An interface can simply be defined as a superclass that cannot be instantiated. This means that they do not
have an implementation part. All the components of an interface are public. In ABAP Objects, the
components which are defined in a superclass can be defined with interfaces. Let us look at an example to
understand this.
As shown in the example here, the interface can be suitably modelled to provide appropriate services to
the classes, lcl_carrier, lcl_hotel, and lcl_rental.
THE CLIENT DEFINES A PROTOCOL
Interfaces are like superclasses that do not have an implementation of their own. In an interface, a client
defines the services that they expect different classes to perform. Each class can now decide whether it
needs to implement the interface. This is similar to the specialization relationship with the superclass.

INTERFACE IN UML NOTATION
Interfaces are represented in the same way as classes in a UML notation. The name of the interface also
contains the stereotype “«interface»” addition, which is optional. The use of an interface is shown by a
dotted line with a two-sided arrow pointing from the user to the interface. A class implementing an
interface is represented by a dotted arrow from the class to the interface.
DEFINING AND IMPLEMENTING INTERFACE
An interface is defined using the keyword INTERFACE followed by its name. Here, the interface contains a
method display_partner. An interface does not have different visibility sections like classes. Therefore, all
the components of an interface are public in nature. An interface is called in the method definition using
the keyword INTERFACES, as shown. After the interface call, the methods of the interface can be
implemented in the class definition. Interface method is implemented using the syntax, interface name,
‘tilde’ operator, followed by the method name, as shown. The tilde operator is also known as the interface
resolution operator.

ADDRESING INTERFACE COMPONENT USING OBJECT REFERENCES
As shown in the slide, class lcl_rental implements the interface lif_partner. This interface (lif_partner)
contains two methods, display_partner and check_availability. Components of an interface can only be
accessed using an object reference of the class which implements the interface. Here, go_rental is the
object reference of the class lcl_rental. The interface method can be called using the syntax, go_renta →
lif_partner~display_partner ( ).
UP-CAST WITH INTERFACE REFERENCES
The class – lcl_rental – implements the interface – lif_partner – and can therefore access the methods of
the interface. We have reference variables go_rental and go_partner of type class and interface,
respectively. The object reference – go_rental – created using the data statement can access the public
components of the class. When this object reference is assigned to a reference variable of type interface,
interface reference variable can also access the interface components. This is up-cast using interfaces.
However, after assignment, go_partner can only access the interface components.

ROW TYPE OF THE INTERNAL TABLE IN THE APPLICATION EXAMPLE
This slide depicts different classes, lcl_hotel, lcl_rental, and lcl_carrier, all of which refer to
lcl_travel_agency. The objects of these different classes can be managed using an internal table of type
lif_partner.
The components of the interface can be accessed uniformly using the method – add_partner – as its
parameter is already typed as a reference to the interface.
POLYMORPHISM - GENERIC ACCESS USING THE INTERFACE REFERENCE
Interface references can be used to call methods, which give different outputs based on the object
reference they point to. In this example, the implemented method – display_partner – displays different
output depending on the object reference it refers to dynamically.
DOWN-CAST ASSIGNMENT AND EXCEPTION HANDLING IN THE APPLICATION EXAMPLE

At runtime, interface reference variables can point to instances of the implementing class. After this type of
assignment, where a reference variable points back to a reference of the implementing class, access is not
limited to the interface components. As shown here, all components of the lcl_carrier instance can be re-
accessed after the assignment using reference r_carrier.
CX_SY_MOVE_CAST_ERROR = type cast exception at runtime
INTERFACE HIERARCHY IN THE APPLICATION EXAMPLE
Let us understand the extension of interfaces using this example. As shown here, both lcl_motel and
lcl_hotel implement the interface, and request for a particular service which must be included in the
interface. It cannot be defined individually for both. However, it should also be noted that there are several
other objects already referring to the interface. Hence, it is a matter of debate whether an extension of this
kind is appropriate.

COMPOUND INTERFACE IN UML NOTATION
This slide illustrates two interfaces, lif_partner and lif_lodging. As we all know, interfaces can include other
interfaces. The including interface is known as a compound interface. The included interface is represented
as a component of another interface and is, therefore, known as a component interface.
In abap objects, interfaces like regular superclasses can include other interfaces. As with regular
inheritance, the interface hierarchies can be of any depth.
DEFINITION AND IMPLEMENTATION OF COMPOUND INTERFACE : SYNTAX
In this example, interface – lif_partner – is a component interface, and therefore, it is defined first. This
interface is included or called in another interface – lif_lodging – using INTERFACES statement. Thus, the
interface – lif_lodging – is now a compound interface. Class lcl_hotel implements the interface – lif_lodging.

As it is a compound interface, lcl_hotel can also access display_partner, which is a method in the
component interface. This is similar to how it can access method – book_room – in compound interface.
ADDRESSING COMPONENT IN COMPOUND INTERFACE - SYNTAX
Up-cast and down-cast assignments are possible with compound interfaces. In case of up-cast, after the
cast assignment occurs, go_lodging can call the methods, display_partner and book_room. Similarly,
go_partner can call display_partner method as shown. In the same way, specific methods can be accessed
using down-cast assignment.
USING INTERFACE
When generalization or specialization relationships are created using an interface, it can help in
defining protocol and services separately;
allowing safe and generic method of access; and
realizing multiple inheritances.

What all this means is that, the software can be extended easily.
EVENT-CONROLLED METHOD CLASS
Events, like attributes and methods, are components of a class. Events are of two types: Instance events
and Static events. Instance events are triggered by the instances of the class, while static events are
triggered by the class itself.
Whenever an event is triggered at runtime, the system calls for handler methods to respond to the event
call.
In this example, creation of an instance in the “vehicle” class triggers the event “vehicle created.” This
event is processed differently by different instances. For example, the car rental company considers
purchasing a vehicle, while the vehicle registration office registers the car.
EVENT HANDLING IN A UML CLASS DIAGRAM
In UML notation, events are represented by a dotted arrow with the stereotype «handlesEventOf» pointing
from the handling class to the triggering class. In the example shown here, lcl_rental is the handling class
which handles the event – vehicle_created – triggered in raising class lcl_vehicle. The definition and
signature of the event are defined in the handler method inside the handling class.

TRIGERING AND HANDLING EVENT - OVERVIEW
Instance events are defined with the keyword EVENTS; while static events are defined using the keyword
CLASS-EVENTS. Objects of a class or the class itself can trigger the event using the RAISE EVENT statement.
Once an event is triggered, it has to be handled. To handle a raised event, we can make use of a handler
method of the handler class using the methods...FOR EVENT … OF …statement as shown; or by using a
handler object with the SET HANDLER statement.
DEFINING AND TRIGERING EVENTS - SYNTAX
Instance events are defined using the EVENTS statement; while static events are defined using the CLASS-
EVENTS statement. The signature of events can only have exporting parameters, which must be passed by
value. A class or instance can trigger an event at runtime using the RAISE EVENT statement as shown.
Instance methods can trigger both instance events and static events; whereas static methods can only
trigger static events.

HANDLING EVENTS - SYNTAX
Event handling by the instance or static method within a class requires FOR EVENT addition with the event
name, along with the OF addition with the class or interface name. If the event has exporting parameters,
then in order to pass values to these, you need to specify exporting parameters immediately after the
keyword IMPORTING in the method definition.
In addition to the explicitly defined exporting parameters, the predefined importing parameter, sender, can
always be listed. Using this parameter, you can place a reference to the event-trigger object into the
handler method.
Instance events can be triggered by the instances of the class, but static events are triggered by the class
itself.
REGISTERING EVENT HANDLING
When an event is raised, it must be handled appropriately by a handler method. There can be many events
which may be triggered. The handler method determines which event of which class method will react, and
how it will react. At runtime, the system also determines which possible reactions will take place and at
what time.
These specifications are collectively referred to as registration. It is always carried out using the trigger. The
runtime makes use of the registrations of the trigger to determine which event handler methods need to
be called.

REGISTERING EVENT HANDLING - SYNTAX
Events are only registered during the program runtime using the SET HANDLER statement. Syntactically in
instance events, FOR addition is followed by the reference to the object that triggers the event. The
addition – ACTIVATION 'X' – is optional during registration. Several methods can be registered with one SET
HANDLER statement.
REGISTRATION/DEREGISTRATION: HANDLER TABLES
All events defined by an object or a class are stored in an internal table, also known as the handler table.
This example shows handler table for two instances, ‘bus1’ and ‘bus2.’ All handler methods registered to
the various events are listed within the table. The handler table also contains references to the registered
objects in case of instance methods.

EVENTS: VISIBILITY SECTION
Events and event handler methods can be categorized as public, protected, or private on the basis of their
visibility.
The visibility of an event determines where the event can be handled:
PUBLIC events can be handled outside.
PROTECTED events can only be handled within that class or its subclasses.
PRIVATE events can only be handled within its class.
The visibility of a handler method determines the locations where the SET HANDLER statement can be
programmed.
If the handler is defined in PUBLIC SECTION, the SET HANDLER statement can appear anywhere in the
program.
If the handler is defined in PROTECTED SECTION, the SET HANDLER statement can appear within that
class or its subclasses.
If the handler is defined in PRIVATE SECTION, the SET HANDLER statement can only appear within its
class.
CREATING GLOBAL CLASSES IN THE OBJECT NAVIGATOR

Global classes can be created using the context menu in the navigation area of Object Navigator. In the
Object Navigator screen, select the package or directly select the class node within the package and choose
Create.
Subsequently, a dialog box appears where you need to specify additional attributes. You should not make
any changes to the default attributes at this point.
DEFINITION OF ATTRIBUTES
When a class description is specified, the control automatically takes you to the Class Builder screen, as
shown here. The Attributes tab helps you to list the required attributes of the class. You can also define
new attributes here and use the input help to define the type of attributes.

DEFINITION OF METHODS
The Methods tab contains a list of all the method definitions in the class. You can add new methods and
give a brief description of each of these by using the input help. It is crucial to specify the signature for each
method. This can be done with the help of Parameter button.
DEFINITION OF METHOD SIGNATURES
When you select a method and click the Parameter button, a screen appears to specify the desired
parameters for that method.
In this example, IV_NAME and IV_PLANETYPE are the defined parameters for the CONSTRUCTOR method.

IMPLEMENTATION OF THE METHODS
There are two ways of carrying out method implementation. You can either double-click a method name
from the method list, or select a method and click the Source code button. Subsequently, the control shifts
to the screen shown here. The source code implementation for the method is defined here. The Signature
button on the screen displays the parameters of the method.
DISPLAYING THE METHOD DEFINITIONS
In the header area of the Class Builder screen, choose Goto → Method definition to modify the number of
attributes of a method. You can define the handler method using the attributes tab.

DEFINITION OF COMPONENT USING THE NAVIGATION AREA
You can define methods, attributes, and events in the Object Navigator’s context menu. You need to right-
click the class name, and choose Create. After doing this, you can view the appropriate list of objects that
can be created.
THE CLASS BUILDER TESTING ENVIRONMENT
To test an active global class, click the test icon in the initial Class Builder screen. An instance of the class
needs to be created to test instance components. In the next screen, select the Instance button to create
an instance of the class. You can execute the method by clicking the clock symbol, which appears as soon as
the instance is generated.

SEPARATION OF NAVIGATION AND EDITING AREAS INTHE OBJECT NAVIGATOR
The navigation area and the editing area are two separate sections in the Object Navigator screen. You can
view the Attributes and the Methods tabs in the navigation pane. You can use the ABAP Editor to make any
changes in the objects in the navigation area.
OBJECT INSTANTIATION USING DRAG AND DROP
Drag a class name to the editing area by holding the left mouse button, in order to create an instance of the
class in Object Navigator. The system automatically generates the CREATE OBJECT statement. You can then
specify the reference variable and the parameters for the statement, if required.

You can generate method calls using drag and drop approach. For this, select a method name from the
navigation area and drag it to the editing area. This automatically generates a CALL METHOD statement.
However, you need to specify both the reference variable and the actual parameters.
DEFINING AN INHERITANCE RELATIONSHIP
You can define the inheritance relationship for a global class by choosing the Properties tab in the Class
Builder screen. The system also proposes for a Superclass. In this example, ZCL_AIRPLANE_00, is the
superclass, and its properties are inherited in the subclass.

REDEFINING AN INHERITED METHOD
An inherited method can be redefined using the redefine button. When a method is redefined, the
Superclass call appears as a comment.
DEFINING GLOBAL INTERFACES
Global interface is created in Object Navigator in the same way as global class. Right-click the interfaces in
the navigation area. In the resultant dialog box, you can specify the name of the Interface and give a
description. You must adhere to the naming conventions meant for user-defined interfaces.

INCLUDING GLOBAL INTERFACES
Once an interface is defined, it automatically appears in the appropriate Method tab with the specified
name. As shown here, double-click a method name to define the implementation f a global interface.
However, interfaces can also be included in a class by selecting the Interfaces button.
IMPORTING A LOCAL PROGRAM CLASS
You need to follow a simple procedure to import local classes into a global class:
Navigate to Class Builder using menu options or call transaction SE24.
In the Initial Screen, select Object type → Import → Local classes in programs. Enter the Program name,
and if local classes and interfaces exist within the program, select Expand Includes.
Select Display Classes or Interfaces.
Specify names for the global classes and interfaces that you want to create with the proper naming
convention.

Select the global classes and interfaces and click the Import button.
GENERATE A UML DIAGRAM FOR A PACKAGE
To view the UML diagram for your package, right-click the package name, select Display, and then select
UML Class Diagram.
DEFINING A LOCAL TYPE
Local class or interface can be defined in a global class using Types. The components of the global class can
access this local class or interface. However, they cannot be accessed from outside.

STRUCTURED DISPLAY OF INHERITED COMPONENTS
Click the Group by button to view the components of a global class in a structured format. Select the Group
by interfaces and superclasses option to get the desired result.
SORTING THE COMPONENT DISPLAY OF GLOBAL CLASSES
The components can be sorted using the Sort button. You need to select the sorting criteria from the dialog
box that appears. This shows the desired result.
SEPARATING THE NAVIGATION AND EDITING AREAS OF THE OBJECT NAVIGATOR

Global classes and interfaces are also included in the navigation area of the Object Navigator screen.
Double-click an object name to edit it in the editing area.
OBJECT INSTANTIATION USING DRAG AND DROP
An instance of the class is created in Object Navigator. Drag the class name to the editing area. The system
automatically generates the CREATE OBJECT statement. If required, the user specifies the reference
variable and the parameters.

When you select a method name from the navigation area and drag it to the editing area, the CALL
METHOD statement for that method is automatically generated. However, the reference variable and the
actual parameters need to be specified.
WORKING WITH THE REFACTORING ASSISTANT
The existing repository objects can be modified using Refactoring Assistant. As shown in this example,
Refactoring Assistant can be used to move the components of a class within the inheritance hierarchy.

22 ALV Grid Control
Is a tool for displaying non hierarchical lists in a standardised form.
Contains standard functions like print and export
When you change the contents of internal tables while the program is running, you need to call the method
REFRESH_TABLE_DISPLAY

Using ALV, we can have three types of reports:
 Simple Report
 Block Report
 Hierarchical Sequential Report
Simple report –
If the output data is from a single dictionary table and all the columns are selected, then we need not
exclusively create the field catalog. It’s enough to mention the table name as a parameter
(I_structure_name) in the REUSE_ALV_LIST_DISPLAY. But in other cases we need to create it.
Block Report
This looks like a simple report but this report has the features of sorting and filtering only. This
report is used if you have to display more than one report on the output. Technically speaking if you
have multiple internal table with data to be displayed as separate blocks then we go for block report
of ALV.
Hierarchical Reports
Hierarchical display is used for displaying data that are related. Like sales order and item details.
Here sales order details can be the header data whereas them items in the sales order can be the item
data
BADIs
BADI stands for Business Add Ins Just like Customer Exits , BADI help hook custom enhancements to SAP
functionality. Example of a BADI: In transaction CAT2 - Time Sheet Entry, HR wishes to include an
interactive acknowledgment that knowingly submitting incorrect data is grounds for dismissal. This can be
achieved using BADI

Features:
 BADI's are Object Oriented
 They can be implemented multiple times
 It does not require SAP Software Change Registration
 No effect on release upgraded on the functioning of BADI's

Define and Implement a BAPI
This involved three steps Step 1 Creating BADI Definition : Transaction SE18.

Step 2 Define BADI interface: Transaction SE19
Step 3 Define a class implements the interface : During implementation creation, a class for implementing
the enhancement's interface is also created
With a badi, an SAP application provides the enhancement option through an interface and an adapter
class implementing the interface.

A reference variable for the type of badi must be defined. An object of the adapter class is instantiated by
the call get_instance static method of the cl_exithandler class.
To search for BADIs
 Use the repository information system
 Use the application hierarchy
 Use IMG customising guide
 Search for get_instance static method
 Search for occurrences of badi interfaces with the naming convention IF_EX_
 Occurrences of get_badi

ABSTRACT CLASSES AND ABSTRACT METHODS
You can use the keyword, ABSTRACT, to withhold a class from being instantiated. The syntax used for this is
CLASS class_name DEFINITION ABSTRACT.
Methods of an abstract class can be of type abstract. This means that their implementation is not defined.

FINAL CLASSES AND METHODS.
The FINAL addition in a class definition prevents it from being inherited. The syntax followed is CLASS
class_name DEFINITION FINAL. All the methods of a final class are by default final in nature, which means
they cannot be redefined.
READ TO A TABLE WITH OBJECT REFERENCES
Object references that are similar in nature are stored in internal tables with key information. These
references can be easily retrieved using this key information.

READ ACCESS USING PUBLIC ATTRIBUTES
When information is stored in an internal table with key values, the key attributes are specified as public
with the READ ONLY addition to avoid redundancy. These public attributes can be directly accessed when
internal tables are accessed. The keyword, TABLE_LINE, is used when the line type of an internal table is of
elementary data type.
NAVIGATION METHODS AND CHAINING OF METHOD CALLS
Association implies that at runtime an instance of one class can store references to the objects of another
class. In this example, lcl_vehicle and lcl_rental are the classes associated through the navigation method,
get_vehicle. Initially, it was necessary to store the reference to the new object in a reference variable. Now,
with the release SAP Netweaver 7.0 EhP 2, we can chain method calls. Therefore, it is now possible to call a
method of the object returned by the navigation method.

INSTANTIATION: VISIBILITY SECTIONS
The visibility of the instance constructor can be controlled, which means that the CREATE OBJECT
statement used to instantiate this class is also restricted to specific areas.
If the instance constructor is PRIVATE, then it can be instantiated only within the class.
If the instance constructor is PROTECTED, then it can be instantiated by all the subclasses.
If the instance constructor is PUBLIC, then it can be instantiated anywhere.
IMPLICIT SETTING OF THE INSTANCE CONSTRUCTOR'S VISIBILITY
The example shown in the slide gives a syntactical representation of the visibility concept. The visibility of
the instance constructor is implicitly defined as PUBLIC, PRIVATE, and PROTECTED using the keyword,
CREATE, in the class definition.

EXAMPLE FOR A CLASS WITH FACTORY METHOD
In this example, the class, lcl_airplane, keeps a reference of all its instances in a static attribute. The
instantiation is permitted within the class itself and can only be done in static METHOD factory. When the
method is called, it first checks if an identical instance already exists. If it does, then it returns the existing
instance, instead of creating a new one.
SINGLETON CLASS 1: USING A FACTORY METHOD
Singleton class is a special case of the factory concept, wherein the class stores only one instance. The class
is instantiated on the first call of the factory METHOD, get_instance. For all the future calls, only the
reference of the existing object is returned.

SINGLETON CLASS 2 : USING THE STATIC CONSTRUCTOR
As shown in this slide, the class, lcl_singleton, makes use of a static constructor to create an instance. The
get_instance method no longer creates an instance, but only returns the reference of an already existing
one.
DEFINITION OF A FRIENDSHIP RELATIONSHIP BETWEEN CLASSES
A class can access the protected and private components of another class using the friendship concept.
Syntactically, a class can become a friend of another class using the keyword, FRIENDS. Friendship is a one-
sided relationship. In this example, the class lcl_2 is able to access the private attributes of the class lcl_1
after declaring it as a friend.

EXAMPLE OF A FACTORY CLASS
In this example, the public static method, create_airplane, either instantiates the class lcl_factory or returns
a reference to an instance that already exists.
AN OVERVIEW OF THE CLASS-BASED EXCEPTION CONCEPT
An exception can be defined as an intermediary situation between program run and execution, after which
it is irrelevant to continue the program any further. In this example, we will see how exceptions and
exception handling are realized using classes.
An exception is represented by an exception object, which is an instance of an exception class. Exception
classes are predefined in ABAP. However, a user can also define an exception class.
An exception is raised using the RAISE EXCEPTION statement, which instantiates the exception class.
Attributes of the exception contain the error information. Every exception that is raised is handled by the
exception handling block that analyses its attributes.

EXCEPTION CLASSES: THE INHERITENCE HIERARCHY
Exception classes are already predefined in the system. All exception classes are derived from CX_ROOT
which implements the interface IF_MESSAGE. It contains the get_text method, which returns an exception
text in the form of a string. CX_ROOT cannot be inherited directly. Therefore, any new exception class that
is defined is inherited from any of its subclasses, such as CX_NO_CHECK, CX_DYNAMIC_CHECK, and
CX_STATIC_CHECK. The method – get_source_position – returns certain details, such as the name of the
main program, the name of the include program, and the line number in the source code where the
exception occurred.
STRUCTURE OF TRY-ENDTRY BLOCK
An exception that is raised is handled using a CATCH statement in the TRY-ENDTRY block. The try block
contains statements for which exception needs to be handled. Exception handlers associated with different
exceptions are defined in the CATCH block. When an exception is raised, the system automatically searches
for an appropriate CATCH statement in the TRY-ENDTRY block. If a handler is not available in the TRY-
ENDTRY block, then the CLEANUP block is executed.

EXAMPLE SYNTAX FOR HANDLING PREDEFINED EXCEPTION
Let us understand exception handling with the help of an example. The variable gv_result in the TRY block
holds a particular value based on the operation defined. The predefined exception –
CX_SY_ARITHMETIC_OVERFLOW – should be raised if the value of the variable gv_result exceeds its
permissible type limit (int).The INTO addition in CATCH statement is used to specify a reference variable
(gx_exc) of type cx_root to hold the attributes of the exception object. The string variable – gv_text – is
used to display the exception information using the get_text () method.
CLASS-BASED EXCEPTION IN DEBUGING MODE
In debugging mode, if an exception is caught in the CATCH block, the user is intimated through a success
message and that particular CATCH statement is displayed. As shown here, the user can make use of
pushbuttons to see the corresponding exception object and the source code where the exception
originated.

CREATING GLOBAL EXCEPTION CLASSES
User-defined exception classes can be created using the class builder or Object Navigator. Select option
‘Create’ from the right-click context menu options, as shown here. Specify a class name with a class type.
Follow naming convention while specifying the name for a user-defined class. As of SAP NW AS 6.40,
message classes can be used to display information.
DEFINE VARIABLE EXCEPTION TEXTS
User-defined attributes can be used to provide information for exceptions.

As of SAP NW AS 6.40, you can use message classes to display information. User can provide the text for
exception using the ‘Texts’ tab, as shown.

VARIANTS OF STATEMENTS RAISE EXCEPTIONS ........
You can create and raise exceptions with any of these syntaxes:
RAISE EXCEPTION TYPE <exception_class> [EXPORTING ...] statement creates an instance of the
exception class and raises the exception in a single step. Attributes to the exception can be passed through
a constructor using the EXPORTING addition.
RAISE EXCEPTION <object_ref> statement can be used if an exception object is already defined. In this
case, an instance of the exception class is first created, which is then followed by the RAISE statement.
SETTING THE EXCEPTION TEXT
Every exception class has some text associated with it, which is usually the name of the exception class.
Whenever the exception is raised, the text is displayed. If the user wishes to display text other than the one
available by default, then instead of TEXTID, the corresponding constant (cx_invalid_planetype2) is passed
as an actual parameter to the constructor. The get_text( ) method is used to get the new defined text.

PROPAGATING CLASS-BASED EXCEPTIONS
The RAISING addition is specified in method definition to raise an exception from a method. In this
example, the RAISING addition is used in the constructor method. The RAISE EXCEPTION statement is
specified in the constructor method definition. The exception is then handled in the calling program.
PROPAGATING EXCEPTION OVER SEVERAL HIERARCHY-LEVEL
It is not mandatory that a class-based exception is handled by the calling method in which it is propagated.
As shown in this example, the constructor propagates an exception cx_exc which is raised by the method
get_tech_attr. When an exception is raised, the program flow jumps directly to the CATCH block in the
main program.
INTEGRATION OF STANDARD EXCEPTIONS IN THE RUNTIME SYSTEM

The way an exception is handled is determined by the superclass it is inherited from. In case of
CX_STATIC_CHECK, exception must be handled using the RAISING addition. Otherwise, a warning
message is displayed.
CX_DYNAMIC_CHECK, no warning message is displayed from syntax check. However, if they are not
handled during program execution, runtime error occurs.
CX_NO_CHECK, exception cannot be propagated explicitly using the RAISING addition.
HANDLING EXCEPTIONS: TRY-ENDTRY BLOCK
When the word RETRY is encountered in the source code, program control jumps back to the TRY
statement of the TRY–ENDTRY block.

RETRY STATEMENT
As shown in this example, after an exception is raised, the error situation is analyzed. When the system
encounters the RETRY statement, program control jumps to the TRY statement. Subsequently, the entire
code is executed again.
RESUME EXECUTION AFTER A RESUMABLE EXCEPTIONS
In order to resume normal processing after an exception is raised, the exception is first handled using the
CATCH BEFORE UNWIND statement. Subsequently, it is checked for its resumable property. If the property
set is true, then the RESUME statement is executed. However, raising and propagation of the exception are
handled by get_tech_attr method.

RE-RAISING AN EXISTING EXCEPTION OBJECT
When the CATCH statement is encountered, exception handling is done by the constructor. The CALL
METHOD statement in the constructor calls the method, get_tech_attr, which contains the RAISE
EXCEPTION statement as shown here. The exception object of the constructor is passed to the reference
variable of the CATCH statement in the main program. The exception object is called again in the main
program.
MAPPING EXCEPTION TO EACH OTHER
An exception can raise another exception. As seen in this example, the exception is handled in the
constructor using the get_tech_attr method, which raises another exception. Both these exception objects
are chained together using the public instance attribute – previous – of the exception classes.
SHARED OBJECT: USES

User-defined shared memory areas can be created to store data. These areas can be used to save catalog
information and shopping cart-related data.
MEMORY MODULE OF AN APPLICATION SERVER
With the introduction of shared objects, the concept of the shared memory is extended to the shared
objects memory. Initially, data exchange between the program and the memory in a user session used
import and export parameters. This new concept makes use of instances to store and retrieve information
in shared memory areas.
ACCESSING SHARED OBJECTS

One of the key characteristics of shared objects memory is faster data retrieval. As shown in the slide, two
different user sessions are trying to access the same memory area instance in shared objects memory.
Shared memory is a memory area on an application server that the ABAP programs running on the same
server can access.
PROPERTIES FOR SHARED OBJECTS
Shared objects have various advantages:

Cross program buffering of data is possible.
Simultaneous read accesses are supported.
Lock mechanism is used for access control.
Data is saved in the form of attributes of objects.
Memory bottlenecks which cause runtime errors must be resolved.
AREAS AND AREA INSTANCES
In shared memory, an area is created using transaction SHMA. It acts as a template for instances that can
be stored in that area. As shown in this slide, an area can have many area instances, with each instance
further divided into several area instance versions. Each area instance version is identified by a unique
version ID.
A pre req for saving an object in shared memory is that you need to define the class of the object with the
SHARED MEMORY ENABLED addition of the CLASS statement.
1 shma has many area ; 1 area has many area instances
CREATING AN AREA

In ABAP, shared memory area can be created using transaction SHMA. When you specify an area name, a
global final area class with the same name is created. The generated area class is a subclass of the area root
class.
EXAMPLE APPLICATION
Let us create a flight catalog class for flight bookings. For this, we need an area handle instance, area root
class, and a catalog class.

ACCESSING AREAS
In this slide, two different applications running in different user sessions are trying to access objects in the
same area. The prerequisites needed for the example application area are
an area,
a program which creates an area instance, and
a program to read data from the area.
AREA MANAGEMENT
To create an area, use the transaction code SHMA and specify the area name, as shown. The area name
must start with Y or Z. The SHMA transaction is used to create and manage areas.
MAINTAINING AREAS

When you are in the process of creating an area or managing an existing area, the screen shown here
appears. Area root class must be assigned to each area. An area instance version must contain at least one
instance of the area root class as its root object.
BEFORE CREATING AN AREA INSTANCE
When you create an area using the transaction SHMA, a global final class with the same name is
automatically created. In order to create a new area or access an existing area, a reference variable that is
typed with the generated area class is required. The area can be accessed using this reference as a handle.

CREATING AN AREA INSTANCE
When an area class is instantiated, an instance is created in the memory. Here, go_handle acts as a handle
for the area instance.
 Create area
 Create root
 Get handle
 Instantiate root
 Place object
GENERATING OBJECTS IN SHARED MEMORY
As shown here, the AREA HANDLE addition is used in the CREATE OBJECT statement to create an object in
the shared objects memory. Henceforth, the area handle is used to perform any operations on the area.

GENERATING OBJECTS IN SHARED MEMORY II
Here, the objects, go_root and go_catalog, are instantiated from the main program. The root object,
go_cat, can also be instantiated here.
SETTING THE ROOT OBJECT
You can make use of the set_root method to assign the root object to the root of the area handle. After this
assignment, any program can access the objects contained in this area by passing a reference to the area
instance.

RELEASING THE WRITE LOCK
Objects contained in an area can be read only when the write lock associated with the object instance is
released. The method, detach_commit, is used to release the write lock.
detach() releases read lock

detack_commit() releases write lock
ACCESSING AN EXISTING OBJECT IN SHARED MEMORY
The read program requires a handle of the area instance to access an already existing area application. The
method, attach_for_read, can be used to do so.

CANCELLING THE READ LOCK
Once the read operation is complete, the read lock associated with the area instance is released using the
detach method. However, the read lock is automatically released once the internal session is closed.
SETTING A READ LOCK ON THE ACTIVE VERSION
Once an area instance is created, the commit method is called internally. This activates the area instance
version and the read lock is automatically applied.

VERSION BEING SET UP
A new version of an area instance can be added if the Number of Versions (max 3) attribute is set for the
area. When the change lock is set for an area instance, a “version being set up” gets created and can
coexist along with all the previously existing ones.
WRITE COMPLETE - PREVIOUS VERSION IS OUTDATED
If the set-up of the new version is final when the area instance is in the read lock mode, then the newly
added version becomes the active version. The earlier existing version automatically becomes outdated.

NEW READ LOCKS FOR THE NEW ACTIVE VERSION
While the read locks for the outdated version still exist, the read locks for the active version are set. The
results of read operation may be ambiguous at this time.
NO MORE READ BLOCKS FOR OUTDATED VERSION: VERSION EXPIRED
Once the read lock is set up on an active version, the read lock associated with the outdated version is
removed and the version expires.
NEW READ LOCKS FOR ACTIVE VERSION

Any number of read locks can be set for the active version. However, an area instance can have only one
active version at a time.
FIELD SYMBOL
Field symbols are dereferenced pointers that have ‘symbolic’ access to a data object. Therefore, data object
can be accessed using the field symbol itself. Field symbols are declared using the keyword, FIELD-
SYMBOLS, as shown. Angular brackets (<>) are a part of the naming convention. The field symbols that are
defined using TYPE or LIKE addition statically refer to a particular type. They can also be generically defined
using TYPE ANY. You can assign a data object to a field symbol using the ASSIGN statement. As shown in the
slide, the field symbol <fs_int> after assignment contains the value of gv_int. When the UNASSIGN
statement is used, the field symbols do not indicate any data object.
EXAMPLE: GENERIC FIELD SYMBOL IN DYNAMIC SELECT
If a field symbol is typed generically, it can be assigned to any data object irrespective of the type of data
object. In this example,<fs_tab> is a field symbol of type internal table. Depending on the parameter
supplied to the variable, lv_table_name, <fs_tab> should hold values from SCARR or SBOOK table. The
SELECT statement is used to fill the internal table using <fs_tab>.

TYPE CASTING FOR FIELD SYMBOLS
A field symbol assigned to a data object can be used to refer to a different data object using the CASTING
addition in the ASSIGN statement. The data object then behaves as if it implicitly had the data type of the
field symbol. However, if the CASTING TYPE addition is used in the ASSIGN statement, then the data object
behaves as if it is explicitly specified with the type of the field symbol. After the first ASSIGN statement, the
field symbol <fs> will hold current date as shown here.
DYNAMIC ACCESS TO DATA OBJECTS
As shown in the slide, any data object, including structure components, can be assigned to a field symbol.
After the release of version 6.1, even static and instance attributes can be assigned to a field symbol.

DYNAMIC ACCESS TO OBJECT ATTRIBUTE AND CLASS ATTRIBUTE
Like data objects or structure components, dynamic access to the static attributes of a class or an instance
of a class, can be made using field symbols, as shown here. The attribute name can be specified either in
uppercase or lowercase. Even a class name can be mentioned either ways.
DYNAMIC ACCESS TO STRUCTURE COMPONENTS
We already know that structure components can be assigned to a field symbol. Using the ASSIGN
statement, it is possible to access a particular component of a structure. As shown here, the syntax used for
this type of assignment is ASSIGN COMPONENT variable_name OF STRUCTURE. The component of a
structure can also be accessed using its position.

FULL PROCESSING OF ANY NON-NESTED, FLAT STRUCTURE
The components of a structure can be accessed using its field symbols. Let us understand this with the
example shown in the slide. The variable, is_struct, is an elementary structure declared as TYPE any. The
system variable, sy-index, is used to assign the components of the structure to the field symbol, ls_comp.
The condition sy-subrc <> 0 (not equal to zero) checks the ASSIGN statement. If the condition is true,
control exits the loop. Otherwise, the index value is displayed using the WRITE statement.
DATA REFERENCES
The reference type for a reference variable is defined using the TYPE REF TO addition in the TYPES
statement. It can be either fully specified or generic. The DATA statement is used when you wish to assign a
data object to a reference variable that is already defined with a specified type.
Let us understand the two statements with an example.
The reference variable gty_ref_int is of the type, Integer. The data object gr_int is also of the same type, as
it refers to get_ref_int. The data object GV_INT holds a value 15.
By using the statement, GET REFERENCE OF, gr_int can point to gv_int. The dereferencing operator ( → *) is
used to directly access the content of the data object.

VALIDATING REFERENCE VARIABLE: LOGICAL
The statement, ref IS [NOT] BOUND, is used to check if a reference variable contains a valid reference. In
the above statement, ref can be a data object or reference variable. If an object reference is involved, the
logical expression returns “true” as the value. Otherwise, the value is “false.”
GENERIC DATA REFERENCES
Reference variables that are generic can be created using TYPE REF TO DATA assignment. It is not possible
to directly dereference a generically typed reference variable. Such reference variables can be used during
dynamic internal table call and for dynamic creation of data objects.
CAST ASSIGNMENT FOR DATA REFERENCES
When values are assigned between two reference variables of different types, it can be defined as cast
assignment. As shown in the slide, lr_int and lr_date are fully typed reference variables; whereas, lr_gen is
generically typed. When a generically typed reference variable is assigned to a fully typed reference
variable, it is known as down cast. However, the opposite assignment is called up cast.
As seen here, down cast in the first case is type compatible. Since the assignment is not type compatible in
the second case, execution of the program will lead to runtime error.

DEFERENCING GENERICALLY TYPED DATA
You can dereference generically typed reference variables only by using the ASSIGN statement. As shown in
the slide, lr_data is assigned to the field symbol <fs> using the ASSIGN statement. After assignment, the
field symbol points to the same data object as the data reference. Value of the data object reference can be
obtained using the field symbol.
OPTIONS FOR CREATING DATA OBJECT AT RUNTIME
A data object pointing to a general data reference variable can be created dynamically using the CREATE
DATA statement. As shown in the slide, when lr_spfli is assigned to lr_data, an up-cast is explicitly defined.
However, the TYPE addition in a CREATE DATA statement implicitly generates an up-cast assignment. Using
the LIKE addition in a CREATE DATA statement, references to an already existing data object can be
specified. References to a character-type data object can be obtained by specifying the name of the object
in parentheses in the CREATE DATA statement as shown here.

ACCESS TO DYNAMICALLY GENERATED DATA
As shown in the slide, CREATE DATA lr_data creates a data object whose type is unknown. Therefore, in
case of dynamically created data objects, reference variable should be generic in nature. Using the ASSIGN
statement, the field symbol <fs> points to the content of the data object, lr_data.
A field symbol is required in this case because
Only the ASSIGN statement can be used to dereference a reference variable.
Generically typed field symbols can be used anywhere.
EXAMPLE: DYNAMICALLY GENERATED INTERNAL TABLE AND DYNAMIC SELECT
An internal table can be created dynamically using the TYPE TABLE OF addition in the CREATE DATA
statement. The line type of the internal table is defined by specifying the name of the table in parentheses,
as shown in the slide. In order to display the values, you can use a generically typed field symbol in the
ASSIGN statement.

CLASS HIERARCHY OF RTTI DESCRIPTION CLASSES
ABAP defines a hierarchical list of global classes that can be used. An instance of the class describes all the
properties associated with the class which can be called using the public attributes and methods. Each class
describes a specific category of types, for example CL_ABAP_TABLEDESCR is used to describe table types.
The list is a combination of abstract classes used for inheritance, as well as those classes which can be
instantiated.
RTTI CLASSES: INSTATIATION POSSIBLE
Only six of the ten RTTI classes can be instantiated and used to describe specific types. All the other classes
are abstract. They cannot be instantiated. This is because they are used to centrally define the attributes
and methods in several other classes (and implement them if necessary). The METHODS attribute, which
contains a list of the methods, is not defined in class CL_ABAP_CLASSDESCR. It is defined in class
CL_ABAP_OBJECTDESCR, as it is also needed in the same form in class CL_ABAP_INTFDESCR.

RTTI: METHOD AND ATTRIBUTES OF THE ROOT CLASS
CL_ABAP_TYPEDESCR is the root class in the hierarchy of RTTI description classes. CREATE OBJECT cannot
be used to instantiate class directly. As shown in the slide, you need to call the static methods,
Describe_By_name and Describe_By_data of class CL_ABAP_TYPEDESCR to create an object reference.
DESCRIBING A TYPE BASED ON ITS NAME
In order to access the attributes and methods of the respective type, you need to suitably cast the subclass
with local or global data type. It is also possible to cast interfaces to the data objects.

CASING A SUITABLE REFERENCE FOR A TYPE DESCRIPTION OBJECT
If the user has no idea about the RTTI class that was instantiated, then the public instance attribute, kind,
can be used. However, a downcast to a suitable subclass must be done.
DESCRIBING TYPES BASED ON DATA OBJECTS AND REFERENCES
As shown in the slide, static methods can be used to describe different reference types. The method,
describe_by_data, returns description about the type of current parameter in the first example whereas,
the same method returns type description of the reference variable in the second example. Similarly, the
method, describe_by_object_ref, gives the type description of the object that is pointed to by the reference
variable.

ANALYSIS OF AN ELEMENTARY DATA TYPE
All the properties of an elementary data type can be accessed using the RTTI class, CL_ABAP_ELEMDESCR.
Technical properties, such as type, length, and decimal places are defined in the respective public
attributes. The public attribute, Type_kind, stores constants, which must be evaluated against the
corresponding constant for the root class. The method, Get_DDIC_field, returns the structure with
dictionary information for the data element.
ANALYSIS OF THE TYPE OF A REFERENCE VARIABLE
The RTTI class, CL_ABAP_REFDESCR, can be used to obtain the type of a reference variable. The inherited
public attribute differentiates between data references and object references. The method,
get_referenced_type, is used to describe the details of the static type of the reference variable.

ANALYSIS OF A STRUCTURE TYPE
The class, CL_ABAP_STRUCTDESCR, is used to determine the structure of the reference variable at runtime.
It contains public attributes, such as Length, Struct_Kind, Has_include, and Components. The attribute,
struct_kind, determines whether the structure is nested or elementary. Similarly, the Components attribute
is an internal table, which contains the names of all components and their technical properties. The
method, Get_DDIC_field_list, describes the semantic information of all the components.
NAVIGATION FROM STRUCTURE TYPE TO COMPONENT TYPES
As shown in the slide, the method, get_componenet_type, returns the description object for the specified
component. The type of reference variable, lo_elem, is identified by the class cl_abap_elemdescr. Using the
variable, ls_comp, in the LOOP AT statement, description objects for all the components of the structure
can be obtained.

ANALYSIS OF A TABLE TYPE
The RTTI class, CL_ABAP_TABLEDESCR, is used to determine the table type of the reference variable at
runtime. Its public attributes contain information, such as whether the internal table is standard or sorted;
and whether it has a unique key. The method, get_table_line_type, can be used to get the line type of the
description object.
ANALYSIS OF AN OBJECT TYPE
The public attributes of class CL_ABAP_CLASSDESCR contain information about attributes, methods, and
interfaces of the described class. The attribute, Class_kind, determines if the class is declared as abstract or
final. The Methods attribute is defined as a nested internal table, which contains parameters and
exceptions for the respective method.

OVERVIEW DIAGRAM: CHANGING THE SAP STANDARD
This slide gives an overview of the various functionalities provided by SAP to its users for modifying the
standard business applications based on their individual requirements. The functionalities can be broadly
classified as Personalization, Enhancement, and Modification.
CHANGE LEVELS.
You can modify the standard ERP system to meet specific requirements through any of these methods:
Customizing: You can use it to implement specific business processes with the help of an implementation
guide.
Personalization: You can adopt it to set menu specifications or fields as per user requirements. This
simplifies and accelerates the whole business process.
Modification: You can follow it to bring changes to the standard SAP Repository objects in the customer
namespace without creating a new object.
Enhancement: You can use it to create new objects that refer to already existing repository objects.
Customer Development: You can follow this method to create new SAP Repository objects that are
unique for an individual customer. This may or may not be SAP objects.

PROCEDURE FOR CHANGING THE FUNCTIONALITY
The customer can use ABAP Workbench tools for meeting their specific customizing and personalization
objectives. If these requirements are not met, you can make use of customer development or
Complementary Software Product (or CSP) solution. If this is also insufficient, the customer can consider
using similar standard functionalities in the form of enhancement. Finally, modification can be used if all
other procedures seem inadequate.
CUSTOMIZING
You can configure an SAP system according to your individual requirements with the help of these
implementing tools:
R/3 reference model
Implementation Guide
List of customizing activities

PERSONALIZATION
You can use personalization to simplify and accelerate the whole business process, as screen transaction or
menu sequences can be specified accordingly. Global attributes can be used to specify default values for
the specific screen fields using the variant transactions and SET or GET parameters. You can specify user-
dependent table or client-dependent table control settings for a particular transaction. The menu
sequences can be adjusted. Role-based menus, favourites, and shortcuts on the desktop can be created.
CHANGE LEVEL USING ABAP WORKBENCH
Various customer programs are available for making changes to the standard SAP system. These can be
classified as Modification, Extension, or Customer Development.

TABLE ENHANCEMENT
You can enhance a table defined in ABAP dictionary using the Append structure or Customizing includes
(CI_Includes). The name of the fields in an append structure or Customizing include should follow proper
naming conventions. After saving, these changes are registered in the underlying database.
TABLE ENHANCEMENT: SAP AND THE CUSTOMER
Standard tables can be enhanced using the table enhancements, such as the Append structure and
Customizing includes (CI_Includes). An append structure can be used only once for a table; whereas a
Customizing include can be used for many tables. Table enhancements using append structures need not
be planned by SAP developers; however, these have to be planned while using Customizing includes.

PROGRAM ENHANCEMENT: HOW THEY WORK
A program enhancement is always used to call an object in the customer namespace. A program
enhancement can be done through
user exits, which are called using subroutines;
customer exits, which are called through function modules;
business transaction events, which are called through function modules; and
business add-ins, which are called by the method of a class.
PROGRAM ENHANCEMENT: SAP AND CUSTOMER
By using program enhancements, you can add additional program logic to a standard SAP application
program. SAP currently provides the techniques as shown here.
You can execute User Exit with the help of subroutine. Similarly, Customer exit and Business Transaction
Event are executed using the function modules. You can also implement Business Add-In using method.

MENU ENHANCEMENT: SAP AND CUSTOMER
The user-defined menu options can be added to a standard SAP menu using menu enhancements. This can
be achieved using Customer Exits or Business Add-Ins. As shown here, a menu item, Customer Function
(Customer Fcn), is added. The added menu items appear as part of the GUI interface.
SCREEN ENHANCEMENTS
Screen exits can be used to display additional objects in an SAP application program screen. The screen
exits can be realized using the Customer Exits or Business Add-Ins. In order to create a screen exit, you
need to
define the subscreen area;
write the corresponding flow logic;
provide the framework for data transport;
call the screen exit in an implementation; and
maintain documentation.

MODIFICATIONS
When you make changes to an object delivered by SAP, it is known as modification. As shown in this
example, any changes or addition done to the code of a program is referred to as modification.
ENHANCEMENT TO THE ABAP DICTIONARY: OVERVIEW DIAGRAM
The changes made to the standard dictionary objects, such as tables or data elements are considered as
enhancements.

TABLE ENHANCEMENT: OVERVIEW
Tables and structures can be enhanced with the help of these methods:
Append structures
Customizing includes
The user can create an append structure for an SAP table. Multiple append structures can be used for a
specific table. The added fields appear to be an implicit part of the table structure.
Customizing includes are already integrated into SAP tables. The user can add fields to multiple tables or
structures. These can also contain source codes or screen exits.
APPEND STRUCTURES
You can use append structures to add fields to a table without actually modifying the table itself. An
append structure can only be assigned to a single table. However, a table may have several append
structures attached to it. The fields of an append structure should follow proper naming convention. After
an append structure is added, the table would finally look like the one shown here.
Append structures may only be assigned to a single table. A table may have several append structures
attached to it.
You cannot create append structures for pool and cluster tables. Cannot use append structures for tables
containing long field (LCHR or LRAW)

APPEND STRUCTURES AT UPGRADE
Append structures are created in the customer namespace. During an upgrade, when new versions of a
standard table are imported, this naming convention helps them from being overwritten. On activation, the
fields of the active append structures are appended to the new standard tables.
CUSTOMIZING INCLUDES
Unlike append structures, Customizing includes can be added to more than one table. The naming
convention for customizing includes begins with ’CI_’, followed by the name of the include. After inserting
Customizing includes, the table appears as shown here. The SAP standard does not provide any code for
customizing includes
TEXT ENHANCEMENTS: OVERVIEW

F1 help on any field provides documentation for that particular field. The documentation shown to the
customer is provided by SAP itself. SAP also provides its customers the freedom to load customer-specific
documentation for a field or data element using the text enhancements.
OVERWRITING SAP FIELD LABELS (1)
The application programmers define field labels of different lengths with a brief description of each data
element. These short descriptions can be overwritten by customer-defined texts.
OVERWRITING SAP FIELD LABELS (2)
You can call transaction CMOD, also known as project management to edit text enhancements. For this,
you need to choose Goto → Global Enhancements → Keywords → Change. Subsequently, a dialog box
opens where you need to specify the required text for overwriting SAP data elements.

PREREQUISITES FOR OVERWRITING AN SAP FIELD LABEL
If the field label for a screen field is not explicitly defined, field labels can be overwritten. In this case, the
dictionary-modified attribute of the screen field has the value ‘F’.
OVERWRITTEN TEXTS IN UPGRADES
The customer-defined field labels need to be restored whenever SAP changes existing labels, or when there
is a release upgrade. In such a situation, restoring the customer-defined labels is usually recommended.
This can be achieved using the menu option, Restore customer.

RESTORING SAP FIELD LABELS
You can use the Restore SAP option to get the original field label for a screen field. A program running in
the background checks all the edited data elements and restores their original field labels.
ENHANCED DOCUMENTATION FOR DATA ELEMENTS
When a user requests for data element documentation using ‘F1 help’, the developer has an option
wherein the customer-defined documentation can be displayed along with the SAP documentation. The
customer-defined documentation can be deleted if the original one is required.
When you enhance, you can copy the SAP documentation as well as your own.

CREATING CUSTOMER DOCUMENTATION
You can follow the specified menu path shown here to create customer documentation associated with a
screen field. The described menu path opens a dialog box with two options, Original text and Template. If
you select ‘Original text,’ you can add the customer-specific documentation to the SAP documentation.
However, if you select ‘Template,’ you can create customer-specific text without incorporating the SAP
documentation.
ENHANCEMENT USING CUSTOMER EXITS: OVERVIEW DIAGRAM
You can categorize customer exits under Enhancements as shown here.

CUSTOMER EXITS: OVERVIEW
This slide shows an overview of Enhancement Management.
SAP APPLICATION ENHANCEMENT
Customers can enhance applications by defining their own functionality. Customer exits are preplanned by
SAP and are usually a combination of several components. Initially, when application enhancements are
delivered they are inactive. They can be modified and activated by customers as per their requirements.
 Each enhancement provides you with a set of preplanned, precisely defined

functions
 The interface between SAP and customer function is clearly defined
 Customers do not need in depth knowledge of how to implement SAP applications
 Customer do not need to adjust enhancements during an upgrade
 CUSTOMER ENHANCEMENT PROJECT

Application programmer can create enhancements using program exits, menu exits, and screen exits or any
combination of these. SAP provides a standard transaction code, SMOD, for managing the enhancements.
This transaction code also gives a list of available enhancements. On the other hand, you need transaction
CMOD for creating an enhancement project.
ENHANCEMENTS AND ENHACEMENT
Enhancement components consist of Program exits, menu exits, and screen exits. An enhancement is a
combination of different components, as shown here. An enhancement project is a combination of
different enhancements. As a customer, you must edit all enhancements that are activated simultaneously
in an enhancement project.
THE SAP ENHANCEMENT CREATION PROCEDURE

Customer exits define program exits, menu exits, and screen exits. An enhancement created using a
combination of these can be termed as an SAP enhancement. The developer must document
enhancements properly, so that in future, customers can implement these enhancements without
analysing program source code or screen source code.
PROCEDURES AT THE CUSTOMER'S PREMISES
As a customer, you first need to create an enhancement project and then select the required SAP
enhancements. The next step is to edit the individual components using the project management functions.
The customer must also document enhancements. Finally, as soon as the enhancement project is active, all
the components of the project get activated automatically.

CREATING A CUSTOMER ENHANCEMENT PROJECT
You can call transaction CMOD to create an enhancement project. Next, you need to specify a project name
by which the system can identify the enhancement. Finally, you need to select the Attributes radio button
to provide a short description for the enhancement project.
ASSIGNING SAP ENHANCEMENT TO CUSTOMER PROJECTS
An existing SAP enhancement can be assigned to a customer enhancement project using transaction
CMOD. In the initial screen of CMOD, select Enhancement assignment radio button and click Change, as
shown here. The resultant dialog box shows a list of available enhancements along with their description.
Whenever you create an enhancement project, you have to assign it to a change request. Each of the
related repository objects, such as programs, subscreens should be assigned to the same change request.

EDITING COMPONENTS
You can edit the components of an enhancement project in the initial screen of CMOD. For this, select
Components and click Change. If the component you are editing is a function module, then the Function
Builder screen appears. However, in case of a menu item, a dialog box with menu options appears. If a
subscreen is edited, then the control is transferred to the Screen Painter screen.
ACTIVITING ENHANCEMENT PROJECTS
To activate an enhancement project, click the Activate button. After successful activation, all the
components are automatically active, and the project status appears active.
TRANSPORTING PROJECTS

When a user creates an enhancement project, a transport request is assigned to it. All the components
should also be assigned to the same change request. This facilitates smooth transport of the entire
enhancement simultaneously using a single change request.
PROGRAM EXIT OVERVIEW
A customer can implement additional logic in applications by using Program Exit. It is executed using a
function module. A programmer needs to clearly define the interface of the function module for data
transfer and specify where it is used. The customer defines the source code for the function module. The
additional source code is implemented when the enhancement project is active.
PROGRAM EXITS: ARCITECHTURE
A program exit is defined in an application program using a function module. The corresponding function
module is called using the statement, CALL CUSTOMER-FUNCTION. When the function module is called, the
function group is loaded in the user’s internal session. Program exits have no effect until the enhancement
project is activated.

PROGRAM EXITS: SYNTAX
You can call the function module ‘001’ using the statement, CALL CUSTOMER-FUNCTION. Here, ‘001’
represents a three-digit code. Function modules are present in the function groups which have names
beginning with ‘X’. The name of a function module begins with the prefix EXIT, followed by the function
module name, and a three-digit code. The three parts of the name are separated by an underscore.
Customer-specific code is defined in the INCLUDE present in the function module.
EXIT_prg_nnn
FINDING PROGRAM EXITS
For finding program exits available for an application program, you need to
follow the menu path, System → Status;
double click the program name in the dialog box;
search for the string, CALL CUSTOMER;
call transaction CMOD;
choose Utilities → SAP enhancements; and
search for the component name EXIT_<program_name>
The name of the required enhancement can be found using the application hierarchy in Repository
Information System or IMG.

EDITING PROGRAM EXITS
You need transaction CMOD to edit the function module exit. Select the Components radio button and click
Change. Subsequently, the system shows the corresponding INCLUDE program. Finally, double-click the
INCLUDE statement to modify the source code.
STRUCTURE OF A FUNCTION GROUP
When a program calls a function module, the associated function group is loaded in the program context.
Global data of the program is stored in the TOP include. All function modules are stored in includes. As
shown here, the include with suffix, UXX, stores all the function modules sequentially. The program also
contains a subroutine.

STRUCTURE OF AN EXIT FUNCTION GROUP
The name of an exit function group defined for enhancements begins with LX or ZX. Here, ZXAAATOP
contains global customer data; whereas, ZXAAAU01 and ZXAAAU02 contain customer source code. You can
only edit the include stored in customer namespace.
Replace abcd with xaa
You cannot add further function modules to a function group
A function group consist of a main program of type function group and includes. The system assigns unique
names to includes for the different objects. Some of the include names are simply proposals and some
cannot be changed. The TOP include stores global data and is generated automatically when the functional
group is created.
GLOBAL DATA OF AN EXIT FUNCTION GROUP
In this example, the include program, LXAAATOP, contains FUNCTION-POOL that should not change. The
include LXaaaTAP contains global SAP application data. However, customer-specific global data is present in
include ZXaaaTOP.

CUSTOMER-SPECIFIC PROCESSING BLOCKS
The function module, LXAAAU01, contains the INCLUDE ZXaaaU01. Therefore, this include cannot contain
any events or subroutines. Any data declarations done in this include are valid only in its context. The
INCLUDE LXAAAF00 is created to specify source text.
OTHER SAP OBJECTS IN AN EXIT FUNCTION GROUP
Includes also contain various subobjects, such as subroutines, PBO modules, PAI modules, and ABAP
events. As depicted here,
LXAAAF01 contains subroutines delivered by SAP.
LXAAAE01 contains the events belonging to the X function group.
LXAAAO01 contains PBO modules for screens to be delivered.
LXAAAI01 contains the corresponding PAI modules.

CUSTOMER OBJECTS IN AN EXIT FUNCTION GROUP
All subobjects are created as includes. These are included in a function group using another INCLUDE
program, as shown here. The naming convention followed for different subobjects is
ZXAAAF01 for subroutines;
ZXAAAO01 for PBO modules;
ZXAAAI01 for PAI modules; and
ZXAAAE01 for events.
CUSTOMER SCREENS
The customer-defined screens in enhancements can be called using the CALL SCREEN statement. Here, the
INCLUDE, ZXaaaU01, contains the CALL SCREEN statement. However, in this case, two separate includes,
ZXAAAO01 and ZXAAAI01, need to be created for both PBO and PAI modules, respectively.

SUMMARY: PROGRAM EXITS
A customer can enhance SAP applications by adding source code at predefined points. As shown here, CALL
CUSTOMER-FUNCTION calls the EXIT function module. The includes used in the process can call screens by
defining their GUI and processing logic. The INCLUDE, ZXaaaU01, calls screen 9000, which in-turn calls the
screen 9100. The text elements and GUI for the screens are defined in the INCLUDE.
MENU EXITS OVERVIEW
You can use menu exits to add menu options in standard SAP menus. There are certain menu options that
are reserved by SAP in the user GUI interface. As a result, the user can add functions to those menu
options. In this slide, Customer Fcn menu item is added to Menu 2. The user can also define the menu text.
The user menus are visible only on activation.

MENU EXIT REQUIREMENTS
In menu exits, the function code for menu items must begin with ‘+.’ On activation, the added menu
options are visible in the menus.
MENU EXITS AND PROGRAM EXITS
When the menu item is selected, the corresponding source code is implemented. The CALL CUSTOMER-
FUNCTION statement calls the customer functions for the menu.

NAMING AND EDITING MENU EXITS
You can edit menu exits by using transaction CMOD. When you click Change, the system displays a dialog
box where you can give a short description for additional menu items.
SCREEN EXITS OVERVIEW
By using screen exits, you can add additional screen fields to an existing screen. You can execute a screen
exit through a reserved part on the main screen.

SUBSCREEN (GENERAL)
A subscreen is a reserved rectangular area on a screen. As shown in this example, the subscreens 200 and
300 contain different fields. These subscreen items are visible only after activation.
CALLING A NORMAL SUBSCREEN
In screen exits, a subscreen must be called within the PBO and PAI of the main screen. The syntax for
subscreen call in PBO is CALL SUBSCREEN ‘abcd’ INCLUDING sy-cprog ‘1234’. Here, abcd is the subscreen
name, sy-cprog is the system variable, which returns the name of the calling program, and ‘1234’ is the
screen number. The syntax call in PAI is CALL SUBSCREEN abcd.

DEFINING SCREEN EXITS
Multiple subscreen areas can be added to the main screen in a screen exit. Customer-specific fields are
inserted when the system encounters the CALL CUSTOMER-SUBSCREEN statement in the PBO of the main
screen.
CALLING CUSTOMER SUBSCREEN
For each subscreen, PAI and PBO events are processed as if the subscreen is a part of the normal screen.
When the CALL CUSTOMER-SUBSCREEN statement occurs in PBO, the subscreen area is called in the main
screen. The statement, CALL CUSTOMER-SUBSCREEN, in PAI of the main screen triggers the PAI of the
subscreen.

EXPORTING DATA TO SUBSCREENS
The X function group acts as a container for screens. It cannot access the global data declared in an
application program. Therefore, program exits are used in order to transfer data from program to the
subscreen.
TRANSPORTING DATA FROM SUBSCREENS
Global data of the X function group is unavailable to the program. However, data transfer between the
program and the subscreen is mutual. It is for this reason that program exits are used to transfer data from
program to subscreen.

NAMING AND EDITING SCREEN EXITS
This slide illustrates how to name and edit screen exits. For this, click transaction CMOD. You need to select
Components and click Change, as shown here. The system displays the screen exit along with a list of
associated program exits. You can then navigate to Screen Painter to modify the UI elements in the screen
exit.
EDITING SUBSCREENS
When a user wishes to edit a screen exit, the system looks for subscreens associated with the screen exit. If
a subscreen is present, the user can navigate to Screen Painter. However, if a subscreen does not exist, the
system proposes the user to create one. While creating subscreens, the screen type should be specified as
Subscreen.

BUSSINESS ADD INS: OVERVIEW DIAGRAM
As an application programmer, you can use business add-ins to create enhancements in customer
namespace. All enhancement types, such as program exit, menu exit, and screen exit, can be created using
BAdIs. In fact, the key feature of a BAdI is its reusability.
BUSSINESS ADD INS: ADVANTAGES
Earlier enhancement techniques had some serious limitations:

Customer exits in these enhancements did not allow multiple uses.
No enhancements were available at program, screen, or menu level.
Administration level enhancements for business transaction events were insufficient.
New enhancement techniques had to address these deficiencies. BAdIs allow you to create all
enhancement types. The key feature of a BAdI being its reusability, you stand to reap certain advantages:
Multiple usage or reusability

Possibility of all enhancement types, such as program, menu, and screen exits
Administration level enhancements
Use of the latest technology
SOFTWARE DELIVERY PROCESS
Previously enhancements were delivered directly to the customer. However, with the introduction of
BAdIs, the implementation is a three-step process. This is because, for a BAdI to be executed, the
implementation class and the service class need to be identified in the system.
BUSSINESS ADD-INS: ARCHITECTURE
A prerequisite for creating BAdIs is the availability of an enhancement option in an SAP application
program. Additionally, there must be a BAdI class and an interface that implements it. The interface is
implemented at the customer site.

BUSSINESS ADD-INS: COMPONENTS
Each BAdI includes a range of enhancement components, such as a program exit, menu exit, or a screen
exit. When a BAdI is created, a BAdI interface and a generated class that implements the interface is
automatically created. The generated class performs various tasks, such as BUSSINESS ADD INS: OVERVIEW
DIAGRAM
As an application programmer, you can use business add-ins to create enhancements in customer
namespace. All enhancement types, such as program exit, menu exit, and screen exit, can be created using
BAdIs. In fact, the key feature of a BAdI is its reusability.

BUSSINESS ADD INS: ADVANTAGES
Earlier enhancement techniques had some serious limitations:

Customer exits in these enhancements did not allow multiple uses.
No enhancements were available at program, screen, or menu level.
Administration level enhancements for business transaction events were insufficient.
New enhancement techniques had to address these deficiencies. BAdIs allow you to create all
enhancement types. The key feature of a BAdI being its reusability, you stand to reap certain advantages:
Multiple usage or reusability
Possibility of all enhancement types, such as program, menu, and screen exits
Administration level enhancements
Use of the latest technology
SOFTWARE DELIVERY PROCESS
Previously enhancements were delivered directly to the customer. However, with the introduction of
BAdIs, the implementation is a three-step process. This is because, for a BAdI to be executed, the
implementation class and the service class need to be identified in the system.
BUSSINESS ADD-INS: ARCHITECTURE
A prerequisite for creating BAdIs is the availability of an enhancement option in an SAP application
program. Additionally, there must be a BAdI class and an interface that implements it. The interface is
implemented at the customer site.
BUSSINESS ADD-INS: COMPONENTS
Each BAdI includes a range of enhancement components, such as a program exit, menu exit, or a screen
exit. When a BAdI is created, a BAdI interface and a generated class that implements the interface is
automatically created. The generated class performs various tasks, such as filtering and control. The first
task is performed so that only the relevant implementations are called. Similarly, the second task is carried
out to call the active implementations.

BUSSINESS ADD-INS: FLOW OF A PROGRAM EXIT
This slide illustrates the process flow of a program that calls a BAdI. When a Business Add-In is defined, the
system automatically generates a BAdI class that implements the interface. Then the interface method of
the BAdI class is called. The BAdI class searches for all of the active implementations of the Business Add-In
and calls the implemented methods.
BUSSINESS ADD-INS: CALL SYNTAX IN SAP PROGRAM
You need to define a reference variable that refers to the BAdI interface to call a Business Add-In. An object
reference is created using the CALL METHOD statement which creates an instance of the generated BAdI
class. By using this object reference, you can call the required methods.

FINDING A BUSSINESS ADD-IN
You can search a Business Add-In using the menu path: System → Status → program name (double-click)
→ Search for CL_EXITHANDLER String.
You can also define Business Add-In by forward navigation. The definition contains documentation and a
guide for Business Add-In implementation. You can use the Repository Information System to search for a
BAdI.
IMPLEMENTING BUSSINESS ADD-INS: INTRODUCTION
The transaction code SE19 is used to implement a Business Add-In. You can view the screen shown here by
using this transaction. Then you need to enter a name for BAdI and click Create.

IMPLEMENTING BUSSINESS ADD-INS: METHODS
In order to implement Business Add-Ins, you need to specify the name of the implementing class. However,
the class name should follow proper naming conventions. Then, you can double-click the method name to
define its implementation part in the class builder. Similarly, you need to click the signature button to
display the methods interface.
IMPLEMENTING BUSSINESS ADD-INS: PRIVATE METHODS
You can use the CALL METHOD statement to create private methods in the interface class. The private
method can be called from the interface method.

IMPLEMENTING BADIs: ACTIVITING IMPLEMENTATIONS
You can click the Activate icon to activate the implementations of a Business Add-In. Whenever the BAdIs
are called; the methods in the implementation are executed. However, if the user deactivates the
implementation, the methods will no longer be called.
BUSSINESS ADD-INS: MENU EXITS (OVERVIEW)
Menu enhancements can be created using Business Add-Ins. As a user, you can add Customer Fcn function
in the menu options. However, the menu enhancements must be pre-planned and should be implemented
inside the BAdI implementation.

BUSSINESS ADD-INS: MENU EXITS (SAP PREPARATION)
As shown here, function codes of menu enhancements begin with a plus sign ’+’. The added menu item is
displayed only if the implementation is active.
BUSSINESS ADD-INS: MENU EXITS (FUNCTION CODE PROCESSING)

The corresponding code for the menu option is declared inside the CASE statement. However, the function
code should begin with the plus sign ‘+’.
BUSSINESS ADD-INS: MENU EXITS (RESTRICTIONS)
The function codes specified in a menu exit for a BAdI are available for single use. You can avoid conflicts
between different BAdI implementations by ensuring they are neither filter-dependent nor reusable.
EXTENDIBLE FILTER TYPES: PREREQUISITES
The filter type property of a BAdI has an extendible attribute. This attribute can be utilized if the domain of
extendible filter type has these properties:
The domain must be linked to a cross-client value table. The value table should have exactly one key
field, which has the data element of the filter type as its field type.
The domain must have a text table with two key fields. One key field has the filter type as its field type,
and the second key field has language as its field type.

The delivery class of both tables must be E or S.
DEFAULT IMPLEMENTATION
If an active implementation is present, it is executed. However, if an active implementation is unavailable a

default implementation is executed. The default implementation is created by the enhancement provider.
COMPARISON WITH OTHER ENHANCEMENT TECHNIQUES
Business Add-Ins are an extension of conventional enhancement techniques. BAdIs are both filter specific
and reusable as compared to customer exits. It is possible to append fields on screens with restrictions
using BAdIs.

NAMING CONVENTIONS (BADI DEFINITION)
As a user, you must comply with these naming conventions for BAdI definitions:
The name of a BAdI must begin with <badi> or z<badi>
The name of the BAdI interface must begin with IF or ZIF as shown here.
Any name can be specified for a BAdI method.
The name of a BAdI adapter class must begin with CL or ZCL.
NAMING CONVENTIONS (BADI IMPLEMENTATIONS)
You must comply with these naming conventions for BAdI implementations:
The name of a BAdI implementation must begin with <impl> or z<impl>

The name of the BAdI interface must begin with IF or ZIF as shown.
The method defined in BAdI definition is implemented.
The name of a BAdI implementing class must begin with CL_IM OR ZCL_IM. . The first task is performed
so that only the relevant implementations are called. Similarly, the second task is carried out to call the
active implementations.
BUSSINESS ADD-INS: FLOW OF A PROGRAM EXIT
This slide illustrates the process flow of a program that calls a BAdI. When a Business Add-In is defined, the
system automatically generates a BAdI class that implements the interface. Then the interface method of
the BAdI class is called. The BAdI class searches for all of the active implementations of the Business Add-In
and calls the implemented methods.
BUSSINESS ADD-INS: CALL SYNTAX IN SAP PROGRAM
You need to define a reference variable that refers to the BAdI interface to call a Business Add-In. An object
reference is created using the CALL METHOD statement which creates an instance of the generated BAdI
class. By using this object reference, you can call the required methods.

FINDING A BUSSINESS ADD-IN
You can search a Business Add-In using the menu path: System → Status → program name (double-click)
→ Search for CL_EXITHANDLER String.
You can also define Business Add-In by forward navigation. The definition contains documentation and a
guide for Business Add-In implementation. You can use the Repository Information System to search for a
BAdI.
IMPLEMENTING BUSSINESS ADD-INS: INTRODUCTION
The transaction code SE19 is used to implement a Business Add-In. You can view the screen shown here by
using this transaction. Then you need to enter a name for BAdI and click Create.

IMPLEMENTING BUSSINESS ADD-INS: METHODS
In order to implement Business Add-Ins, you need to specify the name of the implementing class. However,
the class name should follow proper naming conventions. Then, you can double-click the method name to
define its implementation part in the class builder. Similarly, you need to click the signature button to
display the methods interface.
IMPLEMENTING BUSSINESS ADD-INS: PRIVATE METHODS
You can use the CALL METHOD statement to create private methods in the interface class. The private
method can be called from the interface method.

IMPLEMENTING BADIs: ACTIVITING IMPLEMENTATIONS
You can click the Activate icon to activate the implementations of a Business Add-In. Whenever the BAdIs
are called; the methods in the implementation are executed. However, if the user deactivates the
implementation, the methods will no longer be called.
BUSSINESS ADD-INS: MENU EXITS (OVERVIEW)
Menu enhancements can be created using Business Add-Ins. As a user, you can add Customer Fcn function
in the menu options. However, the menu enhancements must be pre-planned and should be implemented
inside the BAdI implementation.

BUSSINESS ADD-INS: MENU EXITS (SAP PREPARATION)
As shown here, function codes of menu enhancements begin with a plus sign ’+’. The added menu item is
displayed only if the implementation is active.
BUSSINESS ADD-INS: MENU EXITS (FUNCTION CODE PROCESSING)

The corresponding code for the menu option is declared inside the CASE statement. However, the function
code should begin with the plus sign ‘+’.
BUSSINESS ADD-INS: MENU EXITS (RESTRICTIONS)
The function codes specified in a menu exit for a BAdI are available for single use. You can avoid conflicts
between different BAdI implementations by ensuring they are neither filter-dependent nor reusable.
EXTENDIBLE FILTER TYPES: PREREQUISITES
The filter type property of a BAdI has an extendible attribute. This attribute can be utilized if the domain of
extendible filter type has these properties:
The domain must be linked to a cross-client value table. The value table should have exactly one key
field, which has the data element of the filter type as its field type.
The domain must have a text table with two key fields. One key field has the filter type as its field type,
and the second key field has language as its field type.

The delivery class of both tables must be E or S.
DEFAULT IMPLEMENTATION
If an active implementation is present, it is executed. However, if an active implementation is unavailable a

default implementation is executed. The default implementation is created by the enhancement provider.
COMPARISON WITH OTHER ENHANCEMENT TECHNIQUES
Business Add-Ins are an extension of conventional enhancement techniques. BAdIs are both filter specific
and reusable as compared to customer exits. It is possible to append fields on screens with restrictions
using BAdIs.

NAMING CONVENTIONS (BADI DEFINITION)
As a user, you must comply with these naming conventions for BAdI definitions:
The name of a BAdI must begin with <badi> or z<badi>
The name of the BAdI interface must begin with IF or ZIF as shown here.
Any name can be specified for a BAdI method.
The name of a BAdI adapter class must begin with CL or ZCL.
NAMING CONVENTIONS (BADI IMPLEMENTATIONS)
You must comply with these naming conventions for BAdI implementations:
The name of a BAdI implementation must begin with <impl> or z<impl>

The name of the BAdI interface must begin with IF or ZIF as shown.
The method defined in BAdI definition is implemented.
The name of a BAdI implementing class must begin with CL_IM OR ZCL_IM.
MODIFICATIONS: OVEVIEW DIAGRAM
This slide illustrates that Modification is an integral part of the standard SAP applications. It also shows
Modification Assistant and user exits.
ORIGINALS AND COPIES
Any object created in the development system is termed as original. However, when this object is
transported to another system, only a copy of the original is passed. In fact, an object is regarded as original
in only one system. Therefore, when SAP delivers an object, the customer actually gets only a copy of the
original. The original object always lies with SAP.

CORRECTIONS AND REPAIRS
Changes made to an original are called corrections. All the changes done are recorded in a change request
whose tasks have the type Development or correction. The changes done to a copy are termed as repairs.
These changes are recorded in a task with the type Repair. The repairs to SAP objects are known as
modifications. These terminologies are also applicable to any other object created in a development
system.
MODIFICATIONS AND UPGRADES
The modifications done to SAP objects create problems during upgrades. Therefore, in order to save those
changes, modification adjustment needs to be performed. These modification adjustments must also be
performed on development system to ensure that the objects are consistent within systems.

REGISTERING MODIFICATIONS IN SSCR
It is important that all the changes made to objects in customer system are registered. This requires a SSCR
Key. Any changes done to the objects at a later stage would not require generation of a new key.
Sscr (SAP software change registration) has the following advantages
 Quick error resolution and high availability of modified systems
 Dependable operation
 Simplification of upgrades
CARRYING OUT A REGISTERED MODIFICATION
You must provide the Workbench Organizer with SSCR key and a change request to make any changes to
SAP Repository objects. Additionally, you need to confirm the warning dialogs that appear while making
changes.
A change request performs various functions :
Task
Change lock
Import lock
Version created.

WHEN THE MODIFICATION IS FINISHED
Once the user finishes working on an object, the change request associated with it is set for release. The
user needs to document all the changes. Once the developer confirms the repair, an import lock is attached
to the change request. Once the project is complete, the change request is released and all the object locks
associated with it are disabled including change locks and import locks. After the release, the objects are
copied from the database of the SAP system and are stored in a transport directory.
VERSIONS
When a change request is released, complete version of all objects contained in the change request is
written to the versions database. If the Repository object is transported again later, the current object
becomes a complete copy and the differences between the old and the new object are stored in the
versions database as backward delta.

CRITICAL SUCCESS FACTORS (1)
The customer source code should be encapsulated in modularization units instead of being inserted directly
into SAP source code. In addition, you should use narrow interfaces to encapsulate customer-specific
functions for good data control.
CRITICAL SUCCESS FACTORS (2)
You need to consider certain critical factors while maintaining source code documentation:
Using standardized inline documentation
Ensuring not to delete any SAP source code =
Maintaining modification logbook
Taking care not to modify basic dictionary objects
Releasing all requests containing repairs

MODIFICATION LOGS (EXAMPLE)
All modifications done to your system should be recorded. In the template shown here, you must provide
information for these columns :
Object type
Routine (if applicable)
Subject area (according to process design blueprint or technical design)
Repair number
Change date
Changed by
Preliminary correction? (yes/no)
SAP Note number, valid until Release x.y
Estimated time to restore the modification during the adjustment
MODIFICATION ASSISTANT: PURPOSE
The purpose of the Modification Assistant is to simplify modification adjustments.

Modification assistant provides a finer granularity than possible otherwise. This is because modifications
can be done at subroutine or module level. Modifications are registered in a separate software layer.
HOW THE MODIFICATION ASSISTANT WORKS

The changes done in modifications are recorded in a separate layer, which ensures that the original source
code of the object remains unchanged. The modifications are not accepted, until the load is generated.
MODIFICATION ADJUSTMENTS THEN AND NOW
Previously, whenever a new version of an include program modified by the user was provided by SAP,
modification adjustment was necessary. Each modification had to be manually included in the new SAP
version.
Now, using Modification Assistant, modifications can be recorded even at subroutine or function module
level.
MODIFICATION ASSISTANT: SOFTWARE LAYERS
The software layer present at the customer site is a combination of both the originals provided by SAP as
well as present modifications.

MODIFICATION ASSISTANT: TOOLS SUPPORTED
This slide lists the tools supported by the Modification Assistant.
MODIFICATION ASSISTANT: PREREQUISITES
Modification Assistant can be turned on or off for the entire system using the profile parameter
eu/controlled_modification. The user must provide SSCR key and change request to change an SAP object.
The system then displays a dialog box informing that the object is under control of the Modification
Assistant.

MODIFICATION ASSISTANT ICONS
You cannot use all the typical functions of the tool you are working with during modifications. However,
these functions can be accessed using appropriate pushbuttons such as insert, replace, delete, undo
modification, and modification view.
MODIFICATION ASSISTANT: ABAP EDITOR EXAMPLE
This slide shows the use of pushbuttons during modification.

When the user clicks insert, a new block of code is provided for the user as shown here. On replace, the
already existing code is commented and a new code can be inserted. Using delete, the original source code
is commented.

MODIFICATION OVERVIEW
The modification overview icon displays an overview of the modifications done in the current program.
Such changes are displayed for all the various modularization units involved.
RESTORING THE ORIGINAL
All the changes made during modification can be undone if the user selects the Undo button. It deletes the
modification record, which cannot be restored later.

MODIFICATION BROWSER
The Modification Browser displays an overview of all the modified objects in the system. It shows data
based on modifications carried out with or without the Modification Assistant. The results in the
Modification Browser are displayed as a hit list in a tree form.
USER EXITS: STRUCTURE OF A MODULE POOL
User exits are executed using special include programs. The main program, contains a list of all the include
statements for all of the include programs that belong to the module pool. Each include program is named
in a manner in which the last three letters of its name can identify the contents of that program.

USER EXITS: IMPLEMENTATION
The source code for user exit is declared using sub routines in include programs. An Include can contain any
number of sub routines as shown here. Initially these includes are empty and are delivered only once per
release. The user exits are especially developed for SD module. Their main purpose is to simplify the
process of modifications adjustments.
USER EXITS: EXAMPLE
As shown in this slide, user exits are actually delivered as empty subroutines. As a user, you can specify
your own source code inside these subroutines.

USER EXITS: SEARCH
You can search for a user exit by following the menu path: System → Status → Double Click on Program
Name → Search By Character String user exit’.
This procedure provides you with the required documentation for the user exit.
You can also conduct similar search in IMG: In SD, go to System adjustment → User exits and choose
Complete Selection.
OBJECTS FOR ADJUSTMENT
Whenever SAP delivers a new version, the set of objects modified by the customer are compared with the
delivered ones. The set of objects common to both are the ones that require adjustment.

MODIFICATION ADJUSTMENT: SPDD AND SPAU
The comparison between old version and new versions is done using transactions SPDD and SPAU. The
transaction SPDD is used to adjust Dictionary objects; whereas transaction SPAU is used to adjust all the
other ABAP Repository objects.
TRANSPORTING ADJUSTMENT BETWEEN SYSTEM
When modification adjustments are carried out, separate change requests are assigned for SPDD and SPAU
transactions. Subsequently, these change requests are transported into SAP systems where these changes
need to be adjusted. This ensures that all actual adjustments are done solely in the development system.

MODIFICATION ADJUSTMENT: INTRODUCTION
The hit list, which is displayed on a selection screen at the beginning of modification adjustment, can be
restricted. The hit list can be displayed on the basis of objects that are to be adjusted or that are yet to be
processed.
MODIFICATION ASSISTANT ICONS
The modification assistant icons are displayed against objects that need adjustment. There are various
possible ways of making adjustments:
If you choose automatic adjustments, the changes are adopted automatically by choosing the
appropriate icon or menu option.
If you select semiautomatic adjustments, you can make use of the individual tools for this purpose.
During adjustments you can use the Split Screen Editor to make any changes.
If you opt for manual adjustment, the modification adjustment is done without any special support from
the system.
Adjusted objects are marked by a green tick.
If you want to use the new SAP standard version, you should use original restored button.

NEW ENHANCEMENT CONCEPT (OVERVIEW)
The new enhancement framework contains enhancement points and enhancement sections as newly
added options. It includes both implicit and explicit enhancement points and explicit enhancement section.
The new enhancement framework also contains new BAdI and classic BAdI. As shown here, explicit
enhancement point, explicit enhancement section and the new BAdIs are managed using enhancement
spots. A collection of enhancement spots can be called a composite enhancement spot.
ENHANCEMENT POINT
An enhancement point provides the users with an option to insert their own source code, variable
declarations, and parameter declarations in SAP programs, function modules and classes without the need
for a modification. Implicit enhancement points are present at particular points in SAP objects by default,
whereas explicit enhancement points are insertion options that are generated by SAP.
Composite enhancement spot has many enhancement spots

Enhancement spot is what the user creates implementations from
Enhancement spot contains many enh points and many enh sections

IMPLICIT ENHANCEMENT POINTS (1)
The slide lists the options where implicit enhancement points are present.
IMPLICIT ENHANCEMENT POINT (2)
As shown here, implicit enhancement points are also present in various points in classes.
EXPLISIT ENHANCEMENT POINTS AND ENHANCEMENT SECTIONS

An explicit enhancement point is an option provided in advance to SAP users to enhance the SAP source
code without making any modification.
Similarly, an explicit enhancement section is another such option which allows the users to replace the SAP
source code without making any modification.
Enhancement point can be either static (to allow additional data declaration) or dynamic (to allow
additional executable code).
Both point and section are stored inside a spot.

Enhancement Point -
If you have written code using enhancement point your custom code will be executed along with the
standard code.
Enhancement Section -
If you have written code using enhancement section, only your custom code will be executed replacing
standard code. standard code will not be executed.
IMPLICIT Enhancements:
In a abap report, there are two places at which the enhancements are possible by default.
One is the start of the report and at the end of the report.
So, by default in all the reports, customers can do enhancements at the start and end by creating
enhancement implementations.
EXPLICIT Enhancements:
In this case, SAP has to explicitly provide the places in the report where exactly it can be enhanced.
So, again there are three options to do the same.
1. Enhancement Point:
Enhancement points has to be created in the report where exactly customer can enhance such that
the desired results at that point can be changed
by the enhancement implementations.

2. Enhancement Section:
Enhancement sections has to be created in the report by selecting the section of code lines which can
be enhanced by the customer implementation.
3. BAdi:
BAdis are the ways of enhancements which are mainly available for ABAP Objects where a BAdi
definition will be created with a interface with fixed signature that can be implemented by the customer by
BAdi implementation.
Global SAP class

Implicit enhancement options
 Adding optional parameters to method interfaces (importing, exporting etc)
 Defining additional attributes and methods
 Defining pre and post method for any SAP method, or alternately defining an overwrite method
Implicit enhancement points
 Enhancing additional functions or use additional interface parameters, methods or attributes at the
beginning and end of methods
 Implementing additional methods
 Pre-post and overwrite methods
When these three are created, system generates a local class called lcl_<enh name> for the enhancement
enh_name. This local class is attached to the end of the local class implementation section in the original
class
The local class can implement the following interfaces
Ipr_<enhc_name> for pre methods, ipo for post and iow for overwrite
Pre methods do not have export parameters.

Post methods do not have export parameters. The export parameters of the original SAP method become
changing parameters in post method
Returning parameter of a functional method becomes a changing parameter
Overwrite method have same signature
You cannot change the parameter definitions of pre, post and overwrite method
You can also enhance SAP structures and SAP sub routines

REASONS TO THE NEW BADIs TECHNOLOGY
There are several reasons for introducing the new BAdI technology :
It improves performance.
Helps in implementing additional concepts such as enhanced filter concept and an option to inherit
attributes from sample implementation classes.
Integration into the new Enhancement Framework.
Integration into Switch Framework.

CLASSIC BADIs (ARCHITECTURE)
You can execute a BAdI through a BAdI interface and a BAdI adapter class. You must create an instance of
the adapter class in the application program. This instance calls the required BAdI implementations.
CLASSIC BADIs (CALL SYNTAX IN PROGRAM SAP)
In SAP program, you can create an instance of the adapter class by passing the variable name to the
get_instance method of the service class CL_EXITHANDLER. Additionally, you can call the required method
implementations by using the instance, r_exit.

NEW BADIs (ARCHITECTURE)
In the new BAdI technology, BAdI is defined within an enhancement spot. BAdI adapter class is no longer
created. At runtime, the system creates a BAdI handle which performs the same functions as the adapter
class.
NEW BADIs (CALL IN SYNTAX PROGRAM)
In case of new BAdIs, the GET BADI statement is used to acquire the BAdI handle. The CALL BADI statement
is used to call the method of the BAdI handle.
However, if the system fails to retrieve an active implementation for the BAdI in the GET BADI statement,
then the exception, cx_badi_not_implemented, is raised.

SEARCHING FOR BADIs
You can search for a BAdI in various ways:

Using transaction SE84.
Using application related search. SE81 SE84.
Using program-related search.

For this you need to search for string, GET BADI, in your program. Then,
Double-click the reference variable to get the variable definition. Finally, double-click the BAdI name to
access the corresponding enhancement spot.
USING BADIs
This slide describes the steps for creating a BAdI implementation.

FILTER-DEPENDENT BADIs
In the new BAdI implementations, filter values must be specified. More than one filter value can be
specified. Along with single filter values, filter conditions can also be given using the operators <>, >, <, >=,
<=, CP, NP.
SWITCH FRAMEWORK
Switch Framework offers a complete package of various industry solutions to SAP customers. The users can
choose to activate any of these at their discretion.
Another purpose of this Framework is to create switches and assign them different packages, screen
elements and menu entries. You can group these switches using a business function as shown here.

META MODEL DECLARATIONS VERSUS CUSTOM CODING
To develop a Web Dynpro application, we use a declarative programming approach. The ABAP Workbench
contains special tools for constructing an abstract model, a Web Dynpro meta model.
The Generator automatically outputs the necessary Generated Code. This standard Web Dynpro
framework allows you to place the Custom Code at predefined positions within the Generated Code.
Web Dynpro Runtime defines the user interface at runtime.
We can list the advantages of Meta Model Declarations:
They guarantee common application design.
They offer good support for tools, such as screen layout and nesting; navigation and error handling; data
flow; and componentization.

In contrast, Custom Coding has other advantages:
It guarantees universality.
It is good for data-driven, dynamic applications, such as implementation of Business Rules; dynamic
screen modifications; access to services; and portal eventing.
APPLICATION SCENARIOS WITH WEB DYNPRO
SAP Enterprise Portal comprises Web Dynpro Application, through which we can access ABAP Web
Dynpro Runtime. Web Dynpro applications are created using ABAP Workbench. ABAP Back-End
Server processes these applications. RFCs work through RFC-enabled function modules to pass data into
the ABAP back-end server, where it is stored as business data. The Web service also carries this data to the
Web service provider through SOAP, where it is stored as Business Data.
WEB DYNPRO APPLICATION: DATA SOURCES
Web Dynpro applications can access different kinds of data sources:

You can address all kinds of reuse components directly from a Web Dynpro ABAP application:
Methods of classes that are defined in your own system
Function modules that are defined in your own system or in a back-end system using RFC
Web Services through a Web Service client object

Placing a SELECT statement in your controller methods directly leads to a mixing between flow logic and
business logic.
WEB DYNPRO BENEFITS
Web Dynpro uses descriptive tools in a structured design process to enable application developers to
create powerful Web applications with minimal effort. It defines user interfaces through a declarative meta
model. We can list some other advantages of Web Dynpro:
Minimized coding and maximized design
Separate layout and logic
Reusability of components
Binding of data
Availability of multiple platforms
Browser-enabled manipulation with zero footprint
508 accessibility support
WEB DYNPRO COMPONENT

Web Dynpro Component houses the entities related to the user interface (UI) and Web Dynpro.
We can list the main Web Dynpro components, which are entities related to the UI:
Windows define the possible combinations of views. Windows can contain any number of views and a
view can also be embedded in any number of windows. Windows also allow for the flow between views
and the necessary navigation.
Views comprise UI elements, such as input fields and buttons, as well as view layouts, such as the
rectangular part of a page or a browser displayed by the client. The client can set up a complete page by
using just one view or multiple views. View controllers aid these manipulations.
Component controllers help maintain flow control between all the components of the Web Dynpro.
CONTEXT AND DATA TRANSPORT
A context is a hierarchical data storage system, which stores data related to the UI.
User input values for UI elements are connected to the context attributes of the corresponding view
controller. Through data binding, automatic data transport between the UI elements and the context
attributes is possible.
You can reference the variables defined in a Web Dynpro controller from other Web Dynpro controllers
through context mapping.
Combining the two concepts – context mapping and data binding – data transport between UI elements
located in different views can be defined in a purely declarative way.

CONTEXT MAPPING
A context node in one controller can automatically access data from a context node in another controller
using context mapping.
The controller acting as the mapping origin contains the relevant node in its context, This node also has
child nodes or attributes.
The mapping origin controller must not be a view controller.
The controller containing the mapped node must declare the use of the mapping origin controller as a used
controller.
PUTTING DATA ON SCREEN: DATA BINDING
Data binding helps transport data automatically from a view controller’s context to a UI element in its
layout, and vice versa.
UI elements, being private to the view controller in which they are declared, cannot be bound to context
nodes or attributes defined in another controller.
The Web Dynpro framework performs two tasks, subsequent to data binding:
It transports data from the context attribute to the UI.
It repopulates the context attribute from the UI element after the user enters the data and initiates the

next server round trip.
NAVIGATION: PRINCIPLE
Navigation links join outbound and inbound plugs together.

An inbound plug is linked to an outbound plug by registering the inbound plug event handler method to the
navigation event called by firing an outbound plug.
Navigation links are defined in a window.
An Action is used to link a client side event to an event handler method (automatically defined with the
action) in the corresponding view controller.
NAVIGATION BETWEEN VIEWS
You can define the navigation between two views by creating exit and entry points for each view using
outbound and inbound plugs.
You can then specify the navigation flow using navigation links.

WINDOWS AND NESTED VIEWS
When you create a window, you define

which views are displayed;
in what combination; and
how you can change the view combination by firing outbound plugs.
A window is a set of all possible views that can be adjusted in a visible screen.
The container area in a view is defined by the ViewContainerUIElement, which allows nesting within the
window.
This ViewContainerUIElement only displays a single view at a time.
VIEW ASSEMBLY
Outbound plugs trigger a particular view in the view container area.

A view assembly consists of the subset of views visible at any time.
A window definition may have multiple views embedded in view container areas. This gives rise to many
permutations of views.
The permutation that is visible depends on the navigation links you follow. Through navigation, you can
replace either specific views within a view container area or entire view combinations within the window.

MODEL VIEW CONTROLLER
he Model View Controller (MVC) design paradigm is the foundation for SAP’s Web Dynpro. It decoupled
presentation and application logic, using three layers:
The Binding Layer binds the user and interaction layers together. The Controller, which is at the heart of
this layer, performs all intermediate processing.
The Business Interaction Layer consists of the Model, which generates application data without caring
how it will be displayed.
The User Interaction Layer or View visualizes the application data without caring how it was generated.
INTERNALLY VISIBLE WEB DYNPRO ENTITIES (1)
Two types of entities make up a Web Dynpro component – those that are externally visible and those that
are internally visible.
The internally visible parts can be either visual or programming entities, which consist of windows and
views.
A view consists of a view layout and the corresponding view controller. The view controller can contain
navigation plugs, methods, and a context.

A window embeds one or more views and has a corresponding window controller. A window controller can
contain navigation plugs, methods, and a context.
A view can be embedded in different windows, the first view so embedded being the default view.
Business Logic is not part of the Web Dynpro component. It is defined outside, so that it has high
reusability. Global ABAP classes are preferred for encapsulating the related source code.
The component controller acts as a component wide controller.
In the related view controller, only the program logic related to a certain view, such as checking user input,
is coded.
The developer defines optional controllers, which then become custom controllers. They help modularize
component content. They can function as local controllers for some views. Alternatively, they help
encapsulate the logic related to a certain model class. By creating a usage declaration in the custom
controller for the component controller and vice versa, you can reduce the content of the component
controller and populate sub functions.

EXTERNALLY VISIBLE WEB DYNPRO ENTITIES
For one Web Dynpro component (parent component) to access another (child component), the former can
declare the use of the latter. A specific component usage instance is then created. Through the component
interface controller, the parent component accesses the functionality of the child component.
The externally visible entities of the Web Dynpro component are the interface controller and the interface
view(s).
WEB DYNPRO APPLICATION
A Web Dynpro application is the only Web Dynpro entity that can be addressed via a URL, and is an entry
point into a Web Dynpro component.
The Interface view in Component Interface has inbound as well as outbound plugs. An application is
created here with an inbound plug of the type Startup, called Default. This is because an application is a
URL associated with this special inbound plug in the interface view.

WEB DYNPRO APPLICATION: TYPES OF CONTROLLERS
Four main types of controllers exist in a Web Dynpro component:

The Component controller drives the functionality of the entire component. It is a global controller; is
visible to all other controllers; and has no visual interface.
Custom controllers are optional. They are defined at design time and are used to encapsulate sub-
functions of the component controller. A component can have several defined custom controllers, which
are instantiated automatically by the Web Dynpro framework.
The Configuration controller is a special custom controller. It is used for special configuration and
personalization functions. A component can have only one configuration controller.
The View controller handles the view-specific flow logic, such as checking user input and handling user
actions. Each view comprises the layout and exactly one view controller.
The Window controller handles the data passed through the inbound plugs when reused as a child
controller. Each window has exactly one window controller. Its methods are also called from the inbound
plug methods of the window.
CONSTITUENTS OF ALL CONTROLLERS

In the Web Dynpro framework, the Controller comprises Context, Attributes, Properties, and Methods.
The Context houses all the root nodes.
Attributes comprise Standard Attributes and Additional Attributes. Standard attributes may be of two
predefined types: WD_THIS and WD_CONTEXT, which access the functionality of the controller and the
context, respectively.
The Properties tab of a controller defines the sharing of information between different controllers. This is
where usage declarations are stored. Any controller can get access to another only by using this tab.
The Methods tab is the repository for hook methods, which are a set of methods predefined in the Web
Dynpro framework. All controller types have at least two hook methods, which are processed only once
during the lifetime of a controller instance.
WDDOINIT( ) is processed when a controller instance is created and WDDOEXIT( ) when a controller
instance is deleted.
The Methods tab also helps define Additional Methods.
Business Logic, such as function modules, BAPIs, or methods in helper classes, can be accessed from the
methods of all controllers.
COMPONENT/CUSTOM CONTROLLERS: SPECIAL ENTITIES

You can create Events for component and custom controllers, and define them with the parameters of your
choice.
You can register any method of any other controller, including view and window controllers, to the created
events if the method is defined as an event handler one.
The component controller has three additional hook methods: WDDOBEFORENAVIGATION( ),
WDDOPOSTPROCESSING( ), and WDDOAPPLICATIONSTATECHANGE( ).
VIEW CONTROLLERS: SPECIAL ENTITIES
An action links a client-side event, such as clicking a button in a browser, to an event handler method
defined in the corresponding view controller.
A navigation event is raised when an outbound plug is fired.
An inbound plug is a navigation event handler that can be registered to a navigation request.
Layout is used to create the interface between the user and the client.

WINDOW CONTROLLER ARCHITECTURE
Window controllers act as controllers without a UI (view layout). You embed all the views that are to be
displayed when using a Web application in the window that is referred to by it.
The Web Dynpro window embeds the views to be displayed, as well as the navigation links. Each Web
Dynpro window contains outbound plugs and inbound plugs, just like views.
THE CONTEXT

Context refers to the single hierarchical data storage structure assigned to every Web Dynpro controller.
The data is held in the context for the life span of the controller. This is lost with the termination of the
controller instance.
CHANGING THE CONTEXT ( 1 )
You can select the controller and open it in the Change mode in order to modify the context of the
controller.
Next, you select the context tab to get the hierarchical structure of the context.
You can display the properties by choosing the context node or attribute, accordingly.
CHANGING THE CONTEXT ( 2 )
You can edit the properties of all the nodes and attributes simultaneously by simply selecting the Switch
Context Editor View option.
CREATING NEW CONTEXT ELEMENTS
Nodes and attributes constitute a hierarchical arrangement of entities, from which all controller contexts
are constructed.
The parent node of a context is known as the context root node; has fixed properties; and cannot be
deleted.
The main abstraction class used for runtime data storage within the Web Dynpro framework is known
as context node. The node may have attributes or other nodes as children.
A context attribute is an entity within the context, which cannot have children. You can create a context
attribute only as the child of some parent node, whether it is the context root node itself or some other
node.
You can open the context menu of the context node to create the respective node and attribute.
CONTEXT NODES AND CONTEXT ATTRIBUTES AT RUNTIME ( 1 )
You create the metadata structure at design time, within which the runtime data is stored.
During runtime, a node object is automatically created for the context root.
In addition to the creation of the node object, an element object is created .An element is a unit that
aggregates all the child entities of a node. The reference to the element created is stored in the node’s
attribute COLLECTION.
At design time, the context attributes A1 and A2 are created, which are related to the context root.
A corresponding structure is created at runtime only if the context attributes are related to the context
root. The reference to this structure is stored in the elements attribute STATIC_ATTRIBUTES.
The context nodes N1 and N2, as well as the context attributes A1 and A2 are created under the context
root at design time.
Now at runtime, a node object is automatically created for each sub node of the context root. The attribute
CHILD_NODES of the context root element stores the relevant references.
NODE COLLECTION CARDINALITY

Cardinality is a property of every context node. This property defines the maximum and minimum number
of elements that the node collection can hold at runtime. Therefore, cardinality comprises two values. The
lower limit cannot be lower than zero (0) and the upper limit cannot be higher than n.
Four possible combinations give rise to cardinality values (specified as <Min>..<Max>):
0..1: Zero or one element permitted
0..n: Zero or more elements permitted
1..1: Exactly one element permitted
1..n: One or more elements permitted
CONTEXT STRUCTURE AT RUNTIME: CARDINALITY PROPERTY ( 1 )
The context node N1 has the cardinality value c = 0..1. N2 has the cardinality value c = 1..1. These nodes are
created under the context root, which itself has a cardinality value c = 1..1. Cardinality describes the
maximum and minimum number of elements that the node collection may hold at runtime.
The context root node is instantiated automatically at runtime. The reference to this node is provided by
the framework through the controller attribute WD_CONTEXT.
Independent nodes are defined as direct children of the context root node. They are instantiated
automatically when accessed for the first time.

CONTEXT STRUCTURE AT RUNTIME: CARDINALITY PROPERTY ( 2 )
The structure of the context at runtime is no longer the flat, two-dimensional hierarchy seen at design time.
The context now comprises multiple dependent objects. At runtime, you can append multiple elements to a
collection originating from a context node.
This concept mimics the differences that an internal table exhibits at design time and at runtime.
LEAD SELECTION INDEX
The attribute LEAD_SELECTION_INDEX of each context node is used to simplify the access to the node’s
collection. If the context node property Initialize Lead Selection is set to true, the attribute is automatically
set to 1 as soon as the first element is created. You can also set the lead selection index using the program
source code or through user actions related to user interface elements.

LEAD SELECTION - IMPORTANT CASES
You can use special methods in the controller source code to access the value of a node’s lead selection
index, as well as the element related to this index.
The lead selection index is used in certain important situations.
If a single row is selected in a table, the lead selection index is automatically adjusted accordingly and
you can access the related context element without the element index. The marked row can be
manipulated programmatically by changing the lead selection index.
You can bind form fields to attributes of a context node having the cardinality 0..n or 1..n. You can
change the lead selection index to programmatically manipulate the displayed data set.
Special methods, such as supply functions, can be assigned to context nodes. These functions are called
automatically by the framework if the lead selection in the parent node changes.
CONTEXT STRUCTURE AT RUNTIME: SINGLETON PROPERTY ( 1 )
The context node N1 is the parent node, which has a child node called N2.
The N2 node is a distinct node with its own element collection.
If the N2 node has its singleton property set to false (that is, the node N2 at runtime is a nonsingleton,
which is the default), then every element in the parent node N1 is complemented by a distinct instance of
the child node N2.
Note that the arrows pointing to each of the N2 node collections originate in the elements of the parent
node. Hence, for n elements in the parent node, you will see n distinct instances of a nonsingleton child
node.

CONTEXT STRUCTURE AT RUNTIME: SINGLETON PROPERTY ( 2 )
If the Singleton property is set to true for node N2, then despite the multiple elements present in the
parent node collection N1, the node N2 is a singleton at runtime. In other words, there will only be one
instance of the child node N2.
REPOPULATING A DEPENDENT NODE ( HERE SINGLETON NODE ): SUPPLY FUNCTION
Supply functions are mechanisms used for automatically repopulating child nodes. The property Supply
Function has the value GET_N2_DATA. You assign a supply function to each context node of a controller, by
setting this value accordingly.
The Web Dynpro calls the supply function at runtime if the data of the context node is needed.

SUPPLY FUNCTION: AUTOMATIC CALLS
The Web Dynpro runtime automatically calls the supply function under certain conditions:
If the node’s collection is initial.
If the lead selection index of the parent node is changed.
If the node’s collection is invalidated programmatically.
CONTEXT MAPPING
Context mapping allows a controller (typically a view controller) to access data that was pre-processed by
some other controller. You can drag and drop the context node to the target node. The mapped node then
appears as a child node. This mapping relationship allows a direct reference to data in another controller.
This obviates the need to copy or move the data.
The context node that acts as the data source is the mapping origin node; whereas, the context node that
is mapped is the mapped node.
You can view the mapping path in the property of the node.
View controller is always the receiver.

CONTEXT MAPPING: INTERNAL MAPPING
If both the mapped node and the mapping origin node lie within the boundaries of one component, the
mapping relationship is known as internal mapping.
The mapping relationship is fully established when writing the current component.
ELEMENTS
Graphical entities that occupy positions within a view layout are called UI elements.
The Label UI element provides a label to a particular field.
The TextView UI element helps you enter text.
The Button UI element is used to insert a button within a view layout.
The InputField UI element is used for inserting an input field to the layout. The Image UI element can be
used to insert any image in the layout.
There are certain UI elements, such as the Transparent Container, the ViewContainerUIElement, or the
Invisible Element, which are not visible on the screen and are only used to structure the UI.

UI ELEMENT CATEGORIES
The elements for designing the user interface of a Web Dynpro application are divided into categories,
which are displayed in the view designer:
Text comprises elements that are used for displaying texts or entering literals.
Action is the repository for simple elements that trigger navigation or just a round trip.
Selection includes simple elements that display multiple values, from which the user can select one or
more, depending on the element type.
Complex lists elements that need subelements to define a valid UI element.
Layout enumerates the UI elements used to structure the layout.
Graphics groups elements to render graphical members of the page.
Integration assembles elements that embed non-ABAP technologies in Web Dynpro
ARRENGEMENT OF UI ELEMENTS
Let us analyse the hierarchy of UI elements that constitute view layouts:

The root node, called RootUIElementContainer, is of the type TransparentContainer.

Additional UI elements in a view layout are hierarchically subordinate to RootUIElementContainer.
Context_Menu is the hard-coded context menu provider displayed above the RootUIElementContainer,
which enables context menus to be defined at design time, and instantiated and assigned to UI elements.
Hence, context menus can be defined statically as subelements of Context_Menu.
CONTAINER ELEMENTS: POSSIBLE CHILD ELEMENTS
Some UI elements may have arbitrary child elements.

We can identify a few examples of Container elements:
Group
Panel
TransparentContainer
Tray
ScrollContainer (as this is deprecated, use TransparentContainer instead)
These UI elements occupy a rectangular area in a view’s layout and all UI elements that are children of a
container element are located in this rectangular area.
UI ELEMENTS: LAYOUT PROPERTIES
All the container elements define the arrangement of their children with the Layout property, which
assigns a layout manager to the container UI element. The Layout property may have five values:
FlowLayout
RowLayout
MatrixLayout
FormLayout
GridLayout (instead, use MatrixLayout whenever possible)
LAYOUT MANAGERS: FLOWLAYOUT
The layout manager will have FlowLayout as the default selection. This ensures that all the child elements
of a container are sequentially arranged. Therefore the line breaks cannot be specified explicitly.
Elements in different lines are not related to each other and this kind of container can be used to arrange
subcontainers.
The container may be too narrow for the child elements to be displayed in one row. If the browser window
is too narrow, for example, these elements are automatically wrapped to the next row(s).
UI ELEMENTS

If the container is wide enough, elements that do not force a line break are displayed in a row. If the
container is too narrow for these child elements to be displayed in one row, they are automatically
wrapped to the next row(s).
Some elements that do not force a line break are
InputField;
Label;
FormattedTextView and TextView;
Button, ButtonChoice, and ToggleButton;
LinkChoice, LinkToAction, LinkToUrl, and ToggleLink;
CheckBox and TriStateCheckBox;
DropDownByIndex and DropDownByKey;
RadioButton; and
Image.
LAYOUT MANAGERS: ROWLAYOUT
If the layout property is set to RowLayout, then all the children inherit the property LayoutData, which
contains the values RowData andRowHeadData.
A line break is forced if you set this property to RowHeadData.
If you set the property to RowData, no line break is forced.
LAYOUT MANAGERS: MATRIX LAYOUT

If you select MatrixLayout as the layout property, then all the children inherit the property LayoutData,
which can have the values MatrixData andMatrixHeadData.
A line break is forced if you set the property to MatrixHeadData.
If you set the property to MatrixData, the child elements are displayed in the same row as the previous
element, despite the right-hand margin appearing.
The child elements in this container are arranged in columns. The number of columns is defined by the
maximum number of child elements in any row.
LAYOUT MANAGERS: GRIDLAYOUT
You can set the property to the GridLayout if you want a vertical alignment of the elements. The number of
columns is defined statically by setting the colCount property of the container element.
This kind of layout manager should be used if all rows have the same number of columns and if only
complete rows are inserted or deleted.
LAYOUT MANAGERS: FORMLAYOUT ( 1 )

If you set the layout property to FormLayout, then all the children inherit the property LayoutData, which
can have the values FormTopData, FormHeadData, and FormData.
With the setting FormTopData, you can divide the page horizontally in sections where each section
contains a statically defined number of columns. The width of these columns is unique across all sections.
LAYOUT MANAGERS: FORMLAYOUT ( 2 )
You can force the line breaks by setting the property LayoutData property as FormHeadData.
The child elements are displayed in the same row as the previous element for the property set to
FormData.
The spreading of the elements across the columns can be defined automatically if the colSpan is left at its
default value (of -1).
If the colSpan value is set to n then the UI element is spread across n columns.

USING THE VIEW EDITOR
The View Editor is a Web Dynpro-specific tool that allows you to edit a view layout.
You can select the Change option from the context menu of a view to edit a view. The view editor can be
used with or without the layout preview. The layout view will be selected by default.
VIEW EDITOR
By dragging any UI element from the toolbar on the left-hand side of the View Editor and dropping it in the
layout preview, you can add it to the UI element hierarchy.
Alternatively, you can select Insert Element from the context menu of any superordinate element in the
hierarchy that has child elements, such as aTransparentContainer element or a Group element to add a
new UI element in the hierarchical representation.
The properties of a selected UI element can be changed or displayed by choosing the Properties tab.

Properties with the prefix on relate to client-side events, examples being onFilter, onSort, or
onAction. Actions have to be associated with each of these events.
DATA BINDING
The context data is used to supply a value to the UI element property if the UI element property is bound to
a context node or attribute. Thus the data in the bound nodes and attributes are transported automatically
to the corresponding UI elements.
PUTTING DATA ON THE SCREEN ( 1 )
Data binding necessarily defines a two-way relationship.

This two-way transport process is entirely automatic and requires no action on the part of the application
developer.
The context attributes are first defined and declared in the CONTEXT.
Next, create the UI elements on the layout.
Finally, you bind the UI element to the context attribute.
DEFINING UI ELMENT PROPERTIES STATICALLY

You can either hard-code the value of a UI element property or bind it to a context attribute of a suitable
data type. If, at design time, a property value is hard-coded, it only endows the UI element with a fixed
behaviour.
Accessing the UI element hierarchy directly from the controller’s method, however, is avoided. It is
considered poor design, as flow logic and UI are no longer kept separate.
CONTROLLING UI ELEMENT PROPERTIES (1)
You might need to control the behaviour of a UI element programmatically.

In this case,
create a context attribute with a data type that matches the property you wish to control;
choose the corresponding data type from the types available for each UI element property; and
set the value of the attribute using the default value or any other method that accesses the attribute at
runtime.

You can thus control the behaviour of the UI element by modifying the related attribute value using any
method of any controller that has access to this context attribute.
CONTROLLING UI ELEMENT PROPERTIES (2)
Once you create the context attribute, bind it to the appropriate UI element property. The example shows
that the readOnly property of an InputField UI element has been bound to a Boolean context attribute.
The value of the context attribute can now be manipulated by any controller hook method, or by your
methods defined additionally.
You can bind the similar properties of multiple UI elements to the same attribute.
DATA BINDING FOR SAP NW 7.0 (ABAP SPS ≥ 12)
As per the SAP Netweaver 7.0 SAP_ABAP support package stack 12, every context attribute permits you to
bind not only the UI element’s primary property to it, but also the properties enabled, visible, readOnly,
and state.
For the key property, you can select the radio button Bind Directly and establish a direct data binding.
If you choose the radio button Bind to the Property of the Selected Attribute, the
properties enabled, visible, readOnly, and state can be bound to the corresponding context attribute
properties, respectively.
COMPOSITE UI ELEMENTS (1)
Any UI element that requires a child UI element is known as a composite UI element.

Composite UI elements, such as Table and Tree, require complex mandatory child structures.
COMPOSITE UI ELEMENTS (2)
A composite UI element cannot display any information without the subordinate (or child) UI elements.
It must perforce have a child element to be able to function.
The slide depicts a hierarchical representation of a Table UI element.
FLIGHTTAB is considered a composite Table UI element. Its child UI elements are FLIGHTTAB_CARRID,
FLIGHTTAB_CONNID, and so on.TableColumn elements are also considered composite UI elements.

THE TABLE UI ELEMENT
A good example of a composite UI element is the Table UI element. Its child element, the TableColumn UI
element, is also a composite element. The Table UI element acts as a parent for several such TableColumn
UI elements, each of which, in turn, acts as the parent for a header (Caption UI element) and a cell editor
(TextView UI element).
BINDING A TABLE UI ELEMENT TO THE CONTEXT
Without context bindings, the UI elements of a Table cannot function correctly.

The Table UI element allows the two-dimensional display of data in cells arranged in rows and columns. It
must be bound to a context node of cardinality0..n or 1..n.

TABLE COLUMN UI ELEMENTS
The Table UI element must contain at least one TableColumn UI element, which are also composite UI
elements. There is no need to bind the TableColumn UI elements to the context nodes or the context
attributes. The column header is created using a Caption element.
DEFINING CHILD UI ELEMENTS FOR A TABLECOLUMN
A TableColumn UI element must have a child UI element that acts as the cell editor. You can choose the
child elements depending on the kind of interaction between the user and the data in each column.
The caption that appears as the column header is optional and is defined by the type Caption. The user
cannot modify the data if you select a display-only UI element such as TextView.

TABLE ROW SELECTION
The example shows a node collection containing two elements. When the user clicks the second table row,
element 2 of node FLIGHTS is activated. The lead selection of this node is then altered to reflect the user’s
selection.
The number of rows in the table and the elements in the node collection are the same.
SELECTING MULTIPLE ROWS FROM A TABLE
The context node to which the Table UI element is bound must have a selection cardinality of
either 0..n or 1..n, to enable the user to select multiple rows from a table.
The default selection cardinality setting for any context node is 0..1. This means that zero or one element
may be selected at any one time.

SELECTION MODE: POSSIBLE VALUES
The Table UI element property SelectionMode has a default value as auto. This property can also be
adjusted to none, single, multi, singleNoLead, and multiNoLead. These settings help mark rows and set the
lead selection.
If selectionMode is set to none, the selection column is not displayed. The row related to the lead selection
is not highlighted.
If selectionMode is set to single or singleNoLead, only one row may be selected. This is independent of the
context node property Selection.
If selectionMode is set to singleNoLead or multiNoLead, the lead selection index is not changed by
selecting table rows.
TEST PAGE FOR UI ELEMENTS
A Web Dynpro application WDR_TEST_UI_ELEMENTS is delivered in every system containing the Web
Dynpro framework. This allows you to check out the various functions of the available UI elements.
CONTROLLER METHODS
A number of predefined methods are provided by the controller. These methods, which are called by the
Web Dynpro runtime in a predefined order, are calledhook methods.
As these methods are empty at the time of controller creation, the developer can write any desired code in
it.
The developer can also define additional methods, such as ordinary methods, event-handler methods, or
supply functions.
STANDARD HOOK METHODS FOR ALL CONTROLLERS
This slide depicts the two standard hook methods that exist for all controller types:
WDDOINIT( ) is the first method processed in the controller’s lifetime. It is called once in the controller’s
lifecycle, immediately after the controller is instantiated. Therefore, you enter all your initialization codes
here.
WDDOEXIT( ) is the last method processed. As it marks the end of a controller’s lifecycle, you can
mention all your cleanup codes here.

STANDARD HOOK METHODS: COMPONENT
Additional hook methods are available, depending on the controller type.

WDDOBEFORENAVIGATION( ) is called after the action method is processed and just before the events in
the navigation queue are processed by the Web Dynpro framework.
WDDOPOSTPROCESSING( ) is the last controller method that is processed before the UI is sent to the client.
WDDOAPPLICATIONSTATECHANGE( ) is processed each time the application is suspended or resumed. You
can suspend a Web Dynpro application by firing a suspend plug of the window. The suspended Web
Dynpro application can be resumed by a resume plug.
STANDARD HOOK METHODS: VIEW CONTROLLER
View controllers have access to four additional hook methods:

WDDOBEFOREACTION( ) is the first method processed in the Web Dynpro application after you raise a
client event bound to an action. It contains a reference to the source code related to input checks.
WDDOAFTERACTION( ) is called after an action handler method is processed. It modularizes the source
code related to action handling.
WDDOMODIFYVIEW( ) helps you access the UI element hierarchy and can be used to dynamically
manipulate the latter. It is the last view controller method to be processed.

WDDOONCONTEXTMENU( ) is processed each time you right-click any UI element defined in the related
view layout.
PHASE MODEL (SIMPLE CASE)
Controller methods are processed in a certain order, which is described in the phase model:
When starting a Web Dynpro application (Application start),
the method WDDOINIT( ) instantiates all controllers needed for the first display;
the inbound plug method HANDLEDEFAULT( ) processes the interface view related to the application;
and
the component controller methods WDDOBEFORENAVIGATION( ) and WDDOPOSTPROCESSING( ), and

the view controller method WDDOMODIFYVIEW( ), are all processed accordingly. The phase model for a
request triggered by a user interaction describes the action handler method, inbound plug handler method,
and component and view controller methods (Navigation to view):
WDDOBEFOREACTION( ), ONACTION<ACTION>( ) and WDDOAFTERACTION( ) are processed if the client side
event is bound to an action.
The component controller method WDDOBEFORENAVIGATION( ) is processed.
The inbound plug method Handle<PLUG>( ) is processed if
an outbound plug is fired;
a navigation link to an inbound plug is defined; and
the view related to the inbound plug is instantiated by processing the method WDDOINIT( ).The method
WDDOEXIT( ) is processed if the life time of the previous view is restricted.
The view controller method WDDOMODIFYVIEW( ) is processed for the next View.
Finally, the component controller method WDDOPOSTPROCESSING( ) is processed.

ADDITIONAL CONTROLLER METHODS
You can create additional methods by

declaring the method name and its parameters on the Methods tab of the controller editor window;
choosing Method Type as Method to define an ordinary method;
choosing the Method Type as Event Handler to create an event handler method, which can be
registered statically (in the Event column) to any event fired in a controller; or
choosing the Method Type as Supply Function to define methods that can be bound to context nodes
(Supply Function property).
These methods are automatically called from the Web Dynpro framework if the node is accessed and it is
marked as invalid.
You can set the Interface flag for a user-defined component controller method so that the method is also
visible to other components.

STANDARD CONTROLLER ATTRIBUTES
Each controller has at least two predefined attributes.

The standard attributes are
WD_THIS, which is a reference to the current controller’s interface IF_<controller name> and all the
functionality implemented in the generated class;
WD_CONTEXT, which is a reference to the controller’s context root node or the starting point for access
to the controller’s context; and
WD_COMP_CONTROLLER, which is a reference to the component controller and provides access to all
the methods and public attributes of the latter.
USER-DEFINED CONTROLLER ATTRIBUTES AND CONTROLLER METHODS
You can define additional attributes for the related controller on the Attributes tab.
These attributes are also visible for other controllers of the same Web Dynpro component if the Public flag
is set.

Attributes cannot be exposed to the component’s interface.
ACCESSING A CONTEXT NODE
A local interface is generated with the name IF_<ctrl> for each controller.
A constant (WDCTX_<node>) is generated in this interface for each node <node> of a controller context.
A standard attribute WD_CONTEXT is used to access the context root node.
The get_child_node( ) method is used to identify the child nodes of the context root nodes.
ACCESSING THE NODE ELEMENT AT LEAD SELECTION
You can use the method get_element( ) for reference to the element at lead selection of the context node
being accessed. This method returns a reference to the element instance of type
IF_WD_CONTEXT_ELEMENT.

ACCESSING CONTEXT NODES AND NODE ELEMENTS
To identify the child nodes of the context root nodes, use the method get_child_node( ).
To access the element with index n, use the method get_element(index= n).
To obtain the number of elements in a collection, use the method get_element_count( ).
ACCESSING A SINGLE ATTRIBUTE OF A NODE ELEMENT
You can use the method get_attribute( ) to access any attribute of a node element.
The name of the attribute must be exported and the import parameter returns the attribute value.
ACCESSING ALL STATICALLY DEFINED ATTRIBUTES OF A NODE ELEMENT

You can use the method get_static_attributes( ) to obtain statically defined attributes. A structure is
returned in an import parameter.
ACCESS TO THE STATIC ATTRIBUTES OF ALL NODE ELEMENTS
You can use the method get_static_attributes_table( ) to retrieve the attributes of all elements as an
internal table.
CHANGING A SINGLE ATTRIBUTE OF A NODE ELEMENT

You can use the method set_attribute( ) to change the value of any attribute of the node element.
CHANGING MULTIPLE ATTRIBUTES OF A NODE ELEMENT
The method set_static_attributes( ) can be used to change multiple attributes that are statically defined.
ACCESSING AND CHANGING ATTRIBUTES: CONTROLLER NODE
You can use the method get_attribute( ) to access any attribute of a node element. The name of the
attribute must be exported and the import parameter returns the attribute value.
You can use the method get_static_attributes( ) to obtain statically defined attributes. A structure is
returned in an import parameter.
You can use the method get_static_attributes_table( ) to retrieve the attributes of all elements as an
internal table.
You can use the method set_attribute( ) to change the value of any attribute of the node element.
The method set_static_attributes( ) can be used to change multiple attributes that are statically defined.

GETTING THE REFERENCE TO A CONTEXT NODE
You can create an element that can be added to a certain context node. The reference to this node is
determined by using the get_child_node( ) method of the standard attribute WD_CONTEXT, which points
to the context root node.
CREATING A NEW NODE ELEMENT
You can use the method create_element( ) to create the new element, once you obtain the reference to
the node.

SETTING THE ATTRIBUTE VALUES OF THE NEW ELEMENT
The attribute values can be defined using the setter methods set_attribute( ) or set_static_attributes(
).Initial values for the static attributes can be set using thestatic_attribute_values parameter.
BINDING AN ELMENT TO A CONTEXT NODE
The method bind_element( ), related to the node reference, helps you to finally add an element (not yet
part of the context node) to the node.
This method has two import parameters:
The element reference is submitted through the parameter new_item.
The parameter set_initial_elements defines whether the new element is simply added to the element
collection (value = abap_false) or replaces all existing elements in the collection (value = abap_true).

BINDING A STRUCTURE TO A CONTEXT NODE
You can use method bind_structure( ) with parameter new_item to bind a structure. The existing collection
can be extended or replaced by using the parameter set_initial_elements.
BINDING AN INTERNAL TABLE TO A CONTEXT NODE
You can use the method bind_table( ) with parameter new_item to bind an internal table. You can use the
parameter set_initial_elements to extend or replace the existing collection.

ADDING/DELETING ELEMENTS: CONTEXT NODE
You can use the method create_element( ) to create the new element once the reference to the node is
obtained.
You can use the method bind_element( ) related to the node reference to add an element to the node.
You can use method bind_structure( ) with the parameter new_item to bind a structure. The existing
collection can be extended or replaced by using the parameter set_initial_elements.
You can use method bind_table( ) with the parameter new_item to bind an internal table. The existing
collection can be extended or replaced by using the parameter set_initial_elements.
You can use the method remove_element() to remove an element from the collection.

Supply method:

Abap Notes PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Abap Notes PDF

Uploaded by

Copyright:

Available Formats

ABAP Notes

Page 2 of 580 Pages

On demand is synonymous with by design

Page 3 of 580 Pages

SAP Business By Design

SAP Business All in One

 Portal – nw java stack

Page 4 of 580 Pages

Page 5 of 580 Pages

Netweaver business client – uniform look and feel

Page 6 of 580 Pages

Page 7 of 580 Pages

Page 8 of 580 Pages

Various processes exist in AS Java:

Page 9 of 580 Pages

PROCESSING A USER REQUEST

Page 10 of 580 Pages

PROCESS FLOW FOR REQUEST

Application programs include process logic, which is executed by work processes.

DATABASE QUERY FLOW

PROCESSING DIALOG REQUEST

A program with individual dialog steps may consist of several screens.

Page 12 of 580 Pages

PRINCIPAL CHARACTERISTIC: TRANSACTION

Transactions are processing units grouped to provide specific modules.

Page 13 of 580 Pages

RELATIONSHIP BETWEEN DATABASE TRANSACTION AND SAP TRANSACTIONS

LOCK MANAGEMENT IN AS ABAP

The application developer can choose between various lock modes.

Sm12 – display current locks

THE PRINCIPLE OF ASYCHRONOUS UPDATES

THE ASYNCHRONOUS UPDATE PROCESS

An asynchronous update process triggers several steps:

Page 15 of 580 Pages

SCHEDULING BACKGROUND TASKS (JOBS)

Page 16 of 580 Pages

Each instance of an AS ABAP system contains a gateway.

Page 17 of 580 Pages

Page 18 of 580 Pages

 Rfc – describes an interface, not the programming language

CALL FUNCTION <fun name>

BAPI explorer with TCODE 'BAPI'.

Page 19 of 580 Pages

1) Find out which BAPI to be used.

Page 20 of 580 Pages

BAPI RETURN TABLE

BUSSINESS PROCESS DISTRIBUTION USING ALE

Page 21 of 580 Pages

INTERFACES TECHNOLOGIES USED IN SAP SYSTEMS

SAP systems have interfaces at different communication levels.

Business Application Programming Interface or BAPI

Common Program Interface Communication or CPI-C

Electronic Data Interchange or EDI

HyperText Transfer Protocol or HTTP

Page 22 of 580 Pages

Remote Function Call or RFC

Object Linking and Embedding or OLE

Simple Mail Transfer Protocol or SMTP

Simple Object Access Protocol or SOAP

Transmission Control Protocol/Internet Protocol or TCP/IP

Extensible Markup Language or XML

RFC CONNECTION POSSIBILITIES

Page 23 of 580 Pages