Planning Guide

Technical Infrastructure
Guide - SAP
NetWeaver™ 2004s
Document Version 2.5 – April 2007
© Copyright 2004 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and
form or for any purpose without the express permission of SAP AG. other SAP products and services mentioned herein as well as their
The information contained herein may be changed without prior respective logos are trademarks or registered trademarks of SAP AG
notice. in Germany and in several other countries all over the world. All other
product and service names mentioned are the trademarks of their
Some software products marketed by SAP AG and its distributors respective companies. Data contained in this document serves
contain proprietary software components of other software vendors. informational purposes only. National product specifications may
vary.
Microsoft, Windows, Outlook, and PowerPoint are registered
trademarks of Microsoft Corporation. These materials are subject to change without notice. These materials
are provided by SAP AG and its affiliated companies ("SAP Group")
IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, for informational purposes only, without representation or warranty of
MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, any kind, and SAP Group shall not be liable for errors or
xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, omissions with respect to the materials. The only warranties for SAP
Tivoli, and Informix are trademarks or registered trademarks of IBM Group products and services are those that are set forth in the express
Corporation in the United States and/or other countries. warranty statements accompanying such products and services, if any.
Nothing herein should be construed as constituting an additional
Oracle is a registered trademark of Oracle Corporation. warranty.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the

Open Group. Disclaimer
Some components of this product are based on Java™. Any code
Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, change in these components may cause unpredictable and severe
VideoFrame, and MultiWin are trademarks or registered trademarks of malfunctions and is therefore expressively prohibited, as is any
Citrix Systems, Inc. decompilation of these components.

HTML, XML, XHTML and W3C are trademarks or registered Any Java™ Source Code delivered with this product is only to be used
®
trademarks of W3C , World Wide Web Consortium, Massachusetts by SAP’s Support Services and may not be modified or altered in any
Institute of Technology. way.

Java is a registered trademark of Sun Microsystems, Inc.

Documentation in the SAP Service Marketplace
JavaScript is a registered trademark of Sun Microsystems, Inc., used You can find this documentation at the following Internet address:
under license for technology invented and implemented by Netscape. service.sap.com/instguides

MaxDB is a trademark of MySQL AB, Sweden.

Terms for Included Open
e. The Customer may distribute original or modified STLport
sources, provided that:
Source Software • The conditions indicated in the above permission notice
are met;
This SAP software contains also the third party open source software
• The following copyright notices are retained when
products listed below. Please note that for these third party products
present, and conditions provided in accompanying
the following special terms and conditions shall apply.
permission notices are met:

Copyright 1994 Hewlett-Packard Company

SAP License Agreement for STLport Copyright 1996,97 Silicon Graphics Computer
SAP License Agreement for STLport Systems, Inc.
between Copyright 1997 Moscow Center for SPARC
Technology.
SAP Aktiengesellschaft Copyright 1999,2000 Boris Fomitchev
Systems, Applications, Products in Data Processing Copyright 2001 SAP AG
Neurottstrasse 16
69190 Walldorf Permission to use, copy, modify, distribute and sell this
Germany software and its documentation for any purpose is
( hereinafter: SAP ) hereby granted without fee, provided that the above
copyright notice appear in all copies and that both that
and copyright notice and this permission notice appear in
supporting documentation. Hewlett-Packard Company
you makes no representations about the suitability of this
( hereinafter: Customer ) software for any purpose. It is provided "as is" without
express or implied warranty.

1. Subject Matter of the Agreement Permission to use, copy, modify, distribute and sell this
a. SAP grants Customer a non-exclusive, non-transferable, software and its documentation for any purpose is
royalty-free license to use the STLport.org C++ library hereby granted without fee, provided that the above
(STLport) and its documentation without fee. copyright notice appear in all copies and that both that
b. By downloading, using, or copying STLport or any portion copyright notice and this permission notice appear in
thereof Customer agrees to abide by the intellectual property supporting documentation. Silicon Graphics makes no
laws, and to all of the terms and conditions of this representations about the suitability of this software for
Agreement. any purpose. It is provided "as is" without express or
c. The Customer may distribute binaries compiled with implied warranty.
STLport (whether original or modified) without any
royalties or restrictions. Permission to use, copy, modify, distribute and sell this
d. Customer shall maintain the following copyright and software and its documentation for any purpose is
permission notices on STLport sources and its hereby granted without fee, provided that the above
documentation unchanged: copyright notice appear in all copies and that both that
Copyright 2001 SAP AG copyright notice and this permission notice appear in
supporting documentation. Moscow Center for SPARC
 Technology makes no representations about the 3. Exclusion of warranty
suitability of this software for any purpose. It is As the STLport is transferred to the Customer on a loan basis and
provided "as is" without express or implied warranty. free of charge, SAP cannot guarantee that the STLport is error-
free, without material defects or suitable for a specific application
Boris Fomitchev makes no representations about the under third-party rights. Technical data, sales brochures,
suitability of this software for any purpose. This advertising text and quality descriptions produced by SAP do not
material is provided "as is", with absolutely no indicate any assurance of particular attributes.
warranty expressed or implied. Any use is at your own 4. Limited Liability
risk. Permission to use or copy this software for any a. Irrespective of the legal reasons, SAP shall only be liable for
purpose is hereby granted without fee, provided the damage, including unauthorized operation, if this (i) can be
above notices are retained on all copies. Permission to compensated under the Product Liability Act or (ii) if caused
modify the code and to distribute modified code is due to gross negligence or intent by SAP or (iii) if based on
granted, provided the above notices are retained, and a the failure of a guaranteed attribute.
notice that the code was modified is included with the b. If SAP is liable for gross negligence or intent caused by
above copyright notice. employees who are neither agents or managerial employees
of SAP, the total liability for such damage and a maximum
Permission to use, copy, modify, distribute and sell this limit on the scope of any such damage shall depend on the
software and its documentation for any purpose is extent to which its occurrence ought to have anticipated by
hereby granted without fee, provided that the above SAP when concluding the contract, due to the circumstances
copyright notice appear in all copies and that both that known to it at that point in time representing a typical
copyright notice and this permission notice appear in transfer of the software.
supporting documentation. SAP makes no c. In the case of Art. 4.2 above, SAP shall not be liable for
representations about the suitability of this software for indirect damage, consequential damage caused by a defect or
any purpose. It is provided with a limited warranty and lost profit.
liability as set forth in the License Agreement d. SAP and the Customer agree that the typical foreseeable
distributed with this copy. SAP offers this liability and extent of damage shall under no circumstances exceed EUR
warranty obligations only towards its customers and 5,000.
only referring to its modifications. e. The Customer shall take adequate measures for the
protection of data and programs, in particular by making
2. Support and Maintenance backup copies at the minimum intervals recommended by
SAP does not provide software maintenance for the STLport. SAP. SAP shall not be liable for the loss of data and its
Software maintenance of the STLport therefore shall be not recovery, notwithstanding the other limitations of the present
included. Art. 4 if this loss could have been avoided by observing this
All other services shall be charged according to the rates for obligation.
services quoted in the SAP List of Prices and Conditions and f. The exclusion or the limitation of claims in accordance with
shall be subject to a separate contract. the present Art. 4 includes claims against employees or
agents of SAP.
Typographic Conventions Icons

Type Style Represents Icon Meaning

Example Text Words or characters quoted Caution
from the screen. These include
field names, screen titles, Example
pushbuttons labels, menu
names, menu paths, and menu
options. Note

Cross-references to other Recommendation

documentation.
Example text Emphasized words or phrases Syntax
in body text, graphic titles, and
table titles.
EXAMPLE TEXT Technical names of system
Additional icons are used in SAP Library
objects. These include report documentation to help you identify different
names, program names,
types of information at a glance. For more
transaction codes, table
information, see Help on Help → General
names, and key concepts of a
Information Classes and Information Classes
programming language when
for Business Information Warehouse on the first
they are surrounded by body
page of any version of the SAP Library.
text, for example, SELECT and
INCLUDE.
Example text Output on the screen. This
includes file and directory
names and their paths,
messages, names of variables
and parameters, source text,
and names of installation,
upgrade and database tools.
Example text Exact user entry. These are
words or characters that you
enter in the system exactly as
they appear in the
documentation.
<Example text> Variable user entry. Angle
brackets indicate that you
replace these words and
characters with appropriate
entries to make entries in the
system.
EXAMPLE TEXT Keys on the keyboard, for
example, F2 or ENTER.
Document History
The technical infrastructure guide is regularly updated on SAP Service Marketplace at
service.sap.com/installnw2004s.

Make sure you have the latest version of the technical infrastructure guide by
checking SAP Service Marketplace immediately.

The following table provides an overview of the most important changes:

