J2EE Engine

J2EE Engine
Purpose
In this section you can find information about:
Installation
Describes where to find the installation guides, as well as some basic post-installation
procedures.
Starting and Stopping the J2EE Engine
Describes how to start and stop the J2EE Engine.
J2EE Engine Configuration
Describes how to configure the J2EE Engine.
J2EE Engine Administration Tools
Describes the tools for online and offline administration and configuration of the J2EE
Engine.
Core System Modules
Describes the core modules of J2EE Engine, as well as methods for their configuration.
Application Management
Describes the services mostly used for application administration.
Communication Services
Describes the services that facilitate the communication between remote objects.
Utility Services
Describes the services on the J2EE Engine that offer additional functions to system
components and client applications.
Administration of Central Services
Contains information on using, monitoring, and administrating the Central Services. The
Central Services are formed by the Enqueue and Message Services.
Connecting the J2EE Engine to DBs
Describes the Configuration Manager and Configuration Service. You use these for
connecting to the database, managing the persistent data, and editing the configuration
data of the J2EE Engine services and managers, as well as the applications deployed on
the server.
Reference
Contains reference information about the J2EE Engine.
Installation Information
Installation
You can find the SAP Web AS installation guide on SAP Service Marketplace at
service.sap.com/installNW2004s Installation.
Configuration Steps Following Installation

To use certain functions, you need to carry out certain procedures after the installation of
the SAP Web AS. For more information, see Post Installation Procedures.
Applying for and Installing the SAP License

When you first install a J2EE-only installation of the SAP Web AS, you get a temporary
license. You have to apply for a permanent license from SAP and install it. For more
information, see Licensing the J2EE Engine.
Ports
For more information about J2EE Engine ports, see J2EE Engine Ports.
Post-Installation Procedures
Purpose
This section describes the different post-installation procedures you can perform if want to use
certain features on the J2EE Engine.
Process Flow
Creating a second administrator user
To prevent locking the administrator in case you do change its password and forget to
update the entry secure storage, we also recommend you create a second administrator
user after installing the J2EE Engine.
Add-In installation only:
Specifying the J2EE Engine Client to Use for Logon Tickets
Single Sign-On using logon tickets requires a client from the ticket-issuing system. For this
purpose, the J2EE Engine uses the client 000 per default. However, the system ID and
client combination must be unique when tickets are to be accepted by an SAP Web AS
ABAP system. Therefore, in an Add-In installation, you have to change the default client
(000) to a client that does not exist on the SAP Web AS ABAP system.
See also:
Using SSL and SNC for Transport Layer Security
Secure Storage for Application-Specific Data
Specifying the J2EE Engine Client to Use for Logon

Tickets
Use
When issuing logon tickets, it is necessary to make sure that the users ID for which the
logon ticket has been issued is unique. For SAP Web AS, this includes determining the
system ID and the client where the user exists. These attributes are necessary when
maintaining the access control list in accepting systems and are therefore included in the
users logon ticket.
When the J2EE Engine is the ticket-issuing system, its system ID is used as specified in
the installation. Although the J2EE Engine does not have a client, it still needs to provide
a client value to use for logon tickets so that the tickets can be accepted by other systems,
for example, from an SAP Web AS ABAP. The default client for the J2EE Engine is 000,
however, you can explicitly set a different value to use.
The system ID and client combination must be unique when tickets are to be
accepted by an SAP Web AS ABAP system. Therefore, in an Add-In installation,
where the system IDs are the same, you must change the default client for the
J2EE Engine (000) to a client that does not exist on the SAP Web AS ABAP system.
You can specify the configuration for logon tickets either in the UME properties or in the
options for the login module CreateTicketLoginModule. The configuration to use
depends on the value of the property ume.configuration.active.
If you use the UME configuration, then to specify the J2EE Engines client set the
property login.ticket_client in the UME property sheet. Otherwise, set the
property client in the options for the login module CreateTicketLoginModule.
(The reason for these two configuration options is to provide for downward
compatibility.)
See the procedures below for information about checking the
ume.configuration.active property and where to set the logon ticket client
property.
Procedure
Checking the Property ume.configuration.active
To check the value of the property ume.configuration.active for the login
module CreateTicketLoginModule, use the Security Provider service. Check for
this parameter in both the policy configurations as well as in the user store configuration.
Checking the Property in the Policy Configurations

1.
2.
1. ...
1. In the Security Provider service, choose Policy Configurations.
2. Select each template or application that uses the login module
CreateTicketLoginModule, for example, the template ticket.
The login module stack for this component appears.
If you do not know which components use the login module, then check the login
module stacks for all of the components.
The table below shows the login module stack for the ticket template as it is
delivered with the J2EE Engine. In this case, the option
ume.configuration.active=true is set in the policy configuration for the

ticket template.
Ticket Template Login Module Stack
Login Modules
Flag
Options
com.sap.security.core.jaas.
EvaluateTicketLoginModule
SUFFICIENT
{ume.configuration.active=true}
BasicPasswordLoginModule
REQUISITE
{}
CreateTicketLoginModule
OPTIONAL
Checking the Property in the User Store Configuration

2. ...
3.
1. In the Security Provider service, choose the User Management tab page.
4.
2. Choose Manage User Stores.
5.
3. Select the login module CreateTicketLoginModule and choose View /
Change Properties.
The options are shown in the Options section.
Recommendation
If the ume.configuration.active property (or any other property) is set in the
policy configurations and not in the login module options in the user store, then we
recommend moving the setting(s) to the user store.
Reason
If properties are set in the login module options in the user store, then these
properties are inherited by the policy configurations that use the corresponding login
module.
However, if a property is set in the policy configurations, then no inheritance will take
affect, even for additional properties that are set in the user store. Therefore, we
recommend only setting options in the user store and not in the policy
configurations.
Setting the J2EE Engine Client

Once you have determined where to specify the logon ticket configuration, set the J2EE
client. For information about where and how to set the property, see the table below.
Setting the J2EE Engines Client
UME Configuration Active or
Inactive
Location of
Configuration
Property to Set
Information
About How
to Set the
Property
ume.configuration.active=
true
UME Property
Sheet
login.ticket_client
See Editing
UME
Properties.
false
Options for the

login module
client
See
Changing the
Login Module
Options for
Creating
Logon
Tickets.
Licensing the J2EE Engine

Once the J2EE Engine has been installed, you can log on, since a temporary license has
automatically been installed.
You then have to request and install a permanent license from SAP.
If you have installed the SAP Web Application Server with ABAP and J2EE, you
can follow the licensing procedure used in earlier releases of the SAP Web AS. The
documentation can be found in SAP License.
There are two types of SAP licenses permanent and temporary licenses
Permanent License
How you go about getting a permanent license from SAP is explained in Requesting and
Installing an SAP License.
Temporary License
If your permanent license has expired, as a short term measure you can install a temporary
license.
In the Visual Administrator choose Server 0 Services Licensing Adapter. Then
choose tab page Runtime Installed Licenses and Install subsequent temporary license.
This is valid for 28 days. By then you should have installed a permanent license again.
Note that you cannot install another temporary license, if the expired license is also
a temporary license.
A newly installed license does not take affect until the J2EE Engine has been
restarted. It is irrelevant whether the license is a permanent or a temporary license.
Specifying the J2EE Engine Client to Use for Logon

Tickets
Use
When issuing logon tickets, it is necessary to make sure that the users ID for which the
logon ticket has been issued is unique. For SAP Web AS, this includes determining the
system ID and the client where the user exists. These attributes are necessary when
maintaining the access control list in accepting systems and are therefore included in the
users logon ticket.
When the J2EE Engine is the ticket-issuing system, its system ID is used as specified in
the installation. Although the J2EE Engine does not have a client, it still needs to provide
a client value to use for logon tickets so that the tickets can be accepted by other systems,
for example, from an SAP Web AS ABAP. The default client for the J2EE Engine is 000,
however, you can explicitly set a different value to use.
The system ID and client combination must be unique when tickets are to be
accepted by an SAP Web AS ABAP system. Therefore, in an Add-In installation,
where the system IDs are the same, you must change the default client for the
J2EE Engine (000) to a client that does not exist on the SAP Web AS ABAP system.
You can specify the configuration for logon tickets either in the UME properties or in the
options for the login module CreateTicketLoginModule. The configuration to use
depends on the value of the property ume.configuration.active.
If you use the UME configuration, then to specify the J2EE Engines client set the
property login.ticket_client in the UME property sheet. Otherwise, set the
property client in the options for the login module CreateTicketLoginModule.
(The reason for these two configuration options is to provide for downward
compatibility.)
See the procedures below for information about checking the
ume.configuration.active property and where to set the logon ticket client
property.
Procedure
Checking the Property ume.configuration.active
To check the value of the property ume.configuration.active for the login
module CreateTicketLoginModule, use the Security Provider service. Check for
this parameter in both the policy configurations as well as in the user store configuration.
Checking the Property in the Policy Configurations

6.
7.
3. ...
1. In the Security Provider service, choose Policy Configurations.
2. Select each template or application that uses the login module
CreateTicketLoginModule, for example, the template ticket.
The login module stack for this component appears.
If you do not know which components use the login module, then check the login
module stacks for all of the components.
The table below shows the login module stack for the ticket template as it is
delivered with the J2EE Engine. In this case, the option
ume.configuration.active=true is set in the policy configuration for the
ticket template.
Ticket Template Login Module Stack
Login Modules
Flag
Options
EvaluateTicketLoginModule
SUFFICIENT
BasicPasswordLoginModule
REQUISITE
{}
CreateTicketLoginModule
OPTIONAL
Checking the Property in the User Store Configuration

4. ...
8.
1. In the Security Provider service, choose the User Management tab page.
9.
2. Choose Manage User Stores.
10. 3. Select the login module CreateTicketLoginModule and choose View /
Change Properties.
The options are shown in the Options section.
Recommendation
If the ume.configuration.active property (or any other property) is set in the
policy configurations and not in the login module options in the user store, then we
recommend moving the setting(s) to the user store.
Reason
If properties are set in the login module options in the user store, then these
properties are inherited by the policy configurations that use the corresponding login
module.
However, if a property is set in the policy configurations, then no inheritance will take
affect, even for additional properties that are set in the user store. Therefore, we
recommend only setting options in the user store and not in the policy
configurations.
Setting the J2EE Engine Client

Once you have determined where to specify the logon ticket configuration, set the J2EE
client. For information about where and how to set the property, see the table below.
Setting the J2EE Engines Client
UME Configuration Active or

Inactive
Location of
Configuration
Property to Set
Information
About How
to Set the
Property
true
UME Property
Sheet
login.ticket_client
See Editing
UME
Properties.
false
Options for the

login module
client
See
Changing the
Login Module
Options for
Creating
Logon
Tickets.

Once the J2EE Engine has been installed, you can log on, since a temporary license has
automatically been installed.
You then have to request and install a permanent license from SAP.
If you have installed the SAP Web Application Server with ABAP and J2EE, you
can follow the licensing procedure used in earlier releases of the SAP Web AS. The
documentation can be found in SAP License.
There are two types of SAP licenses permanent and temporary licenses
Permanent License
How you go about getting a permanent license from SAP is explained in Requesting and
Installing an SAP License.
Temporary License
If your permanent license has expired, as a short term measure you can install a temporary
license.
In the Visual Administrator choose Server 0 Services Licensing Adapter. Then
choose tab page Runtime Installed Licenses and Install subsequent temporary license.
This is valid for 28 days. By then you should have installed a permanent license again.
Note that you cannot install another temporary license, if the expired license is also
a temporary license.
A newly installed license does not take affect until the J2EE Engine has been
restarted. It is irrelevant whether the license is a permanent or a temporary license.
Requesting and Installing the SAP License

Use
You need a valid SAP license to log on to the SAP Web AS. When the SAP Web AS is
installed, a temporary license is also installed, which you must replace with a permanent
license.
Note that with a J2EE+ABAP installation ( SAP Web Application Server with ABAP
and J2EE), you have to import the ABAP license (see SAP License). You can then
ignore this section.
Prerequisites
You have installed the SAP J2EE Engine and started the Visual Administrator.
Procedure
5. ...
1. In the Visual Administrator choose Server 0 Services Licensing Adapter.
The system data that you need to request the license from the SAP Service
Marketplace appears.
Installation number (if it exists)
System ID,
System number (if it exists)
Hardware key
Current release
12. 2. Under the Internet address service.sap.com mySAP Business Suite,
you can get to the initial page of the license key requests in SAP Service Marketplace.
Here you will find all the information you need to request license keys.
13. 3. Enter your e-mail address in the request. The license key will be sent to you
promptly by e-mail. Alternatively, you can also download the license key from the
SAP Service Marketplace.
11.
Do not make any changes to the license key. To import the license key, the file must
not have been changed.
4. In the Licensing Adapter in the Visual Administrator choose Install License

