SAP ABAP support by bob panic www.rockstarconsultinggroup.com

Introduction to SAP ABAP Development by Bob Panic
www.rockstarconsultinggroup.com 1

Introduction to ERP (Enterprise resource planning)
There are many different systems in a large company's including planning,
manufacturing, distribution, shipping, and accounting.
Enterprise resource planning (ERP) is a system that integrates all of these functions into a
single system, designed to serve the needs of each different department within the
enterprise. ERP is more of a methodology than a piece of software, although it does
incorporate several software applications, brought together under a single, integrated
interface.
Enterprise resource planning (ERP) systems integrate primary business applications; all
the applications in an ERP suite share a common set of data that is stored in a central
database. A typical ERP system provides applications for accounting and controlling,
production and materials management, quality management, plant maintenance, sales and
distribution, human resources, and project management.
Why should you be interested? Because, basically, a well-implemented and appropriate
ERP system can create significant efficiencies across your business, resulting in timely
business information, better customer relationships, a more cost-effective supply chain,
improved internal process and, ultimately, increased profitability.
The ERP system goes far beyond being just a simple piece of software. Each
implementation is unique and is designed to correspond to the implementer's various
business processes. Regardless of how a company approaches it, ERP is sure to bring
significant changes to how a company does business. An ERP implementation can cost
millions of dollars to create, and may take several years to complete.
Once implemented however, the ERP system brings tremendous advantages. Because all
systems are joined together, all departments can more easily share information. The
workflow that takes place between departments can become much more automated, and
ultimately, customers are better served because the individual using the customer-facing
applications will have access to every bit of information regarding each relevant process.
For example, someone in sales would easily be able to log into a single system to
determine the status of a customer order that is still in manufacturing. All this comes at a
cost though; training costs are high because employees must not only learn how to use
new software, they must also learn new processes.

ERP Improves Productivity
Before ERP systems, each department in an organization would most likely have their
own computer system, data and database. Unfortunately, many of these systems would
not be able to communicate with one another or need to store or rewrite data to make it
possible for cross computer system communication. For instance, the financials of a
company were on a separate computer system than the HR system, making it more
intensive and complicated to process certain functions.
Once an ERP system is in place, usually all aspects of an organization can work in
harmony instead of every single system needing to be compatible with each other. For
large organizations, increased productivity and less types of software are a result.
Implementing Enterprise Resource Planning
ERP software is complex and expensive. Companies must devote significant human
resources to ERP projects and often hire consultants or systems integrators to help
implement the systems. As a result, the company can spend millions of dollars and
several years on ERP projects. This report outlines the challenges companies should
expect for ERP implementation and outlines the six main steps of an ERP project:
• Vendor Selection
• Business Strategy Formation
• Application Configuration
• Testing and End-user Acceptance
• Training
• Rollout
Benefits of implementing ERP systems:
• Inventory Reduction
• Improved Cash Management
• Increased Revenue and Profits
• Reduced Transportation and Logistics Costs
• Reduced Information Technology (IT) Costs
Intangible benefits include unanticipated cost reductions, improved responsiveness to
customers, more flexibility, and more effective management of the supply chain.

Advantages of ERP Systems
There are many advantages of implementing an EPR system; here are a few of them:
• A totally integrated system
• The ability to streamline different processes and workflows
• The ability to easily share data across various departments in an organization
• Improved efficiency and productivity levels
• Better tracking and forecasting
• Lower costs
• Improved customer service
Disadvantages of ERP Systems
While advantages usually outweigh disadvantages for most organizations implementing
an ERP system, here are some of the most common obstacles experienced:
Usually many obstacles can be prevented if adequate investment is made and adequate
training is involved, however, success does depend on skills and the experience of the
workforce to quickly adapt to the new system.
• Customization in many situations is limited
• The need to reengineer business processes
• ERP systems can be cost prohibitive to install and run
• Technical support can be shoddy
• ERP's may be too rigid for specific organizations that are either new or want to
move in a new direction in the near future.
ERP software packages Available in the Market
Baan from Infor Global Solutions: The Baan Corporation provides the financial and
administrative consulting services.
JD Edwards Enterprise One & JD Edwards World from Oracle: JD Edward is into
accounting business software development and an ERP system JDE comprises 3 basic
areas of expertise, functional-business, and programmer-developer and technical-CNC-
system administration.
Oracle e-Business Suite from Oracle : Oracle is into finance applications and Oracle
relational database management system technology
PeopleSoft from Oracle: PeopleSoft is into Human resource management systems
(HRMS) applications

SAP R/3 from SAP: The most widely used modules in this ERP are Financials and
Controlling (FICO), Human Resources (HR), Materials Management (MM), Sales &
Distribution (SD), and Production Planning (PP) and it’s an integration around 25
modules. It’s the biggest ERP package in the Market.
Many more ERP packages are available in the market.
------
Enterprise:-Organization or Business oriented company.
Resource: - Man, Money, Machines and materials etc.
Planning:-Plans to maximum utilization of resources with cost minimization.
The ultimate aim of using ERP is planning with the available resources of an enterprise to
get the maximum output with cost minimization.
------
What is SAP
SAP was founded in 1972 by five former IBM engineers in Mannheim, Germany
(Dietmar Hopp, Hasso Plattner, Klaus Tschira, Claus Wellenreuther and Hans-Werner
Hector) and its headquarters in Walldorf Germany and since the 2005 annual general
meeting the company’s official name is just SAP AG.
The acronym of SAP is “Systems, Applications and Products in Data Processing" SAP is
the largest software company in Europe and the third largest in the world. It ranks after
Microsoft and IBM in terms of market capitalization. SAP is also the largest business
application and Enterprise Resource Planning (ERP) solution and software provider in
terms of revenue.
Products
SAP's products focus on Enterprise resource planning (ERP), which it helped to pioneer.
The company's main product is mySAP ERP. The name of its predecessor, SAP R/3
gives a clue to its functionality: the "R" stands for real-time data processing and the
number 3 relates to a 3-tier architecture: database, application server and client (SAPgui).
R/2, which ran on Mainframe architecture, was the first SAP version.
Other major product offerings include Advanced Planner and Optimizer (APO), Business
Information Warehouse (BW), Customer Relationship Management (CRM), Supply
Chain Management (SCM), Supplier Relationship Management (SRM), Human Resource
Management Systems (HRMS), Product Lifecycle Management (PLM), Exchange
Infrastructure (XI), Enterprise Portal (EP) and SAP Knowledge Warehouse (KW).The
APO name has been retired and rolled into SCM. The BW name (Business Warehouse)

has now been rolled into the SAP NetWeaver BI (Business Intelligence) suite and
functions as the reporting modules.
The company also offers a new technology platform, named SAP NetWeaver. While its
original products are typically used by Fortune 500 companies, SAP is now also actively
targeting small and medium sized enterprises (SME) with its SAP Business One and SAP
All-in-One.According to SAP AG there are over 100,800 SAP installations serving more
than 38,000 companies. SAP products are used by over 12 million people in more than
120 countries.
1. The name SAP is acronym for Systems, Applications and Products in Data Processing.
SAP is an extremely complicated system where no one individual can understand all of it.
2. SAP runs on a fourth generation programming language called Advance Business
Application Programming (ABAP). It has many of the features of other modern
programming languages such as the familiar C, Visual Basic, and Power Builder. Your
programs name conventions begins with a letter yxxx or zxxx.
3. SAP graphical user interfaces (SAPGUI) runs on Windows / NT / Unix / AS400.
4. SAP is an enterprise resource planning (ERP) software product capable of integrating
multiple business applications, with each application representing a specific business
area. These applications update and process transactions in real time mode. It has the
ability to be configured to meets the needs of the business.
SAP R/3 is a client/server based application, utilizing a 3-tiered model. A presentation
layer, or client, interfaces with the user. The application layer houses all the business-
specific logic, and the database layer records and stores all the information about the
system, including transactional and configuration data.
SAP R/3 functionality is structured using its own proprietary language called ABAP
(Advanced Business Application Programming). ABAP, or ABAP/4 is a fourth
generation language (4GL), geared towards the creation of simple, yet powerful
programs. R/3 also offers a complete development environment where developers can
either modify existing SAP code to modify existing functionality or develop their own
functions, whether reports or complete transactional systems within the SAP framework.
ABAP's main interaction with the database system is via Open SQL statements. These
statements allow a developer to query, update, or delete information from the database.
Advanced topics include GUI development and advanced integration with other systems.
With the introduction of ABAP Objects, ABAP provides the opportunity to develop
applications with object-oriented programming.

The most difficult part of SAP R/3 is its implementation, since SAP R/3 is never used the
same way in any two places. For instance, Atlas Copco can have a different
implementation of SAP R/3 from Procter & Gamble. Some companies may run multiple
productive clients/systems or even multiple instances of SAP R/3. This is seen, for
example, when a company running R/3 acquires a new business already running R/3.
They may elect to keep both systems separate, migrate one into the other, or migrate both
onto a completely new instance.
The system landscape is ultimately the customer's decision. There are definite pros and
cons on the continuum from single global instance / productive client (master data,
impact of configuration changes on multiple business units) to separate instances per
business unit (hardware costs and communication between instances/clients)
Two primary issues are the root of the complexity and of the differences:
• Customization configuration - Within R/3, there are tens of thousands of database
tables that may be used to control how the application behaves. For instance, each
company will have its own accounting "Chart of Accounts" which reflects how its
transactions flow together to represent its activity. That will be specific to a given
company. In general, the behavior (and appearance) of virtually every screen and
transaction is controlled by configuration tables. This gives the implementer great
power to make the application behave differently for different environments. With
that power comes considerable complexity.
• Extensions, Bolt-Ons - In any company, there will be a need to develop interface
programs to communicate with other corporate information systems. This
generally involves developing ABAP/4 code, and considerable "systems
integration" effort to either determine what data is to be drawn out of R/3 or to
interface into R/3 to load data into the system.
Due to the complexity of implementation, these companies recruit highly skilled SAP
consultants to do the job. The implementation must consider the company's needs and
resources. Some companies implement only a few modules of SAP while others may
want numerous modules.
SAP has several layers. The Basis System (BC) includes the ABAP programming
language, and is the heart (i.e. the base) of operations and should not be visible to higher
level or managerial users. Other customizing and implementation tools exist also.
------
Implementation Tools for ERP Systems
There are multiple tools available to assist in the management of ERP implementation
projects. SAP R/3, for example, provides an Implementation Roadmap that is broken up

into five phases. Each phase includes documentation and planning tools to help the phase
move towards completion. The five phases and their respective tasks include:
• Project Preparation
o Building of the project team.
o Designing the system (This includes network, hardware, and software
requirements).
o Selecting ERP vendors.
o Defining the project’s scope.
• Business Blueprint
o In this phase project team members decide and document how the
business and business processes will function with the implementation of
the ERP system. These decisions will guide the configuration of the ERP.
o Determination of methods to transfer or integrate legacy system
information into the ERP system will also occur in this phase.
• Realization
o Configuration of the ERP system occurs in this phase. Configuration
guidelines are based on documentation from the Business Blueprint phase.
o Legacy system connections are developed in this phase.
• Final Preparation
o Testing of the new ERP system.
o Development of the Help Desk and Help Desk Procedures.
o Migration of existing data.
o User training.
o Schedule a Roll-Out date.
• Roll-Out
o ERP system becomes part of everyday activities.
o Help Desk fields questions about ERP system.
o Monitoring of the ERP system starts in this phase.
o Monitoring of the ERP system starts in this phase.
The time required for each one of these phases differs from project to project based on
the size of the implementation, dedication to the project…etc. Oftentimes the finished
project’s scope differs from the original scope’s documentation causing projects to go
overtime and over budget. When this happens, it is usually testing and training that get
cut short which jeopardize the overall success of the project.
-----
Why SAP

1. SAP is a platform independent; it can support various databases like Oracle, SQL
Server.
2. SAP also supports various operating systems.
3. The integrity between its various modules makes SAP more users friendly.
Areas of SAP
There are three areas in SAP.
1. Functional Area
There are more than 25 functional modules in SAP.
Those who work on functional areas are called Functional Consultants.
Ex: - PP – Production planning
MM- material management
SD- Sales and Distribution
FI- Financial Accounting
CO- Controlling
HR- human Resources
PM- Plant Maintenance. Etc.
2. Technical Area
Here the technical consultants i.e. ABAPers are working.
Technical Consultants will implant the ideas of functional Consultants.
3. Basis Area
Here the basis people will work.
The following works are generally done here
Creation users, Authorization, Dispatcher and Role Allocation
R/3 System Architecture
R/3 is an integrated group of applications designed to handle the data processing for large
corporations. The purpose of an R/3 system is to provide tightly integrated large scale
business applications.
The below figure shows the structure of R/3 Architecture. The architecture contains four
layers as Presentation Servers, Application Servers, Database Servers and Database.

PS: - Presentation Servers
AS: - Application Servers
DBS: - Database Server
DB: - Database
Presentation Servers - The Presentation server is actually a SAPGUI or the user
interface. The interface accepts input from the user in the form of keystrokes, mouse
clicks and function keys, sends these requests to the application server to be processed.
The application server sends the results back to the SAPGUI which then formats the
output display to the user.
Application Server – The application server is a set of executables that collectively
interpret the ABAP/4 programs and manage the input and output for them. When an
application server is started, these executables all start at the same time. When an
application server is stopped, they all shut down together.
Each application server has a profile that specifies its characteristics when it starts up and
while it is running. For example, an application severs profile specifies:
• Number of processes and their types
• Amount of memory each process may use
• Length of time a user is inactive before being automatically logged off
The application server exists to interpret ABAP/4 programs, and they only run there-the
programs do not run on the presentation server. If your ABAP/4 program requests
www.rockstarconsultinggroup.com
PS PS
AS AS
DBS
DB
10

information from the database, the application server will format the request and send it
to the database server.
Database Server - The database server is a set of executables that accept database
requests from the application server. These requests are passed on to the RDBMS
(Relation Database Management System). The RDBMS sends the data back to the
database server, which then passes the information back to the application server. The
application server in turn passes that information to your ABAP/4 program and then you
will get the required output on your presentation server.
Database – Database is nothing but a collection of data arranged for ease and speed of
search and retrieval OR A database is a structured collection of records or data that is
stored in a computer system.
Application Server Architecture
All requests that come in from presentation servers are directed first to the dispatcher.
The dispatcher writes them first to the dispatcher queue. The dispatcher pulls the requests
from the queue on a first-in, first-out basis. Each request is then allocated to the first
available work process. A work process handles one request at a time.

To perform any processing for a user's request, a work process needs to address two
special memory areas: the user context and the program roll area. The user context is a
memory area that contains information about the user, and the roll area is a memory area
that contains information about the programs execution.
USER Context
A user context is contains information about the user like about user name, login id and
which program is running currently.
Roll Area.
It’s a memory allocated by the work process for an instance of a program It contains
information about the recent program which is executing currently
Value of variables, Dynamic Memory Allocation and Pointers to work Process.
Instance: - The term instance means application server
The term central instance means database server
In general the term instance means server.
Roll In: - When a job is assigned to a work process it creates pointers to the user context
and roll area this process is called Roll In.
Roll Out: - After the execution of the job the pointers assigned to both user context and
roll area are deleted this process is called Roll Out.
Dialog Steps: - This is the time taken by the systems to show the next screen from
existing screen is called as dialog step.
Work process
This is the area in which actual work is done. There are seven types of work process each
handles a specific type request.
1. Dialog or Online Process- for Dialog request.
2. Update Process- Request to update data in database.
3. Background Process- Background jobs.
4. Spool Process- print spool request.
5. Enque Process – Logical lock requests
6. Message Process- Routes messages between application server with in an R/3
system
7. Gateway Process- Funnels Messages into and out of the R/3 system.
Components of Work Process

Each Work Process is composed of the following
1. A task handler
2. An ABAP/4 Interpreter
3. A screen Interpreter.
4. A Database Interface
All requests pass through the task handler, which then funnels the request to the
appropriate part of the work process and the Interpreters Interpret the ABAP/4 code.
Messages (6 types)
1. S (Success): Green color status bar.
2. E (Error): Red color status bar.
3. W (Warning): Yellow color status bar.
4. I (Information): In a pop-up box.
5. A (Abort): In a pop-up box.
6. X (Exit): Comes out of the program
Three tier architecture of R/3
Database Server
Application Server
Presentation Server
(Unlike normal Client/server architecture where you have only two layers i.e., client and
server.) Communication among the 3 tiers is accomplished by standard protocol services
like TCP/IP or CPIC (Common Programming Interface Communication).
Database
Application Application Application
Presentation Presentation Presentation Presentation Presentation Presentation

In above case database server stores the data centrally. Basically contains database
engine and associated processes. The database layers contain the database system used
by all servers.
Application server contains software components to run the program. It contains a SAP
kernel, which can run ABAP/4 program.
The presentation server is your client through which you send your request to application
server. It is also called as SAP graphical user interfaces known as SAPGUI and is
available in windows 3.1, Windows NT, Windows 95, and Macintosh. They all look
similar whatever underlying system they are running on.
The SAPGUI includes all graphical capabilities of window interface with menu bars, tool
bars, focus property, and the entire mouse clicking operations.
The R/3 system is open system in the sense that it can run on any operating system or any
database and any communication technology. It means that:
♦ R/3 system can run on any operating system platform such as UNIX, NT, 95, AS/400.
♦ It supports various RDBMS such as SQL server, Oracle, Informix, DB2.
♦ Standard GUIs supported by R/3 are Windows 95, NT, Windows 3.1, and Macintosh.
♦ SAP can use standard communication protocols TCP/IP, CPIC, OSF/DCE/DME for
network.
Using SAP’s Open SQL
ABAP/4 code is portable between databases. To access the database in an ABAP/4
program you will code SAP’s open SQL. Open SQL is a subset and variation of ANSI
SQL. The ABAP/4 Interpreter passes all open SQL statements to the database interface
part of the work process. There they are converted to SQL i.e. native to the installed
RDBMS. For example if you were running an Oracle database your ABAP/4 Open SQL
would be converted by the database interface to Oracle SQL statements.
If you use Open SQL, your SQL statements will be passed to the database interface.
Using Open SQL has three advantages. All of these advantages are implemented via
database interface.
Advantages using Open SQL
1. Buffering Data on the Application Server.

The database interface buffers information from the database on the application
server, when data is read from the database, it can be stored in buffers on the application
server. If a request is then made to access the same records, they would already be on the
application server and the request is satisfied from the buffer without having to go the
database. This buffering technique reduces the load on the database server and on the
network link between the database and application servers and can speed up database
access time by a factor of 10 to 100 times.
2. Portability: - The SQL statements will be portable between databases. For
example, if for some reason your company wanted to switch from an Oracle to an
Informix database, it could change the database and your ABAP/4 code would
continue to run without modification.
3. Automatic client handling:-With Open SQL the client field is automatically
populated by the database interface. This gives your development and testing
teams may advantages. Such as the ability to perform multiple simultaneous
testing and training on a single database without interface from each other
WORKING WITH R/3 system
The SAP R/3 presentation interface behaves very similarly to any other typical window
application and is also known as SAPGUI. The first screen that you come across in R/3
system is SAP logon screen.
SAP R/3 logon Screen
This is the first screen that appears when you use SAP logon utility. It has four fields: the
client, the user, the password and the language.

♦ Client: Here you enter the client number. The client is group of users who has
similar rights. It can be group of users in a business entity or a whole business entity
or a whole company.
♦ User: The name of the SAP user identification. Users of the SAP system are client-
specific, which means that user belonging to one client is valid to only the particular
client.
♦ Password: It is the password that has been assigned by the system administrator.
♦ Language: SAP R/3 system supports multinational language on the same system at
the same time, which is very useful for multinational companies with different
branches in several countries and possibly using different languages.
After entering all the fields press ENTER key and system will take you to MAIN MENU
screen.
User might get different screens when he logs on, depending upon default settings of the
user master record i.e., if user is DEVELOPER then the screen which he often works on
is editor screen and he can go directly to this screen, if system administrator sets this
screen for the user.
Main features of any R/3 window are as follows:
♦ R/3 standard window elements behave exactly the same, as any other standard
window application would, like minimizing a screen, setting the active window etc.
♦ From TOP to BOTTOM, R/3 window can contain typical elements such as check
boxes, push buttons, input fields and following elements:

♦ Menu bar is the first element of the every R/3 window. It contains the menu item
corresponding to the particular R/3 application. The two menu options SYSTEM and
HELP are always present in every R/3 window. SYSTEM menu option contains all
utilities and functions, and is available to user at all the times. The HELP menu
contains all the available options for the different types and methods of obtaining
online help in the system.
♦ Standard tool bar. The second R/3 window element is present in every R/3
window. It is nothing but a collection of icons, which perform common functions
like saving the object, exit etc. The various icons on std. Tool bar are as follows
(from left to right):
♦ Application tool bar: The next part of the screen contains icons most commonly
used in that particular task or transaction.
♦ Status bar is the bottom line of the screen and usually shows errors or information
messages to the user. It also includes other information such as system id, session
number, client, server name and the response time.
Logging Off
User can log off the R/3 system from any screen. There are three ways of logging off the
R/3 system, which are as follows:
♦ From the Menu bar choose SYSTEM → LOG OFF. In this case, you get the log off
dialog box, which informs the user that any data not saved will be lost if continuing
with the log off procedure.
♦ Use/NEX transaction code in the command field. This is dangerous, since it does not
ask if you want to save the data.
♦ Clicking on the EXIT button on the R/3 initial screen.

Getting help in the R/3 system
R/3 includes many possibilities to get online help for almost every element of the system,
users can get help for entire application, for specific function, for definitions of various
terms used in SAP, i.e., Glossary, messages, screens, fields etc.
You obtain HELP by using any of the following options:
♦ Help function from the R/3 window, which is compulsory menu item of every R/3
window.
♦ ? Icon of standard tool bar.
♦ F1 function key.
The SAP system provides help on most fields that appear on the R/3 system. To get help
on particular field, position the cursor over it and press help button or F1 function key.
Another way in which R/3 system provides help is when system displays error messages
in the status bar. Double clicking on the status bar shows additional information about
the message.

ABAP/4 Development Workbench
The development environment of SAP R/3 system is fully integrated set of various
development tools, data dictionary, and programming language. Full integration of all
components means that changes in any part have a direct and immediate effect on all
application using those components.
The screen of ABAP/4 development workbench looks like
Tools of ABAP/4 workbench
For programming:
♦ ABAP/4 dictionary Defining, maintaining and storing the data dictionary of the SAP
R/3 system stores all the dictionary objects including tables relationship and Help
information. Transaction code for this is SE11.
♦ ABAP/4 editor Creating and maintaining the ABAP/4 program, editing function
modules, logical database, and screens. Transaction code is SE38.

♦ Function library Defining and maintaining the ABAP/4 function modules.
Transaction code is SE37.
♦ Screen painter Designing and maintaining the screens in transaction. Transaction
Code is SE51.
♦ Menu painter Designing and maintaining the means for graphical user interface.
Transaction code SE41.
For Navigating:
♦ Object browser Managing and organizing the development object in a hierarchical
form. Transaction code is SE80.
♦ ABAP/4 repository information Navigating and searching for the dictionary Objects,
development objects and relationship objects. Transaction code SE84.
♦ Data browser Navigating in the data tables of the database. Transaction code is SE
16.
For Debugging:
♦ SOL trace tracking the database calls from the system transaction and programs.
Transaction code is ST05.
♦ Debugger Stopping the program and analyzing the results of the execution of every
program statement.
♦ Runtime Analysis Analyzing the performance the system calls Transaction code is
SE30
For Organizing:
♦ Workbench organizer controlling and keeping track of development work and team
related development projects and managing versions of development objects.
Transaction code is SE09.
♦ Transport system performing and managing the transport of development object
across different system. Transaction code is SE01

What is ABAP/4 ?
ABAP (Advanced Business Application Programming) is a programming language for
developing applications for the SAP R/3 system. ABAP is one of many application-
specific fourth-generation languages (4GLs) first developed in the 1980s. The most basic
functions were written in ABAP. ABAP/4 is the language created by SAP AG for
implementation and customization of their R/3 system.
The ABAP programming language was originally used by developers to develop the SAP
R/3 platform. ABAP was one of the first languages to include the concept of Logical
Databases (LDBs), which provides a high level of abstraction from the basic database
level.
It was also intended to be used by SAP customers to enhance SAP applications –
customers can develop custom reports and interfaces with ABAP programming. The
language is fairly easy to learn for programmers but it is not a tool for direct use by non-
programmers. Good programming skills, including knowledge of relational database
design and preferably also of object-oriented concepts are required to create ABAP
programs.
The ABAP/4 Development Workbench contains all tools you need to create and maintain
ABAP/4 programs. ABAP/4 programs are not complied but generated. During
generation, the system creates a so-called runtime object from the source code and the
program attributes. When you start the program, the system executes the runtime object.
ABAP/4, a fourth generation language, contains all usual control structures and
modularizing concepts for structured programming.
Characteristics of the ABAP/4 programming languages
♦ Declarative elements for declaring data of different type and structures.
♦ Operational elements for manipulating data.
♦ Control elements to control processing flow.
♦ ABAP/4 is multi-lingual. Text elements such as titles, headings, and text body are
stored separately, independent of the program codes. Thus, you can change, translate,
and maintain text elements without having no adapt the coding.
♦ ABAP/4 supports business-related data types and operations. You can execute
calculations using special data and time fields. The system automatically executes all
necessary type conversions.
♦ ABAP/4 provides a number of functions for processing character strings.

♦ ABAP/4 allows you to define and call subroutines. You can even call subroutines of
other programs. There are different ways of how to pass parameters to and from the
Subroutines.
♦ ABAP/4 contains a special type of subroutine, called function module. Function
modules are stored and maintained in a central library. They have clearly defined
data interfaces to the calling program. You can test function modules in a stand-alone
mode independent of the calling program.
♦ ABAP/4 contains an SQL subset called OPEN SQL. OPEN SQL allows you to read
and change database tables independent of the underlying database system.
♦ ABAP/4 allows you to define and process internal tables that exist only for the
execution period of the program. Internal tables efficiently support the usage of
database tables and allow you to implement complex data structures in a program.
♦ ABAP/4 allows you to store data not only in databases but also as sequential files on
application and presentation servers.
ABAP language Contains below mentioned topics
1. Data Dictionary Objects
Data Base Tables
Views
Structures
Data Elements
Domains
Search helps
Lock objects
Primary Key and Foreign Key
Table Maintenance Generator
2. Internal Tables
Internal Tables Introduction
Declaring Internal Table
Populating Internal Table
Processing Internal Table
Initializing Internal Tables
3. Moduralization Techniques
Macros
Sub-routines
Function Module
4. REPORTS

