You are on page 1of 35

SAP Web Application Server Technical Infrastructure

Dr. Achim Braemer


Technology Development, SAP AG

Introduction
Technical Infrastructure
" Performance " Availability " Security " Network topology " Network technologies

ad Ple dit ion ase o b a in the l exp serve slid lan e n atio ote ns s

This presentation is about technical system design

Things I do not cover


" Business processes " Customizing " Web application development

SAP AG 2001, TechED 2001 PT1D2P5_Braemer

# This is a presentation I will show you how to build a technical infrastructure to support a solution with SAP Web Application Server. # The technical infrastructure has to assure performance, availability and security of the solution. Special requirements may be imposed both by the specifc application as well as by the need to integrate the new solution into an existing system landscape. # In this presentation, I will cover general aspects of Web technology as well as special features of SAP Web AS and what demands the technology imposes on the supporting technical infrastructure. # Specail emphasis lies on network tolopogy and network technologies that can be used in conjunction with SAP Web AS.

Topics

SAP Web Application Server Architecture and Features Technical System Design
" Load balancing " Stateful user sessions " Secure Communication

Solutions
" Web Switch " SAP Web Dispatcher " Network security

Outlook and Conclusion

SAP AG 2001, TechED 2001 PT1D2P5_Braemer

# The presentation is structured into three major sections. # The first step in designung a technical infrastructure is to understand how the system works. This is the first topic. # In the following section, I will discuss the issues that influence technical system design. Most of these issues are not speficic for the SAP Web AS, but rather of general significance. In this section, we will discuss the design issues and make certain decisions that determine the technical infrastructure. # In the third section, I will present some solutions that comply with our design decisions. There is a solution using off-the-shelve network equipment and an upcoming solution provided by SAP as of SAP Web AS 6.20. # I will conclude with a short outlook on the future of the SAP Web AS.

"Old" SAP Application Server Architecture


SAP GUI RFC Client/ Server

DIAG

Dispatcher Gateway

Work Processes

RDBMS

SAP AG 2001, TechED 2001 PT1D2P5_Braemer

RFC

SAP Web Application Server Architecture


SAP GUI RFC Client/ Server

Internet

HTTP

DIAG

Internet Communication Manager


ICM

Dispatcher Gateway

Work Processes

RDBMS

SAP AG 2001, TechED 2001 PT1D2P5_Braemer

RFC

Internet Communication Manager

ICM
" Separate Process: Dedicated to communication " Multi-threaded: High throughput architecture " Modular: Plug-in protocol handlers

HTTP plug-in
" Web server or client " Static content (like pictures) $ Layered cache
% Memory (very fast) % Disk (fast) % Database (not so fast, but infrequent)

" Dynamic content (applications) $ ABAP work processes


% Very efficient (shared memory) % Internet Communication Framework (low level) % Business Server Pages (high level)

SAP AG 2001, TechED 2001 PT1D2P5_Braemer 6

# Currently ICM has a handler for HTTP and one for SMTP (simple mail transport protocol). # The SMTP handler is not built to be a replacement for sendmail, but rather to allow receiving main from a mail hub and sending mail over a mail relay hub only. It is not intended to be directly connected to the Internet. We will not cover the SMTP handler in this presentation. # The HTTP handler has two parts: client and server. # The client part resembles a Web browser's functionality: Documents can be retrieved from arbitrary HTTP servers and processed in the Web AS. For example, the client could retrieve an XML document containing a data structure form another application (SAP or non SAP), process it using the built in XML processing engines and do something useful with the result. # The client supports SSL. It can authenticate itself using user name/password or X.509 client certificates. It can also use a proxy server for outgoing requests. Thus, the network infrastructure used for regular browsers can be used for Web AS HTTP clients as well. There is not much more to be said about the client functionality. # The rest of this presentation will deal with the requirements of this HTTP server functionality.

SAP Web Application Server Features


Standard Web protocols
" HTTP Server and Client functionality " HTTPS, Server and Client Certificates (X.509), 128 bit encryption " WebDAV, SOAP, ... " SMTP

Integrated SAP Environment


" Usual SAP development and deployment infrastructure " Internationalization " Monitoring and system management " User management, authorization concept

Standard Web documents


" HTML " XML / XSLT

Common SAP communication


" RFC, BAPI, IDOCs, ALE,

Page based Web programming


" Business Server Pages

SAP AG 2001, TechED 2001 PT1D2P5_Braemer

Architecture Summary

