1 of 53

Overview of

SAP Products &

Components

*

2 of 53

SAP AG – An Overview

World’s Leading Provider of Business Management Software
Established in 1972. Headquarters in Walldorf , Germany
82000 Customers run SAP in 120 countries
Addressing business needs of organizations ranging from Fortune 500 Global Organizations to Small & Medium businesses
Solution offerings for more than 25 diverse industries

Media Courtesy : SAP-TV AG

*

3 of 53

SAP Components and Solutions - Overview

SAP is an acronym for Systems , Applications and Products for Data Processing
SAP’s ECC 6.0 (Enterprise Core Components) provide the core solutions for running enterprise business processes in Financials, Logistics and Human Resources
SAP’s Netweaver 7.0 Platform provide the computing environment for managing the core ECC applications using the Web Application Server 7.0 (WAS 7.0). The server can power business application programming in ABAP as well in JAVA
SAP’s Netweaver 7.0 Platforms power Business Analytics and Reporting (BI 7.0) , Process Integration with other enterprise components (PI 7.0) , Data Management (MDM 5.5) and People Integration and Collaboration (EP 7.0)
SAP Cross-Application Business suite components , such as CRM , SRM , SCM are built on the core business functions provided in ECC 6.0
SAP provides a wide ranging set of solutions for specific Industries , such as Utilities , Retail , Oil & Gas , Aerospace , Mining etc , known as SAP Industry Solutions.

*

4 of 53

SAP Components & Solutions : Positioning

SAP NETWEAVER 7.0

Composition Environment 7.1

SAP ERP 6.0

Web Application Server 7.0

ABAP

SAP Enterprise Core Components

(ECC 6.0)

Web Application Server 7.0

JAVA

Master Data Management 5.5

Business Intelligence 7.0

Process Integration 7.0

Computing Engines – Web Application Servers

Application Platform – Core Business Functions

Composites Development – SOA Enablement

Information Integration -

Business Analytics & Reporting , Master Data Management

Process Integration – ERP to ERP , ERP to Non-ERP Integration

Enterprise Portal 7.0

People Integration & Collaboration

*

5 of 53

SAP Components – One View

SAP NETWEAVER 7.0

Composition Environment 7.1

SAP ERP 6.0

Web Application Server 7.0

ABAP

SAP Enterprise Core Components

(ECC 6.0)

Web Application Server 7.0

JAVA

Master Data Management 5.5

Business Intelligence 7.0

Process Integration 7.0

Enterprise Portal 7.0

SAP Industry Solutions

Retail,Utilities,Oil & Gas,Aerospace etc

Business Suite Solutions

CRM 2007

SRM 2007

SCM 2007

SEM 2007

GTS

Technology Components & xApps Composites

Solution Manager

SAP Kernel

Composites

SAPGUI

SAP ITS

Plug-Ins

*

6 of 53

SAP Offerings based on Company Size

Enterprise Size

Solution for Small Businesses

Less than 100 Employees
Less than 30 Users
Basic functions pre-configured

Solution for Medium Businesses

Between 100 and 500 Employees
On demand solution catering to niche process areas

Solution for Medium Businesses

Strong Industry-specific focus
Stable core business processes
Preconfigured solutions

Large & Very Large Enterprises

Complete spectrum of business solutions
Adaptable components to address business process complexities
For over 500 employees

SAP Business One

SAP Business By Design

SAP Business All-in-One

SAP Business Suite

Functionality/Industry Support/Adaptability

*

7 of 53

Evolution of SAP Releases

SAP releases come in two flavours – An application flavour and basis(was) flavour.
The SAP Application , otherwise called ECC 6.0 was earlier called mySAP ERP 2005 , and this is based on WAS 7.0
The older release , ECC 5.0 was called mySAP ERP 2004 and was based on WAS 6.40
The predecessor to ECC 5.0 , was called SAP Enterprise 4.7 , based on WAS 6.20 and 6.30. This was the first time SAP BASIS kernel came to be referred to as WAS. The JAVA Engine made its first appearance in this release.
Earlier SAP releases were called R/3. This is starting from R/3 3.1i to 4.6c. The underlying BASIS kernel was versioned from 3.1i to 4.6D.All such releases were based purely on ABAP engines

*

8 of 53

SAP BASIS Overview

What is SAP BASIS ?

The term “BASIS” is a reference to the underlying technical architecture of an SAP application. The term encompasses the server infrastructure , software and the server processes that run the SAP application.

