What is SAP?

 SAP is an ERP System

 ERP Stands for Enterprise Resource Planning
 An ERP System is a collection of software programs which ties all of an
enterprises various diverse functions (such as finance, sales, manufacturing,
human resources) into a cohesive data base.

Introduction to SAP - History

 SAP stands for Systems, Applications, and Products in Data Processing

 Founded in Germany by Five Former IBM Engineers in 1972
 Five IBM engineers from the AI department (Dietmar Hopp, Klaus Tschira,
Hans-Werner Hector, Hasso Plattner, and Claus Wellenreuther, all from
Mannheim, Baden-Württemberg)
 In 1988, SAP went public and became a joint-stock company, SAP AG
 Headquartered in Walldorf, Germany,
 The World's Largest Inter-Enterprise Software Company
 The world's Third-Largest Independent Software Supplier Overall
 Employs Over 23,700 People in More than 50 Countries
 SAP Supports all Kinds of Industries and all Functions of the Industry
 SAP is an Integrated System
 This means that all SAP modules are designed to share information and
automatically create
transactions based on various business process.
 SAP R/3 is the SAP Client/ Server – 3 Tier Architecture Based Software
Package

R/3 Business Application Modules

 FI - Financial Accounting
 IM - Investment Management
 CO - Controlling
 SD - Sales
 MM - Materials Management
 PP - Production Planning
 QM - Quality Management
 PM - Plant Maintenance
 PS - Project System
 HR - Human Resources
SAP LANDSCAPE

Landscape is like a server system or like a layout of the servers or some may even call it the
architecture of the servers viz. SAP is divided into three different landscape DEV, QAS and
PROD.

- DEV would have multiple clients for ex: 190- Sandbox, 100- Golden, 180- Unit Test.
- QAS may again have multiple clients for ex: 300- Integration Test, 700 to 710 Training.
- PROD may have something like a 200 Production.

DEVELOPMENT ---> QUALITY ----> PRODUCTION

DEVELOPMENT: is where the consultants do the customization as per the company's

requirement.

QUALITY: is where the core team members and other members test the customization.

PRODUCTION: is where the live data of the company is recorded.

A request will flow from Dev->Qual->Prod and not backwards.

ABAP/4 Development Workbench Architecture

 All programs are stored in the R/3 Repository.

o A program is simply an object.
 All definitions are kept in the data dictionary.
o e.g. variable descriptions and parameters of fields.
 Double-clicking will navigate you to wherever the object is stored.
 Remote call functions let you access other systems.

Reporting and Dialog Programming

 In reporting you use the ABAP/4 Open SQL to read data from the R/3
database
o A report consists of a selection screen on which you define the dataset you
wish to display, and a list which displays the data itself.
 In dialog programming you use the screen painter to create screens and
program the sequence in which they appear.

ABAP/4 Program Objects

 You can use the ABAP/4 Development Workbench to create ABAP/4 programs.
 You can call objects from the object list generated from the Object Browser’s
initial screen.
Types Of ABAP Programs

1 Executable Program
I Include Program
S Subroutine Pool Program Created in ABAP Editor
M Module Pool Program

F Function Group
J Interface Pool Program
K Class Pool Program
T Type Pool
X XSLT Program

Development Class

o Dev. Class object type

o Dictionary objects
o Programs
o Function groups
o Includes
o Transactions
o Logical databases
o etc.

Creating Programs

 Begin by first specifying a development class.

o Development classes are categories of SAP objects (e.g. program object).
 Customer-specific program names begin with Y or Z.
 If you are creating a test object which you do not wish to be transported, choose
Local Object.
o The development class is then set to $TMP automatically.

ABAP/4 Syntax

 An ABAP/4 program consists of individual statements

o Each statement must end with a period.
o The first word of a statement is known as the key word.
o Words are separated from each other by at least one blank.
o Statements can be indented.
o Statements can extend over several lines.
 You can concatenate several consecutive statements with an identical key
word
(e.g. WRITE: ).
 o Follow the key word with a colon.
o Separate each concatenated part with a comma.
o End the lines of the concatenated statements with a period.

 You can insert comments into a program in two ways:

1. An asterisk (*) in column 1 flags the whole line as a comment.
2. A quotation mark (“) within a line flags the remainder of the line as a
comment.

ABAP/4 Dictionary (In summary)

 The ABAP/4 Dictionary is the central facility in the system where you can
create and maintain data declarations, tables, structures and aggregated objects.
 Since it is integrated into the ABAP/4 Development Workbench as an active
component, any change made in the ABAP/4 Dictionary takes immediate effect in
programs affected.

Basic Dictionary Objects

 Tables - collection of records of data in fields.

 Data elements - contain the semantic definition (e.g. short description) of what is
contained w/in a field.
 Domains - describe the technical attributes of the table’s fields (e.g. field type,
length, value range, etc.).

SAP ABAP Data types and Data Objects

Data types and Data Objects in SAP ABAP

All ABAP programs use data to work on, which are characterized by a length, name and
data type. Every data in an ABAP program has these attributes. Data type describes the
content of the program. Data objects on the other hand are instances of an abstract data type.
In SAP both data objects and data types have separate name spaces.

ABAP DATA TYPES

ABAP Data types can be divided into elementary, reference, and complex types.

1. Elementary Types: – They are data types of fixed or variable length that are not made
up of other data types. In variable data types the memory space used by the data objects
changes dynamically during runtime and their definitions can be altered later. This is not so
with fixed length data types.
 #Predefined or User-Defined Elementary Data Types: – In predefined data types, you
are allowed to define elementary data types on your own in ABAP by making use of
the TYPES statement. You base these on the predefined data types. You can define your own
technical attributes.

2. Reference Types: – These data types describe reference variables, which are data
objects that have references in them. Reference variables are components of a complex data
object like structures or internal tables.

3. Complex Data Types: – Complex data types are those that are made up of other data
types. They are of two types – structured types and table types.

 Structures : – Structures are used to group together work areas that logically belong
together. The various elements of a structure may be of any type, or can be a different
structure or internal table as well. Structures may be classified as Nested and non-nested
structures or Flat and deep structures.
o Nested structures contain one or more other structures as components, unlike
non-nested structures.
o Flat structures contain only elementary data types of fixed length.
o Deep structures contain at least one internal table, reference type, or a string
as a component.

Internal Tables: – Internal tables may contain a series of lines that are all of the
same data type. Internal tables have a line type, which is used to identify table rows
using a unique or non-unique key and a table type that determines just how
individual table entries, whether non-sorted, sorted index tables or hash tables are
accessed.

Data Objects:

An ABAP data object is a part of the repository which has a content that can be
addressed and interpreted by the program. Before using them, all data objects must
first be declared in the ABAP program, and they exist only as long as the program is
being executed. Which means that Data objects are not persistent?

How do you declare Data Objects?

You can declare data objects in the declaration part of the ABAP program. The
declaration should include the data type of the object, and any missing technical
attributes. The declaration happens before the program is executed, and the technical
attributes are made use of just while the program is running.

The various data objects in ABAP are:

 1. Literals: – Literals exist in the program source code and have a fixed technical
attribute such as field length, number of decimal places and data type. But literals are
nameless.

2. Named Data Objects: – They are data objects that have a name using which you
may address the ABAP program. They include text symbols, constants and variables.

# Text symbols are nothing but pointers to texts present in the text pool.

#Variables are data objects which have contents that may be changed in an ABAP
program using program statements. To declare variables, you should use statements
such as DATA, CLASS-DATA, STATICS, PARAMETERS, SELECT-OPTIONS,
and RANGES.

#Constants are data objects whose contents cannot be changed.

3. System-Defined Data Objects: –

System-defined data objects are available at run-time always and don’t have to be
declared explicitly.

4. Interface Work Areas: - Interface work areas work as interfaces between programs,
screens, and logical databases and are declared with statements such as TABLES and
NODES.

5. Objects: – They are anonymous data objects that are nameless and declared using
CREATE OBJECT command.

Variable Types in SAP ABAP: -

ABAP variables or ABAP data objects are containers that carry information and can be
worked upon during the course of the ABAP programs by making use of various ABAP
statements. The different types of variable types in ABAP are simple variables, structure
variables and table variables. We discuss each type in detail.

Simple variables: – A simple variable in ABAP is declared as:

DATA Var1 TYPE I.

Var1 is the variable name and I is the type of the variable that defines it. Here is an
integer of elementary data type.