Version Important Changes
1.00 (October 2005) First released version
2.0 (February 2006) High Availability updates
2.1 (March 2006) Topology section is added
2.2 (April 2006) Adaptive Computing is introduced
2.3 (June 2006) Relevant SAP Notes are now included
2.4 (December 2006) Usage type EP is separated into two usage types: EP Core
(EPC) and EP. See Enterprise Portal (EP + EPC).
2.5 (April 2007) Updates to some graphics are included
Contents
1 Introduction 1
1.1Target Audience 1
1.2Additional Information 1
1.3Prerequisites 2
2 SAP System Architecture 3
2.1Central Instance 3
2.2Central Services Instance 3
2.3Database Instance 4
2.4Dialog Instance 4
2.5 Topology 4
2.5.1 Strategies for Scalability 4
2.5.2 Single Machine Topology 5
2.5.3 Separating the Database Instance 5
2.6Adaptive Computing 6
3 High Availability Support for Failover Clustering (HA) 7
3.1Protecting System-Critical Components 9
3.1.1 Switchover Units 9
3.1.2 Failure and Switchover of SAP NetWeaver Application Server
Instances 9
3.1.3 Internet Communication Manager (ICM) 10
3.1.4 System Landscape Directory (SLD) 10
3.1.5 Central Services Instance Failure 10
3.1.6 Failure and Switchover of the Database Server 11
3.2High Availability Installation Scenario Rules 13
4 Installable Software Units 14
4.1Systems with Usage Types 14
4.1.1 Application Server ABAP (AS ABAP) 14
4.1.2 Application Server Java (AS Java) 16
4.1.3 Application Server Java (AS Java) and Application Server ABAP (AS
ABAP) as an ABAP+Java System 19
4.1.4 Business Intelligence (BI) 22
4.1.5 Business Intelligence Java Components (BI-Java) 22
4.1.6 Development Infrastructure (DI) 22
4.1.7 Enterprise Portal (EP + EPC) 22
4.1.8 Mobile Infrastructure (MI) 23
4.1.9 Process Integration (PI) 23
4.2Standalone Engines 28
4.2.1 Search and Classification (TREX) 28
4.2.2 liveCache 33
4.2.3 Content Server 34
4.2.4 Job Scheduler 35
4.2.5 Gateway 35
4.2.6 Web Dispatcher 35
5 Web Infrastructure 36
5.1Technical Considerations for SAP NetWeaver AS 36
5.2Load Balancing via SAP Web Dispatcher 37
5.2.1 SAP Web Dispatcher SSL Options 37
5.2.2 SAP Web Dispatcher on an Application Server 38
5.2.3 Hardware Load Balancer vs. SAP Web Dispatcher 38
5.3SAP Web Dispatcher as a Reverse Proxy 38
5.3.1 SAP Web Dispatcher in Demilitarized Zone 38
5.4High Availability 39
5.4.1 Failure of the SAP Web Dispatcher 39
5.4.2 SAP Web Dispatcher in a Switchover Cluster 39
5.4.3 Multiple SAP Web Dispatchers Behind an External Web Switch 40
 Introduction

1 Introduction
The Technical Infrastructure Guide describes how you can distribute the SAP NetWeaver
building blocks on physical hosts, to provide stability, performance and scalability for
productive systems.
This guide covers the following topics:
• Outline of all hosts that are necessary to run the SAP NetWeaver usage types for a
productive system
• The assignment of installable software units to the hosts
• Web infrastructure

1.1 Target Audience

The Technical Infrastructure Guide addresses the following groups:
• System administrators
• Consultants
• Hardware partners
• Switchover software vendors who want to test their products for compliance with the SAP
NetWeaver Application Server
Read this documentation if you want to implement switchover software in an SAP
NetWeaver AS environment and need in-depth technical knowledge. It is also useful if
you want to understand switchover strategies and the technical issues involved.

1.2 Additional Information

We strongly recommend that you also read the SAP High Availability documentation at
help.sap.com/NW2004s Æ SAP NetWeaver 2004s SPS 11 Æ English Æ SAP NetWeaver
Library Æ SAP NetWeaver by Key Capability Æ Solution Life Cycle Management by Key
Capability Æ SAP High Availability.
You can also find it on SAP Service Marketplace at service.sap.com/ha Æ Media
Center.
For information about specific switchover products, contact your hardware and switchover
software vendor. If you have any questions regarding the integration of SAP NetWeaver AS
with a specific switchover product, contact the Competence Centers of SAP’s hardware
partners.
For more information about switchover systems, see the following SAP Notes:

Relevant SAP Notes

Note number Topic

803018 Central note on high availability

You can access the notes on SAP Service Marketplace at service.sap.com/notes.

April 2007 1
Introduction

1.3 Prerequisites
You have to know which installable software units and standalone engines you need and how
your system landscape will look like.
For more information, see the Master Guide - SAP NetWeaver, available on SAP Service
Marketplace at service.sap.com/installnw2004s.

March 2007 2
 SAP System Architecture

2 SAP System Architecture

An SAP system consists of SAP instances. An SAP instance is a group of processes that are
started and stopped at the same time. In SAP NetWeaver 2004s, there are the following
instances:
• Central instance
• Central services instance
• Database instance
• Dialog instance
All instances, except the database instance, are identified by an instance number, which is a
two-digit number between 00 and 97 that is unique on a host. Instances can reside on one
host, or they can be distributed on several hosts.

2.1 Central Instance

Every SAP system must have one central instance, which includes:
• Usage type AS ABAP
Dispatcher
Work processes (dialog, batch, spool, or update)
Gateway
Internet Communication Manager (ICM)
Internet Graphics Service (IGS)
• Usage type AS Java
Java dispatcher
Server processes
Software Deployment Manager (SDM)
Internet Graphics Service (IGS)
When the central services are located on a separate instance, the configuration of the central
instance is the same as the configuration of the dialog instance.
If the central services are not installed as a separate instance, the message server and
enqueue server are part of the central instance.

2.2 Central Services Instance

The central services instance – Java central services instance (SCS) or ABAP central
services instance (ASCS) –), forms the basis of communication and synchronization for the
Java or ABAP clusters.
The ASCS can only be installed for a high availability system with AS ABAP.
A central services instance consists of the message server and the enqueue server:
• Message server
Only one message server can run on each AS Java or AS ABAP usage type. The
message server handles the communication between the dialog instances and also
supplies information to the SAP Web dispatcher about load balancing.
• Enqueue server
The enqueue server contains a lock table that handles logical database locks plus
infrastructure locks set by Java server process. The enqueue server also
synchronizes data in a Java cluster. In usage type AS ABAP, the enqueue server
handles only locks on data objects.

April 2007 3
SAP System Architecture

2.3 Database Instance

The database instance is a mandatory installation component for the installation of an SAP
system. AS Java and AS ABAP have separate database schemes. When AS ABAP with AS
Java (also known as Java Add-In) is installed, the AS ABAP and the AS Java database
schemes are installed in the same database. It is not recommended to use separate
databases for the AS Java and AS ABAP scheme.
The AS Java scheme, named SAP<SAPSID>DB, holds the data stored by AS Java and all
deployed application objects. The ABAP scheme is named SAP<SAPSID>

2.4 Dialog Instance

Dialog instances are optional and can be installed on separate hosts. Dialog instances
include:
• Usage type AS ABAP
Dispatcher
Work Processes (dialog, batch, spool, or update)
Gateway
Internet Communication Manager (ICM)
Internet Graphics Service (IGS)
• Usage type AS Java
Java dispatcher
Server processes
Internet Graphics Service (IGS)

When you add a dialog instance, it belongs to the software cluster. The central instance
initiates an update of the dialog instance so the dialog instance has access to the deployed
applications on that cluster (this also includes usage types such as EP or PI).
A cluster always needs a load balancing solution, for example, SAP Web dispatcher.

2.5 Topology
This section introduces some basic topologies for an SAP system. A topology is a schematic
description of the layout of a system or network. In terms of an SAP system, the topology
describes the arrangement of an application server as a cluster with one or more physical
machines.
The topology of an SAP system also addresses scalability, performance, availability,
maintainability, and security.

2.5.1 Strategies for Scalability

The scenario that is installed on an SAP system might require the application server to scale
up or scale down an application. Therefore, scalability is very important for efficiency,
performance, and cost reduction.
One strategy is to separate the components to different physical machines, so avoiding
multiple uses of resources such as memory, CPU, and so on.
Another strategy for distributing the load is using vertical and horizontal scaling in a cluster
environment:
• Vertical scaling is a technique for a cluster arrangement that includes many dialog
instances created on one physical machine. The single machine needs enough
resources to handle this configuration. We recommend that you monitor performance
and memory before adding a new dialog instance.

March 2007 4
 SAP System Architecture

You can set up vertical scaling whenever required as it does not need any special
installation steps.

Application Server

Machine 1

Dialog
HTTP Dialog
Central Instance DialogInstance
Requests Instance Database
Instance
Central Services

• Horizontal scaling is another clustering technique that separates the dialog instances
across multiple physical machines. This configuration provides failover support and
so ensures high availability of the application server processes. The disadvantages
of this strategy are the increased installation and maintenance effort and also the
cost of additional machines.

Application Server

Machine 1 Machine 3
Machine 2 Machine 4
HTTP Central Instance Dialog
Requests Database
Instance
Central Services

2.5.2 Single Machine Topology

