What Is ABAP?

The R/3 kernel (system

runtime environment)
itself is written in standard
C or C++.

But application programs

running inside R/3 are
written using SAP's
proprietary programming
language ABAP (pronouced
as ahhh-bap).

Note: the "/4" in "ABAP/4"

has been dropped over the
confusion that the "4"
referred to "R/4", which
doesn't exist.

Netweaver AS (Application
Server) combines which
SAP calls two
"personalities" because
WebDynpro (pronouced
"web din pro") for ABAP
and WebDynpro for Java
use the same meta model.
WebDynpro components,
views, models, and
controllers have the same
semantics in both ABAP
and Java.

The main difference is the

design-time environment,
the development
infrastructure, and the
run-time environment.
Different Types of ABAP object programs
Introduced
ABAP
with first Called using Can do
Program Type
part
1 (one) = REPORT SUBMIT (LEAVE started by
Executable TO entering the
TRANSACTION) & program name
or using a
SUBMIT AND transaction
RETURN (CALL code; can
TRANSACTION) have its own
screens.
M = Module (in PROGRAM only by Can be called
Module Pool) (using transaction code: using tcode or
Transaction menu. Have
Maintenance CALL their own
transaction TRANSACTION or dialog
SE93) screens.
LEAVE TO
TRANSACTION;
S = Interface PROGRAM non executable cannot have
Definition container its own
Subroutine programs for screens.
pools sub-routines
called externally
F = Function FUNCTION- non executable can have its
Group POOL container for own screens.
function
modules.
K = Class CLASS-POOL non executable cannot have
Definition container for its own
(container classes. screens.
programs for
 global classes)
J = Interface CLASS-POOL non executable cannot have
Definition TABLES container for its own
(container interfaces. screens.
programs for
global
interfaces)
T = Type TYPE-POOL non executable cannot have
Groups container for its own
type definitions. screens.
I = Include none INCLUDE -
Program non statement.
executable
container for
modularizing
ABAP source
code.
Transports and Packages

When an ABAP module is first created, it is stored as an inactive

local object in a $TMP temporary transport.

With ABAP, deployment of components are organized as

Transport definitions.

Objects need to be activated for editing.

Screens

To invoke the Screen Painter tool, use tcode SE51 or from the
Object Navigator tool.

Screen attributes include its number (default to 0100 for the first
screen), short description, subsequent screen number, and type
of screen:

o normal
o subscreen
o modal (pop-up) dialog box
o selection

Goto Layout (placement) of screen elements (text label,

 input/output edit fields, text boxes, push buttons, radio buttons,
etc.).

Goto Secondary window to set Attributes for each field screen