Variables can also be declared in this way:

DATA Var1 TYPE I.

DATA Var2 LIKE Var1

This code first declares Var1 and used Var1 to declare Var2. In this way, several
permutations and combinations are available to you while declaring variables in an
ABAP program.
Package Builder in SAP ABAP Workbench

Package Builder

Package builder is one of the important tool used for implementation in ABAP
workbench. Package is a development object that stores the objects such as menus, screens,
functional modules, transactions etc. Package builder is used to develop and maintaining
development classes, classes and transfer objects to other packages.

Package Builder Tasks: - The important tasks performed by package builder tools
are as follows -

1. Defining packages interface for users and restricting the use of interface for selected
users.
2. Defining user access for use of service from other package.
3. Creating packages and sub packages.
4. Define hierarchy of package
5. Defining interface for user package.

Package Builder Types: - Package builder creates two types of packages.

1. Provider package also known as server package.

 2. User package also known as Client package.

Server Package: - It provides development tools such as BAPIs, Classes, Programs,

Functional modules, types etc. Provider package tasks: - The tasks performed by server
package are as follows-

 Creation of package and define a hierarchy.

 It help to access the content of one package from another package through package
interface.

Client package: - In user user package you define user access for the visible of
service of other packages. User package tasks: - The tasks performed by client package are
as follows-

 Similar to server package, the client package provides a structure for package.

How to start package builder Package builder can be started by using following
method Enter transaction code “SE21″ or “SAPCKAGE”in the SAP command field and press
enter, then SAP screen opens with title “Initial screen package builder”.

ABAP Internal Table Overview and Create tables

Overview of SAP ABAP Internal Table

An internal table, like a database table, is made of one or more rows of the same structure.
While a database table holds data, an internal table does not hold any data even after the
execution of the program. An internal may hence be regarded as a temporary storage area or
as a temporary buffers where data can be modified as and when required. Internal tables
occupy memory only at run-time and not when they are declared.

Internal tables make it possible for data from one or multiple database tables to be processed
within a program. The number of lines contained by an internal table or its size varies, and
depends on the the program associated with it.

Internal tables perform calculations on the data present in the fields of database tables . You
retrieve data from a database table and store the same in an internal table. After doing so you
may perform calculations – such as addition – on it.
Internal tables are also data types and data objects. A data type is nothing but an abstract
description of a data object.

Work Area

To access an internal table, one must understand the concept of work area. A work area is a
temporary space in the memory space where you can read and modify the data in an internal
table, line by line. It must have the same structure as that of the internal table that is
associated with it.

Structure of an Internal Table

The structure of an internal table has two parts – a body and a header line. A header line
works as an implicit work area of the internal table However, a header line is optional. You
can have an internal table with or without a header line. When the internal table is created
along with a header line, a work area of same name as the internal table and same data type
as the lines of the internal table is created. When internal table is created without a header
line, work area has to be created explicitly by the programmer.

The table has a body and an optional header line, body holds the rows of the internal table.
The header line is a buffer that is used to hold a record before it is added to or retrieved from
an internal table. It holds only one row, which is a field string which has the same structure as
a row of the body.

Types of Internal Table

Internal tables can be categorized into three types: standard tables, sorted tables, and hashed
tables.

1. Standard Tables

Standard tables have a linear index. Here the records are accessed by using a table index or
key. These tables have a non-unique key. To add data to a Standard table, you use the
APPEND statement.
2. Sorted Tables

Sorted tables are similar to standard tables, but are sorted with a key. You can access the
records of a sorted table by making use of a table index or key. Here, the key is either unique
or non-unique and you use the INSERT TABLE statement to add data to it.

Sorted and standard tables use indexes and are therefore also called index tables.

3. Hashed Tables

Hashed tables have no linear index and are accessed using a hash algorithm. Hashed tables
are used when you want to process large volumes of data. Hash tables are non-indexed tables.
Hash table have only unique key
How to create an internal table:

# Create the internal table as a data type and then create a data object which refers to that data
type – For this you should use the TYPES statement to create the data type, create the data
object using the DATA statement and link the two by using TYPE or LIKE statements.

# Directly create the internal table data object – For this you should create the internal table
using DATA and OCCURS statement.

The OCCURS clause defines the body of an internal table by declaring the fields for the table
.

#To create an internal table with a header line, use either the BEGIN OF clause before the
OCCURS clause or the WITH HEADER LINE clause after the OCCURS clause in the
definition of the internal table.

#To create an internal table without a header line, use the OCCURS clause without the
BEGIN OF and WITH HEADER LINE clauses.

We can perform the following data manipulations on internal tables.

1. Moving and assigning internal tables

2. Clearing internal tables
3. Refreshing internal tables
4. Releasing memory of internal tables
5. Comparing internal tables
6. Performing the sort operation in internal tables
7. Determining the attributes of internal tables
1. Moving and assigning internal tables

This makes use of the MOVE statement

MOVE <internal_tab1> TO <internal_tab2>.

Basically, here one internal table is assigned to another.

<internal_tab2> = <internal_tab1>.

2. Clearing or Initializing Internal Tables

CLEAR statement is used to initialize a table.

CLEAR <internal_tab>.

CLEAR <internal_tab>[].

3. Refreshing Internal Tables

The REFRESH statement is used to ensure that an internal table is initialized.

REFRESH <internal_tab>.

4. Releasing the Memory of Internal Tables

The FREE statement is used to initialize an internal table and release the memory allocated to
it.

FREE <internal_tab>.

5. Comparing Internal Tables

Internal tables can be used as operands as well…..

<internal_tab1> <operator> <internal_tab2> …

Here, the <operator> expression stands for EQ, =, NE, <>, ><, GE, >=, LE, <=, GT, >, LT,
and <.

6. Sorting an Internal Table

An Internal Table may be arranged in ascending or descending order by using the SORT
statement.

SORT <internal_tab> [ASCENDING|DESCENDING] [AS TEXT]

[STABLE]