SAP Application Server + Communication Handler ICM + Web Development Framework = SAP Web Application Server

" Built on proven SAP Application Server Technology " Scalability "just like R/3" (3-tier architecture) " High availability "just like R/3" (off-the-shelve solutions) " Utilize existing SAP know-how and infrastructure

SAP AG 2001, TechED 2001 PT1D2P5_Braemer

SAP Application Server + Communication Handler ICM + Web Development Framework = SAP Web Application Server

(SAP Basis Release 4.6)

(SAP Web AS Release 6.10)

# (In 6.20, we will also have integrated Java server. See last slide for more info.) # The basic architecture is the same as proven R/3 technology, so the technical features are similar. # However, there are additional requirements for building a Web application and operating it in the Internet environment. That's what this presentation is about.

Where is Web AS Technology Used?


Today
" Standalone Web AS System Own SID, own database " Web frontend application " Integration
SAP Web AS HTTP RFC

Non-SAP system
SAP Basis

Web App.

R/3
SAP Basis

BW

SAP Web AS

Tomorrow
" SAP Basis $ SAP Web AS " Underlying technology for all mySAP components " BW 3.0 (Q4/2001) " R/3 Enterprise 4.7 (2002)

R/3
HTTP SAP Web AS

BW

SAP AG 2001, TechED 2001 PT1D2P5_Braemer

Topics

SAP Web Application Server Architecture and Features Technical System Design
" Load balancing " Stateful user sessions " Secure Communication

Solutions
" Web Switch " SAP Web Dispatcher " Network security

Outlook and Conclusion

SAP AG 2001, TechED 2001 PT1D2P5_Braemer

10

10

Technical System Design


How to connect the system to the Internet?

Additional challenges
" Load balancing " Secure communication " Network access points " Performance and scalability " Continuous availability " Cost of ownership " Network security

Challenges $ Design criteria $ System architecture

SAP AG 2001, TechED 2001 PT1D2P5_Braemer

11

# Enough of the basics, let's move on to more challenging topics # Now we will consider that what has to be done in order to offer a Web service in a productive way, e.g. in the Internet. The remainder of the presentation will focus on using SAP Web AS as an HTTP server. # Seems like a trivial question: You find yourself an Internetprovider, by a router and then your online... However, living and surviving in the Internet is little more complicated than that...

On the folowing slides I will explain the requirements and design criteria are and show you a possible solution. Note that there is not the one and only solution for all requirements, We have to set priorities and accept tradeoffs. Different design decisions may lead to different solutions. # Most of these considerations can be applied also to intranet applications. However, some aspects that are crucial in the Internet are less important for internal applications.

11

Simple Load Balancing for SAP Web AS

Host1

ta rt rg=s ta r t pp ? a m/ a rg=s r.co pp?a ou /a t1.y .c o m your /hos st2. t p:/ ht / ho G ET tp : / : ht tion o ca

Message Server Central Instance

Host4
GET htt p: /

Rem

ain

/ho

s t2

Host3
.y o ur.

i ng

us e

c om

r s p ? ar g= sta es s i o n rt

/a p

Host2 Dialog Instance

Just like SAPlogon, but...

SAP AG 2001, TechED 2001 PT1D2P5_Braemer

12

Simple load balancing built into SAP Web Application Server based on redirections 1. Browser sends request to Message Server 2. Message Server sends HTTP redirection to suitable Application Server 3. Browser sends request to this Application Server 4. User stays on this Application Server for remaining session

12

Drawbacks of Redirection
Many official external DNS names and IP addresses Confusing for the user, bookmarking not allowed With SSL
" Server certificate must match URL " Every application server needs separate server certificate " High administrative overhead " Expensive

May lead to unnecessary user authentication dialogs

SAP AG 2001, TechED 2001 PT1D2P5_Braemer

13

# Superfluous authentications arise when starting new application on a different application server (after fresh load balancing decision). If basic authentication is used, the authentication information is not sent to the new server, because it is sent ONLY to the exact same server that originally requested the authentication. # This can be avoided by enabling cookie based authentication. Cookies are sent to all servers within the same DNS domain. # The same arguments hold for intranet applications, but not quite as important: & IP address range is not an issue & Servers are known to the internal DNS anyway & Certificates ca be generated with internal certificate authority (CA) to reduce cost

13

Better than Redirections


(especially for Internet applications) Load balancing with single point of access
" One DNS name, one IP address " One server certificate " One URL
Load Balancer Application Server Application Server

Application Server