from File.
15. 5. Select the license file that you want from SAP.
14.
Result
The license has been installed.
You can view all the licenses installed in your SAP System, by choosing, in the Visual
Administrator, Server Services Licensing Adapter, then tab Runtime
Installed Licenses.
Additional Information
For more information about requesting license keys, see SAP note 94998.

Purpose
You can start, stop, and monitor the J2EE Engine using the Java startup and control framework.
This framework provides centralized management of the cluster nodes and monitors their life
cycle. In case of cluster node failure, the framework automatically restarts the corresponding
node.
Features
The Java startup and control framework provides the following set of features:
Serves as a single point of administration (starting, restarting, stopping, and monitoring) of
the J2EE Engine nodes, the Message Server and Enqueue Server processes, and the
database.
In case of cluster node failure, it restarts the corresponding node.
Allows adding remote instances to the SAP MMC snap-in.
Provides options for thread dump monitoring.
This option is critical for the analysis of problem situations (for example, the J2EE Engine is
hanging, 100% CPU load, and so on).
Provides options for viewing the JVM output (useful in case of J2EE Engine crash
situations).
Provides options for configuring the J2EE Engine and exporting that configuration in a file
for future use (Windows).
Allows viewing the trace files, the system environment, and the SAP system environment.
The procedure for starting and stopping the J2EE Engine depends on the underlying operating
system. For more information, see the relevant information:
Starting and Stopping the SAP Web AS ABAP+J2EE System
Starting and Stopping the SAP Web AS J2EE System (Windows)
Starting and Stopping the SAP Web AS J2EE System (UNIX)
Safe Mode in the J2EE Engine
For more information about the Java startup and control framework, see the following topics:
Architecture
Administration
Configuration
Monitoring JCmon
Troubleshooting
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 dont restart the J2EE Engine it will be
launched again with the next restart of the ABAP System.
Procedure
6. ...
16. In the ABAP System start the ICM Monitor (transaction SMICM or by choosing
Administration System Management Monitor System Monitoring
Internet Communication Manager).
17. On the initial screen of the ICM monitor (Transaction SMICM), choose
Administration J2EE Server.
18. 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.
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.
Ending the Process (With or Without a Restart)
The SAP Web Application Servers 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.
Restart Yes/No
This sets the J2EE Engines 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
19.
1. On the SAP system host, choose Start Programs SAP Management

Console.
You get the following window:
20.
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:
1. ...
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

21.
22.
7. ...
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
8. ...
23. 1. Choose Window Preferences SAP J2EE Engine.
24. 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).
25.
3. Select the system and choose OK two times.
26.
4. In the top menu, choose Window Show View Other J2EE

J2EE Engine.
The J2EE Engine view is opened.
27.
5. In the J2EE Engine view, right-click the Local engine node and choose
Start local engine.
The processes are started.
28.
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
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 databasespecific 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
29.
9. ...
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:
1.
i. On the database host, enter:
startdb
2.
ii.
startsap R3
On the central services instance host, enter:
3.
iii.
On the central instance host, enter:
startsap R3
30.
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.
10. ...
1. Enter the following to stop dialog instances:
31.
stopsap
32.
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:
2. ...
4.
i. On the central instance host, enter:
stopsap R3
5.
ii.
On the central services instance host, enter:
iii.
On the database host, enter:
stopsap R3
6.
stopdb
Make sure that no SAP instance is running before you enter stopdb on a
standalone database server. No automatic check is made.

Use
When upgrading/patching the J2EE Engine and the components running on top of it, the
system automatically sets the J2EE Engine in safe mode for precaution reasons. That is,
on the next restart the system will leave stopped all the server processes and dispatchers
in the cluster, leaving only the central instance with one dispatcher and one server process
running. This makes it faster and less resource-heavy to perform the desired operation.
Thus, after the upgrade/patching procedure, you may need to manually disable the safe
mode of the J2EE Engine and to restart the whole cluster.
Features
If the J2EE Engine is in safe mode, you will see a warning message or an indicator:
In the SAP MMC, you will see an indicator in the Status field of the JControl process.
In the Visual Administrator when you log on to the J2EE Engine, a warning message will be
displayed.
If you are using Telnet client to connect to the J2EE Engine, you will see an indicator.
In the Config Tool, you can check the mode in which the J2EE Engine is running by choosing
File Safe Mode.
Activities
Use the Config Tool to enable/disable the safe mode function of the J2EE Engine:
11. ...
33. Start the configtool script file from the /usr/sap/<SID>/<instance
name>/j2ee/configtool directory.
34. Choose File Safe Mode.
A dialog box appears.
35. From the Safe Mode Enabled drop-down list, choose:

11 Yes to enable safe mode.
11 No to disable safe mode.
36. Choose OK.
37. Save the settings and confirm all the messages that are displayed.
38. Restart the J2EE Engine.
Architecture of the Java Startup and Control

Framework
Use
This section contains a detailed description of the components of the Java startup and
control framework, their interaction and communication, and architecture
implementation. You can also follow the steps performed when starting, monitoring, or
stopping a J2EE instance and when stopping or restarting the whole J2EE Engine cluster.
For more information about these topics, see:
Java Startup and Control Framework (contains general information about the components
of the Java startup and control framework)
Startup, Operation and Shutdown of a Java Instance

11 Shutdown and Restart of the Whole J2EE Engine Cluster
Integration
For more information about the J2EE Engine cluster and system architecture, and about
the communication between the J2EE Engine and the other components within the SAP
Web Application Server, see the Architecture Manual.
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)
Startup, Operation and Shutdown of a Java

Instance
Purpose
With the Java startup and control framework you can start, monitor, and stop a Java
instance. This means you can:
Restart processes
Send request to shut instance down
Terminate hanging processes
The program JControl is part of the standard delivery.
Process Flow
The following figure shows the flow of the actions that the Java startup and control
framework executes.
Startup of the Java Instance

The following steps are involved in starting the Java instance:
JControl is started (in Windows by the SAP start service; on UNIX platforms by the
startsap script).
JControl initializes the SAP signal handling to be able to handle signals received.
JControl starts JLaunch with the bootstrap.properties file (1). This executes the
following steps:
The first argument of JLaunch is the PID of the parent process

(JControl). JLaunch starts a thread, which ends the JLaunch process, if the
parent process, JControl, fails.
Creates Java Virtual Machine (JVM) arguments and initializes hosting of the
virtual machine (VM).
Loads the VM into its own process, initializes the VM and starts the
bootstrap program.
The bootstrap program synchronizes the binary data of the Java database with
the local file system (2).
The bootstrap program reads the Java instance description from the Java
database and writes the file instance.properties (3). The file
instance.properties contains the description and the arguments of the AS Java
cluster elements that are to be started.
JControl reads and creates a list of the AS Java cluster elements to be started (4).
JControl starts a JLaunch process for each cluster element (5). This executes the
following steps:
The first argument of JLaunch is the PID of the parent process

(JControl). JLaunch starts a thread, which ends the JLaunch process, if the
parent process, JControl, fails.
Creates JVM arguments and initializes hosting of the VM.
Loads the VM into its own process, initializes the VM and starts the Java
cluster element. This executes the following steps:
Starts the offline configuration manager to read the properties for the
Java Enterprise runtime from the database and to save them in various hash
tables (6).
Stops the offline configuration manager and starts the Java Enterprise
runtime with the saved properties.
Starts the service framework and the services.
See also:
J2EE Engine System Architecture
Operation of the Java Instance

The JControl process monitors the Java instance. It continuously checks the status of
the cluster elements of the instance and restarts terminated processes.
Shutdown of the Java Instance

Signals and named pipes trigger a Java instance to stop. The process ensures that
following a shutdown time interval all cluster elements of the instance are exited.
The figure below shows the communication.
An instance is stopped as follows:
The SAP start/stop environment (start script or SAP Start Service on Windows), which
started the JControl process, sends a SIGINT to the JControl process (1).
JControl sets the status of the Java instance to STOPPING in its list and sends a
notification using a named pipe to all of the running cluster elements (2).
The JLaunch process of the Java cluster element must respond to the notification within a
defined time interval. (If this soft shutdown does not work, the JLaunch process is
completely terminated by JControl.) It triggers the shutdown of the AS Java cluster
element in the JVM and waits for its own VM to terminate (3).
JControl exits.
Shutdown and Restart of the Whole J2EE Engine

Cluster
Purpose
Apart from starting, monitoring, and stopping a single J2EE instance using the startup
framework, you can also shut down or restart the whole J2EE Engine cluster from one
client. This is done through the message server communication of JControl.
Process Flow
The figure below shows the process the flow of the actions that the Java startup and
control framework executes:
Shutdown of the J2EE Engine Cluster

Stopping the J2EE Engine cluster consists of the following steps:
Each JControl program, which is responsible for aJ2EE instance, connects to the message
server and registers the instance inside the J2EE instance list of the message server (1).
JControl waits for notifications from the message server.
The message server clients send the cluster shutdown command to the message server
(2).
The message server distributes the shutdown command to each registered JControl
program (3).
The JControl programs receive the shutdown command and stop the instances.
After all J2EE nodes are stopped, JControl sends the stopped notification back to the client
(4 and 5).
Restart of the J2EE Engine Cluster

The steps are similar to the shutdown scenario:
The client sends the start command to the message server.
The message server distributes the start command to the connected JControl programs.
JControl receives the start command and starts all J2EE nodes of the instances.
JControl sends the started notification back to the client.
Administration of the Java Startup and Control

Framework
Purpose
Use this process to administer the Java startup and control framework.
Process Flow
The administration of the Java startup and control framework consists of the following
procedures:
Administration and Working with the SAP MMC snap-in (for Windows only) see the help
topics in the console (that is, choose Help Help Topics)
Monitoring and interpreting the trace and log files created by the framework, analyzing the
error messages in them, incrementing/decrementing the trace levels, creating stack traces.
For more information, see Developer Trace and Log Files.
See also:
Configuration of the Java Startup and Control Framework
Monitoring JCmon
Troubleshooting
Developer Trace and Log Files

Definition
The trace and log messages of the Java startup and control framework contain important
information about the startup process. In case of errors or misbehavior it will be helpful if
you check and analyze them.
The developer trace and log files are located in the /usr/sap/<SID>/<INSTANCE
NAME>/work directory, where <SID> is the system ID of the cluster (for example, C11)
and <INSTANCE NAME> is the instance name of the J2EE instance (for example,
JC01). In case of a Java-only installation, the instance name consists of a prefix (JC or
J) and the two-digit instance number afterwards.
Structure
dev_jcontrol
The trace file of the JControl process.
JControl is responsible for starting, stopping and controlling the processes of the J2EE
instance.
Use the dev_jcontrol trace file when you have problems starting or stopping the whole
J2EE instance.
We recommend that you always check the end of this file for error messages
regarding the startup of JControl.
dev_<component name>
The trace file of the corresponding JLaunch process (the <component name> can be
bootstrap, bootstrap_<cluster_element_ID>, dispatcher, server<n>, sdm, jcmon,
or icm). For example, the trace file for the bootstrap process is dev_bootstrap.
std_<component name>.out
The standard and error output file of the corresponding JLaunch process (the
<component name> can be bootstrap, bootstrap_<cluster_element_ID>,
dispatcher, server<n>, sdm, or icm). For example, the output file for the bootstrap
process is std_bootstrap.out. Output and error messages from the Java VM are written
to this file.
jvm_<component name>.out
The standard and error output file of the JVM running the corresponding JLaunch process
(the <component name> can be bootstrap, bootstrap_<cluster_element_ID>,
dispatcher, server<n>, sdm, or icm). For example, the output file for the JVM running
the bootstrap process is jvm_bootstrap.out.
For more information in case of errors, see the Trace and Log Files Error Messages.
See also:
Incrementing/Decrementing the Trace Level
Creating a Stack Trace
Trace and Log File Error Messages