BY <internal_tab_field 1> [ASCENDING|DESCENDING

… <internal_tab_field n> [ASCENDING|DESCENDING] .

7. Determining the Attributes of Internal Tables

DESCRIBE TABLE specifies the attributes of an internal table which are not available
statically at run-time. This may include information such as the initial size, current size, and
table type.

DESCRIBE TABLE <internal_tab> [LINES <l>] [OCCURS <n>]

[KIND <k>].

LINES specifies the number of populated lines in the <l> expression, OCCURS specifies the
value of the INITIAL SIZE clause of the internal table in the <n> expression, KIND clause
specifies the table type of the internal table in the <k> expression

Difference between append, collect and insert command

Addition of rows can be done either by using append or insert command. Collect command
can also be used for the same. So whats the difference between all 3 ? This post will cover it
up.

Append command:

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

Ex: append wa_mara TO it_mara.

"Append lines of" can be used to append another internal table contents having same
structure to the other internal table.

Ex: APPEND LINES OF it_mara2 to it_mara.

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

Ex: INSERT wa_mara INTO it_mara INDEX 3.

Insert lines of can be used to copy another internal table contents having same structure to the
internal table. We need to mention the line number also from where it will be copied. The
existing entries will be shifted accordingly.

Ex: INSERT LINES OF it_mara2 INTO it_mara index 1.

If you don’t want to specify line position explicitly , then you can use insert ... into table.

Ex: INSERT wa_mara INTO TABLE it_mara.

Similarly :

Ex: INSERT LINES OF it_mara2 INTO TABLE it_mara.

The line number will be automatically determined based on table type:

1. Standard tables: The line is appended to the end of the internal table. This has
the same effect as the APPEND statement.
2. Sorted tables : The line is inserted into the table automatically according to the sorting
of the table key.
3. Hashed tables : The table is inserted into the internal hash administration according to
the table key.

Collect command:

Collect is used for summation purpose. If there is no record with that key , then it will create
a entry

If a entry with same key is already present , then it will add the numeric values of the new
record to the existing record without changing the non numeric values..

wa_itab-material = '00001'.
wa_itab-qty = 50.
COLLECT wa_itab into it_itab.

wa_itab-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.
A entry with key material 00001 is already present having qty as 50. qty 100 will be added to
it and the value will become 150

Itab contents after collect is

material => qty
00001 => 150
00002 => 100

Sy-subrc will be zero if the insertion/collection/appending operation is performed

successfully.

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

What Information is Stored in the ABAP Dictionary?

The most important object types in the ABAP Dictionary are tables, views, types,
domains, search helps and lock objects.

Tables are defined in the ABAP Dictionary independently of the database. A table
having the same structure is then created from this table definition in the underlying
database.

Views are logical views on more than one table. The structure of the view is defined in
 the ABAP Dictionary. A view on the database can then be created from this structure.

Types are used in ABAP program. The structure of a type can be defined globally in
ABAP programs. Changes to a type automatically take effect in all the programs using
the type.

Lock objects are used to synchronize access to the same data by more than one user.
Function modules that can be used in application programs are generated from the
definition of a lock object in the ABAP Dictionary.
Different fields having the same technical type can be combined in domains. A
domain defines the value range of all table fields and structure components that refer
to this domain.
The ABAP Dictionary also contains the information displayed with the F1 and F4 help
for a field in an input template. The documentation about the field is created for a data
element that describes the meaning of the contents of a table field. The list of possible
input values that appears for the input help is created by a foreign key or a search help.

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.
Table Fields
You must define the following for a table field in the ABAP Dictionary:
 • Field name: The field name can have a maximum of 16 places and may contain
letters, digits and underscores. The field name must begin with a letter.
• Key flag: determines whether the field should belong to the table key.
• Field type: data type of the field in the ABAP Dictionary.
• Field length: number of valid places in the field.
• Decimal places: number of places after the decimal point, specifying numeric
data types.
• Short text: short text describing the meaning of the field.
You can also include he fields of a structure in the table.
Assignment of the Data Type, Field Length and Short Text
You can assign the data type, length and short text in different ways:
• You directly assign the field a data type, field length (and if necessary decimal
places) and short text in the table definition.
• You can assign the field a data element. The data type, field length (and decimal
places) are determined from the domain of the data element. The short
description of the data element is assigned to the field as a short text.
Other Assignment Options
• Check table: An input check for the field can be defined with a foreign key. This
input check appears on all the screens in which the field is used.
• Search help assignment: A search help can be assigned to a field. This search
help defines the input help flow on all the screens in which the field is used.
• Reference field and reference table: You must specify the table field in which the
corresponding unit of measure or currency can be found for fields containing
quantities (data type QUAN) or currency amounts (data type CURR).

Reference Fields and Reference Tables

You must specify a reference table for fields containing quantities (data type
QUAN) or currency amounts (data type CURR).
This reference table must contain a field with the format for the currency key (data
type CUKY) or unit of measure (data type UNIT) . This field is called the reference field of
the output field. The reference field can also reside in the table itself.
A field is only assigned to the reference field at program runtime. For example, if
a field is filled with currency amounts, the corresponding currency is determined from the
assigned reference field, that is the value entered in this field at the moment defines the
currency.

T
able T1
F Fiel F
 ield 1 d 2 (CURR) ield 3

Reference
table T2
F Field F F
ield 4 5 (CUKY) ield 6 ield 7

Reference field

Runtime
T1-Field 2 1,500.00

T
2-Field 5 EM

Includes
In addition to listing the individual fields, you can also include the fields of
another structure in tables and structures. Individual fields and includes can be mixed as
required.

Foreign Keys
You can define the relationships between tables in the ABAP Dictionary by creating
foreign keys.
Using foreign keys, you can easily create value checks for input fields. Foreign keys
can also be used to link several tables in a view or a lock object.

Field Assignment in the Foreign Key

A foreign key links two tables T1 and T2 by assigning fields of table T1 to the
primary key fields of table T2.
 Foreign key fields

Foreign key table T1

F F Fi F
ield 1 ield 2 eld 3 ield 4

Primary key

Ch
eck T2
F Fi
ield 5 ield 6 eld 7

Primary key

Table T1 is called the foreign key table (dependent table) and table T2 the check
table (referenced table). The pair of fields for the two tables must have the same data type
and length. One field of the foreign key table therefore corresponds to each key field of the
check table. This field is called the foreign key field.
A foreign key permits you to assign data records in the foreign key table and check
table. One record of the foreign key table uniquely identifies one record of the check table
using the entries in the foreign key fields.

Check Field and Value Check

One of the foreign key fields is marked as the check field. This means that the
foreign key relationship is maintained for this field.

Foreign Keys
When an entry is made in the check field, there is a check whether the check table
contains a record with the key defined by the values in the foreign key fields. If this is so, the
entry is valid. Otherwise the system rejects the entry.

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.
The Convert to transparent table flag (transparent flag) is also displayed for
pooled tables or for tables which were converted into transparent tables earlier on with
this flag.

Data Class
If you choose the data class correctly, your table is automatically assigned to the
correct area (tablespace or DBspace) of the database when it is created. Each data class
corresponds to a physical area in which all the tables assigned to this data class are stored.
There are the following data classes:
• APPL0 (master data): Data which is seldomly changed. An example of master data is
the data contained in an address file, such as the name, address and telephone
number.
• APPL1 (transaction data): Data that is frequently changed. An example of
transaction data is the goods in a warehouse, which change after each purchase
order.
• APPL2 (organizational data): Customizing data that is defined when the
system is installed and seldomly changed. An example is the table with
country codes.
Two further data classes, USR and USR1, are provided for the customer. These
are for user developments. The tables assigned to these data classes are stored in a
tablespace for user developments.

Size Category
The size category defines the expected space required for the table in the
database. You can choose a size category from 0 to 4 for your table. Each category is
assigned a certain fixed memory size in the database, which depends on the database
system used.
When a table is created, initial space (an Initial Extent) is reserved in the database. If
more space is required at a later time due to data entries, additional memory will be added
depending on the selected size category.

Buffering Permission
You must define whether and how a table is buffered in the technical settings for the
table. There are three possibilities here:
• Buffering not permitted: Table buffering is not permitted, for example because
application programs always need the most recent data from the table or the table is
changed too frequently.
• Buffering permitted but not activated: Buffering is permitted from the business and
technical points of view. Applications which access the table execute correctly with
and without table buffering. Whether or not table buffering will result in a gain in
performance depends on the table size and access profile of the table (frequency of
the different types of table access). Table buffering is deactivated because it is not
possible to know what these values will be in the customer system. If table buffering
would be advantageous for the table size and access profile of the table, you can
activate it in the customer system at any time.
Buffering activated: The table should be buffered. In this case you must specify a
buffering type.
Buffering Types
The buffering type defines which table records are loaded into the buffer of the
application server when a table record is accessed. There are the following buffering types:
• Full buffering: All the records of the table are loaded into the buffer when one
record of the table is accessed.
• Generic buffering: When a record of the table is accessed, all the records having
this record in the generic key fields (part of the table key that is left-justified,
identified by specifying a number of key fields) are loaded into the buffer.
• Single-record buffering: Only the records of a table that are really accessed are
loaded into the buffer.

Cardinality
Use

The cardinality (n:m) describes the foreign key relationship with regard to the number
of possible dependent records (records of the foreign key table) or referenced records
(records of the check table).

The left side (n) of the cardinality is defined as follows:

n=1
 There is exactly one record assigned to the check table for each record of the
foreign key table.
n=C

The foreign key table can contain records that do not correspond to any record of
the check table because the foreign key field is empty. This can occur, for example, if the
field of the foreign key table is optional, in which case it does not have to be filled.

The right side (m) of the cardinality is defined as follows:

m=1

There is exactly one dependent record (record of the foreign key table) for each
record of the check table.
m=C

There is at most one dependent record for each record of the check table.
m=N

There is at least one dependent record for each record of the check table.
m=CN

There can be any number of dependent records for each record of the check 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. A view can be used in ABAP
programs for data selection.

The data of a view is derived from one or more tables, but not stored physically. The
simplest form of deriving data is to mask out one or more fields from a base table
(projection) or to include only certain entries of a base table in the view (selection). More
complicated views can comprise several base tables, the individual tables being linked with a
relational join operation. See also Join, Projection and Selection .
The base tables of the view must be selected in the first step of a view definition. In
the second step, these tables must be linked by defining the join conditions. It is also
possible to use the join condition from a foreign key defined between the tables (see Foreign
Key Relationship and Join Condition ) . In the third step, you must select the fields of the
base tables to be used in the view. Selection conditions that restrict the records in the view
can be formulated in the fourth step.
Four different view types are supported. These differ in the way in which the view is
implemented and in the methods permitted for accessing the view data.
• 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.

Database views implement an inner join. The other view types implement an outer
join
The join conditions for database views can be formulated using equality
relationships between any base fields. The join conditions for the other view types must be
obtained from existing foreign keys. Tables therefore can only be combined in a
maintenance view or help view if they are linked to one another with foreign keys.

Modularization Techniques

Modularization means minimization, if the programs contain the same or similar

blocks of statements or it is required to process the same function several times, we can avoid
this redundancy or duplication of codes by using modularization techniques.

By modularizing the ABAP/4 program

1. We make them easy to read i.e. improves the readability
2. Improve their structure
3. Error handling and maintenance is easy
4. Updating can be done easily
5. Reusability i.e. procedures can be used in other programs as well
6. Encapsulation i.e. hides the internal architecture and data structure from other
classes. It is important to use a series of functions that act as the means to access the data.
7. Reduces code redundancy i.e. avoids duplication of codes

Different modularization techniques available are:

1. SUBROUTINE
2. FUNCTION MODULE
3. METHODS
4. INCLUDES AND MACROS

METHODS: It describes the functions and behavior of classes and their instances in
ABAP objects methods must be defined in classes.

MACROS: Macros designed based on place holder (place holder works like pointers
in c language but in case of place holder changes effect on output.

INCLUDES: If I am defining the same variables in many programs, instead of

defining in all programs we have define all the variables in one program and that program is
included or added to the programs whenever needed that’s called include program. It cannot
be executed independently it has to include in a program.

SUBROUTINES:
A subroutine is a reusable section of code. It’s like a mini program that can be called
from another point in your program. Subroutine is generally for local modularization i.e. they
are generally called from the program in which they defined.
We can use subroutine to write functions that are used repeatedly with in a program.
You can define subroutine in any ABAP programs.
Syntax for defining subroutine
FORM (subroutine name) (parameter (Optional))
-----------------------------------
END FORM.

Syntax for calling subroutines

PERFORM (subroutine name)(parameter)

Subroutines cannot be nested, therefore place subroutine definitions at the end at the
program. One subroutines can call other subroutines and may also call themselves
(recursive). Once a subroutine has finished running, the calling program carries on processing
after the perform statement.

There are two types of subroutines:

1) Internal subroutine: If the source code or body of the subroutine will be in the same
ABAP/4 program i.e. in the calling program which is called internal subroutine.
2) External subroutine: If the source code or body of the subroutine present other than
the calling program which is called external subroutine. An external subroutine is one that
resides in a different program that the perform statement that calls it.

