ABAP Dictionary

The ABAP Dictionary centrally describes and manages all the data definitions used in the
system. The ABAP Dictionary is completely integrated in the ABAP Development Workbench.
All the other components of the Workbench can actively access the definitions stored in the
ABAP Dictionary.
The ABAP Dictionary supports the definition of user-defined types (data elements, structures
and table types). You can also define the structure of database objects (tables, indexes and
views) in the ABAP Dictionary. These objects can then be automatically created in the database
with this definition. The ABAP Dictionary also provides tools for editing screen fields, for
example for assigning a field an input help (F4 help).
The most important object types in the ABAP Dictionary are tables, views, types (data elements,
structures, and table types), domains, search helps and lock objects.

Tables
Tables can be defined independently of the database in the ABAP Dictionary. The fields of the
table are defined with their (database-independent) data types and lengths. When the table is
activated, a physical table definition is created in the database for the table definition stored in
the ABAP Dictionary. The table definition is translated from the ABAP Dictionary to a definition
of the particular database.

A table definition in the ABAP Dictionary contains the following components:
Table fields define the field names and data types of the fields contained in the table
Foreign keys define the relationships between the table and other tables
Technical settings control how the table should be created in the database.
Indexes - To speed up data selection, secondary indexes can be created for the table
The customer can modify SAP tables with append structures and customizing includes. This
kind of modification ensures that the customer enhancements are automatically merged with the
new versions of the SAP tables when there is a release upgrade.

Technical Settings
The technical settings of a table define how the table will be handled when it is created in the
database, that is whether the table will be buffered and whether changes to data records of the
table will be logged.
The most important parameters are:
Data class: The data class defines the physical area of the database (tablespace) in
which the table should be created.
Size category: The size category defines the size of the extents created for the table.
When the table is created in the database, the required information about the memory
area to be selected and the extent size is determined from the technical settings.
Buffering permission: The buffering permission defines whether the table may be
buffered.
Buffering type: If the table may be buffered, you must define a buffering type (full,
single record, generic). The buffering type defines how many table records are loaded
into the buffer when a table entry is accessed.
Logging: This parameter defines whether changes to the table entries should be
logged. If logging is switched on, each change to a table record is recorded in a log
table.


Table Buffering
Single Record Buffering

Generic Buffering (Based on Key Fields)


Full Buffering

Buffers will be by-passed during the following cases in programming:
SELECT BYPASSING BUFFER
SELECT FOR UPDATE
SELECT with aggregate functions like COUNT, MIN, MAX, SUM, AVG etc.,
SELECT DISTINCT
SELECT WHERE IS NULL
SELECT ORDER BY

Indexing
You can search a table for data records that satisfy certain search criteria faster using an index.
An index can be considered a copy of a database table that has been reduced to certain fields.
This copy is always in sorted form. Sorting provides faster access to the data records of the
table, for example using a binary search. The index also contains a pointer to the corresponding
record of the actual table so that the fields not contained in the index can also be read.
The primary index is distinguished from the secondary indexes of a table. The primary index
contains the key fields of the table and a pointer to the non-key fields of the table. The primary
index is created automatically when the table is created in the database.

We can also create further indexes on a table in the ABAP Dictionary. These are called
secondary indexes.

What to Keep in Mind for Secondary Indexes
The indexes on a table should therefore be as disjunct as possible, that is they should contain
as few fields in common as possible. If two indexes on a table have a large number of common
fields, this could make it more difficult for the optimizer to choose the most selective index.

Few constraints while creating Tables:
All key fields of a table must be stored together at the beginning of the table. A non-key
field may not occur between two key fields
A maximum of 16 key fields per table is permitted. The maximum length of a table key is
255
A table may not have more than 249 fields. The sum of all fields length is limited to 1962
(field types LRAW and LCHR are not counted)
Fields of type LRAW and LCHR must be at the end of the table. Only one such field is
allowed per table

Views
Data about an application object is often distributed on several tables. By defining a view, you
can define an application-dependent view that combines this data. The structure of such a view
is defined by specifying the tables and fields used in the view. Fields that are not required can
be hidden, thereby minimizing interfaces. The data of a view is derived from one or more tables,
but not stored physically.


