Abap Notes PDF
Abap Notes PDF
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
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
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.
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.
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
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
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).
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.
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
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
Page 11 of 580 Pages
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.
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.
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.
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.
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.
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.
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
Page 14 of 580 Pages
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
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.
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.
GATEWAY COMMUNICATION
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).
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
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
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 :
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.
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.
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.
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.
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
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.
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:
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.
BAPI USES
They link business processes across system boundaries, such as when using ALE.
They integrate various solutions in the framework of the SAP Business Suite.
Constantly increasing features (during the maintenance period) by functions newly created by SAP
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.
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
Page 26 of 580 Pages
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.
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.
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)
New functions are entered outside the existing systems for Enterprise SOA applications.
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.
A Web service defined can be called up from an ABAP program or from a Business Server Page.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Information about the database table to be accessed and the row in the table to be read is passed on to the
database.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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
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.
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).
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.
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 History
We can also check the previous imports that happened in the system as follows:
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).
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.
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).
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.
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.
With keywords, additions, and operands, the ABAP runtime system does not differentiate between
upper and lowercase.
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.
Page 53 of 580 Pages
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.
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 is known as the classic editor or the Front-End Editor (Old).
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).
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.
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.
In the navigation area, using the context menu of the program, choose Create →Transaction.
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.
As each transaction is a Repository object, you must assign it to a package and then to a change request
on the subsequent screens.
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.
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)
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
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
Page 60 of 580 Pages
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.
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
Page 61 of 580 Pages
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.
C Character 1 ‘‘
N Numeric 1 0
D Date 8 00000000
T Time 6 000000
I Integer 4 0
P Packed 8 0
F Float 8 0
User defined data types
ABAP Variables are instances of data types. Variables are created during program execution and
destroyed after program execution.
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.
Structured Variable
Similar to structured data type, structured variable can be declared using BEGIN OF and END
OF keywords.
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.
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.
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.
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.
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.
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 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.
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.
Page 67 of 580 Pages
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
- indicates subtraction.
* indicates multiplication.
/ indicates 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.
Page 69 of 580 Pages
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
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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
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.
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.
Syntax
DEFINE <macro_name>
'Macro Statements
END-OF-DEFINITION
DEFINE increment.
ADD 1 to &1.
WRITE &1.
END-OF-DEFINITION.
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.
================================
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.
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.
External Subroutines
PERFORM <subroutine>(<Program>) [<pass>].
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
[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]
[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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
You can execute the entire subroutine without stopping by choosing Execute.
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
FUNCTION MODULE
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.
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.
The application-independent search or free search through the Repository Information System helps
The program-related search enables you to search for a function module that is called within an existing
program.
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.
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.
Page 95 of 580 Pages
CALLING A FUNCTION MODULE
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.
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.
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.
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.
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;
USING BAPIs
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.
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_.
The special export parameter RETURN helps report the errors to the user.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
The signature for the method can be displayed while editing the source code by selecting
the Signature option.
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.
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.
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.
In order to get the field labels use the menu in the ABAP editor GOTO->Text Elements->Selection Texts.
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.
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.
ENDFORM.
Example Program.
PERFORM sub_display.
WRITE:/ 'After Perform'.
*&---------------------------------------------------------------------*
*& Form 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.
EXIT statement can be used to terminate a subroutine unconditionally. The control returns to the
next statement after the PERFORM statement.
PERFORM sub_display.
WRITE:/ 'After Perform Statement'.
*&---------------------------------------------------------------------*
*& Form sub_display
*&---------------------------------------------------------------------*
FORM sub_display.
WRITE:/ 'Before Exit Statement'.
EXIT.
WRITE:/ 'After Exit Statement'. " This will not be executed
ENDFORM. " sub_display
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.
*&---------------------------------------------------------------------*
*& Form sub_display
*&---------------------------------------------------------------------*
FORM sub_display.
WRITE:/ 'Before Check Statement'.
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.
REPORT zmain_program.
INCLUDE zinclude_data.
INCLUDE zinclude_write.
Output
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
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 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'.
APPEND gwa_student TO it.
gwa_student-id = 3.
gwa_student-name = 'JACK'.
APPEND gwa_student TO it.
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.
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.
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.
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.
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.
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.
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.
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.
We can also delete the adjacent duplicates from an internal table by using the following statement.
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.
Page 121 of 580 Pages
*————————————————————–* *Data Declaration *——————————
——————————–*
AT FIRST.
ENDAT.
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 *—————————————————
———–*
DATA: gwa_spfli TYPE spfli.
DATA: gt_spfli TYPE TABLE OF spfli.
ENDLOOP.
Output
Below table summarizes the differences between AT NEW and ON CHANGE OF statements.
AT NEW ON CHANGE OF
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
This slide depicts how you should always address the components of a structure by using a hyphen, as
in structure_name-component_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.
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
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.
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.
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.
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).
If you are looping through the internal table and modifying the contents , its recommended to use field
symbols instead of work area.
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
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-material = '00002'.
wa_itab-qty = 100.
COLLECT wa_itab into it_itab.
Now the contents of IT_ITAB is
material => qty
00001 => 50
00002 => 100
wa_itab-material = '00001'.
wa_itab-qty = 100.
COLLECT wa_itab into it_itab.
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.
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.
The second example defines the table type as standard, sorted, or hashed.
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.
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.
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.
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.
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.
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.
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.
Alternatively, use the table tab page; specify the table name in the internal table field; and press Enter,
to display the table contents.
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.
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.
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.
Entities logically connect business information. The flight data model comprises the entities that logically
connect flight information:
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.
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 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
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
You can use the JOIN statement in the SELECT query to select fields from more than one table.
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
You can select from a join that is defined in your program (ABAP join).
In addition to the SELECT statement, Open SQL also contains change accesses, such as the UPDATE, INSERT,
DELETE, and MODIFY statements.
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.
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.
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.
Enter the short description. Place the cursor in the data type and press F4 to get the list of SAP data types.
Enter the number of characters. Enter the decimal places if it applicable to data type that you have
selected. Save and activate the domain.
Select the Data type radio button, enter the name of the data element and press create.
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:
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.
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
CHECK VARIANT
The Code Inspector uses a default check variant with predefined checks. This default check variant contains
extended syntax check;
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.
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.
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.
Search Functions contain the searches for words and the statements in ABAP source code.
PROGRAM CALLS AND DATA STORAGE MANAGEMENT
SYNCHRONOUS 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.
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.
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 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.
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.
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.
The starting point for a new transaction is the execution of a LEAVE TO TRANSACTION statement within a
program.
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.
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.
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.
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)
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
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.
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.
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.
CLEAR bdcdata_wa.
bdcdata_wa-program = 'SAPLSEOD'.
bdcdata_wa-dynpro = '1000'.
bdcdata_wa-dynbegin = 'X'.
CLEAR bdcdata_wa.
bdcdata_wa-fnam = 'BDC_CURSOR'.
bdcdata_wa-fval = 'SEOCLASS-CLSNAME'.
APPEND bdcdata_wa TO bdcdata_tab.
CLEAR bdcdata_wa.
bdcdata_wa-fnam = 'SEOCLASS-CLSNAME'.
bdcdata_wa-fval = class_name.
APPEND bdcdata_wa TO bdcdata_tab.
CLEAR bdcdata_wa.
bdcdata_wa-fnam = 'BDC_OKCODE'.
bdcdata_wa-fval = '=CIDI'.
APPEND bdcdata_wa TO bdcdata_tab.
opt-dismode = 'E'.
opt-defsize = 'X'.
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.
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.
All external sessions of a user session can access the SAP memory.
It helps exchange ABAP data objects between the internal sessions in the same external session.
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.
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.
CLASS c1 DEFINITION.
PUBLIC SECTION.
TYPES: BEGIN OF t_struc,
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
This slide depicts a table listing operators that Open SQL accepts 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.
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.
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.
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.
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.
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.
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.
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.
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.
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 … 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.
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.
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.
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
Page 196 of 580 Pages
input checks that ensure that the values entered are consistent.
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.
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
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
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.
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.
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.
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
(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
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.
The basic objects for defining data in the ABAP Dictionary are
tables
domains.
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.
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.
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
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.
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,
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.
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
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
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 .
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
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
Page 213 of 580 Pages
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.
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;
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
In single-record buffering, only those records that are actually accessed are loaded into the buffer. This can
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.
Page 216 of 580 Pages
BUFFER SYNCHORIZATION 2
Here, Server 2 accesses the records from Table SCARR in the database and loads it into its local buffer.
BUFFER SYNCHRONIZATION 3
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.
BUFFER SYNCHRONIZATION 5
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.
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.
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.
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.
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.
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.
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.
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.
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.
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)
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.
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.
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.
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.
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;
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.
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.
CONVERSION PROCESS 2
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.
CONVERSION PROCESS 4
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.
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
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.
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 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.
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.
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.
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.
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.
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.
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.
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-CUSTOMID = SCUSTOM-ID
SPFLI-CARRID = SBOOK-CARRID
SPFLI-CONNID = SBOOK-CONNID
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.
The ABAP program shown here illustrates how to use the SELECT statement to fetch data from the view
‘sv_flights’.
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.
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.
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.
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.
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.
First define the key fields, then define the function fields. Don’t mix the order.
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
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
Page 259 of 580 Pages
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.
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.
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
Page 261 of 580 Pages
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
In transaction CAT2 - Time Sheet Entry, HR wishes to include an interactive acknowledgment that knowingly
submitting incorrect data is grounds for dismissal.
BEFORE
BEFORE
Parameters
Parameters helps one to do dynamic selection. They can accommodate only one value for one cycle of
execution of the program.
Syntax
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.
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).
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
The internal table <seltab>, which is generated by using SELECT-OPTIONS, lists possible values for the
columns SIGN and OPTION.
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.
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 INTERVALS suppresses the upper interval limit entry on the selection screen. You can use
the Multiple selection screen to specify ranges or intervals.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
A user dialog is a form of interaction between the user and the program.
User dialogs include actions, such as
entering data;
clicking a button; or
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.
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).
This slide depicts various screens represented by numbers such as 100, 110, and 120.
radio buttons for the selection of the required criteria, based on which the required screen or data is
processed or retrieved; and
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 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.
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.
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.
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
Page 283 of 580 Pages
CURRENCY
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
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.
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
Page 285 of 580 Pages
Statically definable attributes that can be changed dynamically
SCREEN: ATTRIBUTE
Type attributes, such as Normal, Subscreen, Modal Dialog Box, and Selection screen, describe the
purpose of the screen.
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.
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.
CREATING SCREEN
Next, you can design the screen layout in the layout editor.
Finally, you write the flow logic in the flow logic editor.
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.
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.
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.
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.
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.
Page 290 of 580 Pages
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.
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-Input and Screen-Output are program attributes that assign the input and output fields 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.
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.
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.
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.
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.
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.
To maintain a static sequence of screens, you enter a value in the Next screen field onscreen Attributes.
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.
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.
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.
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.
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.
a standard toolbar;
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.
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.
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.
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
Page 300 of 580 Pages
mouse by specifying a single letter to select that particular function.
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;
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
Page 307 of 580 Pages
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 icons are special output fields that display icons. Attributes such as Visible length, Intensified, and
Invisible can be changed dynamically.
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.
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.
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.
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.
Page 310 of 580 Pages
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.
You use a template from the ABAP Dictionary, which you access by selecting Dict/Program fields.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
enter a name for the Subscreen area in the Object text field and position it on the screen;
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
Page 332 of 580 Pages
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
Objects are collections of data and the functions belonging to that data.
Integration of the customer and the user into the analysis, design, and maintenance process
The software development process is an iteration of four stages which constitute the whole development
cycle:
The first stage is requirement and idea.
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
Page 349 of 580 Pages
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.
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.
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.
Page 350 of 580 Pages
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.
REPRETATION OF A CLASS
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 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 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 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.
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.
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.”
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.
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.
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.
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.
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.
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.
Page 360 of 580 Pages
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.
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.
Private methods are defined in the PRIVATE SECTION of a class, whereas public attributes are defined in the
PUBLIC SECTION.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
(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.
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
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 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.
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.
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.
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.
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.
All subclasses of a superclass can access its public or protected static attributes.
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.
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.
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;
On the other hand, go_vehicle in the second diagram is a dynamic reference variable which
is created by assignment;
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 ( ).
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.
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.
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.
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.
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.
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.
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;
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.
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.
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.
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.
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.
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.
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.
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 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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
An inherited method can be redefined using the redefine button. When a method is redefined, the
Superclass call appears as a comment.
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.
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.
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.
Specify names for the global classes and interfaces that you want to create with the proper naming
convention.
To view the UML diagram for your package, right-click the package name, select Display, and then select
UML Class Diagram.
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.
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.
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.
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.
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.
When you change the contents of internal tables while the program is running, you need to call the method
REFRESH_TABLE_DISPLAY
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
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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 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 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.
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.
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.
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.
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.
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.
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.
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.
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.
CX_DYNAMIC_CHECK, no warning message is displayed from syntax check. However, if they are not
handled during program execution, runtime error occurs.
When the word RETRY is encountered in the source code, program control jumps back to the TRY
statement of the TRY–ENDTRY block.
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.
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.
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.
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
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.
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.
CREATING AN AREA
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.
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,
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 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.
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.
Here, the objects, go_root and go_catalog, are instantiated from the main program. The root object,
go_cat, can also be instantiated here.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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>.
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.
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.
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.
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.
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.
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.”
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
Various customer programs are available for making changes to the standard SAP system. These can be
classified as Modification, Extension, or Customer Development.
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.
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.
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;
business transaction events, which are called through function modules; and
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.
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;
maintain documentation.
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.
The changes made to the standard dictionary objects, such as tables or data elements are considered as
enhancements.
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 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
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.
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.
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’.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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
For finding program exits available for an application program, you need to
follow the menu path, System → Status;
The name of the required enhancement can be found using the application hierarchy in Repository
Information System or IMG.
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.
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.
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.
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.
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.
Includes also contain various subobjects, such as subroutines, PBO modules, PAI modules, and ABAP
events. As depicted here,
LXAAAF01 contains subroutines delivered by SAP.
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;
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.
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.
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.
In menu exits, the function code for menu items must begin with ‘+.’ On activation, the added menu
options are visible in the menus.
When the menu item is selected, the corresponding source code is implemented. The CALL CUSTOMER-
FUNCTION statement calls the customer functions for the menu.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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
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.
Page 486 of 580 Pages
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
DEFAULT IMPLEMENTATION
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
DEFAULT IMPLEMENTATION
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
You need to consider certain critical factors while maintaining source code documentation:
Using standardized inline documentation
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
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.
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 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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The slide lists the options where implicit enhancement points are present.
As shown here, implicit enhancement points are also present in various points in classes.
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.
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.
You can also enhance SAP structures and SAP sub routines
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.
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.
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.
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.
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.
USING 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.
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.
It is good for data-driven, dynamic applications, such as implementation of Business Rules; dynamic
screen modifications; access to services; and portal eventing.
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.
Function modules that are defined in your own system or in a back-end system using RFC
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
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.
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.
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.
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
NAVIGATION: PRINCIPLE
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.
VIEW ASSEMBLY
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.
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.
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.
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).
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.
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.
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 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
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.
You can edit the properties of all the nodes and attributes simultaneously by simply selecting the Switch
Page 543 of 580 Pages
Context Editor View option.
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.
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
Page 544 of 580 Pages
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.
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.
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.
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.
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.
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.
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.
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.
The Web Dynpro runtime automatically calls the supply function under certain conditions:
If the node’s collection is initial.
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.
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.
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
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
Page 553 of 580 Pages
MatrixLayout
FormLayout
GridLayout (instead, use MatrixLayout whenever possible)
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
Label;
RadioButton; and
Image.
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.
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.
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.
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.
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.
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.
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.
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.
Page 561 of 580 Pages
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.
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.
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).
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.
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.
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.
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.
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.
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.
Page 566 of 580 Pages
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.
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.
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.
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
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.
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.
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.
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.
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.
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( ).
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_table( ) to retrieve the attributes of all elements as an
internal table.
The method set_static_attributes( ) can be used to change multiple attributes that are statically defined.
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.
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.
You can use the method create_element( ) to create the new element, once you obtain the reference to
the node.
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.
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).
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.
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.
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.