"Load balancer with single access point"

SAP AG 2001, TechED 2001 PT1D2P5_Braemer 14

14

Stateful User Sessions

Programming models
" Stateless: No session state on Web AS (state information may be in browser) " Stateful: Web AS keeps session for every user (SAP: "roll area")

"Must support stateful applications"

SAP AG 2001, TechED 2001 PT1D2P5_Braemer 15

# Simple application can be made stateless, but elaborate business applications with transactional behavior are usually stateful (availability checks, database locks etc.) # Alternative: Use stateless programming model. Easy for simple applications. State information can be held in the database even without holding a user context. But unfortunately, only one stateful application is sufficient to make the session persistence mandatory. Since it is nearly impossible to ensure that EVERY application ever used is staeless, the technical infrastructure must allow for stateful session in almost every case.

15

Load Balancing Stateful User Sessions


HTTP is a stateless protocol
" Successive requests may open a new network connection
Session State
u req es t

Application Server

Load Balancer

1 st

2n d

req

u es

Application Server

Requirement of stateful applications:


" Load balancer must ensure that user gets back to same server (session persistence)

SAP AG 2001, TechED 2001 PT1D2P5_Braemer

16

# Stateful applications impose special requirements on the load balancing # HTTP is a stateless protocol, because the network connection does not last for the duration of a user session. The protocol itself offers no provisions to return a subsequent request to an already established session. # First request from user establishes session in application server # If subsequent request would be directed to a different server, session context is not known there so context would be lost. # Worse, if the first context holds any locks, second session would not be able to access locked items. # Conflict between application (stateful) and protocol (stateless) # Load balancing device must ensure that all requests belongoing to an application session are directed always to the same application server!

16

Session Persistence
How to ensure session persistence?

SAP Web AS server uses "session cookie" to identify user session (HTTP header)

Load balancer can use the session cookie for the same purpose
Works, but only for clear text HTTP

SSL is required for secure communication in business applications

"Load balancing must support SSL"

SAP AG 2001, TechED 2001 PT1D2P5_Braemer 17

# The stateful application uses content of a so-called "cookie" that identifies the session ("session cookie") to identify the application session associated with a request. A cookie is a small string that the server sends to the browser and that is returened by the browser with every subsequent request. # Since the application server uses the session cookie to identify the session, the same can be done by the load balancing device. & The load balancing device has to identify the session cookie in the HTTP header and create a mapping between cookie content and application server. & Configuration of how to find the session cookie has to be done manually (for non-SAP load balancers). & This method can only be used for clear text HTTP, if SSL is used the entire data stream (including the HTTP request header) is encrypted. # The session cookie is also used to authenticate successive requests. The cookie can be "stolen" if clear text HTTP is used, e.g. by capturing network packets between browser and server. A stolen cookie would enable an intruder to akt on behalf of the original cookie owner. To prevent this, SSL has to be used. # SSL is a requirement for any application that deals with business content, therefore our infrastructure must support it.

17

Terminating SSL in the Load Balancer

Disadvantages:
" (Usually) no secure channel between load balancer and Web AS " Clear text communication is potentially dangerous " Inhibits client authentication with X.509 certificates

Better: SSL end-to-end (browser to Web AS)

"SSL end-to-end"

SAP AG 2001, TechED 2001 PT1D2P5_Braemer 18

# To read the cookie, the load balancing device could terminate the SSL session in order to establish the session cookie. But once terminated, the SSL session can not be re-established for the network way between load balancer and Web AS. # Terminating SSL before the Web AS is potentially unsafe if there is no secure channel between load balancer and Web AS. # It has tobe said that terminating SSL may also have an advantage & Enhance performance on the application servers by taking the CPU load needed for SSL procession off the servers. Especially esigned so called SSL accelerators are often used for this. They implement SSL handling in "hardware". & Could allow application layer filtering of requests, e.g. - Is the request well formed HTTP - Size restrictions on header and POST data to prevent buffer overflow etc. - Enable only certain applications by examining URL - BUT: not implemented as of now # The end-to-end SSL requirement is a general recommendation, because application that violate this requirement MAY be insecure. # On the otherhand, if you carefully regard all the implications and possible risks, there is nothing wrong with terminating the SSL session. However, YOU have to take the necessary meaures to make the application secure.

18

Session Persistence for HTTPS


Terminate SSL in the load balancing device
Works, but... See above

Redirection
Works, but... See above

SSL session ID
Does not work, because SSL session does not correspond to user session

