SAP-System Applications and Products

SAP- System Applications And Products
BHARATI VIDYAPEETH UNIVERSITY, PUNE


TERM PAPER REPORT

ON
“My SAP ERP”

ERP Software from SAP
Submitted By:- Anshul

Kumar Saxena
64011
MCA-III Year
INSTITUTE OF MANAGEMENT AND ENTREPRENEURSHIP DEVELOPMENT,
BHARATI VIDYAPEETH UNIVERSITY

Acknowledgement
It gives me immense pleasure to put forward this practical venture. But
surely, it would not have been possible without proper guidance and
encouragement. So I would like to thank all those people without whose support
this paper would not have been a success.
I express my deep gratitude to all concerned persons, whose help and

guidance have contributed a lot in accomplishing this paper.
I am very thankful to honorable Director Dr. M.S.Prasad, the esteemed

director of our college for providing all facilities for making the project successful.
I owe a special thanks to Miss Deepa Hebalkar (IT Faculty, MCA

Department, IMED Bharati Vidyapeeth University, Pune) for her able guidance and
valuable suggestions for choosing and shaping this paper. His contribution has
helped a great deal in the timely completion of this term paper.
I would like to express my sincere thanks to all the faculty members of MCA
Department, IMED Bharati Vidyapeeth University, Pune for the interest and
commitment shown in the project, which made it possible for us to complete the
term paper successfully.
Date: Anshul Kumar Saxena

Bharati Vidyapeeth University

Institute of Management and Entrepreneurship
Development, Pune
(Accredited by NAAC with “A” grade)
Certificate
We certify that Mr. Anshul Kumar Saxena Roll No. 64011 respectively is a
bonafide student studying for MCA degree programme of the university in this
institute for the year 2006-2009.
As a part of the Course Curriculum he has completed a term paper titled “MY
SAP ERP” during the period from Dec 2008 to April 2009.
The term paper report is prepared by the student under the guidance of Miss
Deepa Hebalkar..
_______________ _______________ ________________

(Dr. M.S.Prasad) (Prof. A.D.More) (Miss Deepa Hebalkar)
DIRECTOR HEAD OF DEPTT. PROJECT GUIDE
IMED BVP PUNE IMED BVP PUNE IMED BVP PUNE

ABSTRACT
Implementing enterprise resource-planning systems can be extremely painful, and

once you have them up and running they may seem to interfere with the speed
and agility needed for electronic business. Are they a waste? No, but the real
advantages aren't always noticeable.
ERP software integrates all departments and functions across a company onto a
single computer system that can serve all those different departments' particular
needs. ERP combines finance, HR, manufacturing and distribution all together into
a single, integrated software program that runs off a single database so that the
various departments can more easily share information and communicate with
each other. This integrated approach can have a tremendous payback provided
the software is installed and used correctly.
Throughout the 1990s, the majority of large industrial companies installed

enterprise resource-planning (ERP) systems--that is, enormous computer
applications allowing a business to handle all of its operations (finance,
requirements planning, human resources, and order fulfillment) on the basis of a
single, integrated set of corporate data. Enterprise resource-planning systems
assures massive improvements in efficiency--for example, shorter interval
between orders and payments, lower back-office staff necessities, cheap
inventory, and enhanced customer service. Encouraged by ERP's potential,
businesses around the world invested some $ 300 billion in it during the decade.
SAP, one of the leading providers of ERP solutions, has thrown its hat into the ERP
application rental ring. SAP ERP applications are available on an outsourced,
hosted basis. For a fixed monthly rental fee, small to midsize companies can now
reap the benefits of a top ERP package without the capital investment and
infrastructure needed to implement such a setup in-house.
With the emergence of application rentals, however, any size company can have a
top-notch ERP system even though they don't have the IT resources or capital

traditionally needed. This is because the hardware and software is maintained at
the vendor's site and you merely access the system via the Internet or other
connection.
The SAP ERP offering costs between $ 425 and $ 660 per user per month. It
includes the software license, maintenance, and network connection. Although the
target market includes companies with an annual revenue of less than $ 200
million, SAP has learned that larger companies are looking very seriously at this
strategy, and a few are close to implementing it. Core ERP applications are
available, which includes, financials, sales and distribution, manufacturing, human
resources, advanced planner and optimizer, and the business information
warehouse.
SAP ERP helps companies with application outsourcing. It offers:
Consulting to help any size company take full advantage of e-biz capabilities;
Infrastructure and production services including hardware and network routers,
systems management services, facilities management, and support services for
the life of the system. Ongoing software and technology upgrades; and
Comprehensive data protection and backup services to lower the risk of business
disruption.
Survey.com reports that recent surveys of the enterprise resource planning (ERP)
market have revealed poor market knowledge or acceptance of the business-to-
business e-commerce portal offered by SAP.
Of respondents at companies currently using or planning to use an SAP ERP

system, 31.5 percent have "no knowledge", less than 14 percent are currently
evaluating it, and only less than 2 percent are in fact using it.
These results clearly give us an idea about the damage done to SAP ERP's market
position by its reluctance to identify the Internet as an inflection point in the ERP
market. SAP ERP is trying hard to catch up, but these surveys shows that the
delay in delivering and uncertainty caused by changes in the marketing message,

may have pushed many customers to choose instead for third-party solutions to
access and make data from SAP ERP transactional databases more extensively
accessible.

Table of Contents
CHAPTER 1: - ORIGIN & HISTORY OF SAP
CHAPTER-2: - INTRODUCTION TO SAP & ITS APPLICATIONS
CHAPTER 3: - ARCHITECTURE OF SAP
CHAPTER 4: - USING SAP R/3
CHAPTER 5: - TRANSACTION CODES IN SAP
CHAPTER 6: - INTRODUCTION TO ABAP WORKBENCH
CHAPTER 7: - SAP SECURITY & ADMINISTRATION

AUTHORIZATION

CHAPTER 1
ORIGIN & HISTORY OF SAP