Classical
Interactive
Abap list viewer (ALV)
5. BDC - Batch Data Communication
Session method
Call Transaction Method
LSMW
6. Module pool Programming
Screen painter
Menu painter
7. Forms
Scripts
Smart forms
8. Cross-Aplications
ALE & IDOCS
BAPI's
BADI’s
User Exists
9. Miscellaneous Topics
Correction & Transport request (CTS)
Transport Organizer
Work Bench Request
Task Creation
Release Objects
SAP Memory & ABAP Memory
SD Flow
MM Flow

Data Dictionary
Data dictionary is the centralized and structured source of information about a database
table. It’s a logical layer situated over the database.
Data Dictionary does not contains the data like Emp name, Addresses etc but rather a
type of data whose function is to define the properties of data such as type, length and
relationship.
Advantages of data dictionary.
Advantage of using data dictionary is avoiding inconsistencies when defining data type
that will later be used in different applications. This avoids redundancies.
When a type is defined in the dictionary, it is available to any program in the application.
A change in the definition of a type of data in the dictionary automatically affects any
other data or program, which has this data.
Again, data dictionary is a fast and efficient way to answer questions such as which
entries exist in a table of the database, what the structure of table is.
Activation of dictionary objects
For a dictionary object to be effective at runtime, that is, for a dictionary object to be
available for use within a program, transaction, and so on, it must be in active status. For
objects to become active, R/3 includes the ACTIVATION function.
When a table or aggregated object is activated, it is placed at the disposal of the system as
a runtime object in a way that makes it available quickly for the application program to
access relevant information of new activated objects.
When a dictionary object is modified, that means that the object previously existed and
activated. You need to reactivate the object after modification.

When mass activation is performed massively, it might take a quite a long time. Then it
should be in the background system. This type of activation is known as background
activation.
The ABAP/4 Data dictionary is the central component of ABAP/4 repository. A Data
dictionary is centralized and structured source of information for business application.
The ABAP/4 dictionary is the core of the R/3 development system. It is the source of
every definition, within R/3, from the very basic domain to the company data model. It is
totally integrated with other tools of the development environment like screen painter,
menu painter, and editor.
Some of the main available functions in the ABAP/4 dictionary are as follows:
♦ Add, delete, modify, and manage the definition of the dictionary data.
♦ Preserve the data integrity.
♦ Be the central source of information e.g. from the dictionary you get the information
about the defined relationship between two tables or even the directory tells whether
table is active or empty.
♦ It also permits documentation of system data.
In the R/3 system instead of working with original objects, you work with internal
representation of objects. With this type of operation the system performance is
enhanced and has the advantage that the development tools, screen interpreters always
access current data.
When any of the data dictionary objects are used in other parts of the development
workbench for example, in program, programmer only has to enter a table name or field
name. The system automatically knows all the properties and information of the field.
To call ABAP/4 dictionary, from the main menu, Tools → ABAP/4 workbench → data
dictionary or enter transaction SE11.

Objects of Data Dictionary
1. Tables
2. views
3. Data Type
4. Domain
5. Type Group
6. Search Help
7. Lock Objects
8. Primary key and Foreign key
9. Table Maintenance generator.

Tables
A table is two dimensional data matrix i.e. it’s the combination of rows and columns.
The rows contain the data record and columns contain the field.
Tables can be containing 0 or multiple records or rows.
Ex: Employee Table.
Types of Tables
1. Client Dependent
2. Client Independent
1. Client Dependent:- If the first field of a table is MANDT and data type is CLNT
then it is called client dependent table. The length will be always 3.
2. Client Independent: - If the first field contains other than the MANDT then it is
Called client independent table
The client dependent tables are again of three types.
1. Transparent tables.
2. Pooled Tables.
3. Clustered Table.
1. Transparent Tables
A transparent table in the dictionary has one to one relationship with a table in the
database. Its structure in R/3 Data dictionary corresponding to a single database table.
The database table has the same name, the same number of fields and the fields have the
same names as the R/3 table definition. It contains application data. In below fig first
part will shows transparent table.

2. Table Pools and Pooled Tables
A pooled table in R/3 has a many-to-one relationship with a table in the database. For
one table in the database, there are many tables in the R/3 Data Dictionary. The table
in the database has a different name than the tables in the DDIC, it has a different
number of fields, and the fields have different names as well. Pooled tables are an
SAP proprietary construct.
In the database pooled tables are stored in a single table called a table pool table.R/3
uses table pools to hold a large number (tens to thousands) of very small tables (about
10 to 100 rows each). Table pools reduce the amount of database resources needed
when many small tables have to be open at the same time. Pooled tables are primarily
used by SAP to hold customizing data. In the above fig second part is an example for
pooled tables
3. Table Clusters and Cluster Tables
A cluster table is similar to a pooled table. It has a many to one relationship with a
table in the database. Many cluster tables are stored in a single table in the database
called a table cluster.
Table clusters are used to hold data from a few (approximately 2 to 10) very large

tables. They would be used when these tables have a part of their primary keys in
common, and if the data in these tables are all accessed simultaneously. Table clusters
contain fewer tables than table pools and, unlike table pools, the primary key of each
table within the table cluster begins with the same field or fields. In the above fig
third part is an example for cluster tables.
Restrictions on Pooled and Cluster Tables
Pooled and cluster tables are usually used only by SAP and not used by customers,
probably because of the proprietary format of these tables within the database and
because of technical restrictions placed upon their use within ABAP/4 programs.
1. On a pooled or cluster table, Secondary indexes cannot be created.
2. You cannot use the ABAP/4 constructs select distinct or group by.
3. You cannot use native SQL.
4. You cannot specify field names after the order by clause. Order by primary key is
the only permitted variation.
Because of these restrictions on pooled and cluster tables and because of their limited
usefulness. Normally in real time system we will not create much pooled and cluster
tables. Only transparent tables are used or created maximum. So we will discuss only
about transparent tables
Other Components of the Table
Fields: - Fields are nothing but columns.
Domain: - Domain consists of the technical characteristics of a field such as field
length and data type.
Data Element: - A table is composed of fields to create a field you need a data
element. The data element contains the field labels and documentation (F1 help) for
the field. It contains the semantic characteristics for the field and it works like a
interface between Field and Domain.
Domain and data elements are reusable. A domain can be used in more than one data
element and data elements can be used in more than one field and in more than one
table.
Delivery Class: - Delivery class comes under attributes. The value in the delivery
class field identifies the “OWNER” of the data in this table. The owner is responsible
for maintaining the table contents. In customer tables we always enter ‘A’ Here which
indicates that the table contains application data owned by the customer only.
Ex: - A –Application table (Master and Transaction data).

Data Class: It comes under technical settings. It defines the physical address of the
database in which the table uses creates and logically stored or it’s a physical place
where the actual data is to be stored.
Categories of data class: APPLO – Master data, transparent tables.
Size Category: It also comes under technical settings. It defines the probable space
requirement for a table in the database.
Categories:
0:- 0 to 30,000.
1:- 30,000 to 1, 20,000.
2:- 1, 20,000 to 4, 90,000.
3:- 4, 90,000 to 1,9,00,000
Table Maintenance allowed: Its also comes under attributes. By enabling table
maintenance allowed user can be able to enter the data, change and display manually.
Approaches for creating tables:- There are two approaches you can use when
creating tables.
Top-down-approach: In top down approach first we create the field then data
element then domain.
Bottom-up-approach: In the bottom-up-approach first we create the domain, then
data element and then field.
Direct Method: Do not have data element or domain.
Primary key: Primary key is a field or combination of fields that uniquely identify a
row in the database table.
Foreign Key: Foreign Key is a key which is a primary key of another table.
Naming convention for database tables:
1. The tables we are creating are generally called as Z-tables or customizing tables.
2. The name of a table should be started with Y or Z that a user creates.
3. SAP has used A to X for its own use, Z or Y in the beginning means that the
program or table is user defined.
So it avoids the redundancy between predefined and customizing tables.
Steps to Create Database Tables

To create tables, Go to transaction SE11 and select database table radio button: Give
Database table name for example ZKA_EMP. All user-created tables must start with Y
or Z.
Eg: ZKA_EMP. Then click on the CREATE button.
Eg: ZKA_EMP. Then click on the CREATE button and you will get the below screen.
In the Attributes (tab) screen,

Enter the short description as EMPLOYEE DETAILS.
Delivery class: Under multiple entries, select A-Application table (Master and
transaction data).
Check the box for the Table maintenance allowed.
Now select the fields (tab), Field name EMPNO and field type ZKA_EMPNO and
check the primary key check box. Field name EMPNO and field type ZKA_EMPNO
and check the primary key check box and click on save button.
When you click on save button you will get one pop-up box as shown below.

Click on the LOCAL OBJECT button.
Now double click on the field type and u will get CREATE DATA ELEMENT
SCREEN, click on YES.
Enter the short text EMPLOYEE NO and the domain name ZKA_EMPNO.
Now double click on the domain name ZKA_EMPNO and enter the following details.
Short text : EMPLOYEE NO.
Data Type : NUMC(Click on the RIS button and select NUMC from that)

No. of characters: As per the requirement. ( Eg. 10 ).
Note: If the field is employee name then u need to select the data type to be CHAR and
required no of characters.
Now SAVE (CTRL + S) ,
Click on the CHECK button or (CTRL + F2), and should get NO INCONSISTENSIES
FOUND in the status bar.
Then click on the ACTIVATE button (CTRL + F3).
Now click on the BACK button and then,
SAVE(CTRL+S), CHECK(CTRL+F2) & ACTIVATE(CTRL+F3).
Click the BACK button and u will be in the main dictionary screen.

Now click on the NEW ROWS button to enter as many fields u would prefer.
Once all the fields with the data element and the domain is set up, the table need to be
activated as a whole. To activate the table the technical settings should be saved.
Before u activate, u need to set up the technical settings by clicking on the TECHNICAL
SETTINGS button.
Where the data class is APPL0 (Master data, Transparent tables).
Size category is 0(0-30000).
SAVE or (CTRL+S) the technical settings.
Click BACK to get to the main screen and SAVE, CHECK AND ACTIVATE the table.
In order to give the input values(new entries), click on Utilities->Table contents->Create
Entries

Enter and SAVE the values and click RESET to give the new values.
Once the values are saved, click the BACK button and click on the CONTENTS, then
the EXECUTE button to see the output.
So when we click on the EXECUTE button, we get the output in the table format.
Thus the table is created.

Database Views
A view is a logical window to a table or more than one table, the data from a view is
not actually physically stored instead being derived from one or more tables. A view
can be used to summarize data which is distributed among several tables. It does not
contain memory space. During runtime it contains memory after the execution the
memory will be released
Types of Views
1. Projection View
2. Database View
3. Maintenance View
4. Help View
Projection View: This view is used to display data’s from only one table i.e. view
can draw upon only one table, this means that only the data that actually required is
exchanged when the database is accessed. Selection conditions cannot be specified
for projection view.
Database View: This view is used to display data’s from more than one table.
Database views are implement an inner join, that is, only records of the primary table
for which the corresponding records of the secondary tables also exist are fetched. In
database views, the join conditions can be formulated using equality relationships
between any base fields. Inconsistencies between primary and secondary table could,
therefore, lead to reduced selection set
Maintenance View: This view is used to for data manipulation like insert, update,
delete, modify etc. Data from several tables can be summarized in a maintenance
view and maintained collectively via this view. That is the data is entered via the view
and then distributed to the underlying tables by the system.

Help View: This view is used to displaying possible values of field from one or more
than one table i.e. used to output additional information when the online help system
is called or when F4 is pressed on the field.
Steps to create Views
DATABASE VIEW:
View can be performed for more than one table which have the foreign relationship b/w
the tables. For Eg: If we have ZKA_EMP and ZKA_COM, We can perform view.
Now to start with the view. Go to transaction SE11 and select View Radio button and
enter the name as below.
Eg: ZKA_DBV and click on the CREATE button.
Select the database view among the options and then click on the copy button.

Enter the short text: DATABASE VIEW.
And under the tables enter both the table names ZKA_EMP,
ZKA_COM.
Now click on the RELATIONSHIPS button and select the referenced tables and click
on the COPY button.

Now click on the VIEWS tab and click on the TABLE FIELD button.
Now choose the first table ZKA_EMP and select the fields required and click on the
COPY button. Similarly for the second table ZKA_COM.

Now SAVE, CHECK and ACTIVATE.
To see the output, click CONTENTS and EXECUTE.
Thus the database view is done with the fields in both the tables.
PROJECTION VIEW:
Go to SE11 and click on VIEW and enter ZKA_PV. Click on the CREATE button.

Select PROJECTION VIEW and click on the CONTINUE button.
Now enter the short text: PROJECTION VIEW.
Basis table: ZKA_COM (the table for which u need the projection view).
Now click on the TABLE FIELDS button and select the fields that we need to project
and click on the COPY button.

Now SAVE, CHECK and ACTIVATE. To see the output click on the CONTENTS
button and EXECUTE. Thus the projection view is created.
SEARCH HELP
Search helps are independent Repository objects that you create using the ABAP
Dictionary. They are used to present input help for screen fields which gives list of all
possible values for either primary key or non primary keys
The input help (F4 help) is a standard function of the R/3 System. It permits the user to
display a list of possible values for a screen field. A value can be directly copied to an
input field by list selection.
The fields having an input help are shown in the R/3 System by the input help key to the
right of the field. This key appears as soon as the cursor is positioned on the
corresponding screen field. The help can be started either by clicking on this screen
element or with function key F4.
Since the input help is a standard function, it should look and behave the same throughout
the entire R/3 System. The development environment therefore provides tools for
assigning a standardized input help to a screen field.
When you define a parameter of a search help, you must also define whether it should be
used to copy data to the input help (IMPORT parameter) or whether to return data from
the input help (EXPORT parameter).

Types of Search helps
Elementary search helps:- defines a search path where we will define the table from
which the data has to be read and the selection criteria. Through import and export
parameters. Used when we gets the data rom a single table.
Collective search helps:- Combination of elementary search helps. When we need to
fetch data based on multiple selection criteria s. More than one tables are selection from
multiple tables.
Diff Between Elementary search helps & Collective search helps
1) Elementary search helps describe a search path. The elementary search help must
define where the data of the hit list should be read from (selection method), how the
exchange of values between the screen template and selection method is implemented
(interface of the search help) and how the online input help should be defined (online
behaviour of the search help).
2) Collective search helps combine several elementary search helps. Collective search
help thus can offer several alternative search paths.
3) An elementary search help defines the standard flow of an input help.
4) A collective search help combines several elementary search helps. The user can thus
choose one of several alternative search paths with collective search help.
5) A collective search help comprises several elementary search helps. It combines all the
search paths that are meaningful for a field.
6) Both elementary search helps and other search helps can be included in a collective
search help. If other collective search helps are contained in collective search help, they
are expanded to the level of the elementary search helps when the input help is called.
STRUCTURE
Structure is a skeletal view of a table. It contains the definition of columns and don’t
have any contents. Structure is generally a template based on which a table is created.
The basic difference between structure and table is that the structure does not exist at the
underlying database system level. Structure exists as definition in the dictionary.
Types of Structures

Append Structure:- It will add Fields to the table from last . we can't use that structure in
another table. An append structure is a structure assigned to just one table. When a table
is activated, all append structures for the table are found and appended to the
table.Append structures are used to add customer fields to SAP tables and Custom tables
also.
Include Structure: Include structures can used by us to add fields into any ztables and
SAP tables also. Because in a Ztable we can add fields where ever we want. Include
structure can be used more than one time in a table. The same include structure can be
included to any no of custom tables.
Steps to create Structure.
In the DDIC (SE11), select DATATYPE and give the structure name: ZKA_STRUCT.
Now select STRUCTURE and click on the COPY button.
Enter the short text: STRUCTURE.

Then the components (field) corresponding to the table and select the component type
from the existing data type.
Click on SAVE, CHECK and ACTIVATE.
Now go the table to which the structure need to be added (ZKA_EMP).Select the row
where the structure need to be added and click on EDIT->INCLUDE->INSERT
Enter the STRUCURE ZKA_STRUCT and click OK.
SAVE, CHECK and ACTIVATE.
To see the output, Click on CONTENTS and EXECUTE.
Select all the records and click on the CHANGE button and click on the next entry and
fill in all the values and BACK button to see the output.
Thus the Structure is created.

Table types
Table types are construction blueprints for internal tables that are stored in the ABAP
Dictionary. When you create a table type in the ABAP Dictionary, you specify the line
type, access type, and key. The line type can be any data type from the ABAP Dictionary,
that is, a data element, a structure, a table type, or the type of a database table. You can
also enter a predefined Dictionary type directly as the line type, in the same way that you
can with a domain.
In an ABAP program, you can use the TYPE addition to refer directly to a table type. If
you define a local data type in a program by referring to a table type as follows:
TYPES dtype TYPE table.
The construction blueprint of the table type is used to create a local internal table dtype
in the program. The predefined Dictionary data types of the domains used by the data
elements in the structure are converted into the corresponding ABAP types. The semantic
attributes of the data elements are used for the corresponding components of the internal
table in the program.

Type Groups
Type groups were based on the include technique, and allowed you to store any type
definitions globally in the Dictionary by defining them using TYPES statements. The
definition of a type group is a fragment of ABAP code which you enter in the ABAP
Editor. The first statement for the type group pool is always: TYPE-POOL pool.
After that, you define data types using the statement TYPES. It was also possible to
define global constants using the CONSTANTS statement. All the names of these data
types and constants must begin with the name of the type group and an underscore:
pool_
In an ABAP program, you must declare a type group as follows before you can use it:
TYPE-POOLS pool. This statement allows you to use all the data types and constants
defined in the type group pool in your program. You can use several type groups in the
same program.
Let the type group HKTST be created as follows in the ABAP Dictionary:
TYPE-POOL hktst.
TYPES: BEGIN OF hktst_typ1,
col1(10) TYPE c,
col2 TYPE i,
END OF hktst_typ1.
TYPES hktst_typ2 TYPE p DECIMALS 2.
CONSTANTS hktst_eleven TYPE i VALUE 11.
This type group defines two data types HKTST_TYP1 and HKTST_TYP2, as well as a
constant HKTST_ELEVEN with the value 11.
Any ABAP program can use this definition with the TYPE-POOLS statement:
TYPE-POOLS hktst.
DATA: dat1 TYPE hktst_typ1,
dat2 TYPE hktst_typ2 VALUE '1.23'.
WRITE: dat2, / hktst_eleven.
The output is: 1.23, 11

The data types defined in the type group are used to declare data objects with the
DATAstatement and the value of the constant is, as the output shows, known in the
program
Example for type Group
*&---------------------------------------------------------------------*
*& Report ZBASU_TYPE_GROUP *
*& *
*&---------------------------------------------------------------------*
*& *
*& *
*&---------------------------------------------------------------------*
REPORT ZBASU_TYPE_GROUP .
TYPE-POOLs: ZTYPE .
tables: mara.
data: itab type table of ztype_basu with header line.
select-options: material for mara-matnr.
select * from mara into corresponding fields of table itab where matnr
in material.
write:/ ztype_a.
loop at itab.
write:/ itab-matnr,
itab-ersda,
itab-ernam.
endloop.
***************** Type Group defined DDIC
TYPE-POOL ZTYPE .
constants: ZTYPE_a type i value 10.
types: begin of ztype_basu,
matnr like mara-matnr,
ersda like mara-ersda,
ernam like mara-ernam,
end of ztype_basu.
LOCK OBJECTS
These types of objects are used for locking the access to database records in table. This
mechanism is used to enforce data integrity that is two users cannot update the same data
at the same time. With lock objects you can lock table-field or whole table.

In a system where many users can access the same data, it becomes necessary to control
the access to the data. In R/3 system this access control is built-in on database tables.
Developers can also lock objects over table records.
To lock an object you need to call standard functions, which are automatically generated
while defining the lock object in ABAP/4 dictionary. This locking system is independent
of the locking mechanism used by the R/3 system. Whenever an object is locked, either
by in built locking mechanism or by function modules, it creates corresponding entry in
global system table i.e. table is locked. The system automatically releases the lock at the
end of transaction.
Creating Lock Objects
Lock object is an aggregated dictionary object and can be defined by using the following
steps:
o From initial data dictionary screen, enter the name for the object, Click Lock
object radio button and then click on Create. The system displays a dialog box for
Maintain Lock Objects screen
o Enter short text as usual and the name for primary table.
o Save
o Select Tables option
From this screen you can: Select secondary tables, if any, linked by foreign key
relationship.
Fields for the lock objects. This option allows you to select fields for objects (R/3 system
allows locking up to record level). Lock object argument are not selected by user but are
imposed by the system and includes all the primary keys for the table.
Types of locks
You can lock the table or record by using following types of locking:
Exclusive (E) or Read mode: The locked data can only be displayed or modified by
single user i.e. the owner of the object. Access to other users is denied.
Shared (S) or Write Mode: Several users can access the same record simultaneously, but
only in display mode and except the first one, who has asked for the data in update mode.

Exclusive not cumulating (X) it is similar to exclusive lock. It allows only a single user
access. E can be called several times from the same transaction. In contrast, a lock type X
can be called only once during the transaction. Any other call for this lock is rejected.
Activation of Lock Object
When you activate the lock object, the functions are automatically generated. And these
are ENQUEUE-EZN and DEQUEUE-EZN. EZN is name of the lock object.
While ENQUEUE is used in program to set the code over the selected data depending
upon the lock object arguments. DEQUEUE is used to release the lock.

Internal Tables
By definition, internal tables are user defined structured data types. These internal
tables can be created as a replica of data base table, using some or all fields of one table
or more tables. These internal tables are created only during run time no memory is
reserved.
Why we need internal table
Long life data is stored in database tables when we are directly modifying data there is
every possibility that we may loose data by accident, which we can not afford to do so,
As such we need some intermediate etc tables to do some operations upon satisfactory
results, we can modify database tables.
Defining Internal Tables:
Internal table with header line: When we create internal table with header line, a
default work area is created.
Internal table with out header line: In this case, we need to create explicit work area to
work with it. When we need to nest the tables with in tables, we need to use this type of
internal table.
Types of internal tables
1. Standard tables: - Standard tables have an internal linear index. The system can
access records either by using the table index or the key. The response time for key
access is proportional to the number of entries in the tables. The key of standard table is
always non-unique. Standard tables can always be filled very quickly, since the system
does not have to check whether there are already existing entries.
Key access to a standard table uses a linear search. This means that the time required
for a search is in linear relation to the number of table entries. You should use index
operations to access standard tables.
2. Sorted Tables: - Defines the tables as one that is always saved correctly sorted by key.
The system can access records either by using the table index or the key. The response
time for key access is logarithmically proportional to the number of table entries, since
the system uses a binary search. The key of a sorted table can be either unique or non-
unique.

If the key is not unique, the system takes the entry with the lowest index. The runtime
required for key access is logarithmically related to the number of table entries.
3. Hashed tables: - Hashed tables have no linear index. Hashed table is accessed using
its key. The response time is independent of the number of table entries and is constant,
since the system accesses the table entries using a hash algorithm. The key of a hashed
table must be unique.
Defines the tables as one that is managed with an internal hash procedure. You can
only access a hashed table using the generic key operations or other generic operations
(sort, loop and so on) Explicit or implicit index operations (such as loop... from and insert
itab with in and loop) are not allowed.
4. Index Table: - A table that can be accessed using an index. Index table is only used to
specify the type of generic parameters in a from or function. That means that you can not
create a table of type Index. Standard and sorted tables are index tables.
Initializing Internal Tables
Clear: Clears the header (Work Area) line of the internal table.
Syntax: clear Itab.
Clear []: Clears the body of the internal table without clearing the work area or header.
Syntax: Clear itab [].
Refresh <Itab>: Delete all table entries, memory space remains occupied i.e. only
removes only contents of internal table.
Free <Itab>: Delete all table entries, memory space is released i.e. de-allocates memory
associated with internal table.
Operations of Internal Tables
1. Append: It will take data from work area or header into internal table body.
Syntax: Append itab (append itab to itab)
Append wa_itab to itab.
2. Collect: It will work similar to append operation but it will adds the same integer
fields otherwise it will append it.
Syntax: Collect itab.
3. Insert: Used to insert data at any place. For this we have to specify the index no

otherwise its goes to dump screen.
Syntax: insert itab index (Index number).
4. Modify: This operation will modify the existing records.
Syntax: Modify itab index (Index number).
5. Read: Used to read a single record from itab with key or index and it will read from
application server to the screen.
Syntax: read itab with key (field name)
6. Sort: Used to sort the internal tables and by default it is ascending.
Syntax: Sort itab by (Field name).
7. Delete: Used to delete the data from internal tables but you need to give index number
or range and field names.
Syntax: Delete itab by index (Index number)
8. Describe: Used to describe the internal tables like how many records and what kind of
internal table etc.
Syntax: Describe table itab lines (variable name)
Example for internal table operations
*&---------------------------------------------------------------------*
*& Report ZBASU_INTERNAL_TABLE_OPERATION *
*& *
*&---------------------------------------------------------------------*
*& *
*& *
*&---------------------------------------------------------------------*
REPORT ZBASU_INTERNAL_TABLE_OPERATION.
DATA: BEGIN OF ITAB OCCURS 0,
F1,
F2 TYPE I,
F3(3),
END OF ITAB.
DATA: LIN.
******Append Operation
ITAB-F1 = 'A'.
ITAB-F2 = 10.
ITAB-F3 = 'BC'.
APPEND ITAB.
CLEAR ITAB.
ITAB-F1 = 'B'.
ITAB-F2 = 15.

ITAB-F3 = 'BD'.
APPEND ITAB.
CLEAR ITAB.
******* Collect Operation
ITAB-F1 = 'A'.
ITAB-F2 = 20.
ITAB-F3 = 'BC'.
COLLECT ITAB.
CLEAR ITAB.
ITAB-F1 = 'C'.
ITAB-F2 = 25.
ITAB-F3 = 'BF'.
APPEND ITAB.
CLEAR ITAB.
*******Insert Operation
ITAB-F1 = 'D'.
ITAB-F2 = 30.
ITAB-F3 = 'BG'.
INSERT ITAB INDEX 2.
CLEAR ITAB.
*******Modify Operation
ITAB-F1 = 'F'.
ITAB-F2 = 40.
ITAB-F3 = 'BH'.
MODIFY ITAB INDEX 2.
CLEAR ITAB.
ITAB-F1 = 'F'.
MODIFY ITAB TRANSPORTING F1 WHERE F1 = 'D'.
CLEAR ITAB.
*******Sort Operation
SORT ITAB.
SORT ITAB BY F2.
******Read Operation
READ TABLE ITAB INDEX SY-TABIX INTO ITAB.
READ TABLE ITAB INDEX 3 INTO ITAB.
READ TABLE ITAB INTO ITAB WITH KEY F1 = 'D'.
WRITE:/ ITAB-F1,
ITAB-F2,
ITAB-F3.
******Describe Operation
DESCRIBE TABLE ITAB LINES LIN.
******Delete Operation
DELETE ITAB INDEX 2.
DELETE ITAB WHERE F1 = 'A'.
WRITE:/ 'NO OF LINES IN MY INTERNAL TABLE', LIN.
LOOP AT ITAB.
WRITE:/ ITAB-F1,