This type of topology presents a configuration where all components reside on the same
machine. It is easy to install and maintain and is therefore appropriate for first-time
installations when you want to test and familiarize yourself with the functions of the
application server. At this stage, it is easy to determine what kind of topology is needed and
to plan the system landscape.
Although this topology is easily and cheaply configurable, it has some drawbacks that you
must consider. Since all components are located on a single machine, they compete for
resources, which affects the performance processes. In addition, the components cannot be
additionally secured with firewalls and high availability is not supported.
This configuration can be enhanced with horizontal scaling.

2.5.3 Separating the Database Instance

Separating the database instance to a separate host avoids multiple uses of the same
resources, as we discussed above in the drawbacks of a single machine topology. Apart from
the improved performance, locating the database instance on another physical machine lets
you implement high availability solutions. The database is a critical component and it is
therefore very important to ensure high availability for it.
Nevertheless, hosting the database instance on a separate machine adds to the complexity
because you need to configure, maintain, and back up another entity.

April 2007 5
SAP System Architecture

2.6 Adaptive Computing

SAP NetWeaver enables adaptive computing, in which hardware, software, and system
services are able to adapt to changing business needs. SAP NetWeaver provides the
platform for users to run any service anytime on any server, and it provides a central point of
control for flexible computing-resource assignment, the Adaptive Computing Controller, which
is a central component.
It enables the users of ACC to control the whole landscape from a single point through
observation, operation and dynamic resource distribution. The run-time data of logical and
physical landscapes can be monitored, application services can be started/stopped/relocated,
and hardware resources can be assigned to application services. The operation can also be
mass executed and be planned as tasks to be executed.
The observation is the gathering of run-time information of logical and physical landscapes,
such as the application service status, server CPU and memory utilization, and the mapping
relationship between the application service and server.
The operation is the start/stop/relocation of application services. The application services can
be dynamically started on a server according to the work load and ability of the servers. Stop
refers to stopping the running of the application service. Relocate refers to first stopping the
application service, then re-starting the application service on a different server. The user can
also specify the server on which the application service will be started or relocated to.
Mass Operation provides the mass start/stop operations for starting and stopping services.
The user can perform the same start/stop operations for all the services under same level.
The Task Planner schedules tasks for future execution once or repetitively. The user can plan
the recurrent and future operations on application service. The operation is
start/stop/relocation of application services.
User Exits that provides the possibility to call external functionality directly before and after an
application service has been started or stopped.
For more information about Adaptive Computing, see service.sap.com/adaptive.

March 2007 6
 High Availability Support for Failover Clustering (HA)

3 High Availability Support for Failover Clustering

(HA)
Switchover clusters guarantee high availability of the SAP system by switching critical
software units across multiple hosts in the cluster. When a primary node fails, proprietary
switchover software automatically switches the failed software unit to another hardware node
in the cluster. Applications accessing the failed software unit experience a short delay but
resume normal processing after the switchover.

The term “cluster” is used in information technology in the following different

ways: switchover cluster, software cluster, and database cluster.
The first one, switchover cluster, is described here; the second means the
functionality of redundant application servers, all running the same software.
This has the benefit of high availability but at the same time is also a feature for
scalability. The third term means high availability for databases, which may
come in different flavors.
If you come across the term “cluster”, make sure you understand which
meaning is used.
Switchover clusters also have the advantage that you can release a particular node for
system maintenance by deliberately initiating a switchover. Switchover solutions can protect
against hardware failure and operating system failure, but not operator errors or faulty
application software.
SAP NetWeaver introduces the concept of the Server Central Services (SCS) – an instance
that consists of the essential enqueue and message system services only. This has been
standard for AS Java installations and now is possible for AS ABAP also.
The benefit of having a separate SCS instance is mainly in the area of high availability. This
approach concentrates the possible single points of failure of a system into a single instance
and, therefore, ensures isolation just on them. Before the SCS entities were located on a
separate functional instance, it was necessary to extend protection to a complete system.
With the introduction of the SCS, the term "central instance" becomes almost obsolete. Up to
SAP NetWeaver 2004s, the Software Deployment Manager (SDM) is installed on the central
instance, which is a single instance for the cluster. Nevertheless, the SDM is not considered
a single point of failure as deployment on productive systems usually accompanies
downtime.
To reflect this development the, term “dialog instance” is not used any longer in this HA
documentation. From now on, instances running functional services are named "application
server" (AS) instance.
This means that high available SAP NetWeaver systems have only two kinds of instances,
either an SCS or an AS instance. However, as there currently are still two central services
instances in a SAP NetWeaver Add-In installation – one for ABAP and one for Java – they
are called SCS and ASCS.
The critical components in a SAP system are:
• Central services instance (SCS and ASCS) with message server and enqueue
server
• Database instance
• SAP central file system
Other instances can be protected by running them redundantly. For example, you can add
additional application servers.

April 2007 7
High Availability Support for Failover Clustering (HA)

A switchover cluster consists of:

• A hardware cluster of two or more different hosts to hold multiple copies of the critical
software units.
• Switchover software to detect failure in a node and switch the affected software unit
to the standby node, where it can continue operating.
• A mechanism to enable application software to seamlessly continue working with the
switched software unit by using virtual network identity of protected instances.

Design the switchover cluster together with your hardware partner. The switchover product
has to match your operating system.

We strongly recommend that all the hosts used for switchover have the same
operating system.

Assuming that central services instance is running under the operating system
Microsoft Windows and the DB on a UNIX platform, the central services
instance can only switch to another Windows host and the DB to another UNIX
host.

The following figure shows the essential features of a switchover setup:

March 2007 8
 High Availability Support for Failover Clustering (HA)

The figure above shows several switchover units spanning several hardware
clusters. This is not a required setup. There are many possible switchover
scenarios and it is possible to run a switchover environment for SAP systems
with the minimal configuration of two different hosts.

3.1 Protecting System-Critical Components

This section describes switchover strategies for protecting critical components.

3.1.1 Switchover Units

Switchover components are entities that are combined in a hardware cluster for the
switchover process. In the switchover process, every entity in that component is switched. To
keep the downtime of an entity during switchover as short as possible, switchover groups
must be as small as possible.
The SAP recommendation is to group the critical components of your SAP system into the
following switchover components:
• Central services instance
• Database instance
Distributing the database instance from the ASCS onto two different hosts is
recommended when SAP NetWeaver is running in a multi-host environment with a heavy
database workload.

The saposcol process must run on the DB host to enable CCMS functions.
For more information, see SAP Note 20624
• File system
Several directories in a SAP system are shared among all instances. Protecting files
systems is handled by the cluster software solution provider.

3.1.2 Failure and Switchover of SAP NetWeaver Application Server

Instances
The purpose of distributing the SAP NetWeaver Application Server over several instances is
to avoid switchover procedures. If there is more than one distributed instance of the
application server, then high availability is achieved. In case one application server instance
fails, the user can always reconnect to another application server instance. However, the
current session is lost in this case. If session failover is needed in addition, this is possible for
usage type AS Java. For more information, see help.sap.com/nw2004sÆ SAP
NetWeaver 2004s Æ English Æ SAP Library Æ SAP NetWeaver Library Æ SAP NetWeaver
by Key CapabilitiesÆ Application Platform by Key Capability Æ Java Technology Æ
Administration Manual Æ J2EE Engine Æ Application Management Æ Failover System
Failover on application server instances is not recommended for performance reasons.
These instances are much bigger then the SCS instances and need more resources for the
switchover process. Nevertheless, it is a possible setup.

April 2007 9
High Availability Support for Failover Clustering (HA)

3.1.3 Internet Communication Manager (ICM)

The ICM lets the SAP system communicate with the outside world using the HTTP, HTTPS
and SMTP protocols. In its role as a server, the ICM can process requests from the Internet
that arrive as URLs with the server/port combination that the ICM can listen to. The ICM then
calls the relevant local handler for the URL in question.
The Internet Communication Manager (ICM) is implemented as an independent process
started and monitored by the ABAP dispatcher.

ICM Server Cache

The ICM Server Cache saves HTTP objects before they are sent to the client.
The HTTP request handler uses the ICM Server Cache when, for example, response pages
need to be re-used, such as the entry page of an online shop application. The first time, the
request is processed in the backend. The response is stored by the ICM server cache before
it is sent to the client. When the page is requested again, the application gets the page
directly from the ICM, when the expiration date has not expired, sends it to the client and the
work process does not have to be opened. The result is much better performance.

Failure of Internet Communication Manager

When the Internet Communication Manager (ICM) fails, the affected instance cannot
communicate using Internet protocols. Communication using the dispatcher is not affected.
Therefore, the ABAP dispatcher restarts the ICM when it detects a failure. As the ICM does
not hold state information, only active requests are affected.
As there is an ICM for each SAP Web NetWeaver AS instance, it is not a critical component
and does not need further protection.
Sessions that have used the ICM get an error for a recurring request. Using the SAP Web
dispatcher, the sessions are directed to another server. Using message-server based
redirection, the user has to initiate a new redirection to access the message server.

For more information on the ICM, see help.sap.com/NW2004s:

SAP NetWeaver 2004s Æ English Æ SAP Library Æ SAP NetWeaver Æ
Application Platform (SAP Web Application Server) Æ Architecture of the SAP
Web AS Æ Internet Communication Manager (ICM)