The following are some of the most important error messages that may appear in the
dev_jcontrol and dev_<component name> trace files. They describe what you have to do in case
you receive them:
Message server is not available (in dev_jcontrol)
1. Invalid shared library path (in dev_<component name>)
1. Invalid administration shared memory (usually on UNIX)
2. The J2EE Engine does not come up after 800 seconds
Message Server is Not Available (in dev_jcontrol)

During the J2EE instance startup, JControl tries to connect to the message server. If this
fails, you will get an error message like the following in the dev_jcontrol trace file:
*** ERROR => MsIAttach: NiBufConnect to localhost/3604
failed (rc=NIECONN_REFUSED
*** ERROR => Can't attach to message server (localhost/3604)
[rc=-100]-> reconnect
Solution
Check if the central service instance is already running. The message server has to be up
and running on the specified host and port.
Invalid Shared Library Path (in dev_<component name>)

The VM detection builds the library path to find the JVM shared library. If this path is
incorrect, you will receive the following error messages in the dev_<node name> trace
file:
*** ERROR => DlLoadLib: LoadLibrary(jvm.dll) Error 126
Error 126 = "The specified module could not be
found."
*** ERROR => Can't load VM shared library (jvm.dll) (rc=-2)
*** ERROR => Can't load DLL for Java VM
*** ERROR => can't launch program (rc=-2)
JLaunchCloseProgram: close program (exitcode=-2)
Solution
Check the javaVMLibPath property in the VM property file
(instance.properties.vmprop). The file is located in the cluster directory of the J2EE
instance. In the example below, the incorrect property line is in bold (instead of jre the
path contains lall). The <component name> can be bootstrap, dispatcher, server<n>,
and so on.
#test1. : ---------------------------------------#test1. : generated VM parameters

#test1. : Tue May 06 08:26:28 2003
#test1. : ---------------------------------------<component name>.javaVMPath=C:\jdk1.4.2
<component name>.javaVMVersion=1.4.2
<component name>.javaVMVendor=Java HotSpot(TM) Client VM
(build 1.4.2, mixed mode)
<component name>.javaVMType=classic
<component
name>.javaVMLibPath=C:\jdk1.4.2\lall\bin\classic;C:\jdk1.4.2
\jre\bin
<component name>.javaVMExePath=C:\jdk1.4.2\bin
<component name>.javaVMPropVers=1.0
Invalid Administration Shared Memory

After updating the startup framework, you may receive the following error message in
dev_jcontrol or dev_<component name> trace files:
*** ERROR => Can't create to administration shared memory
*** ERROR => Can't attach to administration shared memory
This problem usually appears on UNIX.
Solution
The reason for this error message is an already existing shared memory segment with
wrong size. In this case:
12. ...
39. 1. Stop the J2EE instance.
40. 2. Go to the os_libs directory of the J2EE instance.
41. 3. To invoke the shared memory cleanup, execute:
jcontrol pf=<SAP instance profile> -c.
42.
4. Restart the J2EE instance.
The J2EE Engine Does Not Come Up After 800

Seconds
When installing the J2EE Engine, you receive the following error message:
J2EE engine of instance <instance name> did not come up after 800 seconds.
Solution
Follow the steps below until you identify the problem:
13. ...
1. Check that the J2EE Engine was started
2. Check the JControl developer trace file
3. Check the instance bootstrap developer trace file
4. Check the instance bootstrap log file from the Java VM
5. Check the output from the instance bootstrap Java class
6. Check whether the instance bootstrap terminates
1. Check That the J2EE Engine Was Started

If the J2EE Engine was started, the following file must exist:
<DIR INSTANCE>/work/dev_jcontrol
where <DIR_INSTANCE> is the root directory of the J2EE instance.
If the file does not exist, check the installation log files for error messages.
2. Check the JControl Developer Trace File

If the J2EE Engine was started, analyze the following trace file:
<DIR_INSTANCE>/work/dev_jcontrol
The following problems may have been logged:
Instance properties files are missing or empty:
*** ERROR => JStartupReadArgumentsEx: can't enumerate nodes

[<DIR_INSTANCE>\j2ee\cluster\instance.properties;
<DIR_INSTANCE>\SDM\program\config\sdm_jstartup.properties]
(rc=-1)
In this case, check the installation log files for previous error messages and retry the
installation.
Connecting to the Message Server fails:
*** ERROR => Can't attach to message server

(<hostname>/<port>) [rc=-100]-> terminate
Check that the SCS instance (the SAP Central Services instance containing the Message
Server and the Enqueue Server for the J2EE Engine) on host <hostname> is running and
that the Message Server port is correct.
Detecting the Java Development Kit fails:
*** ERROR => invalid vm detection, please have a look the

files
- java command ["C:\j2sdk1.4.2_02\jre\bin\java.exe" -cp .
JdkDetection_<pid> > ./JdkDetection_<pid>.txt 2>&1]
- output file [./JdkDetection_<pid>.txt]
- java file
[./JdkDetection_<pid>.java]
- class file
[JdkDetection_<pid>]
- used vm type [-server]
- used vm type []
*** ERROR => can't get JDK information (rc=-1)
Verify that the bootstrap.JavaPath property in the
<DIR_INSTANCE>/j2ee/cluster/instance.properties file points to a full version of the Java
Development Kit (and not to an installation of the Java Runtime Environment).
Retry the command in the <DIR_INSTANCE>/work directory from a command interpreter.
The instance bootstrap fails:
*** ERROR => invalid return code of process [bootstrap]

(exitcode=-1)
Check the bootstrap log files. See 4. Check the Instance Bootstrap Log File from the Java
VM.
The instance bootstrap does not terminate.
In this case, the last block in the dev_jcontrol file is:
************************************************************
***
JStartupStartJLaunch: program =
<DIR_INSTANCE>/j2ee/os_libs/jlaunch
-> arg[00] = <DIR_INSTANCE>/j2ee/os_libs/jlaunch
-> arg[01] =
pf=<DIR_SYSTEM>/SYS/profile/<SYSTEM>_<INSTANCE>_<host>
-> arg[02] =
-file=<DIR_INSTANCE>/j2ee/cluster/instance.properties
-> arg[03] = -syncSem=JSTARTUP_WAIT_ON_<pid>
-> arg[04] = -nodeName=bootstrap
-> arg[05] = -nodeId=-1
-> arg[06] =
-jvmOutFile=<DIR_INSTANCE>/work/jvm_bootstrap.out
-> arg[07] =
-stdOutFile=<DIR_INSTANCE>/work/std_bootstrap.out
-> arg[08] = -locOutFile=<DIR_INSTANCE>/work/dev_bootstrap
-> arg[09] = -mode=BOOTSTRAP
-> arg[10] =
pf=<DIR_SYSTEM>/SYS/profile/<SYSTEM>_<INSTANCE>_<host>
-> lib path = <...>
-> exe path = <...>
************************************************************
****
Check the bootstrap log files. See 6. Check whether the instance bootstrap terminates.
If you cannot find any problems in the JControl developer trace file, create a customer
message for the BC-JAS-COR component, create an archive containing the installation
log files and all files from the <DIR_INSTANCE>/work directory, and send the archive
as an attachment to the customer message.
3. Check the Instance Bootstrap Developer Trace

File
If the instance bootstrap was started, you need to analyze the following trace file:
<DIR_INSTANCE>/work/dev_bootstrap
The Java files for the bootstrap are missing:
*** ERROR => Can't load main class

[com.sap.engine.offline.OfflineToolStart
Verify that the <DIR_INSTANCE>/j2ee/cluster/bootstrap directory exists and that it is not
empty.
1. The Java VM starts, but aborts immediately:
JLaunchIAbortJava: abort hook is called

Check the bootstrap log files. See 4. Check the Instance Bootstrap Log File from the Java
VM.
1. The Java VM starts and terminates with a non-zero return code:
JLaunchIExitJava: exit hook is called (rc=66)

Check the bootstrap log files. See 5. Check the Output from the Instance Bootstrap Java
Class.
If you cannot find any problems in the bootstrap developer trace file, create a customer
message for the BC-JAS-COR component, create an archive containing the installation
log files and all files from the <DIR_INSTANCE>/work directory, and send the archive
as an attachment to the customer message.
4. Check the Instance Bootstrap Log File from the

Java VM
The Java VM, which executes the instance bootstrap, is started by using the following log
file:
<DIR_INSTANCE>/work/std_bootstrap.out
Invalid Java VM parameters:
Unrecognized option: <some option>

The option supplied in the bootstrap.JavaParameters property is not valid for the Java VM.
Correct the property value and try again.
Inconsistent memory settings for the Java VM:
Error occurred during initialization of VM

Incompatible initial and maximum heap sizes specified
The memory settings supplied in the bootstrap.JavaParameters and
bootstrap.MaxHeapSize properties do not fit together (for example, MaxHeapSize is
smaller than the initial heap size specified with Xms).
Correct the property values and try again.
5. Check the Output from the Instance Bootstrap

Java Class
The output from the bootstrap Java program is stored in the following file:
<DIR_INSTANCE>/work/jvm_bootstrap.out
Illegal options for the bootstrap main class:
[Bootstrap module]> Bootstrap must be called through the

Startup Framework with the appropriate parameters!!!
Correct the bootstrap.Parameters property and restart the instance.
6. Check Whether the Instance Bootstrap

Terminates
The instance bootstrap may not be able to terminate if it cannot write a new instance.properties
file. Check that the file is writable for the <SID>adm user and that the disk is not full.
A Missing instance.properties File

The values of the instance.properties file (/usr/sap/<SID>/<instance
name>/j2ee/cluster/instance.properties) are stored in the database and are
synchronized to the file during the startup process. The export of the
instance.properties file is handled in the bootstrap section of the startup framework.
However, the bootstrap process apart from using the bootstrap.properties file (for
example, to connect to the database), also uses the instance.properties file for some
additional parameters (such as, the path to the JVM). Therefore, in case of a missing
instance.properties file, the bootstrap will not be able to start. Thus, you will not be
able to start the whole J2EE Engine unless you recover the instance.properties file with
the parameters, which the bootstrap needs.
The instance.properties file is divided into sections. Each section describes a Java
program. The format of one line in the property file is:
<section>.<property name> = <property value>
The parameters from the instance.properties file, which the bootstrap uses, are stored in
one section called bootstrap.*. These properties and their descriptions are:
Property Name
Description
ClassPath
The class path of the Java program.
JavaParameters
Contains additional Java parameters. This

string is passed to the loaded Java VM.
Execute Java without arguments to get help
for the valid Java parameters and options.
JavaPath
The path to the JDK installation directory.

The same as the value of the JAVA_HOME
environment variable.
MainClass
The main class of the Java program.
MaxHeapSize
The heap size of the loaded Java VM. The

value is in MB (megabytes).
Name
The name of the Java program (for

example, bootstrap).
Parameters
Program arguments used to start the

bootstrap process.
RootPath
The root path of the Java program.
Type
The type of the Java program. The possible

values are: unknown, bootstrap,
dispatcher, server, sdm.
Example
The following is an example of an instance.properties file containing the minimal
properties needed by the bootstrap to start and to recover the whole instance.properties
file:
bootstrap.ClassPath=./bootstrap/launcher.jar
bootstrap.JavaParameters=-Djco.jarm=1
bootstrap.JavaPath=C:/j2sdk1.4.2_07
bootstrap.MainClass=com.sap.engine.offline.OfflineToolStart
bootstrap.MaxHeapSize=128
bootstrap.Name=bootstrap
bootstrap.Parameters=com.sap.engine.bootstrap.Bootstrap ./bootstrap
ID0098278
bootstrap.RootPath=C:/usr/sap/J2E/JC00/j2ee/cluster
bootstrap.Type=bootstrap

Purpose
The J2EE Engine installation procedure provides a system that is ready to be run and used.
However, you may need to configure the J2EE Engine additionally to adapt the system to the
needs and requirements of a particular business scenario.
Integration
The SAP NetWeaver provides the Template Installer, which enables the automatic configuration
of the J2EE Engine and the SAP NetWeaver components running on top of it. This configuration
is based on specially designed templates for different business scenarios. For more information,
see Template Installer.
Features
This guide provides general guidelines about:
Clustering the J2EE Engine setting up and configuring the cluster
Mandatory Configuration of the J2EE Engine
Optional Configuration of the J2EE Engine
See also:
For more information about configuring other SAP Web Application Server (Java) components,
see:
User Management Engine
Administration of the Design Time Repository Server
Template Installer
Use
When you have installed a NetWeaver system, the Template Installer makes technical
settings which are required for the technical processing of a system or a technical
scenario, e.g. system name, memory size, connectivity.
Integration
You make the technical settings with the Template Installer, immediately after installing a
NetWeaver system.
The template installer is part of the NetWeaver administrator.
You use the Template Installer for the initial technical configuration. Use the Config. Tool to
make settings which are not in the template, or for subsequent changes to the technical
configuration.
The SAP NetWeaver installation guide contains detailed information about the templates.
Prerequisites
You have installed your system.
Features
The template installer makes the technical settings (technical configuration) using
scenario-based templates, e.g. for Master Data Management. Templates allow you to
enter the same data centrally, once only, e.g. system name, memory size, connectivity.
The system distributes this data automatically via templates in the SAP NetWeaver
system.
Activities
14. ...
43. 1. Call the NetWeaver Administrator under the path
http://<host>:<httpport>/nwa in a browser, and logon to the NetWeaver
Administrator with the user Administrator.
44. 2. Call the Template Installer with Template Installer in the Deploy &
Change tab.
The system gives you the scenario and its templates, according to your selection during
installation.
45.
46.
3. Choose a template from the list, and Execute Template.

4. Enter the required data and choose Next.
When you have entered all required data, the Install pushbutton is active.
47.
5. Select Install.
The system makes the necessary settings.
48.
6. The system reports any configuration errors. Error message long texts are in
the log. Call the log with NetWeaver Administrator System Management
Monitoring Logs & Traces.
Clustering the J2EE Engine

This section is an introduction to the J2EE Engine cluster. It provides information about:
The J2EE Engine cluster architecture
Procedures how to scale the J2EE Engine cluster
The initial configuration steps to run your J2EE Engine cluster
Links to more advanced configuration topics
What is a Cluster?
The cluster is a set of processes that work together to build a scalable and reliable system. The
cluster structure is transparent to the clients and appears to them as a single server unit.
The J2EE Engine cluster consists of one or more Java dispatchers, several server processes, the
Central Services (Message Service and Enqueue Service), and the database. For more
information, see Java Cluster Architecture.
Why Clustering?
Clustering provides the following advantages:
Scalability of the system In case of high system load, you can easily enlarge the current
system.
High availability of the system The set of mechanisms that the system provides
guarantees normal system operation with its ability to transparently recover in case of
failures within the cluster.
To make use of the clustering features, you need to set up and configure the J2EE Engine
according to the deployed applications and the expected workload. For more information, see
Java Cluster Setup and Configuring the J2EE Engine Cluster.
See also:
Mandatory Configuration of the J2EE Engine
Optional Configuration of the J2EE Engine
Java Cluster Architecture

A Java cluster installation consists of:
One or more
Instances of the AS Java
The
Central Services, which also form an instance

One or several databases
The different instances can be split up among different physical machines. The Central
Services (Message Service and Enqueue Service) are installed on one host that meets
possible requirements for high availability.
Minimum Cluster Installation

The following figure shows the simplest installation of the usage type AS Java. A system
installed in this way can process only requests to Java applications. The integrated
scenario with Java and ABAP is described in the section SAP NetWeaver Application
Server with ABAP and Java.
The minimal AS Java installation consists of:

A Java central instance with a dispatcher, a server process, and the Software Deployment
Manager (SDM).
The Central Services instance.
The Database.
A
Java Instance consists of (with the exception of Central Services):

a Java Dispatcher
One or several server processes
Large Cluster Installation

The figure below shows a larger Java cluster installation. It consists of four instances, all
of which have an instance number and each one can be started, stopped, and monitored
separately.
Load Balancing
If you have a large Java cluster installation, the load is distributed between the available
dialog instances by a load balancer. This scenario with implementation of the SAP Web
Dispatcher is described in the section Load Balancing of Java Applications.
Further Information
You will find further information on the cluster architecture in the following sections:
Java Instance
Central Services
Load Balancing of Java Applications
High Availability and Failover
Java Cluster Setup

Purpose
An appropriate cluster setup is one of the main prerequisites for the efficient performance of your
system.
The Java cluster components form the initial system configuration, which is typically based on the
expected system load, defined by such factors as the anticipated throughput and number of
users, as well as on the available hardware resources.
When installing the J2EE Engine, you can choose to install the necessary components on a
single host or on different hosts. In addition, you can choose the number of server processes in
each Java instance.
Process Flow
If the system load is greater than expected and the cluster that you have initially set up does not
scale well, you can resize it by:
Installing new Java instances
Adding server processes to existing Java instances
Adding Java Instances

Use
When the number of customer requests to the J2EE Engine is large, you may need to
resize your cluster by installing new Java instances.
You install new Java instances on different physical machines, thus adding more
hardware resources and improving the failover capabilities of your system.
Prerequisites
You have installed the basic components of the cluster.
Procedure
Using SAPinst, you can expand the cluster with new Java instances, which you can install
on other hosts. For more information about the installation procedure, see SAP Service
Marketplace at service.sap.com/installnw2004s.
Scaling the cluster by adding a Java instance
Guidelines
For applications that access the persistence layer frequently and require a lot of server
processing, you can configure a cluster with fewer Java instances, each with more server
processes.
We recommend that the Java cluster run behind a load balancer, such as SAP Web
Dispatcher, which distributes the client requests among the Java instances. The Java
dispatcher in each Java instance provides load balancing between the server processes.
You do not need to reconfigure the load balancing. For more information, see
Load
Balancing of the SAP Web AS for J2EE Applicationsin the Architecture Manual.
Adding Server Processes

Use
You can scale a Java cluster by adding server processes to already existing Java instances.
This enables optimal utilization of the available hardware resources and of the capacity of
the Java dispatcher to handle multiple server processes.
Scaling the cluster by adding a server process
Prerequisites
You have installed the basic components of the cluster.
Procedure
When you install your Java instance, SAPInst automatically configures the number of
server processes based on the hardware resources that are available.
If you need to add more server processes to an existing Java instance, you can do that
manually using the J2EE Engine Config Tool:
15. Make sure ...
49. 1. Make sure that the J2EE Engine system is stopped. For more information, see
Starting and Stopping the J2EE Engine.
50. 2. Start the Config Tool by running the configtool script file located in the
\usr\sap\<SAPSID>\j2ee\<instance name>\configtool directory.
51. 3. Select the instance to which you want to add the server process.
52. 4. Choose Server Add Server.
For more information about the Config Tool, see Config Tool.
Configuring the J2EE Engine Cluster

Purpose
Typically, after installing the necessary cluster configuration and after applying the
appropriate template for that configuration (using the Template Installer), you should
configure the J2EE Engine cluster optimally for your scenario, hardware resources, and
workload.
The additional cluster configuration that you can perform can be divided into two types
of configuration:
Required cluster configuration this includes the configuration of some additional

parameters depending on the size of the J2EE Engine cluster, the expected workload, and
so on. Although referred to as required configuration, we recommend that you maintain
these settings only after careful consideration and testing.
Optional cluster configuration perform the procedures described in this section only in
case there are some problems within the cluster operation. Otherwise, we recommend that
you do not reconfigure the default settings.
Process Flow
Required Cluster Configuration
Configuring Cluster Elements follow this procedure to configure the name of the cluster
elements and the join port of the server processes.
Connections Manipulation follow these procedures to configure the maximum number of

user connections that the dispatcher can handle simultaneously and a timeout for
establishing these connections.
Setting Service Load Timeout follow this procedure to configure the maximum time for
which the services on a cluster node have to be started.
Optional Cluster Configuration
Thread system configuration to optimize the reallocation of system resources, we

recommend that you closely monitor and if necessary, reconfigure the J2EE Engine thread
system. For more information, see Thread System.
Managing the Cluster Elements Startup and Shutdown use this procedure to configure
manner in which the cluster elements will be started up and shut down.
Configuring the cluster communication mechanisms:
Configuring the Message Server Communication

Configuring the Session Communication
Configuring the Lazy Communication
Configuring the services stop and event timeouts:
Setting Service Stop Timeout

Setting Event Timeout
Configuring Cluster Elements

Use
This procedure enables you to modify the default name of a cluster element that was
assigned to it during the cluster element creation. If necessary, you can also change the
assigned join port of a server process, on which the server process listens for connections
(for example, when the port assigned to the cluster element is already in use by another
program).
Do not modify the cluster element ID (element.clusterId), group ID
(element.groupId), or type (element.type) properties. Modifying any of these
properties leads to problems within the cluster communication and operation.
Procedure
53.
54.
55.
1. Start the J2EE Engine Visual Administrator.

2. Choose Server/Dispatcher Kernel Cluster Manager Properties tab.
3. Modify the required property values depending on the tasks you want to
perform:
1.
a. Use element.name to specify the name of the cluster element.
There are no restrictions about the name.
2.
b. Use element.joinPort to specify the port on which the server

process listens for connections.
The port value must not be: greater than 65535, less than 1024, or a well known
port.
This property is available only on server processes.
56.
4. Choose
Save Properties to save your changes and restart the cluster node.
Managing Cluster Elements Startup and Shutdown

Use
Use this procedure to configure the cluster to work in the manner of a full parallelism, or
to set its startup/shutdown to be serialized. For your configuration purposes, use the
properties provided by the J2EE Engine Cluster Manager.
By default, the cluster elements start up and shut down in full parallelism mode, that is,
simultaneously, without waiting for each other.
We recommend that you do not modify the default cluster elements startup and
shutdown configuration unless there are synchronization problems within the cluster
and you are officially advised by SAP support to maintain these settings.
Procedure
57.
58.
59.

2. Choose Server/Dispatcher Kernel Cluster Manager Properties tab.
3. Modify the required property values depending on the tasks you want to
perform:
3.
a. Use barrier.startup to determine the kind of the element's
startup serialization.
There are three possible values: "none" no serialization; "box" serialization
in the boundaries of the box, that is, the elements in one box will be started one by
one; "cluster" serialization in the boundaries of the whole cluster.
4.
b. Use barrier.shutdown to determine the kind of the element's

shutdown serialization the use of this property is similar to the
barrier.startup.
5.
c. Use barrier.dependent to determine whether the startup and
shutdown barriers are dependent.
This property has a Boolean value. If it is set to true, there can only be one
starting or stopping element in the box/cluster at the moment. Otherwise, there
can only be one starting and one stopping element.
6.
d. Use barrier.timeout to specify the timeout, within which the

element is forced to recheck its permissions to pass the barrier.
This property is used for optimization purposes. It is advisable not to change its
value.
60.
4. Choose
Example
16. ...
Save Properties to save your changes.
61.
1. Example of a serialized startup/shutdown configuration:

barrier.startup=cluster
barrier.shutdown=cluster
barrier.dependent=true
barrier.timeout=10000
62.
2. Example of a full parallelism configuration:

barrier.startup=none
barrier.shutdown=none
barrier.dependent=false
barrier.timeout=10000
Communication Management
Purpose
This system is responsible for managing client connections to the cluster and for
managing the communication between the cluster elements.
Features
The communication management system uses several J2EE Engine managers to complete
its functions.
Cluster Manager
This manager is responsible for managing the communication between the elements in
the cluster. It updates information about the status of each cluster element and the
services running on it. The information that is kept concerns the communication status.
For more information about the different communication mechanisms offered by the
Cluster Manager, see Cluster Communication.
For more information about configuring the different communication mechanisms, see:
Ports Manager
This manager is a non-distributed system that manages ports on which sockets are
opened. It stores information about the mapping of a port and the service that uses it,
collects data about all Sockets and ServerSockets, and registers listeners on the
TCP port. The TCP ServerSockets are then opened and wait for user requests. When
a client request comes, a socket is created (the client socket type depends on the type of
the ServerSocket.) For more information, see Ports Management.
Connections Manipulator Manager

This manager provides options for managing client connections to the cluster. The client
access to the cluster is available through the dispatcher only. Therefore, this module runs
solely on dispatchers.
Each connection is associated with a particular socket (TCP/IP), through which the data
transfer is completed and is connected to a specific service. This connection comprises
two buffers one for client data and another for the data from the server to the dispatcher.
For more information, see Connections Manipulation.
See also:
Cluster Communication in the Architecture Manual

Use
Message server communication is established through the message server that is used as a
dispatcher when sending messages. The advantage of this way of communication is that it
provides a failover function that avoids the loss of information.
Use this procedure to configure the default settings of the message server
communication.
We recommend that you do not modify the default message server communication
settings unless you are officially advised to do so by SAP support.
Procedure
17. ...
63. 1. Start the J2EE Engine Visual Administrator.
64. 2. Choose Dispatcher/Server Kernel Cluster Manager Properties tab.
65. 3. Modify the values of the following properties:
7.
a. Use ms.hostto specify the host (IP address,) where the message
server is running.
8.
b. Use ms.portto specify the port, on which the message server
listens for connections.
9.
c. Use ms.message.pool.size to define the size of the message
library pool.
The size of this pool can be changed for optimization purposes.
10.
d. Use ms.confirmation.timeout to specify the timeout

period that a joining cluster node waits for the confirmation replies from the
cluster participants.
Modify the value of this property if you receive an error message during cluster
startup indicating that there are errors when getting a confirmation message due to
non-responding cluster elements and the node will be rebooted.
11.
e. If necessary, you can increase the time the system waits before
triggering a liveliness check (ping/pong protocol) event if there has been no
communication between a cluster node and the message server. To do so, modify
the value of the ms.keepalive property.
12.
f. Use ms.reconnect.timeoutto increase the time period
during which you can reconnect to the message server. After this time elapses,
you are no longer able to reconnect to the message server.
66. 4. Choose
Save Properties to save your changes and restart the cluster node.
See also:
Message Info Service

Use
Session communication is used to exchange information between the dispatcher and a
server in one cluster group. You can use this procedure to modify the default settings of
the session communication.
We recommend that you do not modify the default session communication settings
unless you are officially advised to do so by SAP support.
Procedure
67.
68.
69.
18. ...
2. Choose Dispatcher/Server Kernel Cluster Manager Properties tab.
3. Modify the value of the session.message.queue.size property.
This property defines the size of the session layer queue. It can be changed for
optimization purposes.
70.
4. Choose

Use
The lazy communication mechanism is used automatically by the Cluster Manager to
quickly exchange large amounts of information between two server processes without
using the message server as an intermediary.
By default, lazy communication is enabled only for a predefined list of services (the list is
stored in the lazy.exclusive.list property) and is disabled for the remaining
services.
You can enable a mechanism by which lazy communication is activated when a
previously defined amount of objects is transferred between two parties for a defined
time interval.
We recommend that you do not modify the default lazy communication settings
unless you are officially advised to do so by SAP support.
Procedure
71.
72.
19. ...
2. Choose Server Kernel Cluster Manager Properties tab.
You can configure the lazy communication on servers only.
73.
3. To add or remove a service from the list of services for which lazy
communication is always enabled, select the lazy.exclusive.list property
and modify its value.
74. 4. To enable the mechanism by which lazy communication is enabled according
to the amount of information exchanged for a definite period of time, modify the
following properties:
13.
a. Specify true as the value of the lazy.transparent.switch
property.
14.
b. Use lazy.time.piece to specify the time interval in
milliseconds for which the quantity of messages defined by the
lazy.threshold property has to be exchanged between two parties in order
to open a lazy connection.
If two parties open a connection, and if they succeed in exchanging more
messages than the size defined by the lazy.threshold property for the time
defined, then a lazy connection will be opened.
15.
c. Use lazy.threshold to specify the size of the messages that

must be sent during a time interval equal to the value set in the
lazy.time.piece property.
16.
d. Use lazy.autoclose.timeout to specify the time for which
the lazy connection will be open after the last large message is transported.
After this timeout, the Cluster Manager closes the connection.
If you specify zero (0) as a value, the lazy connection will be permanently open
(infinite timeout.)
17.
75.
e. Use lazy.message.pool.size to specify the size of the pool

where the currently unused message objects are stored.
5. Choose
See also:
Cluster Manager Properties in the Reference Manual
Connections Manipulation
Use
The management of client connections in the cluster is represented in J2EE Engine by the
Connections Manipulator Manager. This manager has an indirect connection with all
services running on the dispatcher that receive or send data outside the cluster using a
socket. It provides threads in which the processing of the received requests, their transfer
from the dispatcher to the server, and the return of the response back to the user is
accomplished.
Use this procedure to configure the maximum number of user connections that a
dispatcher will be able to process at a certain moment, a timeout for these connections,
and the connections checks.
Activities
Configuring the Maximum Number of User Connections
The maximum number of user connections that the dispatcher can handle at a given
moment is calculated by the system according to the memory (heap size) allocated to the
dispatcher. By default, the Max heap size allocated to a dispatcher node is 170 MB.
Thus, after making some allowances for connections reserved for internal communication
and assuming that each connection consumes 10 KB memory, by default the maximum
number of parallel user connections that a dispatcher (with 170 MB Max heap size) can
handle is 12,403. If you change the Max heap size of a dispatcher node, the system will
dynamically determine the maximum number of allowed user connections. When this
number is exceeded, the users are rejected.
To view or change the Max heap size of a dispatcher node, use the Config Tool.
To check the maximum number of allowed user connections, use Telnet and
execute the following commands:
add debug
debugmanager ConnectionsManipulator
The number calculated by the system is displayed as a value of the

maxPossibleParallelUsers property.
However, you can limit the maximum number of user connections below the number that
the system has calculated. To do so, proceed as follows:
77. Choose Dispatcher Kernel Connections Manipulator Properties tab.
78. Modify the value of the MaxParallelUsers property.
By default the value of this property is 0, which means that the system does not take this
property into account and the maximum number of allowed user connections at a given
moment is calculated by the system as described above.
When you modify the value of this property, the behavior of the system is as follows:
If your value is bigger than the maximum value the dispatcher can afford, the
system will set its maximum value instead of your one.
If your value is less than the maximum value the dispatcher can afford, the system
will accept your value.
Note also that when you increase the Max heap size of a dispatcher node and thus the
maximum number of allowed user connections, you must also monitor the thread system
and the log files and, if necessary, reconfigure the thread system as well (for example, the
request/response times are higher that usual or the number of free threads is very small).
For more information, see Thread System.
Configuring the Connections Timeout

When the connections need more time to establish the communication between the
dispatcher and the client side (for example, new connections in WAN), you need to
increase the default connections timeout as it may not be enough and the connections
may fail.
We recommend that you estimate carefully the new value that you will assign to the
connections timeout property, because setting a too high value might lead to
blocking additional resources in the thread system.
To modify the default connections timeout, proceed as follows:

20. ...
80. Choose Dispatcher Kernel Connections Manipulator Properties tab.
81. Modify the value of the GetStreamsSoTimeout property.
For SSL connections, the value of this property is overwritten by the
HANDSHAKE_SO_TIMEOUT and the RUNTIME_SO_TIMEOUT properties of the SSL
Provider Service on the dispatcher nodes. For more information about these
properties, see SSL Provider Service.
Configuring the Connections Checks

The system performs two types of connection checks: an availability check (a check if
some data is available to read in the connection) and a close-wait check (a check whether
the connection is open or closed on the client side). By configuring these checks, you can
change the balance between the CPU load and the overall system performance. You
achieve this by modifying the value of the CloseWaitCheckPeriod property.
This property determines the number of availability checks for a connection, after which
the system performs a check whether the connection is in close-wait status, that is, if the
connection is closed on the client side but is still open on the server side. If the result of
this check is positive, the system closes that connection on the server side, too. The
default value is 100, that is, after each 100 checks for availability, the system checks
whether the connection is in close-wait status.
To improve the system performance, increase the value of the CloseWaitCheckPeriod
property.
However, if you increase the CloseWaitCheckPeriod value and there are a lot of client
connections in close-wait status, then the total number of connections in the connections
queue increases. This in turn increases the CPU time needed to process this queue and
the system needs more time to detect that a connection is in close-wait status and has to
be closed on the server side.
To decrease the CPU consumption, decrease the value of the CloseWaitCheckPeriod
property.
If you decrease the CloseWaitCheckPeriod value, you increase the frequency in which
the system checks if there are connections in close-wait status. This affects negatively the
overall performance of all connections but also closes faster the connections in close-wait
status and thus decreases the CPU consumption.
The close-wait check is time consuming. Therefore, be careful when decreasing the
CloseWaitCheckPeriod value, because although this check does not block the
CPU, it blocks the thread that serves the corresponding connection. Thus, if there
are a lot of connections and you decrease the property value, this may result in
blocking too many threads and, respectively, in a system bottleneck.
Ports Management
Use
This function is implemented in the J2EE Engine Ports Manager and is used to manage ports on
which sockets are opened. It stores information about the mapping between a port and a service
that uses it, collects data about all Sockets and ServerSockets, and registers listeners to the
TCP port.
Integration
All transport services are using Ports Manager through their context to open ServerSocket or
Socket, as well as to close sockets.
When a client socket is created, it is registered in the Connections Manipulator Manager. It is
then wrapped in a TCPRunnableConnection, through which the manager takes care of reading
and writing in this socket, and sends events to the service that will process the request.
Features
Ports Manager manipulates with the sockets of a particular dispatcher. All methods from the
ServiceDispContextthat are connected with the socket manipulation are implemented on the
basis of this module.
Each service is able to open different types of sockets (ServerSocket, Socket). Different types
of services are granted permissions to apply transport layers when opening a socket. This means
that a socket with a specified queue can be opened, for example SSL/HTTPTunneling. First an
HTTP socket has to be opened: a standard HTTP request is created and sent using the data sent
through this type of socket. Respectively, the HTTP requests are received, from which the data is
extracted and disposed to the user. SSL is applied above this socket.
The different transport layers are realized as separate services that implement methods from the
service frame. Through these methods Ports Manager receives sockets with specific transport
quality from the corresponding service.
See also:
Ports Manager Properties in the Reference Manual
J2EE Engine Ports
Service Management
Purpose
The basic module of the service management system is the Service Manager, which acts
as a container in which all services in the cluster work. This manager defines the main
control implementation for each service through which the administration of a separate
service is accomplished. It is a module that runs on both server processes and dispatcher
nodes.
Features
The J2EE Engine service management has several basic features:
Resolves references between components
Provides states for starting a service in J2EE Engine ALWAYS and MANUAL.
Provides a set of properties for setting load, stop, and event timeouts. For more information,
see:
11
11
11
11
Setting Service Load Timeout

Service Manager Properties in the Reference Manual

Use
Use this procedure to change the maximum time for which all services on a cluster node
have to be started.
If there are still services that have not started after this timeout elapses, the Service
Manager assumes that all services are started and the system continues with the other
startup processes. The timed-out services will continue their startup process in the
background. A notification for each timed-out service is logged in the log files.
If there are large clusters (containing more than five server processes), check the
log files for services that have timed out during startup. If there are such cases, we
recommend that you increase the default timeout from 5 to up to 20 minutes.
Procedure
82.
83.
84.
85.
86.
1.
2.
3.
4.
5.
21. ...
Start the J2EE Engine Visual Administrator.
Choose Server/Dispatcher Kernel Service Manager Properties tab.
From the list of properties, select LoadTimeout.
In the Value field, set the required timeout in minutes.
Choose
Save Properties to save the changes.

Use
Use this procedure to change the maximum time which the Service Manager waits for
each service to stop when the cluster node is shutting down.
If this timeout has elapsed and the service has not managed to stop, the Service Manager
continues with the cluster node shutdown. A notification for each timed-out service is
logged in the log files.
The default service stop timeout is 20 seconds. In case of problems during cluster
node shutdown, check the log files for timed-out services during shutdown. In such
cases, we recommend that you analyze the problematic services and, if necessary,
increase the service stop timeout.
Procedure
87.
88.
1.
2.
tab.
89. 3.
90. 4.

Choose Server/Dispatcher Kernel Service Manager Properties
From the list of properties, select StopServiceTimeout.
In the Value field, set the required timeout in seconds.
91.
5. Choose
Save Properties to save the changes.

Use
Use this procedure to specify the time that the Service Manager waits for the event to be
processed before undertaking another action.
If you want to stop a service, a beforeServiceStopped event is thrown first.
Then it waits for all components to process the event. That is, the components are
notified that the service will be stopped and they should undertake the appropriate
actions, such as unregistration, and so on. After the specified timeout, the service is
stopped.
The default value of the event timeout is 20 seconds. If after 20 seconds there are
still components that have not processed the event, the system will not wait for them
and the service will be stopped.
We recommend modifying this value only if you have problems stopping the
service. Otherwise, we recommend that you do not reconfigure the default timeout.
Procedure
92.
93.
94.
95.
96.
1.
2.
3.
4.
5.
22. ...
Choose Server/Dispatcher Kernel Service Manager Properties tab.
From the list of properties, select the EventTimeout.
In the Value field, set the required timeout in seconds.
Choose
Save Properties to save the changes
Purpose
This section contains:
Web Container
EJB Container
Deploy Service
Message Handling Using JMS
Web Services Container Service
Failover System
Transactions and Resource Handling
Naming System
Web Container
The following modules build the functions of the J2EE Engines container for J2EE web
applications:
HTTP Provider Service carries out the communication over HTTP protocol and provides
a functional HTTP-based web server implementation.
Web Container Service provides runtime services and life-cycle management to J2EE
web applications deployed on J2EE Engine.
Failover System carries out serialization of HTTP sessions.
HTTP Provider Service

Purpose
HTTP Provider Service provides the low-level communication and transportation services for the
J2EE Engine Web Container to work properly. It is a service that implements Hypertext Transfer
Protocol (HTTP) version 1.1 (specified by RFC #2616).
HTTP is a request-response protocol. Based on that paradigm, HTTP Provider Service takes care
of parsing the URL of the incoming HTTP requests, dispatching them to the proper J2EE Engines
module for processing, and returning the generated responses back to the client. It provides
important features to secure a robust, high performance communication infrastructure for running
high-volume business Web applications.
HTTP Provider Service is a session service, that is, it runs on both dispatcher and server nodes.
That allows for using load balancing algorithms and fast requests processing.
From a clients point of view, HTTP Provider Service represents a server socket that listens for
client HTTP connections to the J2EE Engine.
Integration
HTTP Provider Service is an integral part of the J2EE Engines Web Container. It is closely
related to the Web Container Service, which represents a container that provides managed
environment for running servlets and JavaServer Pages. HTTP Provider Service is the underlying
communication module that transfers HTTP responses generated by Web applications dynamic
content back to the client.
Features
Some of the most important features of the HTTP Provider Service are:
Supports communication through proxy environment
Supports multipart requests parsing
Integrated mechanism for heterogeneous load balancing for requests to web applications
Supports virtual hosting
Supports applying gzip transfer encoding to requests and responses to static Web resources
Provides efficient configurable HTTP cache

You can perform the following tasks with the HTTP Provider Service:
Configuring Heterogeneous Load Balancing
Setting up HTTP Provider Service to Accept Incoming Requests
Mapping Ports
Certificate Login When Using SSL-enabled Proxy
Configuring Rules for HTTP Responses Compression
Configuring the Zone Separator
Setting Timeout for Persistent Connections
Limiting the Length of the Requests Headers
Specifying the Size of the File Buffer
Update the HTTP Cache Content
Configuring the HTTP Cache
Configuring HTTP Responses Caching by Client Caches
Configure Traces and Logs for HTTP Communication
Managing MIME Types
Specifying Welcome Files
All tasks can be performed using the Visual Administrator tool. For some of them you can use
either the Visual Administrator or Telnet with the corresponding shell commands for execution.
For more information about the HTTP Provider Service shell commands available, see HTTP.
Requests Parsing
Use
HTTP Provider Service running on the Java dispatcher parses incoming HTTP requests to
determine which server process to direct them to. Then, additional request parsing occurs
on the corresponding server process so that the appropriate module is invoked to process
it.
Features
There are two scenarios that have implication on how HTTP Provider Service parses
requests. These are:
23. ...
97. 1. HTTP Provider Service is running, Web Container Service is stopped.
98. 2. Both HTTP and Web Container services are running.
Running HTTP Provider Service Only Scenario

When running HTTP Provider Service while Web Container Service is stopped, you can
run web sites that contain static web resources only. No servlets or JSPs can be served by
the J2EE Engine in this case.
For this scenario, a request URL may contain an HTTP alias, or simply the directory path
to the requested resource (relative to the servers root directory). In either case, HTTP
Provider Service running on the dispatcher parses the request and directs it to a randomly
selected server in the cluster that has the HTTP Provider Service started on it (determined
using the J2EE Engine Load Balancing System). The HTTP Provider Service running on
server processes then parses the request to determine the location of the requested
resource, the HTTP method to be performed, and so on.
When you run HTTP Provider Service without Web Container Service, you cannot
execute PUT requests to web resources on the J2EE Engine.
Running Both HTTP Provider and Web Container Services Scenario

In this case, you can deploy and run J2EE web applications on the J2EE Engine. The
request URL for a web application contains its application alias. HTTP Provider Service
running on the Java dispatcher parses the request and based on the load balancing
mechanism determines which server node to direct the request to.
The server-side request parsing, in this case, is performed first by the HTTP Provider
Service, and then (only if the request is directed to a deployed web application) by the
Web Container Service. Based on its configuration, the latter determines which module to
process the request. For example, each request to a file with jsp extension is processed by
the JSPServlet class. Also, each PUT request is processed by the PutServlet
class.
See also:
Load Balancing by the Java Dispatcher (in Architecture Manual)
Load Balancing for J2EE Web Applications (in Architecture Manual)

Use
You can enable your HTTP Provider Service to perform heterogeneous load balancing for
client requests to distributed Web applications that run within the J2EE Engine cluster.
This function is very useful if you do not want your Web application to be started on all
server processes in the cluster.
When you enable heterogeneous load balancing on HTTP Provider Service, you can be
sure that client requests to a specific Web application are directed to a server process
where the application is available. Subsequent requests to the same application are
dispatched to the same server process where the application session has been already
established. For more information about the heterogeneous load balancing mechanism
used by HTTP Provider Service see Load Balancing for J2EE Web Applications in the
Architecture Manual.
Procedure
Use the Visual Administrator tool to enable heterogeneous load balancing:
24. ...
99. 1. Open the Properties tab of the HTTP Provider Service on the dispatcher.
100.
2. Assign value true to the HeterogeneousLoadBalancing property.
If you set the value false to this property, the HTTP Provider Service will perform
homogeneous load balancing based on the J2EE Engine Load Balancing System as
described in Load Balancing by the Java Dispatcher in the Architecture Manual.
101.
102.
3. Choose Update to add it to the list of properties.

4. To apply these changes, choose
(Save Properties).
Setting up HTTP Provider Service to Accept

Incoming Requests
Use
If you want the HTTP Provider Service to accept incoming requests, you have to specify
several properties that the system uses when opening the server sockets that carry out the
client-server communication. These include:
The TCP port number on which HTTP Provider Service listens to for incoming HTTP requests.
The size of the queue of indications of incoming connections. If the queue is full and an
indication of connection comes, the connection is refused by HTTP Provider Service.
The IP address that HTTP Provider Service uses to bind all incoming requests to. This property
makes sense only when connecting to a host that has multiple addresses configured.
The number of threads that work simultaneously and process the indications of incoming
connections from the queue.
You can configure more than one HTTP and SSL port to be opened. You must just
provide the necessary entries as a value of the Ports property as described by the
procedure below.
Procedure
Use the Visual Administrator tool to perform this configuration task:
25. ...
103. Open the Properties tab of the HTTP Provider Service running on the dispatcher.
104. Edit the Ports property. The value of this property is a list of separate ports
configurations, each contained within brackets. For example, the default value of this
property contains two port configurations: (Port:50000,Type:http) and
(Port:50001, Type:ssl).
Each port configuration can contain the following attributes:
26. ...
Attribute Name
Value
Port:
Specifies the port number.
To determine the proper values

for the HTTP and SSL ports, refer
to the J2EE Engine Ports.
Type:
Specifies the type of the port. It can be http or

ssl.
SocketQueue:
Specifies the length of the queue of indications

of incoming connections.
BindAddress:
Specifies an IP address to bind all incoming

connections to this address only. If the value is
an empty string, connections will be accepted
on any of the local addresses configured.
AcceptingThreadsCount:
Changes the default value of the number of

threads that listen to the server socket for
incoming connections. The value of the
property must be an integer number.
We recommend that you do not change the
default value of this property. It is estimated to
be optimal for a system with default
configuration.
Only the Port: and the Type: attributes are mandatory for a valid port configuration. If
you do not explicitly specify the rest of the attributes, their default values are
assumed. They are: SocketQueue:200, BindAddress:<an empty string>, and
AcceptingThreadsCount:10.
To apply these changes, choose
(Save Properties).
Result
You now have basically configured your HTTP Provider Service running on the Java
dispatcher to forward incoming HTTP requests to the appropriate server modules (HTTP
Provider Service, and Web Container Service if the request is directed to a J2EE web
application). If you want to further fine-tune your HTTP Provider Service, proceed with
the setup of your virtual hosts.
Once you have configured the ports, the information about the first HTTP and the first
SSL ports (exactly as they appear in the value of the Ports property of the HTTP
Provider Service) is sent to the message server and the ICM. This information is required
by the SAP Web Dispatcher for load balancing. For more information about the topic, see
Load Balancing Between Many Java Instances in the Architecture Manual. The ICM
requires this information in order to redirect requests to the J2EE Engine. For more
information about the communication protocol between ICM and Java Dispatcher, see
Communication Between the ICM and J2EE Engine.
Mapping Ports
Use
You can consider mapping ports in one of the following situations when the client-server
communication is conducted through a proxy environment:
To change the communication scheme from HTTP to HTTPS. In this case, you must map
a port on the Java dispatcher to the proxy servers host and port.
To provide support for HTTP 1.0 client requests. Such requests are not required to have
the Host header. So in cases when the client request is HTTP 1.0 compatible and does not
contain the Host header, it must be redirected to a certain host. That host name is later
returned to the client as a value of the Location header of the response message.
Procedure
You can define port mapping with the ProxyMappings property of the HTTP Provider
Service running on the Java dispatcher. Use the Visual Administrator tool to perform this
configuration task:
27. ...
105.
1. Open the Properties tab of the HTTP Provider Service running on the
dispatcher.
106.
2. Define the port mapping as a value of the ProxyMappings property. The
value represents a comma-separated list of multiple port mappings.
A single port mapping has the following format:
<Port to be mapped>=(Host:<hostname>,Port:<port
number>,Scheme:<scheme>,Override:<true/false>)
The attributes that are specified within the brackets define the host and port to which you
map the original port. It also contains the communication scheme. The possible values of
the Scheme: attribute are http or https.
By default, the Override: attribute has a value of false. That is, if the client request contains
information about the clients host and port, the HTTP Provider Service does not override
its values with the values of the corresponding attributes of the ProxyMappings property.
However, if no host and port information is present in the request, it takes the values of the
Host: and Port: attributes of the property and sets them to the response. If, on the other
hand, you set the Override: attribute to true, the values of the Host: and Port: attributes are
always set to the response even if the request contained host and port information.
Defining a Single Mapping
If you have your engine installed on host localhost and port 50000 and want to map
it to your proxy server with host name www.sap.com and port 80 , enter the
following as a value of the ProxyMappings property:
50000=(Host:www.sap.com,Port:80,Scheme:http,Override:true)
Defining Multiple Mappings
If, in addition to the above mapping, you want to open port 50001 on host localhost
on your engine and map it to port 443 on your proxy server with host name
www.sap.com for HTTPS requests, enter the following as a value of the
ProxyMappings property:
50000=(Host:www.sap.com,Port:80,Scheme:http,Override:true),50001=(Host:www.
sap.com,Port:443,Scheme:https,Override:true)
You should map only one host to a given proxy port! Multiple hosts per port
mappings may not work as expected in cases of HTTP 1.0 clients.
107.
108.
3. Choose Update to add it to the list of properties.

4. To apply these changes, choose
(Save Properties).

You can use an SSL-enabled proxy server in front of the J2EE Engine to handle client
requests to it. You can then perform client certificate verification on the proxy server.
Consequently, the proxy attaches the public key of the client certificate to the request and
forwards it to the HTTP Provider Service on the J2EE Engine. The latter accepts the
request and logs the client without additional verification.
The default communication protocol that the proxy uses to forward the client request to
the J2EE Engine is SSL. In this case, the J2EE Engine verifies the certificate of the proxy
server (used for establishing the SSL connection) against a list of trusted proxy
certificates. This list is given as a value of the ProxyServersCertificates property of the
HTTP Provider Service running on the server process. Each certificate is specified by its
subject DN name. If the subject DN name of the proxy server certificate matches one
specified in the list, then HTTP Provider Service will accept any client certificate that the
proxy forwards with the request. If no match is found, the corresponding headers of the
requests that concern the certificates are ignored.
If the proxy server forwards the client certificates to the J2EE Engine via HTTP, they are
ignored by default. To enable certificates forwarding via HTTP, you should set the
AcceptClientCertWithoutSSL property of the HTTP Provider Service running on the
server process to true.
If you set the AcceptClientCertWithoutSSL property to true, then J2EE Engine will
always accept the client certificate forwarded via HTTP, as it is not able to verify the
certificates origin in this case.
When the proxy server forwards the client certificate, a servlet running in the J2EE
Engine Web Container gets notion of it by the
javax.servlet.request.ForwardedX509Certificate request attribute.
The value of the attribute is an array of X509Certificate objects. The
javax.servlet.request.X509Certificate attribute contains the proxy
servers certificate (if the proxy server and the J2EE Engine communicate using
SSL). If they communicate using HTTP, then this attribute has a value of null.
Client Certificate Header

The public key of the client certificate is forwarded to the J2EE Engine in an HTTP
request header. That is, the proxy server appends one additional header to the original
client request before forwarding it to the HTTP Provider Service. The name of the header
is given by the ClientCertificateHeaderName property of HTTP Provider Service
running on server process. The value of the header represents the Base64 encoded public
key of the client certificate.
If the proxy server is ICM, then the client certificate public key is passed to the J2EE
Engine in a separate block of data according to the J2EE Engine ICM communication
protocol as described in Communication Between ICM and J2EE Engine.
You need to restrict the SSL port so that it is accessible with the certificate of the
trusted proxy server only. You can do this by configuring the SSL Provider Service
using the Visual Administrator tool.
For more information on how to configure SSL on the J2EE Engine, see the
documentation of SSL Provider Service.
Other SSL-related HTTP Headers

The J2EE Engine introduces specific HTTP headers that are used by the SSL-enabled
proxy to forward client authentication information. These properties are:
Property Name
Description
ClientCertificateChainHeaderPrefix
Specifies the prefix of the name of the

header that is used for forwarding the
certificate chain the client certificate is
part of.
ClientCipherSuiteHeaderName
Specifies the cipher suite that the client

used for the secure communication with
the J2EE Engine.
ClientKeySizeHeaderName
Specifies the name of the header that

contains information about the size of the
client key that was used to encrypt data.
You can configure them using the Visual Administrator tool. To do this, you must edit the
corresponding properties on the Properties tab of the HTTP Provider Service running on
the server process. For more information about the default values of the properties, see
HTTP Provider Service.
Example of a Certificate Chain

Assume that the client certificate is part of a certificate chain with n certificates. Then, the
client certificate is transmitted as a value of the ClientCertificateChainHeader header; its
parent certificate is transmitted as a value of the ClientCertificateChainHeaderPrefix1
header; the root certificate is transmitted as a value of the
ClientCertificateChainHeaderPrefixN-1 header.
Protecting Sessions Security

J2EE Engine applications can use system cookies to track user data (such as sessions tracking,
logon data, etc). These cookies contain sensitive information about the user, therefore to prevent
potential misuse of session information the cookies should not be exposed to client side scripts.
To increase the security protection of system cookies, you can enable the use of the additional
system cookie attribute HttpOnly.
System Cookies
The J2EE Engine system cookies affected by this configuration include:
cookies named JSESSIONID (in accordance with the Java
Servlet 2.3 specification) for

tracking Web browser sessions.
cookies named saplb_ <string>, with string representing a logon group. These
cookies are issued by the Web container for session tracking.
For more information about system cookies, see
J2EE Engine Cookies.
When you enable the use of the HttpOnly attribute for these system cookies, some Web
browsers (valid only for IE version 6.0 SP1) return empty responses to JavaScript requests for
access to the system cookies.
This feature currently has effect only for Web browsers Internet Explorer version 6.0
SP1 and later. For more information about the HttpOnly feature in Internet Explorer
6.0 SP1, see the relevant documents available at msdn.microsoft.com. For
information about support of this feature in other Web browsers, consult the
documentation provided by your Web browser provider.
You use the HTTP service property SystemsCookiesDataProtection to enable the use of
the HttpOnly attribute for system cookies, by configuring the property value to true.
For backward compatibility, by default the HttpOnly attribute is not enabled for use
in system cookies. We recommend that you manually enable it after verifying that
your applications do not rely on reading system cookies on the client side .
For more information about configuring HTTP service properties, see HTTP Provider Service.
Logon Tickets
Logon tickets are cookies that are used for user authentication and Single Sign-On on the J2EE
Engine. To set this attribute for logon tickets, set the User Management Engine (UME) property
ume.logon.httponlycookie to the value TRUE.
For more information, see
SAP Logon Ticket and
Editing UME Properties.
Configuring Rules for HTTP Responses

Compression
Use
The J2EE Engine is capable of applying the IANA (The Internet Assigned Numbers
Authority) gzip message transfer encoding mechanism to HTTP responses. The purpose
is to reduce the length of the response message body to be transmitted to the client, and
hence, to achieve better communication performance.
This function is managed entirely by the HTTP Provider Service. Considering this
procedure, you can define rules that determine the behavior of the service when applying
the gzip transfer encoding to both static HTTP responses and dynamic ones (that is,
dynamic servlet or JSP responses). The only exception is that you can use a function of
the Web Container Service to configure two HTTP headers that prevent or force,
respectively, servlet or JSP responses from being compressed as described in Configuring
the Headers That Affect Dynamic Responses Compression.
Procedure
Use the Visual Administrator tool to define the gzip compression related settings:
28. ...
109.
1. Open the Properties tab of the HTTP Provider Service running on the
server process.
110.
2. Edit any of the following properties on the Properties screen:
18.
a. Specify the minimum required length of the response message to
which gzip transfer encoding can be applied using the MinimumGZipLength
property. The value of the property is specified in bytes. By default, it is 8192
bytes.
Response messages that are shorter than the value of the MinimumGZipLength
property are sent as-is. The reason for this is that for fast local area networks, data
compression and decompression is usually slower than when the data is
transmitted uncompressed. Therefore, you can use this property to utilize your
network capacity and achieve the best communication performance.
19.
b. Define a comma-separated list of file extensions or MIME types

that must always be compressed with gzip encoding as a value of the
AlwaysCompressed property. However, response messages that appear in this
list and are shorter than the value of the MinimumGZipLength property are not
compressed.
When you add a file extension to the list, it must start with an asterisk, such as
*.html. All other strings are considered to be MIME types.
There is a special value for this property: this is the string [unknown]. It refers to
dynamic response messages that do not have the Content-Type header set.
20.
c. Define a comma-separated list of file extensions or MIME types

that must never be compressed with gzip encoding as a value of the
NeverCompressed property.
When you add a file extension to the list, it must start with an asterisk, such as
*.html. All other strings are considered to be MIME types.
There is a special value for this property: this is the string [unknown]. It refers to
dynamic response messages that do not have the Content-Type header set.
21.
d. Determine whether or not the response messages types that do not

appear in the AlwayCompressed and NeverCompressed lists are compressed
with gzip encoding using the CompressedOthers property. If you set it to true,
the HTTP Provider Service compresses all other response messages that are
longer than the value of the MinimumGZipLength property.
22.
e. Specify the request URL size above which the generated response
for that request is not compressed (even if it should be according to the rules
defined by the above properties) using the MaximumCompressedURLLength
property. The URL size is specified in bytes. Using this property, you can
overcome known problems with caching compressed responses that are generated
for long URLs on some browsers.
By default, the MaximumCompressedURLLength property has a value of -1,
which means the request URL size does not affect the rules for compressing the
response.
Virtual Hosting
Use
Virtual hosting is a concept that is commonly employed by Web servers. It refers to the option of
specifying several virtual hosts within a Web server, each responding to different URL. These are
name-based virtual hosts, that is, each host name is mapped to a single real IP address of the
server or the cluster of servers. You can do this mapping using your Domain Name System
(DNS).
Use virtual hosting to:
Run several virtual hosts acting as several different Web servers on a single real IP
address
Gain in flexibility by providing different configuration settings for each of the virtual hosts
Prerequisites
You must have configured the HTTP Provider Service listen port, so that the dispatcher is able to
receive client requests. For more information about this, see Setting up HTTP Provider Service to
Accept Incoming Requests.
Features
HTTP Provider Service has a pre-set default virtual host. It can never be removed. The default
host has default configuration settings. For more information about these settings, see the
Runtime properties of the HTTP Provider Service.
When you create a new virtual host, the system assigns the same settings to it as for the default
host.
Activities
You can perform several actions to set up your virtual host completely:
Creating a New Virtual Host
Defining HTTP Aliases on a Virtual Host
Activating and Deactivating Application Aliases
Managing Virtual Hosts Caches
Changing the Root Directory of a Virtual Host
Setting the Start Page of a Virtual Host
Enabling Logging on a Virtual Host

Creating New Host Using the Visual Administrator
Open the Runtime tab of the HTTP Provider Service running on a server process.
If You Want To
Then
29. ...
111.
1. Choose New Host at the
upper part of the screen
112.
2. Enter the name of the new
host
113.
3. Choose OK
30. ...
Create a new virtual host that has the same
settings as an already existing one
114.
1. Highlight the existing host
from the list of hosts at the left part of
the screen
115.
2. Choose Copy Host at the
upper part of the screen
116.
3. Enter the name of the new
host
117.
4. Choose OK
After you have created the new host, you can still set it up differently by changing the
values of some of its properties, set new aliases, root directory, and so on.
Create a new virtual host with default settings
Creating New Host Using Telnet

Using Telnet you can create new virtual host using the HOST shell command with its
add option. The command must be executed on the server process.
You can also use some of the other options of this command to perform various setup
activities over the host that you are creating.
Result
The most important thing you have to do after you have created the new virtual host is to
map the new hosts name to an existing IP address in the DNS server. Now, when you try
to access this host via a browser using the host name in your URL, the host name is
resolved to the IP address that you have mapped to it.
HTTP Alias
The HTTP alias is an alternative name to the location of a static resource on the Web
server (such as an HTML page). That is, you map a name to a directory path on the
servers files system where certain resources are located. Clients can then use it as part of
their request URLs for fast and convenient access to these directories content.
You can set HTTP aliases that have different values for different virtual hosts you have
set up on your server. This may help you organize and manage your operations if you are
running several Web sites, both dynamic and static.
HTTP Alias vs. Application Alias

You must always distinguish between HTTP alias and application alias terms within the
context of the J2EE Engine. The first one denotes the location of a static Web page that
you can request by pure HTTP. The application alias is used for accessing a certain J2EE
Web application that is deployed and running on that particular virtual host. This
application may contain static Web resources but they have been deployed on the server
as part of the whole application WAR archive.
We recommend that you do not define the same string for an HTTP alias and the
application alias or an HTTP alias beginning with the same string as the application
alias, for example HTTP alias /string1/string2 and application alias /string1.
How to Use HTTP Alias

Once you have defined an alias, users can use it as part of their request URL to access a
resource. Have a look at the following example:
Assume your virtual host has the following settings:
Host name: myhost
Root directory: C:\server_dir\
Alias: myalias <-> C:\server_dir\mydir\Webpage\
You can access the mypage.html page using each of the following ways:
If You Are
Type In Your Browser Address Bar
Not using alias
http://myhost/mydir/Webpage/mypage.html
Using alias
http://myhost/myalias/mypage.html
In the above example, you access an HTML page that is located under the server root
directory. Therefore, you have the option of requesting it both using the alias and typing
in the full path to the page in the URL.
When you set alias to a resource that is located under the servers root directory,
you can specify the alias path as a relative path to the root directory, instead of
entering the absolute path.
See also:
Welcome Files
The InferNames property of HTTP Provider Service on server process provides a list of
welcome files; that is, it contains names of several HTML pages that the server searches
for when the request URL points to a directory, not a specific file. The first match is
returned to the client.
The welcome files list is provided so that you can configure the server to return a single
page to the client when a directory has been requested, instead of listing that directory. It
is also useful in cases when directory listing is forbidden on your host.
See also:
Directory Listing
When you request a directory, the server searches the corresponding directory for a file
with name that appears in the welcome files list. If it finds one, it returns it. If no match is
found, the server responds either with a 403 error (Forbidden), or it lists the content of
the requested directory. This server behavior depends on the Directory List property of
the virtual host. If you select the property, the server lists the directory content if the
appropriate file is not found there. In this way, the user can decide which page to open. If
you do not select Directory List property, the user gets a 403 Forbidden error message.
This is considered to be the more secure behavior of your virtual host.
Disabling and Enabling Directory Listing

You can edit the Directory List property using the Visual Administrator tool only.
Proceed as follows:
31. ...
118.
1. Open the Runtime tab of the HTTP Provider Service running on the server
process.
119.
2. Choose the appropriate virtual host from the Hosts pane.
120.
3. Then deselect/select Directory List.
If you decide to use the Telnet to set this property, you must execute the HOST shell
command with the disable dirList or -enable dirList to disable or
activate directory listing, respectively. For more information about the HOST shell
command, see the description of HTTP Shell commands group.
See also:
Application Alias
J2EE Engine
Installation Information
Specifying the J2EE Engine Client to Use for Logon Tickets
Starting and Stopping the SAP Web AS ABAP+J2EE System
Starting and Stopping the SAP Web AS J2EE System (Windows)
Starting and Stopping the SAP Web AS J2EE System (UNIX)
Architecture of the Java Startup and Control Framework
Startup, Operation and Shutdown of a Java Instance
Shutdown and Restart of the Whole J2EE Engine Cluster
Administration of the Java Startup and Control Framework
Developer Trace and Log Files
Incrementing/Decrementing the Trace Level
Creating a Stack Trace
Configuration of the Java Startup and Control Framework
Program Arguments
SAP Profile Parameters
Monitoring JCmon
Checking That All Processes Are Running
Restarting a Single Process
Troubleshooting
Message Server is Not Available (in dev_jcontrol)
Invalid Shared Library Path (in dev_<component name>)
Invalid Administration Shared Memory
The J2EE Engine Does Not Come Up After 800 Seconds
1. Check That the J2EE Engine Was Started
2. Check the JControl Developer Trace File
3. Check the Instance Bootstrap Developer Trace File
4. Check the Instance Bootstrap Log File from the Java VM
5. Check the Output from the Instance Bootstrap Java Class
6. Check Whether the Instance Bootstrap Terminates
A Missing instance.properties File
Template Installer
Clustering the J2EE Engine
Java Cluster Architecture
Java Cluster Setup
Adding Java Instances
Adding Server Processes
Configuring the J2EE Engine Cluster
Thread System

Mandatory Configuration
Optional Configuration
Tuning Web Container
Tuning EJB Request Processing
Tuning Remote Communication
Tuning Database Connectivity
Tuning JMS Provider
J2EE Engine Administration Tools
Visual Administrator
Getting Started with the Visual Administrator
Logging on to the J2EE Engine
Creating a New Connection Entry
Accessing Components
Using the Global Configuration
Shell Console Administrator
Config Tool
The GUI Config Tool
Connecting to a Database
Getting Started with the Config Tool
Server Configuration
Configuring Instance Properties
Modifying Manager or Service Properties
Searching a Particular Property
Exporting and Importing a Configuration

Managing Secure Store Data
UME LDAP Configuration Tool
The Text-Only Config Tool
Connecting to a Database
Configuring the Global Properties
Configuring Instance Properties
Configuring Cluster Element Properties
Core System Modules
Class Loading System
Registering References
ClassLoader Reference Viewer
Working with the Reference Viewer
Thread System
Configuring the Thread Pool
Configuring the Request Queue
Dynamic Allocation/Reallocation of Resources
Cluster Manager Configuration
Communication Management
Ports Management
Service Management

Web Container
Requests Parsing
Setting up HTTP Provider Service to Accept Incoming Requests
Mapping Ports
Protecting Sessions Security
Configuring Rules for HTTP Responses Compression
Virtual Hosting
HTTP Alias
Application Alias
Activating and Deactivating Application Aliases
Managing Virtual Hosts Caches
Changing the Root Directory of a Virtual Host
Setting the Start Page of a Virtual Host
Configuring the Zone Separator
Configuring Persistent Connections
Limiting the Length of the Requests Headers
Limiting the Length of the Request Body
Long Data Transfer Mechanism
Setting up the Size of the InputStream Read Buffer
Specifying the Size of the File Buffer
Update the HTTP Cache Content
Configuring the HTTP Cache
Configuring HTTP Responses Caching by Client Caches
Configure Traces and Logs for HTTP Communication
Enabling HTTP Traces
Tracing HTTP Requests Using Session Tracing
HTTP Access Logs
Enabling Logging on a Virtual Host
Logging in Common Log File Format
Logging Additional Information

HTTP Access Logging Specifics When Using Solution Manager Diagno
Masking Security-sensitive Data in the HTTP Access Log
Troubleshooting Application Errors
Managing MIME Types
Web Container Service
Response Chunking
Specifying Compilation Time of JSP Files
Specifying Servlet Execution Destroy Timeout
Setting up the Compiler
Configuring Headers That Affect Dynamic Response Compression
Configuring the Name of the Multipart Body Request Attribute
Delaying User Authentication
Providing Custom Response Messages When Requesting Stopped Appli
Isolating Running Web Applications from Productive Client Reques
Enable and Configure Tracing for Web Applications
Troubleshooting 404 "File Not Found" Errors
Runtime Administration of Web Applications
Managing Welcome Pages, Error Pages, and Response Status Codes
Managing Tag Libraries
Mapping Servlets and Filters
References
Managing Enterprise Bean Remote References
Managing Enterprise Bean Local References
Managing Resource References
Managing Environment Entries
Managing Resource Environment Entries
Managing Component References
Managing Context Parameters
Managing MIME Mappings
Additional Configuration Settings
EJB Container
Monitoring Enterprise Beans
Runtime Changes in Deployed Enterprise Beans
Changing Enterprise Beans Properties at Runtime
Generating persistent.xml for Container-Managed Entity Beans
Enabling IIOP Support for EJB Applications

Starting and Stopping Message-Driven Beans
Deploy Service
Runtime Administration
Deploying and Updating an Application
Removing an Application
Starting and Stopping an Application
Getting a Client JAR
Setting a Failover Mode
Application Startup Modes
Deployment Operations
Application Statuses
Message Handling Using JMS
Managing Instances
Managing Topics and Queues
Managing JMS Connection Factories
Web Services Container Service
Configuring Proxy Settings
UDDI and SLD Publication
Managing the UDDI Client
Managing the UDDI Server
Proxy Configuration
Web Service Logging and Tracing
Failover System
Specifying the Failover Persistent Storage
Transactions and Resource Handling
Transaction Service
Local Resource in Propagated Transaction
Transaction Timeout Management
Connector Container Service

Viewing Resource Adapter Configuration
Modifying Loader References
Modifying ManagedConnectionFactory Properties
Cloning a Resource Adapter Configuration
JDBC Connector Service
Creating a DataSource with JDBC 1.x Driver
Creating a DataSource with JDBC 2.0 Driver
DataSource Data Import and Export
Managing Connection Pooling
Connection Transaction Isolation
Managing Aliases
Deploying and Removing JDBC Drivers
Defining and Un-defining JDBC Drivers
SQL Engine
Initializing the Database
DataSource Monitoring
JMS Connector Service
Registering a JMS ConnectionFactory using JNDI-Based Provider
Registering a JMS ConnectionFactory using Non-JNDI Provider
Registering a JMS Destination
Editing JMS ConnectionFactory and Destination
JMS ConnectionFactory and JMS Destination Import and Export
Deploying and Removing a JMS Library
Defining and Un-defining a JMS Library
Managing JMS Connections Number
Integrating an External JMS Provider
Naming System
Assigning and Removing Access Permissions
Browsing the Naming Tree
Communication Services
P4 Provider Service
Managing the Underlying Transport Layers
Allowing Access to a Host
Limiting the Size of P4 Requests
Remote Objects Communication Within a Single JVM
Runtime Information
IIOP Provider Service
Remote Object Container Service
Utility Services
Administration Services
JMX Notification Service
JMX Adapter Service
Connecting and Working Using Telnet
File Transfer Service
HTTP Tunneling Service
Java Mail Client Service
Runtime Info Provider Service
Web Application Server Integration
ABAP Communicator Service
JCo RFC Provider Service
Registering a Destination
Configuring an RFC Destination to use a Secure Network Connectio
Connecting J2EE Engine to the CCMS
Tracing JCo Calls
Administration of Central Services
Locking Adapter Service
Architecture of the Locking Adapter Service
Creating and Releasing Locks
Administration of the Locking Adapter Service Using the Console
Troubleshooting
Application Locking Service
Administration of Application Locking Service Using the Console
Message Info Service
Architecture of the Message Info Service

Connecting the J2EE Engine to DBs
Configuration Manager
Configuring a Database Connection
Security Aspects for the Database Connection
Configuration Adapter Service
Configuration Objects
Managing Configuration Objects
Configuration Monitoring
Configuration Cache Management
Reference
J2EE Engine Ports
Shell Administration Commands
Dispatcher
ADMIN
CONFIGURATION
HTTP
JMS
KEYSTORE
LOG
MONITOR
R3STARTUP
SSL
SYSTEM
TELNET
Server
ADMIN
CONFIGURATION
CONNECTOR
DBPOOL
DEPLOY
DSR
EJB
FAILOVER
HTTP
JMS
JMSCONNECTOR
JMX
KEYSTORE
LOG
LOGIN
MONITOR
NAMING
R3STARTUP
SECURESTORAGE
SERVLET_JSP
SYSTEM
TELNET
USER
WEBSERVICES
Administration Properties
Managers
ApplicationThread Manager
ClassLoader Manager
Cluster Manager
Configuration Manager
Connections Manipulator Manager
IpVerification Manager
Log Manager
Ports Manager
Service Manager
Thread Manager
Services
ABAP Communicator Service
Deploy Service
HTTP Tunneling Service
IIOP Provider Service
Java Application Response Time Measurement (JARM)
Java Mail Client Service
JCo RFC Provider Service
JDBC Connector Service
JMS Provider Service
JMS Connector Service
JMX Adapter Service
JNDI Registry Service

Log Configurator Service
Log Viewer Service
Monitoring Service
P4 Provider Service
PMI Service
Security Provider Service
Session Failover Service
SLD Data Supplier Service
SSL Provider Service
Shell Administration Service
Telnet Provider Service
Timeout Service
Transaction Service
Web Container Service
Managers Overview
Services Overview

J2EE Engine

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

J2EE Engine

Uploaded by

Copyright:

Available Formats

J2EE Engine

Configuration Steps Following Installation

Applying for and Installing the SAP License

Specifying the J2EE Engine Client to Use for Logon Tickets

Specifying the J2EE Engine Client to Use for Logon

Checking the Property in the Policy Configurations

ume.configuration.active=true is set in the policy configuration for the

Checking the Property in the User Store Configuration

Setting the J2EE Engine Client

Options for the

Licensing the J2EE Engine

Specifying the J2EE Engine Client to Use for Logon

Checking the Property in the Policy Configurations

Checking the Property in the User Store Configuration

Setting the J2EE Engine Client

UME Configuration Active or

Options for the

Licensing the J2EE Engine

Requesting and Installing the SAP License

4. In the Licensing Adapter in the Visual Administrator choose Install License

Starting and Stopping the J2EE Engine

Starting and Stopping the SAP Web AS ABAP+J2EE System

Starting and Stopping the SAP Web AS J2EE System (Windows)

Starting and Stopping the SAP Web AS J2EE System (UNIX)

Safe Mode in the J2EE Engine

Starting and Stopping the SAP Web AS ABAP+J2EE

Ending the Process (With or Without a Restart)

This sets the J2EE Engines restart flag.

Starting and Stopping the SAP Web AS J2EE System

1. On the SAP system host, choose Start Programs SAP Management

In the Database Manager, choose Online.

The database status changes to online (green color).

Monitoring the Status

Stopping the SAP System

3. Select the system and choose OK two times.

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

6. Click on the Refresh tree

Starting and Stopping the SAP Web AS J2EE System

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

On the central services instance host, enter:

On the central instance host, enter:

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

Stopping the SAP System

On the central services instance host, enter:

On the database host, enter:

Safe Mode in the J2EE Engine

35. From the Safe Mode Enabled drop-down list, choose:

Architecture of the Java Startup and Control

Startup, Operation and Shutdown of a Java Instance

Java Startup and Control Framework

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

Startup, Operation and Shutdown of a Java

Send request to shut instance down

Terminate hanging processes

The program JControl is part of the standard delivery.

Startup of the Java Instance

The first argument of JLaunch is the PID of the parent process

The first argument of JLaunch is the PID of the parent process

Creates JVM arguments and initializes hosting of the VM.

Operation of the Java Instance

Shutdown of the Java Instance

An instance is stopped as follows:

Shutdown and Restart of the Whole J2EE Engine

Shutdown of the J2EE Engine Cluster