ITAB-F2,
ITAB-F3.
ENDLOOP.
REPORTS
About reports
Reports, in the R/3 system are online programs whose function is to retrieve data from
database and display it or print it for the user. An end user often needs some information
to look up, depending upon which various management decisions are taken, or to just see
business results or simply to continue work. As R/3 is collection of all business
applications, it has provided a very powerful feature to satisfy this crucial business need
i.e., reports are involved at each and every step of business. This type of extracting,
collecting and formatting data that is stored in database is done by REPORT program.
The program that is written to retrieve and display data is REPORT program and the data
that is displayed on the screen when you execute the program is called as LIST (output of
the report).
When you display data, you need to display the data, user needs. For example, user wants
to see the all the employee, who has joined after 12th
December 1997. In this case user
has to pass this information, to the system, that he needs only those employee records
where joining data is greater than 12th
December 1997. For user, it is passing information
to the system but for the system it is input from the user. System takes input from the user
before it retrieves the data from the database. This is very common requirement of any
report as the need of any business is to display data, which is required by user.
♦ Reports are ABAP/4 programs.
♦ You use reports to evaluation data from database tables. The results of such an
evaluation can be displayed on the screen or printed form.
♦ Reports are stand-alone programs.

♦ The user can execute reports directly via the program name, for example, by choosing
System ® Utilities ® Reporting.
♦ A report program contains a collection of processing blocks for different events that
are always triggered externally. In a report, you can react on events by programming
the corresponding processing blocks or ignore the events by not writing the
corresponding processing blocks. A report itself never creates events.
♦ Reports can use logical databases or select statements defined by developer.
♦ For each application, SAP supplies logical databases. Or you can easily create logical
database yourself.
♦ Event control of a report corresponds to a certain scheme:
When a report is executed, the ABAP/4 processor creates together with the logical
database used (if any) a sequence of certain events for which you can program
processing blocks. The chronology of the events is (more or less)
Steps involved in creating a Report:
1. Processing the selection screen
After starting a report, the selection screen allows the user to enter limits or
control values for further report processing. The report can contain several
processing blocks for events during selection screen processing, for example, for
checking the input values.
2. Reading the database
After selection screen processing come the events for reading the database. Either
the report reads data from relational databases it using the corresponding ABAP/4
statements (open SQL) or leaves this task to a logical database. In the latter case,
the logical database creates a sequence of events to allow the report to copy the
data.
3. Evaluating data and creating lists
During or after reading the database the report creates the output list. During list
creation, several events allow you to layout the output list (for example, layout the
page header).
4. Outputting a list
The last part of the processing sequence controlled by the ABAP/4 processor is
the list output on the screen or printer. When displaying the list on the screen, user
can trigger other reports, that are interactive and are event driven. For example, by
clicking the mouse. By programming processing blocks for these events, you
change a normal report to a so-called Interactive report. If a report does not
contain event keywords, the entire coding of the report belongs to a single

processing block, which is called by a standard event. This standard event is
triggered directly after processing the selection screen.
Selection criteria
System accepts inputs from user through SELECTION CRITERIA.
Selection criteria are nothing but input fields which allows the user to restrict information
given to program for processing further data. If you don’t specify any criteria for
selection, your report program produces a long list of data, which might not be needed by
the user. Basically, selection criteria are the fields where user enters some value for
which he needs information. Through selection criteria user can enter discrete value
or ranges. For example, user wants to see all the records of the employees, who have
joined between 12th
December 1997 and 12th
May 1998. This range can be entered in
selection criteria. As the user becomes more specific for mentioning the criteria, the list
will be smaller and more specific.
Syntax:
SELECT-OPTIONS <field> for <table field>.
Field is the variable, which you declare for accepting input from the user.
Table field is reference field.
SELECT-OPTIONS: fld1 for sflight-fldate,
carrid1 for sflight-carrid.
Maximum length of the name Select-Options variable is 8.
When system executes this statement, the selection screen is displayed and is like this.

When you enter the desired information and click on execute button, rest of the program
is executed, that is retrieval of data from database, which matches this information and
the list is displayed.
Behavior of SELECT-OPTIONS
When the Select-Options statement is executed the system creates the internal table with
the same variable name (in this case it will be carrid1). This table is also called as
selection table. The main purpose of selection table is to store selection criteria. The
table has four standard fields, which are as follows:
♦ SIGN is a variable, which denotes the system whether the result should be included
with those particular criteria. It can contain either I or E. I denotes Inclusion. The
criteria are included.
E denotes Exclusion. The criteria are excluded from the result.
♦ LOW the data type of LOW is the same as the field type of the database table, for
which you are using selection criteria. This acts as lower limit of the selection.
♦ HIGH the data type of HIGH is the same field type of the database table, for which
you are using the selection criteria. This acts as higher limit. If you don’t enter HIGH
value then the LOW value defines a single value selection.
♦ OPTION is two-character field, which contains operators like EQ, GT, LT, GE, and
LE.

When the user enters both the values i.e., high and low then this field acts as BT
(between). If you don’t enter high value then all other operators can be Applicable.
For each Select-Options statement system creates internal table.
Default values for select-options
If you want to display default values for the selection criteria before your screen is
displayed, give default values for the selection table fields i.e., low or high.
SELECT-OPTIONS: CARRID1 FOR SFLIGHT-CARRID DEFAULT CARRID1-LOW
= ‘LH’ AND CARRID1-HIGH = ‘SQ’.
In this case selection screen is displayed with default values ‘LH’ for lower range and
‘SQ’ for higher range. User can use same values or overwrite these values with new
values, whichever he needs.
Parameters
Parameter statement is used to accept input from user. PARAMETER statement is used
when you want user to enter data and depending upon what he enters you need to take
action. The parameter statement declares the variable and also allows system to accept
data into that variable.
Syntax.
Parameters: num type I.
Here parameter statement declares the variable and creates the selection screen on which
user enters the data i.e., in this case num is declared of type I and user can enter any
number. Entered value is stored in the same variable and can be used in program.
Data: m type I
Parameters: num type I
M = num – 5
Write: / ‘The number is’, m.
You can define default values with parameter statement for example
Parameter: num type I default 12.
In this case when selection screen is displayed the default value is displayed. User can
either use same value or overwrite the value.

Parameter of type character and length = 1, can be displayed as Checkbox and
Radiobutton.
Parameter: C1 as Checkbox,
C2 as Checkbox.
Parameter: R1 Radiobutton group g1,
R2 Radiobutton group g1.
When parameter is defined as Radiobutton, it needs to be attached to one group. Only
one Radiobutton of one group can be clicked.
Every parameter can be associated with language dependent text that is displayed on the
selection screen. This can be done with the help of text elements.
WRITE Statement
The basic APAB/4 statement for outputting data on the screen is WRITE.
Syntax:
WRITE <field> <option>.
This statement outputs the field <f> to the current list in its standard output format.
By default, the list is displayed on the screen.
The field <field>can be any variable or table field or just literal.
PROGRAM ZDEMO
WRITE: /‘HELLO’.
When you start this program, the system leaves the current screen i.e., your editor screen
and branches to the output screen, which is also called as list screen:
The list screen has the same name as the title of the program specified in the program
attributes. First line on the screen contains the list header. By default, the list header is
the same as the title of the program. The current page number (1) appears on the right.
The list header is followed by one line and then the output is displayed.
Write : ‘HELLO’.
Write : ‘WORK HARD’

On the screen, the output is normally left justified. But in above case, because we have
used two WRITE statements, the output fields are displayed one after the other, each
separated by one column (i.e., one blank). If there is not enough space for an output field
on the current line, a new line is started.
Almost all system-defined fields are right justified except FLOAT, INTEGER, and
PACKED i.e., number field. The numeric data types F, P, and I are right justified and
padded with blanks on the left. If there is sufficient space, thousands of separators are
also output. If a type P field contains decimal places, the default output length is
increased by one.
With the data type D, the internal format of a date differs from its output format. When
you use the WRITE statement for outputting data, the system automatically outputs dates
of type D in the format specified in the user’s master record (e.g. DD/MM/YYYY or
MM/DD/YYYY).
CLASSICAL REPORTS
Events in Classical report
Events associated with classical report are as follows and each one will be discussed in
detail.
♦ INITIALIZATION
♦ AT SELECTION-SCREEN
♦ AT SELECTION-SCREEN ON <field>
♦ START-OF-SELECTION
♦ TOP-OF-PAGE
♦ END-OF-PAGE
♦ END-OF-SELECTION
In this case first three events are associated with selection screen. Rests of the events are
associated with your list.
♦ INITIALIZATION
We have already seen how to fill default values for the selection criteria. But in many
cases you need to calculate the value and then put it in selection criteria. For example,
say, you are accepting date from user and you need to fill in the default value for lower

range as sy-datum – 30 days and sy-datum for higher range. In this case you are
calculating lower range and then filling the criteria. This can be done in
INITIALIZATION event. Piece of code to do the above task would look like the
following:
Tables: Sflight.
Select-options: fldate1 for sflight-fldate.
INITIALIZATION.
Data: date1 like SY-DATUM.
Date1 = sy-datum – 30.
Fldate1-low = date1.
Fldate1-high = sy-datum.
Append fldate1.
* Here appending is required because fldate1 is int’ table
This event is triggered when you execute your program for the first time i.e., before
selection screen is displayed.
♦ AT SELECTION-SCREEN
When user enters the values in the fields of selection screen and clicks on execute button,
this event gets triggered. This event is basically for checking the values entered by the
user for the fields of the selection screen i.e., data validity checking. This event is for
entire selection screen. For example:
You are accepting carrid, connid, fldate from user and you don’t want to proceed if user
enters no value for carrid and fldate. Using AT SELECTION-SCREEN can do this.
Select-options: carrid1 for sflight-carrid,
Connid1 for sflight-connid,
F1date1 for sflight-f1date.
AT SELECTION-SCREEN.
If carrid1-low ne ‘ ’ and fldate1-low = ‘ ’.
Error message.
Endif.
In this case, if both the fields are entered blank, then the user gets error message.
Basically, this event is for many fields on selection screen. Usually, it is for the fields
which are logically related.

♦ AT SELECTION-SCREEN ON <field>
When you want to check for specific value of a field. For example, carrid should be in the
range of ‘LH’ and ‘SQ’. This can be done in this event. Basically, this event is for
checking individual fields. You can have many AT selection-screen events in your
program (i.e., for each field specified in the Select-Options).
Select-Options carrid1 for sflight-carrid.
If carrid1-low ne ‘LH’ and carrid1-high ne ‘SQ’.
Error message.
Endif.
Here the system will not proceed on entering wrong values.
♦ START-OF-SELECTION
This is the first event for your list. Once all the events are triggered for selection screen,
the data is retrieved from database. Data declaration, select statements are done in this
event. Consider the following example:
START-OF-SELECTION.
Data: mtype i.
Tables: sflight.
Select * from sflight where carrid = ‘LH’.
Write: / sflight-carrid,sflight-connid.
Endselect.
♦ TOP-OF-PAGE
This event is triggered with first WRITE statement or whenever new page is triggered.
Advantage of using this event is that, whatever you write under this event, is applicable
to all the pages. If you don’t have any write statement before TOP-OF-PAGE or in
START-OF-SELECTION, this event is not triggered at all. For example, if you want the
name of company and column headers for all the pages, it can be written in this event.

TOP-OF-PAGE
Write: / ‘INTELLIGROUP ASIA PVT. LTD.’
Write : / 10 ‘carrid’, 20 ‘connid’, 30 ‘fldate’.
♦ END-OF-PAGE
This event is triggered at the end of page.
End-of-page.
Write : / ‘page number’, sy-pagno.
In this case page number will be written on every page.
Conditional triggering of EOP
Consider the following case.
REPORT ZDEMO1 line-count 15(3).
Top-of-page.
Write: ‘this line is written by top-of-page event’.
Start-of-selection.
Write: ‘this line is written by start-of-selection event’.
End-of-page.
Write : ‘this line is written by end-of-page event’.
In this case EOP will never be triggered, as end of page is never reached. The total Line-
count defined for page = 15 in which 3 lines are for footer area. The output of the above
code will be
This line is written by top of page event.
This line is written by start of selection event.
In output screen, only two lines are written and cursor remains still on 3rd
line, the end-of-
page event is not triggered. To trigger end of page event, cursor should reach at the last
position, in this case on 11th
line.
Such cases are quite common, and could be overcome by conditional triggering of end of
page.
Sy-linct is the system variable, which gives total line count of a list.

Sy-linno is the system variable, which gives the current line number where the cursor is
placed on the list.
Consider the following case:
Report zdemo1 line count 20(1).
Start-of-selection.
Data: m type i.
Write: / ‘this is first line’.
Do 5 times.
Write: / ‘the number is’, sy-index.
Enddo.
M = sy-linct, sy-linno – 1.
Skip x.
End-of-page.
Write: / ‘page end’.
The output of above example is as follows :
This is first line.
The number is 1
The number is 2
The number is 3
The number is 4
The number is 5
After skipping 10 lines
Page end
In this case, with all write statement, you don’t reach to the end of page. After all write
statement, m is calculated in this case:
M = 20 – 8 – 1, So m is 12. And 11 lines are skipped after write statement and end of
page is reached. (In this case you have 6 write statement so 6 lines + 1 line for page
number and 1 horizontal line which is displayed for any list. So cursor is on 8th
line and
is subtracted from total line count i.e, 20.)
Using Variants with selection criteria
In many cases you need report to execute report at regular interval for certain fixed
values of selection criteria. That means each times you execute the report you need to
enter its values again and again. ABAP/4 provides the facility by which you can define
the values for selection screen and store it. Using VARIANTS can do this. It can be

defined as group of values used for selection criteria while executing report. For a
particular report, you create a variant which means variant created for particular report
cannot be used for another report. The group of values for the selection criteria is saved
and assigned a variant name. So every time you call a report, you need not specify the
values for selection criteria but instead call the variant thus avoiding extra typing. User
can have many variants for a single report. Each of them can be used as different type of
information. For example, if a manager wants to see how an employee in personnel
department or admin department has performed. He need not enter the department, one
has to just execute the report with variant. In case he doesn’t know about the variant,
which is available, he can display list of variants attached to the report and values
assigned to each variant.
Creating variant
♦ Execute the report program. The selection screen is displayed.
♦ Enter the values for selection screen and click on saves.
- System displays the variant screen
♦ Enter the variant name and description for it.
♦ Save it.
Usually the variants are useful when you need to execute the report in background, which
will be discussed in background processing.
Example for Classical Report Events.
*&---------------------------------------------------------------------*
*& Report ZBASU_CLASSICAL_REPORT_EVENTS *
*& *
*&---------------------------------------------------------------------*
REPORT ZBASU_CLASSICAL_REPORT_EVENTS NO STANDARD PAGE HEADING LINE-SIZE
90 LINE-COUNT 40(2).
Tables: mara.
data: begin of itab occurs 0,
ersda like mara-ersda,
ernam like mara-ernam,
end of itab.
DATA: M TYPE I.
selection-screen: begin of block b1 with frame title text-002.
select-options: material for mara-matnr.
selection-screen: end of block b1.
INITIALIZATION.
MATERIAL-LOW = '100'.
MATERIAL-HIGH = '200'.

MATERIAL-SIGN = 'I'.
MATERIAL-OPTION = 'BT'.
IF MATERIAL-LOW = ' ' AND MATERIAL-HIGH = ' '.
MESSAGE 'ENTER PROPER DATA' TYPE 'E'.
ENDIF.
START-OF-SELECTION.
SELECT MATNR ERSDA ERNAM FROM MARA INTO CORRESPONDING FIELDS OF TABLE
ITAB WHERE MATNR IN MATERIAL.
TOP-OF-PAGE.
WRITE:/ 'GALAXE SOLUTIONS'.
END-OF-SELECTION.
LOOP AT ITAB.
WRITE:/ ITAB-MATNR,
ITAB-ERSDA,
ITAB-ERNAM.
ENDLOOP.
M = SY-LINCT - SY-LINNO - 2.
SKIP M.
END-OF-PAGE.
WRITE:/ 'BANGALORE', SY-DATUM.
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.
Report ztn1811
Perform<s1><ztn1811>
Report
ztn1811
Form s1 end
term
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:
1. Formal parameters: Parameter names that appear on the form statements are
called formal parameters.
Ex: FORM s1, using P1 changing P2, P3
Here P1, P2, P3 are called formal parameters.
2. 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.
CREATING TYPED AND UNTYPED PARAMETERS:
Formal parameters are divided into two types: typed and untyped.

A typed parameter is a formal parameter that has a data type following its name on the
form statement.
Ex: Form s1 using u1 type t, value (u2) type t
changing c1 type t value (c2) type t.
An untyped parameter is a formal parameter that doesn’t have a data type following its
definition on the form statement. Untyped formal parameters allow you to pass a variable
of any data type or length to it. The formal parameters use the attributes of the actual
parameter.
Ex: if we pass a four byte integer to an untyped formal parameters P1. P1 becomes a four
byte integer.
There are three wage 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.
Ex: Report xyz. Memory address for F1 is 1000 (Example)
Data F1 value A. F1 = A before calling s1
Performs s1 using F1.
Write: / F1. F1 = X after assignment in s1
Form s1 using P1. P1 – P1 is a pointer to memory location 1000
P1 = X. this changes memory location 1000 to X.
Write:/ P1.
End the form
O/p P1= x
F1= x
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.
EX: Report xyz F1 = A before call to s1
Data: F1 value A. F1 = A after assignment in s1
Perform s1 using F1.
Write: / F1.
From s1 using value (P1) 0/P P1 = X
P1 =X. F1 = A
Write: / P1.
End form.
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.
Ex: Report xyz Form S2 changing value (P2)
Data: F1 value A P2 = ‘X’.
PERFORM: S1 changing F1 Write: / P2.
S2 changing F1 Stop.
End form
End of selection
Write: / F1. 0/P - P1 = B
Form s1 changing value (P1) P2 = X
P1 =B. Write:/ P1. F1 = B
End form
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
Function modules are reusable section of codes. Functions modules generally used for
global modularization. Functions modules contain functions that are used in the same
form by many different programs.
Functions modules must be defined in function group & called from any program.
Function modules are similar to external subroutines. Function groups acts as container
for function modules that logically belong together, we cannot execute function group.
When we call a function module the system loads the whole of its function group into the
internal session of the calling program.
A single function group may contain one or more function modules which are logically
related. The advantages of function modules are which helps code reusability. We can
handle exceptions using functions modules. Each function group is known by a four
character identifier called Function group id. If its user created function group than it’s
begins with y or z.
Function groups are stored in a group of tables with in the database called the function
library or central library. To access the function library from the development
workbench, press function library button on the application toolbar or use the transaction
code SE 37.
Syntax for detaining function module
FUNCTION <name>
--------------------------
--------------------------
--------------------------
--------------------------
END FUNCTION
Syntax for all function statement
Call function ‘FUNCTION MODULE NAME’ ---> function module name must be in
upper case other wise it will not find and a short dump will result
[Exporting P1 = V1]
[Importing P2 = V2]
[Changing P3 = V3]
[Table P4 = IT]
[Exception X2 = N [otherwise]}
P1-P3 --> parameter name defined in function module

V1-V3 -->are variables or field strings defined within the calling program
IT --> internal table defined with in the calling program.
X2 --> exception name
Function modules have the following interface parameters
1) Import parameter: A variables or filed string that contains values passed into the
function module from the calling program. These values originate outside of the function
module. They are imported into it. These must be supplied with data when you call the
function module unless they are flagged as optional.
2) Export parameter: Are variables or field string that contains values returned from the
function module. These values originate within the function module and they are
exported out of it. These are also optional you may not have received in your program.
3) Changing parameter: These are variables or field string that contains values that are
passed into the function module changed by code within the function module and then
returned. These values originate outside the function module. They are passed into it,
changed and passed back to the calling program.
4) Table parameter: These are internal tables that are passed to the function module
changed within it and returned. The internal table must be defined in the calling program.
5) An exception: is a name for an error that occurs with in a function module.
To pass parameters to a function module, we must define function module interface.
The function module interface is the description of the parameters that are passed to and
received form the function module. It is also called simply interface.
Passing parameters:
The methods for passing parameters to the function modules are very similar to those for
passing parameters to external subroutines
By default
1) Import and Export parameter are passed by value
2) Changing parameters are passed by value and result
3) Internal tables are passed by reference.
To come out of the function module at any time we use the statement called
1) RAISE ->which terminates the program and switches to debugging mode.
2) The message--->rising

This statement display the specified message how the processing continues depends on
the message type.
Types of functions modules
There are two types of function module
1. Normal
2. Remote function call(RFC)
1. Normal: This function module is used for ABAP programming with in the system.
It is normal function module. We can work within the system only.
2 .Remote function call (RFC): This function module can be called remotely by using
RFC destination. Here remote means external system; it may be a SAP system or non
SAP systems like java system. If it is RFC, we can work with in the system as well as
across the system. Remote function modules are function modules that can be called from
other SAP or non SAP systems. BAPI’S are examples of RFC MODULES
Types of RFC’S
1. Synchronous RFC
2. Asynchronous RFC
3. Transaction RFC
4. Queued RFC
5. Parallel RFC
1) Synchronous RFC: It is the very common method used in real business scenarios.
Both the client and server must be available in this type of RFC. The advantage is that
you can get the result immediately. Which means the RFC function module gives result
or output immediately.
The syntax:
CALL function<function-module name>destination<RFC destination name>
2. Asynchronous RFC: Asynchronous remote function call are similar to transactional
RFC’S in that the user does not have to wait for their completion before containing the
calling dialog. There are three characters however that distinguish asynchronous RFC’S
from transaction RFC’S
1) When the caller starts an asynchronous RFC’S the called serve must be available to
accept the request. The parameters of asynchronous RFC’S are not logged to the database
but sent directly to the server.

2) Asynchronous RFC’s allow the user to carry on interactive dialog with remote system.
3) The calling program can receive results from the asynchronous RFC.
You can use asynchronous remote function calls whenever you need to establish
communication with remote system but do not want wait for the functions result before
continuing processing. Asynchronous RFC can be also sent to the same System. In this
case the system opens a new session (or window) and allows you to switch back and forth
between calling dialog and the called session.
Subroutine Function modules
1) Subroutines are for local modularization 1) It is for global modularization
Maximum
2) Are not remote enabled 2) Are remote enabled.
3) No support for exception handling 3) It supports exception handling
4) Not stored in SAP library stored in ABAP 4) Stored in SAP library i.e.
Memory Functional library
5) Not executed directly we have embedded in 5) Directly executed.
ABAP program before executing
INTERACTIVE REPORTS
About interactive report
A classical report consists of one program that creates a single list. This means that when
the list is displayed, it has to contain all the requested data, regardless of the number of

details the user want to see. This procedure may result in extensive and cluttered lists
from which the user has to pick the relevant data. The desired selections must be made
before hand and the report must provide detailed information.
This is not possible using the classical report and for this ABAP/4 has provided reporting
feature called INTERACTIVE REPORT. The list produced by classical report doesn’t
allow user to interact with the system but the list produced by interactive report allows
the user to interact with the system i.e., user can tell the system, that he needs further
information. Depending upon what the user tells the system, the action is taken.
Interactive reporting thus reduces information retrieval to the data actually required.
Interactive reporting allows the user to participate in retrieving and presenting data at
each level during the session. Instead of presenting one extensive and detailed list with
cluttered information, with interactive reporting you can create a condensed basic list
from which the user can call detailed information by positioning the cursor and entering
commands.
Detailed information is presented in secondary lists. A secondary list may either overlay
the basic list completely or appear in an additional dialog window on the same screen.
The secondary list can itself be interactive again. The basic list is not deleted when
secondary list is created.
User can interact with the system by:
♦ Double clicking or pressing F2
♦ Selecting menu option
Like classical report, the interactive report is also event driven. Both the action
mentioned above trigger events and code is written to handle these events. The events
triggered by this action are as follows:
♦ At line-selection
♦ At user-command
♦ Top-of-Page During Line-Selection for Secondary Page Header info
Interactive report consists of one BASIC list and 20 secondary list. Basic list is produced
by START-OF-SELECTION event. When the user double clicks on the basic list or
chooses the menu option, the secondary list is produced. All the events associated with
classical report except end-of-page are applicable only to basic list.

AT LINE-SELECTION event
Double clicking is the way most users navigate through programs. Double clicking on
basic list or any secondary list triggers the event AT LINE-SELECTION. SY-LSIND
denotes the index of the list currently created. For BASIC list it is always 0. Following
piece of code shows how to handle the event.
Start-of-selection.
Write: / ‘this is basic list’.
At line-selection.
Write : ‘this is first secondary list’.
In this case the output will be displayed on basic list i.e.
This is basic list.
When user double clicks on this line, the event at line-selection gets triggered and
secondary list is produced, i.e.
This is first secondary list.
You can go back to basic list by clicking on F3 or back icon on the standard tool bar. For
this list, the value of sy-lsind will be 1.
HIDE technique
In this case thins are much simpler. Consider the case, wherein you display fields from
table sflight in basic list. When user double clicks on any sflight-carrid, you are
displaying the detailed information related to that particular carrid on secondary list.
Hence there is a need to store the clicked carrid in some variable. So that you can access
this carrid for next list. ABAP/4 has facility; a statement called HIDE, which provides
the above functionality.
HIDE command temporarily stores the content of clicked field in system area.

