SAP Service Marketplace

Lesson Overview


This lesson introduces you to the central point of entry for all SAP services, the

SAP Service Marketplace. A few services that are particularly relevant to mySAP

Business Suite are presented as examples.

Lesson Objectives

After completing this lesson, you will be able to:

• List some of the services provided on the SAP Service Marketplace

• Find and use SAP Notes in the SAP Service Marketplace

Business Example

The system administrator has established that there is a problem in an SAP system

and is looking for a solution.

SAP Service Marketplace Target Group

You can find information on all SAP solutions and on SAP as a company at

http://www.sap.com. This website is open to the general public. The SAP Service

Marketplace on the other hand, at http://service.sap.com, is directed specifically at

SAP's customers and partners. The SAP Service Marketplace enables you to

access various services, special information and additional offers.

Logging on, Personalizing, and Navigating

To log on, you must be registered as an SAP Service Marketplace user (formerly

known as OSS user or SAPNet user). There is normally a contact person in each

company who creates users for employees as required and sets authorizations.

Access to the SAP Service Marketplace is free of charge to customers (apart from

the Internet access required).

Once you have logged on to the SAP Service Marketplace, you have a range of

topics to choose from. You can personalize your homepage, that is, set up your

own pages with topics that are of particular interest to you.

Quick Links enable you to quickly access specific areas of the SAP Service

Marketplace. To call up a Quick Link, simply add it to the Web address, preceded