PARAMENTERS IN SUBROUTINES
Parameters can be either local or reference to global variables. The memory for local
parameters is allocated when the subroutine is called & freed when it ends. If we define
variables on the form statement, the perform statement must pass a value to each of these
variables.

Global variables: A global variable is one that is defined outside of a subroutine by

using the tables or data statement. It can be accessed from any point in the program be it
inside an event or inside a subroutine.
Local variables: A local variables is a variable that is defined inside a subroutine
using local data or static’s statement. It is said to be local to subroutine.
The two types of parameters are:
Formal parameters: Parameter names that appear on the form statements are called
formal parameters.
Example:
FORM s1 using P1 changing P2, P3
Here P1, P2, P3 are called formal parameters.
Actual parameters: Parameter names that appears on the perform statement are
called actual parameters.
Ex: PERFORM S1 using P1 changing P2, P3.
 Here P1, P2, P3 are called actual parameters.

There are three ways of passing parameters to a subroutine.

1) Pass by reference
2) Pass by value
3) Pass by value & result

1) Passing parameters by reference

During subroutine call, only the address of the actual parameter is transferred to the
formal parameters i.e. pointer to the original memory or address location is passed. The
formal parameter has no memory of its own & we work with the fields of the calling program
with in a subroutine. So changes to the variable within the subroutine update the original
memory location immediately i.e. the field contents in the calling program also changes.

2. Passing parameters by value :

When you pass a parameters by value, new memory is allocated for the value i.e. the
formal parameters are created as copies of the actual parameters, thus formal parameters have
memory of their own i.e. the memory allocated when the subroutine is called and freed when
the subroutine returns. Therefore changes to the formal parameters have no effect on the
actual parameters.
3. Passing parameters by value & result:
Pass by value & result is similar to pass by reference like Pass by value, a new
memory area is allocated & it frees when the subroutine ends. When the end form statement
executes, it copies the value of the local memory area back into the original memory area
changes to the parameter with in the subroutine are reflected in the original but not until
subroutine returns.

Leaving subroutine
You can exit out of a subroutine at any time using the following statements.
1) Stop: Immediately leaves the subroutine & goes directly to the end of selection
event.
2) Exit: It leaves the loop, subroutine or comes out of the program & display the
result without any condition.
3. Check: It also comes or immediately leaves the subroutine but it depends on logical
expression. If it is false comes out of the loop or subroutine.

FUNCTION MODULES AND FUNCTION GROUPS

Function modules are special procedures that are globally visible and that can
be called from within other ABAP programs. They can only be defined and
implemented in special ABAP programs, which are called function groups.
Function groups are not executable programs – that is, they cannot be started using
transaction codes or by entering their names. They serve exclusively as main
programs for the function modules. In most cases, a function group contains
several function modules that perform related functions or operate on the same
data.
When an ABAP program calls a function module, the corresponding function
group is loaded into the internal session, where it remains until the calling program
ends. If the program calls several function modules from the same function group
(or the same function module several times) consecutively, the function group is
only loaded during the first call.

Aside from function modules, function groups can also contain the following
elements:•
 Data declarations (global data objects)
 Subroutines
 Screens
These elements can be used by all the function modules in the function group.
Global data objects are...
... encapsulated
They cannot be accessed directly from outside the function group. Access is
only possible by calling a suitable function module.
.... static
They retain their values when an executable program calls several function
modules in the same function group consecutively.

Technically, a function group consists of a main program and a number of include

programs. When you create a function group, the main program and the include
programs are created automatically. The names of the individual components
are generated from the name of the function group (<fgrp>), which can be up
to 26 characters long.

The main program, SAPL<fgrp>, merely contains INCLUDE statements for the
following include programs:
• TOP include
Include program L<fgrp>TOP contains the FUNCTION-POOL statement
and the global data declarations.
• U includes
Include program L<fgrp>UXX contains additional INCLUDE statements
for the include programs L<fgrp>U01, L<fgrp>U02, ... . These contain
the actual function modules.
• F includes
The include programs L<fgrp>F01, L<fgrp>F02, ... can be used to define
subroutines that all the function modules can access through an internal call.
• O includes
The include programs L<fgrp>O01, L<fgrp>O02, ... can be used to define
PBO modules (OUTPUT) for the screens in the function group.
• I includes
The include programs L<fgrp>I01, L<fgrp>I02, ... can be used to define
PAI modules (INPUT) for the screens in the function group.

The creation of these include programs is largely automated through the forward
navigation in the ABAP Workbench.

INTERFACE PARAMETERS FOR FUNCTION MODULES

Interface parameters are used to exchange data between the calling program and
the function module.
Parameter Types
We differentiate between the following types of parameters:
Import parameters are passed by the calling program to the function module.
Export parameters are passed by the function module to the calling program.
Changing parameters are used for both import and export. They are passed
by the calling program to the function module. The function module can
change their contents and pass them back to the calling program.
Tables parameters represent a special option for passing internal tables.
These tables are imported and exported. In general, you should no longer
use tables parameters for regular function modules. Use other parameter
types to pass the internal tables instead (typed with a table type from the
Dictionary or a generic table type).
 DECLARING AND RAISING EXCEPTIONS
Function modules can raise exceptions in order to inform the calling program
of error situations. To do so, you have to declare the exceptions in the function
module interface. Choose a name for each exception that the function module
might raise.
You have two options for raising an exception when an error occurs within a
function module:
RAISE <exception>.
If the <exception> is listed in the call of the function module, control
returns to the calling program. If it is not listed, the program terminates
with a runtime error.

Native and Open SQL in ABAP