3.1.4 System Landscape Directory (SLD)

The System Landscape Directory (SLD) is the central directory of system landscape
information relevant for the management of your software lifecycle. It contains a description
of your system landscape (that is, the software units that are currently installed) and a
repository of software units that can be installed in your landscape.
The SLD can be installed as one single central SLD, as one central SLD with sub-SLDs or
multiple standalone SLDs.

3.1.5 Central Services Instance Failure

The most critical part of a central services instance failure is the loss of the enqueue server.
The locks held by the SAP system are lost and the enqueue server has to be restarted
(unless you are using a replicated enqueue server). The message server is also disabled.
Communication between the different application servers in the distributed system also fails
or is impeded.

March 2007 10
 High Availability Support for Failover Clustering (HA)

SAP NetWeaver 2004s ensures database consistency by disabling enqueue transactions

when the enqueue server is not available.
After the central services instance has been switched over to another host, it has to be
restarted. However, external SAP NetWeaver application servers on different hosts
might still be holding open, uncommitted transactions. These can hold enqueue locks
that have been lost but are not visible anywhere in the entire SAP system.
If no precautions are taken, any user in the SAP system can then lock the same object
and change it in the database, which can cause an inconsistent database. Therefore, all
open transactions in the entire SAP system must be aborted and rolled back before the
enqueue server is restarted.

System Impact
The switchover of the central services instance has the following impact on your system:
• Transaction locks that have not yet been committed are lost at a system-wide level.
• All user input for all transactions that have not been finished with the ABAP command
COMMIT WORK needs to be re-entered.
• RFC connections are maintained.
In the case of a planned central services switchover, you need to notify the users and
give them a deadline to commit all their transactions.

To eliminate the enqueue server as a critical component you have to set up the
enqueue server as standalone replicated enqueue server.

Enqueue Replication Server

The enqueue replication server runs on another host and contains a replica of the lock table.
All clients and the replication server are connected to the SCS instance. If the SCS instance
fails, it is restarted by the cluster software on the replication server, and the lock table stored
on the replication server is transferred to the SCS instance. The cluster software also
ensures that access attempts from clients go through the replication enqueue server while
the SCS instance is out of action.
If the replication server fails, it can also be restarted. It retrieves the lock table from the SCS
instance when it restarts. In normal circumstances, the replication server only gets delta
information for the lock table.

3.1.6 Failure and Switchover of the Database Server

You can use DB reconnect in all situations where the database connection fails, such as host
failure, planned shutdown, or temporary interruption of the connection to the database host.
This feature enables automatic reconnection to the database if the last connection was
closed unexpectedly. There are two types of DB reconnect:
• Reconnect to the same database instance
The reconnect to the same database instance is only successful if the error condition
has been resolved.
• Reconnect to a standby database instance
This setup uses parallel database technology, where application hosts are connected
to one database instance with an additional database instance on another host
available as a standby instance.
The reconnect to a standby database instance is normally successful immediately
after the DB failure, if an error does not occur on this instance as well.

April 2007 11
High Availability Support for Failover Clustering (HA)

However, if an instance is (re-)started without being able to access the database, the
instance stops. There is no reconnect at startup time. The same applies to the restarted work
process in usage type AS ABAP: if the initial connect fails, the work process is stopped and is
not restarted.

DB Reconnect – AS ABAP
In the event of a database host failure, the network connection of SAP work processes to the
DBMS is lost. If a work process encounters an error in the database connection, the built-in
“DB Reconnect” mechanism starts, and tries to re-establish the database connection.
The DB reconnect feature makes sure that all work processes of all SAP instances are
automatically reconnected to the DB as soon as the DB service is restarted and becomes
available again. The work processes can transparently recover after temporary DB failure.
To the end user, the temporary DBMS failure is almost fully transparent, apart from the time
taken for the DB service to be switched over and become operational again. The functionality
depends on the type of access service involved – that is, dialog, batch, or update.
For more information about the database reconnect feature for ABAP, see
help.sap.com/nw2004sÆ SAP NetWeaver 2004s Æ English Æ SAP Library Æ SAP
NetWeaver Library Æ SAP NetWeaver by Key CapabilitiesÆ Solution Lifecycle Management
by Key Capabilities Æ SAP High Availability Æ SAP NetWeaver AS ABAP: High AvailabilityÆ
DB Reconnect (AS-ABAP)

Technical Details
The DB reconnect features avoid all work processes being shut down and therefore the SAP
instances do not have to be restarted.
If pre-defined errors are returned from the database call to a work process, this process is set
to “reconnect” status. The transaction run by the process is terminated while the process
keeps running and informs all other work processes (regardless of the type) on the host
about the database restart. If the database is not available, all work processes switch to this
status within a short period of time.
Whenever a user request is received, a work process in this status tries to reconnect to the
database system before it starts the requested transaction. If the database is accessible
again, a work process in the reconnect state lets the transaction start without terminating.
This is transparent to the user. If the database connection cannot be re-established, the
transaction does not start and the user is informed by a popup message about the lost
database connection.
For more information, see SAP Note 98051.

DB Reconnect – AS Java
The DB reconnect has to be handled by the application. Depending on the programming
model used for database access in your applications, SAP Web AS Java provides the
following reconnect mechanisms:
• Connections using OpenSQL and NativeSQL with Java Database Connectivity
(JDBC)
• Connections using VendorSQL with direct JDBC connection
For more details on the database reconnect feature for Java, see
help.sap.com/nw2004sÆ SAP NetWeaver 2004s Æ English Æ SAP Library Æ SAP
NetWeaver Library Æ SAP NetWeaver by Key CapabilitiesÆ Solution Lifecycle Management
by Key Capabilities Æ SAP High Availability Æ SAP Web AS Java: High Availability Æ
System Failure (AS Java) Æ Persistence Layer and Databases.

March 2007 12
 High Availability Support for Failover Clustering (HA)

3.2 High Availability Installation Scenario Rules

The following set of rules is created to serve as a base when setting up custom installation
scenarios. These rules are meant for different operating systems and some of them may be
obsolete for a particular operating system.
1. Database instance and central services instance run in different switchover groups.
Databases have significant impact on switchover due to processing of transaction
logs, thus it is not recommended to include them together with other components in a
switchover unit.
The central services do not use or need a lot of resources; therefore they can be
switched very fast. Thus, it is better to have independent switchover groups for both
services.
2. Java SCS/ABAP SCS instances should be in a single switchover group
As SCS Instances contain quite small processes which are very important to the
whole environment it is recommended to keep them alone in their switchover group.
Thus eliminating the case that SCS instances have to wait for larger processes get
running
3. AS may run in a switchover group.
It is possible to run an application server in a switchover group, but this is not
necessary. In case of a switchover, all user sessions will be lost if the application
does not support session persistence.
4. Several switchover groups may run on the same hardware cluster.
It is possible to run several switchover groups on one hardware cluster if the HA
software allows this. It is also an option, to distribute them to several hardware
clusters.
5. The use of an enqueue replication server is strongly recommended.
The enqueue service handles locks in the application server. In case the service fails
and is not replicated, there may still be running processes in the system that continue
to use old locks. To keep integrity, the server restarts as soon as it detects such
situation. Although this detection only can appear when contacting the enqueue
service, there is a possible short timeframe of risk.
By using a replicated enqueue server, this risk is completely avoided and integrity
can be assured under all circumstances.
6. If ABAP central instance exists, it has to be in a switchover group.
This is only relevant for installations that will be made highly available later and have
been installed in standard mode. In this way, the critical components are part of the
main process that defines the old central instance. You either have to follow this rule
or reinstall your system in HA mode.
7. Additional AS may serve the same SAP System.
It is possible to have additional non-protected application servers in the same
system, either on additional hardware or on the hardware cluster. This does not
influence high availability issues and is only relevant for performance.

April 2007 13
Installable Software Units

4 Installable Software Units

The following section provides detailed information about the most-used installation cases
and specifics for ensuring high availability on them.

4.1 Systems with Usage Types

Usage types determine the role that a system plays in a particular scenario. They represent
the capabilities offered by a collection of installed and configured software components.
Usage types are a new structuring element of an SAP NetWeaver system on a technical
level.

For more information about usage types, see the SAP NetWeaver Master Guide
on SAP Service Marketplace at service.sap.com/installnw2004s

4.1.1 Application Server ABAP (AS ABAP)

AS ABAP is an ABAP system without a J2EE Engine and requires no other usage type.
Mandatory instances of an AS ABAP system are:
• Central instance
• Central services instance
• Database instance

Optional instances are:

• One or more dialog instances

Distributing the Instances

Distributed System

March 2007 14
 Installable Software Units

Central System
In a central system, the database instance is placed on the same host as the ABAP central
instance.

High Availability

Critical Components

AS ABAP Component or Number of System-