Syntax:
HIDE <FIELDS>.
This statement stores the contents of variable <f> in relation to the current output line
(system field SY-LINNO) internally in the so-called HIDE area. The variable <f> must
not necessarily appear on the current line.
You have to place the HIDE statement always directly after the output statement i.e.,
WRITE for the variable <f>. As when you hide the variable, control is passed to next
record. While writing, WRITE statement takes that record from header and writes it
on to the list, but when writing onto your interactive list you will miss out 1st
record.
To hide several variables, use chain HIDE statement.
As soon as the user selects a line for which you stored HIDE fields, the system fills the
variables in the program with the values stored. A line can be selected.
♦ By an interactive event.
For each interactive event, the HIDE fields of the line on which the cursor is positioned
during the event are filled with the stored values.
The HIDE area is a table, in which the system stores the names and values of all HIDE
fields for each list and line number. As soon as they are needed, the system reads the
values from the table. (Please try to find the name of this table.)
Sy-lsind indicates the index of the list and can be used to handle all the secondary lists.
When the user double clicks on the line or presses F2, sy-lsind is increased by one and
this new sy-lsind can be handled. For example:
Write: / ‘this is basic list’.
• Will create a basic list.
If sy-lsind = 1.
Write: / ‘this is first secondary list’.
Elseif sy-lsind = 2.
Write: / ‘This is second secondary list’.
Endif.

When this code is executed,

• Basic list is produced.
• When the user clicks on the basic list, sy-lsind becomes one.
• AT LINE-SELECTION event is triggered.
• Whatever is written under IF Sy-lsind = 1, gets executed.
• Secondary list is produced.
• Again if user clicks on this list, sy-lsind becomes two.
• AT LINE-SELECTION gets triggered.
• Code written under IF Sy-lsind = 2, gets executed.
Example for Interactive Report Events
*&---------------------------------------------------------------------*
*& Report ZBASU_INTERACTIVE_REPORT_EVENT *
*& *
*&---------------------------------------------------------------------*
*& *
*& *
*&---------------------------------------------------------------------*
REPORT ZBASU_INTERACTIVE_REPORT_EVENT NO STANDARD PAGE HEADING
LINE-SIZE 90 LINE-COUNT 40(2).
Tables: mara, kna1, vbak, vbap.
types:begin of ty_kna1,
kunnr like kna1-kunnr,
name1 like kna1-name1,
end of ty_kna1.
types:begin of ty_vbln,
vbeln like vbak-vbeln,
netwr like vbak-netwr,
end of ty_vbln.
types:begin of ty_vbap,
posnr like vbap-posnr,
end of ty_vbap.
data: it_kna1 type standard table of ty_kna1,
wa_kna1 like line of it_kna1.
data: it_vbln type standard table of ty_vbln,
wa_vbln like line of it_vbln.
data: it_vbap type standard table of ty_vbap,
wa_vbap like line of it_vbap.
START-OF-SELECTION.
select kunnr name1 from kna1 into corresponding fields of table it_kna1.
loop at it_kna1 into wa_kna1.

write:/ wa_kna1-kunnr,
wa_kna1-name1.
hide: wa_kna1-kunnr.
endloop.
TOP-OF-PAGE.
WRITE:/ 'GALAXE SOLUTIONS'.
At line-selection.
case sy-lsind.
when '1'.
select vbeln netwr from vbak into corresponding fields of table it_vbln
.
loop at it_vbln into wa_vbln.
write:/ wa_vbln-vbeln,
wa_vbln-netwr.
hide: wa_vbln-vbeln.
endloop.
when '2'.
select a~posnr b~matnr into corresponding fields of table it_vbap from
vbap as a inner join mara as b on a~matnr = b~matnr.
loop at it_vbap into wa_vbap.
write:/ wa_vbap-posnr,
wa_vbap-matnr.
endloop.
endcase.
Top-of-page during line-selection.
if sy-lsind = '1'.
write:/ ' first list'.
elseif sy-lsind = '2'.
write:/ 'second list'.
else.
write:/ 'proper list no'.
endif.

ALV (ABAP LIST VIEWER) Reports
Sap provides a set of ALV (ABAP LIST VIEWER) function modules, which can be
put into use to embellish the output of a report. This set of ALV functions is used to
enhance the readability and functionality of any report output. Cases arise in sap when
the output of a report contains columns extending more than 255 characters in length. In
such cases, this set of ALV functions can help choose selected columns and arrange the
different columns from a report output and also save different variants for report display.
This is a very efficient tool for dynamically sorting and arranging the columns from a
report output. The report output can contain up to 90 columns in the display with the
wide array of display options.
The commonly used ALV function modules are;
1. REUSE_ALV_LIST_DISPLAY
2. REUSE_ALV_GRID_DISPLAY
3. REUSE_ALV_EVENTS_GET
4. REUSE_ALV_COMMENTARY_WRITE
5. REUSE_ALV_FIELDCATALOG_MERGE
The different steps used for getting the above function modules into use are described
below.
Step 1: DATA DECLARATION
Sap standard type pools: SLIS.
Sap standard tables types taken from the type pools are:
SLIS_LAYOUT_ALV,
SLIS_T_FIELDCAT_ALV
SLIS_T_LISTHEADER,
SLIS_T_EVENT,
SLIS_SELFIELD.
Internal tables to be used in the program declared based on the above table types
TYPE-POOLS: SLIS.
* To pass name of the report in function module for ALV
Data: V_REPID LIKE SY-REPID.

* To pass the overall structure of the ALV report
Data: STRUCT_LAYOUT TYPE SLIS_LAYOUT_ALV.
* Internal table to capture various events in ALV
Data: I_EVENTS TYPE SLIS_T_EVENT.
* Table for catalog of the fields to be displayed
Data: I_FIELDCAT TYPE SLIS_T_FIELDCAT_ALV.
Data: X_FIELDCAT TYPE SLIS_FIELDCAT_ALV.
* Internal table to mention the sort sequence
Data: IT_SORT TYPE SLIS_T_SORTINFO_ALV.
Data: X_SORT TYPE SLIS_SORTINFO_ALV.
* Internal table to display top of page
Data: i_list_top_of_page type slis_t_listheader.
* Internal table to pass data
DATA: BEGIN OF I_TAB OCCURS 0,
MATNR LIKE MARA-MATNR,
MBRSH LIKE MARA-MBRSH,
END OF I_TAB.
Step2 (Defining Output Characteristics)
PREPARING DISPLAY FIELDS CATALOG
A field catalog is prepared using the internal table (I_FIELDCAT) of type
SLIS_T_FIELDCAT_ALV. Field catalog containing descriptions of the list output fields
(usually a subset of the internal output table fields).
A field catalog is required for every ALV list output to add desired functionality (i.e.
Key, Hotspot, Specific headings, Justify, Col. position etc) to certain fields of the output.
If not mentioned specifically, then the defaults are taken. The possible values and
defaults are listed below.
The minimal field catalog is documented below. This can be done in a routine using a
local variable. The user can use the other optional parameters to assign output attributes
to different fields in the output, which differ from the default.
A field catalog need not be built-up and passed explicitly only under the following
conditions:
1. The internal table to be output has the same structure as a Data Dictionary structure
which is referred to in the internal table declaration using LIKE or INCLUDE

STRUCTURE. In this case the attributes of the different fields is taken directly from the
table and the attributes (key fields, length, texts etc) need to state explicitly.
2. All fields in this structure are to be output
3. The structure name is passed to ALV in the parameter of the function module
REUSE_ALV_LIST_DISPLAY or REUSE_ALV_GRID_DISPLAY.
All the values entered in the catalog are specific to the particular field whose name is
entered in the fieldname FIELDNAME of the fieldcat structure. The name of the table is
also entered in the corr. Fieldname TABNAME of the structure.
The different possible attributes are:
• Col_pos (column position): This parameter is relevant when the fields in the output are
to be different from the sequence of the fields in the internal table used for display. The
parameter specifies the relative column position of the field in the list output. The column
order can be changed interactively by the user. If this parameter is initial for all field
catalog entries, columns appear in the internal table field sequence.
Value set: 0, 1 – 60
• Fieldname (field name): This is the name of the internal table field for which the
parameters are passed in the catalog.
Value set: internal output table field name (required parameter)
• Tabname (internal output table): Name of the internal output table that contains the
field FIELDCAT-FIELDNAME above.
• Outputlen (column width): This parameter is used if the desired output length for a
field is desired to be different from the internal output table field. For fields with a Data
Dictionary link this parameter can be left initial. For fields without a Data Dictionary link
(program field) the parameter must be given the value of the desired field list output
length (column width).
Initial = column width is the output length of the referred Data Dictionary field (domain).
N = column width is n characters.
• Text The following parameters are used for customizing the texts in the heading of the
output of the columns. The texts are taken from the Data Dictionary for fields with a Data
Dictionary reference. If this is not desired, the text parameters can also be specified. The
Data Dictionary texts are then ignored.
If the user changes the column width interactively, the column header text with the
appropriate length is always used.
The interactive function 'Optimize column width' takes account of both the field contents
and the column headers: if all field contents are shorter than the shortest column header,
the column width depends on the column header.
The 'long field label' is also used in display variant definition,
Sort, etc. Popup.

• seltext_l (long field label)
• seltext_m (medium field label)
• seltext_s (short field label)
Sample code to populate Fieldcatalog:
X_FIELDCAT-COL_POS = 0. * First field to appear in ALV list
X_FIELDCAT-FIELDNAME = 'MATNR'. * Name of the field in the internal table
X_FIELDCAT-TABNAME = 'I_TAB'. * Name of the internal table
X_FIELDCAT-OUTPUTLEN = 18. * Output Length of the field
X_FIELDCAT-SELTEXT_M = 'MatItem'. * Heading for the column
APPEND X_FIELDCAT TO I_FIELDCAT.
CLEAR X_FIELDCAT.
X_FIELDCAT-COL_POS = 1.
X_FIELDCAT-FIELDNAME = 'MBRSH'.
X_FIELDCAT-TABNAME = 'I_TAB'.
X_FIELDCAT-SELTEXT_M = 'Industry Sector'.
X_FIELDCAT-OUTPUTLEN = 50.
APPEND X_FIELDCAT TO I_FIELDCAT.
CLEAR X_FIELDCAT.
Step 3(Build up events table)
The next step is to build an event table, which are used for firing both user commands
and the system dependent events.
A list of possible events is populated into an event table (I_EVENTS) when this table is
passed from the function module REUSE_ALV_EVENT_GET. The return table from
this function module contains all the possible events.
The function module contains following import and export parameters.
IMPORTING PARAMETERS: I_LIST_TYPE
This parameter has possible values from 0-4.
The parameter I_LIST_TYPE is of TYPE SLIS_LIST_TYPE and is DEFAULT 0 .
EXPORTING PARAMETERS: I_EVENTS table.
This table is of TYPE SLIS_T_EVENT and returns to the program the name of all the
possible events.
The table structure contains the fields:
I_EVENTS-NAME: Name of the Callback event.

I_EVENTS-FORM: Name of the form routine that should be called in the calling
program at the event.
Only events with a form routine name are processed.
1. Slis_ev_user_command TYPE slis_formname VALUE 'USER_COMMAND'.
As this is a frequently-used Callback event, the form routine can also be passed directly
in the interface by passing the user command in the IMPORTING parameter
I_CALLBACK_USER_COMMAND.
2. Slis_ev_top_of_page TYPE slis_formname VALUE 'TOP_OF_PAGE'.
Equivalent to the list processing TOP-OF-PAGE event.
3. Slis_ev_top_of_coverpage TYPE slis_formname VALUE 'TOP_OF_COVERPAGE'.
The selection information and list status are output together (if they exist) on a separate
page by default
4. Slis_ev_end_of_coverpage TYPE slis_formname VALUE 'END_OF_COVERPAGE'.
Analogously to TOP_OF_COVERPAGE the user can add other information
to the information output by ALV (selection information, list status) at this event.
5. Slis_ev_pf_status_set TYPE slis_formname VALUE 'PF_STATUS_SET'.
If a user list status is to be set, it must be done in the form routine assigned to this event.
The ALV function codes, which must not be active, are in the Parameter RT_EXTAB.
This table must be passed with the SET PF-STATUS command (with inactive user
function codes as well, if necessary).
Sample code for Events :
FORMNAME_TOP_OF_PAGE TYPE SLIS_FORMNAME VALUE 'TOP_OF_PAGE',
FORMNAME_USER_COMMAND TYPE SLIS_FORMNAME VALUE
'USER_COMMAND'.
DATA: L_I_EVENT TYPE SLIS_ALV_EVENT.
CALL FUNCTION 'REUSE_ALV_EVENTS_GET'
EXPORTING
I_LIST_TYPE = 0
IMPORTING
ET_EVENTS = I_EVENTS.
READ TABLE I_EVENTS WITH KEY NAME = SLIS_EV_TOP_OF_PAGE INTO
L_I_EVENT.
IF SY-SUBRC = 0.
MOVE FORMNAME_TOP_OF_PAGE TO L_I_EVENT-FORM.
APPEND L_I_EVENT TO I_EVENTS.
ENDIF.

READ TABLE I_EVENTS WITH KEY NAME = SLIS_EV_USER_COMMAND INTO
L_I_EVENT.
IF SY-SUBRC = 0.
MOVE FORMNAME_USER_COMMAND TO L_I_EVENT-FORM.
APPEND L_I_EVENT TO I_EVENTS.
ENDIF.
This will prepare the events table for the report.
The report will contain three forms for the above events:
1. FORM TOP_OF_PAGE: This form will contain the top of page event for the report
i.e. header etc
Using the function module ‘REUSE_ALV_COMMENTARY_WRITE’, the internal table
containing the headings for top of page event can be passed to the list output. Also, any
logo specific to the report can be passed to the function module.
2. FORM USER_COMMAND: This form will contain the desired user command i.e.
pick/line selection
Step 4(Report Output list description)
A layout is build for the report output list description USING the internal table declared
above (I_LAYOUT).
Output list description structure.
The parameters are described under the following heads:
• Display options
• Exceptions
• Totals
• Interaction
• Detail screen
• Display variants (only for hierarchical-sequential lists)
• Color
• Other
The layout table is of type slis_layout_alv_spec and has the following fields:
Display options
1. Colwidth_optimize (1) TYPE c: This parameter optimizes the length of the different
columns in the output. The width of the different col. now depends on the max. Length of
the data in the column.
Value set: SPACE, 'X'
'X' = optimizes the column width so that all contents are displayed completely.
2. No_colhead (1) TYPE c: This parameter suppresses the column headings
Value set: SPACE, 'X'.
'X' = column headers are not output
3. Zebra(1) TYPE c : The report is output in the striped pattern.

Value set: SPACE, 'X'.
'X' = striped pattern (e.g. for wide lists)
4. No_sumchoice (1) TYPE c: This parameter allows the choice for summing up Only by
field catalog.
Value set: SPACE, 'X'
'X' = fields which are to be summed, passed by the calling program (FIELDCAT-
DO_SUM = 'X'). The user should not be able to change this value interactively.
5. List_append(1) TYPE c : no call screen. It is only useful to output block-lists without
specifying the above modules if the number of list blocks exceeds, or may exceed, the
maximum number specified in the block module documentation. These operations are not
possible for user-defined block lists.
Example code for Layouts :
I_LAYOUT-zebra = 'X'.
I_LAYOUT-colwidth_optimize = 'X'.
I_LAYOUT-key_hotspot = ‘X’.
Step 5(Deciding Sort Criteria)
The Table IT_SORT is populated with the sort criteria for the different fields.
The caller specifies the sorting and/or subtotaling of the basic list in the internal table
IT_SORT.
This internal table has the following fields:
• spos : Sort sequence
• fieldname : Internal output table field name
• tabname : Only relevant for hierarchical-sequential lists. Name of the internal output
table.
• up : 'X' = sort in ascending order
• down : 'X' = sort in descending order
• subtot : 'X' = subtotal at group value change
• group : '* ' = new page at group value change ,'UL' = underline at group value change
Step 8(Final Step)
The final step in the output of the report is the use of two ALV functions modules.
1. REUSE_ALV_FIELDCATALOG_MERGE
2. REUSE_ALV_LIST_DISPLAY
The first function module is used to pass the field catalog to the report output and merge
it with the internal output table.
FUNCTION reuse_alv_fieldcatalog_merge.
*"---------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*” IMPORTING

*" VALUE(I_PROGRAM_NAME) LIKE SY-REPID OPTIONAL
*" VALUE(I_INTERNAL_TABNAME) TYPE SLIS_TABNAME OPTIONAL
*" VALUE(I_STRUCTURE_NAME) LIKE DD02L-TABNAME OPTIONAL
*" VALUE(I_CLIENT_NEVER_DISPLAY) TYPE SLIS_CHAR_1 default ‘X’
*" VALUE(I_INCLNAME) LIKE TRDIR-NAME OPTIONAL
*" CHANGING
*" VALUE(CT_FIELDCAT) TYPE SLIS_T_FIELDCAT_ALV
*" EXCEPTIONS
*" INCONSISTENT_INTERFACE
*" PROGRAM_ERROR
*"---------------------------------------------------------------------
Import parameters
I_PROGRAM_NAME: Program in which the internal output table is declared and
populated
I_INTERNAL_TABNAME: Internal output table name
I_STRUCTURE_NAME: Structure name (structure, table, and view)
I_CLIENT_NEVER_DISPL: Hide client fields default ‘X’
I_INCLNAME: Data declarations include name
CHANGING parameter
CT_FIELDCAT: Field catalog with field descriptions
The variant based on a program-internal table should only be used for rapid prototyping
since the following restrictions apply:
1. Performance is affected since the code of the table definition must always be read and
interpreted at runtime.
2. Dictionary reference are only considered if the keywords LIKE or INCLUDE
STRUCTURE (not TYPE) are used.
Step 8(Display Internal Output Table)
The other function module is used to display the internal output table with the contents
FUNCTION reuse_alv_list_display.
*"----------------------------------------------------------------------
*"*"Lokale Schnittstelle:
” IMPORTING
*" VALUE(I_INTERFACE_CHECK) DEFAULT SPACE
*" VALUE(I_CALLBACK_PROGRAM) LIKE SY-REPID DEFAULT SPACE
*" VALUE(I_CALLBACK_PF_STATUS_SET) TYPE SLIS_FORMNAME DEFAULT
SPACE
*" VALUE(I_CALLBACK_USER_COMMAND) TYPE SLIS_FORMNAME
DEFAULT SPACE
*" VALUE(I_STRUCTURE_NAME) LIKE DD02L-TABNAME OPTIONAL
*" VALUE(IS_LAYOUT) TYPE SLIS_LAYOUT_ALV OPTIONAL
*" VALUE(IT_FIELDCAT) TYPE SLIS_T_FIELDCAT_ALV OPTIONAL
*" VALUE(IT_EXCLUDING) TYPE SLIS_T_EXTAB OPTIONAL
*" VALUE(IT_SPECIAL_GROUPS) TYPE SLIS_T_SP_GROUP_ALV OPTIONAL

*" VALUE(IT_SORT) TYPE SLIS_T_SORTINFO_ALV OPTIONAL
*" VALUE(IT_FILTER) TYPE SLIS_T_FILTER_ALV OPTIONAL
*" VALUE(IS_SEL_HIDE) TYPE SLIS_SEL_HIDE_ALV OPTIONAL
*" VALUE(I_DEFAULT) DEFAULT 'X'
*" VALUE(I_SAVE) DEFAULT SPACE
*" VALUE(IS_VARIANT) LIKE DISVARIANT STRUCTURE DISVARIANT
DEFAULT SPACE
*" VALUE(IT_EVENTS) TYPE SLIS_T_EVENT OPTIONAL
*" VALUE(IT_EVENT_EXIT) TYPE SLIS_T_EVENT_EXIT OPTIONAL
*" VALUE(IS_PRINT) TYPE SLIS_PRINT_ALV OPTIONAL
*" VALUE(IS_REPREP_ID) TYPE SLIS_REPREP_ID OPTIONAL
*" VALUE(I_SCREEN_START_COLUMN) DEFAULT 0
*" VALUE(I_SCREEN_START_LINE) DEFAULT 0
*" VALUE(I_SCREEN_END_COLUMN) DEFAULT 0
*" VALUE(I_SCREEN_END_LINE) DEFAULT 0
" EXPORTING
*" VALUE(E_EXIT_CAUSED_BY_CALLER)
*" VALUE(ES_EXIT_CAUSED_BY_USER) TYPE SLIS_EXIT_BY_USER
" TABLES
*" T_OUTTAB
" EXCEPTIONS
*" PROGRAM_ERROR
Import parameters
I_INTERFACE_CHECK: Interface consistency check log output.
I_CALLBACK_PROGRAM: Name of the calling program
I_CALLBACK_PF_STATUS_SET: Set EXIT routine to status.
I_CALLBACK_USER_COMMAND: EXIT routine for command handling
I_STRUCTURE_NAME: Internal output table structure name
IS_LAYOUT: List layout specifications
IT_FIELDCAT: Field catalog with field descriptions
IT_EXCLUDING: Table of inactive function codes
IT_SPECIAL_GROUPS: Grouping fields for column selection
IT_SORT: Sort criteria for first list display
IT_FILTER: Filter criteria for first list output
IS_SEL_HIDE: Selection information modification
I_DEFAULT: Initial variant active/inactive logic
I_SAVE: Variants can be saved
IS_VARIANT: Variant information
IT_EVENTS: Table of events to perform
IT_EVENT_EXIT: Standard fcode exit requests table
IS_PRINT: Print information
IS_REPREP_ID: Initialization keys for Re/Re interface
I_SCREEN_START_COLUMN: Coordinates for list in dialog box
I_SCREEN_START_LINE: Coordinates for list in dialog box
I_SCREEN_END_COLUMN: Coordinates for list in dialog box

I_SCREEN_END_LINE: Coordinates for list in dialog box
IT_EVENT_EXIT: Standard fcode exit requests table
IS_PRINT: Print information
IS_REPREP_ID: Initialization keys for Re/Re interface
I_SCREEN_START_COLUMN: Coordinates for list in dialog box
I_SCREEN_START_LINE: Coordinates for list in dialog box
I_SCREEN_END_COLUMN: Coordinates for list in dialog box
I_SCREEN_END_LINE: Coordinates for list in dialog box
Export parameters
E_EXIT_CAUSED_BY_CALLER: Delete list in CALLBACK_USER_COMMAND
ES_EXIT_CAUSED_BY_USER: How the user left the list Tables
T_OUTTAB: Table with data to be displayed ---mandatory
Documentation on function module: REUSE_ALV_GRID_DISPLAY
The function module outputs an internal table with whatever structure in the form of a
formatted single- or multi-line list.
Process:
􀂾Passing an internal table with the set of information to be output
􀂾Passing a structure with general layout specifications for list layout
􀂾Passing a field catalog in the form of an internal table
The field catalog describes the fields to be output in the list.
Notes
􀂾All interactions performed on the list refer directly to the internal output table. Sorting
the list, for example, also involves a resorting of the internal output table passed (since it
was passed by reference).
􀂾An important factor determining the usability of the tool or of various generic functions
(totals, subtotals) is the expected amount of data to be displayed.
Parameters :
• I_INTERFACE_CHECK
• I_BYPASSING_BUFFER
• I_BUFFER_ACTIVE
• I_CALLBACK_PROGRAM
• I_CALLBACK_PF_STATUS_SET
• I_CALLBACK_USER_COMMAND
• I_CALLBACK_TOP_OF_PAGE
• I_CALLBACK_HTML_TOP_OF_PAGE
• I_CALLBACK_HTML_END_OF_LIST
• I_STRUCTURE_NAME
• I_BACKGROUND_ID
• I_GRID_TITLE
• I_GRID_SETTINGS
• IS_LAYOUT

• IT_FIELDCAT
• IT_EXCLUDING
• IT_SPECIAL_GROUPS
• IT_SORT
• IT_FILTER
• IS_SEL_HIDE
• I_DEFAULT
• I_SAVE
• IS_VARIANT
• IT_EVENTS
• IT_EVENT_EXIT
• IS_PRINT
• IS_REPREP_ID
• I_SCREEN_START_COLUMN
• I_SCREEN_START_LINE
• I_SCREEN_END_COLUMN
• I_SCREEN_END_LINE
• IT_ALV_GRAPHICS
• IT_ADD_FIELDCAT
• IT_HYPERLINK
• E_EXIT_CAUSED_BY_CALLER
• ES_EXIT_CAUSED_BY_USER
I_CALLBACK_PROGRAM: Name of the calling program
Program from which the function module is called and that contains the exit routines. The
program should always be a report, function group, module pool or form routine pool (it
should not be an include).
Caution: Never pass SY-REPID directly at the interface. If field SY-REPID contains the
desired program name, you must absolutely assign this name to an auxiliary variable and
pass this variable to the interface.
I_CALLBACK_PF_STATUS_SET: Set EXIT runtime to status
Passing an EXIT routine indicates to the ALV that the caller wants to set a self-defined
user status. As a result, the default status of the ALV is not set. The interface of the form
routine specified must be defined as follows:
FORM set_pf_status USING rt_extab TYPE slis_t_extab
Table RT_EXTAB contains the function codes that would be hidden on the standard user
interface.
If the caller wants to use a self-defined user interface (for example, in order to provide
additional list functions or use existing functions), we recommend that you copy standard
status STANDARD from function group SALV and modify it accordingly. ALV standard
function codes always start with '&'.
See also the documentation on parameter I_CALLBACK_USER_COMMAND.

If a self-defined user interface is used that includes function codes of the standard user
interface, the function codes of the excluding table passed should be taken into account.
This means that the user status should generally be set as follows:
SET PF-STATUS user status EXCLUDING rt_extab.
Application functions can be added to excluding table rt_extab if they are to be disabled.
The routine is called whenever the standard user interface would be set with SET PF-
STATUS.
I_CALLBACK_TOP_OF_PAGE
EXIT routine for handling TOP-OF-PAGE
Description
If the caller specifies an EXIT routine, this routine must have the following form:
FORM top_of_page.
Module REUSE_ALV_COMMENTARY_WRITE can then be called within the EXIT
routine. This module is responsible for formatting the header information and also
ensures online HTML formatting. In the print preview or in batch mode, the text passed
is then output in the normal format.
If module REUSE_ALV_COMMENTARY_WRITE cannot be used, you must use two
parameters instead. In I_CALLBACK_TOP_OF_PAGE you pass the form routine that is
responsible for normal formatting in batch mode or in the print preview mode. The form
routine that is responsible for online formatting, is passed in parameter
Note the section on pre-defined settings.
Display options
• colwidth_optimize
Value range: SPACE, 'X'
X' = Optimizes the column width to ensure that the content is displayed completely.
• no_colhead
'X' = Do not output column headings.
• zebra
'X' = Striped pattern (for wide lists, for example)
• no_vline
‘X' = Separate columns by SPACE.
You can generate the field catalog automatically or semi-automatically by calling
function module
REUSE_ALV_FIELDCATALOG_MERGE.