Types of Views
Database Views - are implemented with an equivalent view on the database
Projection Views - are used to hide fields of a table (only projection).
Help Views - can be used as selection method in search helps
Maintenance Views - permit you to maintain the data distributed on several tables for
one application object at one time
Except Database views all other views uses outer join, only database view uses inner join
Basic difference of Inner Join and Outer Join



Join Projection and Selection of Views
This example shows the structure of a view with the relational operators join, projection and
selection
Given two tables TABA and TABB; Table TABA has 2 entries and table TABB has 4 entries.

Each record of TABA is first combined with each record of TABB. If a join condition is not
defined, the cross product of tables TABA and TABB is displayed with the view.

As this is not what is expected, we usually filter the data with Join Conditions

As Field 1 of TABA is identical to Field 3 of TABB, we make a condition on these two fields
TABA-Field 1 = TABB-Field 3, so it removes in-appropriate entries.



Projection if some fields are not of interest to be displayed to the user, then we can hide them
from the view. For ex:



Selection-Conditions further restrict the entries of the view based on the field values.





Maintenance Status

The maintenance status of a view controls whether data records can also be changed or
inserted in the tables contained in the view.

The maintenance status can be defined as follows:

Read only: Data can only be read with the view.
Read, change, delete and add: Data of the tables contained in the view can be
changed, deleted and inserted with the view.


Database Views

A database view provides an application-specific view on distributed data.
Database views are defined in the ABAP Dictionary. A database view is automatically created in
the underlying database when it is activated.

Database views implement an inner join



If the database view only contains a single table, the maintenance status can be used to
determine if data records can also be inserted with the view. If the database view contains more
than one table, you can only read the data.






Projection Views

Projection views are used to hide fields of a table. This can minimize interfaces; for example
when you access the database, you only read and write the field contents actually needed.

A projection view contains exactly one table. You cannot define selection conditions for
projection views.
There is no corresponding object in the database for a projection view. The R/3 System maps
the access to a projection view to the corresponding access to its base table. You can also
access cluster tables with a projection view.




Help Views

You have to create a help view if a view with outer join is needed as selection method for a
search help.

The selection method of a search help is either a table or a view. If you have to select data from
several tables for the search help, you should generally use a database view as selection
method. However, a database view always implements an inner join. If you need a view with
outer join for the data selection, you have to use a help view as selection method.


All the tables included in a help view must be linked with foreign keys. The first table to be
inserted in the help view is called the primary table of the help view. The tables added to this
primary table with foreign keys are called secondary tables.


Maintenance Views
Maintenance views offer easy ways to maintain complex application objects.
Data distributed on several tables often forms a logical unit, for example an application object,
for the user. You want to be able to display, modify and create the data of such an application
object together. Normally the user is not interested in the technical implementation of the
application object, which is in the distribution of the data on several tables.
A maintenance view permits you to maintain the data of an application object together. The data
is automatically distributed in the underlying database tables. The maintenance status
determines which accesses to the data of the underlying tables are possible with the
maintenance view.
All the tables in a maintenance view must be linked with foreign keys, that is the join conditions
for maintenance views are always derived from the foreign key. We cannot directly enter the join
conditions as for database views.
A standardized table maintenance transaction is provided (SM30), permitting us to maintain the
data from the base tables of a maintenance view together.


Structures
A structure comprises of fields. A component can refer to elementary type, other structure, table
or table types.
Structures are used to define the data at the interface of module pools and screens and to
define the parameters of function modules.
There are three types of structures Flat, Nested and Deep


A flat structure references to elementary types.
A nested structure references at least one further structure but not a table type.
A deep structure references at least one table type.


Lock Objects
The SAP System synchronizes simultaneous access of several users to the same data records
with a lock mechanism. When interactive transactions are programmed, locks are set and
released by calling function modules. These function modules are automatically generated from
the definition of lock objects in the ABAP Dictionary.

Structure of a Lock Object
The tables in which data records should be locked with a lock request are defined in a lock
object together with their key fields. When tables are selected, one table (the primary table) is
first selected. Further tables (secondary tables) can also be added using foreign key
relationships