element in the Element List (Dict. data type (such as numbers
only), format, length, etc..

Flow logic is determined by ABAP program source code events

and keywords:

o TOP where globals are defined.

o PROCESS BEFORE OUTPUT. (PBO) to display screen
o PROCESS AFTER INPUT. (PAI)
o PROCESS ON HELP-REQUEST. (POH) when F1 is pressed

o PROCESS ON VALUE-REQUEST. when F4 is pressed

Command summary
Operation Commands Description
Object MOVE variable1 TO -
assignment variable2 assigns values to
data objects to a variable. It
works like the equal sign
(=).
MOVE-CORRESPONDING ...
TO ...
WRITE TO passes values to
variables (mainly to fill
character fields).
CLEAR resets a data object
to the initial value
appropriate to its data type.
Numeric compute var3 = var1 - var2 -
operations subtract var2 from var1
add var1 to var2
divide var1 by var2
multiply var1 by var2
Individual MODULE, PERFORM, CALL These create a
modularization FUNCTION, new user
units CALL SCREEN, context:
 CALL TRANSACTION,
CALL DIALOG,
SUBMIT (CALL FUNCTION IN
UPDATE TASK,
CALL FUNCTION IN
BACKGROUND TASK,
CALL FUNCTION STARTING
NEW TASK)
database access SELECT * INTO TABLE -
tableB FROM dbTableA.
endselect.
EXEC SQL
Internal table APPEND, -
operations COLLECT,
READ TABLE�WITH KEY�,
INSERT ... INDEX ...
SORT,
BINARY SEARCH
delete internal REFRESH, -
tables and release FREE
memory

Programming Logic contrasts ABAP with other programing

languages' conditional (IF/ELSE/LOOP) statements.

ULINE requests a line break in the output.

Workbench

WebDynpro application components are created and modified

within the WebDynpro Explorer within the ABAP Workbench
access from Tools > ABAP Workbench > Overview > (within the
Application Hierarchy) SE80 > - Object Navigator
 The Workbench stores its assets (such as MIME definitions and
ABAP development objects (packages, programs, functions) in a
persistent Repository.

ABAP Workbench organization of tools:

• Development Function Builder, Screen Painter, Menu Painter)

SE11 ABAP Data Dictionary (DDIC)

User Interface:

SE38 ABAP Editor

SE51 Screen Painter
SE41 Menu Painter (to define GUI status of Menu bar,
app. toolbar, function keys)
SE37 Function Builder
SE24 Class Builder
SE37 Function Builder
SE33 Context Builder

Programming Environment:
 SW01 Business Object Builder

• Debugging

ST05 SQL Trace

SE30 Run Time Analysis (of memory usage) On Line
Debugger to view variables while stepping through a
program,
SM21 System Log

• Navigation (Application Hierarchy,

SE80 Object Navigator

SE84 ABAP Repository Information System
SE16 Data Browser

• Organizing

SE09 Transport System to make moves requested using

Workbench Organizer

ABAP Editor

ABAP Workbench is the IDE SAP supplies to edit, compile, and

run ABAP programs.

An ABAP program defines and maniulates data using statements

of specific syntax.

XML-based info objects can only be edited in the Knowledge

Workbench.

ABAP Data Dictionary (DDIC)

The ABAP Dictionary contains:

o table type
o tables
o views
o data elements
o domains (value ranges)
o structures (hierarchy)
o lock objects
 o online help information
o search help information

Each field in the DD is based on a built-in DD data type or a Data

Element (which in turn is based on a Domain).

The Data Element contains the more semantical information (text

and documentation).
The Domain defines the basic technical attributes:

o Data type, length, number of decimals -- essential for

dealing with fields correctly and building nice user interfaces
that are aware of the field attributes.
o Check table -- a separate table such as country name
associated with a country code.
o Fixed values -- information about codes stored in the
Domain (not in a separate table).
o Conversion exit -- in SAPGUI to translate between internal
and external representations of data, because most BAPIs
return and expect the internal format, which makes little to
no sense to users.
o Texts and documentation: SAP stores multiple texts per
field and also extended documentation in many cases. This
documentation is available in all installed languages and
therefore an easy way to provide multi-lingual capabilities
in applications.
o Mixed case support. Indicates to the users which fields are
uppercase only. Many text fields in SAP are uppercase only.

SAPscript and forms

A SAPscript form is a
template that supplies
the layout (for example,
page size) and content
(for example, sales data
for an invoice) for
business forms.

SAPscript print program

is needed to print,
distribute, or display
 business forms.

A form is made up of
pages, which contains
several windows (header,
address, main, etc.). Text
elements are formatted
with paragraph formats
(which define font and
tab positions) and
character formats (such
as bold).

Create a view for the

component. This calls the
Layout tab and creates
the root element in the UI
Element Hierarchy. See
the view in the browser
by embedding it actively
in a WebDynpro window.

Activate "Accessibility
Checks Active" by clicking
on the checkbox.

Classic Sections and Events

Classic ABAP programs are made up of self-contained sections

(containing block of code) which cannot be nested. Events in
ABAP report programs are executed in a predefined sequence.

1. INITIALIZATION.
2. SELECTION-SCREEN.
3. START-OF-SELECTION. where select statements retrieve
data.
4. TOP-OF-PAGE.
5. END-OF-PAGE.
6. END-OF-SELECTION.

Bolded events are only for ABAP report programs.

• Even though code sections can be specified in any order, it's

 better to keep this sequence.
Code for an event ends when the next event name is specified.
The STOP command causes (at runtime) a jump to the next
section.

ABAP Functionality

The functionality of an
ABAP program
include:

o Receive
requests and
messages.
o Present user
interface (title
bar, menu bar,
standard &
application
toolbars,
function keys).
o Present screen
elements
(iViews push
bottons, radio
buttons,
checkboxes,
input fields,
scroll fields).
o Obtain user
input in fields,
mouse
movements,
etc.
o Make
calculations and
edits.
o Access
databases.
o web services
(send
responses).
 o Log activities.

o Exit.
Classic Sections and Events

Classic ABAP programs are made up of self-contained sections

(containing block of code) which cannot be nested. Events in
ABAP report programs are executed in a predefined sequence.

1. INITIALIZATION.
2. SELECTION-SCREEN.
3. START-OF-SELECTION. where select statements retrieve
data.
4. TOP-OF-PAGE.
5. END-OF-PAGE.
6. END-OF-SELECTION.

Bolded events are only for ABAP report programs.

Even though code sections can be specified in any order, it's

better to keep this sequence.
Code for an event ends when the next event name is specified.
The STOP command causes (at runtime) a jump to the next
section.
Classic Data Declaration
DATA DECLARATION. Defines:
data i(8) type n value 0.
data final type c value 'literal'.
parameters x(15) type c.
select-options Number for x.

Data are stored in data objects: modifiable field strings,

variables and internal tables or non-modifiable literals and
constants.
Classic List Handling

Interactive report
programs provide menus
for user interaction. When
the user clicks on a row
within a basic list created
using a select statement
within the start-of-
selection section, code
 under section at line-
selection. is invoked to
create a secondary list.

When the user selects a

row and clicks a defined
PF key (i.e., Shift+F12),
code under section at
pf24. is invoked. Because
most PC keyboards have
12 F keys:

13 = Shift F1
14 = Shift F2
15 = Shift F3
16 = Shift F4
17 = Shift F5
18 = Shift F6
19 = Shift F7
20 = Shift F8
21 = Shift F9
22 = Shift F10
23 = Shift F11
24 = Shift F12

When the user selects a

row and clicks the Enter
key, code under section
at user-command. is
invoked.

at user-
command.
if sy-ucomm=20 .

get cursor Field f Value

v. retrieves the field
name and value of where
the user has placed his
cursor.
Object-Oriented Coding

Object-oriented ABAP coding defines events (with only exporting

 parameters) and handler this way:
ABAP Internal Tables

ABAP report programs obtains results from database queries from

temporary internal tables on WebAS server memory.

For example, to define two internal tables with a capacity of 53

records:

data : begin of tableA occurs 100 with header line.

field 1 (c) (like databasefield1 ).
field 2 (c) (like databasefield2 ).
end of tableA.
data : begin of tableB like tableA occurs 100.

To modify data from the internal table:

modify tableA index i.

To read data from internal table:

loop at tableA from 50 to 100.

modify tableA .
" code to display data on the screen.
endloop .
Contexts

To avoid unnecessary system load from repeating calculations,

define contexts in the Context Builder within ABAP Workbench.

Application programs work with instances of a context. SUPPLY

input values for key fields and DEMAND derived data.

Each context has a cross-transaction buffer on the application

server. When you query an instance for values, the context
program searches first of all for a data record containing the
corresponding key fields in the appropriate buffer. If one exists,
the data is copied to the instance. If one does not exist, the
context program derives the data from the key field values
supplied and writes the resulting data record to the buffer.

Class inheritance (Vererbung) is achieved using

CLASS <subclass> DEFINITION INHERITING FROM <superclass>.
Data Types

The largest ABAP datatype holds 65,535 characters.

ABAP UIs

The standard Web user interface is WebDynpro.

The SAP R/3 Style Guide maintained by the SAP Design Guild
provides standards for accessible user interaction design of
functions, UI elements (Screens, application and task menus,
Fields, Checkboxes, Radio Buttons, Drop-Down List Boxes, Lists,
Tables, Trees), hot keys, and presentation of dialogues and texts.

Business Server Pages (BSP) provides a high degree of

adjustment for Web interface.

Java Development

Java Development Infrastructure

WebDynpro ABAP

WebDynpro Java

SAP's Documentation for SAP Getting Started with Netweaver

2004s, 2004, and 6.30.

SAP Interactive Forms by Adobe Overview

ABAP WebDynpro Development Processes
Process Process Description
Modeling 1. Provide business logic APIs.
2. Structure development projects in packages.
3. Create (reusable) WebDynpro components.
4. Model user navigation.
5. Model Portal navigation.
Developing 6. Create and implement controllers and define
contexts.
7. Design of views, define layouts and bind to
contexts.
8. Define WebDynpro applications.
9. Execute testing and debugging.
Configuring 10. Provide component configurations.
 11. Combine WebDynpro components with
WebDynpro application configurations.
12. Execute functional tests.
13. Include WebDynpro applications to Portal iViews
and roles.
Adapting 14. Adapt configuration settings.
15. Enhance or modify WebDynpro components.
16. Internationalization of WebDynpro ABAP
components.
17. Execute end-user and load testing.
18. Configure and personalize WebDynpro
application in the Portal.
Upgrading 19. Merge new developments into productive
applications.
20. Execute end-user testing.
ABAP Persistence

Access to the R/3 System database is made using OPEN SQL

statements in the PUT_<TABLE> subroutines. Data is passed to
the executable program using interface work areas defined using
the TABLES statement. Once the data has been read in the logical
database program, the executable program (report) can process
the data in the GET event blocks. This technique separates data
reading and data processing.

ABAP programmers do not need to open and close database

connections since every ABAP program automatically receives an
open connection to the central database in the system.

ABAP Objects contain Open SQL, SAP's platform-independent

SQL dialect as a direct component of the language.

Accesses to data in the database are synchronized by the runtime

system's lock mechanism which prevents two parallel transactions
from being able to change the same data in the database.

The logic in SAP's Update System avoids database rollback.

To avoid keeping the database waiting, SAP maintains its own

LUW (logical units of work) that spans several screens and
several database LUW.
 Update Management (transaction SM13) Monitoring Updates
Analyzing and correcting update errors

• Update Management (transaction SM13)

• Monitoring Updates

• Analyzing and correcting update errors

eCATT

eCATT (extended Computer Aided Test Tool - BC-TWB-TST-ECA) was

available since release 6.20 and superceded CATT as of Web
Application Server Release 6.40.

SAP supplies it free as part of the R/3 system to document manual

user dialog steps and to record, edit, and execute automated
functional test cases without user dialog.

eCATT can be used with the Test Workbench.

Transactions executed through eCATT require the same authorizations

as manual operation by a live person, so eCATT can be used to verify
user profiles.

In principle, the entire ABAP instruction set is available for use within
inline ABAP code (CREATE, CALL, DATA, SUBMIT, etc.).

eCATT stores its data in R/3 databases and can be controlled by Test
Workbench, the Object Navigator (SE80), or externally through the
BC-eCATT interface.

Test modules can refer to spreadsheets providing various data that are
updated in CATT Maintenance mode.

Logs are created while test modules run.

However, eCATT is less suited for testing lists and display results,
menu paths, online help (F1, F4), free-form editor functions, and
transactions that contain the statement LEAVE TO TRANSACTION.

ABAP Trace

ABAP trace measures the

run times of various ABAP
commands:

1. To avoid tracing the

buffer load process,
execute the
functional sequence
before beginning
trace.
2. Command ST12 or
System > Utilities >
Runtime analysis >
Execute,
at the ABAP
Runtime Analysis:
Initial Screen, Turn
ABAP trace switch
on for an R/3
transaction code,
ABAP program
name, or R/3
function module.
Filtered
3. Perform functional
actions while SAP
captures
measurements into
a file it creates.
4. Analyze
measurement
results:

Overview shows the

gross and net
execution times of a
program call in
microseconds.

gross time is
the total time
required for
the call, which
includes times
of all
 modularization
units and
ABAP
statements

net time is
the gross time
minus the
time required
for the called
modularization
units and for
separately
specified ABAP
statements

For
statements
such as
APPEND, the
gross time
equals the net
time

If the gross
time differs
from the net
times for such
statements,
the call
contains other
calls or
modularization
units

hit list displays the

individual
components of each
call.
Hit list displays the
execution time in
microseconds for
each statement
 executed by the
program or
transaction, sorted
in decreasing order
of the gross times.

Tables hit list lists

database tables
accessed by the
transaction or
program.

Group hit list

displays ABAP trace
results grouped by
modularization unit.

Call hierarchy
displays statements
in chronological
order of execution.
Efficient ABAP Coding Strategies

• After each BAPI call, check the message that came back to see
whether the BAPI call was successful. All BAPIs are supposed to
use a RETURN parameter instead of throwing ABAP exceptions.
However, different BAPIs use different structures with different
field names for the RETURN parameter.
• Be smart about the amount of data retrieved from the database.

Specify SQL to retrieve the least amount of data from the

database, such as requesting only enough data to fit on a page
presented to the user. This reduces memory and network
bandwidth consumption.

However, it may be more efficient to make one call is the user's

task is make a decision (not just to refine the search).

One important technique is to save the values each user provided

for previous searches (such as the user's own department
number, etc.) and present them to the user automatically.

RFCs
 sRFC Synchronous Used by CALL FUNCTION
RFC most BAPI DESTINATION
clients
aRFC Asynchronous - CALL FUNCTION STARTING
(Parallel) RFC NEW TASK
tRFC Transactional transfer ALE CALL FUNCTION IN
RFC Used to (Application BACKGROUND TASK
save function Link
calls in one Enabling)
LUW (Logical Intermediate
Units of Work) Documents
and start the (IDocs)
LUW afterward
asynchronously.
qRFC Queued - CALL FUNCTION
synchronized "TRFC_SET_QUEUE_NAME"
RFC in a +
specified CALL FUNCTION IN
sequence BACKGROUND TASK
through
QIN/QOUT
queues used
within a 3-
phase process.
RFC RFC with SAP - -
with GUI support
dialog (dialog step)

RFMs and BAPIs

ABAP Function Modules can only be called from an external client

if they are marked as RFC-enabled.

BAPIs are RFMs that follow additional rules (as defined in the SAP
BAPI Programming Guide) and are defined as object type
methods in SAP's Business Object Repository (BOR).

RFMs are also used to define ABAP exceptions -- a string such as

"NOT_FOUND" with an associated language-dependent message
text.
 Transaction codes BAPI and SE37 provide metadata for the
several thousand SAP R/3 BAPIs and other RFMs (RFC-enabled
Function Modules) in its Interface Repository. Some of them are
in "unreleased" (unsupported) state. SAP only guarantees
released BAPIs to be upward-compatible When SAP wants to
change a BAPI in a way that would be incompatible with the
existing version, they create a new BAPI and mark the old name
obsolete.

Find suitable BAPIs using the BAPI Explorer (transaction BAPI),

then review the metadata of the RFM in the Function Builder
(transaction code SE37).

RFMs have three types of parameters:

o import (the client sends these to the RFM),

o export (RFM sends these back to the client), and
o tables (bi-directional).

Import and export parameters can be simple (scalar) fields

or structures (an ordered set of fields) based on Data
Dictionary (DD) definitions.

Tables have one or more columns (fields) in zero or more

rows.

Import and table parameters can have mandatory or

optional attributes, export parameters are always optional.

However, a easier request/response programming model is used

when BAPIs are made object-oriented as methods within proxy
classes representing business object types in the BOR.

IDocs

IDoc (intermediate document) provide a standard data container

structure for SAP to exchange data between processes, such as
asynchronous EDI (electronic data interchange) between
application programs written for SAP or between an SAP
application and an external program.

IDocs is the vehicle for data transfer in SAP's Application Link

Enabling (ALE) layer.

Different types of IDoc are used for purchase orders or invoices.

In other words, an IDoc encapsulates data so that it can be

exchanged between different systems without conversion from
one format to another. Each IDoc generated exists as a self-
contained text file that can then be transmitted to a receiver
(requesting workstation) without connecting to the central
database.

There are several types of IDoc records: a single Control Record,

one or many Data Records, and one or many Status record.
Segments and attributes of segments (maximum number,
hierarchical sequence, segment status, etc.) are used for
interpretating the SDATA field in the data record. Each IDoc
consists of several segments and a unique number assigned each
iDoc for tracking and future reference. Each segment contain
several fields.

IDoc data is then converted by SAP's EDI subsystem to a

universal EDI standard such as UN/EDIFACT (Electronic Data
Interchange for Administration, Commerce, and Trade) or
ANSI/X12.

Business Application Programming Interface (BAPI) is used for

synchronous communication method sRFC because data usually is
returned to the sending system.

BAPI methods are stored as RFC-capable function modules in the

ABAP Workbench Function Builder accessing the SAP Business
Object Repository (BOR).

A. SAP Technologies (+) A. Demonstration of how

1. SAP systems users get work done
(mySAP Business o Invoke the
Suite and SAP application, login,
NetWeaver) open, close, logout
2. Technical structure using mouse, menu,
of an SAP Web keyboard shortcuts
Application Server o Business
B. ABAP Workbench Basics transactions: view,
(++) list, select, search,
1. Data types and data add, change, delete
objects o Common error
2. Internal tables messages and taking
3. Data retrieval remediation action
(authorization o Batch job schedule
check) (data management)
4. Subroutines B. Installation, Environment,
5. ABAP runtime and Samples
system
6. Function groups and 1. Download Installer &
function modules patches (zip/tgz
C. Advanced ABAP (++) files)
1. Open SQL 2. Installation
2. Dynamic Troubleshooting
programming (Space, Network
3. Program calls and setup, etc.)
memory 3. Exploration of a
management standard installation
D. ABAP Objects (++) and what needs
1. Classes and objects configuration
2. Inheritance a. Tutorials,
3. Polymorphism Glossary,
(casting) Forums, other
4. Interfaces online support
5. Events b. Folders, Files
6. Global classes and (Sample
interfaces Project, Source
7. Exception handling files)
E. ABAP Dictionary (++) c. Server services
1. Database tables d. Add-ins
2. Performance for 2 Debug an almost working
table accesses sample program using the
3. Consistency by Workbench
means of input Code checkout from source
check (foreign key repository
dependency) 2. Invocation options
4. Dependency for from command line
ABAP Dictionary (such as log
objects verbosity)
5. Views 3. Use test harness to
6. Search helps define positive and
F. List Creation Techniques negative code
 (++) verification tests
1. Data output in lists 4. Stepping through
2. Selection screen (tracing) code
3. Logical database execution and
4. Interactive lists naming conventions
5. List creation with the
ALV grid control: 1. Defining &
1. Simple lists allocating
2. Field catalog variables and
3. Layout Memory
4. Event handling Management
G. Dialog Programming (++) 2. External
1. Screen (basics) references
2. Program interface 3. Chain of
(GUI title, GUI suboutine &
status) external calls
3. Screen elements for 4. Differences
output (text fields, among events
status icons, and and class
group boxes) inheritance
4. Screen elements for 5. Data type
input/output conversions,
5. Subscreen and casting,
tabstrip control polymorphism,
6. Table control and data
7. Context menu transformation
8. Lists in dialog s
programming 6. List creation,
H. Database Changes (+) looping, sorting
1. Database updates 7. Multi-
with open SQL Threading and
2. LUWs and other coding
client/server for Scalability
architecture 2. Code
3. SAP locking concept modularization
4. Organize database and code
changes execution
5. Complex LUW profiling
processing 1. Update/delete
6. Number assignment enqueues,
7. Change document connections to
creation databases
I. Enhancements and 2. Data queries
Modifications (+) with SQL
1. Changes to the procs, SQL
standard SAP system code
2. Personalization 3. Accessing flat
3. Enhancements to files
ABAP Dictionary 2 Compile/Build options and
elements debugging
4. Enhancements via 3 Text Editor navigation to
customer exits find and change a text string
5. Business Transaction Text in localized resource
Events bundles
6. Business Add-Ins 4 Code walkthroughs for
readability, high performance,
7. Modifications and defect avoidance
GUI dialog form, list, and report
formatting
2. Input data editing
3. Lookups, Loops,
sorting
4. Accessing dictionary
elements
5. Messaging (JMS,
etc.)
6. Subroutines and
code modularity
7. Stubs and drivers
during Integration
testing with other
modules
5 Searching for functions to
use from the framework/code
library
6 Review: describe menu
options in the Workbench
Import/Export

7 Production run (minimal

logging)