WAS_07_Web

1

Web Infrastructure for the SAP Web AS

SAP AG

2

First, we will explain briefly how the SAP Web AS works and what we mean by Web infrastructure (or HTTP infrastructure) in the first place. (In short, everything needed to get HTTP requests from the browser or any other Web client to the server and the response back).

It is important to realize that the infrastructure plays a crucial role for the robustness, performance and cost of ownership of a business solution. We will talk about how the requirements that business Web applications impose upon the infrastructure differ from those of other Web applications.

In the second half of the lesson we will outline some solution approaches for building a business-ready Web infrastructure for Web AS. One way of building a Web infrastructure for SAP Web AS is based on components that SAP delivers as part of its technology offering (most notably, a software called Web Dispatcher). The other way is to use standard, third party Web infrastructure components, which is just as well since SAP Web AS is based on HTTP as a standard protocol.

© SAP AG 2004, Web Infrastructure for SAP Web AS

After completing this lesson, you will be able to:

Understand the SAP Web infrastructure.

Understand the role it plays for the robustness, performance and cost of ownership of a business solution.

You will learn some solution approaches for building a business-ready Web Infrastructure for Web AS.

Web infrastructure for the SAP Web AS: Lesson Objectives

3

IntroductionSAP Web AS Technical RequirementsSAP’s Load Balancing SolutionsWeb Dispatcher ScenariosAlternative TechnologiesSummary

4

In order to run an application stable, with high performance, security and low costs, the technical infrastructure must support the application in an optimal way.

Technical infrastructure has a very broad range from computer hardware, operating systems, storage devices, high availability solutions to networks, load balancing devices, firewalls etc.

Web infrastructure – consisting of every piece of equipment needed to convey HTTP requests between browser and server – is a crucial part of the technical infrastructure. It deserves special treatment, especially since the subject is both complex and new to most SAP users.

Applications impose special requirements upon the technical infrastructure. This was obvious in the days of proprietary protocols. However, even when using Web standard protocols, the way in which the protocol is used differs strongly between different applications. Therefore we have to describe the requireme7nts of SAP Web applications and describe solutions for these requirements.

Please: Give the IT folks a chance and integrate them into Web projects at an early stage. Integration of new applications into corporate IT infrastructure is a task that does not happen with a snip of your fingers.


Introduction

Applications require appropriate technical infrastructure

Technical infrastructure must ensurePerformance and scalabilityHigh availabilitySecuritySmooth network integration Low cost of ownership

Technical infrastructure depends on the application

Consider technical infrastructure at an early stage in a project!

Web infrastructureplays a crucial part

5

SAP's modern Web applications are based on SAP Web Application Server (Web AS). Here is a high level picture of its architecture. It supports both ABAP as well as J2EE based applications. A special process, the ICM, is responsible for HTTP communication.

Web AS is like any old SAP Application server except that it can serve HTTP requests.

SAP Web AS 6.40 has an integrated Java Server, which implements the Java 2 Enterprise Edition (J2EE) standard. Technical infrastructure (as discussed I this presentation) is not affected

There is also a J2EE-only version of Web AS, which consists of only the green part of the graphic above.


SAP Web Application Server

J2EE basedWeb Applications

Internet Communication

Manager forHTTP access

ABAP basedWeb applications

6

The remainder of the lesson will focus on using SAP Web AS as an HTTP server.

What has to be done in order to offer a business web application in a productive way, e.g. in the Internet? Seems like a trivial question: You find yourself an Internet provider, by a router and then you are online. However, living and surviving in the Internet is little more complicated than that. Especially with a business critical application...

What you need is what we call a Web infrastructure. What we mean by this term is everything that is needed to get HTTP requests from the browser or any other Web client to the server and the response back. Some components involved in this are networks and routers, wide area network connections, load balancing devices, caches, DNS servers and many more.


SAP Web Application Server

Thispresentationis about HTTP infrastructure

It applies both to

Web AS 6.40 ABAP and J2EE

Web AS 6.40 J2EE-only

7


8

CPU intensive Load balancing

CPU usually dominates throughput

Transactional Requires session persistence

Almost every SAP application