Lock Arguments
The lock argument of a table in the lock object consists of the key fields of the table.
The lock argument fields of a lock object are used as input parameters in the function modules
for setting and removing locks generated from the lock object definition. When these function
modules are called, the table rows to be locked or unlocked are specified by defining certain
values in these fields. These values can also be generic. The lock argument fields therefore
define which subset of the table rows should be locked.

The simplest case of a lock object consists of exactly one table and the lock argument of the
table is the primary key of this table. Several tables can also be included in a lock object. A lock
request therefore can lock an entire logical object, and not only a record of a table. Such a
logical object can be for example a document comprising an entry in a header table and N
entries in a position table.

The name of the lock object (custom development) should always start with EZ or EY. As soon
as the lock object is created two function modules will be created; one for locking (ENQUEUE)
and other for unlocking (DEQUEUE).
Lock Mode - can be assigned for each table in the lock object. This mode defines how other
users can access a locked record of the table.
Types of Locks
Shared Lock (S) - Several users (transactions) can access locked data at the same time
in display mode. A request for another shared lock is accepted, even if it comes from
another user. An exclusive lock set on an object that already has a shared lock will be
rejected.
Exclusive Lock (E) - An exclusive lock protects the locked object against all types of
locks from other transactions. Only the same lock owner can reset the lock
(accumulate).
Exclusive but not cumulative Lock (X) - Exclusive locks can be requested several times
from the same transaction and are processed successively. In contrast, exclusive but not
cumulative locks can be called only once from the same transaction. Each further lock
request will be rejected.
Optimistic Lock (O) - Optimistic locks initially behave like shared locks and can be
converted into exclusive locks.
Life Span of SAP Lock A lock remains set until you either call the corresponding DEQUEUE
function module, or close the transaction with an implicit DEQUEUE_ALL.
Saved locks inherited by the update task are loaded back into the lock table when the system is
started up.
Collision Checks for Locks - The system uses this function to check whether a lock request
collides with an existing lock. If there is a collision, the user of the dialog transaction receives a
message that the object is currently locked by another user. For non-dialog work process (in the
batch input), the lock request is made again at a later time.

1. Write lock ABCD on table TAB1 collides with the existing write lock ABCD on table TAB1.
2. Write lock ABCD on table TAB2 collides with the existing write lock ABCD on table TAB1, is
accepted because lock names are different.
3. Read lock ABCD on table TAB1 collides with the existing read lock ABCD on table TAB1, is
accepted because both are read locks.
4. Write lock ABCD on table TAB1 collides with the existing read lock ABCD on table TAB1.
5. Exclusive lock AB@@ for table TAB1 collides with the existing exclusive lock ABCD for table
TAB1 because @=C and @=D.
6. Exclusive lock ABCD for table TAB1 collides with the existing generic exclusive lock AB@@
for table TAB1 because C=@ and D=@.
7. Write lock @@CD on table TAB1 collides with the existing write lock AB@@ on table TAB1
because @=A, and @=B, and C=@, and D=@ is valid.
8. Write lock @@CDE on table TAB1 collides with the existing write lock AB@@ on table TAB1
because the fifth letter does not match (E not equal to_).
Check for Owner Collision - In the case of a collision between elementary locks, whether the
lock request is accepted or rejected depends on the Owners.
If one of the following conditions is met when elementary locks collide, an owner collision exists:
At least one owner is different.
The owners are identical but at least one lock has mode X (non-cumulative lock)

1. The owners are the same, no locks are in mode X, and therefore there is a collision.
2. Owner_2 is different, therefore there is a collision.
3. Owner_1 is different, therefore there is a collision.
4. Owner_1 is the same, but Owner_2 is different, therefore there is a collision.
5. The owners are the same, no locks are in mode X, therefore there is a collision.
6. The owners are the same, but the lock request is in mode X, therefore there is a collision.
7. The owners are the same, but the existing lock is in mode X, therefore there is a collision.
8. Owner_1 is different, therefore there is a collision.
9. Owner_2 is different, therefore there is a collision.