SAP – Systems, Applications & Products.
SAP AG (SAP) is the largest European software enterprise and the fourth largest
in the world, with headquarters in Walldorf, Germany. It is best known for its SAP
ERP Enterprise Resource Planning (ERP) software.
Aktiengesellschaft (IPA: ['aktsiəngəzεlʃaft]; abbreviated AG) is a German term

that refers to a corporation that is limited by shares, i.e. owned by shareholders,
and may be traded on a stock market. The term is used in Germany, Austria, and
Switzerland.
The German word Aktiengesellschaft is a compound noun made up of two

elements: Aktien meaning shares, and Gesellschaft meaning company.
However to translate it as "share company" is misleading, since other types of
German companies also have shares, although these shares are called Anteile
rather than Aktien. A similar distinction exists in other languages; for example, in
Polish the two types of share are called akcja and udział.
History
SAP was founded in the year 1972 as Systemanalyse und Programmentwicklung

("System Analysis and Program Development") by five former IBM engineers in
Mannheim, Baden-Württemberg (Dietmar Hopp, Hans-Werner Hector, Hasso
Plattner, Klaus E. Tschira, and Claus Wellenreuther). The company headquarters
are based in Walldorf, a small German town close to Heidelberg, where the
university is a continuous source of employees at SAP.
As part of the Xerox exit strategy from the computer industry, Xerox retained IBM
to migrate their business systems to IBM technology. As part of IBM's
compensation for the migration, IBM acquired the SDS/SAPE software, reportedly
for a contract credit of $80,000. The SAPE software was given by IBM to the
founding ex-IBM employees in exchange for founding stock provided to IBM,

reportedly 8%. Imperial Chemical Industries (ICI) was SAP's first ever customer
in 1972.
The acronym was later changed to stand for Systeme, Anwendungen und
Produkte in der Datenverarbeitung ("Systems, Applications and Products in
Data Processing").
In 1976, "SAP GmbH" was founded and the following year, it moved its
headquarters to Walldorf. SAP AG became the company's official name after the
2005 annual general meeting (AG is short for Aktiengesellschaft).
In August 1988, SAP GmbH transferred into SAP AG (a corporation by German

law), and public trading started November 4. Shares are listed on the Frankfurt
and Stuttgart stock exchanges.
Four of the founding members -- Hopp, Plattner, Tschira and Hector -- form the
executive board. In 1995, SAP was included in the German stock index DAX. On
22 September 2003, SAP was included in the Dow Jones STOXX 50. In 1991, Prof.
Dr. Henning Kagermann joined the board; Dr. Peter Zencke became a board
member in 1993. Claus Heinrich and Gerhard Oswald have been members of the
SAP Executive Board since 1996. Two years later, in 1998, the first change at the
helm took place. Dietmar Hopp and Klaus Tschira moved to the supervisory board
and Dietmar Hopp was appointed Chairman of the supervisory board. Henning
Kagermann was appointed as Co-Chairman and CEO of SAP next to Hasso
Plattner. Werner Brandt joined SAP in 2001 as a member of the SAP Executive

Board and Chief Financial Officer. Léo Apotheker has been a member of the SAP
Executive Board and president of Global Customer Solutions & Operations since
2002, was appointed Deputy CEO in 2007, and then became co-CEO alongside
Kagermann in 2008.
Henning Kagermann became the sole CEO of SAP in 2003. In February 2007 his
contract was extended until 2009. After continuous disputes over the
responsibility of the development organization, Shai Agassi, a member of the
executive board who had been named as a potential successor to Kagermann, left
the organization. In April 2008, along with the announcement of Leo Apotheker as
co-CEO, the SAP supervisory board also appointed to the SAP Executive Board,
three new members, and effective 1 July 2008: Corporate Officers Erwin Gunst,
Bill McDermott and Jim Hagemann Snabe.
In 1973 the SAP R/1 solution was launched. Six years later, in 1979, SAP launched
SAP R/2. In 1981, SAP brought a completely re-designed solution to market. With
the change from R/2 to R/3 in 1992, SAP followed the trend from mainframe
computing to client-server architectures. The development of SAP’s internet
strategy with mySAP.com redesigned the concept of business processes.

Since its foundation, SAP has made significant development and marketing efforts
on standard application software, being a global market player with its R/2 system
for mainframe applications and its R/3 system for open client/server technologies.
The company name, SAP, stands for Systems, Applications and Products in Data
Processing. After the introduction of SAP R/3 in 1992, SAP AG has become the
world's leading vendor of standard application software. One of the reasons for
SAP's success is that since it is a standard package, it can be configured in
multiple areas and adapted to the specific needs of a company. To support those
needs, SAP includes a large number of business functions, leaving room for
further functionality and enhancements or adaptability to business practice
changes. More and more, corporations are deciding to use standard software
systems that are highly flexible and configurable and able to support most of their
business practices and information needs.
This kind of package leaves the development of custom software only for
exceptional cases. The maturity and solid experience of SAP in solving the
information management problems of businesses around the globe have made its
R/3 system the clear market leader in the development of standard applications.
Business and Markets Place
SAP is the world's second largest business software company and the third-largest
independent software provider in terms of revenues. It operates in three
geographic regions – EMEA, which represents Europe, Middle East and Africa; the
Americas (SAP America, headquartered in Newtown Square, Pennsylvania), which
represents both North America and Latin America; and Asia Pacific Japan (APJ),
which represents Japan, Australia, India and parts of Asia. In addition, SAP
operates a network of 115 subsidiaries, and has R&D facilities around the globe in
Germany, North America, Canada, China, Hungary, India, Israel and Bulgaria.
SAP invests approximately 20 percent of its annual sales revenue in research and
development in order to remain at the edge of technological innovation. With
more than 25 percent of its employees working in the research area, SAP wants to

make sure that it can maintain a constant dialogue with customers and users and
exchange with them experiences and ideas to enhance its systems and service
offerings. This information exchange is vital in order for SAP to maintain a long-
term relationship with its customers and to attract new ones to the R/3 wave.
Figure: SAP net profit.
SAP focuses on six industry sectors: process industries, discrete industries,

consumer industries, service industries, financial services, and public services. It
offers more than 25 industry solution portfolios for large enterprises and more
than 550 micro-vertical solutions for midsize companies and small businesses.
SAP Products

SAP's products focus on Enterprise Resource Planning (ERP). The company's main
product is SAP ERP. The current product is called the SAP Business Suite (also
known as SAP ERP 6.0). Its previous product was called R/3. The "R" of SAP R/3
stood for real-time - even though it is not a real-time solution. The number 3
related to the 3-tier architecture: database, application server and client (SAPgui).
R/2, which ran on a Mainframe architecture, was the predecessor of R/3. Before
R/2 came System RF, later dubbed R/1.
SAP ERP is one of five enterprise applications in SAP's Business Suite. The other
four applications are:
• Customer Relationship Management (CRM) - helps companies acquire

and retain customers, gain marketing and customer insight
• Product Lifecycle Management (PLM) - helps manufacturers with
product-related information
• Supply Chain Management (SCM) - helps companies with the process of
resourcing its manufacturing and service processes
• Supplier Relationship Management (SRM) - enables companies to
procure from suppliers.
Other major product offerings include: the Net Weaver platform, Governance, Risk
and Compliance (GRC) solutions, Duet (joint offering with Microsoft), Performance
Management solutions and RFID. SAP offers SOA capabilities (calling it Enterprise
SOA) in the form of web services that are wrapped around its applications.
While its original products were 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 Business All-in-One. On 19 September 2007 SAP
announced a new product named SAP Business by Design.

CHAPTER-2
INTRODUCTION TO SAP & ITS APPLICATIONS

What is SAP R/3?
SAP is the leading Enterprise Information and Management Package worldwide.

Use of this package makes it possible to track and manage, in real-time, sales,
production, finance accounting and human resources in an enterprise. After the
Internet, SAP R/3 is one of the hottest topics in the computer industry, and the
company that developed it, SAP AG, has become one of the most successful in the
software market. The SAP R/3 system is targeted to most industries:
manufacturing, retail, oil and gas, electricity, health care, pharmaceutical,
banking, insurance, telecommunications, transport, automotive, chemical, and so
on.
SAP has greatly based the functionality of its R/2 and R/3 software systems in the
business process concept. For SAP, a business process is the complete functional
chain involved in business practices, whatever software module has to deal with
it. This means that the chain might run across different modules. SAP sometimes
refers to this kind of feature as an internal data highway.
International applicability is another important part of the strategy to meet

today's complex and global business needs. For SAP, this does not only mean
having the software available in different languages, but also covering the
differentiating aspects of each country: currency, taxes, and legal practices
concerning human resources, import/export regulations, and so on. Users from a
multinational company in different countries can work simultaneously in the same
system using their own language, currency, and taxes.
An additional aspect of the software integration capability is real time. In fact, the
R from R/3 originally is meant for real time. When new input is made into the
system, the logical application links will concurrently update related modules so
that the business can react to immediate information and changes. This type of
updating reduces the overhead of manual processing and communication and

enables companies to react quickly in the nonstop and complex business world,
which makes SAP software systems a very valuable tool for executive planning
and decision making.
What Makes SAP Different?
Traditional computer information systems used by many businesses today have

been developed to accomplish some specific tasks and provide reports and
analysis of events that have already taken place. Examples are accounting general
ledger systems. Occasionally, some systems operate in a "real-time" mode that is,
have up to date information in them and can be used to actually control events. A
typical company has many separate systems to manage different processes like
production, sales and accounting. Each of these systems has its own databases
and seldom passes information to other systems in a timely manner.
SAP takes a different approach. There is only one information system in an
enterprise, SAP. All applications access common data. Real events in the business
initiate transactions. Accounting is done automatically by events in sales and
production. Sales can see when products can be delivered. Production schedules
are driven by sales. The whole system is designed to be real-time and not
historical.
SAP structure embodies what are considered the "best business practices". A
company implementing SAP adapts it operations to it to achieve its efficiencies
and power. The process of adapting procedures to the SAP model involves
"Business Process Re-engineering" which is a logical analysis of the events and
relationships that exist in an enterprise's operations.
SAP Services Overview
SAP has put in place a comprehensive set of quality services to help customers
during the process of implementing and supporting the R/3 system. These
services include product information, education services installation and upgrade

services, consulting, and more. SAP bases its services mainly on remote
connections with customers through the international networks.
Administrators, support personnel, and consultants should be particularly familiar
with the former SAP online service system (OSS), now known as SAPnet−R/3
front end, which is the primary source of service and support. The next section of
this chapter includes an introduction to SAPnet−R/3 front end. SAP offers a
certification process in the technical, functional, and developing areas of the
system and an extensive number of training courses worldwide.
SAP provides several types of services:
Consulting Services: - This type of individualized consulting can be given on-site

or via a remote connection to SAP. With remote consulting, customers receive
immediate and updated technical support and answers to their questions. SAP
also gives weekend support when upgrades or installations are done outside
regular working hours. Customers open the connection so SAP consultants may
directly access their systems and evaluate the problems online. Once the
consulting session is finished, the customer closes the connection.
Maintenance Services: - This is the basic and most common type of support for
customers in the preproduction and production phases of an R/3 implementation.
This service deals with answering questions and helping to resolve the errors or
problems with the system. For maintenance, SAP has set up a helpdesk, or
hotline, which monitors the calls and resolves them or directs them to the
appropriate SAP expert, and a first level customer service team that is in charge
of resolving the problems, prioritizing the calls, and if needed, referring questions
to other experts. Customers obtain this service via phone, fax, or the SAPnet−R/3
front end. It is available 24 hours a day, 7 days a week.
Preventive Services: - The primary one is the Early Watch service which
ensures successful and efficient installation of the R/3 system in all phases. This
service makes regular (usually once a month) performance checks and analyzes

the system to identify potential problems and help system managers and SAP
administrators tune the system and realize its full potential. Soon after an Early
Watch session, SAP sends the customer a report with the results of the analysis
and recommendations for avoiding potential problems, such as database table
spaces becoming full, shortage of system parameters, and buffer tuning.
SAP Application Modules
SAP has several layers. The Basis System is the heart of the data operations and
should be not evident to higher level or managerial users. Other customizing and
implementation tools exist also. The hearts of the system from a manager’s
viewpoint are the application modules. These modules may not all be
implemented in a typical company but they are all related and are listed below:
• FI Financial Accounting—designed for automated management and external

reporting of general ledger, accounts receivable, accounts payable and
other sub-ledger accounts with a user defined chart of accounts. As entries
are made relating to sales production and payments journal entries are
automatically posted. This connection means that the "books" are designed
to reflect the real situation. Modules are: -
FI−AA Asset accounting

FI−AP Accounts payable
FI−AR Accounts receivable
FI−GL General Ledger accounting
FI−LC Consolidation
FI−SL Special purpose ledger
• CO Controlling—represents the company's flow of cost and revenue. It is a

management instrument for organizational decisions. It too is automatically
updated as events occur. Modules are: -

CO−ABC Activity based costing
CO−OM Overhead cost control
CO−PA Sales and profitability analysis
CO−PC Product cost controlling
• AM Asset Management—designed to manage and supervise individual

aspects of fixed assets including purchase and sale of assets, depreciation
and investment management.
. PS Project System—is designed to support the planning, control and

monitoring of long-term, highly complex projects with defined goals.
The following lists the modules included in the project system application.
PS−APP Project budgeting
PS−BD Basic data
PS−EXE Project execution/integration
PS−IS Information system
PS−OPS Operative structures
PS−PLN Project planning
• WF Workflow—links the integrated SAP application modules with cross-

application technologies, tools and services
• IS Industry Solutions—combine the SAP application modules and additional

industry-specific functionality. Special techniques have been developed for
industries such as banking, oil and gas, pharmaceuticals, etc.
• HR Human Resources—is a complete integrated system for supporting the

planning and control of personnel activities.
There are two module groups within the human resources applications:
PA: Personnel administration, which includes the following:
PA−APP Applicant management
PA−BEN Benefits

PA−EMP Employee Management
PA−INW Incentive wages
PA−PAY Payroll
PA−TIM Time management
PA−TRV Travel expenses
PD: Personnel development, which includes the following:

PD−OM Organizational management
PD−PD Personnel development
PD−RPL Room reservations planning
PD−SCM Seminar and convention management
PD−WFP Workforce planning
• PM Plant Maintenance—In a complex manufacturing process maintenance

means more than sweeping the floors. Equipment must be services and
rebuilt. These tasks affect the production plans.
The PM system includes the following modules:
PM−EQM Equipment and technical objects
PM−IS Plant maintenance information system
PM−PRM Preventive maintenance
PM−PRO Maintenance projects
PM−SMA Service management
PM−WOC Maintenance order management
• MM Materials Management—supports the procurement and inventory

functions occurring in day-to-day business operations such as purchasing,
inventory management, reorder point processing, etc.
The MM system is made up of the following components:
MM−CBP Consumption based planning
MM−EDI Electronic data interchanges
MM−IM Inventory management
MM−IS Information system

MM−IV Invoice verification
MM−PUR Purchasing
MM−WM Warehouse management
• QM Quality Management—is a quality control and information system

supporting quality planning, inspection, and control for manufacturing and
procurement.
The following is a list of the QM modules:
QM−CA Quality certificates
QM−IM Inspection processing
QM−PT Planning tools
QM−QC Quality control
QM−QN Quality notifications
• PP Production Planning—is used to plan and control the manufacturing

activities of a company. This module includes; bills of material, routings,
work centers, sales and operations planning, master production scheduling,
material requirements planning, shop floor control, production orders,
product costing, etc.
The production planning application is made up of the following modules:
PP−ATO Assembly orders
PP−BD Basic data
PP−CRP Capacity requirement planning
PP−IS Information system
PP−KAB Kanban/just−in−time
PP−MP Master planning
PP−MRP Material requirements planning
PP−PDC Plant data collection
PP−PI Production planning for process industries
PP−REM Repetitive manufacturing
PP−SFC Production orders

PP−SOP Sales and operations planning
• SD Sales and Distribution—helps to optimize all the tasks and activities

carried out in sales, delivery and billing. Key elements are; pre-sales
support, inquiry processing, quotation processing, sales order processing,
delivery processing, billing and sales information system.
The SD system is made up of the following components:
SD−GF General Sale’s functions
SD−BIL Billing
SD−CAS Sales support
SD−EDI Electronic data interchange
SD−FTT Foreign trade
SD−SIS Sales information system
SD−MD Master Data
SD−SHP Shipping
SD−SLS Sales
SD−TR Transportation
Each of these Modules may have sub-modules designed for specific tasks as
detailed below.
System-Wide Features
SAP uses certain system wide features that should be understood at the outset.
These are used to logically, safely and flexibly organize the data in a business
enterprise.
• Customizing— is the configuring of the system to represent your

organization's legal structure, reporting requirements and business
processes. Internal reporting is a managerial tool in the daily operations.
External reporting is required by governmental units controlling the legal

structure of the corporation, such as, the IRS state taxing authorities,
SEC etc.
• Organizational Elements
O Financial—
Client is a legal and organizationally independent unit at the
highest level in SAP
Company is an independent legal entity within a client
Business areas are used to produce profit and loss
statements and balanced sheets across marketing lines.
O Materials Management
Purchasing units
Plants
O Sales and Distribution

Sales Organization
Distribution channel
Division
• Master Data is records that remain in the database over an extended

period of time. Examples:
O Customer Master
O Vendor Master
O Material master
O Account Master
This structure eliminates redundant data and is shared by all SAP Modules. It is a
critical aspect of the robustness of the system.

• Employee Self Service—your employees have access to the own HR
records over the Internet.
• Classification is the assignment of object s to a class. Each class has
standard characteristics.
• Match Codes are query tools used to find specific information using
search methods.
• Security is administered for objects, profiles and authorizations. Users
are only authorized to see or change the parts of the system required by
their job responsibilities.
Business Processes and SAP Functionality
In order to understand a system like SAP a thorough understanding of the events

and relationships that take place in a business is required. It is not enough to just
realize the Sales, Production, Finance and Accounting have jobs to do in a
business. The exact details of each action, the timing of that action and its
interrelationships with every other process must be understood. In many large
operations there may be no person that has a complete grasp of the situation.
Before an operation can be automated or computerized a thorough study of the
business must be undertaken. This task is called Business Process
Engineering.
Sequential Walk Through

• Sales
O Pre-sales activity—planning and availability support for the sales
personnel.
O Sales Order—the actual entry of the sales orders into the system
done by the salesperson at the point of sales perhaps using a PC
and Internet connections.
O Determining where the most efficient source of the ordered
product is in inventory and shipping it.
O Delivery

O Customer Billing
O Customer Payment
• Production
O Sales and Operations Planning SOP where the sales forecasts
are used in a production planning model to check feasibility.
O Master Production Scheduling MPS—the actual plan for the

whole production process.
O Material Requirements Planning MRP—where the production

plan is actually converted into raw materials input requirements.
O Planned Order—When materials are available and capacity exists

this plan is created and then converted into a
O Production Order.
O Shop Floor Control where the actual production takes place and
is registered into the system as finished goods.
O Purchasing
Requisition—Once the Production manager plans to
manufacture something a requisition for the raw materials
required but not on hand must be prepared.
Vendor Selection—made by the purchasing department
Purchase order sent
Goods receipt increasing inventory
Invoice verification as it is received from vendor
Payment to vendor.
O Finance and Accounting

Sales events must be captured at the proper time into the

ledger system.
Inventory must be adjusted to match goods shipped
Inventory must be adjusted to match raw materials received
Inventory must be adjusted to move value from raw

materials to work in process.
Inventory must be adjusted to increase finished goods when
they are produced.
Accounts Payable must be set up for purchases.
Accounts Receivable must reflect goods billed but not yet
paid for
Business Process Engineering must not only identify all these steps but must also
find the most efficient way to minimize redundant actions. For example, when
sales are made, inventory and manufacturing plans should be automatically
updated. When manufacturing plans are updated raw materials should be
automatically ordered from vendors. When finished goods are shipped customers
should be automatically billed at the same instant. Real situations are far more
complex than the simple explanation above.

Quick Tour of the SAP User Interface
The SAP R/3 system presents a Windows interface with several of the familiar
Windows functions for screen manipulation. The apparent simplicity of the
interface hides the power of the menus residing within the menu bar at the top of
the screen. The initial screen shows a menu bar with the following selections. The
first level sub menus are listed below to give you an idea of where to start:
o Office
Workplace
Telephone Integration
Appointment Calendar

Room Reservations
Start Workflow
Business Documents
o Logistics
Materials Management
Sales/distribution
Logistics Execution
Production
Production-process
Plant Maintenance
Customer Service
Quality Management
Logistics controlling
Project Management
Environment Health & Safety
Central Functions
o Accounting
Financial Accounting
Treasury
Controlling
Enterprise Control
Investment Mgt.
Project management
Real Estate
o Human Resources

Managers Desktop
Personnel admin.
Time management
Payroll
Training and Event Management
Organizational Management
Travel
Information system
o Information Systems
Executive Information Systems
Logistics
Accounting
Human Resources
Project System
Ad Hoc Reports
General Report System
o Tools
ABAP/4 Workbench
Accelerated SAP
Administration
ALE
Business Communication
Business Documents
Business Framework
Business Workflow
CCMS
Web Development

SAPScript
Hypertext
SD FI
Sales & Financial
Distribution Accounting
MM CO
Materials
Controlling
Mgmt.
PP AM
SAP
Production Fixed Assets
Planning Mgmt.
QM
Quality
Client / Server TR
Manage-
ment PM
ABAP Treasury
WF
Plant Main- Workflow
tenance
HR IS
Human Industry
Resources Solutions

SAP ERP Business Benefits
• Improve alignment of strategies and operations

o Run your enterprise in accordance with strategy and plans, accessing
the right information in real time to identify concerns early.
o Pursue opportunities proactively.
o Achieve corporate objectives by aligning workforce and
organizational objectives.
o Find the best people and leverage their talent in the right job at the
right time.
• Improve productivity and insight
o Leverage self-services and analytics across your organization.
o Improve operational efficiency and productivity within and beyond
your enterprise.
• Reduce costs through increased flexibility
o Use enterprise services architecture to improve process
standardization, efficiency, and adaptability.
o Extend transactions, information, and collaboration functions to a
broad business community.
• Support changing industry requirements
o Take advantage of the SAP NetWeaver platform's latest open, Web-
based technology to integrate your end-to-end processes seamlessly.
• Reduce risk
o Solve complex business challenges today with SAP, your trusted
partner for long-term growth, with 30 years of experience working
with organizations of all sizes in more countries than any other
vendor.
o Join SAP's world-class partner network, uniquely qualified to support
the best business practices in more than 25 industries.
• Improve financial management and corporate governance

o Gain deep visibility into your organization with financial and
management accounting functionality combined with business
analytics.
o Increase profitability, improve financial control, and manage risk.
• Optimize IT spending
o Integrate and optimize business processes.
o Eliminate high integration costs and the need to purchase third-party
software.
o Deploy other SAP Business Suite applications incrementally to
improve cash flow and reduce costly borrowing.
• Gain higher ROI faster
o Install SAP ERP using rapid-implementation techniques that cost less
than half what traditional approaches cost.
o Leverage preset defaults and prepackaged versions available for
specific industries.
• Retain top performers
o Retain your top performers through clearly defined career and
development plans.
o Link employees' performance to compensation programs such as
variable pay plans and long-term incentives.
• Provide immediate access to enterprise information
o Give employees new ways to access the enterprise information
required for their daily activities.

CHAPTER-3
ARCHITECTURE OF SAP

Overview

Now that you know what SAP R/3 is, what its foundations are, what its main
functions are, and what the company profile is, the next step is to get a closer
look at the architectural principles of the system: how it works, the main
processes involved, how communications are handled, how the system uses the
underlying database, and the way it interfaces with the operating system.
Architecture is basically the art of building, and to be able to construct or build

something, two elements are needed: a design and the building materials. SAP
R/3 includes both: it has a sound design based on a modular multitier software
client/server principle and it has architectural components, the processes and
software modules which offer the services.
This section deals with such issues as defining which elements make up the
system and how they join together. Using this approach, we will come upon how
SAP defines and implements the client/server architecture of the R/3 system. For
simplicity reasons, the figures and examples shown are mainly based in the UNIX
and Windows NT operating systems and Oracle database. However, the R/3
software's modular design and its openness make these examples conceptually
the same as for other database engines (Informix, Adabas D, and SQL−Server)
and other operating systems.
R/3 Basis Software
The R/3 basis software is the set of programs and tools which interfaces with the
computer operating system, the underlying database, the communication
protocols, and the presentation interfaces. This software enables the R/3
applications (FI, CO, SD, etc.) to have the same functionality and work exactly the
same way no matter what operating system or database the system is installed
on. The R/3 basis software is an independent layer that guarantees the integration
of all application modules. When referring to the basis software in this sense, it is
generally known as the R/3 common kernel or R/3 middleware. Kernel and
middleware have become generic computing terms which are widely used: kernel
usually refers to the core or nucleus of a

System; middleware means a set of programs which allows an independent
interface between an upper layer and a lower layer (it stands in the middle).
Note although applications functionality is the same on all platforms, there are
some differences, for instance in the transactions that deal with the management
of the database or the operating system. Additionally, adjustments in the ABAP
code must sometimes be made on the AS/400 platform, since it runs on the
EBCDIC character code, instead of ASCII for example, some SELECT statements
might differ from those used in other platforms.
The environment for the R/3 applications, built on the ABAP development
workbench and the ABAP repository, which includes the ABAP data dictionary
(centralized logical repository with all the business and system data). This
environment also has the workbench organizer and the transport system to
facilitate the modification and enhancement of the system and the integration of
new developments across systems.
Step by Step Look on Architecture

Logical Groupings or “layers” of SAP R/3 Components
The Presentation Layer

Those SAP R/3 software components that
Specialize in interacting with end-users
Form the Presentation Layer.
The Application Layer

Specialize in processing business
Applications form the Application Layer.
The Database Layer

Specialize in the management, storage and
Retrieval of data form the Database Layer
Basically, there are three logical groups or “layers” of SAP R/3 Software
components. Aside from having different functions, each group also needs a
different computer processing environment.
The R/3 Software components are grouped together in the following manner:
1. Those components that manage the storage and retrieval of data form
what is referred to as the Database Layer. Components that reside in this layer
require a computer that is specially equipped with very large and fast hard drives.
2. Those components that specialize in processing business applications

form what is referred to as the Application Layer. Components that reside in the
Application Layer provide an optimal processing environment for SAP R/3’s

business applications. These components require a computer that has multiple
CPUs and vast amounts of RAM.
3. Those components that specialize in interacting with end-users form

what is referred to as the Presentation Layer. These components simply need
an industry standard PC to support a graphical user interface (GUI).
Let’s take a closer look at the roles/responsibilities of each of these layers.
Three tiered client-server architecture “logical layers”
Communication
The Presentation Layer

collects user input and
creates process requests.

uses the application logic of
SAP programs to collect and
process the process requests.
The Database Layer

stores and retrieves all data.
The presentation or GUI layer typically executes on an industry standard

compatible PC. It receives keyboard/mouse data from a user and sends that data
in the form of process requests to the application layer for further processing.
When the presentation layer receives output from the application layer it

reformats the data and presents textual and graphical data to the users PC
screen.
The application layer consists of R/3's core components. The majority of R/3
business logic processing occurs in the application server layer. This is where the
work processes are managed by the dispatcher. We’ll learn more about work
processes and the dispatcher shortly.
The database layer contains an engine whose sole mission is to store and
retrieve data on behalf of the application layer. SAP R/3 uses the industry
standard database access language SQL (pronounced “SEE”-”QUEL”) as an
interface to access its supporting database.
The R/3’s database layer supports many relational data base systems from
different data base suppliers such as Oracle and Informix. To make SAP R/3
database vendor independent, R/3 uses only used a minimum subset of the
functionality of the supporting database.
Physical distribution of R/3’s logical layers
Presentation Layer Application Layer Database Layer

Components components Components
reside in: reside in: reside in:
Presentation servers: Application servers: Database servers:

Systems capable of Specialized systems Specialized systems
providing a graphical multiple CPUs and with fast and large
interface. vast amounts of RAM. hard drives.
As we know, each of R/3’s layers requires a different, and specialized computing

environment. In a practical sense, no single hardware platform can be optimized
to provide each of R/3’s layers with the ideal environment.

Therefore, through the use of client/server technologies, separate optimized
computers are used to provide the ideal environment to each of the different
layers. (Shown above)
In the next session we’ll define the term “client/server”, and specifically
take a closer look at SAP R/3’s client/server model.
Communication with Database
ABAP
Objects
interface between the ABAP Dictionary

Databas
e and the underlying database.
Utility
Databas
e

Illustration: Client/server defined.
PC Software program SAP Client Server Software

Presentation Layer
Application Layer
MS Excel components Database Layer
A B C
We know that SAP R/3 is software, it particular it is client-server software. This

means that the groups/layers that make up an R/3 System are designed to run
simultaneously across several separate computer systems.
When you install Microsoft Excel on your PC, each component of Excel (printing
components, graphing components, word processing components, and etc.) is
stored, managed, and processed via the hardware of your PC.
When a company installs SAP’s software each component (or “layer” in R/3’s case)
is stored, managed, and processed via the hardware of separate and specialized
computer systems.
Each of the various layers is capable of calling upon the specialty of any of the
other installed layers in order to complete a given task. Those components/layers
that are requesting services are called “clients”, those components/layers that are
providing services are called “servers”. Thus the term - “client/server”.

Let’s take a look at specifically how the various SAP R/3 layers are physically
distributed across separate and specialized computer systems.
Physical distribution of R/3’s three layered client-server

architecture
Presentation Layer components are installed across many PCs.

components are installed
across one or more high-
end servers.
The Database Layer

components are installed on
one high-end database server.
The typical physical distribution of each of the R/3 layers is shown above.
It is important to note that each and every installed copy of SAP R/3 always inter-
operates as a logical three layered client/server system. In certain sub-optimal
cases multiple logical layers may coexist on the same physical computer.
Nevertheless, SAP R/3 always works as a three layered client/server system.
On the next you’ll see how R/3’s layers can be distributed across one or many
computers. The arrangement of the logical layers across computers is referred to
as a system’s client/server configuration.

R/3’s Client/Server Configurations
Centralistic
Computer
“A”
R/3 Basis client/server configurations:

Centralistic: All SAP R/3 layers reside on the same physical computer. One
important distinguishing characteristic between the various R/3 client/server
configurations is “scalability”. If a configuration is scaleable, adding additional
computers to the system will increase the overall performance of the system.
Centralistic client/server configurations are not scaleable at all. Consequently, this

configuration is never used in a production environment. Centralistic client/server
configurations can be used for example as a “proof-of-concept”/demonstration
system. SAP has actually installed an entire SAP R/3 system on a notebook
computer for use by SAP’s sales representatives.

Distributed Presentation
Computer
“A”
Computer
“A-1”
Computer
“B”
Computer
“A-2”
Computer
“A-n”

Distributed presentation: The presentation layer is “rolled out” to
desktop PCs. The application layer and the database layer are installed on the
same computer.
In terms of increased performance, the Distributed presentation configuration is

no more scaleable than the centralistic configuration. Additional computers can be
added at the presentation layer, however, this does not return a significant
increase in the overall system’s performance. This configuration is very
“mainframe”-”ish”.

Two tier Client/Server

Computer
“A”
Computer
“A-1”
Computer
“B”
Computer
“A-2”
Computer
“A-n”

Two tier client/server: The presentation and application layers are
installed on the same computer. The database layer is installed on a separate
computer.
Two tier client/server configurations, or first generation client/server
configurations as they are often referred to, offer increased scalability.
However, two tier client/server configurations create other problems. The

communication across the network between the front-end (presentation and
application layers) and the back-end (database layer) becomes a bottle-neck
quickly. The performance of a two tier client/server system across a wide area
network is abysmal.

Three tier Client/Server

Computer
“A”
Computer
“B”
Computer
“A-1” Computer
Computer “C”
“B-1”
Computer
“A-2”
Computer
“B-n”
Computer
“A-n”

Three tier client/server: Presentation, application, and database layers
run on separate computers.
Currently, three tier client/server offers the best solution for most businesses. It is
highly scaleable, and offers better distribution of process requests received from
the users. The computers in the application layer are often capable of satisfying
the users process requests without accessing the database, which in turn boosts
performance.
The GTC uses three tier client/server for most of its SAP R/3 functional courses.

R/3’s multi-tier, cooperative client/server configuration
Multi-tier, cooperative Client/Server

Computer
“A” Computer
“B”
Computer
Computer “C”
“A-1”
Computer
Computer “B-1”
Computer
“A-2” “C-n”
Computer
Computer
“B-n”
“A-n”

Multi-tier, cooperative client/server. Presentation, application, and
database layers run on separate computers. But what makes multi-tier,
cooperative client/server different is that this configuration is scaleable on the
backend (database layer) as well.
Multi-tier, cooperative client/server is becoming a very important technology as

more and more organizations attempt to implement SAP R/3 globally. In such a
case one central database is not feasible. New technologies such as SAP’s
Application Link Enabling (ALE) and Oracle’s Parallel Server are making multi-tier,
cooperative client/server a growing reality.
Let’s take a closer look at ALE.

R/3’s multi-tier, cooperative client/server configuration
Computer
“A” Computer
“B”
Computer
Computer “C”
“A-1”
Computer
Computer “B-1”
“A-2” Computer
Computer “C-n”
Computer
“A-n” “B-n”
Application Link Enabling (ALE) is designed to create a distributed - but

integrated - SAP R/3 system.
ALE permits the loose coupling of different independent SAP R/3 systems.
The ALE concept is based upon business-process controlled exchange of messages
with consistent data storage. Applications are integrated by means of synchronous
and asynchronous communication mechanisms in a time-controlled manner.

Business transactions and the R/3 Runtime System
Screen 2 Screen 1
R/3 Runtime System
... LOCK business object “XYZ” then,

... Prepare to “ROLLBACK” if necessary
From the view point of the R/3 runtime system, a business transaction is simply a
sequence of SAPGUI screens that that logically flow one upon the other.
The R/3 runtime system is capable of providing “locks” to ensure that a given user
session receives exclusive access rights to a certain business object for the
duration of a business transaction.
The R/3 runtime system also ensures that all changes made to the database,
within the scope of a given business transaction, can be completely reversed or
undone at any time until the business transaction has been successfully
concluded.

Work Process
SAP Architecture’s Terminology Overview
A Process is essentially
a program. Each process Process
has memory and access
to system resources.
In the simplest of terms the operating system provides a working environment for
software applications. In some cases (Windows NT, UNIX) it will enforce rules that
determine the length of time that an application can access the central processing
unit (CPU). The operating system also monitors and provides memory and file
access.
Processes are used to efficiently manage the software application’s requests for
the resources of the operating system. A software application must have a
process open in order to request resources from the operating system. The
process and the software application are very closely linked.
Each process has memory and access to system resources. A process comprises:
1. An executable program that defines initial code and data
2. A memory address space where the process’s code and data are
stored
3. System resources

4. At least one threads to execute the code. The ability to
simultaneously manage a number of threads per process defines multi-threaded
operating systems.
A Thread is the actual component Process

of a process that is executing at
one time. Each thread is capable
of completing a different task that
it’s process requests.
Thread 1 Thread 2 Thread 3
A thread is a single unit of execution. It is the actual component of a process that

is executing at one time.
It runs in the address space of the process, using resources allocated to the
process. Each thread is capable of completing a different task that it’s process
requests.


Process
Process Process
OS Kernel
CPU
Multi-threading operating systems, like Windows NT and UNIX are capable of

executing more than one thread at a time.
At the “heart” of an operating system is the kernel.
It is the responsibility of the operating system’s kernel to manage the time of the
CPU. It must keep each of the processes that are attempting to accesses the CPU
in harmony. It is capable of changing the priority the threads from each of the
processes that are attempting to get processing time on the CPU.

SAP
Online Update
Enqueue Spool Background
SAP Dispatcher
A component of the SAP
Kernel called the Dispatcher
CPU must manage process access
OS Kernel to the OS kernel.
Within the scope there are 5 different SAP R/3 processes. In R/3 they are referred
to as Work Processes. Each work process completes a specific task for the SAP
application software.
R/3 also has its own kernel. In the center of the R/3 Basis Kernel is SAP’s
proprietary control agent, the SAP Dispatcher. Together with the respective
operating system, the dispatcher manages the resources used by the R/3
applications. It must “communicate” with the operating system’s kernel to
manage the activities of its processes.
Now let’s take a closer look at how the SAP R/3 work processes
work.

The R/3 Runtime System

Dispatcher
Application
Server “A”
Online Update Enqueue Spool Background
Dispatcher
Application
Online Update Enqueue Spool Background Server “B”
Dispatcher
Database
Online Update Enqueue Spool Background Server
The SAP R/3 Dispatcher and its Work Processes constitute the R/3 Runtime
System.
To the host operating system, the R/3 Runtime System simply appears as a
collection of processes. No different than any other programs that may be running
on the machine.
Throughout the R/3 System, you can be assured that where there are works
processes there will be a dispatcher, the exact number of work processes is
variable and depends on the specific configuration.
One of the main purposes of the dispatcher is to dole out pending processing
requests to the work processes. There are special work processes for:
1. Interactive SAPGUI screen processing,
2. Updating of the database,
3. Background processing,
4. Spooling,
5. and management of locks.

Dispatcher
USER 3
USER 1
Dispatcher
USER 2 USER 4
We know in the center of the R/3 Basis Kernel is SAP’s proprietary control agent,
the SAP Dispatcher. Together with the respective operating system, the dispatcher
manages the resources used by the R/3 business applications.
The dispatcher acts like a conductor, orchestrating the assignment of the correct
resources to the processing requests that are received from the end-users. The
following page shows an example of how the dispatcher works.
The specific tasks of the dispatcher are:
1. Maximize efficient distribution of process requests to work
processes
2. Monitor the use of the R/3 buffers.
3. Ensure process requests are sent back to presentation level
when completed.
4. Overall management of communications activities.

Let’s have a look on each of R/3’s work processes
Work Processes

or Batch
There are five types of work processes:

- Online work process for executing sequential steps in business
transactions
- Update work process updates the database. It has two types of
components:
a. U1 components for executing time-critical database changes
b. U2 components for executing non-critical database changes
- Enqueue work process for setting and releasing locks on SAP business
objects
- Spool work process for spool formatting
- Background work process for executing background jobs.
Let’s take a simplified look at how the presentation layer interacts with
the dispatcher and work processes.

Dispatcher in action
Presentation level Various types of
processing requests
Application level
Request
queues
Dispatcher
Update Enqueue Spool Batch

Online
First, user input is accepted by SAPGUI. SAPGUI is the SAP software that runs on
your PC. SAPGUI converts the users input into process requests that the
dispatcher can understand, and then sends the process requests to the
dispatcher.
After receiving the process request the dispatcher places it into the request
queues.
As work processes become available the dispatcher dispatches the queued process
request to the appropriate work process. The actual processing takes place in the
work process.
Work processes are specialized components of the SAP software that are designed
to do very specific activities. For example if the dispatcher receives a process
request to print a report, that process request will inevitability find its way to the
work process that manages the print spool.

When processing is complete, the result of a work process is returned, via the
dispatcher, to the SAPGUI. The SAPGUI interprets the received data and
generates the output screen for the user.
Let’s add some more details to this concept.
Inside the R/3 Runtime System

Various types of
processing requests
Process Request
User: Fred Jones
Activity: Read data XYZ
Screen: 1
Request
queues
Dispatcher
On the previous figure we explained that after a process request is received by

the dispatcher it is placed in a set of request queues, but what exactly is
contained within a process request? Let’s find out.
Each process request that is sent to the application layer contains information that
describes the user (security privileges, etc.) as well as a specific description of
what the user is trying to do.
What is important to note here is that the specific description of what the user is
trying to do, mention above, pertains to only one SAPGUI screen at a time.

Several SAPGUI screens together create a single SAP R/3 transaction. If you recall
in an earlier chapter we defined an business transaction as a sequence of SAPGUI
screens that that logically flow one upon the other.
The term business transaction is used to describe a SAP R/3 transaction which is
used within the context of one of the business applications i.e. FI, CO, MM, PP,
etc. however not all SAP R/3 transactions are business transactions. Many SAP
R/3 transactions are used in the management of the R/3 System itself.
What all of this means is that when you run an SAP R/3 transaction you are
actually sending many individual screens to the application layer in the form of
individual process requests.
The code behind R/3
SAP R/3 Transactions are

written in ABAP/4. SAP’s 4th
generation interpreted
programming language.
SAP R/3 Runtime System

Dispatcher is written in ANSI C
The SAP R/3 transactions are written in ABAP/4 (pronounced “AH-BAP four”),
SAP’s own 4th generation programming language. ABAP/4 is an interpreted
language.
The R/3 Runtime System i.e. the dispatcher, and work processes, etc. are written
in ANSI-C, but all of the business applications and system management tools are

written in ABAP/4. ABAPs (programs written in ABAP/4) are interpreted not
compiled.
In order for interpreted languages to execute they require additional components

that are external to the program. For example Microsoft’s Visual Basic
programming tool is, like ABAP/4 an interpreted language. Therefore Visual Basic
relies on external components that reside in Windows to execute. ABAPs similarly
rely on external components that reside in the R/3 Runtime System.
There are two external components (not contained within the ABAP/4 code) that
are used to interpret ABAP/4 code, the Dynpro Processor, and ABAP/4 Processor.
Let’s take a closer look at how this concept relates back to the concept of
process requests.
Wor k Pr oc es s
Task
Handler
DYNPRO Processor
ABAP/4 Processor
memory

The specific description of what the user is trying to do, which is contained within
each process request, is in the form of ABAP/4 code, and routines.
Therefore, most work processes must use two “interpreters” to “understand” what
the process request is actually requesting, The ABAP/4 processor or the Dynpro
Processor.
You can think of the Dynpro processor as the SAPGUI screen processor. For you
ABAPers (people who program in ABAP/4) out there the Dynpro processor handles
flow-logic. Flow-logic describes how one screen in an ABAP works with other
screens in an ABAP.
The ABAP/4 processor on the other hand is used to actually interpret the ABAP
code (non-flow-logic code).
The overall activities conducted within a work process are coordinated by its Task
handler. The Task Handler is the component of a work process that manages the
work that occurs within the work process. The Task Handler, in turn, uses the
ABAP/4 Processor and the Dynpro Processor to discover what exactly it is being
asked to do.


Various types of
processing requests
Process Request
Read data “XYZ” or
Write data “XYZ”
Request
queues
Dispatcher
In the most basic sense these process requests are either requesting to read data
(i.e. when generating a report) or requesting to write data (e.g. entering a new
customer).

Reading data in the R/3 System
Transactio
n
Screen Screen Screen
1 2 n.
Process Process Process

Request 1 Request 2 Request 3
Request
queues
Dispatcher
Each screen in the SAP R/3 Transaction is sent to the dispatcher, which resides in
the application layer, in the form of processing requests.
After the Dispatcher receives the first processing request from a transaction it will
place it into the request queues.
The Dispatcher knows at this point what type of processing request it has just
received. In this example the Dispatcher knows that this processing request
should be serviced by an Online Work Process, as opposed to a Spool work
process or some other type of work process.
The Dispatcher will keep this process request queued until an Online work process
signals the Dispatcher that is now available.
Once an Online work process becomes available it’s Task Handler will copy the
process request data to its own local private memory so that it can begin working
on the request.

Shared Memory Segments

Reading data in the R/3 System
Transaction
Screen 1 Screen 2 Screen n.
Dispatcher
R/3 Request Process Requests

Buffers Queues
Online
Task Task
Onlin
Onlin
Task Handler Handler
Handler
e
DYNP DYNP
DYNP
Requested ABAP/4 ABAP/4
data retrieved ABAP/4
memory
emor
memor
from the R/3
m
Buffers
y
LE Y
A B B US
Y B US
AV A IL
The Online work process’s Task Handler will use the Dynpro and ABAP/4
Processors to determine what this process request is actually requesting.
In our example, the first screen of this transaction is requesting data for a report.
Therefore the Task Handler will search R/3’s Buffers for the specified data. If the
specified data is not buffered than a database access will be needed.
Let’s suppose that the data is actually in the R/3 Buffers at the time of this read.
Since this is only the first screen of this transaction there may be a need to store
the data that the Task Handler just retrieved from the R/3 Buffers. This retrieved
data will most likely be needed by the next screen in this transaction.

Let’s review what we’ve just learned.
An end-user runs an SAP R/3 transaction. In our example the transaction creates
a report. The transaction itself contains three screens, which allow the end-user to
specify additional criteria to the report. Each screen is translated into a process
request. The first process request is received by the Dispatcher and is
subsequently stored in the request queue.
The Task Handler of the first available Online work process copies the process
request to its own local private memory. The Task Handler uses the Dynpro and
ABAP Processors to determine what exactly it is being requested to do.
If it needs to access data, the Task Handler will access the R/3 Buffers to acquire
the data. The acquired data will then be stored in a user context located in
extended memory so subsequent process requests in this transaction can access
the data. When each process request for this transaction has been serviced (by
multiple online work processes or by the same online work process) the sum total
of the user context is sent to the end-user as results.

Now that we have an understanding of what happens when the Dispatcher
receives a request to read data, let’s take a look at what happens when the
Dispatcher receives a request to write data.
Writing data to the database is a much more intensive operation that simply
reading data from the database. There are more types of work processes used,
and the transaction itself, of course, is very different. A transaction that writes to
the database is structured as a SAPLUW.
SAPLUW is the term used to describe the sum total of the sequential SAPGUI
screens of an SAP R/3 transaction plus the update of the database.
A SAPLUW is always executed completely or not at all.
The Background Work Process
Background
Defining a background
job.
Background processing enables you to plan the start of ABAP/4 programs. Then,
at the given time, they are started by special work processes called a Background
work process.

Background processing runs are composed of jobs. Each job consists of one or
more steps that are processed one after another.
In general, job processing is not triggered immediately, usually, a specific start
time is defined when the job is planned.
The Spool Work Process
The Operating System Print

spooler assumes the
print queue management.
O/S
Spooler
Spool Requests that are generated online or during background processing are
placed in the spool database with information about the print format.
As resources become available a print request will be generated for the spool
request.
The print request is then processed by a spool work process.
Once the spool work process has edited the data for printing, it forwards the print
request to the operating system spooler.
The operating system spooler assumes the print queue management and makes
sure the requested data is forwarded to the output device.

Communication
A service
Service A
Online
Process A1 Process A2
Requesting a particular
function or “service”.
In this part we introduce the term “service”. A service is a process or group of

processes that perform a specific system function (i.e. “service”) and often
provide an application programming interface (API) for other processes to call.
Many services start at boot time and continue to run as long as the system is up.
An API is a defined set of related function calls that can be used to ease the
programming burden. Instead of writing routines from scratch, a programmer can
make use of an environment's API.
Two vital components of the SAP R/3 communications system are:
1. The Message Service*
2. The SAP Gateway Service*

* The computer that the Message Service resides upon is referred to as the
Message Server. The computer that the SAP Gateway Service resides upon is
referred to as the Gateway Server.
The Message service
Message
server
Online
Lock Request
Enqueue
Message Lock Table
Service
The message service is used by the application servers to exchange short, internal
messages (for example, trigger an update, enqueue/dequeue, trigger a
background job). Shown above is an enhanced example, from the previous
chapter, of the message service being utilized.
Every application server reports to the message service with a unique name.
The application servers must know the names of the other application servers that
“specialize” in update, enqueue, background, and spool processing, and activate
the corresponding services by specifying this “address” to the message service.

The SAP Gateway service
Gateway
server
Communication to an
external R/3 System
SAP Gateway
An external Service
R/3 System
While short messages can be exchanged between an R/3 System’s application

servers via the message server, larger quantities of data (application data) are
transferred via the SAP gateway. The communications partner can be in the same
system, a different R/3 or R/2 System, an external program.
The Common Programming Interface - Communications (CPI-C) is a standard call
interface for applications (i.e. an API), which performs direct program-to-program
communication. For those of you with Windows programming experience; CPI-C is
similar to Microsoft’s Dynamic Data Exchange (DDE).
CPI-C was first defined as a standardized communications interface by IBM in
1987, as part of the SAA standard.
The main advantage of CPI-C is the easy portability of programs to various
system platforms made possible by the common interface.

The CPI-C handler (SAP gateway) enables communications between R/3, R/3, and
external applications using the CPI-C protocol.
Remote Function Calls
Non SAP system
Example: Communication with an external system
Remote Function Call (RFC)

This interface lies on a higher logical level than CPI-C. It simplifies the
implementation of communication processes, by relieving the programmer of
writing communication routines.
The RFC interface enables function calls between two SAP systems (R/3 or
R/2), or between an SAP system and an external one. The RFC library functions
support the C programming language and Visual Basic (on Windows platforms).
In the case of asynchronous RFC, calls are also transmitted to remote
systems when the target system is not active or momentarily cannot be reached.

SAP obviously realizes the importance of providing communication access to R/3
via industry standards. Another industry standard that SAP R/3 utilizes is EDI or
Electronic Data Interchange.
EDI is a computing standard that large corporations use to efficiently complete
business transactions between each other.
LOGON LOAD BALANCING
Logon Load Balancing
or or
R/3 logon load balancing is used to dynamically distribute R/3 end-users across
application instances.
When you set up logon workgroups you maximize the efficiency of each of the
application instances defined within your R/3 System.
Each logon workgroup consists of one or more application instances. Each of the
application instances defined within a given logon workgroup will be available to
the end-user, but only under predefined circumstances.

R/3 System Administrators can define the maximum response time for a particular
logon workgroup, as well as, the maximum number of users logged on within the
logon workgroup.
End-users simply need to know the name of the R/3 System and the name of the
logon workgroup. The host name and the system number are no longer needed
when an end-user logs on.
Logon Workgroups
This Logon Load Balancing configuration is good
because the servers are assigned to specific
applications.
Logon Group “HR” Logon Group “FI/CO”
Server A Server B Server C Server D

HR HR FI/CO FI/CO
Configuration below for Logon Load Balancing is not as

good because servers are available to all applications.
Logon Group “PUBLIC”
Server A Server B Server C Server D

HR+FI/CO HR+FI/CO HR+FI/CO HR+FI/CO
The benefits of defining logon workgroups are

1. You now have the ability to create specially re-configured
Application instances designed with improved response time, for user groups with
time-critical transactions.
2. Activities of the application instances become more predictable
which, in turn, allows you to tune each specific application instance.
3. A given application instance will naturally develop buffers that are
tuned exclusively to tasks of its logon workgroups.

SMLG is a transaction within the CCMS (Computing Center Management System).

CCMS is a set of tools that facilitate the System Administration component of the
R/3 system.
Lets take a look at the CCMS and how logon workgroups are configured
on the R/3 System.
SAP Logon Menu
Application Servers
Workgroup
You log on to the R/3 System from the SAP Logon Menu, which is a special
program for Windows PCs that mediates between the R/3 System and the user
interface, SAPGUI.
The SAP Logon Menu displays the available logon groups and automatically selects
the server with the best response times.
You can add an available Workgroup or Application Server to the menu.
When you log on to the R/3 System, you can:
1. Log on to a specific Application Server

2. Log on to a Workgroup. The Application Server with the best
response time is selected automatically
To display the SAP Logon Menu, double-click its icon. (Source executable is
SAPLOGON.EXE)
To log on to an SAP R/3 System
Highlight an entry and select Logon or double-click the entry.
Recommendations for Logon Groups
Production
Planning
or
Each SAP business application has different resource requirements. Certain

applications require their own logon workgroups and application instances.
For example, you should assign separate application servers for the R/3
application PP.
For contingency reasons, each logon workgroup should have two application
instances associated to it. If the first application instances are unavailable or are
very busy, the end-user will be connected to the second application instances.
Application instances can be added or removed while the R/3 system is running.

SAP Logon Menu
You can log on to the R/3 system via the SAP logon menu (SAPLOGON.EXE)
The SAP logon menu is a program made for Windows PCs that mediates between
the R/3 System and the user interface, SAPGUI.
After logon workgroups have been specified in the central message server, the
SAP logon menu will be able to read the groups from the message server into its
menu configuration.
The SAP Logon Menu displays a list of available application instances and logon
workgroups that are available to the end-user.
End-users will use SAP logon menu to log on to a specific application server or log
on via a logon workgroup. If they utilize their logon workgroups they will
automatically logged onto the application instance with the best response time.
FRONT END OF MYSAP ERP

CHAPTER-4

USING SAP R/3

Using SAP R/3
The SAP R/3 presentation interface behaves very similarly to any other typical
windows application. It does not make much sense for administrators and
technical consultants to know and control the kernel of the system without being
able to use the basics of the presentation interface. If you are the system
administrator, you will very often be requested to give end-user support regarding
the SAPGUI features. The purpose of this chapter is to give an overview of the
main functions and possibilities of the SAP R/3 windows presentation interface,
also known as SAPGUI.
Basic topics such as logging in and out of the system, changing the passwords,
the elements of the R/3 window, how to move around, getting help, filling up
screen fields, launching and looking at background and printing jobs, and the
basics of user sessions and transactions are covered.
After Installing the SAP GUI
To log on to the SAP System the SAP GUI must be installed.
New icons for the SAP GUI
After you have installed the SAP GUI one or more of the icons for SAP Logon Pad
or/and SAP Logon will appear on your desktop.
SAP Logon
SAP Logon Pad
A new icon SAP configuration will be added to the Windows control panel.
New menu for the SAP GUI

In the Windows menu Start -> Programs a new submenu SAP Front End will
appear.
User-specific Automatic Update
If SAP GUI was installed from an installation server, every user can activate an
automatic update of the local SAP GUI from this installation server.
To optimize network load the automatic update does not check for a new update
every time SAP GUI is started, but only after a configurable number of double-
clicks on the SAP Logon (or SAP Logon Pad) icon.
In case an updated version of SAP GUI is available on the installation server
SAPSetup is launched to update the local SAP GUI before SAP Logon is started.
To configure the automatic update,
o Right-click the SAP Logon (or SAP Logon Pad) icon

o And choose Configure Auto Update from the context menu.
The following dialog box appears:
By default the automatic update is

o Switched on if the installation of SAP GUI was run from an installation
server. The default value for the number of double-clicks on the SAP Logon
(SAP Logon Pad) icon required before the check for an update is performed
is set to 5.
o Switched off if the installation of SAP GUI was run from CD / DVD.
Using the checkbox "Activate Auto-Update" you can deactivate or activate the
automatic update. You can also configure the number of double-clicks on the SAP
Logon (SAP Logon Pad) icon before the check for available updates on the
installation server is performed according to your needs. To activate the change(s)
choose the "OK" button.
Using SAP GUI to Log on to SAP Systems
Logging on to a System and Logging Off
Before you log on for the first time, your system administrator will give you an
initial password. During the logon process, you should create a new password,
known only to you. After that, you use your own password whenever you log on.
(These procedures may differ somewhat at your company; for more information,
contact your system administrator.)
Logging On
After you have started the SAP System the first screen you see is the logon screen
(in this case, with the title SAP R/3).

When you choose the TAB key after you have entered data in a field, the cursor
moves to the beginning of the next field.
Passwords
A password is a string of characters (letters and numbers) known to a single user,
which prevents other users from accessing the system using that user
identification. As stated before, when logging on for the very first time, the new
password dialog box is displayed, as shown in Fig. below. There are specific rules
for setting passwords.
Password Rules
In the SAP system, users must follow certain rules when entering passwords.
Some rules are fixed in the SAP code and others can be set by the system
administrator using certain profile parameters or by forbidding entries by
specifying values in tables.

Providing the administrator made no changes, the standard password rules of the
system are as follows:
 Password length must be at least three characters long and no more than
eight.
 Passwords are not case sensitive, so, for example, if your password is
Laura, all strings laura, LAuRa, and LAURA behave just fine.
 Valid alphanumeric characters include all the letters (from a to z), the
numbers, and even the punctuation marks, as long as the password does
not begin with a question mark (?), a blank space, or an exclamation point
(!).
 You cannot use the string pass as your password; nor can the password
start with three identical characters (oooyeah is an invalid password).
 The password cannot begin with any sequence of three characters which
matches the same sequence anywhere in your user ID (laughu2 is an
invalid password if your user ID is laurab).
 You cannot use any of the last five passwords.
 The following list gives some examples of valid and invalid passwords.
o Valid Passwords Invalid Passwords
o 13071985 pass (it's a system nonpermitted password)
o maria099 !jun97 (begins with an invalid character)
o hello=98 sapr3 (just because the system manager decided to include
it among forbidden passwords)
o uandme2 mmmycar (begins with the three identical characters)
 System administrators can impose additional password rules, such as
forbidding some strings of characters as
passwords, setting a minimum password length other than three, setting an
expiration time, and so forth.
The logon screen is shown above. To log on to the SAP System:

1. Enter the client number in the Client field.
If a default client number appears in the field, you can either accept it, or
change it by typing over it.
2. To move the cursor to the User field, choose the TAB key. Enter your user
ID in the User field.
3. To move the cursor to the Password field, choose the TAB key. Enter the
initial password provided by your system administrator in the Password
field.
4. As you type the initial password, the asterisks remain in the field, and only
the cursor moves. As a security measure, the system does not display what
you type.
5. In the SAP System, passwords are not case-sensitive.
6. To display screens, menus, and fields in another language, move the cursor
to the Language field by pressing the TAB key. Enter the language key for
the desired language.
7. Choose Enter.
8. The system automatically displays the new password dialog box. You must
change your initial password.
1. If you do not see the new password dialog box, check the status bar for a
system message. You may have entered an incorrect client number,
password, user ID or language key. If this is the case, repeat steps 1
through 5.

2. In the New password field, enter a new password.
As you type the new password, the asterisks remain in the field, and only
the cursor moves. As a security measure, the system does not display what
you type.
3. To move the cursor to the Repeat password field, choose the TAB key.
4. In the Repeat password field, enter the new password again, exactly as you
entered it the first time.
5. Choose Confirm (or choose Enter). If you have successfully changed your
password, the Copyright dialog box will appear.
6. In the Copyright dialog box, choose Continue (or choose Enter).
If there are system wide messages, the System Messages dialog box
appears. After you have read the messages, choose Continue (or choose
Enter) to close the dialog box.
Logging Off
You can log off from the SAP System from any screen:
o From the menu bar, choose System -> Log off.

o Click the button at the upper right-hand corner of the screen (if you only
have one session running).
The Log off dialog box appears. It informs you that any data you have not yet
saved will be lost if you proceed with logging off.
If you are not certain that you have saved all of your data and you do not want to
log off after all, choose No. You return to the screen in which you were working.

If you are certain that you have saved all of the data you want to save, choose
yes. All of your SAP System sessions close. You have successfully logged off.
In the standard system, the main menu screen is displayed, as shown in Fig.
below.
Figure: SAP R/3 main menu.

When you see this screen, you have successfully logged on to the R/3 system.
Elements of a SAP GUI Window
The Main Window
The Menu Bar
The menu bar is the bar in the screenshot below containing the menu options
Display, Edit and so on.
The following menus are standard on every SAP screen:
Menu Description
System Contains functions that affect the system as a whole - such
as Create session, User profile and Log off.
Help Provides various forms of online help.

The following menus are standard in most SAP applications:
Menu Description
<Object> Usually named after the object you are currently working
with, for example, Material. Contains functions that affect
the object as a whole – such as Display, Change, Print, or
Exit.
Edit Allows you to edit components of the current object.
Common functions include Select, Edit and Copy. The
Cancel option lets you leave a task without saving the data
you have entered.
Goto Allows you to move directly to other screens of the current
task. Also contains the Back option, which takes you back
one level in the system hierarchy. Before going back, the
system checks the data you have entered on the current
screen, and displays a dialog box if it detects a problem.
The following menus may also appear:
Menu Description
Extras Contains additional functions you can choose to complete
the current object or an object component, but which you
do not need regularly.
Environment Contains functions to display additional information about
the current object.
View Allows you to display the current object in different views,
for example, switching between a single-line and double-
line display of a table.
Settings Allows you to set user-specific transaction parameters.
Utilities Allows you to do object-independent processing, such as
deleting, copying, and printing functions.
Sometimes not all of the available menus fit on one line in the menu bar. In
this case, they wrap to the next line. The dropdown principle remains the
same.

The System Function Bar
The system function bar is the bar below the menu bar. It consists of a range of
icons with general GUI functions and a field where you can enter a transaction
code.
The Title Bar
The title bar contains the name of the R/3 application currently being displayed.
In the graphic below the title bar is the bar containing the title SAP Easy Access
ABAP Workbench:
The Status Bar
The status bar provides general information on the SAP System and transaction or
task you are working on. System messages are displayed on the left of the status
bar. There are three fields on the right hand side of the status bar: one with
server information, the other two with status information
The status fields are described from left to right:

o On the far left,
 A cross on a red background identifies an error message.
 A check mark on a green background identifies other system
messages.
o To hide (or show) the status fields, choose the small white arrow to their
left (or right, respectively) .
o To display the following system information, choose the icon in the first
status field:
 System
 Client
 User
 Program
 Transaction
 Response time
o The second status field displays the server to which you are connected.
o The third status field specifies your data entry mode. By clicking on this
field, you can toggle between the Insert (INS) and Overwrite (OVR)
modes.
Insert and Overwrite Modes
You can enter data in two modes:
o Insert: Any data to the right of the cursor moves to the right as you type.
o Overwrite: You type over any data to the right of the cursor.
Typically, you use the Overwrite mode to overwrite data, and the Insert mode to
insert data between existing data (for example, if you left out a letter in the
middle of a word).

In the standard system, the default entry mode is Insert. However, you can to
switch to Overwrite at any time.
The status bar shows which mode you are currently in. It displays INS when you
are in the Insert mode and OVR when you are in the Overwrite mode.
To switch entry modes, choose the INS key (insert).
The current entry mode changes to the new entry mode.
The INS key is a toggle between the two modes, that is, the entry mode changes
each time you choose INS .
You can also toggle between modes by clicking the entry mode status field at the
far right of the status bar.
Working with Sessions
A session is basically another SAP instance on your screen. Multiple sessions allow
you to work on more than one task at a time. This can save you time and reduces
the need to jump from screen to screen.
A record can only be edited by one user in one session at a time. Multiple
write access to the same record is denied.
Displaying a List of all Sessions
To display a list of all sessions for a system, enter /o in the transaction

field. The following dialog box appears:

Creating a New Session
The system administrator specifies the maximum number of sessions (from 2 to

6) you can have opened at any one time. Each session you create is as if you
logged on to the system again. Each session is independent of the others. An
operation on one session (for example, closing it) does not cause the affect the
other sessions.
Too many open sessions can result in slower system performance. Therefore, your
system administrator may limit the number of sessions you can create to fewer
than six.
To create a new session from anywhere in the system:
o Choose System -> Create session from the menu bar, or
o Choose
The system opens an additional window. The new session becomes the active
session and remains the active session unless you click on a different (open or
new) session.
Each session has a session number. It is part of the system information in

the status bar and is located next to the transaction name.
Closing Sessions

After you have finished using a session, it is a good idea to end it. Each session
uses system resources that can affect how fast the SAP System responds to your
requests.
If you have only one session open and you end it, you will log off from the
system. However, before logging you off, the system prompts you to save your
data.
Before you end a session, save any data you want to keep. When you end a
session, the system does NOT prompt you to save your data.
You can close a session in the following ways:
o Choose System -> End session
o Click on in the right hand corner of the active session.

o Enter /i in the transaction field of the session you want to close
o To close a specific session enter /i followed by the number of the session
you want to close in the transaction field of any of the sessions. For
example, /i3 to close the third session.
You can close all the sessions at once in two ways:
o Enter /nend in the transaction field.

o Enter /nex in the transaction field.
The difference between the two commands is that /nend prompts you to
confirm that you want to close all the sessions whereas /nex closes all the
sessions without prompting.
Adjusting the Local Layout Options
Choose -> Options -> (tab) Options to change the following settings:

o Quick Info
o Messages
o System
o Dynpro Size Check
o List Links Visualization
You make these changes using the following dialog box:
Information about the Front End
For version information about the front end chose -> About... The
following dialog box is displayed:


CHAPTER-5
TRANSACTION CODES IN SAP

SAP System Administration
Relevant Transaction Codes
Transaction Codes Explanation
AL08 List of All Users Logged On
RZ20 CCMS Monitor Sets
SA38 ABAP Program Execution
SCC4 Display View "Clients"
SE11 ABAP Dictionary
SE16 Data Browser
SE38 ABAP Editor
SE80 Object Navigator (ABAP Workbench)
SE93 Maintain Transaction
SLICENSE SAP License Administration

SM02 System Messages
SM04 User List
SM12 Select Lock Entries
SM13 Update Requests
SM21 System Log
SM28 SAP Initial Consistency Check
SM31 Maintain Table Views
SM37 Simple Job Selection
SM50 Process Overview
SM51 SAP Servers
SM66 Global Work Process Overview
SMLT Language Management
SR13 Administration of the SAP Library
SU01 User Maintenance
Software Logistics
SAINT Add-On Installation Tool
SE01 Transport Organizer (Extended View)
SE03 Transport Organizer Tools
SE09 Transport Organizer
SPAM Support Package Manager
SPAU Modification Adjustment

SPDD Modification Adjustment Dictionary
SPRO Customizing: Execute Project
SPRO_ADMIN Customizing: Project Administration
STMS Transport Management System
Client Administration
Transaction Codes Explanations
BDLS Tool: Conversion of Logical System Names
SCC1 Copy by Transport Request
SCC3 Client Copy / Transport Log Analysis
SCC4 Display View "Clients"
SCC7 Post-Client Import Methods
SCC8 Client Export
SCC9 Remote Client Copy
SCCL Local Client Copy
SCMP View / Table Comparison
SCU0 Customizing Cross-System Viewer
SE01 Transport Organizer (Extended View)
STMS Transport Management System
User & Authorization
Transaction Codes Explanations

BD82 Generate Partner Profile
LICENSE_ADMIN License Administration Workbench
PFCG Profile Generator / Role Maintenance
SCUG Central User Administration - Transfer Users
SM19 Security Audit: Administer Audit Profile
SM20 Analysis of Security Audit Log
SU01 User Maintenance
SU05 Maintain Internet User
SU10 User Maintenance: Mass Changes
SU21 Maintain Authorization Objects
SU24 Maintain Assignment. of Authorization

Objects
SU25 Profile Generator: Upgrade / First Install.
SU3 Maintain User Profile
SU53 Display Authorization Data for User
SUCOMP User Company Address Maintenance
SUGR Maintain User Groups
USMM System Measurement
_ Default User:
"SAP*" in Client 000 & 001, Initial Password "06071992"

"DDIC" in Client 000 & 001, Initial Password "19920706"
"EARLYWATCH" in Client 066, Initial Password "support"
Background Processing

RZ01 Job Scheduling Monitor
RZ04 CCMS: Maintain Operation Modes/Instances
SM36 Define Background Job
SM37C Extended Job Selection
SM49 External Operating System Commands
SM61 Background Controller List
SM62 Event History
SM64 Background Events
SM65 Analysis Tool - Background Processing
SM69 External Operating System Commands
SMX Job Overview
Update
SM12 Lock Entries
SM13 Update Requests
SM14 Update Program Administration

Output Configuration & Administration
SPAD Spool Administration
SP01 Output Controller: Spool Request Selection
SP12 TemSe - Admin. Of Temp. Sequential Data
Data Archiving
AOBJ View Cluster Maintenance
DB15 Tables and Archiving Objects
FILE Logical File Path Definition
OAAD Archive Link: Admin. of Stored Documents
OAC0 Content Repositories
OAM1 Archive Link: Monitor
SARA Archive Administration
SARI Archive Info System: Central Management
SF01 Logical File Names, Client-Specific

Data Transfer & Exchange
BAPI BAPI Explorer
BD73 Error Handling for Non-Posted IDocs
BD82 Generate Partner Profile
BDM2 IDocs Tracing
BMV0 Manage Data Transfer
IDOC IDocs and EDI Basis: Repair & Check
RZ12 RFC Server Group Maintenance
SCOT SAP Connect: Administration
SHDB Transaction Recorder: Recording Overview
SM35 Batch Input: Session Overview
SM58 Transactional RFC
SM59 Configuration of RFC Connections
SMQ1 qRFC Monitor - Outbound Queue
SMQ2 qRFC Monitor - Inbound Queue
SMQR qRFC Monitor - QIN Scheduler
SMT1 Display and Maintain Trusted Systems
SOST SAP Connect: Transmission Requests
SXDA Data Transfer Workbench
WE05 IDOC List
WE21 Ports in IDocs Processing
Instance Maintenance

RZ03 Server Statuses and Alerts
RZ04 Maintain Operation Modes and Instances
RZ10 Edit Profiles
RZ11 Maintain Profile Parameters
RZ12 RFC Server Group Maintenance
SM63 Display/Maintain Operation Mode Set
SMGW Gateway Monitor / Active Connections
SMLG Maintain Logon Groups
SMMS Message Server Monitor
System Monitoring
AL08 List of All Users Logged On
AL11 SAP-Directories
DB13 DBA Cockpit: System Config. Maintenance
DB24 Logs for Administrative Database Operations
OS03 Parameter Changes in Operation System
OS07 Operation System Monitor
SM04 User List
SM12 Select Lock Entries

SM14 Update Program Administration
SM21 System Log: Local Analysis
SM35 Batch Input: Session Overview
SM51 SAP Servers
SM58 Transactional RFC
SM66 Global Work Process Overview
SMGW Gateway Monitor / Active Connections
SMICM ICM Monitor
SMMS Message Server Monitor
SMQ1 qRFC Monitor - Outbound Queue
SMQ2 qRFC Monitor - Inbound Queue
SP01 Output Controller: Spool Request Selection
SSAA Administrative Activities
ST01 System Trace
ST02 Tune Summary
ST03, ST03N Workload Monitor
ST04 Maintain Database Integration
ST05 Performance Analysis
ST06 Operation System Monitor
ST07 Application Monitor: User Distribution
ST10 Table Call Statistics
ST11 Error Log Files

ST22 ABAP Runtime Error
ST30 Global Performance Analysis
STAD SAP Workload: Business Transact. Analysis
TU02 Parameter Changes in SAPSYSTEM
Monitoring Architecture
AL15 SAPOSCOL Destination
OS07 Operating System Monitor
RZ04 Maintain Operation Modes and Instances
RZ21 Monitoring: Properties and Methods
SE91 Message Maintenance
SE92 System Log Message Maintenance
ST02 Tune Summary
SM21 System Log: Local Analysis

CHAPTER-6
INTRODUCTION TO ABAP WORKBENCH


ABAP (Advanced Business Application Programming, originally
Allgemeiner Berichts-Aufbereitungs-Prozessor = general report creation
processor) is a high level programming language created by the German
software company SAP. It is currently positioned, alongside the more recently
introduced Java, as the language for programming SAP's Web Application Server,
part of its Net Weaver platform for building business applications. Its syntax is
somewhat similar to COBOL.
ABAP is one of the many application-specific fourth-generation languages (4GLs)

first developed in the 1980s. It was originally the report language for SAP R/2, a
platform that enabled large corporations to build mainframe business applications
for materials management and financial and management accounting.
ABAP used to be an abbreviation of Allgemeiner Berichtsaufbereitungsprozessor,

the German meaning of "generic report preparation processor", but was later
renamed to Advanced Business Application Programming. 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.
The ABAP programming language was originally used by developers to develop

the SAP R/3 platform. 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.
ABAP remains the language for creating programs for the client-server R/3
system, which SAP first released in 1992. As computer hardware evolved through
the 1990s, more and more of SAP's applications and systems were written in
ABAP. By 2001, all but the most basic functions were written in ABAP. In 1999,

SAP released an object-oriented extension to ABAP called ABAP Objects, along
with R/3 release 4.6.
SAP's most recent development platform, Net Weaver, supports both ABAP and
Java.
Where does the ABAP program run?
All ABAP programs reside inside the SAP database. They are not stored in
separate external files like Java or C++ programs. In the database all ABAP code
exists in two forms: source code, which can be viewed and edited with the ABAP
Workbench tools, and generated code, a binary representation somewhat
comparable with Java byte code. ABAP programs execute under the control of the
runtime system, which is part of the SAP kernel. The runtime system is
responsible for processing ABAP statements, controlling the flow logic of screens
and responding to events (such as a user clicking on a screen button). A key
component of the ABAP runtime system is the Database Interface, which turns
database-independent ABAP statements ("Open SQL") into statements understood
by the underlying DBMS ("Native SQL"). The database interface handles all the
communication with the relational database on behalf of ABAP programs; it also
contains extra features such as buffering of frequently accessed data in the local
memory of the application server.
SAP has three different layers as presentation layer (GUI), application layer
(programs run on this) and data base layer where all data is stored and retrieved
from user driven conditions, commands given by end user programmer through
presentation layer.
The ABAP language environment, including the syntax checking, code generation
and runtime system, is part of the SAP Basis component. SAP Basis is the
technological platform that supports the entire range of SAP applications, now
typically implemented in the framework of the SAP Web Application Server. In
that sense SAP Basis can be seen as the "operating system" on which SAP
applications run. Like any operating system, SAP Basis contains both low-level

services (for example memory management, database communication or
servicing Web requests) and high-level tools for end users and administrators.
These tools can be executables ("SAP kernel") running directly on the underlying
operating system, transactions developed in ABAP, or Web-based interfaces.
Installations of the Web Application Server (landscapes) typically consist of three

systems: one for development, one for testing and quality assurance, and one for
production. The landscape may contain more systems, e.g. separate systems for
unit testing and pre-production testing, or it may contain fewer, e.g. only
development and production, without separate QA; nevertheless three is the most
common configuration. ABAP programs are created and undergo first testing in
the development system. Afterwards they are distributed to the other systems in
the landscape. These actions take place under control of the Change and
Transport System (CTS), which is responsible for concurrency control (e.g.
preventing two developers from changing the same code at the same time),
version management and deployment of programs on the QA and production
systems.
The Web Application Server consists of three layers: the database layer, the
application layer and the presentation layer. These layers may run on the same or
on different physical machines. The database layer contains the relational
database and the database software. The application layer contains the instance
or instances of the system. All application processes, including the business
transactions and the ABAP development, run on the application layer. The
presentation layer handles the interaction with users of the system. Online access
to ABAP application servers can go via a proprietary graphical interface, the
SAPGUI, or via a Web browser.
A transaction in SAP terminology is the execution of a program. The normal way
of executing ABAP code in the SAP system is by entering a transaction code
(for instance, SE80 is the code for the ABAP workbench). Transactions can
be accessed via system-defined or user-specific, role-based menus. They can also
be started by entering their transaction code (a mnemonic name of up to 20

characters) in the special command field, which is present in every SAP screen.
Transactions can also be invoked programmatically by means of the ABAP
statements CALL TRANSACTION and LEAVE TO TRANSACTION. Transaction codes
can also be linked to screen elements or menu entries. Selecting such an element
will start the transaction. The term "transaction" must not be misunderstood here:
in the context just described, a transaction simply means calling and executing an
ABAP program. In application programming, "transaction" often refers to an
indivisible operation on data, which is either committed as a whole or undone
(rolled back) as a whole. This concept exists in SAP but is there called a LUW
(Logical Unit of Work). In the course of one transaction (program execution),
there can be different LUWs.
Dialog transaction
These are the most common kind of transactions. The transaction code of a dialog
transaction is linked to a Dynpro of an ABAP program. When the transaction is
called, the respective program is loaded and the Dynpro is called. Therefore, a
dialog transaction calls a Dynpro sequence rather than a program. Only during the
execution of the Dynpro flow logic are the dialog modules of the ABAP program
itself are called. The program flow can differ from execution to execution. You can
even assign different dialog transaction codes to one program.
Parameter transaction
In the definition of a parameter transaction code, a dialog transaction is linked
with parameters. When you call a parameter transaction, the input fields of the
initial Dynpro screen of the dialog transaction are filled with parameters. The
display of the initial screen can be inhibited by specifying all mandatory input
fields as parameters of the transaction.
Variant transaction
In the definition of a variant transaction code, a dialog transaction is linked with a
transaction variant. When a variant transaction is accessed, the dialog transaction
is called and executed with the transaction variant. In transaction variants, you
can assign default values to the input fields on several Dynpro screens in a

transaction, change the attributes of screen elements, and hide entire screens.
Transaction variants are maintained in transaction SHD0.
Report transaction
A report transaction is the transaction code wrapping for starting the reporting
process. The transaction code of a report transaction must be linked with the
selection screen of an executable program. When you execute a report
transaction, the runtime environment internally executes the ABAP statement
SUBMIT.
Object oriented transaction
A new kind of transaction as of release 6.10. The transaction code of an OO
transaction is linked with a method of a local or global class. When the transaction
is called, the corresponding program is loaded, for instance methods an object of
the class is generated and the method is executed.
Types of ABAP programs

In ABAP, there are two different types of programs:
Report programs
A Sample Report
Report programs follow a relatively simple programming model whereby a user
optionally enters a set of parameters (e.g. a selection over a subset of data) and
the program then uses the input parameters to produce a report in the form of an
interactive list. The output from the report program is interactive because it is not

a passive display; instead it enables the user, through ABAP language constructs,
to obtain a more detailed view on specific data records via drill-down functions, or
to invoke further processing through menu commands, for instance to sort the
data in a different way or to filter the data according to selection criteria. This
method of presenting reports has great advantages for users who must deal with
large quantities of information and must also have the ability to examine this
information in highly flexible ways, without being constrained by the rigid
formatting or unmanageable size of "listing-like" reports. The ease with which
such interactive reports can be developed is one of the most striking features of
the ABAP language.
The term "report" is somewhat misleading in the sense that it is also possible to
create report programs that modify the data in the underlying database instead of
simply reading it.
A customized screen created using Screen Painter, which is one of the tools
available in ABAP workbench (T-code = SE51).
Online programs
Online programs (also called module pools) do not produce lists. These programs
define more complex patterns of user interaction using a collection of screens. The
term “screen” refers to the actual, physical image that the user sees. Each screen
also has” flow logic”; this refers to the ABAP code invoked by the screens, i.e. the
logic that initializes screens, responds to a user’s requests and controls the
sequence between the screens of a module pool. Each screen has its own Flow

Logic, which is divided into a "PBO" (Process before Output) and "PAI" (Process
after Input) section. In SAP documentation the term “Dynpro” (dynamic program)
refers to the combination of the screen and its Flow Logic.
Online programs are not invoked directly by their name, but are associated with a
transaction code. Users can then invoke them through customizable, role-
dependent, transaction menus.
Apart from reports and online programs, it is also possible to develop sharable
code units such as class libraries, function libraries and subroutine pools.
Subroutine pools
Subroutine pools, as the name implies, were created to contain collections of
subroutines that can be called externally from other programs. Before release
6.10, this was the only way subroutine pools could be used. But besides
subroutines, subroutine pools can also contain local classes and interfaces. As of
release 6.10, you can connect transaction codes to methods. Therefore, you can
now also call subroutine pools via transaction codes. This is the closest to a Java
program you can get in ABAP: a subroutine pool with a class containing a method
– say – main connected to a transaction code!
Function pools
Function pools, more commonly known as "function groups", are libraries of
functions developed in ABAP. Functions differ from subroutines in that they are
self-contained and do not belong to a specific program. ABAP functions accept as
input any number of input parameters; return as output any number of output
parameters, and raise exceptions if an error condition occurs.
Functions are invoked in ABAP programs by means of the CALL FUNCTION
statement. A very important feature of ABAP is the ability to call function modules
in another SAP system or in an external application using the RFC (Remote
Function Call) mechanism. It is also possible to call functions asynchronously; the
ABAP program then does not wait for the function to return but instead continues
immediately, while the function executes in a separate context.
Type pools
Type pools are the precursors to general type definitions in the ABAP Dictionary.
Before release 4.0, only elementary data types and flat structures could be

defined in the ABAP Dictionary. All other types that should’ve been generally
available had to be defined with TYPES in type pools. As of release 4.0, type pools
were only necessary for constants. As of release 6.40, constants can be declared
in the public sections of global classes and type pools can be replaced by global
classes.
Class pools
Class pools serve as containers for exactly one global class. Besides the global
class, they can contain global types and local classes/interfaces to be used in the
global class. A class pool is loaded into memory by using one of its components.
For example, a public method can be called from any ABAP program or via a
transaction code connected to the method. You maintain class pools in the class
builder.
Interface pools
Interface pools serve as containers for exactly one global interface—nothing more
and nothing less. You use an interface pool by implementing its interface in
classes and by creating reference variables with the type of its interface. You
maintain interface pools in the class builder.
ABAP workbench
The ABAP Workbench contains different tools for editing Repository objects. These
tools provide you with a wide range of assistance that covers the entire software
development cycle. The most important tools for creating and editing Repository
objects are:
ABAP Editor for writing and editing program code

ABAP Dictionary for processing database table definitions and retrieving global
types.
Menu Painter for designing the user interface (menu bar, standard toolbar,
application toolbar, function key assignment). Screen Painter for designing screens
(dynamic programs) for user dialogs
Function Builder for displaying and processing function modules (routines with

defined interfaces that are available throughout the system)
Class Builder for displaying and processing ABAP Objects classes
The ABAP dictionary
The ABAP Dictionary is a fully integrated data environment controlling facility. It
contains all definitions for Domains, Data Elements, Structures, Tables, Views,
Search Helps, Lock Objects, Match code Objects, The Table Maintenance
Generator, and the Table Description Generator.
With these objects in its repository, the ABAP Dictionary:
 Enforces data integrity
 Manages data definitions without redundancy
 Is tightly integrated with the rest of the ABAP/4 Development
Workbench.
Enforcing data integrity is the process of ensuring that data entered into the
system is logical, complete, and consistent. When data integrity rules are defined
in the ABAP/4 Dictionary, the system automatically prevents the entry of invalid
data. Defining the data integrity rules at the dictionary level means they only
have to be defined once, rather than in each program that accesses that data.
The following are examples of data lacking integrity:

A date field with a month value of 13.
An order assigned to a customer number that doesn’t exist.
An order not assigned to a customer.
Managing data definitions without redundancy is the process of linking similar
information to the same data definition. For example, a customer database is
likely to contain a customer’s ID number in several places. The ABAP Dictionary
provides the capability of defining the characteristics of a customer ID number in
only one place. That central definition then can be used for each instance of a
customer ID number.
The ABAP Dictionary’s integration with the rest of the development environment
enables ABAP programs to automatically recognize the names and characteristics
of dictionary objects.

Additionally, the system provides easy navigation between development objects
and dictionary definitions. For example, as a programmer, you can double-click on
the name of a dictionary object in your program code, and the system will take
you directly to the definition of that object in the ABAP/4 Dictionary.
When a dictionary object is changed, a program that references the changed
object will automatically reference the new version the next time the program
runs. Because ABAP is interpreted, it is not necessary to recompile programs that
reference changed dictionary objects.
ABAP syntax
This brief description of the ABAP syntax begins inevitably with the ubiquitous
"Hello World" program.
"Helloworld"
PROGRAM TEST.
WRITE 'Hello World'.
This example contains two statements, one on each line. The keywords are
PROGRAM and WRITE. The program displays a list on the screen. In this case, the
list consists of the line "Hello World".
White space significance

ABAP has no format restrictions. You can enter statements in any format, so a
statement can be indented, you can write several statements on one line, or
spread a single statement over several lines. The only requirement is that every
statement ends in a period.
You must separate words within a statement with at least one space. The system
also interprets the end of line marker as a space.
The two-line "Hello World" program from above could also be written as
PROGRAM TEST. WRITE 'Hello World' .
or even as:
PROGRAM

TEST.
WRITE
'Hello World'.
Free formatting is convenient, but with complex code, such as deeply nested
IF/ELSE blocks, it can get tricky. The ABAP editor therefore offers a "Pretty
Printer" function, which can take care of proper indentation.
One obvious exception to the free-formatting rule are text literals. A text literal is
a sequence of alphanumeric characters in the program code enclosed in single
quotes. If a text literal in an ABAP statement extends across more than one line,
then a ‘&’ character must be used to combine a succession of text literals into a
single one. Example:
USERPROMPT = 'Please double-click on a line in the output list ' & 'to see the
complete details of the transaction.
Case sensitivity
ABAP statements are not case-sensitive. The following code is perfectly
permissible:
proGRAm TEsT.
WriTe 'Hello World'.
Users can configure the way source text is presented (all upper case, all lower
case, ABAP keywords in upper case and variable names in lower case, etc.)
according to their own preference. Typically the keywords are in upper case and
every thing else (variable, function, method, and class names) in lower case.
Chained statements
The ABAP programming language allows you to concatenate consecutive
statements with an identical first part into a chain statement.
To concatenate a sequence of separate statements, write the identical part only
once and place a colon (:) after it. After the colon, write the remaining parts of
the individual statements, separating them with commas. Ensure that you place a
period (.) after the last part to inform the system where the chain ends.
Chaining is very often used in WRITE statements. WRITE accepts just one
argument, so if for instance you wanted to display three fields from a structure
called FLIGHTINFO, you would have to code:

WRITE FLIGHTINFO-CITYFROM.
WRITE FLIGHTINFO-CITYTO.
WRITE FLIGHTINFO-AIRPTO.
Chaining the statements results in a more readable and more intuitive form:
WRITE: FLIGHTINFO-CITYFROM, FLIGHTINFO-CITYTO, FLIGHTINFO-AIRPTO.
In the chain, a colon separates the beginning of the statement from the variable
parts. After the colon or commas, you can insert any number of spaces.
You could, for example, write the same statement like this:
WRITE: FLIGHTINFO-CITYFROM,
FLIGHTINFO-CITYTO,
FLIGHTINFO-AIRPTO.
In a chain statement, the first part (before the colon) is not limited to the
keyword of the statements. For example, the code
SUM = SUM + 1.
SUM = SUM + 2.
SUM = SUM + 3.
SUM = SUM + 4.
could be written in chained form:
SUM = SUM + : 1, 2, 3, 4.
Comments
ABAP has 2 ways of defining text as a comment.
An asterisk (*) in the leftmost column of a line makes that line a comment. A
double quotation mark (>>"<<) anywhere on a line makes the rest of that line a
comment.
Example
***************************************
** Program: BOOKINGS **
** Author: Joe Byte, 07-Jul-2007 **
***************************************
REPORT BOOKINGS.

* Read flight bookings from the database
SELECT * FROM FLIGHTINFO
WHERE CLASS = 'Y' "Y = economy
OR CLASS = 'C'. "C = business
(...)
Naming notation
This list is incomplete; you can help by expanding it.
ABAP has a large number of naming conventions for different language elements.
These are conventions and not rules, so an ABAP programmer is free to abide by
them or not. However ABAP code developed by SAP itself generally respects these
naming rules. Below is a list.
ALV_* Advance list viewer
AS_* Methods that perform type conversions
CHECK_* Check Methods
CH_* Changing Parameters
CL_* Class name
CO_*/C_* Constants
DR_* Data reference
G_* Global variables/data objects
GT_* Global table
GX_* Global boolean field (X or space)
IF_* Interface
INT_*/IT_ Internal Table
IS_* Methods that return a Boolean value
L_* Indicates the data object is local. Often, before underscore, put a 'type letter'
in case of simple type (LC_,LF etc.)
LC_* Local Constant
LR_* Local Range
LT_* Local Table
LVC_* List Viewer Control
ON_* Event handler
PA_* Parameters

PE_*/EX_* Export parameter
PI_*/IM_* Input parameter
RA_* Ranges/Type Range Of
RE_* Result
RF_* Reference Variable
SET_* Accessors Methods
SO_* Select-Options
ST_* Structure
TA_* Internal Standard Table
TC_* Table Control
TH_* Internal Hashed Table
TP_* Other Variables
TS_* Internal Sorted Table
TT_* Table type
TY_* Types
T_* Variable is a table (T_MY_TABLE_VARIABLE)
X* Source/first data object (e.g. XVBAK)
Y* Destination/second data object (e.g. YVBAK)
WA_* Working Area
** Secondary working area (e.g. *VBAK in TABLES statement. Obsolete)
DATA and TYPES
It is a special strength of ABAP that you can define a great variety of data types
and objects that span the spectrum from very elementary data types to very
complex and dynamic types. Consequently, the subject of ABAP declarations is
quite extensive.
ABAP accepts all data types defined in the SAP dictionary or in Type Pools. Types
can also be defined inside the program itself. Object numeric (I for integer, F for
floating point), packed decimal (P), character (C or N, where the N type is used
for numeric strings that can be used in computation) or hexadecimal (X). Date
fields (type D) and time fields (type T) have a "dual" nature; in an input/output
context they behave like strings, but in a computational context they are numeric
integers. This makes date and time calculations extremely easy. For example:

DATESENT = '20070901'.
VALIDTO = DATESENT + 60.
WRITE: 'Offer is valid until', VALIDTO DD/MM/YYYY.
In this example, a string literal representing September 1, 2007 is assigned to
DATESENT. DATESENT is then used in a numeric calculation to produce another
data field, VALIDTO. VALIDTO is then output as a string. The optional
"DD/MM/YYYY" modifier displays the date in a predefined format, here
"31/10/2007". Without the modifier the date would display as "20071031".

Data and Types

All ABAP variables must be explicitly declared in order to be used. The convention
is for all declarations to be at the top of the program, or subroutine. The
declaration consists of the name, type, length (where applicable), additional
modifiers (e.g. the number of implied decimals for a packed decimal field) and
optionally an initial value:

* Primitive types:
DATA: COUNTER TYPE I,
VALIDITY TYPE I VALUE 60,
TAXRATE(3) TYPE P DECIMALS 1,
LASTNAME(20) TYPE C.
* Dictionary types:
DATA: ORIGIN TYPE COUNTRY.
* Internal table:
DATA: T_FLIGHTS TYPE TABLE OF FLIGHTINFO,
T_LOOKUP TYPE HASHED TABLE OF FLT_LOOKUP.
* Objects:
DATA: BOOKING TYPE REF TO CL_FLT_BOOKING.
Notice the use of the colon to chain together consecutive DATA statements.
ABAP Objects
Object orientation in ABAP is an extension of the ABAP language that makes
available the advantages of object-oriented programming, such as encapsulation,
interfaces, and inheritance. This helps to simplify applications and make them
more controllable.
ABAP Objects is fully compatible with the existing language, so you can use
existing statements and modularization units in programs that use ABAP Objects,
and can also use ABAP Objects in existing ABAP programs. Note, however, that
syntax checking is stronger in ABAP Objects programs, and some syntactical
forms (usually older ones) of certain statements are not permitted.
ABAP statements – an overview
The first element of an ABAP statement is the ABAP keyword. This determines the
category of the statement. The different statement categories are as follows:
Declarative statements

These statements define data types or declare data objects which are used by the
other statements in a program or routine. The collected declarative statements in
a program or routine make up its declaration part.
Examples of declarative keywords:
TYPES, DATA, TABLES
Modularization statements
These statements define the processing blocks in an ABAP program.
The modularization keywords can be further divided into:
· Event Keywords
You use statements containing these keywords to define event blocks. There are
no special statements to conclude processing blocks - they end when the next
processing block is introduced.
Examples of event keywords are:
AT SELECTION SCREEN, START-OF-SELECTION, AT USER-COMMAND
· Defining keywords
You use statements containing these keywords to define subroutines, function
modules, dialog modules and methods. You conclude these processing blocks
using the END- statements.
Examples of definitive keywords:
FORM ..... ENDFORM, FUNCTION ... ENDFUNCTION, MODULE ... ENDMODULE.
Control statements
You use these statements to control the flow of an ABAP program within a
processing block according to certain conditions.
Examples of control keywords:
IF, WHILE, CASE
Call statements
You use these statements to call processing blocks that you have already defined
using modularization statements. The blocks you call can either be in the same
ABAP program or in a different program.
Examples of call keywords:
CALL METHOD, CALL TRANSACTION, SUBMIT, LEAVE TO
Operational statements

These keywords process the data that you have defined using declarative
statements.
Examples of operational keywords:
MOVE, ADD
Unique concept of internal table in ABAP
Internal tables provide a means of taking data from a fixed structure and storing
it in working memory in ABAP. The data is stored line by line in memory, and each
line has the same structure. In ABAP, internal tables fulfill the function of arrays.
Since they are dynamic data objects, the programmer is saved the task of
dynamic memory management in his or her programs. Internal tables should be
used whenever there is a need to process a dataset with a fixed structure within a
program. A particularly important use for internal tables is for storing and
formatting data from a database table within a program. They are also a good
way of including very complicated data structures in an ABAP program.
Like all elements in the ABAP type concept, internal tables can exist both as data
types and as data objects. A data type is the abstract description of an internal
table, either in a program or centrally in the ABAP Dictionary, that you use to
create a concrete data object. The data type is also an attribute of an existing
data object.
Internal tables as data types
Internal tables and structures are the two structured data types in ABAP. The data
type of an internal table is fully specified by its line type, key, and table type.
Line type
The line type of an internal table can be any data type. The data type of an
internal table is normally a structure. Each component of the structure is a column
in the internal table. However, the line type may also be elementary or another
internal table.
Line Type can also refer to an ABAP Object's reference pointer value. If two ABAP
Objects are not related, they do not have the same line type. The line type is
stored in the value of the reference pointer and can be viewed in the debugger. If
one object attempts to access another unrelated object's components, you will
receive an error specifying that the line types do not match.

Key
The key identifies table rows. There are two kinds of key for internal tables - the
standard key and a user-defined key. You can specify whether the key is UNIQUE
or NON-UNIQUE. Internal tables with a unique key cannot contain duplicate
entries with the same key. The uniqueness depends on the table access method.
If a table has a structured line type, its default key consists of all of its non-
numerical columns that are not references or themselves internal tables. If a table
has an elementary line type, the default key is the entire line. An internal table
which has a line type that is itself an internal table, has an empty key.
The user-defined key can contain any columns of the internal table that are not
references or themselves internal tables. Internal tables with a user-defined key
are called key tables. When you define the key, the sequence of the key fields is
significant. You should remember this, for example, if you intend to sort the table
according to the key.
Later versions of ABAP permit the definition of secondary keys.
Table type
The table type determines how ABAP will access individual table entries. Internal
tables can be divided into three types:
Standard tables have an internal linear index. (Think of index as "record number".
It is not to be confused with a database index, for example). From a particular
size upwards, the indexes of internal tables are administered as trees. In this
case, the index administration overhead increases in logarithmic and not linear
relation to the number of lines. 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 table. The key of a standard table is always non-unique.
You cannot specify a unique key. This means that standard tables can always be
filled very quickly, since the system does not have to check whether there are
already existing entries.
Sorted tables are always saved sorted by the key. They also have an internal
index. 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. When you define the table, you must specify
whether the key is to be unique or not. Standard tables and sorted tables are
known generically as index tables.
Hashed tables have no linear index. You can only access a hashed table 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. When you define the table, you must
specify the key as UNIQUE.
Generic internal tables
Unlike other local data types in programs, you do not have to specify the data
type of an internal table fully. Instead, you can specify a generic construction, that
is, the key or key and line type of an internal table data type may remain
unspecified. You can use generic internal tables to specify the types of field
symbols and the interface parameters of procedures. You cannot use them to
declare data objects.
Internal tables as dynamic data objects
Data objects that are defined either with the data type of an internal table, or
directly as an internal table, are always fully defined in respect of their line type,
key and access method. However, the number of lines is not fixed. Thus internal
tables are dynamic data objects, since they can contain any number of lines of a
particular type. The only restriction on the number of lines an internal table may
contain are the limits of your system installation. The maximum memory that can
be occupied by an internal table (including its internal administration) is 2
gigabytes. A more realistic figure is up to 500 megabytes. An additional restriction
for hashed tables is that they may not contain more than 2 million entries. The
line types of internal tables can be any ABAP data types - elementary, structured,
or internal tables. The individual lines of an internal table are called table lines or
table entries. Each component of a structured line is called a column in the
internal table.
Choosing a table type
The table type (and particularly the access method) that you will use depends on
how the typical internal table operations will be most frequently executed.

Standard tables
This is the most appropriate type if you are going to address the individual table
entries using the index. Index access is the quickest possible access. You should
fill a standard table by appending lines (ABAP APPEND statement), and read,
modify and delete entries by specifying the index (INDEX option with the relevant
ABAP command). The access time for a standard table increases in a linear
relationship with the number of table entries. If you need key access, standard
tables are particularly useful if you can fill and process the table in separate steps.
For example, you could fill the table by appending entries, and then sort it. If you
use the binary search option with key access, the response time is logarithmically
proportional to the number of table entries.
Sorted tables
This is the most appropriate type if you need a table which is sorted as you fill it.
You fill sorted tables using the INSERT statement. Entries are inserted according
to the sort sequence defined through the table key. Any illegal entries are
recognized as soon as you try to add them to the table. The response time for key
access is logarithmically proportional to the number of table entries, since the
system always uses a binary search. Sorted tables are particularly useful for
partially sequential processing in a LOOP if you specify the beginning of the table
key in the WHERE condition.
Hashed tables:
This is the most appropriate type for any table where the main operation is key
access. You cannot access a hashed table using its index. The response time for
key access remains constant, regardless of the number of table entries. Like
database tables, hashed tables always have a unique key. Hashed tables are
useful if you want to construct and use an internal table which resembles a
database table or for processing large amounts of data.
Batch input: concepts
Processing sessions

The above figure shows how a batch input session works.

A batch input session is a set of one or more calls to transactions along with the
data to be processed by the transactions. The system normally executes the
transactions in a session non-interactively, allowing rapid entry of bulk data into
an R/3 System.
A session records transactions and data in a special format that can be interpreted
by the R/3 System. When the System reads a session, it uses the data in the
session to simulate on-line entry of transactions and data. The System can call
transactions and enter data using most of the facilities that are available to
interactive users.
For example, the data that a session enters into transaction screens is subject to
the same consistency checking as in normal interactive operation. Further, batch
input sessions are subject to the user-based authorization checking that is
performed by the system.
There are three batch input methods:

(1) In the Direct Input Method, the programs are provided by the SAP system.
These programs are available for Standard Applications. Under this method, the
data base is updated using a Function Module, which is responsible for executing
the appropriate consistency checks.
(2) In the Call Transaction Method, the ABAP Program reads the external data
which is present on the Application or Presentation Server, and uses the ABAP
Statement CALL TRANSACTION USING to run a SAP statement.
(3) In the Session Method the program reads the data and the SAP system stores
the data in a "Batch Input Session". The session records the actions that are
required to transfer data into the system using normal SAP transactions.
Other Features
ABAP Objects ABAP uses object-oriented interfaces.
Sharing Data: With ABAP shared objects, you can aggregate data in memory
once at a central location. Different users and programs can then access this data
without the need for copying.
Exception Handling: With the class-based exception concept of ABAP, you can
define a special control flow for a specific error situation and provide the user with
information about the error.
Developing Persistency: For permanent storage of data in ABAP, you use
relational database tables by means of database-independent Open SQL, which is
integrated in ABAP. However, you can also store selected objects transparently or
access the integrated database or other databases using proprietary SQL.
Connectivity and Interoperability: The Exchange Infrastructure and Web
services are the means by which developers can implement a service-oriented
architecture. With Web services, you can provide and consume services
independently of implementation or protocol. Furthermore, you can do so within
NetWeaver and in the communication with other systems. With the features of the
Exchange Infrastructure, you can enable, manage, and adapt integration
scenarios between systems.
Making Enhancements: With the Enhancement Framework, you can enhance
programs, function modules, and global classes without modification as well as

replace existing code. The Switch Framework enables you activate only specific
development objects or enhancements in a system.

CHAPTER-7
SAP SECURITY AND

AUTHORIZATION ADMINISTRATION

SAP Security and Authorization Administration
Introduction
SAP has done nothing less than change the entire systems landscape for
enterprises. The benefits it can bring have led to widespread adoption across the
globe. One of the key benefits SAP brings to an enterprise is the ability to
integrate the data both within the enterprise, and between it and its partner’s
competitors. In many cases organizations today are both partners and
competitors at the same time. Think of wholesalers and distributors, SAP and
Oracle, AT&T and BT, or two oil giants who have an upstream joint venture. These
companies use SAP to integrate process between themselves for their mutual
benefit. This ability to integrate, however, brings with it a particular risk – that of
exposing their data to the un-authorized outside world.
Entire companies have been built up around highly guarded intellectual property
and process secrets ... and could easily fall if this was breached. Therefore,
keeping the security of the organization intact is one of the vital aspects of any
SAP implementation.
SAP BASIS addresses all security issues by incorporating an authorization module.

With increased potential for security breaches in the computer systems around
the world, BASIS consultants face a tough task of maintaining the integrity and
administering the security of SAP systems. Interoperability features of a SAP
system makes this task a bit more difficult.
SAP Security Components – The Big Picture

SAP security in an integrated environment can be viewed in the form of discrete
components as shown below

Tight security is required for each of the above components (Network,

Workstation, Operating System and Database) as a breach made in one area can
compromise the entire system. The scope of this article is SAP Application
Security, which can be achieved with the help of SAP’s BASIS security application
through the concept of authorization.
In SAP, security is administered for objects (profiles and authorizations). Users are
only authorized to see or change the parts of the system required by their
respective job responsibilities.
SAP Authorization Concept

The SAP authorization concept is based upon the logical relationship between a
user ID and the range of system authorizations with which it can be associated.
The architecture of the authorization system is based upon the utilization of
several individuals but related logical components: Profiles, Objects, Fields, and
Authorizations. The user ID refers exclusively to profiles. Each profile grants a set
of specific system access authorizations to user. Figure illustrates the hierarchical
authorization concept in SAP.

Figure
Composite Profiles
Composite profiles refer to the various employee roles available in the corporation
(for instance: Purchasing / Receiving Clerk or Accounts Agent). As the name
suggests, composite profiles may contain multiple user IDs necessary to perform
all the business operations associated with a particular role. A composite profile
may encapsulate another composite profile(s). In practice, a model composite
profile should be recognized for each possible role in the organization, which may
be used to produce hybrid composite profiles. The over existence of the hybrids
can defy the very purpose of composite profiles and they should be created only
when specific needs arise.
User Ids
User ids allow access to SAP applications. Each user must have a corresponding
profile specifically assigned. In many situations, multiple composite profiles can be
assigned to a user ID, depending on the role(s) an individual user is responsible
for, in the business processes.

Authorizations
Authorizations are the key building blocks of SAP security. Authorization is the
process of assigning values to fields present in authorization objects. In SAP,
access to all system functionality is achieved through a complex array of
authorizations. Sometimes users find that they lack the necessary authorizations
to perform a certain function in the system, in which case the message: "You are
not authorized..." is displayed at the bottom of the screen.
An authorization process may ask for second associated authorization process
which in turn asks for third and so on. For example, the task of paying a vendor
invoice may require 10 different authorizations.
Security Configuration in SAP

Security configuration and administration in SAP is a multi-phase process. Four
key security components are required to ensure the adequate security, privacy,
and integrity of information. The phases are as follows:
User Authentication
The first phase comprises confirmation of user identity and results in
authentication of user. Unauthorized access to SAP system is prevented through
independent. Current research this initial check. This ensures system integrity by
regulating secure access through genuine user authentication.
Creating and Assigning Authorization Profiles
A Profile Generator (PG) is used to automatically generate and assign
authorization profiles. This tool was released with SAP version 3.1g and above.
The administrator can also create authorization profiles manually.
Note: Profile Generator can be retroactively installed in SAP versions 3.0f and
above.
The authorization objects can be selected using the SAP Profile Generator.
Administrators can automatically generate authorization profiles for function
specific access to SAP users after configuring initial settings.
The entire authorization functionality of SAP signifies a new approach to
authorization. The administrator can define user authorization based on SAP

functions. Based on the selected function, the PG groups objects in administrator-
created authorization profiles.
Authorization profiles created by a Profile Generator are based on the given
authorizations. It also speeds up the process and simplifies administrator/user
communication facilitating both the administrator and users to use the same SAP
function terminology. To auto-generate an Authorization profile, an Activity Group
needs to be created.
Activity Groups contain simple profiles and usually represent employee or job
roles. They are user-defined and allow administrator to organize and maintain
system activities. Activity group when used as an information database reduces
data entry time. Administrators can define activity groups in two steps:
1. Selecting the criteria, such as access controls.
2. Dividing the activities into appropriate groups.
For example, activities can be organized by functions, such as human resources,
payroll, or administration or by job classes, such as computer programming
activities, or accounting activities. A combination of function-specific activity and
job-specific activity can also be implemented.
Security implementation with the new Profile Generator is based on the creation
of activity groups or a collection of linked or associated activities, such as tasks,
reports, and transactions.
Consider a business situation involving a company, ABC Inc. faced with
transaction security hiccups in business dealings with its dealers. To address this
problem, the company can create authorization profiles for its dealers using the
profile generator features. This can be done by implementing the following
instruction set:
Instruction 1: A dealer activity group should be created. Name this activity
group as Dealer.
Instruction 2: All dealer-specific business transactions should be included in the
activity group.
Instruction 3: Generate an authorization profile for Dealers.
Instruction 4: Assign Dealer to a “new user” or in your system and update
master records.

Following this procedure will ensure complete functional access to the new user
using the system as Dealer.
Auditing and Monitoring
In this subsequent phase, a track of the authorizations created (previous phase)
is kept. Detailed accounts of system events are used to record the actions of a
user corresponding to that unique user account identifier. Auditing/Monitoring
activities should be in compliance with enterprise’s overall IT strategy and should
be performed on a weekly, monthly, quarterly, and yearly basis.
Figure
There are some key tasks that should be included in a monitoring plan. The
following reviews should be a part of ideal monitoring plans.
Using System Logs and Security Audit Logs
The system log records critical information important events. Each individual
application server maintains local log files to which the information is written
periodically. The security audit log records areas such as successful and
unsuccessful dialog log-on attempts, RFC log-on attempts, changes to user
master records, and transaction starts.
Reviewing User Activity

All SAP system users must be continuously monitored so that their problems can
be rectified as soon as they occur. The timely attention to user problems can
reduce administration overheads.
For example, if a SAP administrator wants to check for unrecognizable user Ids or
the users trying to use non-permitted transactions, administrator can execute
transaction AL08 and review user activity.
Monitoring User access in BASIS User Group
The BASIS users in a SAP system have access to sensitive areas of an
organization. Therefore it is vital to monitor their access. Following instructions
can be performed to check the access of BASIS User group.
Instruction Set
Enter transaction SUIM to view Repository Information of the system.
Follow the Menu Path:
o User > Lists of users (according to selection criteria) > user IDS
(Double Click).
Monitoring Change Requests
All change requests need to be properly reviewed and controlled prior to being
applied. This formal process needs to be detailed enough to ensure that
separation of duties and other control features are not breached. Strong
integration knowledge of the SAP system is required for this review. Critical
profiles, authorizations, and transactions need to be identified and treated even
more carefully.
Checking Important Default SAP Profiles
Administrators must check that default profiles act a template for user defined
profiles and are not directly used in production. Default profiles contain values,
which apply to all application servers. These include: SAP_ALL, SAP_NEW,
S_A.ADMIN, S_A.CUSTOMIZ, S_A.DEVELOP, S_A.DOKU, S_A.SYSTEM, S_A.USER,
S_ENT_IMG_GE, S_WF_ALL, and P_ALL.
Changing Default SAP User ID’s

SAP comes with some pre-configure clients (independent business units). They
are client 000, 001 and 066 in the non-IDES system. In the IDES system, client
800 is the default client. SAP installation process automatically creates default
user Ids and their corresponding passwords. SAP administrators must ensure that
they are not used to access the system. The following table explains default user
Ids in various SAP clients.
User Ids Client Name User Function
SAP* 000 and 001 SAP* denotes the default super user and has all administrative
powers. DDIC 000 and 001 DDIC user is responsible for the maintenance of the
ABAP/4 Dictionary and the software logistics. EarlyWatch 066.The EarlyWatch
user has access only to monitoring and performance data.
Instruction Set
Change all default passwords and verifying the password change by logging into
various client areas.
Assign SAP* to the Super user group.
o Enter transaction SE16.
o Enter SAP* into the field called BNAME.
o Click “Execute” and verify.
As a final step, check that the secret super user has been created (with a different
user ID and password). All of the authorizations assigned to SAP* should then be
removed (an empty profile list followed by a password change.
Auditing Information System (AIS)
SAP Audit Information System (AIS) serves as a centralized repository for reports,
queries, and views of interest to auditors. It is designed to address the overall
system configuration as well as SAP business processes and their related control
features, providing audit and security practitioners with the critical information
they need to conduct effective reviews of their SAP systems. SAP administrators
can use AIS for security auditing. The AIS plays a supportive role in providing
security services for SAP systems. The primary function of AIS is auditing but
auditing features can derive the measures that help in developing the security
policy for SAP systems.
Administration and Maintenance

A successful security set up of a SAP system concludes with proper management
and administration of user IDs, password resetting, audit trails, audit logs, access
control list, and personnel responsibilities.
Security administration in SAP includes maintenance of the overall SAP security
environment using the SAP Profile Generator, creating user-level activity groups
and creating user master records.
The concept of SAP security is flexible as well as complex. SAP has a multilayered
integrated framework. To ensure adequate protection, security measures must be
factored into all layers of the SAP infrastructure. With client/server architecture,
SAP systems include many components that exchange information, each of which
constitutes a layer of the SAP security infrastructure. Security is often not a
priority in an implementation and as a result, the default security is not strong.
SAP security functionality could be enhanced using various measures as discussed
above.
Enterprises must develop a security strategy to ensure a secure and functional
SAP system. A business critical application like SAP needs continuous monitoring
and improvement of its security features.

Reference:
1. www.google.com
2. www.sap.com
3. www.sapstudymaterial.com
4. www.erpgenie.com
5. www.sapdevelopment.co.uk
6. www.simplysap.org
7. www.sapdb.com
8. Pdf Files based on
 Oracle Architecture
 IBM Database & Servers
 SAP Handbook on Different Modules

SAP-System Applications and Products

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SAP-System Applications and Products

Uploaded by

Copyright:

Available Formats

SAP- System Applications And Products

BHARATI VIDYAPEETH UNIVERSITY, PUNE

BHARATI VIDYAPEETH UNIVERSITY, PUNE

TERM PAPER REPORT

“My SAP ERP”

Submitted By:- Anshul

INSTITUTE OF MANAGEMENT AND ENTREPRENEURSHIP DEVELOPMENT,

BHARATI VIDYAPEETH UNIVERSITY

BHARATI VIDYAPEETH UNIVERSITY, PUNE

I express my deep gratitude to all concerned persons, whose help and

I am very thankful to honorable Director Dr. M.S.Prasad, the esteemed

I owe a special thanks to Miss Deepa Hebalkar (IT Faculty, MCA

Date: Anshul Kumar Saxena

BHARATI VIDYAPEETH UNIVERSITY, PUNE

Bharati Vidyapeeth University

_______________ _______________ ________________

BHARATI VIDYAPEETH UNIVERSITY, PUNE

Implementing enterprise resource-planning systems can be extremely painful, and

Throughout the 1990s, the majority of large industrial companies installed

BHARATI VIDYAPEETH UNIVERSITY, PUNE

SAP ERP helps companies with application outsourcing. It offers:

Of respondents at companies currently using or planning to use an SAP ERP

BHARATI VIDYAPEETH UNIVERSITY, PUNE

BHARATI VIDYAPEETH UNIVERSITY, PUNE

CHAPTER-2: - INTRODUCTION TO SAP & ITS APPLICATIONS

CHAPTER 3: - ARCHITECTURE OF SAP

CHAPTER 4: - USING SAP R/3

CHAPTER 5: - TRANSACTION CODES IN SAP

CHAPTER 6: - INTRODUCTION TO ABAP WORKBENCH

CHAPTER 7: - SAP SECURITY & ADMINISTRATION

BHARATI VIDYAPEETH UNIVERSITY, PUNE

ORIGIN & HISTORY OF SAP

BHARATI VIDYAPEETH UNIVERSITY, PUNE

SAP – Systems, Applications & Products.

Aktiengesellschaft (IPA: ['aktsiəngəzεlʃaft]; abbreviated AG) is a German term

The German word Aktiengesellschaft is a compound noun made up of two

SAP was founded in the year 1972 as Systemanalyse und Programmentwicklung

BHARATI VIDYAPEETH UNIVERSITY, PUNE

In August 1988, SAP GmbH transferred into SAP AG (a corporation by German

BHARATI VIDYAPEETH UNIVERSITY, PUNE

BHARATI VIDYAPEETH UNIVERSITY, PUNE

Business and Markets Place

BHARATI VIDYAPEETH UNIVERSITY, PUNE

Figure: SAP net profit.

SAP focuses on six industry sectors: process industries, discrete industries,

BHARATI VIDYAPEETH UNIVERSITY, PUNE

• Customer Relationship Management (CRM) - helps companies acquire

BHARATI VIDYAPEETH UNIVERSITY, PUNE

INTRODUCTION TO SAP & ITS APPLICATIONS

BHARATI VIDYAPEETH UNIVERSITY, PUNE

What is SAP R/3?

SAP is the leading Enterprise Information and Management Package worldwide.

International applicability is another important part of the strategy to meet

BHARATI VIDYAPEETH UNIVERSITY, PUNE

What Makes SAP Different?

Traditional computer information systems used by many businesses today have

SAP Services Overview

BHARATI VIDYAPEETH UNIVERSITY, PUNE

SAP provides several types of services:

Consulting Services: - This type of individualized consulting can be given on-site

BHARATI VIDYAPEETH UNIVERSITY, PUNE

SAP Application Modules

_______ _ __________