Central Services

Definition
The Central Services run on one physical machine and constitute a Java instance.
They comprise the Message Service and the Enqueue Service.

Use
The Central Services form the basis of communication and synchronization for the Java cluster.

The Message Service keeps a list of the dispatchers and server processes of the Java cluster. It represents the

infrastructure for data exchange (small datasets only) between the participating nodes. The Message Service also

supplies information to the SAP Web Dispatcher about Load Balancing Between Many Java Instances.

The Enqueue Service manages logical database locks, which are set by the executed application program in a server

process. The Enqueue Service also synchronizes data across the cluster.

The section Deployment of a New Application describes how the central components handle the deployment of a new

application.

Integration
The Central Services are always required when a Java cluster is installed. The Central Services instance has its own

system number.

When Central Services are running, further Java instances are started with the program JControl. For more information,

see Java Startup and Control Framework.

Administration of Central Services

Purpose
The use of the Central Services in a Java cluster by J2EE Engine components or applications is interfaced by the Locking

Adapter, Application Locking and Message Info services. The Central Services are the Enqueue Service and the Message

Service, which form one instance in each Java cluster. They perform central tasks in the cluster, such as message and

data exchange, cluster synchronization, and administration of logical locks.

Implementation Considerations
The Central Services’ integration into the J2EE Engine’s enterprise runtime is implemented as Manager components –

the Locking Manager and the Cluster Manager for the Enqueue Service and Message Service, respectively. The Locking

Adapter and Application Locking services use the Locking Manager to connect to the Enqueue Service. This is explained

in the following sections:

Architecture of the Locking Adapter Service

Architecture of the Message Info Service

Integration
The architecture of the Central Services and their functions in an SAP Web AS Java cluster are described in the

Architecture Manual. The following sections are particularly relevant:

Java Instance

Central Services

Features
You can monitor and manage the Central Services at runtime using the Visual Administrator.

The following sections describe how you can use the Locking Adapter service to manage locks and the Message Info

service to view information about the Message Server.

Locking Adapter Service

Application Locking Service

Message Info Service

Visual Administrator contains general documentation about the Visual Administrator.

Java Instance

Definition
A Java instance is a unit in the AS Java cluster, which can be started, stopped, and monitored separately. The cluster

elements that form an instance run on one physical machine. It is also possible to run several instances on one physical

machine. An instance is identified by the system ID (SID) and the instance number.

Central Services are a special example of a Java instance.

Another special instance is the one that runs the SDM ( Software Deployment Manager). This one usually runs with

the database and Central Services on the same machine and is then indicated as the central instance.
Structure
A Java instance contains at least one Server Process.

Normally it comprises one Java Dispatcher and several server processes.

A Java instance is started and stopped by the Java Startup and Control Framework.

Integration
There could be Java instances in mixed ABAP/J2EE systems, as well as in Java-only systems. For more information, see

SAP NetWeaver Application Server with ABAP and Java.

Example
An HTTP request to execute a servlet runs through several layers in the J2EE Engine. The Java dispatcher receives the

request, selects a server process for the processing and establishes the connection from the client to the server.
Java Startup and Control Framework

Definition
The Java startup and control framework comprises the programs JControl and Jlaunch. JLaunch is started

by JControl and itself starts the bootstrap Java program or an element of the Java cluster (dispatcher or

server process).

Use
The Java startup and control framework is used to start, stop, and monitor a Java Instance.
The program JControl starts the Java instance as specified in the configuration file.

Structure
The framework consists of the following components:

 JControl starts, stops, and monitors the processes of a Java instance (usually a dispatcher and several
server processes). The program implements the SAP signal handling to stop the instance. JControl

starts the JLaunch processes.

 JLaunch starts a Java program. It loads the JVM into its own address space and then represents the
required cluster element. The program can receive notification from the JControl process via named

pipes to stop the cluster element, and terminates, if the JControl stops running (fork emulation

under Windows).

 The Bootstrap JAVA program synchronizes the binary data from the Java database with the local file

system and creates a property file, which describes the processes of the Java instance.

The process is described in Startup, Operation and Shutdown of a Java Instance.

Integration
The Java startup and control framework is called in different ways according to the operating system and

installation type:

 Under Windows, the SAP Management Console is used. If you choose Action → Start from the context