Search Helps
The input help (F4 help) is a standard function of the R/3 System. The user can display the list
of all possible input values for a screen field with the input help. The possible input values can
be enhanced with further information. This is meaningful especially when the field requires the
input of a formal key.
This standard process can be completely defined by creating a search help in the ABAP
Dictionary. This search help only has to be assigned to the screen fields in which they should be
available.
There are two kinds of Search Helps
Elementary Search Helps - describe a search path. The elementary search help must define
where the data of the hit list should be read from (selection method), how the exchange of
values between the screen template and selection method is implemented (interface of the
search help) and how the online input help should be defined (online behavior of the search
help).
Collective Search Helps - combine several elementary search helps. A collective search
help thus can offer several alternative search paths

Creating Search Helps:


Set the SDis flag if the parameter should be a pure display field in the dialog box for value
selection. The user is thus informed that the contents of the parameter restrict the value, but he
cannot change this restriction. This makes sense for example when the parameter is an import
parameter or if it has a default value.
Modified Flag is used to change the copied data element to a different one of our choice. When
we check this flag, the data element field will be ready for input.
Collective Search Helps:
When you define a collective search help, you have to specify only the search helps that are to
be combined in the collective search help. In the input help, the values are transported between
the selected elementary search help and the input template using the collective search help.
This is the reason why a collective search help also has an interface for transporting the values.
A collective search help comprises several elementary search helps. It combines all the search
paths that are meaningful for a field.
Note:
The interface parameters (import and export parameters) of the included search helps must be
assigned to the parameters of the collective search help. Not all of the parameters need to be
assigned, that is, the assignment can be open for some of the parameters. This is explained by
an example in the following figure.

ABAP Workbench Tools
The tools in the Workbench are integrated. For example, when you are working on a program,
the ABAP Editor will also recognize objects created using other tools. This integration means if
you double-click an object, the Workbench automatically launches the tool that was used to
create the object.
SAP has developed the Object Navigator to help you to organize your application development
in this integrated environment. It provides a context that makes it easier for you to trace the
relationships between objects in a program. Rather than working with tools and packages, you
work with objects and allow the Workbench to launch the appropriate tool for an object.

Object Navigator SE80
ABAP Editor SE38
Function Builder SE37
Class Builder SE24
Screen Painter SE51
Menu Painter SE41
Split Screen Editor SE39
Transformation Editor XSLT
Messages SE91
Transactions SE93
ABAP Web Dynpro using SE80
Business Add-in (BADI) SE18 / SE19
Packages SE21
Logical Database SE36
Data Dictionary SE11
SAP Scripts SE71
Smart Forms SMARTFORMS
Adobe Forms SFP
Customer Exits CMOD
SAP Enhancement Viewer SMOD
Runtime Analysis SE30 / SAT
System Traces ST01

Position of ABAP in SAP R/3
The following figure illustrates three different views of the R/3 system, which shows the role of
the ABAP workbench.

Logical View



Software Oriented View

The R/3 system supports the following database systems like ADABAS D, DB2/400 (on AS400),
DB2/Common Server, DB2/MVS, Informix, Microsoft SQL Server, Oracle, and Oracle Parallel
Server, SAP HANA.

Dialog Step the program logic in an application program that occurs between two screens is
known as dialog step


User Oriented View

Work Processes
Work processes execute the individual dialog steps in R/3 applications. The next two sections
describe firstly the structure of a work process, and secondly the different types of work process
in the R/3 System.

Structure of Work Process:
Work processes execute the dialog steps of application programs. They are components of an
application server. The following diagram shows the components of a work process:

Each work process contains two software processors and a database interface.
Screen Processor:
In R/3 application programming, there is a difference between user interaction and processing
logic. From a programming point of view, user interaction is controlled by screens. As well as
the actual input mask, a screen also consists of flow logic. The screen flow logic controls a large
part of the user interaction. The R/3 Basis system contains a special language for programming
screen flow logic. The screen processor executes the screen flow logic. Via the dispatcher, it
takes over the responsibility for communication between the work process and the SAPgui, calls
modules in the flow logic, and ensures that the field contents are transferred from the screen to
the flow logic.