Access control Authentication

Variety of methods

SSO influence on DNS domain structure

Security of communication SSL

Everywhere

Option X.509 client Certificate

Security of application servers Firewalls

Currently: HTTP Access to business systems required

Dynamic content Low fraction of cacheable content

Depends on application and usage patterns


Requirements of Business Web Applications

CPU intensiveScalability achieved by load balancing

TransactionalStateful user sessions require session persistence

Access controlUser authentication required

SecurityEncryption of communication (Secure Socket Layer – SSL)Application servers and networks need protection

Dynamic contentLow fraction of cacheable content

9


Load Balancing Mechanisms (Client Side)

RedirectionsSimpleBad user experience and maintenance

DNS based methodsPerhaps OK for intranetOK for global load balancingGenerally not OK for server load balancing

10


Load Balancing Mechanisms (Server Side)

Load balancing deviceTransparent for clientAlways the same URL One official IP address for all application serversOne server certificate for all serversTechnically challengingUsually preferable

LoadBalancer

ApplicationServer

ApplicationServer

ApplicationServer

11

Stateful applications impose special requirements on 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.

he Web AS uses a session ID which is returned with every request in order to recognize the user session in which each request has to be processed.


Stateful User Sessions

Complex applications are usually statefulHold database locks Store intermediate SQL results etc.Session state persistent between requests ("roll area")

HTTP is a stateless protocolSuccessive requests may open a new network connection

SAP Web AS uses session ID to recognize user sessionSession cookiePart of the request URL ("URL rewriting")

12

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.

There is a conflict between application (stateful) and protocol (stateless)

Load balancing device must ensure that all requests belonging to an application session are directed always to the same application server!


Load Balancing + Stateful User Sessions

Requirement: Session persistence(Load balancer must ensure that user gets back to same server)

LoadBalancer

ApplicationServer

ApplicationServer

SessionState

1st request

2nd request

13

These mechanisms can be used to ensure session persistence.

Two of the mechanisms need to look at the data or even modify data passing through.


Persistence Mechanisms

Session ID (Cookie or URL)Detect actual application need for session persistenceRequires no state in load balancer, because SAP session ID contains application server instance nameRequires access to clear text HTTP request

IP address of clientWorks also with encrypted trafficProblems with proxies not good for InternetNo way to detect stateless requestsProblems with alternative host names

Cookies inserted into the data stream by load balancerWorks "out-of-the-box"Problems with some SAP applicationsRequires access to clear text HTTP request

14

Encrypted traffic cannot be looked at or even modified by the load balancing device.

Way out: Load balancer acts as the end point of SSL encryption. This enables better session persistence mechanisms and also inspection of requests before they reach the application server. This is sometimes called "in-depth security".

A different security philosophy is "end-to-end security". It assumes that the server itself is secure and the connection between client and server is the most vulnerable asset. This philosophy prohibits the termination of SSL sessions by any intermediary.

Therefore, end-to-end security does not go together well with load balancing, as it does not allow the use of session ID or cookies for session persistence. IP based persistence is not recommended in the Internet.


Secure Socket Layer

Encryption is required for business applicationsProtect user credentials (e.g. passwords)Data security

Secure Socket Layer (SSL)

SSL encrypts entire communication between browser and server

Server authentication (mandatory)Browser verifies, that server certificate matches URL

Client authentication with X.509 certificates (optional)Server takes identity of user from browser certificate

End point of SSL session is either Application Server (end-to-end security)Web infrastructure component (in-depth security)

15


Load Balancing Design Criteria

Load balancing mechanism (client or server side)

End-to-end SSL or SSL termination in load balancer. Criteria:In-depth vs. end-to-end security, need to inspect traffic Persistence mechanism (session ID or IP address) Client certificate authentication

Cost of device

Performance

Robustness and high availability

Ease of configuration and operation (TCO)

Integration into existing infrastructure and security policy

16

Random list of some special requirements of some SAP applications. Not meant to be complete. This is just to make you aware that there are more things to care about. These requirements do not apply to all applications. We are currently working on a comprehensive list of requirements.


Other Application Specific Requirements (Examples)