Who are BASIS consultants ?

SAP consultants who design, build and manage the SAP environment are termed as BASIS consultants. They are the SAP Technical architects in the IT organization.

What is the scope of BASIS consultants in an IT organization ?

SAP consultants possess the skills required to administer and configure SAP specific settings in an IT landscape. They are part of a larger organization which may run a landscape consisting of several SAP and Non-SAP applications.

What are the pre-requisites for starting a career in SAP BASIS ?

Basic knowledge of operating system administration, network management and database administration.

*

9 of 53

SAP BASIS Services in an Organization

BUSINESS ORGANIZATION

SAP IT ORGANIZATION

SAP Functional Analysts – SD , MM , PP , QM

SAP Developers – ABAP & JAVA

Sales

Purchase

Finance

HR

Customer

SAP BASIS Consultants

*

10 of 53

Introduction to

Netweaver

*

11 of 53

Introduction to SAP Netweaver

Basic Concept of SAP Netweaver

SAP Netweaver Application Server

*

12 of 53

Basic Concepts

SAP Netweaver provides the platform for deploying IT processes that support enterprise business functions. Such IT processes when grouped together form “IT Practices”.
Each IT practice requires an integration of various IT scenarios as shown below

IT Practices

IT Scenarios

*

13 of 53

Basic Concepts

Each IT scenario requires an integration between various components of the SAP Netweaver stack
The SAP Netweaver stack consists of 4 broad layers

People Integration
Process Integration
Data Integration
Application Platform

People Integration

Achieved by using SAP Enterprise Portal
SAP EP provides tools for developing applications for the presentation layer
Knowledge Management and Collaboration functions are in-built

Process Integration

Achieved by using SAP Process Integration
PI provides the tools and functions for SAP to SAP and Non-SAP communications
Provides means for performing Business Performance monitoring

Data Integration

Achieved by using SAP Business Intelligence and SAP MDM
A dual stack solution that provides powerful tools for data extraction, reporting , analytics and providing real-time view of business performance

Application Platform

Platform is based on SAP Web Application Server for ABAP and for JAVA
Platform that provides numerous tools for administration, monitoring and integration

*

14 of 53

SAP Netweaver Application Server

SAP Netweaver Application Server Features

Multi Level Architecture
Runtime environment for both ABAP and JAVA Programs
High Scalability

Architecture View of SAP Netweaver Application Server

PRESENTATION LAYER

APPLICATION LAYER

ABAP

JAVA

DATABASE LAYER

External Systems (SAP , Non-SAP)

Built on a wide range of Operating systems and Database Platforms
Choice of Presentation layer tools – SAPGUI , WEBGUI
Development IDES for Java and ABAP
Standard protocols supported Ex: HTTP , RFC
Security functions follow industry standards

*

15 of 53

BREAK

*

16 of 53

SAP Architecture

Fundamentals

*

17 of 53

SAP Architecture Fundamentals

ABAP & JAVA Runtimes

Client Server Architecture

Concept of SAP Instances

AS ABAP Processes & Architecture

Request Processing in AS ABAP

*

18 of 53

ABAP & Java Runtimes

SAP systems provide the basis for building applications that implement business processes
The SAP applications are not dependent on the type of Operating systems and Databases to a great extent
Applications can be built in either ABAP or JAVA languages
ABAP stands for “Advanced Business Application Programming”. Most applications in SAP are written in ABAP
To run ABAP programs , the Netweaver application server provides a ABAP Runtime environment
To extend SAP applications so that they become highly interoperable with external and internet web-based applications , the JAVA runtime was introduced in the SAP Netweaver environment. The JAVA runtime is based on J2EE standards
IMPORTANT NOTE : The ABAP and JAVA runtimes are also called as ABAP and JAVA engines

*

19 of 53

Client Server Architecture

The client is a device on a network , which transmits requests for data processing. The client in the SAP architecture can be either the SAPGUI running on Windows , SAPGUI for JAVA for other OS’ or WEBGUI which can be invoked from any common browser
The server is the Netweaver application server which processes client requests in the ABAP or JAVA engine
Communication happens over a dedicated network infrastructure (LAN) or through Wireless LAN (WLAN)
In SAP , there are several types of multi-level architectural scenarios possible :

SAPGUI

WEBGUI

BROWSER

MULTI TIER

THREE TIER

TWO TIER

INTERNET

APPLICATION SERVER