The goal of this tutorial is not to teach you SQL or database concepts but to introduce
you to the SQL diversity in ABAP
In ABAP/4 programming language, there are two types of SQL being used.
NATIVE SQL
OPEN SQL.
Open SQL allows you to access the database tables declared in the ABAP dictionary
regardless of the database platform that the R/3 system is using.
Native SQL allows you to use database-specific SQL statements in an ABAP/4 program.
This means that you can use database tables that are not administered by ABAP
dictionary, and therefore integrate data that is not part of the R/3 system.
Open SQL consists of a set of ABAP statements that perform operations on the central
database in the R/3 system. The results of the operations and any error messages are
independent of the database system in use. Open SQL thus provides a uniform syntax
and semantics for all of the database systems supported by SAP. ABAP programs that
only use Open SQL statements will work in any R/3 system, regardless of the database
system in use. Open SQL statements can only work with database tables that have been
been created in the ABAP dictionary.
Basic Open SQL Commands
SELECT
INSERT
 UPDATE
MODIFY
DELETE
OPEN CURSOR, FETCH, CLOSE CURSOR

*********************************
Open SQL Return Codes
All Open SQL statements fill the following two system fields with return codes.
SY-SUBRC
After every Open SQL statement, the system field SY-SUBRC contains the value 0 if the
operation was successful, a value other than 0 if not.
SY-DBCNT
After an Open SQL statement, the system field SY-DBCNT contains the number of
database lines processed.
Native SQL
As already mentioned, Native SQL allows you to use database-specific SQL statements
in an ABAP program.
To use Native SQL statement, you must precede it with the EXEC SQL statement, and
follow it with the ENDEXEC statement.
EXEC SQL [PERFORMING <form>].
<Native SQL statement>
ENDEXEC.
There is no period after Native SQL statements. Furthermore, using inverted commas (")
or an asterisk (*) at the beginning of a line in a native SQL statement does not introduce
a comment as it would in normal ABAP syntax. You need to know whether table and
field names are case-sensitive in your chosen database.
In Native SQL statements, the data is transported between the database table and the
ABAP program using host variables. These are declared in the ABAP program, and
preceded in the Native SQL statement by a colon (:). You can use elementary structures
as host variables. Exceptionally, structures in an INTO clause are treated as though all of
their fields were listed individually.
As in Open SQL, after the ENDEXEC statement, SY-DBCNT contains the number of
lines processed. In nearly all cases, SY-SUBRC contains the value 0 after the
ENDEXEC statement.
Open SQL - Performance Rules
To improve the performance of the SQL and in turn of the ABAP program, one should
take care of the following rules-
Keep the Result Set Small
Using the where clause
If only one record is required from the database, use SELECT SINGLE whenever
possible
Minimize the Amount of Data Transferred
Restrict the number of lines
If only certain fields are required from a table, use the SELECT <field1> <field2>
INTO ... statement
Restrict no of columns
Use aggregate functions
Minimize the Number of Data Transfers
Avoid nested select loops
An alternative option is to use the SELECT .. FOR ALL ENTRIES statement. This
statement can often be a lot more efficient than performing a large number of SELECT
or SELECT SINGLE statements during a LOOP of an internal table.
Use dictionary views
Use Joins in the FROM clause
Use subqueries in the where clause
Minimize the Search Overhead
Use index fields in the where clause
When accessing databases, always ensure that the correct index is being used .
Reduce the Database Load
Buffering
Logical databases
Avoid repeated database access

Using Internal Tables to Buffer Records

To avoid executing the same SELECT multiple times (and therefore have duplicate
selects), an internal table of type HASHED can be used to improve performance.
Control Break Statements in SAP ABAP

Control break statements are like events inside the loop. There are 5 control break
statements in ABAP. These are used within loop.(Except ON CHANGE OF which
can be used outside the loop as well)

AT FIRST - ENDAT
AT NEW - ENDAT
AT END OF - ENDAT
AT LAST - ENDAT
ON CHANGE OF

Explanation:

AT FIRST : Will trigger at the first run of the loop.

AT LAST: Will trigger at the last run of the loop.

 The below 3 events are normally used when the table is sorted.

AT END OF : When we use At end for a field, it will trigger whenever there is
any change in any of the fields from the left to that of the particular field. The trigger
point will be the at the last occurrence of the same value for the field.

AT NEW: When we use At new for a field, it will trigger whenever there is any
change in any of the fields from the left to that of the particular field. The trigger point
will be the at the first occurrence of the new value for the field.

ON CHANGE OF: On change of it triggers only when there is any change in the
particular field.
On change of can be used outside the loop too

ABAP Classical Reports

SAP ABAP Classical Reports are the most basic ABAP reports that contain both
selection screen and an output screen. Classical reports are executed based on events, and
not executed on a line-by-line basis. Classical reports are non-interactive reports.
Basically, they consist of one program that creates a single list.
The following SAP training tutorials guides various events in classical reports, provide
the syntax for each and then present a simple programming example of a Classical
Report.
Events in Classical Reports.
The following are the list of Events in Classical Reports.
1. Load-of-program
The Load-of-program event loads the program into memory for execution. Always,
Load-of-program is the first event in execution sequence.
2. Initialization
Initialization is an event that is used for initialize variables, screen values and other
default actions.
3. At Selection-Screen output
One of the selection screen events is used to manipulate dynamic selection-screen
changes.
4. At Selection-Screen on field
It is used to validates the screen input parameter.
5. At Selection-Screen on value request
This selection screen event allows for a value help or field help for an input field.
6. At Selection-Screen on help request
This selection screen event enables function key F1 help for a input field.
7. At Selection-Screen
Selection screen validates various input fields.
8. Start-of-Selection
This is the default event in any ABAP program and is activated whether we use it
explicitly or not .
9. End-of-Selection
This event signals that event of what has been initiated by the start-of-selection event.
10. Top-of-Page
This event is used to print the same heading for all pages.
11. End-of-Page
This event is used to print the same footer for all pages.

SAP-ABAP programs are either written as “Reports” or as “Dialogs”. ABAP Report

programming is done when a large amount of data is to be presented. This includes
selecting data from the tables in the ABAP Dictionary, processing the data and
formatting it. ABAP Reports can also be downloaded from SAP into an Excel sheet and
distributed within and outside an organization, or sent by e-mail to a person several
thousand miles away.
Events in Report Programming
ABAP Report programs are also known as Event Driven Programs. The various events in
report programming are:
Load-of-program
This is the first event in report programming which loads a program of type 1, M, F, or S
and triggers the associated event in an internal session after the loading. It then runs a
processing block that is associated with the program only once for each program and
internal session.
Initialization
Initialization is executed just before the display of the selection screen. Here are the
values are initialized and one may assign different values other than the values that are
shown by default on the selection screen. One may also feed the selection screen with
more values at runtime.
At Selection-Screen.
This event occurs when the selection screen is processed, at the end of then event PAI (or
Process After Event). Any validations and checks of the values are done here after input.
Start-of-Selection.
In this event, the report program begins and values are selected from the tables.
End-of-selection.
This event writes the data to the screen after all the data have been selected.
Interactive Events
These are events used for interactive reporting, to create a detailed list from a basic list.

Dialog Programs
ABAP Dialog Programs are ABAP programming that accept user input and allow an
interaction between the program and the user, using dialog boxes. Dialog programs are
type ‘M’ programs or Module Pool programs. They have to be associated with a
transaction code in which the initial screen is specified.
Using dialog programming, a user can interact with the program by entering data,
selecting a menu item, by clicking on a data item or display button. Also, using dialog
programming, a user may navigate back and forth in between screens.
How is a Dialog Program different from a Report Program?
In a report program, a user directly reads from a database without having the capability
to make changes to the database. However, a dialog program allows a user to change the
contents of a database and is far more interactive than a report program.
What does a Dialog Program consist of?
A report program has just one independent program which is unrelated to other objects.
A dialog program however has several interdependent objects that do different things but
serve a common purpose. These objects are linked by hierarchy to the main program and
executed sequentially in accordance with the commands used in the main program.
Components of Dialog program
Transaction code
The transaction code is created in the Repository Browser of ABAP Workbench, or can
be created using the Transaction code SE93. The transaction code starts the screen
sequence, by linking the ABAP program to an initial screen. The CALL SCREEN
command is used to create the screen sequence from any point in the ABAP program.
Screens
An SAP system is actually a system of inter-related screens, each on leading to another.
Screens can be created by the use of the Transaction code SE51 or by using the Screen
Painter in the ABAP Workbench. Every screen is related to an ABAP program, consists
of layouts and screen masks and is activated according to the screen flow logic. The
layout determines the how the input and output fields are placed, as well as other
graphical elements such as check boxes and radio buttons. A screen flow logic decides
how the actual processing takes place.
GUI status
GUI status is used to control the menu bars, standard toolbar, application toolbar and can
be created by using the Menu Painter in the ABAP Workbench.
ABAP Program
In SAP every screen and GUI status are related to an ABAP program, which has the
dialog modules which are activated according to the screen flow logic. These modules
also process the user input from the GUI status.
Screen Flow Logic
 Screen Flow logic has the following events”
■Process Before Output (PBO) event: processed before the screen is displayed
■Process After Input (PAI) event: processed after a user action on the screen
■Process on help request (POH): processed when F1 is pressed
■Process on value request (POV): processed when F4 is pressed
Dynpro
A Dynpro is also called a Dynamic Program and consists of a screen together with its
Flow logic. It is responsible for just one step of a Dialog Program.

SAP BDC (Batch Data Communication) Training

SAP BDC

SAP BDC stands for batch data communication and it is a technique using with legacy data
or data loading in to SAP system which is not updated in the SAP systems. For example,
company decides to adapt its systems and procedures to SAP, and installs SAP, it will have to
upload a huge volume of data that are a part of its legacy systems or old systems into the SAP
system. This technique is done through SAP BDC (Batch Data Communication).

BDC sessions, which are also known as Batch Input Sessions, are used to load legacy data
into the SAP system and perform highly repetitive tasks that involve in data entry. BDC
session simulates the online entry of all data, transactions, validations that are included in
each transaction.

To perform SAP BDC transaction, a programmer has to manually examine the entire
transaction for the first time . He must note every single field – including details such as the
field’s name, type and length. Programmer has to write a batch input program to format the
entire incoming data into a BDC table. SAP simplifies the entire process by using BDC
Recording. BDC Recording is a feature that is included in SAP R/3 systems. In BDC
Recording, a user records a sample transaction and Importer Wizard formats the recording
into a structure of type tree. The tree is then used in a Map Designer, which maps the entire
data directly into the BDC table format. This is then processed entirely by the SAP BDC
session program.

To perform SAP BDC, we do the following steps

1. Load SAP systems with data using a BDC session

2. Identify the transaction which is used to create the SAP data. (For example, take
MM01)
3. Run SHDB transaction (Use SM35 recording)
By using the above SAP transactions, you have loaded the initial data into the SAP system
means have done a “recording”. So, next, you must use this format for the rest of the
program. You will do well to note down each of the fields here.

The data can only be read in form of a text file or a flat file, and fed by the ABAP program
into an internal table called the BDCDATA. Now, this internal table, BDCDATA is taken as
the format for the input and executed in the background. The SAP BDC Data table should
have the following structure.
How to write SAP BDC Program

——————–

report ZMAT_MAST_UPLOAD
no standard page heading line-size 255.
TABLES : RLGRAP.
include bdcrecx1.
DATA : BEGIN OF IT_MM01 OCCURS 0,
MATNR(18),
MBRSH,
MTART(4),
KZSEL,
MAKTX(40),
MEINS(3),
END OF IT_MM01.
DATA : STR_FPATH TYPE STRING.
PARAMETERS : P_FPATH LIKE RLGRAP-FILENAME.
AT SELECTION-SCREEN ON VALUE-REQUEST FOR P_FPATH.
CALL FUNCTION ‘F4_FILENAME’
* EXPORTING
* PROGRAM_NAME = SYST-CPROG
* DYNPRO_NUMBER = SYST-DYNNR
* FIELD_NAME =‘‘
IMPORTING
FILE_NAME = P_FPATH.
start-of-selection.
IF P_FPATH IS NOT INITIAL.
STR_FPATH = P_FPATH.
ENDIF.
CALL FUNCTION ‘GUI_UPLOAD’
EXPORTING
filename = STR_FPATH
FILETYPE = ‘ASC’
tables
data_tab = IT_MM01.
LOOP AT IT_MM01.
WRITE :/10 IT_MM01.
ENDLOOP.
perform open_group.
LOOP AT IT_MM01.
perform bdc_dynpro using ‘SAPLMGMM’ ‘0060’.
perform bdc_field using ‘BDC_CURSOR’
‘RMMG1-MTART’.
perform bdc_field using ‘BDC_OKCODE’
‘=AUSW’.
perform bdc_field using ‘RMMG1-MATNR’
IT_MM01-MATNR.
perform bdc_field using ‘RMMG1-MBRSH’
IT_MM01-MBRSH.
perform bdc_field using ‘RMMG1-MTART’
IT_MM01-MTART.
perform bdc_dynpro using ‘SAPLMGMM’ ‘0070’.
perform bdc_field using ‘BDC_CURSOR’
‘MSICHTAUSW-DYTXT(01)’.
perform bdc_field using ‘BDC_OKCODE’
‘=ENTR’.
perform bdc_field using ‘MSICHTAUSW-KZSEL(01)’
IT_MM01-KZSEL.
perform bdc_dynpro using ‘SAPLMGMM’ ‘4004’.
perform bdc_field using ‘BDC_OKCODE’
‘/00′.
perform bdc_field using ‘MAKT-MAKTX’
IT_MM01-MAKTX.
perform bdc_field using ‘BDC_CURSOR’
‘MARA-MEINS’.
perform bdc_field using ‘MARA-MEINS’
IT_MM01-MEINS.
perform bdc_dynpro using ‘SAPLSPO1′ ‘0300’.
perform bdc_field using ‘BDC_OKCODE’
‘=YES’.
perform bdc_transaction using ‘MM01′.
REFRESH BDCDATA.
ENDLOOP.
perform close_group.

———————–

# Now run the program, so that the initial data contained in it is loaded into the SAP system

# The last step to is run SM35 to process the batch session, where the entire legacy system
data is uploaded into the SAP system.

SAP BDC can be perform by Call Transaction method or by Session method. The above
example makes use of the Session method.

SAP Data Transfer Techniques and Methods

SAP ABAP Data Transfer Techniques and Methods

One of the most important things that you shall be required to do as a SAP ABAP
programmer is to perform data transfer or data migration from a legacy system to SAP
system. Getting the right data migration is the most important part of the “go live” phase.
There are several data migration techniques in SAP ABAP. Let discuss briefly some of the
important data transfer techniques.

SAP BDC – SAP Batch Data Communication

SAP BDC programs are the most important methods of data transfer technique or migration
in SAP, where data is transferred by writing a batch input program, and implemented using a
session method or a call transaction method. BDC helps in mass data transfer, in which
several thousands of data entries related to a transaction have to be transferred into an SAP
system from a legacy system. BDC works by automating the process of manually transferring
data from legacy system to SAP system. Here, you are only required to transfer a data related
to a single transaction at first, using the right data format.

On running the SAP BDC program, and after using batch input transaction code SM35, it
automatically transfer all the remaining data entries that run into several thousand lines by
using the same format that has been established. The entire process takes place in the
background, and the whole data transfer happens one-by-one as though you are doing it
manually – except that the SAP system takes care of everything. All that you have to do is to
properly establish the framework for the very first data transfer.

While BDC is an old technique of data migration used by the SAP R/3 system, you must
understand that it is a 1-way transfer. Data is transferred from legacy system to SAP system
and not from SAP system to legacy system. The data reads only in form of a text file or a flat
file, and fed by the ABAP program into an internal table called the BDCDATA. Now, this
internal table, BDCDATA is taken as the format for the input and executed in the
background.

There are two methods of BDC – call transaction method and Batch Input session method. In
call transaction, all transactions are triggered during the time of processing and the ABAP
program must itself handle the error handling. It allows for real-time interfaces, custom error
handling and logging features.

In Batch Input Session methods, a session is created which has all the transactional data. This
session can be viewed, scheduled and and also processed by making use of the
transaction SM35. It has in in-built error processing mechanism.
Batch Input (BI) – Batch input uses the BDC approach but do not need an ABAP program
to format the BDCDATA. The data is formatted using predefined structures and saved in a
flat file. The Batch Input (BI) program reads the file and then implements the transaction in
the header record of the file.

Direct Input (DI) – This is exactly the same as Batch Input method of data transfer with one
crucial different – instead of processing screens, here all the fields are validated and data is
directly loaded into tables by making use of standard function modules. Direct Input (DI)
method of data transfer is much faster than BDC programs and best for loading large volumes
of data. The problem in this method is not available for all types of applications.

LSMW – Legacy System Migration Workbench

LSMW tool enables an encapsulated method of data transfer which facilitates Data Migration
from legacy systems to SAP system. LSMW works best for master data, one doesn’t require
to use much coding while using LSMW. Even a non-specialist in ABAP who is using the
SAP system can easily use this method. This method is preferred by functional SAP
consultants rather than technical consultants for data migration. LSMW has the same
functionality as a BDC program, but lacks in complexity and it used only for simple
transactions that do not require much input or effort from an ABAP programmer.

BAPI

BAPIs are other great methods used for large scale data migration and is an excellent
alternative to BDC. BAPIs are standard programming interfaces that provide access to
different business processes and data used in the SAP system. An ABAP programmer can
define his own interface using a BAPI and successfully implement them to conduct large
scale data migration from legacy system to SAP system.

SAP BDC Tools | Write BDC program

SAP BDC Tools

SAP BDC is the most effective method of mass data migration from legacy systems to SAP
system. There are two methods of BDC tools i.e Call Transaction Method and Batch Input
Session Method. In our previous SAP training tutorials we have discussed about what is SAP
BDC

Here, we are going to explain BDC tools through the implementation of an program is done
using the call transaction method.

To perform BDC using the Call transaction method, we need to do the following:

1. Analyze the legacy data. Closely study how the data which is to be transferred can be
mapped into a recognized SAP structure. Also determine the necessary data types that need to
be used as well as the data length conversions.

2. Next, create SAP data structures which are used to export the data. (Creation of internal
table, BDCDATA)

3. Now, export the data in to a sequential file. Be very careful about the character format
which is used.

4. You can use the standard SAP batch input program or customize and create your own
program, depending on your requirements. Choose call transaction method or batch input
session method according to your needs.

5. Now, execute the program, process the data, add it to the SAP System.

6.. For batch input session method, you will have to analyze the process log. But for the
CALL TRANSACTION method, there is no proper log, you will have to use the messages
that are collected by your program.

7. Closely study the results of the process analysis, correct and reprocess the data entries that
are displayed as errors.

Important points to be noted While writing the BDC program.

1. Use the right transaction to process batch input data.

2. The data has to be stored in the batch input structure, BDCDATA.
3. Do you want to use call transaction method or batch input session method?.
4. Now read the data from a sequential file.
5. Do the data conversion as well as the error checking.
6. Generate a batch input session if you are using batch input sessions method,or execute
the program with CALL TRANSACTION USING statement, which processes the
data directly, without using a session.

What is the difference between batch input and call transaction in BDC?
 Session method.
1) synchronous processing.
2) can transfer large amount of data.
3) processing is slower.
4) error log is created
5) data is not updated until session is processed.