See also the documentation on function module :
REUSE_ALV_FIELDCATALOG_MERGE.
The minimum values required for the field catalog are documented in the 'Default'
section. The caller can optionally use all other parameters to assign non-standard output
attributes to a field.
It is only in the following cases that you are not required to generate the field catalog and
pass it explicitly:
• The structure of the internal table to be output corresponds to a structure stored in the
Data Dictionary and is referenced with LIKE or INCLUDE STRUCTURE in the
declaration of the internal table.
• All fields of this structure should be output in the list.
• The structure name is declared to the ALV using parameter I_STRUCTURE_NAME.
See also the documentation on IMPORTNG parameter I_STRUCTURE_NAME.
Positioning
• col_pos (column position)
Value range: 0, 1 - 60
Only relevant if the relative column positions should by default not be identical to the
sequence of the fields in the field catalog.
The parameter determines the relative column position of the field in the list output. The
column sequence can interactively be changed by the user. If this parameter is set to its
initial value for each field catalog entry, the columns are arranged in the order of the
fields in the field catalog.
• fieldname (field name)
• outputlen (column width)
Value range: 0 (initial), n
For fields with reference to the Data Dictionary you can leave this parameter set to initial.
For fields without reference to the Data Dictionary (program fields) you must set the
parameter to the desired field output length on the list (column width).
initial = The column width is derived from the output length of the referenced field
(domain) in the Data Dictionary.
n = The column width is n characters.
• do_sum (calculate totals for column)
'X' = Totals are calculated for this field of the internal output table.
This function can also be used interactively by the user.
• no_sum (totals calculation not allowed)

'X' = No totals may be calculated for this field although the data type of the field allows
totalling.
Formatting column contents
The long field label is also used in the dialog boxes for defining the display variant, the
sort order, and so on.
• seltext_l (long field label)
• seltext_m (medium field label)
• seltext_s (short field label)
• reptext_ddic (heading)
Example Code
WS_REPNAME = SY-REPID.
CALL FUNCTION 'REUSE_ALV_FIELDCATALOG_MERGE'
EXPORTING
I_PROGRAM_NAME = WS_REPNAME
I_INTERNAL_TABNAME = Internal output table field name
I_INCLNAME = WS_REPNAME
CHANGING
CT_FIELDCAT = I_FIELDTAB.
IF SY-SUBRC <> 0.
WRITE: 'SY-SUBRC: ', SY-SUBRC, 'REUSE_ALV_FIELDCATALOG_MERGE'.
ENDIF.
CALL FUNCTION 'REUSE_ALV_LIST_DISPLAY'
EXPORTING
I_CALLBACK_PROGRAM = WS_REPNAME
I_STRUCTURE_NAME = Internal output table field name
IS_LAYOUT = I_LAYOUT
IT_FIELDCAT = I_FIELDTAB
I_DEFAULT = 'A'
I_SAVE = 'A'
IS_VARIANT = 'X'
IT_EVENTS = I_EVENTS[]
IT_SORT = I_SORT
IS_SEL_HIDE = I_SELINFO
TABLES
T_OUTTAB = Internal output table field name.
IF SY-SUBRC <> 0.

WRITE: 'SY-SUBRC: ', SY-SUBRC, 'REUSE_ALV_LIST_DISPLAY'.
ENDIF
Using other function module 'REUSE_ALV_GRID_DISPLAY’ can help us get list
output in the form of a grid and also attach logos to the report output.
1 Simple list output:
REPORT Y_DEMO_ALV NO STANDARD PAGE HEADING.
* Data to be displayed
DATA: I_SFLIGHT TYPE TABLE OF SFLIGHT.
*---------------------------------------------------------------------*
* Selection
SELECT * FROM SFLIGHT INTO TABLE I_SFLIGHT.
* Call ABAP List Viewer (ALV)
CALL FUNCTION 'REUSE_ALV_LIST_DISPLAY'
EXPORTING
I_STRUCTURE_NAME = 'SFLIGHT'
TABLES
T_OUTTAB = I_SFLIGHT.
2.Simple grid output:
REPORT Y_DEMO_ALV_1.
*
* Data to be displayed
DATA: I_SFLIGHT TYPE TABLE OF SFLIGHT.
*---------------------------------------------------------------------*
* Selection
SELECT * FROM SFLIGHT INTO TABLE I_SFLIGHT.
* Call ABAP List Viewer (ALV)
CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY'
EXPORTING
I_STRUCTURE_NAME = 'SFLIGHT'
TABLES
T_OUTTAB = I_SFLIGHT.

BATCH DATA COMMUNICATIONS/BATCH INPUT/INBOUND-
OUTBOUND (BDC’s)
ABOUT DATA TRANSFER
Implementing a new software system takes major effort. New implementation requires
moving data from the present system i.e., legacy system into the R3 system. The
product, components, customers and vendors have to be available in the new system.
Initial data transfer is the process of populating your R3 database with data from your
legacy system.
To prepare for the data transfer there are certain tasks you need to perform.
♦ First, understand your SAP system to know which data needs to be transferred, e.g.,
you would not transfer any sales order if you do not use the Sales and distribution
module.
♦ Second, you need to know the contents of existing data in your legacy system.
Data transfer program, an effective and efficient way of transferring large amount of data
into your new system, saves time and resources. But more importantly it ensures that
accurate data is transferred into R/3.
Two steps involved in data transfer are CONVERSION and SAP DATA
TRANSFER.
♦ CONVERSION, data is converted from your legacy system into the required flat file
format.

♦ SAP DATA TRANSFER, data is automatically entered into the SAP system. A
SAP data transfer program reads the prepared data from the flat file and moves it into
R/3.
Steps for any data transfer
Preparation for legacy database
This is the first step of transfer though not associated with SAP, plays very important role
in data transfer.
Before data is extracted, delete obsolete data in the legacy system and fix inconsistencies.
It is easier this way, than doing it during conversion.
The two steps involved in this are:
Data purging: Before transferring data from legacy system, delete all the old and
obsolete data, e.g.: To save conversion time and disk space, you may delete all one-time
customers, vendors and all unused materials.
Data cleansing: This process corrects data inconsistencies and ensures the integrity of
the existing data during the transfer process. Mistakes must be fixed before the transfer.
Converting legacy data to the flat file
For this second step, SAP provides no specific tools.
♦ In the ABAP/4 development workbench, write an ABAP/4 program to convert a file
from your legacy system into the required flat file structure.
♦ Use other programming language to write conversion program. For C, COBOL, you
can easily download the table definition for specific flat file structure.
♦ Use third party tools, such as format editors and code generators, which support
mapping and conversion between different file formats.
♦ For other RDBMS like oracle, Sybase, MS access, you have EXPORT utility. By
which, you can directly export data to flat file.
Files will be discussed in detail in later part of the topic.

Getting the data into R/3
This step actually transfers data to SAP database. After converting the data into the flat
file you are ready to begin the third step of the data transfer.
Data transfer is an interactive process. You may often feel like you are taking two steps
forward and one step back.
For example, short steps involved in whole process are as follows:
♦ Convert the data from the legacy system into the flat file format.
♦ Run the data transfer program.
♦ Check data for error.
♦ Is the transfer working as it was designed?
♦ If not, adjust the data/conversion program and start with step 1. Go back to step one,
if you don’t get the desired result.
You have three different options to enter your data into R/3.
♦ Automatically, with SAP standard data transfer programs.
♦ Automatically, by creating your own branch input programs
♦ Manually, by entering the data via the corresponding online transaction.
Automatic transfer with a standard data transfer program
This can be done if:
♦ A standard program exists for the data transfer of a business object in R/3.
♦ The data is available in electronic form.
♦ There is a significant number of records you want to transfer.
♦ The cost of converting the legacy data into the required flat file format is acceptable.
Manually transferring business objects
You should manually transfer data, if:
♦ You have no legacy system.
♦ There is only small number of records to enter.
♦ Translating legacy data into the R/3 structure is more an effort than manually entering
the data.

Using customer specific batch input to transfer business objects
Create batch input program to transfer data if:
♦ No standard program exists to transfer the business object in R/3.
♦ The data is available in electronic form.
♦ There is a significant number of records you want to transfer.
♦ Translating your legacy data into the structure required by your custom program is
easier than manually entering data.
♦
Batch input is a standard procedure for transferring large amount of data into the R/3
system. It simulates manual data entry. Data consistency is ensured because batch input
uses all the checks conducted on the normal screen. Using batch input is like entering the
data online. Another advantage to batch input is that you do not have to check the data in
advance.
Batch input is a two-step procedure. It involves a program that creates the batch input
session. This session is the data file that includes everything to begin the transaction and
the data to be entered on the appropriate screens. The data is not yet in the database tables
of R/3 application. The second step is to process the session, which then actually transfers
the data to database table. You can transfer data directly to database table by using CALL
TRANSACTION method also. Another method - Direct Input, is done for high volume
of data for the standard application. All these methods are discussed in detail in later part
of the topic.
Basically there are two steps involved in any transfer of data from legacy system to SAP
system.
- Creation of file and transferring file into SAP system
- Transferring data to database file
Whenever, you create flat file following points should be considered:
- Provide the data in an ASCII/Text file format.
- Know how each line of the file is structured.
- Know how the required flat file for the business object must be structured.
- Once your flat file is ready, the data should be transferred into SAP system.
Handling of local files
Introduction

Files on presentation server / workstation are LOCAL FILES.
Local files are processed using UPLOAD and DOWNLOAD functions. The local files
are brought into ABAP/4 memory using these functions. Unlike dataset, all the records of
the file are UPLOADED into an internal table in one shot. Similarly, all records are
DOWNLOADED in one shot from an internal table to a local file.
DOWNLOAD function:
Important EXPORTING parameters for this function are:
Filename = name of the local file to which the internal table is to be downloaded.
Filetype = file type, default values are ASC, DAT, BIN
Mode = Write mode, overwrite (‘ ‘) or append (‘A’)
Important IMPORTING parameters are:
Filename = actual file name entered
Tables to be passed to the function:
Data_tab = the internal table that is to be downloaded.
Similar function called GUI_DOWNLOAD is used to download the information from
internal table to local file.
UPLOAD function
Upload function is used to upload the local file to internal table into SAP system.
For uploading, you have similar function called GUI_UPLOAD.
Files with multiple record types
Many times the input files will have records with different structures. In all such cases
each record will have a field, (usually the first) which identifies the record (e.g., ‘H’ for
header, ‘D’ for detail or ‘1’ & ‘2’ etc).
Text tile with multiple record types would be as mentioned below:
Hxxxxyyyyyyyynnnnnnnnn
Daaaaaaaaaabbbbbbbbbcccccccc
Daaaaaaaaaabbbbbbbbbbcccccccc
Hxxxxyyyyyyynnnnnnnnnnn

Processing Text file with multiple record types:
To process such files, it is necessary to first read the record into a character field that is a
minimum of the lengths of the different structure in the file. If ‘H’ type record is 30 char
long (including the record identifier) and ‘D’ type is 40 long (including the record
identifier), then this character field should be at least 40 char long.
BATCH DATA COMMUNICATION
About Data Transfer In R/3 System
When a company decides to implement the SAP R/3 to manage business-critical data, it
usually does not start from a no-data situation. Normally, a SAP R/3 project comes into
replace or complement existing application.
In the process of replacing current applications and transferring application data, two
situations might occur:
♦ The first is when application data to be replaced is transferred at once, and only once.
♦ The second situation is to transfer data periodically from external systems to SAP and
vice versa.
♦ There is a period of time when information has to be transferred from existing
application, to SAP R/3, and often this process will be repetitive.
The SAP system offers two primary methods for transferring data into SAP systems.
From non-SAP systems or legacy system. These two methods are collectively called
“batch input” or “batch data communication”.
1. SESSION METHOD

2. CALL TRANSACTION
3. DIRECT INPUT
Advantages offered by BATCH INPUT method:
1. Can process large data volumes in batch.
2. Can be planned and submitted in the background.
3. No manual interaction is required when data is transferred.
4. Data integrity is maintained as whatever data is transferred to the table is through
transaction. Hence batch input data is submitted to all the checks and validations.
To implement one of the supported data transfers, you must often write the program that
exports the data from your non-SAP system. This program, known as a “data transfer”
program must map the data from the external system into the data structure required by
the SAP batch input program.
The batch input program must build all of the input to execute the SAP transaction.
Two main steps are required:
♦ To build an internal table containing every screen and every field to be filled in
during the execution of an SAP transaction.
♦ To pass the table to SAP for processing.
Prerequisite for Data Transfer Program
Writing a Data Transfer Program involves following prerequisites:
Analyzing data from local file
Analyzing transaction
Analyzing transaction involves following steps:
♦ The transaction code, if you do not already know it.
♦ Which fields require input i.e., mandatory.
♦ Which fields can you allow to default to standard values.
♦ The names, types, and lengths of the fields that are used by a transaction.
♦ Screen number and Name of module pool program behind a particular transaction.
To analyze a transaction:

♦ Start the transaction by menu or by entering the transaction code in the command
box.
(You can determine the transaction name by choosing System – Status.)
♦ Step through the transaction, entering the data will be required for processing your
batch input data.
♦ On each screen, note the program name and screen (dynpro) number.
(dynpro = dyn + pro. Dyn = screen, pro = number)
♦ Display these by choosing System – Status. The relevant fields are Program (dynpro)
and Dynpro number. If pop-up windows occur during execution, you can get the
program name and screen number by pressing F1 on any field or button on the screen.
The technical info pop-up shows not only the field information but also the program
and screen.
♦ For each field, check box, and radio button on each screen, press F1 (help) and then
choose Technical Info.
Note the following information:
- The field name for batch input, which you’ll find in its own box.
- The length and data type of the field. You can display this information by
double clicking on the Data Element field.
♦ Find out the identification code for each function (button or menu) that you must
execute to process the batch-input data (or to go to new screen).
Place the cursor on the button or menu entry while holding down the left mouse
button. Then press F1.
In the pop-up window that follows, choose Technical info and note the code that is
shown in the Function field.
You can also run any function that is assigned to a function key by way of the
function key number. To display the list of available function keys, click on the right
mouse button. Note the key number that is assigned to the functions you want to run.
Once you have program name, screen number, field name (screen field name), you
can start writing.
DATA TRANSFER program.

Declaring internal table
First Integral Table similar to structure like local file.
Declaring internal table like BDCDATA
The data from internal table is not transferred directly to database table, it has to go
through transaction. You need to pass data to particular screen and to particular screen-
field. Data is passed to transaction in particular format, hence there is a need for batch
input structure.
The batch input structure stores the data that is to be entered into SAP system and the
actions that are necessary to process the data. The batch input structure is used by all of
the batch input methods. You can use the same structure for all types of batch input,
regardless of whether you are creating a session in the batch input queue or using CALL
TRANSACTION.
This structure is BDCDATA, which can contain the batch input data for only a single run
of a transaction. The typical processing loop in a program is as follows:
♦ Create a BDCDATA structure
♦ Write the structure out to a session or process it with CALL TRANSACTION
USING; and then
♦ Create a BDCDATA structure for the next transaction that is to be processed.
Within a BDCDATA structure, organize the data of screens in a transaction. Each screen
that is processed in the course of a transaction must be identified with a BDCDATA
record. This record uses the Program, Dynpro, and Dynbegin fields of the structure.
The screen identifier record is followed by a separate BDCDATA record for each value,
to be entered into a field. These records use the FNAM and FVAL fields of the
BDCDATA structure. Values to be entered in a field can be any of the following:
♦ Data that is entered into screen fields.
♦ Function codes that are entered into the command field. Such function codes execute
functions in a transaction, such as Save or Enter.
♦
The BDCDATA structure contains the following fields:

♦ PROGRAM: Name of module pool program associated with the screen. Set this field
only for the first record for the screen.
♦ DYNPRO: Screen Number. Set this field only in the first record for the screen.
♦ DYNBEGIN: Indicates the first record for the screen. Set this field to X, only for the
first record for the screen. (Reset to ‘ ‘ (blank) for all other records.)
♦ FNAM: Field Name. The FNAM field is not case-sensitive.
♦ FVAL: Value for the field named in FNAM. The FVAL field is case-sensitive.
Values assigned to this field are always padded on the right, if they are less than 132
characters. Values must be in character format.
Transferring data from local file to internal table
Data is uploaded to internal table by UPLOAD of WS_UPLOAD function.
Population of BDCDATA
For each record of internal table, you need to populate Internal table, which is similar to
BDCDATA structure.
All these five initial steps are necessary for any type of BDC interface.
DATA TRANSFER program can call SESSION METHOD or CALL TRANSACTION.
The initial steps for both the methods are same.
First step for both the methods is to upload the data to internal table. From Internal
Table, the data is transferred to database table by two ways i.e., Session method and
Call transaction.
SESSION METHOD
About Session method
In this method you transfer data from internal table to database table through sessions.
In this method, an ABAP/4 program reads the external data that is to be entered in the
SAP System and stores the data in session. A session stores the actions that are required
to enter your data using normal SAP transaction i.e., Data is transferred to session which
in turn transfers data to database table.
Session is intermediate step between internal table and database table. Data along with its
action is stored in session i.e., data for screen fields, to which screen it is passed, the
program name behind it, and how the next screen is processed.

When the program has finished generating the session, you can run the session to execute
the SAP transactions in it. You can either explicitly start and monitor a session or have
the session run in the background processing system.
Unless session is processed, the data is not transferred to database table.
BDC_OPEN_GROUP
You create the session through program by BDC_OPEN_GROUP function.
Parameters to this function are:
♦ User Name: User name
♦ Group: Name of the session
♦ Lock Date: The date on which you want to process the session.
♦ Keep: This parameter is passed as ‘X’ when you want to retain session
after processing it or ‘ ‘to delete it after processing.
BDC_INSERT
This function creates the session & data is transferred to Session.
Parameters to this function are:
♦ Tcode: Transaction Name
♦ Dynprotab: BDC Data
BDC_CLOSE_GROUP
This function closes the BDC Group. No Parameters.
Some additional information for session processing
When the session is generated using the KEEP option within the BDC_OPEN_GROUP,
the system always keeps the sessions in the queue, whether it has been processed
successfully or not.
However, if the session is processed, you have to delete it manually. When session
processing is completed successfully while KEEP option was not set, it will be removed
automatically from the session queue. Log is not removed for that session.
If the batch-input session is terminated with errors, then it appears in the list of
INCORRECT session and it can be processed again. To correct incorrect session, you can

analyze the session. The Analysis function allows to determine which screen and value
has produced the error. If you find small errors in data, you can correct them
interactively, otherwise you need to modify batch input program, which has generated the
session or many times even the data file.
CALL TRANSACTION
About CALL TRANSACTION
A technique similar to SESSION method, while batch input is a two-step procedure, Call
Transaction does both steps online, one after the other. In this method, you call a
transaction from your program by
Call transaction <tcode> using <BDCTAB>
Mode <A/N/E>
Update <S/A>
Messages into <MSGTAB>.
Parameter – 1 is transaction code.
Parameter – 2 is name of BDCTAB table.
Parameter – 3 here you are specifying mode in which you execute transaction
A is all screen mode. All the screen of transaction are displayed.
N is no screen mode. No screen is displayed when you execute the
transaction.
E is error screen. Only those screens are displayed wherein you have error
record.
Parameter – 4 here you are specifying update type by which database table is updated.
S is for Synchronous update in which if you change data of one table then
all the related Tables gets updated. And sy-subrc is returned i.e., sy-subrc
is returned for once and all.
A is for Asynchronous update. When you change data of one table, the sy-
subrc is returned. And then updating of other affected tables takes place.
So if system fails to update other tables, still sy-subrc returned is 0 (i.e.,
when first table gets updated).

Parameter – 5 when you update database table, operation is either successful or
unsuccessful or operation is successful with some warning. These
messages are stored in internal table, which you specify along with
MESSAGE statement. This internal table should be declared like
BDCMSGCOLL, a structure available in ABAP/4. It contains the
following fields:
1. Tcode: Transaction code
2. Dyname: Batch point module name
3. Dynumb: Batch input Dyn number
4. Msgtyp: Batch input message type (A/E/W/I/S)
5. Msgspra: Batch input Lang, id of message
6. Msgid: Message id
7. MsgvN: Message variables (N = 1 - 4)
For each entry, which is updated in database, table message is available in
BDCMSGCOLL. As BDCMSGCOLL is structure, you need to declare a internal table
which can contain multiple records (unlike structure).
Steps for CALL TRANSACTION method
1. Internal table for the data (structure similar to your local file)
2. BDCTAB like BDCDATA
3. UPLOAD or WS_UPLOAD function to upload the data from local
file to itab. (Considering file is local file)
4. Loop at itab.
Populate BDCTAB table.
Call transaction <tcode> using <BDCTAB>
Mode <A/N/E>
Update <S/A>.
Refresh BDCTAB.

Endloop.
(To populate BDCTAB, You need to transfer each and every field)
The major differences between Session method and Call transaction are as follows:
SESSION METHOD CALL TRANSACTION
1. Data is not updated in database
table unless Session is processed.
Immediate updation in database
table.
2. No sy-subrc is returned. Sy-subrc is returned.
3. Error log is created for error
records.
Errors need to be handled
explicitly
4. Updation in database table is
always synchronous
Updation in database table can be
synchronous Or Asynchronous.
Error Handling in CALL TRANSACTION
When Session Method updates the records in database table, error records are stored in
the log file. In Call transaction there is no such log file available and error record is lost
unless handled. Usually you need to give report of all the error records i.e., records which
are not inserted or updated in the database table. This can be done by the following
method:
Steps for the error handling in CALL TRANSACTION
1. Internal table for the data (structure similar to your local file)
2. BDCTAB like BDCDATA
3. Internal table BDCMSG like BDCMSGCOLL

4. Internal table similar to Ist internal table
(Third and fourth steps are for error handling)
5. UPLOAD or WS_UPLOAD function to upload the data from the local
file to itab. (Considering file is local file)
6. Loop at itab.
Populate BDCTAB table.
Call transaction <tr.code> using <Bdctab>
Mode <A/N/E>
Update <S/A>
Messages <BDCMSG>.
Perform check.
Refresh BDCTAB.
Endloop.
7 Form check.
IF sy-subrc <> 0. (Call transaction returns the sy-subrc if updating is not
successful).
Call function Format_message.
(This function is called to store the message given by system and to
display it along with record)
Append itab2.
Display the record and message.
Common batch input errors
- The batch input BDCDATA structure tries to assign values to fields which do not
exist in the current transaction screen.
- The screen in the BDCDATA structure does not match the right sequence, or an
intermediate screen is missing.

- On exceptional occasions, the logic flow of batch input session does not exactly
match that of manual online processing. Testing the sessions online can discover by
this.
- The BDCDATA structure contains fields, which are longer than the actual definition.
- Authorization problems.
RECORDING A BATCH INPUT
A B recording allows you to record a R/3 transaction and generate a program that
contains all screens and field information in the required BDC-DATA format.
You can either use SHDB transaction for recording or
SYSTEM → SERVICES → BATCH INPUT → EDIT
And from here click recording.
Enter name for the recording.
(Dates are optional)
Click recording.
Enter transaction code.
Enter.
Click Save button.
You finally come to a screen where, you have all the information for each screen
including BDC_OKCODE.
♦ Click Get Transaction.
♦ Return to BI.
♦ Click overview.
♦ Position the cursor on the just recorded entry and click generate program.
♦ Enter program name.
♦ Click enter
The program is generated for the particular transaction.
AN EXAMPLE WITH SESSION METHOD
Following program demonstrates how data is passed from flat file to SAP transaction and
further to database table by using SESSION method.
The transaction is TFBA (to change customer).

A simple transaction where you are entering customer number on first screen and on next
screen data is displayed for the particular customer number. Field, which we are changing
here, are name and city. When you click on save, the changed record gets saved.
Prerequisite to write this BDC interface as indicated earlier is:
1. To find screen number
2. To find screen field names, type of the field and length of the field.
3. To find BDC_OKCODE for each screen
4. Create flat file.
Flat file can be created in your hard disk as follows:
1 Vinod Krishna Hyderabad
2 Kavitha Secunderabad
3 Kishore Hyderabad
(Where 1st
character field is Customer number, 2nd
field is Customer name and 3rd
field is
City.)
To transfer this data to database table SCUSTOM following interface can be used.
REPORT DEMO1.
* Following internal table is to upload flat file.
ID(10),
NAME(25),
CITY(25),
END OF ITAB.
*Following internal table BDCDATA is to pass date from internal table to session.
DATA: BDCTAB LIKE BDCDATA OCCURS 0 WITH HEADER LINE.
* Variables
DATA: DATE1 LIKE SY-DATUM. DATE1 = SY-DATUM - 1. “ This is for Hold Date
* To upload flat file to internal table.
CALL FUNCTION UPLOAD
EXPORTING
FILE NAME = ‘C:FF.TXT’

FILE TYPE = ‘ASC”
TABLES
DATA_TAB = ITAB
EXCEPTIONS
CONVERSION_ERROR = 1
INVALID_TABLE_WIDTH = 2
INVALID_TYPE = 3
NO_BATCH = 4
UNKNOWN_ERROR = 5
OTHERS = 6.
If sy-subrc = 0.
* Calling Function to Create a Session
CALL FUNCTION ‘BDC_OPEN_GROUP’
EXPORTING
CLIENT = SY-MANDT
GROUP = ‘POTHURI’
HOLDDATE = DATE1
KEEP = ‘X’
USER = SY-UNAME
EXCEPTIONS
CLIENT_INVALID = 1
DESTINATION_INVALID = 2
GROUP_INVALID = 3
GROUP_IS_LOCKED = 4
HOLDDATE_INVALID = 5
INTERNAL_ERROR = 6
QUEUE_ERROR = 7
RUNNING = 8
SYSTEM_LOCK_ERROR = 9
USER_INVALID = 10
OTHERS = 11.

If sy-subrc = 0.
*-------------------------- MAIN Logic------------------------------
LOOP AT ITAB
PERFORM GENERATE_DATA. “ Populating BDCDATA Table
CALL FUNCTION ‘BDC_INSERT’
EXPORTING
TCODE = ‘TFBA’
TABLES
DYNPROTAB = BDCTAB
EXCEPTIONS
INTERNAL_ERROR = 1
NOT_OPEN = 2
QUEUE_ERROR = 3
TCODE_INVALID = 4
PRINTING_INVALID = 5
POSTING_INVALID= 6
OTHERS = 7.
REFRESH BDCTAB
ENDLOOP.
* Calling function to close the session
CALL FUNCTION ‘BDC_CLOSE_GROUP’
EXCEPTIONS
NOT_OPEN = 1
QUEUE_ERROR = 2
OTHERS = 3.
Endif.
Endif.
*&--------------------------------------------------------------------*
*& Form GENERATE_DATA
* Create BDC Data
*&--------------------------------------------------------------------*