APPS + DB

DATABASE SERVER

LOCAL AREA NETWORK

*

20 of 53

Concept of SAP Instance

An SAP Instance is the basic building block of an SAP system
An SAP system can comprise of one or more SAP instances
It is an administrative unit that combines multiple components to provide one or more services
An SAP system comprises of two parts : Application Instance and Database Instance
When the application instance and database instance reside on the same hardware , it is then known as a “SINGLE INSTANCE”
When the application instance and database instance do not share the same hardware resources , then the instance is known as a “DISTRIBUTED INSTANCE”
An SAP Instance is uniquely identified with a system ID , known as SID and an instance number
Each SAP instance can be distributed over multiple hardware units. These units can be separate physical machines , logical/physical partitions within the same machine.

The Database Instance ID , also called DBSID is normally the same as the SAP instance ID , or SID.The SID is always 3 characters long and can contain alphanumerals , but it must start with an alphabet. The Instance Number is always a 2 digit number , and can be any combination of digits between 0 and 9.

*

21 of 53

Concept of SAP Instance

An SAP Application Instance can be broken down to the following types :

Application Instance

Central Instance

Central Services Instance

Dialog Instance

Type of Application Server	Instance Name	Name of Processes
ABAP Application Server	Central Instance	Enqueue Server , Gateway Process
	Central Services Instance	Message Server
	Dialog Instance	ABAP Work Processes
JAVA Application Server	Central Instance	Software Deployment Manager(SDM) , Dispatcher
	Central Services Instance	Message Server
	Dialog Instance	JAVA Server Processes

Each SAP system can have only 1 Central Instance , 1 Central Services Instance and only 1 Database instance. It can have any number of additional dialog instances

*

22 of 53

Distribution of SAP Instances in a SAP system

APPLICATION INSTANCE

DATABASE INSTANCE

CENTRAL INSTANCE

CENTRAL SERVICES INSTANCE

APPLICATION INSTANCE

CENTRAL INSTANCE

CENTRAL SERVICES INSTANCE

DATABASE INSTANCE

APPLICATION INSTANCE

CENTRAL INSTANCE

CENTRAL SERVICES INSTANCE

DIALOG INSTANCE 1

DATABASE INSTANCE

DIALOG INSTANCE 2

DIALOG INSTANCE 1

DIALOG INSTANCE 2

Single Instance

Distributed Instance

Distributed Instance with multiple dialog instances

Note : Each Box represents a physical machine or a partition within the same hardware

*

23 of 53

LUNCH BREAK

*

24 of 53

Application Server – ABAP

Processes

*

25 of 53

AS ABAP Processes

Process Name	Description
Dispatcher Work Process	There is 1 dispatcher work process per Application Instance and per each Dialog Instance.If there is 1 Central Instance and 2 Dialog instances in an SAP system , there will be 3 dispatchers. The role of the dispatcher is to distribute incoming requests to the ABAP worker threads.
Dialog Work Process (D)	There are a minimum of 2 Dialog work processes required per dispatcher that need to be configured per instance.This work process executes the transactions as required and communicates with the database instance processes
Background Work Process (B)	Background work processes execute programs that run without interacting with the user. At least two background work processes for each SAP system are required.More than one background work process for each dispatcher can be configured.
Enqueue Work Process (E)	Only 1 enqueue process exists in each SAP system. This process ensures that updates are serialized with the help of a lock table.
Update Work Process (V)	Minimum 1 Update process is required , and more than 1 process per dispatcher is allowed. This process takes care of processing update requests.
Spool Work Process (S)	Minimum 1 spool process is required and more than 1 process per dispatcher is allowed. This process passes sequential data to output devices such as printers.

The table shows the different types of Processes in AS ABAP Environment

*

26 of 53

AS ABAP Processes

Process Name	Description
Message Server (M)	Only 1 Message server exists in the SAP system and is installed on the Central Services Instance. It is responsible for communication between the different dispatchers of each SAP instance within the same SAP system.
Gateway (G)	There is exactly 1 Gateway Per Dispatcher in a SAP system.The gateway is meant to allow communication between different SAP systems
Internet Communication Manager	There is only 1 ICM per SAP system.The ICM receives requests for HTTP protocol and forwards it to the ABAP dispatches for further processing

The table shows the different types of Processes in AS ABAP Environment (Contd.)

SAP uses the acronym DVEBMGSxx , where xx is the instance number to denote an SAP instance within the SAP system.