ABAP Processor:
The actual processing logic of an application program is written in ABAP - SAPs own
programing language. The ABAP processor executes the processing logic of the application
program, and communicates with the database interface. The screen processor tells the ABAP
processor which module of the screen flow logic should be processed next. The following
screen illustrates the interaction between the screen and the ABAP processors when an
application program is running.



Database Interface:
The database interface provides the following services:
Establishing and terminating connections between the work process and the database.
Access to database tables
Access to R/3 Repository objects (ABAP programs, screens and so on)
Access to catalog information (ABAP Dictionary)
Controlling transactions (commit and rollback handling)
Table buffer administration on the application server.
The following diagram shows the individual components of the database interface:

The above diagram shows two different ways of accessing the database Native SQL and
Open SQL.
Open SQL statements are a subset of Standard SQL that is fully integrated in ABAP. They allow
you to access data irrespective of the database system that the R/3 installation is using. Open
SQL consists of the Data Manipulation Language (DML) part of Standard SQL; in other words, it
allows you to read (SELECT) and change (INSERT, UPDATE, DELETE) data. The tasks of the
Data Definition Language (DDL) and Data Control Language (DCL) parts of Standard SQL are
performed in the R/3 System by the ABAP Dictionary and the authorization system. These
provide a unified range of functions, irrespective of database, and also contain functions beyond
those offered by the various database systems.
Native SQL is only loosely integrated into ABAP, and allows access to all of the functions
contained in the programming interface of the respective database system. Unlike Open SQL
statements, Native SQL statements are not checked and converted, but instead are sent directly
to the database system. Programs that use Native SQL are specific to the database system for
which they were written. R/3 applications contain as little Native SQL as possible. In fact, it is
only used in a few Basis components (for example, to create or change table definitions in the
ABAP Dictionary).

Types of Work Processes:
Although all work processes contains the components as shown above, they can still be divided
into different types. The type of a work process determines the kind of task for which it is
responsible in the application server. It does not specify a particular set of technical attributes.
The individual tasks are distributed to the work processes by the dispatcher.
Before you start your R/3 System, you determine how many work processes it will have, and
what their types will be. The dispatcher starts the work processes and only assigns them tasks
that correspond to their type. This means that you can distribute work process types to optimize
the use of the resources on your application servers.
The following diagram shows again the structure of an application server, but this time, includes
the various possible work process types:



Dialog Work Processes deal with requests from an active user to execute dialog steps.
Update Work Processes execute database update requests. Update requests are part of an
SAP LUW that bundle the database operations resulting from the dialog in a database LUW for
processing in the background.
Background Work Processes process programs that can be executed without user interaction
(background jobs).
Enqueue Work Process administers a lock table in the shared memory area. The lock table
contains the logical database locks for the R/3 System and is an important part of the SAP LUW
concept. In an R/3 System, you may only have one lock table. You may therefore also only have
one application server with enqueue work processes.
Spool Work Process passes sequential datasets to a printer or to optical archiving. Each
application server may contain only one spool work process.
The services offered by an application server are determined by the types of its work processes.
One application server may, of course, have more than one function. For example, it may be
both a dialog server and the enqueue server, if it has several dialog work processes and an
enqueue work process.
You can use the system administration functions to switch a work process between dialog and
background modes while the system is still running. This allows you, for example, to switch an
R/3 System between day and night operation, where you have more dialog than background
work processes during the day, and the other way around during the night.

Structure of an ABAP Programs
ABAP processing logic is responsible for processing data in R/3 application programs. ABAP
was designed specifically for dialog-oriented database applications. The following sections deal
with how an ABAP program is structured and executed.
Program Structure
ABAP programs are responsible for data processing within the individual dialog steps of an
application program. This means that the program cannot be constructed as a single sequential
unit, but must be divided into sections that can be assigned to the individual dialog steps. To
meet this requirement, ABAP programs have a modular structure. Each module is called a
processing block. A processing block consists of a set of ABAP statements. When you run a
program, you effectively call a series of processing blocks. They cannot be nested.
The following diagram shows the structure of an ABAP program:

Program Types and Execution
Type 1 (executable) programs have the important characteristic that they do not have to be
controlled using user-defined screens. Instead, they are controlled by the runtime environment,
which calls a series of processing blocks (and selection screens and lists where necessary) in a
fixed sequence. User actions on screens can then trigger further processing blocks.
Type 1 programs can be executed using a transaction code or by entering the program name in
ABAP Editor or Object Navigator. This is why we refer to type 1 programs as Executable
Programs.
Type M (module pool) the most important technical attribute of a type M program is that it can
only be controlled using screen flow logic. You must start them using a transaction code, which
is linked to the program and one of its screens (initial screen). Another feature of these
programs is that you must define your own screens in the Screen Painter (although the initial
screen can be a selection screen).
Type F (function group) programs are containers for function modules, and cannot be started
using a transaction code or by entering their name directly. Function modules are special
procedures that you can call from other ABAP programs.
Type F programs are known as function groups. Function modules may only be programmed in
function groups. The Function Builder is a tool in the ABAP Workbench that you can use to
create function groups and function modules. Apart from function modules, function groups can
contain global data declarations and subroutines. These are visible to all function modules in the
group. They can also contain event blocks for screens in function modules.
Type K (class pool) you cannot start type K programs using a transaction code or by entering
the program name. They are containers for global classes in ABAP Objects . Type K programs
are known as class definitions. The Class Builder is a tool in the ABAP Workbench that you can
use to create class definitions.
Type J (interface pool) you cannot start type J programs using a transaction code or by entering
the program name. They are containers for global interface in ABAP Objects . Type J programs
are known as interface definitions. Like class definitions, you create interface definitions in the
Class Builder.
Type S (sub-routine) you cannot start a type S program using a transaction code or by entering
the program name. Instead, they are containers for subroutines, which you can call externally
from other ABAP programs. Type S programs are known as subroutine pools. They cannot
contain screens.
Type I (include programs) programs - called includes - are a means of dividing up program code
into smaller, more manageable units. You can insert the coding of an include program at any
point in another ABAP program using the INCLUDE statement. There is no technical
relationship between include programs and processing blocks. Includes are more suitable for
logical programming units, such as data declarations, or sets of similar processing blocks. The
ABAP Workbench has a mechanism for automatically dividing up module pools and function
groups into include programs.

Processing Blocks in ABAP Program
The following set of screens shows different kinds of processing blocks in ABAP Programs.

Dialog Modules we call dialog modules from the screen flow logic (screen command
MODULE). You can write a dialog module in an ABAP program for each state (PBO, PAI; user
input) of any of the screens belonging to it. The PAI modules of a screen together with the PBO
modules of the subsequent screen form a dialog step. The interaction between the flow logic
and the screen is controlled by a dialog processor.
Dialog modules are introduced with the MODULE statement and concluded with the
ENDMODULE statement.



Event Blocks for Selection Screens a selection screen is a special kind of dialog screen that
you create using ABAP commands in the declaration part of the program. The different events
in a selection screen (PAI, PBO, user input), are controlled by a selection screen processor.
You can program processing logic for these events in your program. The selection screen
processor controls the flow logic of the selection screen.

We do not have to create the screen flow logic our self; neither can we create our own dialog
modules for the PBO or PAI events. Data is passed between selection screen and ABAP
program using the fields (parameters and selection tables) which we create in the selection
screen definition in the declaration part of the ABAP program.

Event Blocks for Lists - lists are special screens which output formatted data. You can create
them in any processing block in an ABAP program using a special set of commands (such as
WRITE, NEW-PAGE and so on). The list processor displays the list on the screen and handles
user actions within lists. The list processor controls the flow logic of the list. You do not have to
create the screen flow logic yourself, neither can you create your own dialog modules for the
PBO or PAI events.

Event Blocks for Executable Programs - When you run an executable program (type 1), it is
controlled by a predefined process in the runtime environment. A series of processors is called,
one after the other. These processors trigger events, for which you can define event blocks.
Type 1 programs are event-driven.

The process is as follows:
The runtime environment creates the INITIALIZATION event and calls the corresponding
event block (if it has been defined in the ABAP program).
If there is a selection screen defined in the program, control returns to the selection
screen processor. This generates the corresponding events and calls their event blocks.
Control then passes to the reporting processor. It creates the START-OF-SELECTION
event and calls the corresponding event block (if it has been defined in the ABAP
program).
The logical database, if you are using one, calls further event blocks at this point.
The reporting processor creates the END-OF-SELECTION event and calls the
corresponding event block (if it has been defined in the ABAP program).
If the program contains a list description, control now passes to the list processor. The
list processor displays the list defined in the ABAP program. It converts user actions on
the list into events and calls the corresponding event blocks.