Call transaction.
1) asynchronous processing
2) can transfer small amount of data
3) processing is faster.
4) errors need to be handled explicitly
5) data is updated automatically

SAP LSMW Tools Steps | Migrate data using LSMW

LSMW Tools

LSMW stands for legacy system migration workbench and it is a special form of data
migration that is used in SAP, to transfer data from legacy systems and to the SAP system.
LSMW is ideal for master data, and does not require too much coding. Even a non-specialist
in ABAP who is using the SAP system can easily use LSMW. That is why functional
consultants rather than technical consultants use LSMW for data migration. LSMW may have
the same functionality as a BDC program, but lacks in complexity and should only used for
simple transactions. There are 14 steps in LSMW, here we describe each of the 14 steps.

First, before carrying out the 14 LSMW steps, we create the project.

Creating Project/ Subproject and Object:

Step 1: - Enter the transaction code “LSMW” in command field and enter.

Step 2: - On the legacy system migration workbench screen, update the following fields.

1. Project: – Update name of Project, you can update up to ten characters.

2. Subproject: - Update the subproject ID
3. Object: - Update the object ID that identifies the business object.
Step 2: – From the menu bar, select “Goto” and then click on “Recordings”. Next click on
create icon and update recording name and its description.

Now Enter in transaction code ‘PA30’