Example : If an SAP system comprises of 1 Central instance with number 01 , and 2 Dialog Instances , with number 02 and 03 , then the SAP system is said to be comprised of DVEBMGS01 , DVEBMGS02 and DVEBMGS03 instances

*

27 of 53

AS ABAP Architecture

Note that there is no enqueue process within the dialog instance.

Architecture showing the interaction between ABAP processes in a SAP system with a Central Instance and 1 Dialog Instance

*

28 of 53

AS ABAP Processes

The AS ABAP Message Server process is for internal communication. For example initiating updates , requesting and removing locks , triggering background requests etc.
It also keeps track of which instance is available by periodically pinging each instance
There is 1 dispatcher per instance. In a system with multiple instances , the dispatchers communicate with each other through the message server
All requests received through HTTP are handled by the ICM. Each ICM then forwards the request to the dispatcher within its own instance.
The gateway process accepts requests that follow the RFC protocol. Typically such requests are sent from either other SAP systems or from applications running outside the SAP system.

*

29 of 53

Request Processing in AS ABAP

Users in SAP use the SAP Frontend , called SAPGUI as shown below.The details of the system to login into has to be specified in the SAP Logon Pad

*

30 of 53

Processing a user request

*

Technical Notes on this slide :

The screen entries of a user are accepted by the SAP presentation program SAPGUI (SAP Graphical User Interface), converted to an internal format and forwarded to AS ABAP.The (ABAP) dispatcher is the central process of AS ABAP. It manages the resources for the applications written in ABAP in coordination with the respective operating system. The main tasks of the ABAP dispatcher include the distribution of the requests to its work processes, the integration of the presentation layer and the organization of communication transactions.

The dispatcher first saves the processing requests in request queues and then processes them according to the first in, first out principle.

The ABAP dispatcher distributes the requests one after the other to the available work processes. Data is actually processed in the work process, whereby the user

who created the request using the SAP GUI is not always assigned the same work process. There is no fixed assignment of work processes to users. To process user

requests it is often necessary to read data from the ABAP schema of the database or to write to it. For this, every work process is connected directly to the ABAP

schema of the database.

Once the process is complete, the result from the work process is sent via dispatcher back to the SAP GUI. The SAP GUI interprets this data and generates the output

screen for the user.

The buffers help to speed up processing of user requests. Data that is often read but seldom changed (for example, programs or Customizing data such as clients,

currencies or company codes) can be kept as a copy of the database content in the shared memory of the application server. This means that the data does not have to be

read from the database every time it is needed, but can be called very quickly from the buffer. Each instance has its own buffers.

31 of 53

Processing a user request

*

Technical Notes on this slide :

Work processes execute the process logic of application programs. In addition to internal memory, a work process has a task handler that coordinates the actions within a work process, software processors and a database interface. The dynpro processor executes the screen flow logic of the application program, calls processing logic

modules, and transfers field content to the processing logic. The actual processing logic of ABAP application programs is executed by the ABAP interpreter. The

screen processor tells the ABAP processor which subprogram needs to be executed,depending on the processing status of the screen flow logic.

The dialog work process selected by the dispatcher, performs a roll-in of the user context first. That is, the data that contains the current processing status of a running

program as well as data that characterizes the user is made known to the work process.The work process then processes the user request, which may involve, for example,

requesting data from the database or from the buffers in the shared memory. Once the dialog work process has processed the dialog step, the work process returns the result, rolls the user context back out to the shared memory, and is now available again for a new user request from the request queue. The result is transferred to the SAP

GUI and the user sees the new screen.

32 of 53

Processing a Dialog Request

Each SAP program has a number of dialog steps , which are steps that have input parameters, processing functions and output parameters. Each step is manifested in the form of screen changes from a user’s point of view.
Each dialog step can have multiple screens to process. Each step may be executed by any of the available dialog work processes.This is known as Work Process Multiplexing.
A single dialog process therefore may sequentially process dialog steps for any user and any program during its activity cycle.

*

Technical Notes on this slide :

SAP application programs differentiate between user interaction and processing

logic. The user actions are technically realized using screens, also called dynpros

(from dynamic programs), which consist of a screen image and the underlying flow

logic. The dynpro processor of the work process executes the screen flow logic of

the application program, calls processing logic modules, and transfers field content

to the processing logic. The screen flow logic itself is further divided into PBO

(Process Before Output), which is processed before the screen image is sent, and PAI