All servers belonging to one portal "domain" should be in one DNS domain, and only them.

DNS domain restrictions for Single Sign-on (SSO) cookie (workaround available)Security considerations for SSO cookieCross-frame JavaScript (Portal)

SSL should be re-encrypted if terminated in load balancer.Some applications react on the incoming protocol.

HTTP header "Host:" should be preserved.Beware of Apache 1.3. Use 2.0 with ProxyPreserveHost directive.

17


18

A disadvantage of the Message server load balancing is the redirection of the request, and difficulties to store the Website as favorite.


Message Server Based Redirections

MessageServer

CentralInstance

DialogInstance

DialogInstance

RDBMShttp://web.acme.com

Location: http://web2.acme.com

http://web2.acme.comRemaining user session

19

Simple load balancing built into SAP Web Application Server based on redirections

Not well suited for the Internet because of general problems with redirections

Not easy to integrate into firewall

Need dedicated servers for internal and external (server certificate!)

Perhaps OK for intranet, but consider inconvenience for the users

Not generally recommended for production systems


Message Server Based Redirections

Works out-of-the-box (add one profile parameter)

Just like SAPlogon

No problems with session persistence & SSL

But: user experience not optimal ConfusingNo bookmarkingSuperfluous password dialogs

Each server needs own SSL certificateAdministration overhead

Suitable only for internal systems

20

The SAP Web dispatcher is located between the Web client (browser) and your SAP system that is running the Web application.

The architecture is the same as the Internet Communication Manager, see the Internet Communication Manager (ICM). It uses the same HTTP framework and is likewise structured modularly from subhandlers. But unlike the ICM, the SAP Web Dispatcher does not directly pass incoming requests to a work process – it passes them to the ICM of the application server or to a dispatcher of a SAP J2EE Engine. The response from the application server does not pass via the Web dispatcher again to the client – it goes direct to the client (via a proxy, if the network is configured with one).


Web Dispatcher

SAPWeb

Dispatcher

MessageServer

CentralInstance

DialogInstance

DialogInstance

RDBMS

http://web.acme.com

21


SAPWeb

Dispatcher

MessageServer

CentralInstance

DialogInstance

DialogInstance

RDBMS

http://web.acme.com

Web Dispatcher

Load BalancingSession Persistence

Request Filtering

Automatic configurationretrieval from

Message Server

One URL forall AppServersof one system

Either End-to-end SSLor SSL termination

Software loadbalancing server

Optionalre-encryption

22

Web Dispatcher is not meant to compete with hardware loadbalancers for high end applications.

It is not meant to compete with fully fledged reverse proxies.

It is not a general purpose piece of Web infrastructure.

Web Dispatcher is meant to be an easy solution for SAP customers that need a Web infrastructure solution without massive investments.


Web Dispatcher Features

Web Dispatcher is a software load balancer and application layer gateway for SAP Web AS

No full reverse proxy – not meant to be!

Software delivered free of charge as part of SAP Web AS

"Near zero" configuration and administrationRetrieves system state from message server

Supports SAP Web AS features "out-of-the-box"Persistence mechanisms (cookie formats, URL rewriting)Logon groups, distinguish J2EE and ABAP application ...

Both end-to-end SSL and SSL termination possible

Simple request filtering

23


Web Dispatcher End-to-end SSL Mode

ProClient authentication with X.509 certificatesEnd-to-end data securityLoad balancer is "untrusted" component

ContraPersistence based on client IP address only Load balancing problems

ProxiesEnd-of-sessionBut: IP address based persistence usually OK in intranet

No logon groupsNo distinction between J2EE and ABAP applicationsOnly one Web Dispatcher for every group of servers

24

SSL re-encryption does not triple the CPU load for SSL processing. Reason: The most expensive operation in SSL processing is the key exchange during handshake. Afterwards, the bulk encryption/decryption is not so expensive. Keys can be re-used in subsequent SSL sessions, but only between the same communication partners. Therefore, Web Dispatcher and backend application server have to do the expensive handshake only once (every couple of hours) and only have the load of bulk encryption in the mean time.

Since there are usually many browsers accessing the system at once, Web Dispatcher has to do the handshake with them much more frequently, typically once per logon.