.> In the Master data maintain screen, enter Personnel No, infotype, subtype and click on
“create”.

> Now Update fields start data, Name and additional data.

> Click on save button and save the data.

> In next screen, click on default all and save the data and come back

Now, we perform the 14 basic steps in LSMW.

Step 1: Maintain Object Attributes

> Locate object attributes on the radio button, click execute.

> Click Display/ Change. Enter the type of recording to be done while doing upload.

> Select ‘Batch Input Recording’ and give a recording name.

> Save and come back.

Step 2: Maintain Source Structures

> This is for building hierarchical relationships.

> Select source structure, click create

> Save and come back.

Step 3: Maintain Source Fields

> All the fields are assigned to be uploaded to the source structure.

> Go to, Object Overview, select table

> Go to change, select the source field and then Table.

> Copy the fields in excel – for now

> Save and come back.

Step 4: Maintain Structure Relations

> We check whether structure relations between legacy and R/3 are established or not.

> Don’t do anything here, just save and come back.

Step 5: Display Field Mapping and Conversion

> The relationship between legacy and R/3 based on object fields is established here.

> Go to extra, click on Auto Field Mapping.

> Upload the fields now.

Step 6: Maintain Fixed Values, Translations, User-Defined Routines

> Don’t do anything in this step.

Step 7: Specify Files

> Here, specify the location of the legacy file.

> Select legacy data from the folder in your computer.

> Double Click on Legacy Data and go to the Path,

> Save , come back

Step 8: Assign Files

> Check whether the file is assigned to source structure or not.

> Save and come back

Step 9: Read Data

> The legacy data is read here

Step 10: Display Read Data

> The data is displayed by giving line numbers.

Step 11: Convert Data

> The data is converted to SAP standards.

Step 12: Display Converted Data

> The converted data is viewed for cross checking

Step 13: Create Batch Input Session

> Batch input session is created

Step 14: Run Batch Input Session

> The batch input session is run

> Just Select Session and execute process

> The legacy data is now uploaded into the SAP system.

Successfully SAP Data is migrated by using LSMW.

SAP Scripts Tutorial and SAP Script program

SAP Scripts

SAP script is a text processing system where it is similar in scope and form as the best
text processing systems in the world. SAP Scripts make use of pre-formatted forms to
print pre-formatted text.

Components of SAP Scripts

The important five components of SAP Scripts are as follows,

1. Editor: – which is used to enter lines of text and to edit them.

2. Styles & Layouts Sets: – It is used to print layout, and creates individual
texts.
3. Composer: – It is a output module and not visible to the user.
4. Programming interface: – This is the interface that makes it possible for the
programmer to include SAP script components in their application programs and to
control how the layout sets outputs are displayed.
5. Database: – SAP Scripts uses many database tables which are capable of
storing large amounts of texts, sets and styles.

What is a Layout Set in SAP Script?

The purpose of layout sets is to display documents in output form . SAP Script layout
sets do not contain any data but are used to describe how the text elements are
incorporated into the program and printing is done and may be considered the page
design for the document.

Components of SAP Script Layout: – The important components of SAP script

layout are as follows
1. Header Data: – It controls how printing is done and it consists of Starting page,
paragraph, , Page format, Language and so on.

2. Paragraph, Font and Character Formats: – Paragraph attributes are page margin,
Alignment, etc. Font attribute is the type of font, size and so on.

3. Windows and Text Elements: – Windows are independent text areas such as header
address, date and footer placed in a page. Windows group the information presented in
a document into groups which appear on the printed page in their own area. Text
elements are used by the print program by their names and then formatted and printed
in their own window.

4. Pages: – They independent pages contained in the document with their own name.
Each page may have a different layout and may have different data.

5. Page Windows : – Page windows are elements that contains the page and specify the
area with width and height.

Function Modules used in SAP Scripts are OPEN_FORM, CLOSE_FORM,

START_FORM, WRITE_FORM, END_FORM

Print Program
The execution of script is done through an ABAP program, which is referred as Print
Program. Each print program should have an ENTRY form , which will be called from
customization.
For a standard configuration we can see the form name (script name), print program
name and output type in the table TNAPR. The print program uses the Form control
functions to call the script.
The print program call either all or some of the form control functions to execute the
script

OPEN_FORM (Mandatory) Opens the layout set output

CLOSE_FORM (Mandatory) Ends the layout set output
START_FORM (Optional) Starts a new layout set
WRITE_FORM (Mandatory) Calls a layout set element
END_FORM (Optional) Ends the current layout set