Work Process Configurable Units Wide
Critical
Componen
ts
DBMS 1 for each AS ABAP X
Enqueue server 1 for each AS ABAP X
(part of ASCS instance)
Message server 1 for each SAP system X
(part of ASCSABAP
central services
instance)
Dialog work process 1…n for each instance
Update work process 1(2)…m for each
instance
Batch work process 0…q for each instance
Spool work process 1…p for each instance
Gateway 1 for each instance
saprouter (WAN access) 0…r for each AS ABAP
NFS 1 for each AS ABAP X
ICM 1 for each instance
Web Dispatcher Comment: Web X
Dispatcher is a
standalone engine
(*)The SAP Web dispatcher is recommended when you use an SAP system with several SAP
NW application servers for Web applications.

Switchover Scenario
The following sections deal exclusively with host failure and switchover of the DB and SAP
central services instances. NFS is not included in the examples because we consider it to be
part of the operating system, which is handled externally by the switchover product.
The switchover of AS ABAP dialog instances is not included in the SAP NetWeaver
switchover scenarios for the following reasons:
• We strongly recommend that you configure the dialog instances that are critically
important to your business on several SAP NetWeaver hosts to increase failure
resilience. This ensures that a single SAP instance does not contain dialog instances
that are critical system-wide components. Therefore, dialog instances do not
necessarily need to be part of the switchover cluster.

April 2007 15
Installable Software Units

• If you need to centralize a particular work process – that is, batch, update, spool, or
gateway – on one dedicated host, which in effect introduces another system-wide
critical component, configure it as part of the ABAP central services instance on the
switchover cluster. This means that the switchover for ABAP central services
instance then also applies to this work process.

The installations described in this section concern releases of SAP NetWeaver

2004s. For older installations, see the corresponding documentation.

Database instance and ABAP central services instance, each in its own switchover
group, ABAP central instance outside

This is only one of several possible configurations. If your business scenario

requires a different setup of your system, then see Installation Scenario Rules.
[p.13]

Scalability
As a general rule, when all work processes are active most of the time you can add additional
work processes while the host still has enough memory and CPU resources available. The
number of work processes has to be in accordance with the requirements for the dispatcher
to work efficiently.
An additional dialog instance is necessary when all work processes are active most of the
time and the host cannot bear additional work processes.

4.1.2 Application Server Java (AS Java)

AS Java consists of the J2EE Engine and auxiliary services. There is no ABAP application
server.

March 2007 16
 Installable Software Units

Mandatory instances of a Java system are:

• Central instance
• Central services instance
• Database instance
Optional instances are:
• One or more dialog instances

Distributing the Instances

Distributed System

Central System
In a central system, the database instance is placed on the same host as the Java central
instance and the Java central services instance.

High Availability
Critical Components

AS Java Component Number of Configurable System-Wide

or Service Units Critical
Components
DBMS 1 for each AS Java X
Enqueue service 1 for each AS Java (part of X
Java-SCS instance)
Message service 1 for each AS Java (part of X
Java-SCS instance)
SDM 1 for each AS Java (part of X (*)
CI)

April 2007 17
Installable Software Units

Java dispatcher 1 for each Java instance

Java server process 1..m for each Java instance
NFS service 1 for each SAP NetWeaver X
(*) The Software Deployment Manager (SDM) is the component for delivering applications to
AS Java. The SDM is located on the central instance. If it is not available, no new software
components can be deployed to AS Java. However, this might not be an issue in production
environments since software updates already imply “planned downtime”. Therefore we do not
describe high availability measures for the SDM in this document.

Switchover Scenarios
The following sections deal exclusively with host failure and switchover of the DB and Java
central services instances of the AS Java. NFS is not included in the examples because we
consider it to be part of the operating system, which is handled externally by the switchover
product.
The switchover of application server services is not included in AS Java switchover scenarios
because services that are of critical importance to your business on several NetWeaver hosts
are redundantly configured by default. This makes sure that a single SAP instance does not
contain services that are critical system-wide components. Therefore, SAP instances do not
necessarily need to be part of the switchover cluster.
A Java dialog instance is connected with the database using the enqueue server.
When running a server instance only on the idle host and using the switchover software to
shut down the running server instance before switching, you can take advantage of the
resources from both hosts.

Database Instance and Java Central Services instance and Java central services
instance Each in its Own Switchover Group, Java Central Instance Inside

March 2007 18
 Installable Software Units

This is only one of several possible configurations. If your business scenario

requires your system to be set up differently, see Installation Scenario Rules.

For systems with a high load, the database instance and the Java central services instances
should be distributed to different hosts. If you want to reduce the number of idle hosts, you
could run this environment on three hosts, by running only one computer in idle state. When
a switchover occurs, the database or the Java central services instance switches to the
computer that is currently idle.

Scalability
The default number of application threads for AS Java is 40. As a general rule, when all
threads are active most of the time you can add additional server processes while the host
still has enough memory and CPU resources available.
Adding a dialog instance is necessary when all server processes are active most of the time
and the host cannot bear additional server processes.

4.1.3 Application Server Java (AS Java) and Application Server ABAP
(AS ABAP) as an ABAP+Java System
This system variant consists of AS ABAP and AS Java (ABAP+Java system). This means,
that the ABAP central instance is enhanced by a Java stack on the same host.
You can install an ABAP+Java system in one installation run (new system), or you can
enhance an already existing AS ABAP system with a Java Add-In.
Mandatory instances of an ABAP+Java system are:
• Central instance
• Java central services instance
• Database instance

Optional instances are:

• One or more dialog instances

The AS ABAP part communicates with AS Java using standard RFC calls.

April 2007 19
Installable Software Units

Distributing the Instances

Distributed System

Add-In Central Instance Java Central

Services
ICM Add-In Dialog Instance
Instance
ENQ ICM
ABAP Java Server
Dispatcher Dispatcher (Java)
ABAP Java
MSG Dispatcher Dispatcher
Work Server Server
Process Process (Java)
Work Server
Process Process
Gateway SDM ABAP Central
Services Gateway
Instance
ABAP Java
ENQ ABAP Java
Server
IGS (ABAP) IGS

MSG
Server
(ABAP)

Critical components: Database

• Database
• ABAP Central Services Instance ABAP Schema
including
• Enqueue Server for ABAP Java Schema
• Message Server for ABAP
• Java Central Services Instance including
• Enqueue Server for Java
• Message Server for Java
• Central file share /sapmnt/…

Central System
In a central system, the database instance is placed on the same host as the Add-In central
instance of the ABAP+Java system.

March 2007 20
 Installable Software Units

High Availability
The critical components of this scenario include the critical components for AS Java and AS
ABAP.

Database Instance and ABAP/Java Central Services Instance, Each in Its Own Switch-
over Group, Add-In Central Instance Outside
In this scenario, the database instance and central services instances are each in their own
switchover group. This variation keeps the Add-In central instance outside of the hardware
cluster, thus only running necessary parts for switchover in such an environment.

A dialog instance for an ABAP+Java system

This is only one of several possible configurations. If your business scenario

requires your system to be set up differently, see Installation Scenario Rules.

Scalability
The recommendation for an Add-in is to have an AS ABAP and an AS Java Add-in on it.
However, it is possible to add an Add-In DI that only contains AS ABAP in case the
NetWeaver system needs more AS ABAP resources.
A load balancer is needed whenever HTPP/HTTPS requests have to be processed.

April 2007 21
Installable Software Units

4.1.4 Business Intelligence (BI)

Business Intelligence is installed on a central instance of AS ABAP and inherits the high
availability from AS ABAP.
Business Intelligence scales with AS ABAP.

4.1.5 Business Intelligence Java Components (BI-Java)

Business Intelligence-Java is installed on a central instance of AS Java and inherits the high
availability from AS Java.
Business Intelligence-Java scales with AS Java.

4.1.6 Development Infrastructure (DI)

The Development Infrastructure has the following parts:
• Design Time Repository (DTR)
Source management system
• Component Build Service (CBS)
Builds deployable SAP NetWeaver archives
• Change Management Service (CMS)
Manages all phases of development, from the definition of a central development
environment for each software project to quality management and production. The
Change Management Service controls the Design Time Repository and the
Component Build Service.

Distributing the Instances

The Development Infrastructure (DTR, CBS, and CMS) is installed on a central instance of
AS Java.
Component Build Service is a CPU-intensive process and can be distributed to a separate
host with AS Java.
Development Infrastructure inherits the high availability from AS Java and scales with AS
Java.

4.1.7 Enterprise Portal (EP + EPC)

The usage types that comprise the Enterprise Portal
As of SAP NetWeaver 2004s SR2, usage type Enterprise Portal (EP) has been separated
into two usage types: EP Core (EPC) and Enterprise Portal (EP). Usage type EPC provides
the core portal capabilities. Usage type EP now includes all portal add-on capabilities: KM,
Collaboration, Guided Procedures and UWL, but without the core portal functionality. The
Enterprise Portal is installed on AS Java, by using both usage types, EP + EPC.

Distributing the Instances

The application sharing server provides data streaming services that enable application
sharing capabilities provided by SAP NetWeaver Collaboration. The server handles the flow
of data between portal users collaborating through the real-time-collaboration-based
application sharing feature. Real-time collaboration application sharing allows users to share
their Windows desktop or individual applications with other portal users in real-time. Remote
users can interact directly with the shared desktop or application as if they were sitting at the
host's machine.