To evaluate how many users the SAP Web dispatcher can serve, you must take the following factors into account:

When a user sends a request, this request can open more than one HTTP connection. Depending on the application a request can open between one and 10 or 20 HTTP connections. The user cannot see how many connections the request opens.

The “think time” is also crucial to the capacity of the Web dispatcher. The think time is the time between two user dialog steps (clicks). During this time there is no active HTTP connection (depending on the timeout).

Another important parameter is the keepalive timeout (icm/server_port_<xx> or icm/keep_alive_timeout), which specifies how long the Web dispatcher keeps the connection open for further inquiries from the request.

For more information see the online documentation SAP Web dispatcher -> Management of theSAPLibrary -> SAP NetWeaver-> SAP NetWeaver Configuration -> SAP Web Application Server-> Management of SAP Web Dispatcher -> The SAP Web Dispatcher Profile Parameters -> Configuration for Large Number of Users. And note number 715400.


Web Dispatcher SSL Termination Mode

ProPersistence based on application session IDLogon groups Detection of application type (ABAP / J2EE), select correct server Request parsing and URL FilteringSystem can be reached using different namesSSL re-encryption is possible

ContraHarder to configureWeb Dispatcher becomes "trusted component"Make sure Web Dispatcher does not become performance bottleneck

25


26

The SAP Web Dispatcher was first delivered with SAP Web AS 6.20 (although it can also be used with SAP Web AS 6.10 systems). Its configuration and operation are simple.

The customer receives here a product that is designed for a throughput up to around 3000 hits per second (HTTP). The SAP Web Dispatcher handles SAP-specific load distribution and is sufficient for the vast majority of cases. In cases of extremely high throughput, a customer can, of course, purchase hardwareWeb switches from third-party vendors.

This often offer additional features such as hardware SSL acceleration.

The SAP Web Dispatcher is a small program (closely related to the ICM) without need of an additional server with a database in the DMZ are therefore entirely


Implementation Area of the SAP Web Dispatcher

27

The SAP Web dispatcher ultimately forwards an HTTP(S) request to a specific application server.

The SAP Web dispatcher first uses a cookie to identify whether the request concerns a stateful application. If this is the case, the request is sent to the application server that is processing this session.

Otherwise, the SAP Web dispatcher must determine whether this is a request for the ICF (“abap”) or the J2EE Engine (“j2ee”).

In the case of a J2EE request, the request is sent to the (internally defined) !J2EE server group, which contains all application servers with SAP J2EE Engines. If the request is an ABAP request, the !DIAG group is selected. This group consists of all application servers with dialog work processes. A logon group is only used if this logon group (maintained in transaction SMLG) is explicitly specified in the ICF service.

Thee SAP Web dispatcher distributes the requests in turn within the selected server group, weighted according to the capacity of the individual servers. The capacity is calculated in the case of an ABAP request from the number of dialog work processes and, in the case of a J2EE request, from the number of server processes. The SAP Web dispatcher collects the information about the server groups from the message server. The HTTP interface of the message server allow you to display the information with a Web browser.


SAP Web Dispatcher: Server Selection & Load Balancing

28

1. If there is at least one SAP J2EE Engine active in the SAP system, the prefix (in the example, /cars) is compared to the prefixes known in the ICF. If the prefix is known, the request is an ABAP request. If the URL contains only one ./. character after the host name, special handling is required. The value of the profile parameter is/HTTP/default_root_hdl determines the destination in this case.

The internal structure of the SAP Web dispatcher is based on the ICM process. A profile file is also used in this case to determine the settings with which the SAP Web dispatcher is started. You can easily copy and use the executable file (sapwebdisp.exe) that SAP makes available for all supported operating systems to a separate host, together with the profile.

The SAP Web dispatcher essentially only needs to know the port at which it should receive HTTP(S) requests (parameter icm/server_port_<x>) and on which host (rdisp/mshost) and with which HTTP port (ms/http_port) it can access the message server.

You start the SAP Web dispatcher with the operating system command sapwebdisppf=<profile file>, where you can set additional options such as trace file and trace level (see the online documentation). You stop the SAP Web dispatcher using a kill command at operating system level.