Standard Texts and Graphics

Standard Texts for your report can be created using transaction SO10
Graphics and printer macros are uploaded with report RSTXLDMC into individual
standard text documents or through transaction SE78. Graphics are uploaded in
"Baseline TIFF 6.0" format (.tif files on PC)
SAP Script & Standard text elements can exported or imported between two systems
using RSTXSCRP program
Copying Scripts Across clients:
SAP Script is a client dependent object.Unlike programs, changes done to SAP script in
one client will not be reflected in other clients. For copying script from one client to
another, go to SE71 and use "Copy from Client" option available under Utilities menu
or import the transport request, in which the script is saved, from the original client
using the transaction SCC1 .
Important Points to Note
 SAP script does not maintain any versions. So when modifying the SAP script ,
ensure that the changes are well documented in script. This applies to the standard texts
too.

 The output of the form will differ when viewed on the screen and on the printer. So
always test the output of the script on the printer.

SMARTFORMS

SAP Smart Forms is used to create and maintain forms for mass printing in SAP
Systems.As output medium SAP Smart Forms support a printer, a fax, e-mail, or the
Internet (by using the generated XML output).
SAP introduced SmartForms in 1998 to overcome the limitations in SAP Scripts.
SmartForms are easier to develop, maintain and transport than SAP Script.

Smart Forms and SapScripts Comparison

 Multiple page formats are possible in SmartForms which is not the case in
SAPScripts

 It is possible to have a SmartForm without a main window.

 Routines can be written in SmartForms tool.

 SmartForms generates a function module when activated.

 Labels cannot be created in SmartForms.

Advanatges of Smart Forms

 They help adapting forms without any programming knowledge due to
entirely graphical user interface

 When activating the smart form the system automatically generates the
function module and at the runtime .

 To make any changes we have to use the Drag & Drop, Cut & Paste. These
actions do not include writing of coding lines or using a script language.

 We can insert static and dynamic tables. These include the line feeds in the
individual table cells, triggering events for table headings and subtotals and sorting
data before output.

 The smart forms allow the user to include graphics, which can be displayed as
a part of the form or as background graphics. During printout the user can suppress
the background graphic as and when necessary.

 Web Publishing is possible using the generated XML output

Introduction to SAP SmartForms

What is SAP Smart Forms?

SAP Smart Forms is introduced in SAP Basis Release 4.6C as the tool for creating and
maintaining forms.

SAP Smart Forms allow you to execute simple modifications to the form and in the form
logic by using simple graphical tools; in 90% of all cases, this won't include any
programming effort. Thus, a power user without any programming knowledge can
configure forms with data from an SAP System for the relevant business processes.

To print a form, you need a program for data retrieval and a Smart Form that contains the
entire from logic. As data retrieval and form logic are separated, you must only adapt
the Smart Form if changes to the form logic are necessary. The application program
passes the data via a function module interface to the Smart Form.
When activating the Smart Form, the system automatically generates a function
module. At runtime, the system processes this function module.

You can insert static and dynamic tables. This includes line feeds in individual table
cells, triggering events for table headings and subtotals, and sorting data before
output.

You can check individual nodes as well as the entire form and find any existing errors in
the tree structure. The data flow analysis checks whether all fields (variables) have a
defined value at the moment they are displayed.

SAP Smart Forms allow you to include graphics, which you can display either as part of
the form or as background graphics. You use background graphics to copy the layout of
an existing (scanned) form or to lend forms a company-specific look. During printout,
you can suppress the background graphic, if desired.

SAP Smart Forms also support postage optimizing.

Also read SAP Note No. 168368 - Smart Forms: New form tool in Release 4.6C

What Transaction to start SAP Smart Forms?

Execute transaction SMARTFORMS to start SAP Smart Forms.

Key Benefits of SAP Smart Forms:

SAP Smart Forms allows you to reduce considerably the implementation costs of
mySAP.com solutions since forms can be adjusted in minimum time.

You design a form using the graphical Form Painter and the graphical Table Painter. The
form logic is represented by a hierarchy structure (tree structure) that consists of
individual nodes, such as nodes for global settings, nodes for texts, nodes for output
tables, or nodes for graphics.

To make changes, use Drag & Drop, Copy & Paste, and select different attributes.

These actions do not include writing of coding lines or using a Script language.
Using your form description maintained in the Form Builder, Smart Forms generates a
function module that encapsulates layout, content and form logic. So you do not need
a group of function modulesto print a form, but only one.

For Web publishing, the system provides a generated XML output of the processed
form.

Smart Forms provides a data stream called XML for Smart Forms (XSF) to allow the use
of 3rd party printing tools. XSF passes form content from R/3 to an external product
without passing any layout information about the Smart Form.

Advantages of SAP Smart Forms

SAP Smart Forms have the following advantages:

1. The adaption of forms is supported to a large extent by graphic tools for layout and
logic, so that no programming knowledge is necessary (at least 90% of all adjustments).
Therefore, power user forms can also make configurations for your business processes
with data from an SAP system. Consultants are only required in special cases.

2. Displaying table structures (dynamic framing of texts)

3. Output of background graphics, for form design in particular the use of templates
which were scanned.

4. Colored output of texts

5. User-friendly and integrated Form Painter for the graphical design of forms

6. Graphical Table Painter for drawing tables

7. Reusing Font and paragraph formats in forms (Smart Styles)

8. Data interface in XML format (XML for Smart Forms, in short XSF)

9. Form translation is supported by standard translation tools

10. Flexible reuse of text modules

11. HTML output of forms

12. Interactive Web forms with input fields, pushbuttons, radio buttons, etc.

Difference with SMARTFORMS vs. SapScript (SE71)

The Following are the differences :-

a) Multiple page formats are possible in smartforms which is not the case in SAPScripts

b) It is possible to have a smartform without a main window .

c) Labels cannot be created in smartforms.

d) Routines can be written in smartforms tool.

e) Smartforms generates a function module when activated.

f) Unlike sapscripts (RSTXSCRP), you cannot upload/download Smartform to your

local harddisk.

It was said that it was provided in CRM 3.0 version, but not available in R/3. You can
download smartforms into Local PC in a XML format. In the same way you can upload
this XML format into Smartform. From the smartform editor itself you can call
download option, if you are working in CRM 3.0 environment.

In R3 also, you can download into XML format. However, it's not sure about uploading.
Refer to the program 'SF_XSF_DEMO'.

In 4.7 Enterprise, other have seen this utility which is completely missing in 4.6c. There
is functionality to download a complete form or only a particular node. (Utilities ->
Download form). It will create a XML file and save it in the hard disk.

For others, if you want to download/upload the Smartforms source, you will need
the help from the Basis people. What you can do is to create a Transport and then
FTP down to your local harddisk. When you need the Smartform source in another
system, you have FTP up the Smartforms file back to the SAP server. Finally, the
Basis team, will tp it into your system.

g) The protect and endprotect command in sapscript doesn't work with smartforms.
For example on a invoice: First data of position no 80. is printed on page one, other data
of position no 80 is printed on page 2. And there's nothing you can do about it. Actually,
there is something you can do about it. By using a folder node and checking the
'protect' checkbox, everything in that folder will be page protected.

i) The main difference is that SAP script is client-dependant, while smartform is

independent.

ABAP TRANSACTION CODES

SE01 Transport Organizer(Extended View)

SE06 Set up workbench organizer

SE09 Transport organizer

SE10 Customizing organizer

SE11 Data dictionary maintenance`

SE12 Data dictionary display

SE15 Repository Info System

SE16 Display table content

SE17 General table display

SE37 ABAP Function Modules

SE38 ABAP Editor

SE41 Menu Painter

SE51 Screen Painter

SE71 Form Painter

SE80 Object Navigator

SE93 Maintain Transaction

SHDB Transaction Recorder

SM35 Batch Input Monitoring

SALE ALE customizing transaction

NACE conditions of output control (to create a link between forms

and driver programs)

ST05 SQL tracer (for performance tunning)

SE30 ABAP runtime analysis(Performance tuning)

SE72 SAPscript Styles

SE73 SAPscript Font Maintenance

SE74 SAPscript format conversion

SE75 SAPscript Settings

SE76 SAPscript: Form Translation

SE77 SAPscript Styles Translation

Smartforms Smartforms
Transaction codes are stored in the table TSTCT with their corresponding texts.