(Process After Input), which is processed after a user interaction on the screen. The

PAI part of a dialog step logically belongs to the preceding screen image, while the

PBO part logically belongs to the subsequent screen image. The actual processing

logic of ABAP programs is executed by the ABAP interpreter. The screen processor

tells the ABAP processor which subprogram needs to be executed, depending on the

processing status of the screen flow logic.

If, during a dialog step, data needs to be exchanged with the database or the buffers,

then this exchange takes place through the database interface, which enables access to

database tables, ABAP programs or the ABAP Dictionary among other things.

33 of 53

Transaction Processing in AS ABAP

Transactions are processing units, that functionally belong together. They have four principal characteristics. The initial letters of these characteristics together form the acronym ACID.

Atomic
Consistent
Isolated
Durable

Atomic means that a transaction is either fully successful or does not have any effects at all. If a transaction-oriented system goes down, you need to ensure that inconsistent, partial results are not stored.
Consistent means that the system status changes from one that is accurate and consistent in business terms to another that is also accurate and consistent in business terms.
Isolated means that the changes made within a transaction can only be seen by other transactions, even those that run simultaneously, after the final confirmation (Commit).
The results of a transaction are durable because after the final confirmation they are stored permanently in the database.

*

34 of 53

Database Transactions & ABAP Transactions

Graphical Illustration of an Asychronous Update

*

Technical Notes on the Slide :

In the SAP system, a business process is mapped using an SAP transaction that can

contain several screen changes (for example, the creation of an order). Data changes

effected by this process are supposed to be executed completely or not at all in the

database. If the operation is terminated during the transaction or an error occurs, the

transaction is not supposed to make any database changes at all. The SAP update

system, which is described below, takes care of this.

The update system also offers increased security, performance and restorability in the

execution of database changes.

The updating system is a technology which allows SAP transactions to off-load

time-intensive database changes. These are then carried out asynchronously in

special update work processes. It also circumvents the roll-back problems caused

by the difference in the conception of the logical unit of work (LUW) in an SAP

transaction and in the database.

If, during a dialog work process, data temporarily stored for processing is passed to an

update work process for further processing, the dialog work process does not wait for

the update request to be completed: the update is asynchronous (not simultaneous).

The asynchronous update process is illustrated in the graphic The Principle of

Asynchronous Updates.

The dialog part is completed with the ABAP command COMMIT WORK; the update

part of the transaction starts: the update server transfers the update request to an

update work process. Here, each dialog step corresponds to a database transaction

(which is executed either completely or not at all in the database and there completed

with a COMMIT command). The update part of the SAP transaction is executed in a

database transaction. It is only then that the data is copied to the application tables.

35 of 53

BREAK

*

36 of 53

Enqueue & Lock Management

*

Technical Notes on the slide :

To ensure data consistency within an SAP system, you must ensure that data records

cannot be accessed and changed by more than one user at any one time. To do this,

the SAP system has its own lock management concept.

From a database perspective, every dialog step forms a physical and logical unit:

the database transaction.. The database lock administration can only coordinate

this type of database transaction. From an SAP point of view, however, this is not

sufficient, because SAP transactions, which are formed from a sequence of logically

related work steps that are consistent in business terms, are generally made up

of several dialog steps. SAP systems need to have their own lock management.

This is implemented using the enqueue work process. This also ensures that the

platform-independence of the lock management is maintained.

The SAP lock concept works on the principle that SAP programs make lock entries

for data records to be processed in a lock table. Lock entries can only be made if none

already exist for the table entries to be locked.

The enqueue work process manages the logical lock of the SAP transactions in the

lock table. The lock table is located in the main memory of the instance with the

enqueue work process.

If a user wants change access to data, the executing dialog work process requests a

lock (to do so, the application developer must program this request explicitly).

If a dialog request is processed on the enqueue server, the dialog work process can

access the lock table directly. It now checks whether a new lock can be generated; that

is, whether there is a collision with locks that have already been set. If a lock can be

set, the dialog work process creates it and the user (lock owner) is given the lock key.

The lock key is kept in the user context in the shared memory.

If the dialog work process that processes the user request and the enqueue work

process are not running on the same instance, these two work processes communicate

through the message server. In this case, the lock request is forwarded from the

dialog work process to the enqueue work process via the dispatchers and the message

server. The enqueue work process now checks whether a lock can be set. If this is

possible, the lock is set by the enqueue work process and the lock key transferred to