menu of an instance containing a J2EE Engine, the JControl program is called.

 Under UNIX and OS/400 platforms, the scripts startsap and stopsap are used to call the program.
  If you start the Java instance using the SAP NetWeaver Developer Studio (NWDS), the client integrated
into the NWDS calls the JControl program.

See also:

Starting and Stopping the SAP System (UNIX)

Starting and Stopping the SAP System (Windows)

Starting and Stopping the SAP Web

AS J2EE System (UNIX)

Use
You need to check that you can start and stop the SAP system after the installation using the scripts startsap and

stopsap in the exe directory.

Prerequisites
 You have signed on to the SAP system hosts as user <sapsid>adm.

 For more information on how to start or stop database-specific tools, see the database-specific

information in this documentation and the documentation from the database manufacturer.
 If you want to use startsap or stopsap (for example, in a script) and require the fully qualified name

of these SAP scripts, create a link to startsap or stopsap in the home directory of the corresponding

user.

If there are multiple SAP instances on one host – for example, a central instance and a dialog

instance – you must add an extra parameter to the scripts:

startsap <instanceID>

stopsap <instanceID>

For example, enter:

startsap DVEBMGS00

SAP Web AS J2EE only system

 The instance name (instance ID) of the central instance is JC<Instance_Number>, the

instance name of a J2EE dialog instance is J<Instance_Number>.

Procedure
Starting the SAP System
1. To start the central instance and database instance:
  If you have a central system – that is, central instance, central services instance and
database instance on the same host – enter the following on the central system host:

startsap

This checks if the database is already running. If not, it starts the database before starting the

central services instance and the central instance.

You can start the database and SAP system separately by entering the following commands:
startsap DB <instanceID>

startsap R3 <instanceID of central services instance>

startsap R3 <instanceID of central instance>

Make sure that you always start the database first because otherwise the central services

instance and the central instance cannot be started.

There is also the parameter J2EE that is a synonym for the parameter R3. For SAP Web AS

ABAP+J2EE systems, you can enter either the command startsap R3 or startsap J2EE to

start the SAP instance comprising both ABAP and J2EE.

  If you have a distributed system – that is, central instance, central services instance and
database instance on different hosts – do the following:

i. On the database host, enter:

startdb

ii. On the central services instance host, enter:

startsap R3

iii. On the central instance host, enter:

startsap R3

2. Enter the following to start dialog instances, if there are any:

startsap
Stopping the SAP System

When you use stopsap in an MCOD (Multiple Components in One Database) system with two

central instances, only one central instance and the database are shut down. Therefore, you
must first stop the other SAP system with stopsap R3 or make sure that it has already been

stopped.

1. Enter the following to stop dialog instances:

stopsap

2. To stop the central instance, the central services instance and the database instance:
  If you have a central system – that is, central instance, central services instance and
database instance on the same host – enter the following on the central system host:

stopsap

This stops the central instance, the central services instance and then the database.

You can stop the SAP system and the database separately by entering the command stopsap

R3 <instanceID of central instance>, then stopsap R3 <instanceID of

central services instance> and then stopsap <instanceID> .

Make sure that you always stop the central instance first and the central services instance

second because otherwise the database cannot be stopped.

There is also the parameter J2EE that is a synonym for the parameter R3. For SAP Web AS

ABAP+J2EE systems, you can enter either the command stopsap R3 or stopsap J2EE to

stop the SAP instance comprising both ABAP and J2EE.

  If you have a distributed system – that is, central instance, central services instance and
database instance on different hosts – do the following:

i. On the central instance host, enter:

stopsap R3

ii. On the central services instance host, enter:

stopsap R3

iii. On the database host, enter:

 stopdb

Make sure that no SAP instance is running before you enter stopdb on a standalone database

server. No automatic check is made.

Starting and Stopping the SAP Web

AS ABAP+J2EE System

Use
You can use this procedure to stop and restart the J2EE Engine in case of the J2EE Engine installed as an

add-in in a SAP Web AS ABAP System.

The J2EE Engine gets automatically started with the ABAP System, but you can stop and restart

the J2EE Engine. If you don’t restart the J2EE Engine it will be launched again with the next

restart of the ABAP System.

Procedure
In the ABAP System start the ICM Monitor (transaction SMICM or by choosing Administration → System

Management → Monitor → System Monitoring → Internet Communication Manager).

On the initial screen of the ICM monitor (Transaction SMICM), choose Administration → J2EE Server.