FORM GENERATE_DATA
* Passing information for 1st screen on BDCDATA
BDCTAB-PROGRAM = ‘SAPMTFBA’.
BDCTAX-DYNPRO = 100.
BDCTAP-DYNBEGIN = ‘X’.
APPEND BCDTAB.CLEAR BDCTAB.
* Passing field information to BDCDATA
BDCTAB-FNAM = ‘SCUSTOM-ID’
BDCTAB-FVAL = ITAB-ID.
APPEND BDCTAB.CLEAR BDCTAB.
* Passing BDC_OKCODE to BDCDATA
BDCTAB-FNAM = ‘BDC_OKCODE’.
BDCTAB-FVAL = ‘/5’.
* Passing screen information for next screen to BDCDATA
BDCTAB-PROGRAM = ‘SAPMTFBA’.
BDCTAB-DYNPRO = 200.
BDCTAB-DYNBEGIN = ‘X’.
* Passing screen information to BDCDATA
BDCTAB-FNAM = ‘SCUSTOM-NAME’.
BDCTAB-FVAL = ITAB-NAME.
* Passing screen information to BDCDATA
BDCTAB-FNAM = ‘SCUSTOM-CITY’.
BDCTAB-FVAL = ITAB-CITY.
* Passing BDC_OKCODE to BDCDATA
BDCTAB-FNAM = ‘BDC_OKCODE’.
BDCTAB-FVAL = ‘SAVE’.

ENDFORM. “GENERATE_DATA
AN EXAMPLE WITH CALL TRANSACTION
Same steps to be repeated for CALL TRANSACTION
The only difference between the two types of interface is in Session method, you create
session and store information about screen and data into session. When session is
processed the data is transferred to database. While in CALL TRANSACTION, data is
transferred directly to database table.
REPORT DEMO1.
* Follow above Code till MAIN Logic. Even the Subroutine should be copied
LOOP AT ITAB
PERFORM GENERATE_DATA, “Populating BDCDATA Table
Call transaction ‘TFBA’ using BCDDATA Mode ‘A’ Update ‘S’.
REFRESH BDCTAB
ENDLOOP.
TRANSACTIONS
GENERAL INTRODUCTION TO TRANSACTION
Transaction, in R/3 system is an operation that lets the user make necessary changes to
the database. The entire R/3 system is nothing but set of business transaction. The data
transfer from old system to SAP R/3 database, or modifying data, or deleting data, which
is not required, is done through transaction.

For SAP system, Transaction is nothing but sequence of steps called as dialog steps and
for user it is sequence of screens that appears one after the other depending upon the
option he selects. The special transaction monitor called the SAP dispatcher handles the
sequence of steps that takes place in any transaction. The main task of transaction is to
update database table. The database table is not updated until a transaction is completed.
All changes can be rolled back if the transaction has not finished.
The transaction contains two steps which are as following:
• Interactive phase: In this step, user enters the data, which needs to be inserted or
deleted or modified on to the screen. There can be single screen or multiple
screens depending upon the transaction. So this step can consist of single step or
multiple steps. In this phase you prepare database record.
• Update phase: This phase processes the database record and updates the database
table. Actual updating of database table takes place in this phase.
All the transactions are associated with transaction code. And all these codes are stored in
a table TSTC.
Logical Unit of Work (LUW)
The R/3 system is multi user system and many users access the same information at the
same time, which is mainly DATA. Consider the case where one user is modifying a
record, and second user is trying to delete the same record. If the second user is
successful in deleting the record then the first user will face problem for modifying the
record that is already deleted. The avoid such situation, R/3 system has provided Logical
Unit of Work, which is defined as a locking mechanism to protect transaction integrity.
Of course, there are other measures, which ensures data integrity like check table i.e.
foreign key relationship. Within SAP system there are three types of transaction and may
be distinguished as:
• Database transaction known as LUW. It can be defined as a period in which
operation requested must be performed as a unit, i.e. all or nothing operation. At
the end of LUW, either of the database changes are committed or rolled back.
• Update transaction or SAP LUW. One SAP LUW can have several databases
LUW. So a set of a database is either committed or rolled back. The special
ABAP/4 command COMMIT WORK, marks the end of a SAP LUW.

• ABAP/4 transaction. Is made up of a set of related task combined under one
transaction code. ABAP/4 transactions are for programming environment, in
which ABAP/4 transaction functions like one complete object containing screens,
menus and transaction codes.
R/3 system has provided in built locking mechanism, which defines the Logical Unit of
Work. Also user can set his own locking mechanism. The LUW starts when a lock entry
in the system table is created, and it ends when the lock is released.
To provide the user the facility to communicate with the table in order to modify or delete
or insert data, R/3 has provided tool called SCREEN PAINTER. This tool allows you to
design screen, process screen through program and update the database table. SAP has
provided one and only one way to update the database table, i.e. transaction. Though you
can update database table by using open SQL statement through program, SAP usually
doesn’t recommend this kind of updating. Many standard transactions are available to
update standard table but if the need arises, the developer should be able to develop new
transaction, which allows the updating of database tables. This can be achieved by using
various components of screen painter.
Following are the few concepts and steps for creating entire new transaction.
DYNPRO concept
A dynpro refers to the screen + flow logic. With screen painter you can develop screen and
flow logic. The relationship between screen, flow logic, and program can be shown as
follows:
Screen 200
Module Pool
Program
Flow logic
Screen 100
Flow logic
Flow logic

Dynpro, as figure indicates consist of screen and flow logic and places exactly one call to
module pool program. A transaction consists of many screens and for each screen flow
logic is attached. When the transaction is executed, the screen places a call to flow logic
and flow logic in turn places a call to module pool program.
• A module program is usual ABAP/4 program that consist of modules and data
declaration.
• ABAP/4 is an event driven language. In module pool program too, events get
triggered and these events are handled in flow logic. Flow logic editor is subset of
ABAP/4 editor. The system automatically displays the two important events for
the flow logic.
• Screen is the important component of dynpro and can be created, designed by
screen painter.
Screen Painter
A screen painter can be started by
Development workbench  Screen Painter
Or
SE51 transaction code.
Using Screen Painter
The process of creating a dynpro includes the creation and definition of all the needed
screen components.
The steps involved in creating the dynpro are as follows:
• Create screen and attributes by using screen attribute screen.
• Select and place the needed fields within the screen by using dict/program fields.
• Establish the field attributes to which the screen belongs by using field list.
• Define the flow logic respect to the transaction to which it belongs by using flow
logic.
Creating a new Screen
Steps involved are as follows:
• Enter the name of program and number of the screen
• Click on Create
• On “screen attribute” screen enter short description
• Enter screen type. Normally, you select NORMAL option for usual R/3 screen.
Other options available are SUBSCREEN & MODAL DIALOG BOX. Modal
dialog box is used to establish independent and interactive dialog box while
subscreen is screen within screen.

• Next attribute to be passed is NEXT SCREEN. Here you need to specify the next
screen number, which must be processed after the current one.
Designing of Screen
Screen can be designed by using FULL SCREEN EDITOR. You can go to full screen
editor.
From screen attribute screen
By pressing full screen editor pushbutton
Or
From initial screen of screen painter.
There are two modes available with full screen editor.
• Graphical mode. The graphical mode works similarly to typical window
application.
• Alphanumeric mode (rarely used).
Elements of screen
• Text – Standard text or field labels.
• Entry - display field.
• Radiobutton – All radiobutton must be associated with one group.
• Checkbox – Normally used for YES/NO operations.
• Pushbutton – Used for activating particular function.
• Boxes – grouping together many screen elements.
• Subscreens – This is a screen area in which you can display another screen.
• Table controls – This area of screen is similar to table but should be treated as a
loop.
• Status - Display output fields containing icon.
All these elements are on the control bar of full screen editor and can be placed on the
screen work area by clicking and placing them wherever needed.
Selecting Screen Fields
Screen field can be either dictionary objects or program fields. Steps involved in the
placing of fields on the screen are as follows:
Click the pushbutton Dict/program fields on the full screen editor
Or

Goto  dict/prog fields.
• Enter table name.
• Click Get from dictionary.
• Select fields.
• Click copy pushbutton.
• Position the cursor where you want those fields to be placed.
To adjust various screen elements, you can use drag and drop facility for screen elements.
Attributes of Screen Elements
The entire element of a screen has some attributes, which determines their behavior.
• General – These attributes are directly managed by the screen painter like name of
the element, or text of element or column width and various things associated
with the screen.
• Dictionary – These attributes are applicable to fields, which are from dictionary.
Various components of dictionary can be attached to this element like search help,
foreign key.
• Program.
• Display – Behavior of the element with respect to their display feature.
Attribute dialog box can be displayed by
• Clicking on the ATTRIBUTE push button on the application tool bar.
• Double clicking on the element.
Field List
This list displays a list of all screen elements together with their screen attributes. One
important element of Field list is OKCODE. Any pushbutton is associated with function
code as in menu item in menu painter. When the user clicks the pushbutton this code is
stored in OKCODE. This OKCODE is created by system without a name and is not
visible on the screen. In ABAP/4 this field is work field and is nothing but an area
wherein system stores the variable and is the last field of the field list and is invisible,
hence user needs to give the name OKCODE. It is not mandatory to give the name
OKCODE; developer can give any name to this field.

Screen Flow Logic
You can go to this screen either by
Initial screen of Screen painter  Flow logic
Or
From Screen attribute screen  Flow logic
When transaction is executed, the screen is displayed, user enters few fields, selects few
functions. Later the screen is processed and processing of screen is done by flow logic.
The events that are associated with screen are as follows:
• Process before Output (PBO)
• Process after input (PAI)
• Process on value request (POV)
• Process on help request (POH)
The system automatically displays two very important events or modules in flow logic
i.e. PAI and PBO
PBO event
This event is triggered before the screen is displayed. The processing of screen before the
display of screen is done in this event. For example, filling in default values in the screen
fields.
PAI event
This event is responsible for processing of screen after the user enters the data and clicks
the pushbutton. The processing of screen can include displaying another screen, or just
displaying list or quitting the transaction itself and many more things. Usually it is
displaying another screen. These operations can be carried out in the PAI event.
OKCODE plays an important role in this operation.
POV event
Process on value request is triggered when the user clicks F4 key. You can handle this
event when the user presses F4 key by writing code for the same in module pool
program. Normally when the user presses F4, list of possible values is displayed. The
standard list produced by system is adequate for applications you develop yourself.

However, you can also have the option of setting up your own documentation and lists of
possible values that are more detailed.
POH event
Normally when the user places the cursor on the field and presses F1 function key, the
system displays its own Help for that particular field. You can add your own functionality
to the Help button by writing code for the same in the POH event.
Module Pool Programming
This component though is not attached to the screen painter, plays important role in
transaction. Normally, for reports, on line executable programs are written but for
transaction, Module Pool Programs are written. The module pool program contains only
modules to handle various events associated with screen and data declaration statements.
System divides the module pool program into several include program. These are global
field, PBO modules, and PAI modules. It is entirely user’s decision whether to use these
modules or write directly into main program.
Creation of Module Pool Program
You can create module pool program either through
Object browser
System automatically creates the module pool program and for these program which are
created through object browser, system creates the include modules.
Or
ABAP/4 editor
It is similar to normal program creation. Type of program should be given ‘M’ and is not
created by system.
Communication between Dynpro and Module Program
For each screen, the system executes the flow logic, which contains corresponding
events. The control is passed to Module Pool Program. Module Pool Program handles the
code for these events and again passes back control to the flow logic and finally to

screen. Unlike on line program, in this case, the control remains with flow logic. The
switching of control between flow logic and module pool program and back is common
process when user executes transaction.
Creation of a Complete Transaction
Steps involved to create a complete transaction
• Create module pool program.
• From screen painter create screens.
• Write flow logic for each screen.
• Write code for all the events in module pool program.
• Check for any error in screen and flow logic.
• Generate each and every component of screen i.e. flow logic and screen.
• Single screen can be tested using Screen Painter.
• Create transaction code through object browser.
• Generate the transaction code.
• User can execute the transaction by entering the transaction code in the command
field.
Handling Function Code
The function code or OKCODE is the last field of Field list. Function code can be
handled as follows:
During the Designing of the screen, a function code is assigned to pushbutton.
• In field list, developer needs to specify OKCODE as last field.
• In module program it is a global field and can be evaluated in the PAI event.
• A function code is treated in the same way, regardless it comes from pushbutton,
menu item or any other GUI element.
A complete example for transaction is shown below:
If you have a screen like the one below:

When the user clicks on the Display button, you want to display details of sflight, with
corresponding carrid and connid (which is entered by the user).
Module pool program to handle this particular screen is as follows:
Program YVTEST7.
TABLES: SFLIGHT.
DATA: OKCODE (4).
MODULE INPUT1 INPUT,
CASE OKCODE.
WHEN ‘DISP’.
SELECT * FROM SFLIGHT
WHERE CARRID = SFLIGHT – CARRID AND
CONNID = SFLIGHT – CONNID.
ENDSELECT.
LEAVE TO SCREEN 200.
WHEN ‘EXIT’. LEAVE TO SCREEN 0.
ENDCASE.
ENDMODULE. “INPUT1 INPUT
MODULE USER_COMMAND_0200 INPUT.
CASE OKCODE.
WHEN ‘BACK’. LEAVE TO SCREEN 100.
ENDCASE.
ENDMODULE. “USER_COMMAND_0200 INPUT
When the user clicks on display, control is transferred to screen no. 200 on which you
display sflight details & on the same screen, when user clicks on BACK button, he comes
back to main screen.
Flow logic for screen 100 is as follows:

PROCESS AFTER INPUT.
MODULE INPUT.
Flow logic for screen 200
PROCESS AFTER INPUT.
USER_COMMAND_0200.
MODULES: Modules are handled in module pool program.
You need to write flow logic for screen 200 and design screen 200.
In case of transaction transfer of data from program to screen is automatic i.e. you need
not transfer the data from program to screen explicitly. The fields, which you define in
the screen receives the data from program and displays the same.
The Field Checks
As already mentioned Transaction is the only method, which SAP recommends to update
the database tables. Data entered in the database table should be valid and correct. Data
entered is validated at each and every point. ABAP/4 offers various methods to validate
data and those are as follows:
• Automatic field checks
• Checks performed in the flow logic
• Checks performed in the ABAP/4 module pool program
Automatic Field Checks
These checks are based on the field information stored in the dictionary. These checks are
performed by the system automatically when the user enters the data for the screen field.
System performs these checks before PAI event is triggered. Types of field checks
performed by system are as follows:
• Required input
While designing the screen, for particular screen field if you click the Req. Entry
checkbox, the field becomes mandatory. When the transaction is executed if user leaves
this particular field blank, the system displays error message. User cannot proceed until
the user enters some data.
• Proper Data Format

Each field has its own data format whether it is table field or screen field. Whenever data
is entered, system checks for the proper format of the data. For example date. Each user
has its own format for date, which is defined in the user master record. If the date defined
in the user master record is in the format DD/MM/YYYY, if the user enters the date, say,
in YY/DD/MM, the user displays the error message. System also checks for the value of
month or days. For example if month entered is greater than twelve then the error
message is displayed.
• Valid Value for the Field
In data dictionary two tables are related by Primary key-Foreign key relationship.
Whenever the user enters the data, the system checks for the check table values. Also in
Domain, if you have fixed values, then the system checks for these values.
Automatic field checks are repeated each time the user enters the data.
Flow Logic Validations
Consider the case where you want user to enter only ‘LH’ and ‘SQ’ for sflight-carrid. In
this case, you are restricting value of a screen field. This cannot be achieved by automatic
field check. Hence there is a need of additional validation. It can be done in flow logic by
using following statement:
Field --------------- Values
Syntax
PAI.
Field sflight-carrid values (‘LH’).
For multiple values
PAI.
Field sflight-carrid values (‘LH’ ‘SQ’).
Field sflight-price values (between 1000 and 2000).
In this case when the user enters the value, PAI is triggered and field is checked for that
particular value. If the value entered happens to be wrong, that field is enabled for user to
enter. If you have multiple Field statements in your flow logic, it is sequential execution.
Consider the following case:
PAI.

Module assign.
Field sflight-carrid values (‘LH’ ‘SQ’).
In ABAP/4
Module assign.
Data: carrid1 like sflight-carrid.
Carrid1 = sflight-carrid.
Endmodule.
In this case, Sflight-carrid is used in the flow logic before the field statement. The system
will give invalid value or some previous value as the field sflight-carrid is used in module
before it is checked i.e., field statement is after the module in which sflight-carrid is being
used. The field is not available to the system unless it executes the field statement.
Field statement transfers the values to the program and is done only once. If you don’t
have Field statement in your flow logic, transfer of values takes place in PAI event.
Consider one more case where you have multiple field statement.
PAI.
Field Sflight-carrid values (‘LH’).
Field Sflight-connid values (‘0400’ ‘0500’).
In this case if the user enters only carrid wrong, then this particular field is enabled and
rest of the fields are disabled for user to input. Many times if the user enters wrong value
for one field, then you might want to give option to user to enter all the fields, which is
not possible by using Field statement only. This functionality can be achieved by CHAIN
– ENDCHAIN.
Syntax
Chain.
Field sflight-carrid value (‘LH’).
Field sflight-connid values (between ‘200’ and ‘500’).
Endchain.
Field sflight-price values (‘100’ ‘1000’).

In this case, if the user enters wrong value only for carrid, both the fields i.e. carrid and
connid are enabled as they are grouped together in the Chain statement. The field price
will be disabled for input. Usually, logically related fields are grouped together with
Chain-Endchain statement.
Module Pool Program Validations
Checking fields ABAP/4 program includes
• Field statement in flow logic.
• Module statement in ABAP/4 module pool Program.
Syntax
PAI.
Field sflight-carrid module <name>.
This module can be handled in the main program i.e. module pool program.
In ABAP/4 program
Module Check.
Select single * from sflight where carrid = sflight-carrid.
If sy-subrc ne 0.
Message e001.
Endif.
In this case, field sflight-carrid is checked in the table for its existence.
Dynamically Calling the Screens
About Displaying Next Screen
Transaction is a sequence of screens, which are displayed one after the other. The next
screen displayed depends upon the attributes of first screen. In attributes you need to give
Next Screen number i.e. if next screen displayed should be 200 screen, then this number
should be given in next Screen attributes. These are static attributes of the screen. By
default, if nothing is specified in the program, the system branches out to the screen
number, which is specified in the attribute screen.

But this doesn’t happen always. If you have many pushbuttons on the screen like the one
in the following case:
In this case, if user selects MARA pushbutton, then fields from Mara table are displayed.
When the user clicks on the MARD, then the fields from MARD table are displayed.
Depending upon users selection, the screen is branched out and this has to be done during
runtime. This functionality can be achieved by dynamically calling the screen in module
pool program.
The screen can branch out to new screen depending upon user selection. Following
command in module pool program can do this:
• SET SCREEM
• CALL SCREEN
• LEAVE TO SCREEN <NUMBER>
All these commands override the specifications given in the attributes. This overriding is
temporary. The values stored in the attribute are not changed.
Set Screen
Syntax

Set screen <number>.
In module pool program
Case okcode.
When ‘DISP’.
Set screen 200.
When ‘LIST’.
Set screen 300.
Endcase.
In this case, the entire processing of current screen takes place and then the system
branches out to next screen. If you want to branch out to the next screen without
processing the current screen, LEAVE SCREEN should be used along with the SET
SCREEN.
For Example:
Case okcode..
When ‘DISP’.
Set screen 200.
Leave Screen.
When ‘LIST’.
Set screen 300.
Leave Screen.
Endcase.
When SET SCREEN is used, control cannot be transferred to the main screen or previous screen, unless you write code for
the same.
Call Screen
Usually used for pop up screens. Many times, there is a need for user to enter additional
information or secondary information on another screen or pop up screen. Once the user
enters the data, he should be able to go back to main screen or to the screen where he
started. This is not possible by using SET SCREEN. CALL SCREEN achieves this
functionality.
Syntax
Call Screen 200.

Will simply call a screen number 200 from a main screen. Once the screen is displayed
the user can enter all the data and return to the main screen by clicking BACK button.
To call screen as pop up screen the syntax is
Call screen starting at <col.no.> <line no>
Ending at <col no> <line no>.
In this case window will be popped as window and user can close it by using BACK
button.
Leave to screen
To SET a new screen without processing current screen, you need to use the following
two statements together:
SET SCREEN 200.
LEAVE SCREEN.
Or a Single statement
LEAVE TO SCREEN 200.
Table Controls
A table can be created in transaction. These tables when designed on the screen are called
as SCREEN TABLES. These screen tables are of two types viz.
• Table controls
• Step loops
Though these are tables when code is written to handle them, the tables are treated as
loops.
Features of Table Controls
• Data is displayed in the form of table when many records match the criteria.
• Table control gives user the feeling of an actual table.
• You can scroll through the table vertically and horizontally.
• You can select rows and columns
• Resize the width of a column

• You can have separator lines in between rows and columns
• Automatic resizing of the table when the user resizes the window.
In general table control includes all the features of an actual table and user gets the
feeling that he is actually working with table. You can update information in table control
and it can be updated in the database table by writing code for it.
Steps associated for creating complete screen table are as follows:
• Declaration of table control in module pool program.
• Designing of table control on the screen.
• Passing data to table in flow logic.
Declaring of Table Control in the Module Pool Program
Syntax
Controls TCI type Tableview using screen <screen no.>
When you use table control in a screen you must declare the structure in module pool
program. Important fields of tableview are as follows:
• Lines – number of displayable rows in a table.
• Top_line – the row of table where the screen displays start.
• Current_line – The row currently being processed inside a loop.
When you process the table control in flow logic depending upon where you want to start
display of rows, you need to use these variables.
Designing Table Control on Screen
• To design table control on the screen, you need to click on Table in control bar
and place it on the screen. You can adjust the length and width of table control.
• Name the table control. (Here you need to use same name which you have used
for declaration of table control in module pool program)
• From dictionary object, select table fields and place them in the table control.

Passing data to Table Control
As already mentioned, table controls are tables but are treated like loops. Usually transfer
of data from program to screen is automatic. But in case of table control, transfer of data
is not automatic. You need to explicitly transfer the data to table control. ABAP/4
provides loop statement, which is associated with flow logic to transfer the data. Because
table control is treated like a loop, data from where it is transferred should be a loop. You
cannot transfer the data by only select statement; you need to put the data into internal
table. ABAP/4 provides the LOOP statement, which is associated with the flow logic and
allows you to loop through the table control and internal tables. In between LOOP-
ENDLOOP, you can use most of the flow logic keywords like field values. Module etc.
You need to code a LOOP statement in both PBO and PAI event of the screen. With
LOOP statement, you can transfer the data from program to table control and vice versa.
That is, if user updates the value in the table control, you can update database table with
its value. And this can be done in PAI event. So even if you are not updating database
table through the table control, you need to put the LOOP statement in the PAI event
also.
Syntax
PBO.
LOOP AT <internal table> with control <table control name> cursor <scroll variable>
PAI.
Loop at itab.
Proper usage of Table Control is as follows:
In flow logic.
PBO.
LOOP AT ITAB WITH CONTROL TC1 CURSOR TC1-TOP_LINE.
MODULE ASSIGN.
ENDLOOP.
PAI.
LOOP AT ITAB.
ENDLOOP.

Considering, we have following fields in table control and the screen looks like this:
CONTROL TC1 Type tableview using screen 200.
Module assign.
Sflight – carrid = itab – carrid.
Sflight - connid= itab - connid.
Sflight - fldate= itab – fldate.
Endmodule.
The transfer of the data from program to table control takes place in steps and these steps
are as follows:
• With LOOP AT statement the first row is picked up and placed in the header of
the internal table.
• Whatever statements you have in between LOOP-ENDLOOP are executed. In
this case, you have Module statement. In Module statement, value of internal
table is assigned to table control field.
• The row in internal table is transferred to the first line of the table control as stated
in the LOOP AT statement.
• The system encounters the ENDLOOP statement and Control is passed to the next
line of the internal table.

• In the same way, all the records of the internal table are passed to the table
control.
STEP LOOPS
Step Loops are type of screen table as already mentioned. Step loops are repeated blocks
of field in a screen. Each block contains one or more fields and these blocks are repeated.
Step loops aren’t like actual table. You can scroll vertically but not horizontally. Three
steps are associated with creation of step loops:
• Creation of step loops on screen, which includes declaring fields on the screen
and then defining the step, loops for these fields.
• Passing data to the step loop is exactly similar to the passing of data to table
controls.
• In step loop, you don’t need to define the step loop as such in the module pool
program but the cursor needs to be defined in the program.
Types of Step Loops
• Static – Static Step Loop (SSL) have fixed size that cannot be changed during the
runtime. If user resizes the window, the size of the static step loop is not changed.
• Dynamic – Dynamic Step Loop (DSL) is variable in size. When the user resizes
the window, the system increases or decreases the number of the step loop blocks.
You can have only one dynamic step loop and can have as many static loops in your
transaction.
Programming with the Static and dynamic step loop is exactly same. For the system or
for the user it doesn’t make any difference whether it is static or dynamic step loop. Only
attribute, which you fix during designing of the step loop, is type attribute for step loop F
for fixed i.e static and V for variable i.e. dynamic.
Writing code for Step Loop in the flow logic.
PBO.
Loop at itab cursor cl.
Module set.
Endloop.
PAI.
Loop at itab.

Endloop.
* Empty loop is must for both table control and step loop
LOOP AT statement for step loops and Table controls is similar. Loop At statement
transfers the data to screen table. You need to have the Module to assign the values for
the screen table.
In module pool program you need to define the cursor.
Date: CL TYPE i.
* Cursor parameter tells which line of step loop display should start.
“Module Set” in module pool program assigns the values to step loop fields, which is
similar to table controls.
Branching to List Processing
Switching To List Mode
You can display a list within a transaction.
You can produce a list from module pool program by using the command
Leave to List-Processing.
This statement switches the system from dialog mode to list mode. And from this point
onwards until you return to dialog mode, you can use all the normal report statement like
write, select or any other event.
Returning back from LIST mode
You can return back to dialog mode by clicking the BACK button.
You can have your GUI status and write code for the same. You can include the
command LEAVE LIST-PROCESSING. When the system reaches this command, it
leaves the list mode and returns to the dialog mode.
Help & Value Request
In any transaction, When the user presses F1 or ? on a field, System provides the help
facility for that particular field. In dialog program, when F1 is pressed, help provided by R3
system is sourced from data element documentation. If this documentation is not present
for that particular field or if user needs to display additional information for that particular
field, then user defined help can be provided through PROCESS ON HELP REQUEST.