SAP Web Dispatcher: Server Selection & Load Balancing

29

SSL termination imposes high load, this may not be desirable on central instance. Can use other application server or separate computer as well.

Possible scenario for Internet also, behind a reverse proxy, for example.


Web Dispatcher on Application Server

Web Dispatcher on central instance server or other app. server

On CI not generally recommended forSSL termination

30

Like traditional HA for SAP systems

CI must be reachable by clients at all times under same address (IP takeover)

SSL termination imposes high load, this may not be desirable on central instance.


Simple Web Dispatcher High Availability

Web Dispatcher on central instance server for fail over

High AvailabilityCluster

31

A separate fail over cluster for Web dispatcher is the high end solution.

Another solution is shown later in the presentation: Using a network load balancer to distribute requests between multiple Web Dispatcher hosts. The load balancer also ensures the high availability by health checks of the Web Dispatcher nodes.


Advanced Web Dispatcher High Availability

High availabilitycluster

SAP WebDispatcher

SAP WebDispatcher

CorporateNetworkSAP Web

AS

Fail-Over

RedundantNetwork

Infrastructure

32


Internet

Fire

wal

l SAP WebDispatcher

CorporateNetwork

Fire

wal

l

SAP WebAS

Web Dispatcher In DMZ

Web Dispatcher is an application layer gateway, but does not have full reverse proxy functionality.

Encrypted orclear text traffic

End-to-end SSL orSSL Termination

Possiblyfilter

requests

33


Internal NetworkDMZ Internet Service Network

Internet1

R/3, FI, HRetc.

Fir

ew

all

Database

SAP WebAS

SAP WebDispatcher

Fir

ew

all

Fir

ew

all

Layered Security Zones

Enhanced Security for internal network

RecommendedInternet systems

Back-endsystems

34

Need one Web Dispatcher for every system.

Need separate certificates, because server names differ.

Really need separate IP addresses for SSL, because Host header cannot be used with SSL. For clear text HTTP you can do with one IP address and DNS aliases.


Web Dispatcher For Multiple SAP Web AS

Multiple Web Dispatchers on different (virtual) IP addresses

Recommended

https://web1

SAP WebDispatcher


AS

SAP WebDispatcher


AS

443

443

IP1

IP2

https://web2

35

Cookies do not distinguish between servers on the same host but on different ports.

J2EE engine sets session cookie to path "/", therefore the cookies will overwrite each other. Perhaps there is a way to configure this.

Another reason holds for systems in the Internet: Internet proxies often block outgoing SSL traffic to ports other than 443. For example, SAP's proxy does this.

Too bad, because we could use the same server certificate for both systems.


Web Dispatcher For Multiple SAP Web AS (II)

Multiple Web Dispatchers on different TCP ports

Not recommendedJ2EE session cookies overwrite each other.SSL to port other than 443often not possible

https://web

SAP WebDispatcher


AS

SAP WebDispatcher


AS

443

444

https://web:444IP

36


37

In customers networks you usually find already existing infrastructure were the SAP Web AS can be integrated.

These infrastructures are building up by alternative technologies to the SAP Infrastructure Technologies like the SAP Web Dispatcher.

The main advantages of reusing the existing technologies are generally associated with the homogenization of these Web technologies across the enterprise.

The main disadvantages reside in the lack of integration with SAP NetWeaverscenarios in terms of resource optimization and configuration knowledge.


Other Web Infrastructure Technologies

Alternative TechnologiesHardware load balancer ("Content Delivery Networking")Reverse proxy (optionally with authentication etc.)Standard Web server integrates SAP Web AS services

ProAdditional featuresRe-use existing infrastructureUnified Web infrastructure for all Web systems (SAP and non-SAP)

ContraCost Less integrated with SAP Web ASConfiguration, operation, maintenance requires special expertise

38


Network Load Balancer

MessageServer

CentralInstance

DialogInstance

DialogInstance

RDBMS

SSL

http://shop.abc.com

Web Switch


Manual configuration

Same URL forall AppServers

Either End-to-end SSLor SSL termination,

possibly re-encryption

39