Choose one of the following functions:

Sending a Soft Shutdown (With or Without a Restart)

The (ABAP) dispatcher of the SAP Web Application Server sets the restart flag for the J2EE Engine and sends

the SOFTSHUTDOWN message to the J2EE Engine. The dispatcher does not actively close the connection,

the J2EE Engine must close itself instead. If the application server is restarted, the J2EE Engine is restarted by

the dispatcher.

1. Sending a Hard Shutdown (With or Without a Restart)

The (ABAP) dispatcher of the SAP Web Application Server sets the restart flag for the J2EE Engine and sends

the HARDTSHUTDOWN message to the J2EE Engine. The dispatcher does not actively close the connection,

the J2EE Engine must close itself instead. If the application server is restarted, the J2EE Engine is restarted by

the (ABAP) dispatcher.

1. Ending the Process (With or Without a Restart)

The SAP Web Application Server’s dispatcher sets the restart flag for the J2EE Engine and sends a signal to

the process (shell or Java process). If the application server is restarted, the J2EE Engine is restarted by the

dispatcher.

1. Restart Yes/No

This sets the J2EE Engine’s restart flag.

Starting and Stopping the SAP Web

AS J2EE System (Windows)

Use
You use this procedure to start and stop the SAP system after the installation. You can use the SAP Management Console

or the SAP NetWeaver Developer Studio to start and stop the SAP system.

You have to start the following components:

● Database (SAP DB)

● Central Services (Enqueue Service and Message Service)

● J2EE instance

● Software Deployment Manager (SDM)

Prerequisites
You have administrator rights on the SAP system host.

Procedure
Starting the SAP System using the SAP Management Console
1. On the SAP system host, choose Start → Programs SAP Management Console.

You get the following window:

2. Right-click the SAP system node (C11 in this example) in the left-hand panel and choose Start.

The SAP DB, the Central Services and the SAP J2EE instance start.

You can start only the SAP DB as follows:

 Select the database node.

In the right-hand panel, the Database Manager is displayed.

 In the Database Manager, choose Online.

The database status changes to online (green color).

When the processes are running, you see the following screen:
Monitoring the Status
To display the status of all processes, choose the process list subnode of the required node in the left-hand

panel.

The JControl process starts the dispatcher and the server. To display the dispatcher and server status, choose

Process Table.

Stopping the SAP System

1. Choose Start → Programs SAP Management Console.

2. In the left-hand panel, right-click the SAP Systems node and choose Stop.

Starting and Stopping the SAP System in the SAP NetWeaver Developer Studio
You can also start the SAP system from within the SAP NetWeaver Developer Studio.

Prerequisite
The SAP DB is running and online. You can start it using the SAP Management Console (see above) or the SAP Database

Manager.

Procedure
1. Choose Window → Preferences → SAP J2EE Engine.

2. Select the option SAP J2EE engine is installed on local host and choose Browse.

You see the system ID of the installed SAP system (e.g. C11).

3. Select the system and choose OK two times.

4. In the top menu, choose Window → Show View → Other → J2EE → J2EE Engine.

The J2EE Engine view is opened.

 5. In the J2EE Engine view, right-click the Local engine node and choose Start local engine.

The processes are started.

6. Click on the Refresh tree icon.

In the right panel of the J2EE Engine view, the status of the process is displayed.

See also:

J2EE Startup and Control Frameworkin the Architecture Manual

Load Balancing:
Load Balancing of Java Applications
The purpose of load balancing is to distribute inbound requests optimally to the available resources.

Technical System Landscape

The SAP NetWeaver AS provides load balancing at various levels.

These are shown as (1) and (2) in the figure below.

  Load balancing between many SAP NetWeaver AS instances (1)

You can start a system with many Java dispatchers, for which the SAP Web Dispatcher or a different

load balancer is already activated as a Web switch. For more information, see Load Balancing

Between Many Java Instances.

 Load balancing within the SAP NetWeaver AS instance (2)

In the Java Instance the Java Dispatcher distributes the inbound requests to the Server

Processes to which it is connected. The Java dispatcher runs the load balancing when the first session

request arrives. The dispatcher ensures that subsequent requests get to the server process that is

processing this session.

For more information, see:

Load Balancing by the Java Dispatcher

Load Balancing for J2EE Web Applications

Registering Server Processes for HTTP Load Balancing