by a “/” (for example: http://service.sap.com/ui). After logging on to the SAP

Service Marketplace, you can access a selection of “Quick Links”.
 
Important Services Provided on the SAP Service


Marketplace

Some SAP Service Marketplace functions are named below. The focus here is on

services that are particularly relevant to SAP Web Application Server.

Administering users

As an SAP Service Marketplace user with the appropriate authorizations,

you can request and administer other SAP Service Marketplace users

at /user-admin. SAP Service Marketplace users are also subject to an

authorization concept. You can, for example, withhold authorization to

create SAP messages (see below).

Developer key

A developer needs a developer key to be able to create or change objects

in an SAP system. You can request this key using the Quick Link /sscr

(“SAP Software Change Registration”).

Changes to SAP objects (such as ABAP programs) are called modifications

and require an object key, which you can also request at /sscr.
 
Notes Database


You can access the comprehensive Notes Database using the Quick Link

/notes. You can access specific SAP Notes either by entering the Note

number directly, or using search criteria (such as the name of a transaction or

an error code).

Note Assistant

All SAP systems as of the SAP Web AS 6.10 include the Note Assistant.

This is a tool (transaction SNOTE) that can automatically import corrections

to ABAP code from SAP Notes into SAP systems. /noteassistant provides

information on how to implement the Note Assistant in SAP systems with

earlier releases, as well as other information on the tool.

Corrections and messages

SAP regularly provides corrections for known problems (for example, as

Support Packages, kernel patches, or front-end patches). You can download

them at /patches. SAP recommends that you keep your correction status as

up-to-date as possible.

Itmay happen that an error occurs for which there is no relevant SAP Note

or correction available. If this does happen, you can enter a message to SAP

under /message. This message is then processed by SAP Support.

Access to your SAP system and to other services

If an SAP employee needs access to your SAP system to work on a problem,

then you can release the connection using /serviceconnection.

Other services, such as Remote Consulting (/remoteconsulting: SAP

consulting services without consultant site visits) or EarlyWatch

(/earlywatch: SAP experts proactively analyze your SAP systems to ensure

optimum performance and availability), also require this type of access.

You can find and order services provided by SAP in the Service Catalog

(Quick Link /servicecat).

Software requirements

Are you looking for information on software requirements (operating

system release or database release) for a specific SAP solution? You can find

the answer using the Quick Link /platforms.

Information on the latest developments

You can find information on the latest developments in the SAP NetWeaver

area using /netweaver.

For information about SAP Web AS, use the quick link /webas

Quick link /enterprise points to news about SAP R/3 Enterprise

Planing hardware investments


The Quick Sizer (/quicksizer) is a tool that helps you to plan your hardware

investment. Your expected hardware requirements (such as disk space and

main memory) are determined on the basis of your load profile. Standardized

SAP benchmarks carried out by SAP's hardware partners at regular intervals

on their servers help you to size your hardware correctly.

Contacts

If you need to get in touch with an SAP partner, you can find their contact

details in the Partner Directory at /partnerdir.

Training offer

/education provides details of SAP's current Education Services. You can

find out which courses in your country still have free places, or even book

them online.
 

Remote Function Calls and BAPIs

SAP systems use the following interface technologies that are listed in the above


graphic:

• ALE: Application Link Enabling

• BAPI: Business Application Programming Interface

• CPI-C: Common Program Interface Communication

• EDI: Electronic Data Interchange

• HTTP: HyperText Transfer Protocol

• LU 6.2: Logical Unit Type 6.2

• RFC: Remote Function Call

• OLE: Object Linking and Embedding

• SMTP: Simple Mail Transfer Protocol

• SOAP: Simple Object Access Protocol

• TCP/IP: Transmission Control Protocol / Internet Protocol

• XML: Extensible Markup Language

Remote Function Call

The Remote Function Call interface is an SAP interface protocol based on CPI-C

and TCP/IP. It simplifies the programming of communication processes between

different systems. RFCs enable you to call and execute predefined functions in a

remote system – or within the same system. RFCs manage the communication

process, parameter transfer and error handling.

RFC describes an interface, not the programming language in which the function


runs. You can also use RFCs to call functions in non-SAP systems. The procedure

for RFC communication between two SAP systems is that the calling system uses

an RFC definition in the system called to access a specific function.

This function is normally a remote-enabled function module. You can also,

depending on the release, use RFC to call functions in SAP R/2 systems.
If you want to start external programs remotely, you need an RFC interface outside


the SAP system. This could be, for example, a simple Dynamic Link Library

(DLL). Every RFC interface is bidirectional, so external programs can also use

RFC to access functions in SAP systems.

Note: All function modules (including those that are remote-enabled)

are created, together with their import and export parameters, using the

Function Builder. You can call the Function Builder using Tools → ABAP

Workbench → Development → Function Builder or using transaction

code SE37.

To call an RFC module from an SAP system, you need to know the import

and export parameters (defined in the Function Builder), and there must be a

technical connection between the two systems. This connection is called an RFC

connection or an RFC destination.
You can manage your RFC connections using Tools → Administration →


Administration → Network → RFC Destinations or using transaction SM59.

In the above graphic you can see, on the left side, the calling system, in which

an RFC destination named DEST has been created. An RFC destination in

transaction SM59 should not be confused with an SAP system, since an RFC

connection can only point to one specific client in an SAP system. These are

therefore also referred to as connections between logical systems; this term is

used, above all, in the ALE environment.

This also means that you can have at least as many RFC connections between two

systems as there are clients in the target system. Since you can specify a logon

user for the destination in each RFC connection, you can therefore also access

clients in the target system several times, for example, with a different logon user

each time. If you need a bidirectional RFC connection between two systems, that

is, that the system called can also execute RFC modules in the calling system, then

you need to set up an equivalent second RFC connection in the system called.

Hint: When you are defining RFC destinations, RFC connections are

• Addressed to one client, when they are pointing at an SAP system

• Accessible from all clients in the system

In ABAP, you use RFCs to call a function module in another system as follows:

CALL FUNCTION

DESTINATION

EXPORTING ...

IMPORTING ...


The function to be executed in the target system is named. The name of the target

must refer to one of the RFC connections available. When you are creating an

RFC connection, you can specify logon data for the target system; if you do not do

this, you need to enter logon parameters when you start the RFC. Exporting

and Importing are used to pass parameters to the target function and to receive

the returned parameters. The function called in the target system is executed using

the user ID entered for the connection.

Note: You can also create RFC connections for which the user of the user

making the call is used in the target system. That means different users

can use the same connection in the target system. This procedure is also

called Trusted RFC. It is, of course, a prerequisite that identical users are

created in the source and target systems. Trusted RFC is explained in the

course ADM960 - Security in SAP System Environments.

The RFC has become the most important interface in the SAP environment. Some

special RFC modules, which follow certain conventions, are also known as BAPIs

(Business Application Programming Interfaces).

BOR and BAPIs

A Business Application Programming Interface (BAPI) is a standardized

programming interface that facilitates internal and external access to business

processes and data in SAP systems. BAPIs are defined in the Business Object

Repository as methods of SAP business objects and enable an object-oriented

view of business data in an SAP system. Functions that can be called using BAPIs

are normally implemented and stored in the ABAP Workbench Function Builder

as RFC-enabled function modules. You can display an overview of available

BAPIs in the BOR, for example, using the Business Object Repository pushbutton

in the Business Object Builder (Tools → ABAP Workbench → Development →

Business Object Builder), transaction SWO1. You can access the BOR directly

using transaction code BAPI.

BAPIs, which represent methods for business objects in an SAP system, are used

in a variety of contexts. Here are some possible uses for BAPIs:

• To link business processes across system boundaries (for example, when

using ALE)

• Used by SAP to integrate various solutions in the framework of mySAP

Business Suite

• To connect an SAP system to the Internet

• Used in conjunction with SAP Business Workflow

• To connect to external programs

Note: BAPIs are created and tested in exactly the same way as other

function modules, using the Function Builder, transaction SE37, and are

then defined as BAPIs in the BOR.

Cross-System Business Processes

The Significance of Cross-System Business Processes


Let's start by defining cross-system business processes, using common situations

as examples.

For example, it may be the case that within a company, the human resources

system is separate from the rest of the business software system. Obviously, the

systems cannot be completely separate, since the accounting system needs the

employees' wage data. In this situation, you need cross-system business processes

to exchange the relevant data.

Cross-system business processes are used, for example, if two companies

collaborate closely and send joint orders to a vendor. The companies' business IT

systems need to communicate with each other to consolidate the quantities to be

ordered. In this case, the business process does not just cross system boundaries,

but also company boundaries.

An additional example is the transfer of a limited quantity of specific data, for

example, the electronic transfer of account statement data from a bank to a

company.

Recent developments suggest that the significance of cross-system business

processes will continue to increase rapidly.

Application Link Enabling (ALE)

Application Link Enabling is a means of creating and operating distributed

applications. The basic concept of Application Link Enabling is to ensure

operation of a distributed, yet integrated system landscape. This involves

business-controlled message exchange using consistent data across loosely linked


application systems. The applications are integrated through synchronous and

asynchronous communication, not through a central database.

Systems that use ALE to exchange data can be located at the same company, or

they may belong to different companies. One of the characteristics of ALE is

that different systems are linked in business terms through secure and consistent

data transfer.
You could also describe ALE as being composed of the elements: who exchanges


which data when, with whom, and by what means.

Implementing ALE therefore requires that you clarify the following points in

detail:

1. Identify the business process and the objects involved

2. Identify the information to be transmitted

3. Specify the format for the data to be transferred

4. Decide on the transfer technology to be used

5. Decide on the transfer type

6. Specify the destination of the data transfer

The following table contains examples for implementing ALE:
Process Internet Sales with mySAP CRM


Identify the information

to be transmitted

Order data from the SAP CRM System, which is to be

passed to an ERP backend

Format of the data IDoc format

Transfer technology by RFC

Transfer type asynchronously, every 60 seconds

Objective Provide goods and/or services for sale in the Internet

The data is often identified within the SAP system using a business object and its

Business Application Programming Interfaces (BAPIs). A BAPI is a method of a

business object, for example, the material master record. A permissible method

could be creating or changing the material master data. BAPIs normally enable

you to edit all data belonging to the object.

The IDoc format describes the structure of “intermediate documents”. There

are various kinds of IDoc formats for different types of data to be exchanged.

Alternatively, you can use ALE to transfer data in an agreed XML format.

You can select your preferred data transfer technology within the constraints

imposed by the system. For example, you can transfer data by Remote Function

Call (RFC) or using HTTP or HTTPS.

There are two basic transfer types: synchronous and asynchronous. Synchronous

transfer means that the data is transferred at the time of creation or change. You

can start asynchronous transfers at intervals of your choice.

There are very few restrictions on the systems that can be linked. The systems

involved must have the technical capability to receive the communications

(RFC-enabled, HTTP-enabled) and interpret the format transferred (IDoc, XML).

SAP systems of different releases can be linked using ALE.

Communication with the Database

Lesson Overview


SAP systems can be used with a variety of operating systems and databases made

by different manufacturers. The application data in the SAP system is accessed in

the ABAP stack via platform-independent ABAP programs. But the data is stored

database-specifically. Hence, the database queries from the ABAP programs have

to be translated into the respective dialect of the database. This is taken care

of by the database interface.

Lesson Objectives

After completing this lesson, you will be able to:

• Describe how the SAP system communicates with the database

• List the advantages of open SQL statements

Business Example

You want to find out how to access the database using Open SQL statements.

The SAP Web Application Server Database Interface

Relational Database Management Systems (RDBMS) are generally used to

manage large sets of data. An RDBMS saves data and relationships between

data in the form of two-dimensional tables. These are known for their logical

simplicity. Data, tables, and table relationships are defined at database level in the

database catalog (the data dictionary) of the RDBMS.

Within the SAP programming language ABAP, you can use SAP Open SQL (SQL

= Structured Query Language, database query language) to access the application

data in the database, regardless of the RDBMS used. The database interface,

which is part of every work process on the SAP Web Application Server, translates

Open SQL statements from ABAP into the corresponding SQL statements for

the specific database used (“Native SQL”). This allows ABAP programs to be

database-independent.

Note: Open SQL is a database query language based on the (ISO) SQL

standard that also contains enhancements that are not included in the

standard.

When interpreting Open SQL statements, the SAP database interface checks

the syntax of these statements and automatically ensures optimal utilization of

the SAP buffers that are in the shared memory of every SAP Web Application

Server. Data that is frequently required by the applications is stored in these

buffers so that the system does not have to access the database server to read
this data. In particular, all technical data, such as ABAP programs, screens, and


ABAP Dictionary information, as well as a number of business administration

parameters, usually remain unchanged in an operational system and are therefore

ideally suited to buffering.

Figure 57: Database Query Flow

Furthermore, "native" SQL commands can be used directly in ABAP, that is,

without using the local buffers and without the database interface interpreting the

commands. You can do this by including the commands in a EXEC SQL. - END

EXEC. bracket in the ABAP program. The ABAP Interpreter does not check the

syntax of any commands within this bracket. If you use native SQL, you can no

longer maintain the platform independence of the affected programs.

Lesson: Dialog Processing in the SAP System

Lesson: Dialog Processing in the SAP System
Lesson Overview
In this unit, you learn how your (dialog) requests are processed by the SAP
system, step-by-step. The process for a dialog transaction that consists of several
screens is also outlined.
Lesson Objectives
After completing this lesson, you will be able to:
• Outline the processing flow for a dialog step in the SAP system
• Describe the concept of work process multiplexing
Business Example
You want to be able to understand how dialog processing functions in the SAP
system.
Distribution of User Requests to Dialog Work
Processes
Each SAP Web Application Server has its own dispatcher. The dispatcher is
the link between the work processes and the users logged on to the SAP Web
Application Server (or rather, their SAP GUIs). Its tasks include distributing
all the user requests it receives to the dialog work processes on the SAP Web
Application Server.
Every time a user sends a (dialog) request to the SAP system (resulting in the
hourglass being displayed), this request is sent to the SAP Web Application Server
that the user is logged on to. On the server, the request is first placed in a request
queue for dialog requests. Requests in this queue are distributed by the dispatcher
to available dialog work processes on a “first in, first out” (FIFO) basis.
The dialog work process selected by the dispatcher first "rolls in" the user context
(that is, the dataset that contains both the current processing status of an active
program and data that characterizes the user). It 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 to the dispatcher, rolls the context
102 © 2005 SAP AG. All rights reserved. 2005/Q4
TAW10_1 Lesson: Dialog Processing in the SAP System
back out to the shared memory, and is now available again for a new user request
from the request queue. Finally, the dispatcher returns the result to SAP GUI, and
the new screen is displayed for the user.
Note: Memory management and the roll-in/roll-out process:
The memory management system differentiates between main memory
areas that are available exclusively to one particular work process, and
memory areas that can be used by all work processes. The memory
space used exclusively by a work process stores session-specific data
that must be kept for longer than the duration of a work step. This data
is automatically made available to the process at the start of a dialog
step (rolled in) and saved at the end of the dialog step (rolled out). This
data includes data that characterizes the user (user context), such as
authorizations, administrative information, and other data for the ABAP
and screen processors that has been collected in previous dialog steps
for the active transaction. There are also additional memory areas for
all processes in the shared memory for, among other things, the factory
calendar and screen, table, and program buffers.
The execution of dialog transactions is characterized by the following :
• A program dialog step is assigned to one specific dialog work process during
execution.
• The individual dialog steps for a program consisting of several screens can
be executed by different dialog work processes during program runtime.
This is called work process multiplexing.
• A dialog work process sequentially processes dialog steps for various users
and programs.
The following graphic illustrates this:

2005/Q4 © 2005 SAP AG. All rights reserved. 103
Unit 3: The System Kernel TAW10_1
Figure 55: Work Process Multiplexing
Structure of a Work Process
As components of SAP Web Application Servers, work processes execute dialog
steps for application programs. In addition to internal memory, a work process has
a task handler that coordinates the actions within a work process, two software
processors (see below), and a database interface.
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 screen processor 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 (see “Work
process multiplexing” graphic).
The actual processing logic of application programs written in SAP's programming
language, ABAP, 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.

104 © 2005 SAP AG. All rights reserved. 2005/Q4
TAW10_1 Lesson: Dialog Processing in the SAP System
Figure 56: Processing flow for dialog steps
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, the ABAP Dictionary, and
screens, among other things.

Sertifikalı SAP ABAP Danışmandan özel ders

Merhaba Değerli Arkadaşlar,
SAP ABAP sertifikalarına yönelik SAP AG tarafından onaylı kurs kitaplarından TAW.10-11-12 eğitimleri vermekteyim. Eğitim ile SAP R/3 global sertifika sınavlarını geçme ve SAP alanında uluslararası kariyer yapma şansını yakalayın, detaylar için GSM : 05536630689,Email : u_turkeli@yahoo.com dan ulaşabilirsiniz.

Certification Test

SAP Certified Development Associate - ABAP with SAP NetWeaver 7.0

The certification test for "SAP Certified Development Associate - ABAP with SAP NetWeaver 7.0" verifies the profound knowledge in the area of ABAP Development. This certificate proves that the candidate has a fundamental understanding within this profile and is able to apply these skills practically under supervision in a project environment.

Software

Software components: SAP NetWeaver 7.0

Notes

Associate Certifications are targeting profiles with 1 - 3 years of knowledge and experience. The primary source of knowledge and skills is based on the corresponding training material.