the requesting dialog work process via dispatcher and message server.

When the lock is requested, the system checks whether the requested lock conflicts

with existing entries in the lock table. If the lock table already contains corresponding

entries, the lock request is refused. The application program can then inform the user

that the requested operation cannot currently be executed.

The application developer can choose between different lock modes:

� Write locks (lock mode Exclusive); the lock data can be edited only by one user.

The requests for another write lock and another read lock are rejected. A write

lock protects the locked objects against all types of other transactions. Only the

same lock owner can set the lock again (cumulate).

� Read locks (lock mode Shared); several users can have read access to the locked

data at the same time. The requests for additional read locks are accepted, even

if they are from other users. A write lock is rejected.

� Enhanced write locks (lock mode eXclusive noncumulative); while write locks

can be successively requested and released by the same transaction, an enhanced

write lock can only be requested once, even by the same transaction. All other

requests for locks are rejected.

� Optimistic locks (lock mode Optimistic); optimistic locks respond like read lock

at first and can be changed to write locks. An optimistic lock is set if the user

displays the data in change mode. Optimistic locks on the same object do not

collide. If the user wants to save the (changed) data, the optimistic lock must be

changed to a write lock (mode E). (This fails if someone set a non-optimistic

lock on the object before.) Other optimistic locks on the object are deleted in

the process.

Locks set by an application program are either released by the application program

itself or by the update program once the database has been changed. Locks that have

been passed on to an update work process in this way are also written to a file at

operating system level and can therefore be restored if the enqueue server goes down.

Transaction SM12 (Tools → Administration → Monitor→ Lock Entries) displays the

locks that are currently set. If a lock has already been inherited to the update process,

the backup flag has also been set. Such a lock will also be included in the lock table

again after restarting the enqueue server.

There are basically two ways of deleting locks held by users:

� Ending the user session in the user overview (transaction SM04 or Tools →

Administration → Monitor → System Monitoring → User Overview)

� Manually deleting the lock entries in SM12

The first method (ending the user session) also results in the original lock owner

leaving the transaction and thereby releasing all locks held; the second method

(manually deleting using SM12) merely deletes the lock entry from the lock table. This

theoretically enables several users to change the same data records simultaneously.

37 of 53

Update Process

*

38 of 53

Principles of Asychronous Updates

*

Technical Notes on the Slide :

If users want to change a data record in an SAP transaction, they call the corresponding

transaction in the dialog, make the appropriate entries on the screens and then initiate

the update process by saving the data. This process triggers the following steps:

1. The program locks the data record for other users. The program does this by

addressing the enqueue work process (using the message server if appropriate).

The enqueue work process makes the relevant entry in the lock table or (if

another user has already locked the data) informs the user that the data record

cannot currently be changed.

2. If the enqueue work process succeeded in writing the lock entry to the lock table,

it passes the lock key it created to the user, the program reads the record to be

changed from the database and the user can change the record on the screen

image of the SAP transaction.

3. In the active dialog work process, the program calls a function module using

CALL FUNCTION ... IN UPDATE TASK and writes the change request to

database update tables. These are also called VB* tables, because their names

begin with VB. They act as temporary memory and store the data to be

changed until it can be collected and written to the application tables in the

database (in a single database transaction).

4. At the end of the dialog part of the transaction (for example, when the user saves

the data � possibly after completing other dialog steps), the program initiates

the close of the transaction with the COMMIT WORK statement. The work

process that is handling the active dialog step completes the update header and

triggers an update work process.

5. Based on the information (key of the update order, lock key) transferred from the

dialog work process, the update work process reads the log records that belong

to this SAP transaction from the VB* tables.

6. The update work process transfers the changes marked and collected in the VB*

tables to the database as a change request and evaluates the database response.

If the changes were successfully written to the target tables, the update work

process triggers a database commit after the last change to the database and

deletes the entries from the VB* tables. If an error occurs, the update work

process triggers a database rollback, leaves the log records in the VB* tables

and marks them as defective.

7. The lock entries in the lock table are reset.

Note: The application developer decides whether and how to use

asynchronous updates while programming the transaction. Besides the

asynchronous update, there are some other update techniques (for example,

synchronous or local).

To increase performance further, application developers can configure

different types of updates:

time-critical, primary V1 updates. They are relevant to objects that

have a controlling function in the SAP system, such as a change to the

material stock or an order creation.

non-time-critical, secondary V2 updates that depend on the V1 updates.