Client IP address
Works, although some problems with proxies

"Session cookie (HTTP) or client IP address (HTTPS)"

SAP AG 2001, TechED 2001 PT1D2P5_Braemer 19

# Terminating SSL enables load balancer to read the session cookie for session persistence. # Redirections ensure session persistence, because the user accesses each application server directly. It is not the method of choice especially in Internet application because of the problems mentioned above. # The SSL session ID was once deemed a way to achieve session persistence without the weaknesses of the IP address method and without having to look into the HTTP data. Unfortunately, it has turned out that the SSL session ID is not suitable to ensure the integrity of application sessions, because the livetime of SSL session does not correspond to the lifetime of a user session. The browser decides after a fixed period of time to end the SSL session and start a new one, regardless of user activity at that time. On some browsers this time is only 2 minutes, but even if it is longer, the end of the SSL session is never synchronized with the end of a user session. # Using client IP address to identify a session has problems with proxies & Users from same IP address are associated to same session and thus routed to the same server. The server can distinguish between the sessions, so session integrity is OK, but load balancing is not optimal. In the intranet, an extreme case could be that ALL users access the system through a proxie. & Someties (but quite rarely) load is balanced among different proxy servers resulting in DIFFERENT IP addresses for the same user and within an application session. Usually, these IP addresses differ only in the last byte (are in the same class C subnet). Thus the problem can mostly be circumvented by configuring the load balancing device to treat all clients in the same class C subnet as equal. However, the quality of load balancing may suffer even more from this. & Another weakness of this method is that the device can not determine when an application session is terminated and so the load balancing decision lasts for a longer time than necessary. In practise, it is true also for the cookie method, though, because here the cookie s usually not deleted after a session, but rather overwritten by the next session. Only restarting the browser would force a new load balancing decision to be made, because then the session cookie is forgotten. # But there is no other choice: Either we terminate SSL (which I assume for now is not acceptable) or we stick to client IP addresses

19

Topics

SAP Web Application Server Architecture and Features Technical System Design
" Load balancing " Stateful user sessions " Secure Communication

Solutions
" Web Switch " SAP Web Dispatcher " Network security

Outlook and Conclusion

SAP AG 2001, TechED 2001 PT1D2P5_Braemer

20

20

Web Switch

Single access point


" One IP address and port " One URL seen by user

Message Server

Standard Web technology


Web Switch

Central Instance RDBMS

http://shop.abc.com Dialog Instance

Session persistence
" HTTP session cookie (HTTP) " Client IP address (HTTPS)

SSL end-to-end
SSL

SAP AG 2001, TechED 2001 PT1D2P5_Braemer 21

Dialog Instance

# High end (high cost) solution # Consider also that high availability concepts require redundancy, so you usually need 2 devices.

21

Alternative: Web Switch with SSL Accelerator

Session persistence
" HTTP session cookie Web Switch
http://shop.abc.com

Message Server Central Instance RDBMS

Dialog Instance

SSL Accelerator

SSL Terminated Not End-to-End


SSL

SAP AG 2001, TechED 2001 PT1D2P5_Braemer 22

Dialog Instance

# High end (high cost) solution (even more than simple Web switch)

22

Web Switch Features


Pros
" Off-the-shelve products " Suitable for very high volume " Can check individual Web AS availability

Cons
" Well known problems with SSL session persistence Can optionally terminate SSL (with SSL accelerators), but... " Expensive " Complex configuration (need expert) " All Web AS instances have to be configured manually " Generic, no awareness of SAP system

SAP AG 2001, TechED 2001 PT1D2P5_Braemer

23

23

Load Balancing Mechanism


Load balancing device needs information about system state Configuration (host names, port numbers, ...)
" Manual " Use information from SAP Message Server

Load balancing
" Round-robin (weighted) " Load-based (get load info from application server) " Use information from SAP Message Server

High availability
" Check individual Web AS instances " Use information from SAP Message Server

"Message Server-based configuration"

SAP AG 2001, TechED 2001 PT1D2P5_Braemer 24

# A crucial part of the technical architecture of a large Web application (Internet or intranet) is the load balancing mechanism. # Load balancing mechanism is usually also used for high availability & LB Device checks availability of servers and directs requests only to those that are "alive" # LB device can also check current load of server and adjust load accordingly # Checks (both load and availability) done by & Inspecting the response to regular requests (does a response take place, how long does it take) & Requesting information from each server via HTTP & In case of SAP Web AS, Message Serve information can be used. # Configuration of LB devices is usually not trivial. Each server has to be entered into a table, the load balancing algorithm has to be specified and session persistence has to be enabled (see below). # We want a load balancing device that can retrieve information about system configuration as well as current state and load from the SAP Message Server to keep configuration effort low and allow optimal load balancing.