March 2007 22
 Installable Software Units

Enterprise Portal inherits the high availability from AS Java and scales with AS Java.

4.1.8 Mobile Infrastructure (MI)

The Mobile Infrastructure is installed on a central instance. It inherits the high availability from
AS Java and AS ABAP and it scales with AS Java and AS ABAP.

4.1.9 Process Integration (PI)

Distributing the Instances
The default installation variant for a Process Integration system is the all-in-one installation
where all the central components, namely the central Integration Server, Integration Builder,
and System Landscape Directory (SLD) are installed on one host.

PI All-in-One

AS-Java Runtime
Workbench

AS-ABAP

Integration Builder Integration Server

Business Process Engine

Repository

Integration Engine
Directory

Mapping Runtime

System Landscape Adapter Engine

Directory

All ABAP parts of the Process Integration system run on the central instance of AS ABAP.
The AS Java components are also installed together in one AS Java instance. AS ABAP and
AS Java can be secured as one unit. For scalability reasons, additional dialog instances for
AS ABAP and AS Java can be added on different hosts.
Start with the all-in-one scenario and securing all components of the all-in-one installation
together by using switchover software. Thus, there are no additional actions required to
consider the communication between those components when a switchover is initiated.

April 2007 23
Installable Software Units

Using the all-in-one scenario as your starting point reduces the post-installation
tasks for enabling switchover to a reasonable number and it keeps the
administration of the server cluster as simple as possible.

High Availability
The figure below shows the major PI building blocks. The critical components are marked in
gray.

Web Dispatcher (Optional)

ABAP-SCS Java-SCS
MSG ENQ MSG ENQ Instance
Instance

AS-ABAP Instance AS-Java Instance

Mapping Runtime
Integration Server
Adapter Engine

SLD

NFS Integration NFS

DBMS
Repository

Integration
Directory

Critical Components
PI Component or Service Number of Configurable System-Wide
Units SPOF
AS Java/AS ABAP 1 … n (*)
Enqueue Service X
Message Service X
NFS X
DBMS X
SLD 1…m
Integration Repository Running on AS Java
1 for each AS Java/AS
ABAP (*)
Integration Directory Running on AS Java
1 for each AS Java/AS

March 2007 24
 Installable Software Units

ABAP (*)
Integration Server 1 for each AS Java/AS
ABAP (*)
Central Adapter Engine
Integration Engine Running on AS Java
Business Process Engine Running on AS ABAP
Running on AS ABAP
(*) High availability is inherited from usage type AS Java and AS ABAP. For more information
about critical components, see usage type AS Java and AS ABAP.
Adapters
Adapters may play crucial roles for PI. Adapters are required in communication involving
systems where PI middleware is not built in. It is important to note, however, that the scope of
adapters as critical components is restricted to specific scenarios only. In general, one failing
adapter will not affect the entire PI based landscape like an Integration Server failure.
For example, consider PI-based communication between two legacy SAP systems, which are
accessed by using the RFC adapter at runtime. In this case, the RFC adapter is a critical
component for any mission-critical RFC communication scenario between those two systems.
However, IDoc-based communication with the same application systems (using the IDoc
adapter) is not affected by the runtime availability of the RFC adapter. A failing RFC adapter
of course will not affect independent scenarios running across the Integration Server.

Integration Repository & Integration Directory

System Landscape Directory

Integration Server

Business Process Engine

http http http

Integration Engine
http
J2SE Central Adapter Engine
Adapter
Engine Non-Central Other
Adapter
IDoc Adapter

Adapter Engine Non-Central

Adapter

(optional) Framework
Messaging (optional) Adapter Engines
Queuing (optional)
Adapter
Adapter Msg. Security
File/
File/JDBC/ File/JDBC/ File/JDBC/
JDBC/ RFC
JMS, ... JMS/RFC, ... JMS/RFC, ...
JMS/ RFC
Soap

File Application Application Application

SAP
DB Techn. System Techn. System Techn. System
JMS System File/DB/JMS File/DB/JMS/RFC File/DB/JMS/RFC

April 2007 25
Installable Software Units

Critical Components

PI Adapter Number of Configurable System-Wide

Units SPOF
Central Adapter Engine 1 for each Integration
Server
Adapter Engine (non-central) 1 … m (*)
J2SE Adapter Engine (**) 1…n X
Integration Server based Running on AS ABAP
Adapters (Idoc, plain HTTP)
1 for each Integration
Server (*)
PI to PI (no Adapters) Running on AS ABAP
1 for each Integration
Server (*)
(*) High availability is inherited from usage type AS Java and AS ABAP. For more information
about critical components, see usage type AS Java and AS ABAP.
(**) J2SE Adapter Engine is available for backward compatibility only and should not be
considered in a new SAP NetWeaver system and is not described in this document.

Application Systems
When analyzing the high availability of the entire application landscape, it is helpful to see
application systems as independent systems. The result is:
• An application system as such is a critical component
• Critical components inside an application system must be secured (for example, with
switchover software)
• Resilience to failures in application systems must be discussed
Even if PI is set up in a failure-resilient way with optimized availability, this has no impact
whatsoever on how resilient to failures a sender or receiver system will be. A mission-critical
application scenario needs high availability along the complete communication path.
Application systems can be optimized in their availability by proper configuration and by
implementing switchover software (similar to the Integration Server). For non-SAP systems,
see the documentation of the specific product. For the case of other SAP usage types see
the according sections in this document.

Scalability
Process Integration scales with AS Java and AS ABAP.
Normal Process Integration message traffic enters the Integration Server using the HTTP
protocol. However, if the IDoc adapter is used, message data enters the Integration Server by
using the standard RFC protocol.
Load balancing is also available for the RFC protocol. The AS Java and AS ABAP message
server is used as the call dispatcher. RFC load balancing offers two major benefits for the PI
system:

March 2007 26
 Installable Software Units

• Improved scalability
Calls are parallelized and forwarded to several different AS Java and AS ABAP
instances.
• Improved availability
Any AS Java and AS ABAP of the Integration Server can be the target of the incoming
call. Therefore, it is not necessary that a specific AS Java and AS ABAP instance is
working.
With RFC load balancing activated, the sudden failure of one AS Java and AS ABAP will not
affect the accessibility of the PI system by IDocs.
RFC load balancing can also be used with the RFC adapter of an Adapter Engine. The
adapter then registers several threads at the SAP Gateway of an RFC client system. The
client system can then make use of load balancing by means of multiple SAP Gateway
registration.

April 2007 27
Installable Software Units

4.2 Standalone Engines

Standalone engines of SAP NetWeaver are additional installable software units. They do not
work as full-blown systems of SAP NetWeaver but as standalone engines that provide
specific server functionality in combination with one or more SAP NetWeaver systems.

A full definition list of the standalone engines is available in the Master Guide on
SAP Service Marketplace at service.sap.com/installnw2004s.

High Availability
As a result of the independence of the standalone engines they have to be analyzed in detail
for the occurrence of a potential single point of failure that is introduced through it. Because
such engines are not running on top of any Java or ABAP servers, they cannot profit from
their redundancy.
In consequence this may result in the need of a switchover group for such standalone engine.

4.2.1 Search and Classification (TREX)

Overview
Search and Classification (TREX) offers an integrated set of services. TREX services include
search and retrieval in large document collections, text mining, automatic document
classification, and search and aggregation of structured data in SAP applications. TREX can
handle text from documents in numerous formats, including Microsoft Office formats and
Adobe format (PDF), and more than 30 languages. TREX search options, such as exact,
Boolean, fuzzy, or linguistic searches, and classification options, such as query-based or
example-based classification, provide power and flexibility for end users.
TREX is based on a client/server architecture. The client component is integrated in the
application that uses the TREX functions and allows communication with the TREX servers.
The server component processes the requests; indexes and classifies documents, and
answers search queries.
TREX has the following components:
• Java client and ABAP client
• Web server with TREX extension
• RFC server
• Queue server
• Preprocessor
• Index server
• Name server
The figure below shows the individual components and how they communicate.

March 2007 28
 Installable Software Units

Applications using TREX

SES
(Search Engine Serv ice)
HTTP/HTTP S

ABAP Client Java Client

RFC/SNC

SAP Gateway HTTP/HTTP S TCP/IP

Web Server
RFC Server
TRE X extension
Possible
communication
TCP/IP

paths
Index Server Name
Queue Server TRE X
TRE X engines Server
components

TCP/IP Queues Indices TCP/IP TRE X

Queues Indices
data storages
Other
Preprocessor components

April 2007 29
Installable Software Units

Java Client and ABAP Client

TREX provides programming interfaces (application programming interfaces, APIs) for the
Java and ABAP languages. These interfaces are also called the Java client and the ABAP
client. The interfaces allow access to all TREX functions. You can use the interfaces to create
indexes and queues, to perform indexing and searches. In addition, the interfaces provide
functions for querying the internal status of TREX. The interfaces are part of the NetWeaver
Application Server (NW AS).

Web Server with TREX Extension