These are, for example, purely statistical updates such as the calculation

of results.

non-time-critical updates that are collected and processed at a later point

in time (collective run).

The V1 modules for an SAP transaction are processed sequentially in a

single update work process. If your SAP system has a work process for V2

updates (type UP2), then V2 modules will only be updated there. Once it has

successfully completed processing, the V1 update work process releases the

relevant locks again. This means that the normal update work processes

are available again more quickly for time-critical V1 updates, and that the

relevant lock entries are deleted sooner. If you have not configured any V2

update work processes, then the V1 work process handles all updates.

In the collective run, the modules are not updated automatically but only

when a special report (report RSM13005) triggers the update. All calls of the

function modules are then collected, aggregated and updated at once. In doing

so they are handled like V2 update modules.

If an error occurs during an update, then processing of the active update component

terminates. Users can be notified automatically by express mail when an update

terminates.

If a dialog work process terminates whilst writing data to the VB* tables, the tables

will contain data that will not be updated. These entries can be automatically deleted

the next time you start the system or they can be deleted manually. The application

tables remain unchanged.

An asynchronous update may terminate for a variety of reasons. If, for example,

several attempts are made to enter the same data record (using insert) in a table, this

triggers the exception condition Duplicate Key in the coding because an entry

already exists in the table under this key. Therefore, the corresponding data record

cannot be written to the database table more than once.

When an update terminates, the system sends an express mail to the user who triggered

the update. Any additional steps must be carried out by the system administrator.

Transaction SM13 (update requests) provides system administrators with analysis

tools to handle terminated updates. Once the error that caused the termination has

been corrected (for example, hardware damage repaired), the end user should restart

the processing.

39 of 53

Print Processing

*

Technical Notes on the Slide :

A spool request contains information on the data to be output, its formatting, and the

printer model used. The spool request generated is stored in the TemSe (temporary

sequential file).

Hint: Spool requests can be created by dialog work processes or by

background work processes. Spool work processes do not create spool

requests.

A spool work process formats the data specified in the spool request and creates an output request.

The output request contains all data in an appropriate format for the printer. This data

can either be passed on to an appropriate operating system spool process locally (on

the same computer) or remotely (over a network connection).

Note: In an SAP system, the connection between a spool work process and

the operating system spool process is known as the access method. There

are more access methods than displayed above. These are the two most

commonly used access methods for connecting printers to SAP systems. In

this context, remote or local do not refer to the physical location of the output

but to the place where the spool work process is connected to the operation

system spool process.

For print processing, the best performance is achieved by sending the data to be

printed to the operating system as soon as possible. You do this using the local access

method. The operating system then performs all remaining tasks, such as queuing

and data transfer to the selected printer.

Hint: One minor but indispensable requirement for printing from SAP

systems is that each selectable printer allows printing at operating system

level.

You can display your own spool and output requests via System → Own Spool

Requests (transaction SP02).

Via System → User Profile→ Own Data (transaction code SU3) you can specify

personal settings for printing on the Defaults tab page in the Spool Control section.

40 of 53

Background Processing

*

Technical Notes on the Slide :

SAP background processing is a method for automating routine tasks and for

optimizing the use of your organizations SAP computing resources. In background

processing, you instruct the R/3 System to run programs for you. You can use

background processing to execute long-running or resource intensive programs

at off peak times. You can use it to assign the system the task to execute reports

and programs. There is no strain on your dialog resources and reports running

in the background are not subject to the runtime restrictions of dialog processing

(termination of the program after a runtime of ten minutes).

The segregation of background processing to special work processes gives you an

additional dimension for separating background processing and interactive work.

Normally, background processing and interactive work in the system take place at

different times. For example, the system is used interactively during the day and

background processing takes place at night. You can use background work processes

to separate background processing and interactive work also by servers because

background jobs are only executed on servers that offer background processing.

The end user can usually schedule the program to be started in the background as a job

from the application transaction. The job then �waits for the planned execution time

in the job scheduling table. If the time has come and free background work processes

are available, the job is distributed to a background work process by the background

scheduler and then executed. Users can display the result in the application transaction

or, in case of list generating programs, look at the spool request belonging to the

job (see Printing section). To display your own jobs, choose System → Own Jobs

(transaction code SMX).

The system administration and the work preparation have access to a tool for

scheduling different types of background takes with transaction SM36 (Tools →

CCMS → Background Processing→ Define Jobs). The system-wide monitoring of