Network Load Balancer

Technology OptionsSimple load balancing switch (layer 2-4) End-to-end SSLWeb Switch (layer 2-7) without SSL termination End-to-end SSLWeb Switch (layer 2-7) with SSL accelerator SSL Termination

Off-the-shelve solutions, appliance type

Integrated with network management systems

Standard high availability solutions

40


Internet

SAPWeb AS

Web SwitchFi

rew

all

Fire

wal

l

Direct Access to Web AS Through Web Switch


Request Filtering

End-to-end SSL orSSL termination

High availabilitysolution

41

Why? Re-use existing Web switch infrastructure, but no need for complicated configuration, because Web Dispatcher handles all the intricacies of the Web AS server selection and load balancing between several SAP Web AS.

SSL termination on Web switch OK, re-encryption by Web Dispatcher possible

SSL session ID stickiness necessary, otherwise excessive SSL handshakes.

Use load balancing with fail over capability if present.

Second firewall could also be between Web switches and Web Dispatchers, in other words, the Web Dispatchers could also be located in server network.

Could install Web dispatchers on application servers.

Not useful for SSL end-to-end


Internet

Network LoadBalancer

Fire

wal

l

SAP WebDispatcher

SAP WebDispatcher

CorporateNetwork

Fire

wal

l

SAP WebAS

Web Dispatcher with Web Switch


Request FilteringNo need for

session persistence

End-to-end SSL orSSL termination

42

Apache can handle this out-of-the-box with mod_proxy.

Web switches often have this possibility, too.

IIS does not have reverse proxy functionality. You can use SAP's J2EE plug-in for Web AS J2EE-only. Does it work for BSP applications???

BSP applications have a specialty: When you start /sap/bsp/app/start.html, BSP framework will redirect you to /sap(QBSCXKJQB=)/bsp/app/start.html (with some variable characters inside the parentheses, that constitute language, theme and possibly the session ID). The Web server must be prepared to handle this.

For load balancing, you can use the Web server, but watch out for complicated requirements of SAP Web AS session persistence. Or you use an additional Web Dispatcher, either on the Web server host, or in the server network.


SAP WebAS

Web Server

Reverse ProxyModule

Fir

ew

all

Static WebPages

Internet

443

Fir

ew

all

/sap*

other

Integration Into Web Server / Reverse Proxy

Integrate SAP Web AS services into Web site

Optional Web Dispatcher for Scaling

Forward requests for/sap* to Web AS

43

General problems with cookie overwriting (see description on slide "Web Dispatcher For Multiple SAP Web AS" above)

Additional requirements:

In the second Web AS configure the application you are using to run on /shop using ICF. In J2EE-only servers, make sure the application URL prefix does not conflict with first server.

Do not alter the URL path component in the Web server, for example, map all incoming requests /C11/sap/bsp/app/start.html to /sap/bsp/app/start.html. This will break, because Web AS uses path-absolute URLs to access some resources. There is no way to configure it to prepend the "/C11" to the absolute paths it generates.

Therefore, all applications must have separate paths configured in the server itself. Consider also the MIME repository paths!

Some applications do not allow configuring their paths, most notably, J2EE application like enterprise portal, for example. In this case it is not possible to run two such applications over the same Web server.


SAP WebAS

Web Server

Reverse ProxyModule

Fir

ew

all

Static WebPages

Internet

Reverse ProxyModule SAP Web

AS

Fir

ew

all

/shop*

other

443

/sap*

Integration Into Web Server / Reverse Proxy

Integrate multiple SAP Web AS into Web site

Not recommended

44


45


Summary

SAP Web AS requires HTTP infrastructure.

Business Web applications are more demanding than ordinary Web apps.

Web Dispatcher is SAP'sWeb Infrastructure offering.

SAP Web AS works also with standard Web infrastructure technologies.

46


You should now be able to:

Understand the SAP Web infrastructure.

Understand the role it plays for the robustness, performance and cost of ownership of a business solution.

Build a business-ready Web Infrastructure for Web AS.

Web infrastructure for the SAP Web AS: Lesson Summary

WAS_07_Web

Documents

Transcript of WAS_07_Web