Upload
mohd-abdul-raheem
View
217
Download
0
Tags:
Embed Size (px)
DESCRIPTION
sap web admin
Citation preview
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.
© SAP AG 2004, Web Infrastructure for SAP Web AS
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 AG 2004, Web Infrastructure for SAP Web AS
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 AG 2004, Web Infrastructure for SAP Web AS
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
IntroductionSAP Web AS Technical RequirementsSAP’s Load Balancing SolutionsWeb Dispatcher ScenariosAlternative TechnologiesSummary
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
© SAP AG 2004, Web Infrastructure for SAP Web AS
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
© SAP AG 2004, Web Infrastructure for SAP Web AS
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
© SAP AG 2004, Web Infrastructure for SAP Web AS
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.
© SAP AG 2004, Web Infrastructure for SAP Web AS
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!
© SAP AG 2004, Web Infrastructure for SAP Web AS
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.
© SAP AG 2004, Web Infrastructure for SAP Web AS
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.
© SAP AG 2004, Web Infrastructure for SAP Web AS
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
© SAP AG 2004, Web Infrastructure for SAP Web AS
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.
© SAP AG 2004, Web Infrastructure for SAP Web AS
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
IntroductionSAP Web AS Technical RequirementsSAP’s Load Balancing SolutionsWeb Dispatcher ScenariosAlternative TechnologiesSummary
18
A disadvantage of the Message server load balancing is the redirection of the request, and difficulties to store the Website as favorite.
© SAP AG 2004, Web Infrastructure for SAP Web AS
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
© SAP AG 2004, Web Infrastructure for SAP Web AS
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).
© SAP AG 2004, Web Infrastructure for SAP Web AS
Web Dispatcher
SAPWeb
Dispatcher
MessageServer
CentralInstance
DialogInstance
DialogInstance
RDBMS
http://web.acme.com
21
© SAP AG 2004, Web Infrastructure for SAP Web AS
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.
© SAP AG 2004, Web Infrastructure for SAP Web AS
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
© SAP AG 2004, Web Infrastructure for SAP Web AS
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.
© SAP AG 2004, Web Infrastructure for SAP Web AS
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
IntroductionSAP Web AS Technical RequirementsSAP’s Load Balancing SolutionsWeb Dispatcher ScenariosAlternative TechnologiesSummary
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
© SAP AG 2004, Web Infrastructure for SAP Web AS
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 AG 2004, Web Infrastructure for SAP Web AS
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 AG 2004, Web Infrastructure for SAP Web AS
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.
© SAP AG 2004, Web Infrastructure for SAP Web AS
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.
© SAP AG 2004, Web Infrastructure for SAP Web AS
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.
© SAP AG 2004, Web Infrastructure for SAP Web AS
Advanced Web Dispatcher High Availability
High availabilitycluster
SAP WebDispatcher
SAP WebDispatcher
CorporateNetworkSAP Web
AS
Fail-Over
RedundantNetwork
Infrastructure
32
© SAP AG 2004, Web Infrastructure for SAP Web AS
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
© SAP AG 2004, Web Infrastructure for SAP Web AS
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.
© SAP AG 2004, Web Infrastructure for SAP Web AS
Web Dispatcher For Multiple SAP Web AS
Multiple Web Dispatchers on different (virtual) IP addresses
Recommended
https://web1
SAP WebDispatcher
CorporateNetworkSAP Web
AS
SAP WebDispatcher
CorporateNetworkSAP Web
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.
© SAP AG 2004, Web Infrastructure for SAP Web AS
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
CorporateNetworkSAP Web
AS
SAP WebDispatcher
CorporateNetworkSAP Web
AS
443
444
https://web:444IP
36
IntroductionSAP Web AS Technical RequirementsSAP’s Load Balancing SolutionsWeb Dispatcher ScenariosAlternative TechnologiesSummary
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.
© SAP AG 2004, Web Infrastructure for SAP Web AS
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
© SAP AG 2004, Web Infrastructure for SAP Web AS
Network Load Balancer
MessageServer
CentralInstance
DialogInstance
DialogInstance
RDBMS
SSL
http://shop.abc.com
Web Switch
Load BalancingSession Persistence
Manual configuration
Same URL forall AppServers
Either End-to-end SSLor SSL termination,
possibly re-encryption
39
© SAP AG 2004, Web Infrastructure for SAP Web AS
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
© SAP AG 2004, Web Infrastructure for SAP Web AS
Internet
SAPWeb AS
Web SwitchFi
rew
all
Fire
wal
l
Direct Access to Web AS Through Web Switch
Load BalancingSession Persistence
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
© SAP AG 2004, Web Infrastructure for SAP Web AS
Internet
Network LoadBalancer
Fire
wal
l
SAP WebDispatcher
SAP WebDispatcher
CorporateNetwork
Fire
wal
l
SAP WebAS
Web Dispatcher with Web Switch
Load BalancingSession Persistence
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 AG 2004, Web Infrastructure for SAP Web AS
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 AG 2004, Web Infrastructure for SAP Web AS
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
IntroductionSAP Web AS Technical RequirementsSAP’s Load Balancing SolutionsWeb Dispatcher ScenariosAlternative TechnologiesSummary
45
© SAP AG 2004, Web Infrastructure for SAP Web AS
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
© SAP AG 2004, Web Infrastructure for SAP Web AS
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