jobs takes place with transaction SM37 (Tools → CCMS → Background Processing→

Jobs - Overview and Administration).

For cross-system scheduling and monitoring of background tasks, you can use SAP

Central Process Scheduling (SAP CPS) and other licensed partner products.

41 of 53

Internet Communication Manager (ICM)

*

Technical Notes on the Slide :

Web requests are received by the Internet Communication Manager (ICM). These

HTTP(S) requests can be processed either in the ABAP work process (for example,

ABAP web dynpro applications) or forwarded to AS Java in an AS ABAP+Java

system (for example, Java web dynpro applications). The ICM can use the URL to

decide to where it forwards the request (if it cannot reply to the request from its cache).

If the request is to the Java runtime environment, it is sent to the Java dispatcher

(2b), which then forwards it to a Java server process (3b). The Java server process

then refers to the database's Java schema, if applicable, and uses the Java dispatcher

process to send the response back to the ICM. Finally, the ICM sends the response

from the SAP system to the user who sent the request (5).

If the request is to the ABAP runtime environment, the ICM forwards it to the ABAP

dispatcher (2a), which then handles it like a typical SAP GUI request (see previous

section). The work process that processes the enquiry now communicates directly

with the ICM (4a). The ICM returns the response to the user who sent the request (5).

42 of 53

BREAKOUT

SESSION

*

43 of 53

Notes on SAPGUI

There are various ways to access an SAP System. The most commonly used are SAPGUI for Windows , SAPGUI for JAVA and WEBGUI for browsers.
SAPGUI is a client utility that has to be installed on a user’s machine.
SAPGUI is available for installation on Windows and on Non-Windows platforms as well.
A JAVA based SAPGUI is required for OS such as Linux or any other Unix flavour
SAPGUI is available as SAPGUI for HTML , popularly called WEBGUI , that is supported on most common browsers such as IE 6 , Firefox 3
For Windows desktops , the entries in the SAPGUI logon pad are stored in a file called saplogon.ini file , which is located in the path C:\Windows

*

44 of 53

Alternative types of SAPGUI

*

45 of 53

Navigation using SAPGUI

ELEMENTS OF SAPGUI

SAPGUI Version

SAP System Entries in SAP Logon Pad

SAP LOGON PAD

Log On Button

Create New System Entries

*

46 of 53

System Entry in SAPGUI

ELEMENTS OF SAPGUI

Description of the SAP System.This can have any convenient name as per the users choice

SAP Application Server Host Name or IP address

SAP System Number

System ID

*

47 of 53

SAP Logon Screen

ELEMENTS OF SAPGUI

User ID

Password

Client Number

Note :

Client Number is a logical unit of an SAP system

Password field is case-sensitive

You can change your password once a day

2 Character Language Field : By default the system takes EN if left blank. (EN – English)

*

48 of 53

SAP Logon Screen

ELEMENTS OF SAPGUI

User ID

Password

Client Number

Note :

Client Number is a logical unit of an SAP system

Password field is case-sensitive

You can change your password once a day

2 Character Language Field : By default the system takes EN if left blank. (EN – English)

*

49 of 53

SAP Logon Screen

ELEMENTS OF SAPGUI

Field to enter Transaction Code

In SAP , all operations are carried out using Transaction Codes.These are codes that can call reports,programs from the users screen.
/n denotes a new session.A user can open upto maximum of 6 sessions where he/she can parallely work
/o followed by a transaction code causes the transaction to open in a new session.
Each new session means a new window opened on your computer

*

50 of 53

ABAP Work Processes – SM50

This transaction shows the various ABAP work processes : Dialog,Update,Enqueue,Background,Spool and Update2

The dispatcher process is not shown here.

*

51 of 53

ABAP Work Processes as Unix Processes

In the previous screen , there were a total of 21 ABAP processes indicated
On an UNIX OS Level , these processes are realized as individual unix processes denoted by “dw”
The above screen shows 22 dw processes. This is because there is the additional “Dispatcher” process
The ICM process is a process that starts with the name “icman”
The Gateway process is a process that starts with the name “gwrd”
The Message server is a process that starts with the name “ms”

*

52 of 53

Checking for Locks – SM12

You can check for lock entries in a system using SM12 transaction

The above screen shows locks on table VBAK (Sales Order Table)
The lock will remain on the table until the user either saves the sales order data or exits the transaction without saving

*

53 of 53

Q&A Session

*