In ABVP/4 help can be provided to the user by:
Data element documentation: The F1 help can be enhanced, by adding an additional text
for the data element in ABAP/4 dictionary.
It can be done with the help of following steps:
Place cursor on the screen field,
GOTO  DOCUMENTATION  DATA ELEMENT DOCUMENT
You can now extend the existing help.
USING THE PROCESS ON HELP-REQUEST.
If you don’t have this event in a program, then the documentation of the field in the
ABAP/4 dictionary is taken into consideration. If this event exits in the program then it is
executed.
Process on HELP-REQUEST event
This event is triggered when user presses F1 on a screen field. You need to handle this
event in flow-logic by specifying the fields and attaching the module to it.
Syntax
PROCESS ON HELP –REQUEST.
FIELD SFLIGHT-CARRID MODULE HELP-FOR-CARRID.
MODULE HELP.
Write : `This is field is from sflight table’
Write : / ‘It is of four Character’.
ENDMODULE.
When the user presses F1 on this particular field, then this message will be displayed on
the screen.
Value Request
Whenever the user presses F4 on the screen field list of possible values, particular fields
are displayed. If the standard value-help is inadequate or if you want to display additional
fields or with different combination of fields, developer can program this in PROCESS
ON VALUE-REQUEST event in the flow-logic and subsequent module in the module
pool program. When the user presses F4, list of possible values are displayed either from
matchcode objects or check table or help view or domain. Each one of them is explained
briefly.

Check Table: If a check table is assigned to the table field and if the user presses F4 for
that particular field, then all the key fields are displayed.
Domain Values: The values defined in the domain are displayed. These values are set in
domain when the domain is created in the dictionary.
Help views: In cases where the check table is not sufficient, you can create a help view
with this check table, which gives additional information like explanatory text for the
fields of the check table.
PROCESS ON VALUE_REQUEST.
Each time the user presses F4 on the screen field, following algorithm is called internally.
Does this field have its own F4
module in the Screen Painter?
noyes
Execute the
module
Matchcode object in
the Screen
noyes
Execute matchcode
help
Check table?
no
yes
Help view for the
check table?
Domain
values?
no
Message ``No
display of possible
entries here”
yes
Display domain
values
yes
no
Display
check
Display
help view

When the user presses F4 on flight number, the following screen is displayed.
The screen displayed is pop-up screen and code for the flow
logic and module is written below:
Flow-logic code
PROCESS ON VALUE-REQUEST.
FIELD SFLIGHT-CONNID MODULE HELP-FOR-CONNID.
Code for module pool program.
MODULE HELP-FOR-CONNIDINPUT.
CONNID(50),
END OF ITAB.
REFRESH ITAB.
ITAB-CONNIDI= POSSIBLE VALUES FOR CONNECTION ID’.
APPEND ITAB.

SELECT CONNID FROM SFLIGHT INTO TABLE ITAB.
CALL FUNCTION ‘POPUP_WITH_TABLE_DISPLAY’
EXPORTING
ENDPOS_COL = 45
ENDPOS_ROW = 25
STARTPOS_COL = 10
STARTPOS_ROW = 1
TITLETEXT = ‘TEXT’
IMPORTING
CHOISE = Some Integer Variable
TABLES
VALUETAB = ITAB
EXCEPTIONS
BREAK_OFF =1
OTHERS =2.
ENDMODULE. “HELP-FOR-CONNID INPUT
Changing The Screen During Runtime
The attributes are assigned to the screen field when the screen is designed in full screen
editor. Such kind of assignment is static, which means that these attributes are fixed. But
many times the need to change the attributes of the screen arises. And this has to be done
during runtime.
Need To Change Screen
There can be a requirement in the transaction that, certain fields on the screen
Appear only in certain conditions.
Are in Change/display mode according to user inputs
Become mandatory subject to specific inputs.
Changes its format depending upon certain conditions.
Modifying the screen
At the runtime, attributes for each screen field is stored in system defined internal table,
with header line, called as SCREEN TABLE. It contains name of field and its attributes.
This tab le can be modified during the runtime i.e. through module pool program. Screen
table has following fields:

Field Name Length Description
NAME 30 Name of screen field
GROUP1 3 Field belongs to field group1
GROUP2 3 Group 2
GROUP3 3 Group 3
GROUP4 3 Group 4
ACTIVE 1 Hide/Show
REQUIRED 1 Field input is mandatory
INPUT 1 Enable/Disable
OUTPUT 1 Field for display only
INTENSIFIED 1 Field is highlighted.
INVISIBLE 1 Field is suppressed.
LENGTH 1 Field output length is reduced
DISPLAY 3D 1 Field is displayed with 3-D Frame
VALUE_HELP 1 Field is displayed with Value help
E.g., SCREEN-ACTIVE = 0 has the same effect as the following statements.
SCREEN- INPUT = 0.
SCREEN-OUTPUT = 0.
SCREEN-INVISIBLE = 1.
The fields SCREEN-NAME and SCREEN-GROUP 1 through SCREEN-GROUP4 tell
you which field and / or field group has the attributes.
You can assign up to 4 groups to a field.
You need to program screen modifications in module, which is processed during the
event PROCESS BEFORE OUTPUT.
`SCREEN’ is an internal table and, in order to change the field values, LOOP statement
has to be used so that the header-line can be populated with the new values, changing the
earlier values, the SCREEN table consisted for the specific screen. Finally the changed
record in the header-line is NOT APPENDED, but is MODIFIED to the SCREEN table.
That is, we first use `LOOP AT SCREEN’ and then assign the values. And finally
PRIOR TO ENDLOPP give `MODIFY SCREEN’.
PROCESS BEFORE OUTPUT.
MODULE MODIFY_SCREEN OUTPUT.

MODULE MODIFY_SCREEN.
LOOP AT SCREEN.
IF SCREEN-NAME = ‘SFLIGHT-CARRID’.
SCREEN-INPUT = 1.
MODIFY SCREEN.
ENDIF.
ENDLOOP.
ENDMODULE.

Creating Lock Objects
Lock object is an aggregated dictionary object and can be defined by using the following
steps:
o From initial data dictionary screen, enter the name for the object, Click Lock
object radiobutton and then click on Create. The system displays a dialog box for
Maintain Lock Objects screen
o Enter short text as usual and the name for primary table.
o Save
o Select Tables option
From this screen you can:
Select secondary tables, if any, linked by foreign key relationship.
Fields for the lock objects. This option allows you to select fields for objects (R/3 system
allows locking up to record level). Lock object argument are not selected by user but are
imposed by the system and includes all the primary keys for the table.
Types of locks
You can lock the table or record by using following types of locking:
Exclusive (E) the locked data can only be displayed or modified by single user i.e the
owner of the object. Access to other users is denied.
Shared (S) several users can access the same record simultaneously, but only in display
mode and except the first one, who has asked for the data in update mode.
Exclusive not cumulating (X) it is similar to exclusive lock. It allows only a single user
access. E can be called several times from the same transaction. In contrast, a lock type X
can be called only once during the transaction. Any other call for this lock is rejected.
Activation of Lock Object
When you activate the lock object, the functions are automatically generated. And these
are ENQUEUE-EZN and DEQUEUE-EZN. EZN is name of the lock object.
While ENQUEUE is used in program to set the code over the selected data depending
upon the lock object arguments. DEQUEUE is used to release the lock.

SAP Scripts/Layout Sets/Forms
Sap Scripts
If the user wants to print documents such as invoices, purchase order, all such documents
are printed with the use of forms. SAP allows the user to define these forms by using
layout sets. SAP script is the tool used to create the layout set.
In order to print the document, the SAP system runs a program that collects the data for
the document and feeds it into the layout set. This is called as Print Program.
SAP Provides a standard layout set for every printable document and usually there is no
need to create layout sets as such. User just modifies the existing layout sets as per
requirement of client. Following are some standard layout sets provided by SAP:
• RVORDER 01 Sales order confirmation
• RVDELNOTE Picking List
• RVPICKSIN Picking List
• RVINVOICE 01 Invoice
• MEDRUCK Purchase Order
• F110_PRENUM_CHCK Pre-numbered check
Layout Set
Layout set is used to design the document. Layout set on its own does not contain any data.
The selection of data for the document is done through the print program i.e. the print
program selects the data from database table and feeds it to the layout set. The document is
printed after the print program gets executed.
A layouts set consist of following components:
• Header
• Paragraph
• Character String
• Windows
• Pages
• Page Window

Header: The header consists administrative information for the layout sets and default
settings for the various other components of the layout sets like page, paragraph. You
give all the administrative information for the header when you create the layout set,
while all default settings are specified when all the components are created.
Paragraphs: A Paragraph contains all the information needed to format a paragraph of
text and font. Tabs are important for paragraphs. Specifying the list of tabs is the way to
create columns for outputting line items of a document.
Character string: is used to override paragraph settings for specific words in a
paragraph. For example you might want to use Bold for a single word but not the entire
paragraph. The only important thing that is defined with the character string is the font.
Windows: A window mainly contains the SAP scripts text and the variable to be printed.
There is one special window, MAIN, which contains the output of the line item of a
document and is created by the system. The window can be of type VAR or CONST
except for the MAIN. But in the present version, SAP system does not distinguish
between these two types. The content of variable window is regenerated on every page.
The content of a constant window is generated once at the beginning and later printed on
every page.
Printing a company logo
There are two ways to print a company logo:
1. The logo can be included in the layout set.
2. It can be a macro on PCL – 5 printers.
Including a logo in the layout sets
• Create logo with a graphics program and save it as tiff file.
• From editor run the program RSTXLDMC.
Parameters to be passed are
• File name
• File type
• BMON – For a black and white image.
• BCOL – For a color image.
• Text name – The standard text in layout set

This text can be included in a layout set by including <text name>. Using PCL – 5
printers, can also print the logo. In R3, the printer types are IIPLJIIID, IIPLJ4, LX4039
and SM120XXS.
Control Commands
About control commands:
All script control commands are entered in the SAP Script editor.
• All commands are indicated by /: in the tag column
• Only one control command is allowed per line
• Lines with control commands are not affected by the editor formatting
• If control command is unknown or incorrect, command line is treated as comment
line
ADDRESS: This command formats and address according to the postal standards of
the country.
Syntax:
/: Address
/: Title ‘Company’
/: Name ‘Intelligroup’
/: Street ‘115’
/: P.O. BOX ` `
/: Postcode
/: City
/: Region
/: Country
/: End Address
BOTTOM-ENDBOTTOM: For the Main window you can determine lines,
which are always output automatically at the bottom of that window. This is called footer
text.
Syntax:
/: BOTTOM
/: ENDBOTTOM
BOX, POSITION, & SIZE: These commands are used for drawing boxes and
are used only during creating output.
Syntax:
/: BOX [Xpos] [Ypos] [Width] [Height] [Frame] [Intensive]
X & Y – Upper left corner of the box.
Width – Width of the box

Ht – Height of the box
Frame – Thickness of the box (Default is full black)
Units used for Width, Height and Thickness are TW, PT, IN, CM, CH, LN.
Ex., /: BOX WIDTH ‘20’ CM HEIGHT 1 IN
FRAME 10 TW INTENSIFY 15.
POSITION
Syntax:
/: POSITION [X Origin] [Y Origin] [Window] [Page]
X & Y - Sets the origin for x 7 y parameters for the box command.
Window - Sets the default values for the left and upper edges.
Pages - Sets the values for the left and upper edges of the current page.
Basically used to set default setting for the box command.
/: Position x Origin ‘1.5’ cm y origin ‘1’ cm
SIZE
Syntax:
/: SIZE [WIDTH] [HEIGHT] [WINDOW] [PAGE]
Sets width and height parameters for the box command.
CASE: It is similar to ABAP/4 editor command ‘CASE’ only symbol can be queried.
Syntax:
/: CASE SYMBOL
/: WHEN 1
/: WHEN 2
/: WHEN OTHERS
/: ENDCASE
DEFINE: Values can be assigned to text symbol by DEFINE keyword. The assigned value may have a maximum 60
characters. It can also contain further symbols.
Syntax:
/: DEFINE & SYMBOL & = ‘XXXX’
IF: With IF command you can define the lines that are output only under certain
conditions.
Syntax:
/: IF &var& = ‘char val’
/: ENDIF

INCLUDE: Contents of another text can be included in text by INCLUDE command.
The contents are copied only at the time of the output formatting. You can also specify
language and the paragraph irrespective of the language in which the calling text is
created. The language which is used in include test is used for output.
Syntax:
/: INCLUDE MYTEXT
MISCELLANEUOS TOPICS
RUNTIME ANALYSIS
The runtime analysis is an additional development workbench tool that is quite useful for
analyzing performance of an ABAP / 4 Program or transaction. With this tool, the system
can display information about:
• Executed instruction
• Accessed execution time.
• Tables and Types of access.
• Chronological execution flow
The runtime analysis tool creates lists that reveal expensive statements, summarize table
accesses. Runtime analysis is specifically designed for tuning individual programs and
transactions.
The Runtime Analysis tool measures ABAP/4 statements that are potentially expensive in
terms of CPU time. The most significant of these are:
Statement used for database access like select.
Statement used for modularization such as module, perform, call function.
Internal table statements like append, collect.
Starting Runtime Analysis
• From ABAP/4 development workbench select Test – Runtime Analysis.
• From ABAP/4 editor, select utilities – more utilities – Runtime Analysis.
• From ABAP/ source code screen, select Execute – Runtime Analysis.
• From R3 screen, select System – Utilities – Runtime Analysis.
• Entering Transaction code SE30 in the command field.
Following screen is the initial screen for SE30 transaction.

On the initial screen, select the needed object you want to analyze i.e. program or
transaction. Enter the name of the object. Click on execute. The system will execute the
specified object and will generate a trace file or performance data file, which can then be
analyzed when the transaction or program is finished.
Analyzing a performance data file
These files are created at operating system level and many times occupy large memory space,
so be sure to remove the files, which are no longer needed.
To analyze the files:
• Click on Analysis
• Following screen is displayed
• From GOTO option you can get overview of runtime analysis.
The options are as follows:
• Hit List – Displays a list with the most system expensive instructions.
• Tables – Displays the most important tables, the number of accesses and the time
needed for the accesses.
• Group hit list – Displays a list with the performed instructions classified by
instruction type.
• Call hierarchy – Presents a chronological listing with the flow of calls during the
execution of a program.
During Runtime Analysis, the system measures the statements and stores these
measurements in a performance data file. If you measure the same program or transaction
several times, the data can vary. Many factors make it difficult to reproduce identical result.
E.g., Network traffic.