24

SAP Web Dispatcher (Release 6.20)


Load balancing & configuration
" SAP Message Server based

Single access point


" One IP address and port " One URL seen by user

Message Server

Software
SAP Web Dispatcher

Central Instance RDBMS

http://shop.abc.com Dialog Instance

Session persistence
" HTTP session cookie (HTTP) " Client IP address (HTTPS)

SSL end-to-end
SSL

SAP AG 2001, TechED 2001 PT1D2P5_Braemer 25

Dialog Instance

SAP Web Dispatcher: Will be SAP's standard solution for Web load balancing & Available as of release 6.20, usable for current 6.10 system also (kernel is downword compatible) As of release 6.20: Very similar to Web switch, but overcomes some of its problems: & Cheaper & Easier to configure Aware of SAP system configuration and current state by requesting information from Message Server Features as of 6.20: # (Currently) End-to-end SSL, SAP Web Dispatcher does not constitute an end point of SSL connection & SSL terminated in Web AS, all servers appear to have the same identity in the Internet & All servers use same server certificate # Single entry point, one IP address, one port HTTP, one port HTTPS # Load balancing decision based on message server, which knows about availability of dialog instances # Stateful sessions: & Based on session cookie for HTTP & Based on client IP address for HTTPS - Problems with proxies that switch IP address during one user session can be coped by configuring a range of addresses that are treated as identical for load balancing. # No manual configuration of servers, ports etc. necessary, because SAP Web Dispatcher retrieves this information from Message Server # Targeted at small and medium installations where cost matters # SAP plans further features, see below

25

End-to-End SSL Revisited


All servers used by an SAP Web Dispatcher share the same certificate
" Good: few certificates " Bad, because:
internal host1
host1

SAP System

host1

Application Server

Every load balancer must use an exclusive set of servers


external

Load Balancer

Application Server

Multiple load balancers must use non-overlapping groups of servers


" Example: different URLs for internal and external users

host2

host2

Load Balancer

Application Server

host2

Application Server

SAP AG 2001, TechED 2001 PT1D2P5_Braemer

26

# This problem is independent of SAP Web Dispatcher, it is caused by End-to-end SSL requirement # The only secure way to overcome this problem is to establish a secure channel between load balancing device and Web AS and terminate the SSL encryption on the load balancing device # This is what SAP is planning for a future release > 6.20

26

Planned SAP Web Dispatcher Features (Release >6.20)


Secure channel between SAP Web Dispatcher and ICM SAP Web Dispatcher becomes "Part of the Web AS System" Terminate SSL in SAP Web Dispatcher

New features
" Use HTTP header for session persistence " Forward client certificate information to SAP Web AS " Allow multiple logon groups in one SAP Web Dispatcher " Allow multiple SAP Web Dispatchers for same group of servers

SAP AG 2001, TechED 2001 PT1D2P5_Braemer

27

# SAP is planning to establish secure channel between SAP Web Dispatcher and Web AS in the future # Now SAP Web Dispatcher becomes effectively an integral part of the Web AS system. # Therefore we can terminate SSL session in the Web Dispatcher without violationg our "end-to-end SSL" requirement

Details: # The server certificate now resides on the SAP Web DP # This enables complete freedom of server groups attached to one SAP Web DP # Request URL is seen by SAP Web DP # Multiple logon groups can be handled by one SAP Web DP (encoded in URL)

27

Topics

SAP Web Application Server Architecture and Features Technical System Design
" Load balancing " Stateful user sessions " Secure Communication

Solutions
" Web Switch " SAP Web Dispatcher " Network security

Outlook and Conclusion

SAP AG 2001, TechED 2001 PT1D2P5_Braemer

28

28

Network Security
" Use firewall to prevent network based attacks " Application proxy (SAP Web Dispatcher or Web switch) in the DMZ " Web Application Server in internal server network
Secure Server Network (DMZ) Internal Server Network

Web Servers

Applications

Internet
Firewall Firewall

Access Router & Firewall

Firewall

Database

Application Proxy

SAP Web Application Server

SAP AG 2001, TechED 2001 PT1D2P5_Braemer

29