Load Balancing by the Java

Dispatcher
The Java dispatcher uses the J2EE Engine Load Balancing System to perform load balancing for various types of client

requests. The Load Balancing System is used to distribute requests to resources within the cluster. When a client

application requests a resource of a server process, the Load Balancing System chooses the most appropriate server
within the cluster to dispatch the request to. This system is implemented in the J2EE Engine by means of the “Round

Robin” algorithm.

Features of the Load Balancing System

The Load Balancing System is used by distributed services only (services that run on the dispatcher and server elements

of the cluster). The services running on the Java dispatcher use this system to determine which server process will work

on the request.

The J2EE Engine Load Balancing System implements the following functions:

Load balancing of system (cluster) resources using the “Round Robin” algorithm.

Monitoring each server process for a particular service that can process the incoming request.

The Load Balancing system includes only the server cluster elements that are not stopped or marked for

shutdown:
1. When a server element is shut down, it is excluded from the Load Balancing system. When
a new element is started, it is included in the system.
2. When there is a server process marked for shutdown, it is excluded from the Load
Balancing System. The mark for shutdown option is used if you want to stop a particular
server process without terminating the work of the clients that are currently connected to
it. The J2EE Engine waits for the current requests to be processed and then stops the
corresponding element. After the element is stopped the Load Balancing System stops
sending requests to it.

Load Balancing for J2EE Web

Applications
The J2EE Engine HTTP Provider Service running on the dispatcher performs heterogeneous load balancing for Web

applications. It is an important function when you run distributed applications in a cluster environment. It gives you the

opportunity to run an application on a few cluster nodes, and you can always be sure that the client request to that

application is dispatched to the correct server where the application is available.

The heterogeneous load balancing is a configurable function of the HTTP Provider Service. For more information, see

Configuring Heterogeneous Load Balancing in the Administration Manual. If you have switched off heterogeneous load

balancing, the HTTP Provider Service performs homogeneous load balancing as described in the Homogeneous Load

Balancing for HTTP Requests section of Load Balancing by the Java Dispatcher.
The Heterogeneous Load Balancing Mechanism
Web applications are identified and invoked using their unique application aliases. The HTTP Provider Service running on

the dispatcher keeps a table of records about the Web application alias, and the server IDs of the servers in the cluster

where the corresponding application is started. In this way, the Java dispatcher can direct a client request to the

appropriate server process where the requested Web application is running.

The heterogeneous load balancing mechanism also uses cookies or URL rewriting as an underlying mechanism to

transmit session-related information. The J2EE Engine has defined a load balancing cookie type that defines the format

of the information that the HTTP Provider Service needs in order to perform such load balancing.

For more information about the load balancing cookie format, see J2EE Engine Cookies in the Development Manual.

Heterogeneous Load Balancing and HTTP Requests Parsing

The HTTP Provider Service running on the dispatcher parses client requests. Based on its records (as described above), it

directs the request to the appropriate cluster element to be processed. The following scenarios are possible:

The incoming request is part of a series of requests associated with a user session to a particular Web

application. That is, that request has a load balancing cookie attached to it. The HTTP Provider Service

gets the value of the cookie and directs the request to the server with the corresponding ID.

1. The incoming request is the first request from the client to that particular Web application. That is, it has

no load balancing cookie attached. In this case, if the application is running on more than one server

process in the cluster, the request is directed to a random server among all those that have the

application started on them. With the response, the server will send a load balancing cookie to the client

and all subsequent requests to the same application will be handled as described in the above case.

High Availability Cluster:

High Availability and Failover
An AS Java cluster has the following single points of failure (SPOF):

● Database

● Enqueue Service

● Message Service

The other cluster elements (dispatcher and server processes) represent no SPOFs in the sense that a

breakdown in one of them would not affect the entire system.

● The dispatcher is stateless, this means that running transactions are not hindered. It can be restarted,

or from the outset, two dispatchers can be started.

 ● If a server process fails, the session is terminated. One way of getting round this problem is to make the

session persistent.
For more information about failover at application level, see:

● Failover for J2EE Web Applications

● Failover for RMI-P4 Applications

New Communication Schema

The figure below shows the cluster elements and the communication between them. The single points of failure are

shown at the bottom.

You can see that the server processes do not communicate with each other. The advantage of this communication

schema is that the number of connections only increases linearly with the number of server processes.