The Web server is responsible for the communication between Java applications and the
TREX servers. The application sends requests to the Web server in XML format using HTTP
or HTTPS. The Web server converts the requests to a TREX-internal format and then
forwards them to the responsible TREX servers. A TREX component that enhances the Web
server with TREX-specific functions is installed on the Web server.

RFC Server
The RFC server is responsible for the communication between an SAP system and the TREX
servers. The SAP system sends requests to an RFC server using an SAP Gateway. The
RFC server converts the requests to a TREX-internal format and then forwards them to the
responsible TREX servers.

Queue server
The queue server coordinates the processing steps that take place during indexing. It collects
incoming documents, triggers preprocessing by the preprocessor and further processing by
the index server. The queue server allows documents to be indexed asynchronously. This
has the advantage that you can control the time of indexing. For example, you can schedule
indexing for times when the system load is lower because there are fewer search queries.

Preprocessor
The preprocessor prepares documents and search queries.
Document preprocessing comprises the following steps:
• Loading documents
If the application transmits the documents as Uniform Resource Identifiers (URI) rather
than directly, TREX resolves the URIs. This involves fetching the documents from the
repository that the URIs reference.
• Filtering documents
Documents can exist in various formats, such as Microsoft Word, Microsoft
PowerPoint, PDF, and others. The preprocessor extracts textual content from the
documents and then converts it into the UTF-8 Unicode format for further processing.
• Analyzing documents linguistically
Linguistic analysis involves splitting text into individual words and reducing words to
base forms (stems). The preprocessor uses a lexicon that exists in several languages
for this.
During search queries, the preprocessor performs a linguistic analysis. It transmits the results
of the analysis to the index server, which continues the processing of the document.

March 2007 30
 Installable Software Units

Index Server
The index server is responsible for indexing, classifying, and searching. It receives requests
and forwards them to the TREX engines. The engines provide the actual core functions of
TREX such as:
• The search engine is responsible for standard search functions such as exact, error-
tolerant, linguistic, Boolean, and phrase searches.
• The text-mining engine is responsible for classification, searching for similar
documents (‘See Also’), the extraction of key words, and so on.
• The attribute engine is responsible for searching in document properties, such as
author, creation date, change date, and so on.

Name Server
The name server manages information in the entire TREX system. It makes sure that the
TREX servers can communicate with each other and that they receive all necessary
information. The name server has the following tasks:
• Managing topology data
The topology data includes information on the central components of a TREX system
(TREX servers, indexes, and queues).
• Coordinating replication services
The replication services are only relevant for a distributed TREX system. The name
server has information about which TREX server has a particular data status. It
makes sure that changed data is replicated.
• Load balancing
The name server accepts requests and distributes them to the responsible TREX
servers. It is responsible for distributing indexes and search queries
• Ensuring high availability
The name server launches several watch dogs. They constantly monitor whether the
TREX servers are available. If a TREX is not available, the name server ensures that
the TREX server that is down does not receive any requests.

Search Engine Service (SES)

The Search Engine Service (SES) is not a TREX component, but allows users to search for
business objects using TREX. SES is installed as part of the SAP NetWeaver Application
Server (NW AS) together with the AS (Application Server) usage type. SES accesses TREX
functions through the TREX ABAP client. SES replicates the business objects from the ABAP
application to TREX, so that it can apply TREX search functions to them. When a user enters
a search query, the TREX system responds to it, not the database for the ABAP application.

BI Accelerator (BIA)
The BI accelerator (BIA) allows you to improve the performance of BI queries. The BI
accelerator is based on TREX technology. To use the BI accelerator you need a TREX
installation based on 64-bit architecture. Hardware partners deliver this variant in a
preconfigured form on a blade system as the BI accelerator box. For more information, see
Installation Guide – SAP NetWeaver 2004s Search and Classification (TREX) Multiple
Hosts on SAP Service Marketplace at service.sap.com/installnw2004s.

April 2007 31
Installable Software Units

Distributing the Instances

Search and Classification (TREX) offers a flexible and scalable architecture. Your options
range from a minimal system with one host, to a large distributed server landscape.

Single-Host System
A minimal TREX system consists of a single host that provides all TREX functions (indexing,
classification, and searching). You can use a minimal system as a demo and test system, or
as a production system. For a production system, SAP recommends that you install TREX on
a dedicated host that is used exclusively for TREX.

SAP application host TREX host

HTTP or RFC

Multiple-Host System
You have numerous options for scaling TREX. You use a scaled scenario to distribute the
search and indexing load between several hosts and to ensure the availability of TREX. In a
multiple-host system, the individual hosts are responsible for different tasks depending on
which TREX components run on them. For example, you can set up dedicated search
servers with copies of the original indexes and configure automatic index replication to keep
the copies up-to-date.

Master Slaves

RFC WS
RFC WS

M NS PP
S NS PP
M QS File Server
S IS
M IS
Backup
T

RFC WS
Q Q Q
Q QQ MI MI
M NS PP
B QS
B IS Q
Master Q SI SI Slaves
SN SNQSI

RFC WS RFC WS

M NS PP S NS PP
M QS S IS
M IS

March 2007 32
 Installable Software Units

Explanation of the abbreviations:

• Master server
M NS = Master name server; M QS = Master queue server; M IS = Master index
server
• Slave server
S NS = Slave name server; S IS = Slave index server
• Backup server
B NS = Backup name server; B QS = Backup queue server; B IS = Backup index
server
• Other servers
RFC = RFC server; WS = Web server; PP = Preprocessor
• Data
Q = Queue; MI = Master index; SI = Slave index; SN = Index snapshot;
T = Topology file
TREX also supports blade systems that run on UNIX. A blade system consists of hosts in the
form of server blades. A blade system has the advantage that the initial costs and running
costs for maintaining the system are less than if you were using individual hosts.
For more information about distribution options and implementation, see the following
documentation:
• Installation Guide – SAP NetWeaver 2004s Search and Classification (TREX) Single
Host
• Installation Guide – SAP NetWeaver 2004s Search and Classification (TREX)
Multiple Hosts
The documents can be found at service.sap.com/installnw2004s

4.2.2 liveCache
liveCache is SAP's memory-resident object management technology that enables higher
levels of performance in business processing for mySAP Supply Chain Management (SCM)
and Workforce Deployment (WFD) Server.

Distributing the Instances

You can install liveCache on a host that is separate from SCM or WFD.

High Availability
liveCache has the following high availability options:
• Failover Cluster
A failover cluster consists of a primary and a backup instance on different hosts, both
of which access shared data and logs. In the event of failure, switchover software
switches from the primary to the backup instance so that processing can continue as
normal.
Advantages:
o Rapid and automatic switchover
o Supported by SAP for Windows with Microsoft Cluster Service (but not until
SAP NetWeaver 2004s SR1) or platform partners for UNIX

April 2007 33
Installable Software Units

• Standby Database
A standby database is a copy of the primary database. Log shipping keeps the
standby database up-to-date by regularly importing the log backups from the primary
instance.
If you experience problems with the primary database, you can start operating the
standby database immediately, and continue working without significant downtime.
Advantages:
o No storage system is needed. Therefore standby databases can run in a less
expensive hardware environment.
o Depending on the configuration, you can restore the standby instance to the
status it had at a previous point in time.
• Hot Standby
A hot standby system consists of a master component and one or more standby
components. The hot standby system behaves externally like any normal database
instance. The standby components must run on separate hosts.
Hot standby often uses switchover software to transfer control to the standby
instance.
Advantages:
o Rapid and automatic switchover
o Processing can resume without loss of data
You must always mirror the log areas of the database for all instances. For more information,
see the NW04s installation documentation at service.sap.com/installnw2004s

Scalability
liveCache runs on a single host.

4.2.3 Content Server

Content Server is a separate server instance that is used to store documents or other types
of content related to SAP applications. With the accompanying cache, server content can be
cached, if your company operates at several locations. This reduces the load on the wide
area network when you work with documents.

Distributing the Instances

The content server can run on a host with an AS ABAP instance or run on a separate host.
The content server can run without a DB instance or can have its own DB instance. It cannot
use the DB instance of the AS ABAP.

High Availability
See liveCache.

Scalability
Content server runs on a single host.

March 2007 34
 Installable Software Units

4.2.4 Job Scheduler

Distributing the Instances
The Job Scheduler must be installed on separate host and needs an Oracle 9iR2 or 10g
general purpose database. If you have a central operations hub in your landscape, you can
install the Job Scheduler on this hub.
The main instance of the Job Scheduler is the Process Server.

High Availability
The Process Server can be protected by switchover in a cluster. The Process Server is
switched completely.

Scalability
The Job Scheduler can be scaled by adding Process Servers, running on different hosts.
However, the Job Scheduler license provided by SAP NetWeaver allows the operation on
one host only. An additional license is necessary to add Process Servers.
For more information, see SAP Service Marketplace at service.sap.com/job-
scheduling.

4.2.5 Gateway
AS ABAP can be installed as a standalone gateway. The standalone gateway has no work
process types (dialog, background, update, enqueue, or spool); only the gateway process
(gwrd) is started.
The standalone gateway is also needed on the SLD host to enable the SLD to receive RFC
calls from ABAP data suppliers.
For more information, see usage type AS ABAP.