# Where should the components be located in a firwall scenario? # A firewall is used to prevent network attacks on the system. A typical firewall system comprises & An Internet access point with simple filter rules & A so called "demilitarized zone" (DMZ) or "secure server network". Servers that are directly accessed from the Internet are located here. Typically Web servers, mail servers adn application proxies for other Web related application that reside in internal networks. & Another filtering software that allows tightly controlled access from servers in DMZ to internel networks. & This is often done by specialized firewall products (like Checkpoint Firewall-1, Cisco PIX or Raptor). Often these products combine the function of access router and inner firewall into one product with three (or more) network interfaces: One external interface, one DMZ interface and one internal interface. The administrator can configure the filtering rules between these interfaces. # We generally recommend to place the Web AS in the internal network. Requests from the Internet reach the Web AS through an "application proxy" located in the DMZ. # We do not recommend to position application servers in the DMZ and the database in the internal network, because a firewall between application server and database server may seriously degrade system performance. On the other side, the security benefit is small, because the application server needs full access to the database anyway. # Internal clients can have direct access to Web AS in internal server network via corporate backbone network. However, note the possible problems with Server certificates as mentioned above.

29

Network Security (II)


" Optional high security network with internal firewall

Secure Server Network (DMZ)

Internal Server Network

High Security Network Protected Applications

Web Servers

Applications

Internet
Firewall Firewall
Firewall
Database

Access Router / Firewall

Firewall

Database

Database

Application Proxy

SAP Web Application Server

Internal Firewall

R/3, FI, HR etc.

SAP AG 2001, TechED 2001 PT1D2P5_Braemer

30

# For high security demands a multi layer security concept is possible. # Depending on security ploicy, it may not be appropriate to connect application with very high security demands (like FI, HR etc.) directly to the Internet # Such systems that doe not require direct Web access are located in a separate high security network. A firewall controlls all access to this network (even internal users). # SAP Web AS (which is accessible from the Internet and thus potentially "unsafe") can access internal systems through firewall suing RFC, for example. # Firewall may prohibit opening of connection from Web AS to protected applications alltogether. Only systems in high security network can open connection to Web AS and send or retrieve data from it.

30

Topics

SAP Web Application Server Architecture and Features Technical System Design
" Load balancing " Stateful user sessions " Secure Communication

Solutions
" Web Switch " SAP Web Dispatcher " Network security

Outlook and Conclusion

SAP AG 2001, TechED 2001 PT1D2P5_Braemer

31

31

Outlook: SAP Web Application Server

Dispatcher ICM Work Processes Gateway

RDBMS

SAP AG 2001, TechED 2001 PT1D2P5_Braemer

32

# This is the architecture of the SAP Web AS release 6.10 (that I have described so far)

32

Outlook: SAP Web Application Server (Release 6.20)


Integrated J2EE Server
Dispatcher Gateway

Work Processes

ICM

RDBMS

J2EE Server Processes

J2EE Dispatcher

Technical infrastructure not affected!

SAP AG 2001, TechED 2001 PT1D2P5_Braemer 33

# The next release of SAP Web AS will have an integrated Java Server, which implements the Java 2 Enterprise Edition (J"EE) standard. # This is a very exciting development, and I am sure will be the major topic of next year's TechEd # But not for me, because the good news about this development is: # Technical infrastructure (as discussed I this presentation) will not be affected

33

Conclusion

Thank you for your attention!

Read this presentation and more on technical infrastructure for mySAP.com: http://service.sap.com/network

Time for Questions

???

SAP AG 2001, TechED 2001 PT1D2P5_Braemer

34

34

Copyright 2001 SAP AG. All rights reserved


" " " " " " " " " " "

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, WINDOWS, NT, EXCEL, Word, PowerPoint and SQL Server are registered trademarks of Microsoft Corporation. IBM, DB2, OS/2, DB2/6000, Parallel Sysplex, MVS/ESA, RS/6000, AIX, S/390, AS/400, OS/390, and OS/400 are registered trademarks of IBM Corporation. ORACLE is a registered trademark of ORACLE Corporation. INFORMIX-OnLine for SAP and Informix Dynamic ServerTM are registered trademarks of Informix Software Incorporated. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, the Citrix logo, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, MultiWin and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc. HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. JAVA is a registered trademark of Sun Microsystems, Inc. JAVASCRIPT is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.com are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other products mentioned are trademarks or registered trademarks of their respective companies.

"

SAP AG 2001, TechED 2001 PT1D2P5_Braemer

35

35