Subroutines we call subroutines from ABAP programs using the PERFORM statement.
Subroutines are introduced with the FORM statement and concluded with the ENDFORM
statement.

We can define subroutines in any ABAP program. You can either call a subroutine that is part of
the same program or an external subroutine, that is, one that belongs to a different program. If
you call an internal subroutine, you can use global data to pass values between the main
program and the subroutine. When you call an external subroutine, you must pass actual
parameters from the main program to formal parameters in the subroutine.

Memory Structure of an ABAP Program
In the Overview of the R/3 architecture we have seen that each user can open up to six R/3
windows in a single SAP GUI session. Each of these windows corresponds to a session on the
application server with its own area of shared memory.
The first application program that you start in a session opens an internal session within the
main session. The internal session has a memory area that contains the ABAP program and its
associated data. When the program calls external routines (methods, subroutines or function
modules) their main program and working data are also loaded into the memory area of the
internal session.
Only one internal session is ever active. If the active application program calls a further
application program, the system opens another internal session. Here, there are two possible
cases: If the second program does not return control to the calling program when it has finished
running, the called program replaces the calling program in the internal session. The contents of
the memory of the calling program are deleted. If the second program does return control to the
calling program when it has finished running, the session of the called program is not deleted.
Instead, it becomes inactive, and its memory contents are placed on a stack.
The memory area of each session contains an area called ABAP memory. ABAP memory is
available to all internal sessions. ABAP programs can use the EXPORT and IMPORT
statements to access it. Data within this area remains intact during a whole sequence of
program calls. To pass data to a program which you are calling, the data needs to be placed in
ABAP memory before the call is made. The internal session of the called program then replaces
that of the calling program. The program called can then read from the ABAP memory. If control
is then returned to the program which made the initial call, the same process operates in
reverse.
All ABAP programs can also access the SAP memory. This is a memory area to which all
sessions within a SAPgui have access. You can use SAP memory either to pass data from one
program to another within a session, or to pass data from one session to another. Application
programs that use SAP memory must do so using SPA/GPA parameters (also known as
SET/GET parameters). These parameters are often used to preassign values to input fields.
You can set them individually for users, or globally according to the flow of an application
program.
SAP memory is the only connection between the different sessions within a SAPgui.
The following diagram shows how an application program accesses the different areas within
shared memory:

In the diagram, an ABAP program is active in the second internal session of the first main
session. It can access the memory of its own internal session, ABAP memory and SAP
memory.
The program in the first internal session has called the program which is currently active, and its
own data is currently inactive on the stack. If the program currently active calls another program
but will itself carry on once that program has finished running, the new program will be activated
in a third internal session.

Creating Programs with ABAP
The name of an ABAP program can be between 1 and 30 characters long. It cannot contain any
of the following characters: Period (.), comma (,), space (), parentheses (), apostrophe (),
inverted commas (), equals sign (=), asterisk (*), accented characters or German umlauts (, ,
, , , and so on), percentage signs (%), or underscores (_).
Program Attributes Like many other Repository objects, ABAP programs have attributes,
which are important in determining the function of the program within the R/3 System.
Source Code ABAP source code defines the processing logic of R/3 application programs. For
an introduction to writing source code,

Program Structure
The following gives a short overview on how to structure a program. Apart from the first
statement, the sequence of statements is not obligatory, but you should keep to it for reasons of
clarity and readability.
The first statement of an ABAP program must always be the statement REPORT or
PROGRAM, respectively (only exception: FUNCTION-POOL for function modules). Both
statements have exactly the same function. The name specified in the statements
REPORT and PROGRAM must not necessarily be the program name, but for
documentation reasons, you should use the correct name. The statements REPORT or
PROGRAM can have several options, such as LINE-SIZE, LINE-COUNT, or NO
STANDARD PAGE HEADING. You use these options mainly in programs that which
evaluate data and display the results in a list. For other options, such as the definition of
a message class, see the key word documentation. Whenever you create a new
program, the system automatically inserts the first ABAP statement, for example:
REPORT <name>. for executable programs (reports) or PROGRAM <name>. for dialog
programs