When you evaluate this file, the system displays the overview - Runtime Analysis Evaluation
screen including a bar chart for total execution time. From this screen, you can analyze
several types of information like:
• Hit list: displays the list with the most `system-expensive’ instructions.
• Tables: displays the most important tables, the number of accesses and the time
needed for the accesses.
• Group hit list: displays a list of performed instruction classified by its type.
• Call hierarchy: presents a chronological listing with the flow of calls during the
execution of program.
SQL TRACE
The SQL trace is a tool, which allows displaying and analyzing the contents for the database
calls, which are made by the reports and transactions written in ABAP/4. It monitors
programs and transactions on the database level. With the help of this facility for every open
SQL instructions, you can display, about which SQL Embedded (DECLARE, OPEN,
FETCH) Statement have been executed, besides analyzing the system performance.
Steps to Creation
• From R3 screen, select system –-> Utilities –-> SQL trace. Or Enter transaction
ST05.
• Click the trace on button.
• Enter the user name whose programs are going to be traced.
• Execute the program or transaction you want to trace.
• Return to SQL trace initial screen and press the button SQL trace off. This switching
off is necessary because if it is not done then SQL trace will trace each and every
program executed by a particular user. And it is quite expensive in terms of memory
and time of the system.
Analyzing The Trace File
To analyze the created trace, press the button list trace. Using this file you can see exactly
how the system handles database requests. The first screen of the SQL trace data file
displays each measured database requests, the application made. The trace file records when
the request occurred and its duration.

To display dictionary definition information about the table field, position the cursor on the
table field and click on the DDIC info button. When this button is clicked, it displays system
information like object name, table class, whether buffering is allowed or not i.e. information
related to dictionary.
Explain SQL: This button provides the functionality, which includes the utility for
providing detailed information about the SQL Operation Strategy followed by the
underlying database system. You need to click on Explain SQL button. The system displays
the execution plan for SQL statements. Here you can display the actual SQL statement like
Select, which fields are being accessed, Table being accessed, all where conditions.
ABAP/4 Display Gives you the actual ABAP/4 code.
More information gives the detailed information for time, select statement, client, number of
records selected etc. Replace variable will display the SQL statement with another variables.
Workbench Organizer & Transport System
SAP recommends three types of systems for implementation purpose
• Development System
• Test System
• Production System
Though number of systems used by an organization depends upon many factors such as size
of implementation, budget etc. However even in the smallest installation, a second system is
a must.
Development system
Development system is the system where the actual development takes place. Normally the
development is carried out for objects and these objects are original for these systems.
Test system
Also known as quality assurance system and are used to test the objects. You can test objects
on development system also, but on Test System the object is tested against real data. When
the tests are validated the development objects are transported to the production system.
Production System

The production system is where the end user enters real business data and where the actual
business runs. No development takes place in this system. You need to transfer the object
from test system to production system.
The overall flow of objects can be understood in the following diagram:
Developer creates the objects in the development system, these objects are transported to
the Test system to test them against the real data and when validated, these objects are
transported to the Production System.
To transport these objects from one system to another, ABAP/4 development work bench
provides the tool called Work bench organizer which is also used to manage activities that
are important in the overall development environment.
Example, for these activities are.
• The management and control of new development requests.
• Modification of objects
• Version management
In a distributed environment, workbench Organizer transports the development object
between different SAP systems. In the following example, the objects are transported from
the development system to production system.
E.g., between development and Production System
Develop System: New Development No development
DEVELOPMEN
SYSTEM
TEST
SYSTEM
PRODUCTION
SYSTEM
Type Users:
Developers,
Consultant
Production System
End Users

Workbench Organizer
The most puzzling topic of R3 system is intended to help functions for system development.
Concepts of workbench
• Development objects: Workbench records and controls change to existing
development objects as well as new objects. A development object is an object
created in R/3 system. (Program, Screens, Function modules.)
• Dictionary objects: Tables, Domains, Match code objects, Data Elements.
The workbench is fully integrated into the ABAP/4 development workbench.
• Development Classes: A Development class classifies the objects belonging to the
same development project. When a user creates a object in R/3 system, the object
needs to be stored in a particular development class. The development class are
objects themselves. In R/3 system you can store objects.
• In local object i.e. object is stored in $tmp class and cannot be transported from one
system to another.
• User can assign his own development class and can be transported.
Transport System
• Developers are in charge of creating or correcting data objects and will create change
request, which can be for individual object or common request for a project. When
the change request is released the system performs transport
• R/3 administrator is the person who sets up the transport system. This group works
both at the R/3 application level and at the operating system level, using transport
control (tp) program.
Change Request
A Change request is a list in the system, which mainly contains the object to be transported.
It also contains the transport type, the request category and the target system.
When the change request is created either manually or automatically, the system assigns a
number to it automatically. This number is known as change request number.
The format of this number is normally
<SID>K<Number>
E.g., DD1K<900002>
Where DD1 is System Identification Number (SID)

K is keyword
The number is automatically generated by system and starts with 900001.
The change request records all modifications made to development object.
When the changes are made and the change task (will be discussed) has been released,
the change request can be released.
SEO9 transaction
Or
Tools -> ABAP/4 W.B -> overview -> W.B. organizer
Will display and check all the change requests.
Tasks
A task in the workbench organizer is an activity in which user either creates an object or
modifies the same. In workbench organizer, task can be either development or repair task.
A task is related to single user while change request contains tasks belonging to different
users. You cannot transport task as such, but as a part of request. Each task is associated
with task number, which is similar to change request number.
Usually, when a development work starts, a system administrator or project manager
creates a change request to define tasks for all users involved in the project. Later, user
starts modifying objects or create new object. Once user finishes his task, they must
release them. A change request can be released for transporting, only when all tasks
under the same change request are released.
Objects included in task become locked against other development work on the same
object.
Version Management
ABAP/4 workbench and the organizer provide a version management for all the objects
in the system. With version management user can compare current version object and
object with the previous version.
To display the version for a object,
Locate your object through the change request number of workbench organizer. Click on
the object and from menu.
Or
Utilities  display version.

It displays what has been modified and who did it.
Version management is important for developers also as it allows user to compare
previous programs with the current one.
Transport
A transport means the process of moving something from one place to another. In R/3
system this ‘something’ means change request. To transport the objects you need to
create the change request. It can be done with the help of workbench organizer. Transport
System and workbench organizer are closely linked to each other.
An object original is a development object that has been created in the system in which
you are working.
DD1 PP1
Suppose you transport object Zsus001 to another system, Zsus001 is object original for
system DD1. If anyone tries to modify the program, he will be making repair to it,
provided he has access key for the same. R/3 system offers this security measure to
ensure that development object remain consistent for all system, thus preventing parallel
work on the same objects. Correction of objects and development of objects can be only
in original system.
The difference between Repair and Correction is as follows:
• If you modify an object in a system in which it is created, you are making
Correction to it.
• If you modify an object in a system in which it was not created, then you are
making Repair task.
Releasing Tasks and Request
When new development or correction is complete, developer must release their task and
request.
To release a task:
• Find a task from the Workbench initial screen.
• Position the cursor over the task.
• Click on the release button
Zsus001
(Development
System)
Zsus001
(Production
System)

A request is released by either system Administrator or Project Managers, once all the
tasks are released
Cross Applications
BAPI:-Business Applications Programming Interface
SAP created the Business Framework to allow the technical integration and
exchange of business data among SAP components and between SAP and non-SAP
components. Important components of the Business Framework are the Business
Application Programming Interfaces (BAPIs), which represent visible interfaces at the
component boundaries and whose properties serve to integrate these components.
The integration can include both components within a local network and components
that are connected with one another through the Internet. BAPIs allow integration at the
business level, not at the technical level. This provides greater stability in the link, and
independence from the underlying communication
Process Flow
The structure of the tools in the ABAP Workbench determines how the BAPI is
implemented.
1. Defining the data structures (including domains and data elements) in the ABAP
Dictionary.
2. Implementing the Function Module in the Function Builder
3. Defining the Business Object Types And it’s methods in the BOR
4. The Business object Repository (BOR) is object oriented repository in R/3 system.
It contains SAP business objects and their methods.

Conventions for BAPI Data Structures
1. Each parameter must refer to a data structure in the ABAP Dictionary. In the case
of structured parameters this is always to the whole BAPI data structure. If the
parameter consists of only one field, it must refer to a field in a BAPI structure.
2. You have to create separate data structures for BAPIs, which are independent of
the data structures generally, used in the R/3 application.
3. All data structure names must begin with <namespace>BAPI.
4. BAPI structure names should be as meaningful as possible.
Custom BAPI creation - Step-by-step Procedure
Scenario: Step-by-step creation of a BAPI to retrieve fields from table T001.
Procedure: Go to transaction SE11 and create a structure as shown or as per your
requirement.
Give the name in the Data type field and click on create.

In the pop-up that comes up, select the radio button “structure”.
In the components tab of the structure, give the different fields and their corresponding
field types and press enter to check the compatibility and creativeness.

Do not forget to save it in a package. You can even save it as a local object. For my
example, I save it in a package.
Check the structure (ctrl + F2) and activate (ctrl + F3) the structure.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Now we are done with the creation of a Structure.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Go to transaction SE37 where you create function modules. Click on create after you
enter the name of the Function module.

A screen as shown above would pop-up where you mention the function group to save
the function module and also provide some short text describing your function module.
In the next pop-up that follows, click on continue as shown above.

The function module screen would look like the one above.
Go to the Attributes tab and select the radio button reading “remote-enabled module”.
Come back to the imports tab and provide the import parameters as shown or as per your
requirement.

Now in the Export tab, provide the export parameters as shown or as per your
requirement.
In the tables tab, provide the information as shown or as per your requirement.
The next screen you visit is the source code. It would look like this.

In the source code tab, write the following code in order to pick the data based on the
input you provide.
Now, save and check the code and activate the function module.
After successful activation, go to the attributes tab. Go to Function
moduleàReleaseàRelease.

+++++++++++++++++++++++++++++++++++++++++++++++
Now we are done with the creation of a Function Module.
+++++++++++++++++++++++++++++++++++++++++++++++
Go to transaction SWO1 and enter the name of the BAPI you would like to create or as
shown in the screen and click the create button.
Give the name of the BAPI as above and click on create.

Give the above-mentioned details and click on the continue icon.
Save in a package.
The resulting screen is as follows.

Now click on the methods to drop down and see what methods are provided by default.
There would be two methods, showing in red color which comes by default while
creating the BAPI.
Click or select the method as shown above and go to the path “UtilitiesàAPI
methodsàAdd methods”.

On the screen that follows, provide the function module name and click on the continue
icon.
In the ultimate pop-up, click the next step icon. We observe that the information is
predefined in the fields.
This is the next screen where you would just click on the “next” icon.

Click on Yes. You can see an information message reading “ZBAPIFMT001” inserted.
Now save after you add the method. Select & Double click on the API method.
Go to Tab: ABAP Check 'API Function'.

The above screen is displayed. Go to the ABAP tab as shown below.

Select the Radio button reading “API Function” as already said above.

click on the continue icon to proceed further.
Now select the Object “ZBAPI_T001” as shown below.
Go to : EditàChange Release StatusàObject type àTo Modeled.

The above shown screen will be displayed. Click on yes.
The message shows, ‘The object type status set to modeled’. (Or already modeled)
Go to: EditàChange Release StatusàObject type à To Implemented.

You can see a message reading “Object type status set to implemented”
Now, go to: EditàChange Release StatusàObjectàTo Released.
There would be two pop ups coming up. Click on continue on the Pop Ups.
Keep the cursor on the 'Method'.
Go to: EditàChange Release StatusàObject type componentàTO Modeled.

You can see the message reading “status for method ‘zbapifmt001’ set to modeled”.
Now, go to: EditàChange Release StatusàObject type componentà TO Implemented
You can see the message reading “status for method ‘zbapifmt001’ set to implemented”.
Now go to: EditàChange Release Status à Object type component à To Released

You can see the message reading “status for method ‘zbapifmt001’ set to Released”.
Click on Generate Button. (The red ball kind of button is the Generate button)
After clicking on the generate button, you can see the message reading “Object type
'ZBAPI_T001' generated successfully”.
Now go to BAPI Tcode (BOR) there we can find the BAPI (our BAPI)
The BAPI browser would look like the screen below.
You can click on the Alphabetical tab so that you can browse the BAPI’s in an
alphabetical order. Find your BAPI as shown.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Now we are done with the creation of a BAPI.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Test Your BAPI.
Enter the name of your BAPI in the transaction SWO1 and click on ‘Test’.

The above screen is displayed. Click on the Execute icon against the BAPI as shown.
The above screen is displayed where you would require entering the data against the
empty input fields.

We have entered some data in the Field.
After entering the data, click on the execute icon as shown below.
The following screen is displayed which has some values as is indicated by the
ITEMTAB.

Click on the Edit table icon as shown below.
The results as per our input are as shown below.

By this, we would get it confirmed that our BAPI is working properly.
We can even check it by passing different values again. Come back to the input and
execution screen.
After executing the BAPI based on the input provided, we get the following screen.

Hit on the execute icon.
In the above shown screen, hit on the edit table icon.

The above is the output we get from the input we provided.
We are now done with the creation and successful execution of a BAPI.
ALE (Application Link and Enabling) & IDOC(Intermediate Documents)
What is ALE?
ALE (Application Link and Enabling) is SAP proprietary technology that enables data
communications between two or more SAP R/3 systems and/or R/3 and external systems.
ALE is the set of tools, programs, and data definitions that Provides the mechanism for
distributing SAP functionality and data across multiple systems. ALE enables the
construction and operation of distributed applications.
ALE Overview

From a System Infrastructure view, an SAP system consists of three layers:
• The Database Layer stores and retrieves all data. The database contains all of
the data related to the SAP system, including the ABAP programs, the
Configuration data, the master data, and the transaction data.
• Application layer: This layer provides ALE with an interface to R/3 to originate
or receive messages containing data to or from external (or other R/3) systems
and executes the SAP programs and processes requests from users.
• The Presentation Layer contains the SAP Graphical User Interface (GUI), and
handles all user input and output.
Together, the three layers make up the three-tiered client-server architecture of SAP.
We can distribute the three layers over any number of physical computers. However,
there may only be one database server.
From a Database or Configuration view, the SAP system consists of:
• Client-Independent data, such as ABAP programs, client-independent tables, etc.
• One or more Clients. Each client contains its own client-dependent configuration
(Company hierarchy, process configurations, etc.), master data (customer,
Material, vendor, etc.), and transaction data.

The Basic Ideas of ALE
ALE is a technology introduced by SAP with its 3.0 release. Its purpose was to overcome
the limitations of a single SAP system. A single SAP system that runs on top of one
database often does not fulfill the needs of larger corporations, either from a business or a
technical perspective.
ALE allows the implementation of loosely coupled SAP systems; each of the SAP
systems has its own database and is essentially independent from the other systems. ALE
allows us to distribute data between different systems and different business processes.
The distribution of data happens at the application server level (Hence, Application Link
Enabling).
SAP supports a number of distribution scenarios, which define how different SAP
systems can interact. The scenarios define what messages are sent back and forth between
the systems (for example, Contract information needs to be exchanged between systems
that run central purchasing and systems that run decentral purchasing).
The “data container” that carries the message is the Intermediate Document, or IDoc.
SAP delivers over 100 IDoc types to support its distribution scenarios; along with the
IDocs come the associated programs to generate (on the outbound side) or to process (on
the inbound side) IDocs.

Part of ALE is a communication infrastructure; specifically ALE uses the “transactional
RFC” technology to ensure the transaction consistency across system boundaries. ALE
also ties into SAP workflow to handle errors in the data transfer process.
ALE scenarios fall into three categories: master data, transactional data, and control data
distribution. Although the underlying principles are the same for the different categories,
there are differences in their functions and configurations. SAP delivers over 200 ALE
scenarios; and by extension there are approximately 200 application areas that can
leverage ALE technology for data distribution or communication. A subset of these
scenarios is supported by R/3 for Electronic Data Interchange (EDI).
There are several advantages to using ALE technology:
ALE Building Blocks and Concepts
The following building blocks are fundamental to ALE functionality:
Logical System: A Logical System (LS) is the representation of an R/3 or external
system in SAP R/3 for the distribution of data to and from the R/3 System. Every R/3
client used for ALE or EDI has to have a base LS associated with the client. This LS
becomes the “sender” for outbound messages and a “receiver” for inbound messages. In
addition to the base LS, a second LS should be created within that R/3 system for each
R/3 or external system used for ALE interfaces. In an inbound ALE interface, this second
LS represents the sender (another R/3 or external system) with respect to the base LS
(receiver). In an outbound ALE interface, this second LS is the receiver on behalf of the
R/3 or external system with respect to the base LS (sender).
Message type: A message type represents the application message exchanged between
R/3 systems and R/3 and an external system. A message type characterizes the data sent
across systems and relates to the structure of the data called an IDOC type (see below).
For example, MATMAS is a message type for Material Master, and INVOIC is a
message type for an Invoice (Billing Document). ALE supports over 200 message types
in R/3 and about 200 application areas.
IDOC type and IDOC: An Intermediate Document (IDOC) type represents the structure
of the data associated with a message type (DEBMAS02 for message type DEBMAS —
Customer Master, and WMMBID02 for message type WMMBXY— Goods
Movements), while an IDOC is an object containing the data of a particular message
type. IDOCs are data containers with intelligence built in. Each IDOC contains one and
only one business object. For example, an IDOC of type SHPMNT01, message type
SHPMNT, will contain data only of one Shipment Document. Generally, the architecture
of an IDOC is independent of the message type by virtue of ALE’s ability to redefine it
for any message type.

Customer Distribution Model: In an R/3 system, the Customer Distribution Model is a
tool that stores information about the flow of messages across various systems. The
Customer Distribution Model uses an SAP-delivered Distribution Reference Model as its
basis (the Customer Distribution Model can have distribution scenarios other than ones
stored in the Distribution Reference Model.) The Customer Distribution Model stores
data that dictates which messages (message types) flow to which Logical Systems. Many
messages can flow to one Logical System, and one message can flow to several systems.
With the use of filter objects and listings (which I’ll describe shortly), it is also possible
to specify in a model the criteria for filtering information for a specific system. A
Customer Distribution Model can be created in an R/3 system with that client’s base
Logical System as the “sender” Logical System.
ALE provides powerful capabilities to capture changes occurring to master data and to
distribute them via the IDOC interface. This feature can be used to keep two or more
systems synchronized with respect to master data.
Ports: A port is a logical representation of a communication channel in SAP, with the
data communicated being IDOCs. There are four types of ports that can be defined in
R/3: tRFC, File, R/2, and Internet. ALE can use all port types to distribute IDOCs, while
EDI typically uses a file-based port. tRFC and File ports can link to RFC destinations
connected to R/3-to-R/3 or TCP/IP. By linking ports to RFC destinations, the port can
also trigger scripts to invoke EDI subsystems, IDOC mapping software, and FTP.
You can maintain ports by executing transaction WE21 or WEDI, or selecting IDOC ->
Port Definition. RFC destinations can be maintained using transaction SM59.
Partner profile: A partner profile is an identifier for a system used for communicating
messages. There are four types of partner profiles: KU for Customer, LI for Vendor, B
for Bank, and LS for Logical System. KU, LI, and B are used for EDI partners, while LS
is used for ALE communications. Every partner profile used for ALE must be based on
an existing LS.
A partner profile brings together several ALE and EDI elements to define the parameters
of communication between two or more systems. Other than general information, you
have to maintain inbound parameters, outbound parameters, and message control. The
main parameters are message types, IDOC types, process codes, partner functions,
application identifiers, message functions, output types, and ports. Other parameters also
determine the mode of processing and error handling.
A partner profile plays a major role and can be viewed as a gateway for ALE and EDI
communications. It routes the specified messages through defined IDOC types to a given
port after invoking the appropriate function modules for outbound processing. It receives
IDOCs of a specific type, and it identifies modules to post data to the application
databases in the case of inbound interfaces.

RFC Destination:Used to define the characteristics of communication links to a remote
system on which a functions needs to be executed.
Process: The processes in the application layer and the ALE layer are completed on both
the inbound and outbound processing sides. The communication layer transfers the data
by transactional Remote Function Call (tRFC) or by EDI file interface.
The process can be divided into the following sub-processes:
1. Outbound Processing
2. Inbound Processing
Why use ALE?
ALE provides for the integration of distributed applications, but why would we distribute
applications in the first place? There are several technical and business reasons:
• System Performance: The transaction load is too heavy for a single
SAP system.
• High Availability Requirements: The company cannot afford downtime due to
backups, maintenance, upgrades, etc.
• SAP Release Coordination: Different units of the organization may require
different releases of the SAP software.
• Very Large Database: Companies with very large databases may need to
distribute the data across multiple SAP systems.
• Business Structure: Business units may require independence and autonomy for
day-to-day operations, and yet still need to share some data and functionality with
other units in the enterprise.
• Interfacing with non-SAP systems: The company may wish to maintain certain
applications on non-SAP systems, while at the same time integrate these
applications and their data with the SAP system.
• Keep development system data in sync with production data: An
organization may wish to keep the data on a development system the same as on
a production system.
• Maintain configuration and master data across clients: Organizations using
multiple clients may wish to maintain certain data on a client-independent basis.
What can we distribute with ALE?
We can distribute all types of data with ALE:
• Control or Customizing Data: Control data includes all configuration objects that

define how the SAP system is organized. This includes the enterprise structure
configurations, global settings, etc.
• Master Data: Master data objects that can ALE can distribute include:
 Material Master
 Customer Master
 Vendor Master
 Cost Centers
 Activity Types
 G/L Accounts
 Characteristics/Classes/Classifications
and many others
• Transaction Data: Transaction data is data related to specific business
transactions or processes (e.g. sales orders, credit memos, invoices).
SAP delivers several hundred predefined distribution scenarios. If a standard solution is
not provided, then we can develop a custom scenario to distribute any data required by
the business. The number of supported business scenarios increases with each SAP
release.
Example distribution scenario: Sales and Distribution
The sales system provides only the logistics data that the warehouse requires to fill an

order. Summary information is reported into the central sales information system. All of
the data sent references a single order document.
The Intermediate Document (IDoc)
The Intermediate Document, or IDoc, is the main component of all interface functionality
in SAP. Each interface message type has an associated IDoc type. The IDoc, in turn,
defines the structure and formatting of the data contained within the message type.
IDocs provide support for customized development:
 API for development
 Easy to use and apply
 Real-time or asynchronous interface connection
 Independent of external system data requirements
 Independent of type of external system
The data interface standard is standardized according to the following
key rules:
 The documentation of the interface is published.
 SAP takes responsibility for compatibility of the interface standard for its own
applications.
 Field lengths and types are defined according to the data element definitions of
the EDIFACT EDI standard and SAP’s data repository.
 Codes for coded fields are taken from international standards where the standard
applies.
IDoc Structure

An IDoc consists of three record types:
 Control Record: Contains the data that uniquely identifies the IDoc.
 Data Records: Contain the application data related to the message type. An IDoc
may have multiple data records, called segments. A data segment is made up of a
key section and a data section. The key section uniquely identifies its respective
data segment.
 Status Records: Contain the information relative to the various statuses that the
IDoc encounters, such as IDoc created, document posted, etc.The IDoc is data
stored in a structured format. It is a medium for data transfer. An IDoc is
not a process nor executable code.
SAP originally developed IDocs for EDI, and then adopted the IDoc concept and
structure for its ALE interface.
The IDoc Control Record
The Control Record stores the characteristics of the IDoc. Some of the more important
fields are:
• IDoc ID Number (DOCNUM)
• IDoc type (DOCTYP)
• Direction (In or Out) (DIRECT)
• Name of Sender (SNDPRN)
• Name of Receiver (RCVPRN)
• Processing Status (STATUS)
• EDI Message Type (if EDI) (STDMES)
Control Records are stored in the R/3 transparent table EDIDC, keyed by IDoc ID
number. This ID number is assigned by SAP for all IDocs.
The IDoc Data Records
The Data Records contain the actual application data. Some of the more important fields
are:
 IDoc ID Number (DOCNUM)
 Segment Name (SEGNAM)
 IDoc Data (SDATA) (structure differs with each IDoc type)
The Data Records are stored in table EDID4 (EDID2 in prior versions), keyed by IDoc
number and segment number. The table structure is 71 bytes of administration data (IDoc
number, segment identifier, etc.) Followed by 1000 bytes of free-form application data.
Each segment type uses a different format for the 1000 bytes of

application data.
Data Record Hierarchy
Information that relates to the object as a whole is stored in the main segment.
Hierarchical information is stored in separate segments. Each segment typically
corresponds to a different database table.
 Attributes of a segment:
 The fields of the segment. Each field is assigned a length and a data element from
the ABAP dictionary.
 Whether the segment is required or optional in a valid IDoc.
 The minimum and maximum number of instances of the segment.
Example – Material Master
As an example, consider the Material Master IDoc Type (MATMAS01). Each material
has information that is common throughout an SAP implementation. This data is stored in
the main segment. Each material has some information that is different for each plant,
which is stored in a separate plant segment. Within a plant, the material can be stored in
multiple storage locations, each of which requires a storage location segment for its
information. We can store several different descriptions of the material (for different
languages, for example).

Distribution Models
The distribution model describes the flow of data between logical systems:
 What systems are there?
 What applications will run on which systems?
 What systems will SEND data?
 What systems will RECEIVE the data?
 Other rules for data distribution?
ALE uses the model to control data distribution. The ALE system will not distribute any
data unless you specify the data flow in a distribution model.
Before building a distribution model, we must define the logical systems that we will be
using. The Logical System Definition transaction will access the list of logical system
names. Click on New entries to create new logical systems.
Steps to create ALE and IDOC’s:
 Create the Logical System using SALE Tcode.
 Assign Clients to logical System using SALE Tcode.
 Create RFC Destinations using SM59 Tcode.
 Create Ports using WE21 Tcode.
 Create Distribution Model using BD64 Tcode.

 Create Partner profile using BD64 Tcode.
 Outbound Process using WE05 Tcode.
 Inbound Process using WE05 Tcode.
Enhancements
SAP has developed its various modules with standards, which are broadly practiced all
over. But yet the requirements of customers differ from place to place. In this scenario it
becomes imperative to modify SAP objects to suit the customer’s needs.
Hence SAP allows you to change the system accordingly and add your own functionality
to the SAP system. There are four different ways of changing the SAP system to fit our
needs:
1. Customizing: Customizing constitutes changing the system parameters with its own
special user interface. These changes are organized and preplanned. It is an obligatory
part of a SAP implementation process.
2. Enhancement Concept: It constitutes changing of SAP Repository objects by the
customer without modification
3. Modification: Modifying the SAP repository objects in the form custom changes. This
should be avoided because when SAP changes occur in new versions then the customer
version and the new SAP version have to be reconciled manually. This means an
increased maintenance workload because of the need to adjust all such modifications.
Hence, use of this option should be avoided as far as possible.
4. Customer Development: If the customer requirements are not met by SAP then we
should go in for customer development. These means that we need to create customer
specific objects within the customer range. Modification and Customer Development
involve high maintenance and costs. Hence use these only when customer requirements
are not met by customizing or by exits. SAP creates customer exits for specific programs,
screens and menus within standard R/3 applications.
There are two methods in enhancements.
1. User Exits.
2. BADI (Business Add Ins)
User Exits
There are mainly two reasons to why we have to use exits if we ever have to.

1. You should them because they do not affect the SAP source code but still allow you to
change the functionality of SAP to suit your needs. SAP has provided us with some
standard exits that we should modify by adding our encapsulated as separate objects.
When you create Exits, they are encapsulated as separate objects.
2. And since, they do not affect the source code and are named as per the SAP naming
conventions; they do affect future software upgrades. Hence you do not have to save
them and then reenter add-ons attached to exits. You can only use exits if they already
exist within the SAP R/3 System In case you do not find an exit available for an area
where you would want to make a change, then you should request SAP to develop an
exit.
There are four types of exits:
1. Menu Exits
2. Screen Exits
3. Function module Exits
4. Field Exit
1. Menu Exits
Using the Menu Exits you can add menu items to the menus of standard R/3
Applications. The Menu Exit entries have function codes that begin with + (plus sign).
2. Function Exits
This includes creating function modules with the administrative part, the interface and the
documentation but usually without any additional code. Function module exits play a role
in both in menu and screen exits When you add a new menu item to a standard pull-down
menu, for example, you can use a function module exit.
3. Screen Exits
Screen Exits defines special areas called Subscreens within a screen. Using Screen Exits
you can add subscreens to the screens within R/3 applications.
4. FIELD EXITS
Let us now see how to create field exits.
 First and foremost, ask your system administrator to include the parameter
abap/fieldexit = Y in your Instance Profile
 For the Field Exits we do not need an Enhancement project.
 To create a Field Exit, you need to first determine which Data Element you
would want to change, The program that you would like to have the effect on, The
screen number.
In our example we will consider the transaction MM02, which is for changing the
material master. We will select the Basic Data view and then make fields exit for
restricting the Basic Unit Of Measurement. For example, we will not allow the user to

enter ‘BOX’ as basic unit of measurement. For this field, we need to have
details such the Data Element, Program name and Screen Number.
This information can be gathered by as follows:
i. Start the Transaction MM02.
ii. Select a material and click enter
iii. From the pop up that you get, select the Basic Data view
iv. Locate the label Base Unit of Measure in the General Data section.
v. Place your cursor in the field and press F1
vi. In the Help screen of this field, press on Technical Info button and note down the
above information
Detailed explanation about BADI with an example
Defination:
BADI (Business Add-In) is a new SAP Object Oriented enhancement technique which is
used to add our own business functionality to the existing SAP standard
functionality. BADI's are available in SAP R/3 from the system release 4.6c
Why BADI?
In contrast to the earlier enhancement techniques, BADI follows Object Oriented
approach to make them reusable. A BADI can be used any number of times where as
standard enhancement techniques can be used only once.
For example if we assign an enhancement to one custom project, then that enhancement
cannot be assigned to any other custom projects. To overcome this drawback SAP has
provided a new enhancement technique called BADI.
Transaction code for BADI Definition: SE18
When you create a BAdI definition, a class interface will be automatically created and
you can define your methods in the interface. The implementation of the methods can be
done in SE19 transaction.
When a BAdi is created following are automatically generated:An interface with
'IF_EX_' inserted between the first and second characters of the BAdi name. An adapter
class with 'CL_EX_' inserted between the first and second characters of the BAdi name.
Transaction code to Implement BADI: SE19
Types of BADI's:

While creating a BADI using the T-code SE18, it provides the pop-up screen to select the
type of BADI to be used is as shown below.
There are two types of BADI's.
1) Multi use BADI:
With this option, any number of active implementations can be assigned to the same
definition BADI. By default this option is checked.If we want the BADI for multiple use
If you have multiple-use BADI definitions, the sequence must not play any role.
The drawback in Multiple use BADI is, it is not possible to know which BADI is active
especially in country specific version.
2) Filter dependent BADI:
Using this option we can define the BADI's according to the filter values to control the
add-in implementation on specific criteria.
Ex: Specific country value.
How to Find BADI's in SAP system:
Method 1:
Steps to find BADI:
1. Go to SE 24 transaction, type CL_EXITHANDLER and then click on display.

2. Double click on GET_INSTANCE method.
3.
Put a break-point on class method
CL_EXITHANDLER=>GET_CLASS_NAME_BY_INTERFACE.

4. Run any transaction on which we want finds the BADI's say VA01.
5. Give the transaction name VA01 and press enter.
6. It will automatically take you to the break-point which we have set the in the SE24
transaction. Each time if you press F8 a list BADI names will be displayed

7. You can find the BADI name in field EXIT_NAME and if you double click on it, we
can get the corresponding BADI name before hit the corresponding screen. Based on the
requirement find the BADI name and accordingly implement your functionality using the
transaction se19.
Method 2:
Go to transaction SE84 and click on Enhancements. Then double click on Business Add-
Ins. For example if you want to find the BADI's for the standard transaction ME22n, the
procedure is as follows. This example shows, finding the way of BADI names by
providing the Package of ME22n.
1) Go to transaction ME22n. Select the System option from the menu and then click
on Status. It displays the following information.
2) Double click on the program name i.e. SAPLMEGUI. It will take you into the
program and click on Go to tab from the Menu. There we can find the package name of
the standard transaction ME22n.Copy and paste it in the package filed.

3) Now Press F8, a list of BADI names will be displayed as shown below. Select the
appropriate BADI name and implement it based on the business requirement using the
transaction SE19.
Method 3:
Finding the BADI names using SE18 transaction
1) Go to transaction SE 18. Select F4 help for the definition name and click on
Information System button as shown below.

2). A pop-up screen will be displayed and give the package name for any standard
transaction say VA02. Finding the package is explained above. Please refer above
method to find the package name. The package name for VA02 transaction is 'VA.'
3) A list of BADI names will be displayed for the transaction VA02. Select the
appropriate BADI name and implement it using T-code SE19.

Example :
This Example explains how to implement BADI's. Here I am trying to show how to add
custom screen to the ME23N Transactions using BADI's.
The procedure is as explained below.
- Find the BADI using the method 1 as shown above.
The BADI name to add the custom screen to ME23n is 'ME_GUI_PO_CUST'.
- Go to T-code SE19 and create an implementation ZME_GUI_PO_CUST and then
click on create button
- Give the Definition name "ME_GUI_PO_CUST" and continue, give short text, save
- Click on Interface Tab, you can find the implementation class name as
ZCL_IM_ME_GUI_PO_CUST2.
- Click on ZCL_IM_ME_GUI_PO_CUST2, which will take you to SE24.
- Add "MMMFD" in the Type Group Section of properties tab.
- Go to Attributes section and declare the following attribute
- SUBSCREEN1 Constant Public Type MEPO_NAME Name of a View
'ITEMSCREEN1 '.
- Go to Methods section, you can find the BADI interface methods.
- Double click on the method "IF_EX_ME_GUI_PO_CUST~SUBSCRIBE", this
method is having 3 parameters

Go to the code section of the method and add the following code there.
Code for IF_EX_ME_GUI_PO_CUST~SUBSCRIBE:
DATA: ls_subscriber LIKE LINE OF re_subscribers.
*--FIRST SCREEN POPULATION
*--we want to add a customer subscreen on the item detail tab
CHECK im_application = 'PO'.
CHECK im_element = 'ITEM'.
*--each line in re_subscribers generates a subscreen. We add one subscreen
*--in this example
CLEAR re_subscribers[].
*--the name is a unique identifier for the subscreen and defined in this
*--class definition
ls_subscriber-name = subscreen1.
*--the dynpro number to use
ls_subscriber-dynpro = '0002'.
*--the program where the dynpro can be found

ls_subscriber-program = 'ZME_GUI_PO_CUST_SCREEN'.
*--each subscreen needs itsown DDIC-Structure
ls_subscriber-struct_name = 'ZMARA'.
*--a label can be defined
ls_subscriber-label = 'Cust BADI'.
*--the position within the tabstrib can be defined
ls_subscriber-position = 7.
*--the height of the screen can be defined here. Currently we suport two
*--screen sizes:
*--value <= 7 a sevel line subscreen
*--value > 7 a 16 line subscreen
ls_subscriber-height = 7.
APPEND ls_subscriber TO re_subscribers.
Save and check & back
Double click on method IF_EX_ME_GUI_PO_CUST~MAP_DYNPRO_FIELDS".
Add the following code in the method.
*given the field catalog of structure ZMARA we have to
*establish a mapping to metafields which are used for field selection
*purposes and error handling Standard definitions can be found in type
*pool MMMFD. It is important for customer fields to use integer
*constants above 90000000 for the metafield.
FIELD-SYMBOLS: <mapping> LIKE LINE OF ch_mapping.
LOOP AT ch_mapping ASSIGNING <mapping>.
CASE <mapping>-fieldname.
WHEN 'MATNR'. <mapping>-metafield = mmmfd_cust_08.
WHEN 'MTART'. <mapping>-metafield = mmmfd_cust_09.
WHEN 'MATKL'. <mapping>-metafield = mmmfd_cust_10.
ENDCASE.
ENDLOOP.
The metafield mapping important for field selection & error handling purpose.
Save, check and back
Activate the Implementation class.
Activate the BADI Implementation.
Now create a structure in SE11 with the name ZMARA.

Add the following fields in the structure.
Now Create a Program with the Name 'ZME_GUI_PO_CUST_SCREEN' and create a
screen with sub screen type with the number 0002.
Add the fields on to screen from ZMARA program 'ZME_GUI_PO_CUST_SCREEN'.

De comments the PBO module in screen flow logic & create the module in above
program.
Add the following code in program ZME_GUI_PO_CUST_SCREEN.
TABLES: ZMARA.
DATA: call_subscreen TYPE sy-dynnr,
call_prog TYPE sy-repid,
call_view TYPE REF TO cl_screen_view_mm,
call_view_stack TYPE REF TO cl_screen_view_mm OCCURS 0.
*---------------------------------------------------------------------*
* FORM SET_SUBSCREEN_AND_PROG *
*---------------------------------------------------------------------*
* ........ *
*---------------------------------------------------------------------*
* --> DYNNR *
* --> PROG *
* --> VIEW *
* --> TO *
* --> CL_SCREEN_VIEW_MM *
*--------------------------------------------------------------------*
FORM set_subscreen_and_prog USING dynnr TYPE sy-dynnr

prog TYPE sy-repid
view TYPE REF TO cl_screen_view_mm.
call_subscreen = dynnr.
call_prog = prog.
call_view = view.
ENDFORM.
*&---------------------------------------------------------------------*
*& Module STATUS_0002 OUTPUT
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
MODULE STATUS_0002 OUTPUT.
SELECT SINGLE * FROM MARA
INTO CORRESPONDING FIELDS OF ZMARA
WHERE MATNR = '100-100'.
ENDMODULE. " STATUS_0002 OUTPUT
The sub-routine "set_subscreen_and_prog" is must with the same signature.
This routine is called from BADI to call the sub screen.
Activate the screen & program.
Now Go to T-Code ME23N to test the application.
You can find a new tab is added in the item level with the name CUST BADI.
Final Output:

SAP ABAP support by bob panic www.rockstarconsultinggroup.com

More Related Content

What's hot

Viewers also liked

Similar to SAP ABAP support by bob panic www.rockstarconsultinggroup.com

Recently uploaded

SAP ABAP support by bob panic www.rockstarconsultinggroup.com