4.2.6 Web Dispatcher

The SAP Web dispatcher is recommended when you use an SAP system with several SAP
NetWeaver Application Servers for Web applications. It lies between the Internet and your
SAP system. It is the entry point for HTTP(S) requests into your system, which consists of
one or more Web application servers. As a "software Web switch", the SAP Web dispatcher
can reject or accept connections. When it accepts a connection, it balances the load to
ensure an even distribution across the servers.

April 2007 35
Web Infrastructure

5 Web Infrastructure
In order to run an application in a stable manner, with high performance, security and low
costs, the technical infrastructure must support the application in an optimal way. The
infrastructure has a very broad range, from computer hardware, operating systems, storage
devices, high availability solutions to networks, load balancing devices, firewalls and so on.
The Web infrastructure is a crucial part of the technical infrastructure. It consists of every
piece of equipment needed to convey HTTP(S) requests between the browser and server.
The Web infrastructure plays a meaningful role in the stability, performance, and cost of
ownership of a business solution.
This section outlines the technical considerations and load balancing solution approaches for
building a business-ready Web infrastructure for SAP NetWeaver.
For more information about security, refer to the security guide on SAP Help Portal at
help.sap.com/nw2004s → SAP NetWeaver 2004s → English → SAP Library → SAP
NetWeaver → Security → SAP NetWeaver Security Guide

5.1 Technical Considerations for SAP NetWeaver AS

These are the most important technical requirements that must be considered when building
a Web infrastructure:
• Load balancing mechanisms
With load balancing, client requests are distributed across multiple servers of one
SAP NetWeaver system. Load balancing solutions have to be used to scale a SAP
NetWeaver AS system and to improve the overall performance. SAP offers the SAP
Web dispatcher as a software load balancing device. Other third party software or
hardware load balancer can be used as well. The load balancing product has to be
chosen according to the customer’s other Web infrastructure components and
technical requirements. Technical requirements can be ease of configuration,
support of stickiness or high availability.
• Security
Certain security considerations must be made when designing a Web infrastructure.
The most important considerations are the use of http versus https (SSL encryption),
the use of reverse proxies and firewalls. Other considerations may cover the use of
IDS (Intrusion detection systems).

March 2007 36
 Web Infrastructure

5.2 Load Balancing via SAP Web Dispatcher

Message
Server

Central
Instance RDBMS
SAP
Web
Dispatcher
http://web.acme.com

Dialog
Instance

Dialog
Instance

The SAP Web dispatcher is located between the Web client (browser) and your SAP system
that is running the Web application. It forwards the incoming requests to the AS Java and AS
ABAP of the SAP system. The Web dispatcher is a load balancing solution that retrieves
system administration and configuration from the message server.

5.2.1 SAP Web Dispatcher SSL Options

The SAP Web dispatcher supports SSL in three manners:
• End-to-End SSL – The SAP Web dispatcher forwards the HTTPS request without
decrypting it to an (HTTPS-enabled) AS Java and AS ABAP.
This approach provides end-to-end data security and must be chosen if the
application server where the SAP Web dispatcher is running is potentially insecure..
The SAP Web dispatcher cannot read any request data and therefore cannot
interpret any session cookies that may be available (and necessary for stateful
applications). The necessary information for forwarding the request to the correct
server is therefore missing and the SAP Web dispatcher forwards the request based
on the browser’s IP address. This technical restriction results in a suboptimal load
distribution. This option affects CPU performance.
• SSL termination – The SAP Web dispatcher decrypts the HTTPS request and in this
way it reads session cookies and performs the load balancing properly. The
communication between the SAP Web dispatcher and the NetWeaver AS is done
via HTTP (unencrypted). SSL termination increases the need for CPU power.
• SSL re-encryption – The SAP Web dispatcher decrypts the HTTPS request, reads
necessary session cookie information and encrypts the outgoing requests. The
communication between the SAP Web dispatcher and the SAP NetWeaver AS is
done via HTTPS (encrypted). Since the SSL sessions between the SAP Web
dispatcher and the SAP NetWeaver AS can be reused, this option does not need
more CPU power than the SSL termination option.

April 2007 37
Web Infrastructure

5.2.2 SAP Web Dispatcher on an Application Server

In this scenario, the SAP Web dispatcher is situated on the application server of SAP
NetWeaver AS. This scenario is not recommended for productive installations because it
potentially leads to overloading of the hardware and might impose (especially in Internet
scenarios) a security risk.
A better solution is to have the SAP Web dispatcher on a separate host.

5.2.3 Hardware Load Balancer vs. SAP Web Dispatcher

Another solution for HTTP/HTTPS load balancing in a system landscape is using a third party
hardware load balancer. In order to increase availability the hardware load balancer should
be redundant in its components.
The load balancers require more complicated configuration and administration to “fit” to the
AS Java and AS ABAP. Hardware load balancers can have an advantage when it comes to
SSL termination / re-encryption since they use a specialized hardware for the SSL
operations.

5.3 SAP Web Dispatcher as a Reverse Proxy

Apart from being a load balancer, the SAP Web dispatcher can also act as a reverse proxy.
Depending on the situation, the SAP Web dispatcher can act as a load balancer and as a
reverse proxy at the same time. In very complex scenarios, the functions can be shared
among different SAP Web dispatchers.
A reverse proxy acts as an application gateway. The browser communicates only with the
SAP Web dispatcher and there is no direct connection from the browser to the SAP
NetWeaver AS. The SAP Web dispatcher is the gateway between two different networks
(NAT – network address translation). In addition to the feature of separating and connection
different networks, the SAP Web dispatcher can perform content filtering and allow access to
certain resources only.

5.3.1 SAP Web Dispatcher in Demilitarized Zone

Especially in an Internet scenario, a danger of malicious access exists. Therefore, a certain
area of the network is defined as a demilitarized zone (DMZ). The DMZ is protected by
firewalls to prevent unauthorized access.
If the SAP Web dispatcher is used as a reverse proxy, it is highly recommended to install it
inside a DMZ. A DMZ can be quite simple as shown in the figure below but depending on the
security requirements, a multi-layer DMZ can be used.

March 2007 38
 Web Infrastructure

Internet

Firewall

Firewall
SAP Web Corporate
Dispatcher Network
SAP Web
AS-Java
AS-ABAP
AS

5.4 High Availability

The SAP Web dispatcher is a system critical unit and has to be protected by a switchover
system. One scenario is to use third party switchover software and install the SAP Web
dispatcher within this switchover environment. The switchover software is responsible to
assign the virtual resources to the active server.

5.4.1 Failure of the SAP Web Dispatcher

When the SAP Web dispatcher fails, clients no longer have access to functions of the SAP
NetWeaver Application Server using HTTP or HTTPS connections. Therefore, the SAP Web
dispatcher has to be restarted.
High availability at process level can be obtained for UNIX systems via a watchdog
functionality. These functions are not available for Windows systems and are not meant to
substitute a complete hardware cluster solution.
The following command starts a second process of the Web Dispatcher; it needs to be
entered when you start the dispatcher:
sapwebdisp pf=<name_of_the_profile> -auto_restart
This second process monitors the SAP Web dispatcher process and tries to restart it in the
event of failure. If you want to stop the SAP Web dispatcher, make sure that you first stop the
watchdog process (this is started if you stop the other process).
Stopping the watchdog also stops the SAP Web dispatcher work process.

If only the SAP Web dispatcher work process is stopped, the watchdog starts
this process again.

5.4.2 SAP Web Dispatcher in a Switchover Cluster

You can achieve automatic failover by including the SAP Web dispatcher in a switchover
cluster.
The following resources should be protected by the cluster:
• IP address of the SAP Web dispatcher

April 2007 39
Web Infrastructure

• File system with the executable and the profile files (these can be also maintained
locally on each cluster node)
• The application
You can check the status of the process using the PID (you can find this in
dev_webdisp or ev_webdisp_watchdog when using automatic restart).

Internet DMZ Intranet

Switchover Cluster
SAP Web Application Server
Central
Instance
Firewall

Firewall
Standby

RDBMS

DB Server
Web Application
Dispatcher Servers

5.4.3 Multiple SAP Web Dispatchers Behind an External Web Switch

Another way to achieve high availability of the SAP Web dispatcher is to use multiple SAP
Web dispatchers behind an external Web switch. This is a reasonable scenario (despite the
additional effort with external Web switches) if you are already using other Web switches, but
you want to use the simple configuration of the SAP Web dispatcher.
Using multiple Web dispatchers eliminates the need of an HA software, but at the same time
causes major limitations. This scenario does not work if End-to-End SSL is used because
mapping of IP addresses is held in the main memory and the hardware load balancer needs
to forward the request to the correct SAP Web dispatcher. Furthermore, the network load
balancer must support IP forwarding; otherwise, the SAP Web dispatcher will always see the
same IP address and dispatch all requests to the same application server.
Internet DMZ Intranet

SAP Web Application Server

Central
Instance
Firewall

Firewall

Web
Dispatcher

RDBMS
Web switch
(3rd party) DB Server
Web Application
Dispatcher Servers

March 2007 40