Data Declaration - This includes the global data definitions, selection screen definitions,
and the definitions of classes and interfaces in ABAP Objects

Processing Logic - After the declarations, write the processing logic. This consists of a
series of processing blocks.

Subroutines - At the end of your program, include its internal procedures (subroutines
and methods).



Saving and Activating Programs
Choose Save to save the source code.
The system stores the source code in the program library. Before you can execute the program
from outside the ABAP Editor, you must generate an active version using the Activate function.

Types and Objects
ABAP distinguishes between types and objects. Types are descriptions that do not occupy
memory. Objects are instances of types, and do occupy their own memory space. A type
describes the technical attributes of all of the objects with that type.
ABAP types form a hierarchy. Objects in ABAP reflect the same hierarchy.


Data Types and Data Objects
Programs work with local data. Data consists of strings of bytes in the memory area of the
program. A string of related bytes is called a field. Each field has an identity (a name) and a
data type. All programming languages have a concept that describes how the contents of a field
are interpreted according to the data type.
In the ABAP type concept, fields are called data objects. Each data object is an instance of an
abstract data type. Data types in ABAP are not just attributes of fields, but can be defined in
their own right. There are separate name spaces for data objects and data types. This means
that a name can at the same time be the name of a data object as well as the name of a data
type.

The following picture shows where we can define data types in ABAP

Pre-defined data types are the ones defined in the Kernel
Local types can be defined in the program
Data types in dictionary are available to all programs in the entire system. In the ABAP
Dictionary, you can define types either as Dictionary objects or in type groups.

Pre-Defined ABAP Types
These are pre-defined in the R/3 Kernel system and are visible in all ABAP Programs. We can
use pre-defined types to define data types and objects in a program to hold the data at run time.
Pre-Defined Elementary types with Fixed Length - following predefined elementary
data types are used to specify the types of individual fields whose lengths are always
fixed at runtime.
The following table shows the different fixed-length data types. All field lengths are
specified in bytes.

o Integers - type I - The value range of type I numbers is -2**31 to 2**31-1 and
includes only whole numbers. Non-integer results of arithmetic operations (e.g.
fractions) are rounded, not truncated. We can use type I data for counters,
numbers of items, indexes, time periods, and so on.
o Packed numbers - type P - Type P data allows digits after the decimal point.
The number of decimal places is generic, and is determined in the program. The
value range of type P data depends on its size and the number of digits after the
decimal point. The valid size can be any value from 1 to 16 bytes. Two decimal
digits are packed into one byte, while the last byte contains one digit and the
sign. Up to 14 digits are allowed after the decimal point. The initial value is zero.
When working with type P data, it is a good idea to set the program attributes to
fixed point arithmetic. Otherwise, type P numbers are treated as integers. You
can use type P data for such values as distances, weights, amounts of money,
and so on.
o Floating point numbers - type F - The value range of type F numbers is 1x10**-
307 to 1x10**308 for positive and negative numbers, including 0 (zero). The
accuracy range is approximately 15 decimals, depending on the floating point
arithmetic of the hardware platform. Since type F data is internally converted to a
binary system, rounding errors can occur. Although the ABAP processor tries to
minimize these effects, you should not use type F data if high accuracy is
required. Instead, use type P data. You use type F fields when you need to cope
with very large value ranges and rounding errors are not critical.


Pre-Defined Elementary ABAP Types with Variable Length - These predefined
elementary data types are used to specify the types of individual fields whose lengths
are not fixed until runtime. There are two predefined ABAP data types with variable
length that are generically known as strings:

o STRING for character strings - A string is a sequence of characters with variable
length. A string can contain any number of alphanumeric characters. The length
of a string is the number of characters multiplied by the length required for the
internal representation of a single character.
o XSTRING for byte strings - A byte string is a hexadecimal type with variable
length. It can contain any number of bytes. The length of a byte string is the
same as the number of bytes.