This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
The Web App Server prov ides a c omm on foundat ion for NetWeaver
The Web Application Server isthe comple te in f ras t ruc ture
to develop, deploy and run:
All SAP NetWeaver components
mySAP Business Suite
Customer-developed
applications
3rd-party Java 2—Enterprise
Edition-compliant
applications
Integrates the proven ABAP
and the innovative in ternet -dr iven Java technology in one
application server
SAP NetWeaver™
CRM
mySAP Business Suite
BW EP XI MI MDM
Web Application Server
ERP SRM
J2EE ABAP
The SAP Web Application Server is the technical platform for SAP NetWeaver,
providing the complete infrastructure to develop, deploy and run all SAP NetWeaver components, the mySAP Business Suite, customer-developed applications and 3rd-
party J2EE 1.3 compliant applications.
SAP Web AS fully supports both the proven ABAP technology and the open source
internet-driven technologies—Java and Java 2 Enterprise Edition, also called J2EE.
1. Master Guide – SAP NetWeaver Which technical scenario do you want to install?
Technical system landscape
Required components
Installation sequence
2. Installation Guide – SAP Web AS ABAP and/or
Installation Guide – SAP Web AS Java
3. If relevant: Planning Guide – SAP Web AS on UNIX: Oracle
Information about basic system variants, instances, distribution,
installation options (MCOD, LDAP, …), and detailed parameter tables for
your installation service
4. UNIX only: SAP Software on UNIX: OS Dependencies 5. New Troubleshooting Guide for the Java installation
Master Guide
The Master Guide is the starting point for implementing SAP NetWeaver.. It lists the required SAP componentsand third party applications that are required for each scenario. It provides scenario-specific descriptions of
preparation, execution, and follow-up of an implementation. It also offers references to other documents,such as Component Installation Guides and SAP Notes.
Target group:
Technology consultants
System administrators
Project teams for implementations
The Master Guide is regularly updated on SAP Service Marketplace at service.sap.com/instguidesNW04.
Make sure you have the latest version of the Master Guide by checking Service Marketplace immediatelybefore starting the installation.
Now there is only one NW - Master Guide, no longer separate master guides for the different components.
Component Installation Guide
The Component Installation Guide describes the technical implementation of an SAP component, taking into account
the combinations of operating systems and databases. It does not describe any business-related configuration.Target group:
Technology consultants
Project teams for implementations
Current version is located on SAP Service Marketplace at service.sap.com/instguidesNW04
Application server installation guides are separated by ABAP and Java part. When doing Add-in installation both of them must be considered.
There is also Java Support package guide it is required if patching older version of Web AS Java.
Concept o f Ins ta l la t ion Check l is t s in Ins ta l la t ion Gu ides
List chronologically the actions that you must perform: You choose and print out the relevant installation checklist(s) for your
installation (there is one checklist for each installation service).
If a step is required for your installation, you follow the link for that stepto the corresponding section.
You perform the procedure described there.
After successfully completing the installation step, you mark thecorresponding entry in the printed table with ! to log the progress of your installation.
You proceed with the next step in the checklist
General Information
Installation Checklists
Step 1
Step 2
…
Step n
Preparation
Installation
Post-Installation
Additional Information
Planning
Concept not new, but essential for
navigation in installation guides
Installation Checklists
References
Print
This is not new but convenient way to follow the Installation steps.
If SAPinst prompts for a CD, it will be possible to select thecorresponding sub-directory (browse the DVD)
New supported OS and Database versions:
Linux and Windows IA64
MySQL MaxDB 7.5
IBM DB2 Universal Database for UNIX and Windows
IBM Informix (ABAP schema only)
See SAP Service Marketplace at http://service.sap.com/platforms
for the latest information.
Check the installation guide before performing an installation for changes. For
example immediately after the installation you may need to apply a support package. The installation now is shipped on DVD, however the installation is still pointing to
different CDs, you’ll find them all stored on this data carrier.
MySQL MaxDB is the former SAP DB
Oracle 10g will be released at the Q1/2005
J2EE Engine is using Unicode enabled databases. Informix doesn’t support Unicode
and is not possible to be used as J2EE Engine Database. For Add-in installation
where the ABAP stack is using Informix, other (Unicode supporting) database must
The installation provides possibility to install Web AS Java + Java Developer
Workspace at once. This is fast and very convenient way for developer, where theyhave testing server and the developer IDE on one box. All configurations are
predefined.
The Java only installation is distributed by the different databases. The customer
installation package contains one DB installation option only.
J2EE Engine is using Unicode enabled databases. Informix doesn’t support Unicode
and is not possible to be used as J2EE Engine Database. For Add-in installation
where the ABAP stack is using Informix, other (Unicode supporting) database must
You need a valid SAP license to log on to the SAP Web AS. When the SAP Web AS is installed, a temporarylicense 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 importthe ABAP license (see SAP License).
This section only describes the procedure for the J2EE only Installation.
In the Visual Administrator choose Server -> Services -> Licensing Adapter. The system data that you need torequest the license from the SAP Service Marketplace appears.
Installation number (if it exists)
System ID,
System number (if it exists)
Hardware key
Current release
Under the Internet address service.sap.com/licensekey -> 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 requestlicense keys.
Enter your e-mail address in the request. The license key will be sent to you promptly by e-mail. Alternatively, youcan also download the license key from the SAP Service Marketplace.
Do not make any changes to the license key. To import the license key, the file must not have been changed.
In the Licensing Adapter in the Visual Administrator choose Install License from File.
Select the license file that you want from SAP.
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.
See SAP note 94998 for additional information about requesting license keys.
You could install multiple licenses, for example when running scenarios as EP and XI.
You need a valid SAP license to log on to the SAP Web AS. When the SAP Web ASis installed, a temporary license (29 days) is also installed which you must replacewith a permanent license.
With an ABAP + J2EE installation you need an ABAP license!
In the Visual Administrator choose Server 0 → Services → Licensing Adapter. Thesystem data appears that you need to request the license from the SAP ServiceMarketplace.
Installation number (if it exists)
System ID
System number
Hardware Key
Current Release
service.sap.com → Software Distribution Center →mySAP Business Suite → license key requests
After SAPInst has started navigate to -> SAP NetWeaver ’04 JavaSystem (J2EE only) -> MaxDB -> Central System -> Custom Installation -Java System
And press Next.
Note: SAP distributes Web AS installation exclusively on DVD.Nevertheless SAPInst is looking for CDs which you can find copied as foldersin the DVD storage.
Choose SAP NetWeaver ’04 -> J2EE System -> Central System -> Install aJ2EE Server in Custom Mode
Click on the icon in the white label bellow Package Location
Users log on to the dispatcher and work processes perform the users’ tasks.
Processing Web requests.
Web requests are received by an Internet Communication Manager (ICM). These HTTP(S) requestsmay be designated for the Internet Communication Framework (ICF), that is, processed in an ABAPwork process (for example, BSP Applications), or they may be J2EE requests, designated for the J2EEEngine.
For each incoming HTTP request, the ICM must decide whether it should forward the request forprocessing to the ABAP engine (the ICF) or to the SAP J2EE engine. This decision is made using theURL prefix. A separate protocol is used for the communication between the ICM and Java Dispatcher.The ICM can be set up so that the communication with the J2EE Engine is SSL-encrypted.
The ICM server cache saves HTTP(S) objects before they are sent to the client. The next time an object isrequested, then, the application gets the content directly from the cache before sending it to the client.
You can also use the Internet Server Cache with the J2EE server, in order to store HTTP responses (such asHTML pages or images). The next time, the request can be retrieved directly from the cache
The HTTP request handler uses the ICM Server Cache when, for example, response pages need to be re-used,such as the entry page of an online shop application. The ICM server cache saves the pages before they are sentto the client. When the page is next called, then the application gets the page directly from the ICM and sends itto the client.
Additionally to the ICM server HTTP(S) cash, the Java Dispatcher implements HTTP(S) cash as well.
To be able HTTP request to be redirected to the J2EE Engine, the following services must be active in the HTTPservice tree (Transaction SICF):
/sap/public/icman - The ICM uses this service to forward requests to the J2EE Engine.
/sap/public/icf_info - Supplies the SAP Web Dispatcher with details of logon groups, server load, etc.
One or more Java instances (Java Dispatcher, Server) and the Software DeploymentManager (SDM)
The Central Services (Messaging Service, Enqueue Service), which also create aninstance (Central Instance)
Ax external database.
Changes in architecture of J2EE – Engine are made since 6.20
A J2EE Cluster now consists of an Central Service Instance. One Central ServiceInstance is required in the J2EE Cluster.
The Configuration of the J2EE Engines are now stored in a Database. Not any morestored in XML-Files in the file system. A database for the J2EE Cluster is required.
An Startup and Stop Framework is used.
In a large Java cluster installation, the load is distributed from a load balancer ontothe different Java dispatchers.
The Central Services run on one physical server and are one Java instance. They comprise theMessage service and the Enqueue service.
The Central Services form the basis of communication and synchronization for the Java cluster.
Central Services are always required when a Java cluster is installed. They are started on a serverwith their own system number and the system ID (SID) of the whole system.
When Central Services are running, further Java instances (Dispatcher, Server) are started with theprogram JControl
The message service is a separate program used for communication between the elements of a Javacluster. It keeps a list of all processes (dispatchers and server) of the Java cluster. It represents theinfrastructure for data exchange (small datasets only) between the participating nodes. The messageservice also supplies information to the SAP Web Dispatcher about Load Balancing.
Processes on Operating system level
NT: msg_server.exe
UNIX: msg_server
Trace file:
dev_ms in work directory of Central Service Instance
The settings and the status of the message service are made accessible to the administrator via themessage Info Service in Visual Administrator described bellow.
Message server and Message Service are used synonymously. The correct expression would be thatthe Message Server is a process or program that provides the Message Service.
The message info service is the interface between the J2EE Engine and the
Message Service, it is used it to monitor and administrate the message server. The message service doesn’t communicate direct to the Message Server, but it is
using the cluster manager, which has a direct connection to the message server.
The message info service is not automatically started when the J2EE Engine isstarted. If should be started manually:
Using the SAP J2EE Engine visual administrator.
1. Choose Cluster → Server 0 → Services
2. Choose Message Info
3. Choose Start Service in the toolbar
Using the telnet console.
1.In the console where the server process is running, enter the command:startservice msp
• The Message Info Service data should be used mostly for supportability purposes, becareful
The Enqueue service runs on the Central Services instance of the Java cluster. It
manages the lock table in the main memory and receives requests for setting orreleasing locks.
It also maps the logical locks to the database.
The Enqueue service can be configured for high availability, by setting it up with thereplication server and a platform-independent high availability solution.
The status of the Enqueue service are made accessible to the administrator via theLocking Adapter Service in the Visual Administrator.
The terms Enqueue server and Enqueue service are used synonymously. Thecorrect expression is that the Enqueue server is the program or process that provides
the Enqueue service.
Enqueue Service is represented by an en.sap<SAPSID> process
The locking adapter service establishes the interface between the J2EE Engine and the enqueue service.
You can display and manage locks, carry out tests, and display statistics.
The locking adapter service is available on each server process, but it is not available on the dispatcher. It connects to theEnqueue Service and fetches requested data or sends changed data to it. As there is only one enqueue server in the system,all the locking services of the various server processes have the same information. Therefore it is not important on whichserver process you use the locking adapter service.
Locks are used for example during deployment of applications. The configuration manager requests a lock from the Locking
Manager. The Locking Manager in turn requests the lock from the Enqueue Service. The relevant area in the database islocked
To look into the Locking Adapter use the following path:
1. Start the SAP J2EE Engine visual administrator.
2. Choose Cluster -> Server 0 -> Services
3. Choose Locking Adapter
Choose the Runtime tab page to see a list of the functions offered in the locking adapter service:
To display existing locks; choose Display Locks.
To set and release locks, choose Create/Release Lock.
To delete existing locks, select the locks and choose Delete Selected Locks.
To run test programs, choose Run Tests . To run functional tests choose Execute Functional Tests, and to load testschoose Execute Load Tests ).
To display files, choose View Files . You can view the profile data or the trace file of the lowest layer of the enqueueservice. This is useful for looking for errors.
A Java instance is a unit in the SAP Web Java cluster, which can be started,
stopped, and monitored separately. It runs on a physical server; but it is also possibleto run several instances on one server. An instance is identified by the system ID(SID) and the instance number.
One Java instance contains at least one Dispatcher and one Server Process, theCentral Services (Message, Enqueue) and the SDM.
A Java instance is started and stopped by the Java Startup and Control Framework.
The Java dispatcher receives the client request and forwards it to the server processwith the lowest capacity usage. If there is already a connection to the client, therequest goes to the server process that processes this client.
Dispatcher processes are represented by a jlaunch processes
The Java Dispatchers do not communicate to each other, they are light applicationsused for load balancing to the local servers only.
Interprocess communication Dispatcher on one box – Server on other box is notpossible.
The Server Processes of the J2EE Engine actually execute the J2EE application.
Each server process is multi-threaded, and can therefore process a large number ofrequests simultaneously. Java Dispatcher assigns requests to the server processes.
The identification of the jlaunch processes can be easy done with their PID, the PIDis also represented in the monitoring tools as the SAP Management Console.
Another special instance is the one that installed the SDM (Software Deployment Manager). This oneusually runs with the database and Central Services on the same machine and is then indicated as the
central instance .
The Software Deployment Manager (SDM) is a tool with which you can manage and deploy softwarepackages that you receive from SAP or created with NetWeaver Developer Studio.
The Software Deployment Manager (SDM) groups several different deployment types in a singlenetwork interface for the deployment of any software that you develop with the SAP NetWeaverDeveloper Studio.
In all modes SDM is only able to handle one access at a time.
On the SAP system host, choose Start -> Programs -> SAP Management Console .
You use this procedure to start/stop and monitor the processes of the SAP systemafter the installation. You can use also the SAP NetWeaver Developer Studio when indevelopment to start and stop the SAP system.
You have to start/stop monitor the following components:
Database (SAP DB)
Central Services (Enqueue Service and Message Service)
The start and stop of the SAP system are done using the scripts startsap and
stopsap in the exe directory. You have to be logged on to the SAP system hosts as user <sapsid>adm.
If there are multiple SAP instances on one host – for example, a central instance anda dialog instance you have to 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 centralinstance is JC<Instance_Number>, the instance name of a J2EE dialog instance isJ<Instance_Number>.
To view all the processes use command: ps -ef | grep jlaunch
You can manage the Java Engine from the SAP Web AS ABAP, however the Java Engine it is not startedautomatically. The parameter disp/j2ee_start activates or deactivates starting the J2EE Engine, it
should be set to 1 so that the J2EE server is started automatically.
Note: The start of the J2EE Engine is automatically deactivated (disp/j2ee_start = 0) if a specificnumber of attempts to start the server failed (rdisp/j2ee_error).
Profile parameter within the J2EE Engine in transaction RZ11:
icm/HTTP/j2ee_<xx> Determines the ICM’s communication with the J2EE Engine.
Exe/j2ee full path to JControl
rdisp/j2ee_error Number of incorrect attempts to start a J2EE Enginebefore the restart is deactivated.
rdisp/j2ee_start Activates or deactivates starting the J2EE Engine.
rdisp/j2ee_start_lazy
If 1 and if the rdisp/j2ee_start is set - the J2EE Engine it is not started until the ABAP runtimeenvironment has been fully initialized. This avoids problems that are caused by a long initializationphase.
If 0 (default) – the J2EE Engine can be started without waiting for the ABAP initialization.
rdisp/j2ee_timeout Time span, the J2EE Engine must log on to the Web Dispatcher.
You can use the ICM to manage the Java Engine as well. You can find the functions in the ICM monitor(Transaction SMICM or by choosing Administration → System Management → Monitor → System
Monitoring → Internet Communication Manager ) choose Administration → J2EE Server on the initialscreen.
The following functions are available:
Sending a Soft Shutdown (With or Without a Restart):
The (ABAP) dispatcher of the SAP Web Application Server sets the restart flag for the J2EEEngine and sends the SOFTSHUTDOWN message to the J2EE Engine. The dispatcher doesnot actively close the connection, the J2EE Engine must close itself instead. If the applicationserver 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 J2EEEngine 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 theapplication server is restarted, the J2EE Engine is restarted by the (ABAP) dispatcher.
Ending the Process (With or Without a Restart):
The SAP Web Application Server’s dispatcher sets the restart flag for the J2EE Engine andsends a signal to the process (shell or Java process). If the application server is restarted, theJ2EE Engine is restarted by the dispatcher.
Startsap and stopsap have to be launched by user <sid>adm.
The J2EE startup and control framework mainly comprises the programs JControl and Jlaunch.
JControl: A native program that 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 theJLaunch processes.
JLaunch: Starts a Java program. It loads the JVM into its own address space and then represents the required clusterelement. 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).
Bootstrap: This JLaunch process synchronizes the binary data from the Java database with the local file system andcreates a property file, which describes the configuration of the Java instance. Note 710663 shows the different modesconfigurable for bootstrapping.
I. Start of JControl - JControl is started (in Windows by the SAP start service; on UNIX platforms by the startsap script).This script must be executed by the <SAPSID>adm user.
II. Signal handling - JControl initializes the SAP signal handling to be able to handle signals received. Signal can be sendvia kill command (Unix) or sapntkill.exe (Windows NT). Important Signals:
SIGINT - Initiates a soft shutdown
SIGSEGV - Initiates a hard shutdown
SIGUSR1 - Increment the trace level.
SIGUSR2 - Decrement the trace level
The bootstrap.property can be found under the folder: /usr/sap/<SID>/<InstName>/j2ee/cluster/bootstrap
The instance.property can be found under the folder: /usr/sap/<SID>/< InstName >/j2ee/cluster
JLaunch (J2EE Dispatcher, J2EE Server, SDM)• Reads process specific properties• Attach to SHM segment created by JControl• Parametrizes, loads and hosts JVM
startsap (UNIX) / SAP Service (Windows) starts 1 instance of …
Arc hi t ect ure of SAP J2EE Star t up Framew ork 6.40
The graphic above provides a functional view on the J2EE startup and control framework.
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 JVM arguments and initializes hosting of the 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 fileinstance.property (3). The file instance.property contains the description and the arguments of theJ2EE cluster elements that are to be started.
JControl reads and creates a list of the 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, whichends 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 executesthe following steps:
Starts the “ offline“ configuration manager to read the properties for the Java Enterprise runtime fromthe database and to save them in various hash tables (6).
Stops the “offline“ configuration manager and starts the Enterprise Java runtime with the savedproperties.
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. 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 anotification using a named pipe to all of the running cluster elements (2).
The JLaunch process of the Java cluster element must respond to the notificationwithin a defined time interval. (If this soft shutdown does not work, the JLaunchprocess is completely terminated by JControl.) It triggers the shutdown of the Java
Instance element in the JVM and waits for its own VM to terminate (3).
JControl: A native program that starts, stops, and monitors the processes of a Java
instance (usually a dispatcher and several server processes). The programimplements the SAP signal handling to stop the instance. JControl starts the JLaunchprocesses.
JControl controls J2EE processes …
is the master process of all J2EE worker processes
controls the lifecycle of the J2EE instance
Restart of crashed processed
Termination of hanging processes
Sends shutdown signal to instance processes
responsible for starting the processes in the right order (bootstrapping..)
integration of different processes into one J2EE instance (SDM, ICM, ...)
provides the monitoring information in a shared memory segment
supports SAP profiles to share configurations with the ABAP Stack
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 from notificationfrom the JControl process via named pipes to stop the cluster element, andterminates, if the JControl stops running (fork emulation under Windows).
Dispatchers and servers are started by JLaunch processes. In the jlaunch trace file,the JlaunchISetState can be checked. The start of the server process is correct, ifstatus 3 is reached:JLaunchISetState: change state from 2 to 3
How t o c hec k t he c orrec t st ar t up using J CMon
JCMON
displays the serverprocess in status“Running” only, if allapplications havebeen started upsuccessfully.If an application is stillin the startup process,JCMON will describethe status as “Startingup”.
SAPMMC
has to change theserver status from“RED” to “GREEN”.
The developer trace files can be seen for every process in the process tree from the
SAPMMC (in Windows). Right click on the process and choose “Developer Trace”. The developer trace files can be watched directly from their location as well (for all
OS). All the files are all stored into the jlaunch traces and the output files in the /usr/sap/<sid>/<instance>/work folder.
I. In the mixed mode with the ABAP Stack, please choose“shutdown without restart” in the transaction smicm.
II. Check, if there are jcontrol or jlaunch processes running(Task manager on Windows NT, “ps –ef | grep <SAPSID>”).Kill first the jcontrol process and afterwards the jlaunchprocesses, if there are such processes running.
III. Copy the latest Startup Framework into the os_libs directoryof the J2EE instance:
I. Unix: /usr/sap/<SAPSID>/< INSTANCE_NAME >/j2ee/os_libs
II. Windows: c:\usr\sap\<SAPSID>\< INSTANCE_NAME > \j2ee\os_libs
IV. Cleanup the administration shared memory. Execute“jcontrol pf=<SAP instance profile> -c” to invoke the sharedmemory cleanup.
Online ONLYText- Start/Stop and configure Servicesand Managers.
- Start/Stop nodes.
Shell console Administrator
JVMOffline ONLYJavaGUI
Configuration of the current state ofthe Configuration Database.
Configuration Editor
JVMOnline or OfflineJavaGUI
- Add/Delete instance nodes.
- Java memory settings.
- Permanent configuration changes
GUI Config Tool
JVMOnline ONLYJavaGUI
- Start/Stop and configure Servicesand Managers at runtime.
-Start/Stop nodes.
-Runtime administration of Services
Visual Administrator
REQ.J2EE ENGINEUIMAIN FEATURESTOOL
The “J2EE Engine” column refers to the status of the server node while working with thetool. In same cases even an Online tool would have to restart the node so the changestake effect.
Java Message and EnqueueServer Host and Port number.
SDM Server Info.
Node version Info.
Dispatcher nodemain ports
License Info.
Database Info.
This is a good starting point to see a overview of the most important information of theSAP Web AS running system:
System/Instance/nodes identification
Instance and node state
Hostnames and Open ports
DB and OS version
Installed Java software
Java Runtime Environment version and settings
Licensing information
You have to log on to the J2EE Engine server as an Administrator to access the page:http://<hostname>:50000 -> System Information
The VM Parameters link shows the Java Virtual Machine (JVM) settings for theselected node. This is the better place to see these settings for a running node.
Visual Admin is t ra t or : Connect ing v ia Message Serv ice
Transport Layers
Default: use Java RMI / P4
NI: SAP Network Interface
Load Balancing Method
Random: The Message Server will select a dispatcherrandomlyManual: The Message Server will select a dispatchermanually
Use this type of Connection if you like to balance your administration connections between the differentserver processes of your system or you don’t know the host name and P4 port number of any dispatcher
(or you are not certain which one is running).
Remember that the Message Server is only used to obtain a Dispatcher. After the Dispatcher is chosen adirect network connection to it is created.
Follow these steps to create this type of Connection:
1. Specify the user name.
2. Specify the host and the HTTP port of the Message Server (you can find this in the trace of the messageserver of the Java Central Instance).
3. Choose a load balancing method for the connection – that is, whether the dispatcher to connect to will beselected randomly by the Message Server or manually by you.
4. Specify the transport layer type:
Default – the connection is done using RMI/P4 protocol (P4 is a proprietary protocol, RMI is RemoteMethod Invocation)
NI – the SAP Network Interface (NI) layer enables you to connect to a SAProuter.
If you use this layer, you have to specify the Route String that defines the connection path to the SAProuter by
Visual Admin is t ra tor : Connec t ing to a D ispatcher
Transport Layers
Default: use Java RMI / P4
SSL: Provides privacy over the Internet using
cryptographic securityHTTP Tunneling: Allows communicationthrough proxies and firewall
HTTPS: Using SSL with HTTP Tunneling
NI: SAP Network Interface
Use this type of Connection if you know the host name and port number of a running dispatcher and/or you want touse HTTP as the communication protocol between the Visual Administrator and the Dispatcher.
Follow these steps to create this type of Connection:
1. Specify the user name.
2. Specify the host name (or IP address) and the port of the Dispatcher.
3. Specify the transport layer type:
Default (P4) – the connection is done using RMI/P4 protocol
SSL (P4 over SSL) – use this option if you want to enable encrypted client-server communication
HTTP Tunneling (P4 over HTTP) – use this option if the communication is through a proxy or firewall.
If you use this layer, you have to specify the HTTP Tunneling proxy host and port by choosing Settings . HTTPS (P4 over HTTPS) – this transport layer includes both HTTP Tunneling and SSL features. The
communication between the Visual Administrator tool and the SAP J2EE Engine is performed through proxies andfirewalls, using cryptographic security.
If you use this layer, you have to specify the HTTP Tunneling proxy host and port by choosing Settings .
To use the SSL or HTTPS layer you must have the Key Storage Service and SSL Provider Service running. Touse HTTP Tunneling you must also have the HTTP Tunneling Service started.
NI – the SAP Network Interface (NI) layer enables you to connect to a SAProuter.
If you use this layer, you have to specify the route string that defines the connection path to the SAProuter bychoosing Settings .
SAP J2EE Engine Visual Administrator is a graphical user interface (GUI) that enables administration ofthe whole cluster, all cluster elements, and all modules running on them. It provides remote monitoring andmanagement of managers, services, libraries, and interfaces working on each element in a single GUI.
Features
Start/Stop of nodes (not instances or systems)
Start/Stop of Services/Managers
Obtaining the properties of a service, manager, interface, or library (for example, its name, group, and soon)
Administrating and changing the properties for an specific node or globally for all nodes of the same type(dispatcher or server).
Runtime administration and control, and perform large parts of the system monitoring
Constraints
You cannot create new server processes using the Visual Administrator. Use the Config Tool to do this.
You can use the Deploy Service of the Visual Administrator to deploy and update your applications.However the use of the Software Deployment Manager (SDM) is recommended.
Visual Admin is t ra t or : Acc ess ing Local Conf igurat ion
LocalProperties
Dispatcher node
components(Managers expanded)
Server node components(Services expanded)
Runtime tab of theClass Loader Service
Info tab of theWeb Service Interface
Additional Info tab of the
HTTP Provider Service
Properties tab of theHTTP Service
From the Visual administrator you have access to the properties of the nodes of an specific instance (Cluster tab) or to the generic properties of a dispatcher or server node (Global Configuration tab).
The Runtime tab shows dynamic information and let you do online administration of the service.
The Info tab shows information about the naming, versioning, references to other components, JARscontained and a description.
The Additional Info tab shows the name, version, references to other services and startup information of theselected service.
The Properties tab shows, and let you edit, the static parameters of the selected service (to change aproperty just select it, enter the new value, click update an then saving icon).
For every Manager, you’ll have a Properties tab.
For every Service you’ll find the Properties , and Additional Info tabs (some of them also show a Runtime tab, see appendix).
The J2EE Engine components have two types of properties: global and local. Globalproperties are common for all cluster elements while local properties are only validfor a specific cluster element.
Each property has a default value and a custom value.
The default value of a property is assigned by the time of its creation (you can not create local default properties withthe Visual Administrator).
The custom value of a property is created the first time a default value is modified.
When, for example, a property value is changed using the Visual Administrator in aspecified node, this property is saved as a local custom property for that node.
The runtime value of a property is formed in the following way: if a custom valueexists, this is the actual value of the property, else the default value is used.
Visual Administ rator : Acc essing Global Conf igurat ion
1.- Click on a property
to edit its custom value
2.- Press Update
when done editing
3.- Click on Save
to commit changes on all dispatcher nodes
Working on the
Global Configuration of a Dispatcher
Procedure
1. Choose the Global Configuration tab.
2. After Saving the Properties changes, the Apply global changes to cluster elements dialog appears, which gives you the option of applying the changes to the localproperties of the selected cluster elements only.
3. Choose Yes to save the changes (If you deselect all the cluster elements or justchoose No , the changes made to the global properties will still be valid).
The properties of the services and managers are formed by posting their localproperties upon their global ones.
ADD without parameters list all available command groups
MAN without parameters list all available commands
Username and Password
The Console Administrator enables remote administration through Telnet clients. This function providesTelnet clients with a distributed, scalable Telnet server that supports remote shell administration using theTelnet protocol. Telnet administration function is implemented in SAP J2EE Engine using the TelnetProvider Service.
By default, the Telnet shell is opened on the dispatcher. Once you are connected you can access and useall shell commands available on the different J2EE Engine cluster elements. Use the LSC command todisplay all server components with their ID, component name, host, port, and type. The first componentdisplayed is the current one.
To pass over from one component to another, use the JUMP command and specify the ID of the targetelement. For example, executing jump 4001 enables the remote administration of a cluster element with ID
4001. You can obtain an overview of the available commands with the command MAN. MAN <command>
displays a short explanation of a command.
The commands are grouped into a number of groups that can be activated and deactivated. You canobtain an overview of the groups with the command ADD. To activate a group of commands, enter thecommand ADD <group>.
In the path SAP Library -> SAP NetWeaver -> Application Platform -> Java Technology in SAP Web Application Server -> Reference Manual -> SAP J2EE Engine Reference -> Shell Administration Commands of the NetWeaver’04 documentation you can find all the Shell Administrator commands.
Secure store file – contains the path to thesecure store properties file. This file containssecure data for connecting to the database orvisual administrator. It is encrypted for securityreasons.
Secure store key file – contains the path to thesecure store key file. The key file contains thepassword for the encrypted store file.
System name – displays the name of thesystem to which this data applies.
Secure store lib – contains the path to the IAIKpackage. It enables the encrypting of theproperties file.
RDBMS connections – contains a property keyof which the value contains the DB connectionsettings.
RDBMS driver location – contains the path tothe RDBMS driver.
RDBMS initial connections.
RDBMS maximum connections.
To start the tool use: usr/sap/<SID>/<InstanceName>/j2ee/configtool or<drive>:\usr\sap\<SID>\<InstanceName>\j2ee\configtool.bat
The database is initialized and the connection to it is configured for the first time at installation. Theinstallation procedure creates the tables in the database, copies all the necessary data to it, and sets theproper parameters for establishing a connection. You can configure a DB connection manually. If youwant to switch to another database, you must make sure that the database has been properly initializedand that all the data necessary to run the J2EE Engine is in the database.
It is strongly recommended that you use the automatic configuration
Manual procedure
1. If you want to change some of the default settings for connecting to the database, then choose File →
Connect
2. If secure storing fails, you can use the Overwrite RDBMS Settings option:
Enter the URL of the RDBMS
Enter the user name for connecting to the database
Conf ig Tool : Managers/Serv ic es Conf igurat ion
Add/Removeinstance nodes
Configureconnectionencryption andUME data
GlobalDispatcherand GlobalServersConfiguration
All instancesin the Web AS
Java System
Switch to Configuration Editor mode
Use the“Connect to DB” button to refreshthe information
The J2EE Engine Config Tool enables the modification of service or manager module properties in the DB.The current server configuration is scanned from the database to which you have connected anddisplayed in the main frame as a tree structure.
No start/stop of any service/manger or node can be done in the Config Tool
The root element of the tree is the J2EE Engine cluster. It contains:
A global dispatcher configuration and a global server configuration
Contain the global services and managers properties for each type of node. Changing these propertiesreflects to all cluster elements. The global properties include default and custom values. You cannotchange the default values, you can set a new custom value and it will has a lower priority than thelocal values (default or custom) for this property.
All instances listed
Each instance contains one Java dispatcher and a specific number of server processes. Each nodecontains a list of managers and services.
You can change them according to your needs. To delete the local values of a property, so the globalvalues are taken, use the SET TO GLOBAL button.
For more information on UME and LDAP configuration refer to the TADMJ8 course.
You can Add or delete Servernodes in an already created instance
To create new J2EE Engine instancesyou have to use the installation tool
SAPInst
Create/Remove Server node
1. Select the instance on which you want to create the new server process
2. Choose Server→ Add Server
Only one dispatcher is allowed per J2EE Instance, and only SAPInst can create newinstances, thus, the Config Tool doesn’t allow to create any dispatcher node.
This procedure enables you to configure instance properties such as Java settings (Java home, Heap Size, Java parameters, classpath),server process debug settings, message server settings, and bootstrap settings that refer to the instance itself and all server nodes containein it.
Dispatcher properties are managed only in the Dispatcher node.
The Java settings are read from DB by the Bootstrap processes. Because this process only runs when the Instance/node starts, theInstance/node need to be restarted in order to make affective any change in this area.
Instance tabs (see appendix for details)
Message Service & Bootstrap : View or edit the message server host and port, view or edit the Java settings of the Instance Bootstrap proce
Servers General : Startup Framework default settings and JVM default settings of every Server node created in this instance.
Servers Debug : Debugging default settings of every Server node created in this instance.
General : Startup Framework custom settings and Java custom settings of the nodeselected (same configuration options than the Servers General tab of the Instanceproperties).
Bootstrap : Java settings of the Bootstrap process of this node.
Log configuration : Logging and tracing configuration of this node (see TADMJ5 or thedocumentation path: SAP Library -> SAP NetWeaver -> Application Platform -> Java Technology in SAP Web Application Server -> Administration Manual -> Server
Administration -> Logging -> Log Configuration )
Debug : Debug Settings in the Servers nodes only. (same configuration options thanthe Servers Debug tab of the Instance properties) .
The Configuration Manager is related to all J2EE Engine modules. In addition, there are services thatstore extra information in the database. The container services (EJB Container Service, Web
Container Service, Connector Container Service, and so on) store the data for the applications that aredeployed on the server.
Configuring a Database Connection
The rdbms.maximum_connections property defines how many connections can be established to thedatabase at a time. These connections are used by the Configuration Manager to access theunderlying database. If you set a small number of connections such as one, some of the services willhave to wait for an idle database connection while accessing the Configuration Manager.
You have to change the properties shown on both the server and dispatcher elements to connect thecluster elements to the same database. Server and dispatcher nodes do not need the same number ofinitial and maximum connections, but they must access the same
When connecting to the database, the J2EE Engine as well as the applications deployed on itauthenticate themselves by means of a user name and a password. They are specified only once,when the DataSource that is used to provide the database connection is created. The DataSource isinitialized with the supplied credentials and uses them for the authentication of all physical connectionsthat it provides. The user name and password for the default DataSource are stored encrypted in asecure store. The parameters for this secure store are the following properties of the ConfigurationManager:
Configuration objects are persistent objects that hold information about the J2EE
Engine cluster elements, components and the applications deployed on them;configuration objects contain parameters as key-value pairs and files.
The configuration objects exist in the database in a tree structure. You can edit thestructure and its substructures as well as the configuration objects themselvesdirectly in the database using the means provided by the Configuration AdapterService.
The Service Manager communicates with the Configuration Manager toenable storage of configuration data about the services.
Can be started by:•Visual admin: Configuration Adapter Service of the Server nodes.•Config Tool: Switch to Configuration mode button.•UNIX script: /usr/sap/<SID>/JC<inst-nr>/j2ee/configtool
Edit the configuration objects directly in the database only in extreme cases.When you need to edit the configurations, always use the Runtime tab of ConfigurationAdapter Service in Visual Administrator.
Only J2EE Engine administrators have permission to edit the configurations.
Purpose
exploring the content of the Configuration Database (e.g. problem analysis in the case of suspectedmissing or corrupted configurations)
deleting/changing/updating configuration entries (to be used carefully)
The shell commands in the CONFIGURATION group enable you to view details aboutconfigurations and locks.
Conf igurat ion Edi tor : changing the c onf igurat ion
Double-click to edit
the Property Sheet
Right-click toedit theConfigurations
Configurations are cached in a distributed cache within the cluster.
Stores objects, files and property sheets
A property sheet is a flat set of properties and distinguishes between default and custom settings(if the custom flag is not flagged the value is default and vice versa).
The global properties are common for all dispatcher and server elements. The configurations of thisproperties are situated in the following configuration Propertysheets (this Propertysheets can be seenusing the Configuration Adapter Service):
1. Dispatcher elements:
a. for managers: cluster_data/dispatcher/cfg/kernel/<manager_name>
b. for services: cluster_data/dispatcher/cfg/services/<service_name>
2. Server elements:
a. for managers: cluster_data/server/cfg/kernel/<manager_name>
b. for services: cluster_data/server/cfg/services/<service_name>
DB Schema Data Filesystem ContentJ2EE AppDB Content
IDE
Database
J2EE Server
Filesystem
DB SchemaDeploy Tool
FilesystemContent Deploy
Tool
DB ContentDeploy Tool
J2EE EngineDeploy Tool
• Deployment is the process of
delivering a Java application to the
runtime environment of the J2EE
server
•During deployment the different
parts that compose the application
are stored in the correct runtime
repositories.
• The Deployment Descriptor file,contains the information needed by
the Deploy Tool to deploy the
application.
The word deploy has roots as a military term, used to describe the placement ofequipment and troops in a battlefield.
As a J2EE term, is the final step in the software delivery process; it’s used to describethe process (automatic or manual) of placing the files and other resources in the correctruntime repository (Database, File system, J2EE system) and assuring that all theinformation the J2EE Server needs to run the application is available.
The information the Deploy tool needs to deploy an application is contained in an XMLfile called Deployment Descriptor (DD)
The standard deployment API included in the J2EE specification is described inhttp://www.jcp.org/en/jsr/detail?id=88 (see the appendix for more information of theJ2EE standard deployment process).
Various deployment scenarios require different ways to perform the deployment tasks. Thefollowing means for deployment are provided:
Software Delivery Manager (SDM)It is especially suitable for:- Administrators/Developers when they want to deploy other people’s applications.- Administrators when deploying SPs for SAP Java applications (necessary for correct versioning).- Developers deploying software with the SAP NetWeaver Developer Studio in a local target.
Deploy Service (Visual Administrator)suitable for runtime administration:- deploying, updating, removing, starting, and stopping an application- updating a single file- getting Client Jar
- getting application information
Deployment Tools Overv iew
• The Deploy Tool is another solution suitable for generating, assembling anddeploying J2EE applications and application components.
• It was the only deployment tool on WAS 6.20 but on Web AS 6.40 The softwareDeployment Manager is recommended.
DB Schema Data Filesystem ContentJ2EE AppDB Content
IDE
Database
J2EE Server
Filesystem
DB SchemaDeploy Tool
FilesystemContent Deploy
Tool
DB ContentDeploy Tool
J2EE EngineDeploy Tool
IDE
Database
J2EE Server
Filesystem
DB Schema Data SDADB Schema Data
DB Content SDADB Content
J2EE App SDAJ2EE App
Filesystem Content SDAFilesystemContent
Software Deployment Manager
Deploym ent : SDM Overvie w
With SDM, the deploying of various content types is facilitated
The deployment user interface for all kinds of content and systems is unified
The Software Delivery Manager – SDM – unifies the deployment process for several ofdifferent content types by providing a unique deployment interface for all these typesand by using a standardized delivery/transport format.
SDM serves as a single access point for SAP tools like CMS, IDE, SAPINST whichneed to deploy content into different runtime systems.
The foundation for SDM is the (development) component model.
2 major file formats supported: SDA: Software Deployment Archive corresponds to the deployable
part of a Development Component
SCA: Software Component Archive corresponds to the deployableparts of a Software Component
Support Packages and products are concepts put on top of thecomponent model.
Software Deployment Archive (SDA): The Software Deployment Archive (SDA) is thedelivery format for SAP applications in programming languages other than ABAP. AnSDA is the smallest unit that you can deploy. Furthermore, the SDA is the smallest unitfor which patches can be created and delivered.
Software Component Archive (SCA): A Software Component Archive (SCA) is thephysical representation of a version of a software component. It contains a specificnumber of SDAs, whose quantity describes a precisely-defined version level. An SCAupdate always results in a new version level of the software component.
Refer to the course TADMJ8 “Java Development Infrastructure Administration ” or to theonline help: Architecture Manual -> SAP NetWeaver Java development Infrastructure -> Component Model for more information about the Component Model.
SDA It is an archive format that is compatible with ZIP and that can be used as acontainer for other archives.
An SDA contains at least the following files:
MANIFEST: File with meta information on the content of a Java archive (jar).
SAP MANIFEST: Manifest that also contains information on software logistic processing. Among otherthings, this includes the Descriptions of dependencies and the Internal SAP descriptions of versions.
SDA Deployment Descriptor: XML file that must contain all information required for the deployment.The development team responsible for the SDA is responsible for providing this file.
The EAR archive is a special case in the J2EE context. If an EAR archive contains anSAP manifest, it is also an SDA. The SDM recognizes the EAR archive as an SDA, butdoes not rename the archive extension as <archive_name>.sda.
Larger entities can be created in SCA format in the second step from the different SDAs.
SDM can also work in Auto install / update Mode , this means that the softwaredelivered with the SDMKit is able to do installations and updates of SDM.
In all operation modes SDM is able to handle only one access at a time
1. Stop the SDM Integrated Server 2. Switch startup mode: sdm jstartup "mode=standalone“
3. Start SDM Standalone Server: StartServer or sdm server
To include SDM of the Java Startup Framework:1. Stop the SDM Standalone Server: sdm shutdown 2. Switch startup mode: sdm jstartup "mode=integrated“
3. Start SDM Integrated Server
As standard, the Software Deployment Manager (SDM) is integrated into the JavaStartup framework of the SAP J2EE Engine, which means that it is started and stoppedautomatically with the Engine.
Situations can arise in which you need to start and stop the SDM independently of theSAP J2EE Engine. For example, for security reasons, you may want to run the SDMduring the current deployment only.
SDM Server can also run in an standalone mode with the help of the command lineinterface (sdm.bat for Windows or sdm.sh for UNIX).
Remember that, in standalone mode, the SDM is no longer started and stoppedautomatically with the SAP J2EE Engine. You can then only use the command line tocontrol the SDM (for more information, see the file SDM_Commandline_en_final.pdf inthe directory <sdm_home>/doc).
When deploying SDAs/SCAs, the Software Deployment Manager stores the data inthe SDM Repository, where it then manages the installed archives. The SDMrecognizes dependencies between archives and provides support when you installand maintain shared applications
A Target System represents a physical runtime system in conjunction with itsdeployment relevant configuration.
The following target systems are possible: File system, Database or SAP J2EEEngine.
The SDM Repository tab on the initial screen gives you an overview of the installedtarget systems and the archives they contain. When you expand the target systemsnode, you see the SCAs and SDAs that are assigned to the corresponding targetsystems.
Expanding and SCA you see all the SDAs contained in it.
The following tab pages appear in the right screen when you select a target system:
Each SDA is assigned a Software Type which is declared within the SDA-DD inside theSDA – the Software Type determines the kind of deployment which is executed for theSDA
The Configuration tab shows information about the current settings of the SDM server
The Substitution Variables tab shows the catalog of Deploy time Substitution Variablesthat SDM understands.
Deploy time Substitution Variables can be referenced by name inside the SDADeployment descriptor. To distinguish a parameter reference from a fixed string theDeploy time Substitution Variables has to be enclosed in a pair of start and stopdelimiters "${" and "}".
Substitution Variables can be used for file system and engine deployment.
The deployment of new software components is divided into several steps:
1. To select additional SCAs, or SDAs, choose Add SCA/SDA to Deployment List . Todelete superfluous SCAs or SDAs, choose Delete SCA/SDA from Deployment List .Choose Next .
2. The SDM determines the Deployment Action from the manifest data and displays thedata in the archive list. The Repository Preview shows how the SDAs are distributed inthe SDM Repository. Choose Next .
3. The SDM tells you that it is ready for deployment. Choose Start .
If an error occurs and you have to perform the deployment again, deployments that were successfullyperformed are not repeated.
4. A success message appears at the end of the deployment process. Choose Confirm toconfirm the deployment
You can always go back during the deployment steps
Update deployed SCAs/SDAs that have lower component versions than the selected SCAs/SDAs only With this option, you can deploy new archives only, or update existing archives with a newer version.
Update deployed SCAs/SDAs that have the same or lower component versions than the selected SCAs/SDAs With this option, you can redeploy existing archives. This overwrites the previous deployment.
Update deployed SDAs/SCAs that have any version With this option, you can deploy any archive, without its version being checked by the SDM.
Handling in case of deployment errors Stop when the first error occurs
With this setting, the deployment terminates as soon as it encounters an error. Any deployments that have already been completedare retained.
Skip deployment of SCA/SDAs depending on the erroneous deploymentWith this setting, any archives that cause deployment errors are skipped. The SDM still processes the list of archives until the end.
Settings for Updating SCAs/SDAs
Update deployed SCAs/SDAs that have lower component versions than the selected SCAs/SDAs only
With this option, you can deploy new archives only, or update existing archives with a newer version.
Update deployed SCAs/SDAs that have the same or lower component versions than the selected SCAs/SDAs
With this option, you can redeploy existing archives. This overwrites the previous deployment.
Update deployed SDAs/SCAs that have any version
With this option, you can deploy any archive, without its version being checked by the SDM.
Handling in case of deployment errors
Stop when the first error occurs
With this setting, the deployment terminates as soon as it encounters an error. Any deployments that have already beencompleted are retained.
Skip deployment of SCA/SDAs depending on the erroneous deployment
With this setting, any archives that cause deployment errors are skipped. The SDM still processes the list of archives untilthe end.
Some of the runtime administration operations you can perform include:
• Manage the deployment of applications
• Observe the status of the deployed applications
• Request information about the application components or
• Remove applications and to change the application status
Depending on your needs, you can specify different application startup modes for yourapplications.
As a response to your actions in the runtime management, the Deploy service performsdeployment operations. They change the application status of the targeted
applications.
Go to the documentation for more information of the Deploy Service (AdministrationManual -> Server Administration -> SAP J2EE Engine Administration -> DeployService)
Servers Debug : Debugging default settings of every Server node created in this instance.
Debuggable – specifies that the selected server process is debuggable (that is, the “debug mode” feature for this server process is enabled)
Enabled debug mode – specifies whether the server process is in debug mode
Restricted load balance – specifies whether the server process is part of the load balancing system.
Debug port – enables debugger clients connections. This port is opened by the virtual machine and must not be among the ports that the J2EE Engine uses. Bydefault, it is set to 33561
Separation of Tasks (Role Concept)Bean Bean developers develop Enterprise Beans that implement the business logic for a developer
specific specialist area as reusable SW components. Bean developers forward theircomponents as jar-archive files, which contain meta data in an XML file(deployment descriptor) in addition to the compiled classes and interfaces. Componentfeatures and their requirements of the (as yet unknown) runtime environment arecontained in a declarative format.
Application Application assemblers use the components provided for a specific application by assemblercombining several components as larger conglomerates. They have the option of adding
additional Java beans here. The overall archive created here is also known as aDeployment Unit or EJB Module.
Deployer Deployers are experts for a specific system environment and are familiar with the serverand container products used. They use deployment tools to integrate the deploymentunit in the server.
Container Container providers provide the specialist tools for the respective container and server.Provider
System The system administrator is responsible for the infrastructure required to operate theAdmin server, configures and binds the system services and resources required and uses tools
Enterprise Java Beans contain business logic orrepresent data from a database.
Separation of Business Logic and PlatformJ2EE defines strict encapsulation of business logic as components (Enterprise Java Beans,EJBs). These components are installed to be run on a specific platform (Web Container fora J2EE Server). EJBs communicate with the container for the application server viastandard interfaces and are therefore platform-independent.
Enterprise Java BeansEJBs are the smallest components within the EJB architecture. This means that they canonly be forwarded or exchanged as a total unit. An additional significant characteristic hereis the fact that bean developers can focus on implementing business logic. Runtime logic
(such as transaction control) has been implemented in the EJB Container. The beandeveloper uses the corresponding entries in the deployment descriptors to determinewhether they can use the runtime logic for the container. Bean developers can alsoimplement the runtime logic themselves.
Runtime logic such as transaction control or security checks is requestedvia entries in deployment descriptors.
Each archive contains a deployment descriptor (XML format).
J2EE Dep loyment 1 /4
WAR/JAR/EAR: Declarative Specification by Deployment DescriptorsA series of formats in which the compiled form of J2EE applications (class-files, JSP, HTMLfiles, pictures etc) are packed, have been defined for J2EE so that these can be installed onan application server for execution.EJB-JAR All (auxiliary) classes and interfaces for EJB are saved here with a standardizedXML deployment descriptor (ejb-jar.xml).
The deployment descriptor describes the EJBs and their contexts and features,such as the JNDI name, transaction features etc.WAR W(eb)AR(chive) files contain the "web section" of J2EE applications, such as
servlets, JSPs, HTML files, pictures etc. A corresponding Web Archive DeploymentDescriptor is also available here.EAR JAR and WAR files are bundled ("assembly") as a J2EE total application inJ2EE E(nterprise) AR(chive) files.
Deployment descriptors contain information on how components areinstalled on the respective application server (declarative specification).
Entries in the DD
are used togenerate
additional classes
J2EE Dep loyment 4 /4
DeploymentThis work step has not been standardized in the J2EE Specification. Each containerproduct has its own solution here.During deployment of an EJB Jar file, the following steps are usually executed by thecontainer:
The system checks whether components in the EJB Jar file adhere to the rules in the EJBspecification.
The container tool generates the EJB and home classes for the Enterprise Beans.Methods in the remote object correspond to methods in the Enterprise Bean.
However, methods in the remote object contain additional code that is added using entries in thedeployment descriptor. The remote object then acts as a proxy object.Line 2: The generated class provides the same method as the actual bean.Line 3: Implementation of the runtime logic takes place within the remote class. The
deployment tool inserts additional code here, e.g for transaction control etc.Line 5: Actual calls of the bean method take place here..
The container tool generates all stub and skeleton classes that are required to support RMI-IIOP.
1-6 Which Data Sources are configured in the JDBC Connector Service of your J2EE
Engine and how many free connections do they have left?
1-6.1 The only JDBC connector is in the server node (which is the only process that
connects to a DB)
1-6.2 On the left tree go to Server→ JDBC Connector
1-6.3 On the right panel choose Runtime tab→ Datasources
1-6.4 There is only one data source called SAP<SID>DB (the default datasource)
1-6.5 In the monitoring tab you can see 2 free connections of a maximum of 10
(20% available).
1-8 Check the Telnet Service port and change it to 50088 for DEV and 51088 forQAS with the Visual Administrator using the local properties of the node.
1-8-1 To find the correct Telnet Port of the dispatcher you can have a look to the
“System Info” page with the J2EE_Admin user:
http://<full qualified DNS name>:50000 for DEV
http://<full qualified DNS name>:51000 for QAS
1-8-2 Check the Service opening a Telnet connection to that port. Open a
command port and execute telnet localhost 50008 for DEV or telnet
localhost 51008 for QAS
1-8-3 Navigate to the Telnet Provider Service on the Dispatcher and the Server
nodes. Only the Dispatcher one is configured to listen on port 50008. The
Telnet service on the Server node is not been using
1-8-4 Select the property Port of the Telnet Provider Service on the Dispatcher
and edit its value to 50088 for DEV or 51088 for QAS.
1-8-5 Click on Update and then on Save Properties.
1-8-6 Restart the Telnet Service on the Dispatcher node
1-8-7 Refreshing the System info page should update the change.
The Dispatcher trace also logs the open telnet ports at:
The server processes of the J2EE Engine actually execute the J2EE application. Eachserver process is multi-threaded, and can therefore process a large number ofrequests simultaneously. Java Dispatcher assigns requests to the server processes.
The server process consists of the following components: Some of these are the sameas in the Dispatcher.
• Communication handler
• Session level services
• Application-level services or the actual application program
Java Dispatcher
The Java dispatcher receives the client request and forwards it to the server processwith the lowest capacity usage. If there is already a connection to the client, therequest goes to the server process that processes this client.
Managers simplify the administration of the Java Virtual Machine, using thread management or memorymanagement. The Managers don’t have runtime administration and administration require process restart.
Monitoring the Managers is done vie the Monitoring capabilities of the server.J2EE Engine Components
Built on top of the runtime and being able to communicate and use each other, these components form the completesystem infrastructure to run both J2EE and SAP proprietary applications.
Three types of J2EE Engine components are defined:
• Interfaces – you can think of them as “contracts” that define how different components of the system worktogether. Those components do not provide any runtime functions. At runtime, they provide the system with theirname and classes (no objects). They are used by services components that provide their implementation.Interface components can also be implemented directly by applications.
• Libraries – they provide name, classes and objects to the system. These objects are created by the system whenit loads the library, or when an object is first requested. Other library components or services components usuallyaccess them using static methods.
Services – they are more powerful than the previous two types of components. They provide the system with their
name, classes and runtime objects. The runtime objects are registered on the system once the componentsclasses have been loaded. Service components can access and utilize functions of the runtime through theFramework API. Some of the services support runtime administration and have runtime view in the Administrationconsole. Some services run only on the dispatcher or the server, some run on both procesess.
Applications
The applications form the third level of the J2EE Engine architecture. The boundary between the applications leveland the J2EE Engine components level is defined by the J2EE 1.3 APIs along with a few SAP proprietary APIs.Applications use them to utilize the functions of the different types of components on the lower level in thesystem.
The SAP Enterprise Portal for example is a J2EE Application.
A thread is a thread of execution in a program. The Java Virtual Machine allows anapplication to have multiple threads of execution running concurrently. Every thread has a
priority. Threads with higher priority are executed in preference to threads with lower priority.
The J2EE Engine thread system is responsible for handling system and client threads. It
comprises two managers – Thread Manager and Application Thread Manager. All threads in
which J2EE Engine system operations are executed (core, services, and so on) use system
threads supplied by the Thread Manager. Application Thread Manager supplies the threadsin which the client application’s code is executed. When an HTTP request reaches the J2EE
Engine, an application thread receives it.
The separation of the thread system into application and system thread pools enables the
J2EE Engine to sustain greater system load without disrupting its normal work.
Application Thread Manager - When a client request comes, the system tries to find a free
thread in the Application Thread Manager and to assign the execution of the request to this
thread. If no free thread is available, the thread system queues the request in a requestqueue.
Thread Manager - The logic is similar to the application logic – the system uses a queue for
system requests if a free thread is not available.
Monitoring the Thread System Managers is done through the Monitoring APIs of the Web ASServer.
3. Select cluster_data -> server/dispatcher -> cfg -> ext/interfaces/service -> <component_name>-provider.xml.In the dialog box that appears, modify the component references.
4. Choose OK to save changes. Then restart the corresponding cluster element.Note: this procedure is only available if you are administrator of the system.
Modifying Application References
The deployed applications have a set of default references to services, libraries and interfaces that areloaded each time the application is started. You can add, edit and remove these references at runtimethrough Telnet using the CHANGE_REF shell command.
Weak Reference - component A sets weak reference to component B if it needs to use classes of B.
Strong Reference - component A sets strong reference to component B if it needs to use classes andruntime objects that B provides.
Hard Reference - is equal to the “Strong Reference ” type, however, “Hard Reference ” is deprecated!
The Cluster Manager is responsible for handling the elements in the cluster. Itupdates the information about the status of each cluster element and the servicesrunning on it.
You can use the Cluster Manager to configure the properties of each element inthe cluster.
Specifies the type of the cluster element –server or dispatcher.
element.type
Specifies the name of the cluster element.element.name
Specifies the port on which the serverprocess listens for connections.
element.joinPort
Specifies the group ID of the element.element.groupId
Connections Manipulator 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.
The Connections Manipulation Manager runs in the following modes:
• Mode 1 - there are N number of client requests and N threads are waiting to read information from the
client connections. Each connection is processed by one thread until the value specified in theMaxSoTimeOutConnections property is reached.
• Mode 2 - the number of client connections is bigger than the number of the threads. In this case acommon time (t) for all threads is defined, which determines the milliseconds during which each thread
must wait for data in a particular client connection. After this time the thread moves to the next freeconnection (the connection in which there is no thread).
• Mode 3 - the thread spends more time taking the next free connection than the time it spent waiting inthe previous one. In such cases, the J2EE Engine starts working in a busy read mode. The time for
reading is switched off and waiting in the connection is substituted with a check whether there is datain the connection. If there is data, it is processed; if there is no data, the thread passes to the nextconnection.
The Connection Manipulator switches automatically between the working modes when the boundarymarks are reached. The mode can be monitored using the server monitoring capabilities.
Refer to the Web AS Documentation for more information.
The Connections Manipulator properties can be monitored through the monitoring service of the Web AS.
If the file specified as a value for the HostsFileName property is missing, the system creates defaulthosts.txt files in the ../dispatcher/cfg/kernel and ../server/cfg/kernel directories. The contents of the
generated files are: allow = *.*.*.*The content of the hosts file must be correct. Each line of this text file must have the following syntax:
A line beginning with the # sign is not interpreted. This denotes a comment line.
mode specifies if the host (or range of hosts) on this line is allowed or denied
hostIp represents one or more IP addresses
hostRange is a single number or a range of numbers. Range of numbers are two numbers divided with“–".
number is a positive integer number (0 – 255)
mask is a subnet mask. Bitewise and operation is calculated between the given IP (range of IPs) andthe mask.
port is a positive integer number. A range of ports can be specified using the “–" sign
protocoldefines the used protocol. Possible values are tcp, udp and * (both)
The name and allocation of the Hosts File is specified in the HostsFileName property. The file iscreated, or must exist, in the corresponding ../dispatcher or ../server directory.
The IpVerification Manager enables many resources to share the common configuration file for easiermanagement.
Basic Administration Service - Registers MBeans that can be used for managing a single cluster node or thewhole cluster.
Administration Adapter Service - These interfaces can be used to invoke operations on the MBeans. They alsoprovide methods for cluster administration and for viewing all registered MBeans.
JMX Adapter Service properties:
DefaultDomain – value for the MBeanServer default domain
MessageTimeout – timeout for synchronous requests sent to an MBeanServer on a remote cluster node (inmilliseconds)
[NotificationQueue] – Within the J2EE Engine JMX notifications are usually sent asynchronously. Thenotifications are queued and get processed by several worker-threads.
NotificationQueueMaxThreads – maximum number of worker-threads that process the notification queue
NotificationQueueEngTimeout – timeout for adding a new item to the notification queue (in milliseconds)
NotificationQueueThreadThreshold – number of notification queue items that cause the creation of a new worker-thread
[ObjectNameCompletion] – JMX ObjectNames have to meet certain conventions. There is a factory whichsupports the creation of ObjectNames that include the necessary location information. The factory uses a cacheto optimize the naming process.
ObjectNameCompletionCacheMinSize – initial cache size for ObjectName completion
ObjectNameCompletionCacheMaxSize – maximum cache size for ObjectName completion
Additional Administration Services which provide different types of administration:
Shell Administration Service – provides console administration using shell commands.
Telnet Provider Service – provides remote administration using the Telnet protocol. The administration is doneusing shell commands.
HTTP Provider Service implements Hypertext Transfer Protocol (HTTP) version 1.1 (specified by RFC
#2616).
HTTP Provider Service runs on both dispatcher and server nodes. That allows for using load balancingalgorithms and fast requests processing.
From a client’s point of view, HTTP Provider Service represents a server socket that listens for clientHTTP connections to the Java Engine.
HTTP is a request-response protocol. Based on that paradigm, HTTP Provider Service takes care ofparsing the URL of the incoming HTTP requests, dispatching them to the proper SAP WebAS Java
Engine’s module for processing, and returning the generated responses back to the client. It providesimportant features to secure a robust, high performance communication infrastructure for running high-volume business Web applications.
The heterogeneous load balancing is an important function when you run distributed applications in a
cluster environment. It gives the opportunity to run an application on a few cluster nodes, thisguaranties that the client request to that application is dispatched to the correct server where theapplication is available.
• Response Chunking – use the EnableChunkedResponse property - applies chunked transfer encoding(defined by HTTP 1.1 specification) to dynamically generated responses that are sent back to theclient. It is an important feature when transferring responses with large message bodies.
• Specifying Compilation Time of JavaServer Pages – use the CompileOnStartUp property - Configuresthe Web Container Service behavior concerning compiling JSP files of your web applications intoservlet implementation classes.
• Specifying Servlet Execution Destroy Timeout – use the DestroyTimeOut property
• Setting up the Compiler – use the Internal Compiler property or the External Compiler propertydepending on type of compiler you want to use
• Configuring the Header Preventing Dynamic Responses Compression – use theHeaderForNoCompression and HeaderForCompression properties
• Configuring the Name of the Multipart Body Request Attribute – use the MultipartBodyParameterName property
• Delaying User Authentication – use the DelayAuthentication property
• Providing Custom Response Messages When Requesting Stopped Applications – use theApplicationStoppedFile property
• Isolating Running Web Applications from Productive Client Requests – use theApplicationStoppedAliases property
Using Telnet you can list the HTTP sessions and the security policy domains in all running applications ofthe Web Container.
Strong reference - If the referenced service stops for some reason, the correspondent services stops aswell.
The Runtime screen of Web Container service provides information and means of administration of all
applications deployed on the J2EE Engine. It contains:
• Global Web Descriptor – defines initial settings, which are relevant to all web applications runningwithin the Web Container. It is XML based and its DTD is equivalent to that of the web.xml , and the
web-j2ee-engine.xml deployment descriptors of the web application.
• Deployed applications – each application is defined and configured using the web.xml and web-j2ee- engine.xml deployment descriptors. Those configuration settings have greater priority over the globalsettings of the global-web.xml .
Viewing Web Application Components via Runtime Screen
To view the Global Web Descriptor or to change the deployed web application settings, select the
component and choose “View”.
Displaying Servlets and Filters
When selecting a servlet or filter, the displayed screen contains the following information:
View and/or store in files information about all enterprise beans, their JAR files and applications
Change at runtime the properties of the deployed enterprise beans
Generate persistent.xml for the container-managed entity beans to be deployed
Create database tables for container-managed entity beans
Enable IIOP Support for EJB Applications - The EJB 2.0 specification defines a standardinteroperability protocol with which the applications deployed on different vendors’ application servers
can effectively communicate with each other. This protocol is based on CORBA/IIOP.During the typical application deployment procedure, the EJB Container generates only P4 support. Toenable the IIOP support, use the runtime tab of the EJB Container service, select the desired
application and choose the “Deploy IIOP Support” option.
By selecting an enterprise bean, you can modify some of its properties at runtime.For all types of Enterprise Beans you can change:
Description - description of the bean and its functions
Display Name - A short name for the bean. This name is displayed by tools.
JNDI Name - The name under which the bean must be registered in the JNDI and by which it can be looked up.
Container Size - The initial size of the EJB Container when the bean is loaded.
For Stateful Session Beans:
Session Timeout - The period (in seconds) since the session was last used, after which the EJB Container maydestroy it.
For Entity Beans:
Reentrance - Specifies whether the entity bean is reentrant or not.
For Message-Driven Beans:
Connection Factory Name - The name of the connection factory, which will be used by the EJB Container toobtain connections in order to register the bean as a message listener.
Destination Name - The name of the Topic or the Queue to which the bean wants to be subscribed.
Message Selector - The JMS message selector, which will be used to determine the messages that the bean willreceive.
Destination Type - The type of the destination – Topic or Queue.
Subscription Durability - Defines whether the JMS topic subscription is intended to be durable or nondurable.
Acknowledge Mode - Defines the message acknowledgment semantics that should be used for the onMessagemessage if the message-driven bean uses bean-managed transaction demarcation.
JNDI Registry Service provides a way by which names are
associated with objects, and objects are found based on theirnames. The service performs binding, rebinding, and unbinding
operations.
JNDI Registry Service basic concepts:
Operations are provided, through which can be associatenot only an object with a specified name, but also with
specified attributes.
Directory
concepts
Associating an object with a particular name as binding it
in the J2EE Engine naming system. Once the object isbound, it can be accessed through the lookup operationsand through the operations for working with names
Information collection – As long as the data is stored into an nonresistance storage, rebooting the J2EE
Engine ensures that all stored objects will be removed from the naming system.
Tree-like structure – The client gets an abstraction called “root context”, which is the starting point for allfollowing operations in the naming system.
Global objects – The global operations in all servers’ naming systems objects appear with the same nameand data. These (global) objects can be accessed from all over the cluster.
Non-serializable objects - The service provides an opportunity for non-serializable objects also to bebound in the naming system, but their data is kept on the client side and they are available only to the
client that has bound them.
Additional Features
Redirection – Each remote client is using the JNDI Registry service of one of the server processes inthe cluster through a context instance. This instance is connected to the naming system of this server
process and all naming operations are performed there. In case this server process goes down, thenext naming operation will be directed to another server process for procession.
Load balancing – The JNDI Registry service uses the P4 Provider service to make the connectionbetween the client side and one of the servers in the cluster. This server is chosen with the load
The JNDI Registry service provides a GUI which helps you to monitor the naming tree and to check the
bound objects at runtime. If you have bound an object to the naming system, you can check if this
object is bound successfully. You can also monitor the available naming system contexts. Theinformation displayed can be easily exported to a file.
To access the runtime GUI, open the Visual Administrator tool and choose Cluster -> Server -> JNDI
Registry Service -> Browser.
The bound objects and the available contexts are listed in a tree view:
The blue objects represent the available contexts
The red objects represent the bound objects. Each object is associated with a class name and anobject value. When the object is non-serializable, this is displayed in the [Object Value] sub-node (non-
serializable means that only server-side clients can look it up).
The Transactions and Resource Handling component is a system that manages the execution of the
transactions in the Java Engine, transaction propagation to other clients or application servers, as well
as the usage of resources in these transactions.
Integration
This component defines a uniform way for transaction usage and access to resources. It is used by thecontainer services (EJB Container, Web Container, Application Client) to provide access to resources
for the J2EE application components deployed in them.
Features
The functions of the Transactions and Resource Handling system are provided by the following J2EEEngine services:
• Transaction Service
• Connector Container Service
• JDBC Connector Service
• JMS Connector Service
The last three services are also part of the J2EE Connector Architecture implementation in the J2EE
The Transactions and Resource Handling component enables theexecution of local and distributed transactions and the usage of resourceswithin these transactions.
The Transactions and Resource Handling enables the Java Engine to: Work in a distributed environment to provide scalability and increased
performance.
Access other resource systems, such as databases, Java Message Service(JMS) providers, and Enterprise Information Systems (EIS).
Transactions and Resource Handling services:
Enables the use of JMS resources in both localand distributed transactions.
JMS Connector Service
Enables databases connectivity and providesfunctions for creating and managing DataSourceobjects.
JDBC Connector Service
Manages the overall connectivity to back-endresource systems.
Connector Container
Service
Manages all transactions on the SAP J2EEEngine server elements.
With the implementation of both JTA and JTS, Transaction Service offers a broad range of functionsregarding transaction execution on J2EE Engine. Among them are:
Support for distributed transactions – in a clustered environment distributed transactions are a basic
factor for the functioning of the business system
Support for local transactions – this enables local transaction optimization, which is defined in the
J2EE 1.3 Specification.
Support for the two-phase commit protocol (2PC) – Transaction Service uses it when completing
distributed transactions to ensure synchronization between them.
Using the functions that Transaction Service provides, you can:
Enable the enlisting of local resource in a propagated transaction – to do this, use the
EnableLocalResourceInOTS property
Manage the transaction timeout – to do this, use the TransactionTimeout property
The adapters are modules that are deployed on a J2EE compatible application server and provide unified
access to the resource system for any application components that are also installed on the server.
Implementation You can use the Connector Architecture implementation in the J2EE Engine to access any back-end
system from your application. For example, you can easily connect your entity enterprise bean to arelational database using a DataSource created with the JDBC Connector service, or your message-
driven bean to an external JMS provider using the JMS Connector service.
The Connector Architecture in the J2EE Engine enables:
easy and uniform connectivity to external resources using resource adapters or the interfaces that theconnector services provide.
the deployment of resource archives (RAR files) on the J2EE Engine. It also provides overallconnection management by registering all client requests for connections. The Connector Container
service offers support for connection pooling. You can use the functions this service provides todevelop and deploy a resource adapter following the requirements of the J2EE Connector Architecture1.0 standard.
The Connector Container service provides you the possibility to:
• view the configuration of the resource adapters that are deployed and started on the server
• modify the properties of a ManagedConnectionFactory - when a resource adapter is deployed, a
ManagedConnectionFactory (MCF) is configured with a set of specific properties (configurableproperties). You can change their values at runtime using the Connector Container service runtime.
Note: changing the property values may significantly alter the function of the resource adapter, whichmay also affect other applications that use it. Therefore, you must be careful when modifying the MCFproperties.
• modify the loader references - you can use the Connector Container service runtime to change the
reference to the class loader that loads a resource adapter. You can also add loader references toexternal resources that the adapter uses.
• clone the resource adapter - when deploying the resource adapter, you can only register a single MCFinstance. To configure another MCF derived from the same adapter, use the cloning function, available
in the Connector Container service runtime. With this function you create a MCF instance, which youbind in the JNDI registry by a different name and can configure with the appropriate settings for yourapplication. Thus, you do not need to re-deploy the whole resource adapter to create another MCF
configuration.
The resource adapters are deployed on the J2EE Engine similarly to the other J2EE components – enterprise beans, web components, and application clients.
• General – the properties set in the standard ra.xml, such as resource adapter display name,description, vendor name, specification version, EIS type and version. You can also see if a license isrequired for the adapter and if it has been deployed within an application or it is a standalone resource
adapter. The adapter is standalone, if the Is Real Application indicator is not selected.
• Resource Adapter – the connector group and the loader references. These properties are related tothe resource adapter classloading.
• Managed Connection Factory – the configuration of the ManagedConnectionFactory (MCF) thatprovides a ConnectionFactory, which the applications can lookup from the JNDI registry and use toobtain a connection to the EIS. The settings are related to the transaction support and the
authentication mechanism of the MCF, its specific properties, and the ConnectionFactory provided bythe MCF and registered in the JNDI registry.
• Security – you can check the authentication type of the resource adapter and the identity subjectsdefined for it.
• Drivers – you can check if any JDBC drivers have been registered with the resource adapter.
The JMS Connector Service provides connectivity to JavaMessage Service (JMS) systems. It enables the use of JMS
resources in both local and distributed transactions.
The JMS Connector service :
combines the functions defined in the J2EE Connector Architecture
and in the JMS standard as well.
presents the middle tier between the client and the JMS provider.
is implemented as a resource adapter.
As a part of the connector architecture in Java Engine, the JMS Connector Service is closely related to
the Connector Container Service . It processes the requests for connections, manages their allocation,
and handles the resources involved in the transactions.
The JMS Connector Service It enables the client to use the JMS administered objects in anenvironment that also provides transaction and resource handling logic. The JMS Connector Service is
therefore related to the JMS Provider Service in the J2EE Engine as well.
The RFC is an SAP interface protocol, which simplifies the programming of communication processes
between systems. The RFCs enable you to call and execute predefined functions in a remote system,
or in the same system.
The JCo RFC Provider Service processes RFC calls from the SAP systems. It dispatches the calls toa stateless session bean, which is registered in the J2EE Engine naming system. By naming
convention the JNDI name used is identical to the name of the SAP function module.
The JCo RFC Provider Service offers two types of connection – though a TCP/IP, and through ashared memory.
RFC Scenario:
1. On startup the JCo RFC Provider Service connects to the Web AS repository.
2. On startup the JCo RFC Provider Service registers itself at the Gateway with a defined name. It ispossible to register it under different names and at different Gateways.
3. The Web AS calls a function for the registered RFC destination.
4. The Gateway forwards the call to the JCo RFC Provider Service.
5. The JCo RFC Provider Service looks in the JNDI for the EJB, which is registered under the function
name.
6. The JCo RFC Provider Service calls the processFunction(JCO.Function) method of the EJB found.
7. The results of that call (the modified JCO.Function) are passed to the Gateway.
8. The Gateway passes the results back to the Web AS.
1. In the JCo RFC Provider use the RFC destination pane to specify the destinations parameters:
a. Choose the Program ID field and enter the program ID of the JCO server which is configured at the
gateway service.b. In the Gateway host field, specify the host of the gateway, through which the requests are passed.
c. In the Gateway service field, enter the gateway service that will receive requests for handling JCOfunctions.
d. Choose the Number of processes (1 to 20) field and specify the number of JCO Servers simultaneouslyrunning with the same Program ID.
2. Use the Repository pane to define the repository parameters:
a. In the Application server host field, specify the host of the SAP Web AS for the repository.
b. In the System number field, enter the system number for the client connection to the repository.
c. Choose the Client field to specify the client used to connect to the repository.
d. Choose the Language field and specify the language for the specific connection (for example – En ).e. Choose the User field and enter the user name for the client connection to the repository.
f. In the Password field, enter the user password for the client connection to the repository.
3. Select the Local bundle indicator, if you want the bundle to run only on the current cluster element.
4. Use the Unicode indicator, if you want to use a Unicode mode.
5. Add the destination as a bundle.
6. After the RFC destination is registered along with the defined repository, choose Set in the bottom of
The JMS Provider Service is the administration service of the Java Message Service (JMS), than the JMSConnector Service which is rather a resource adapter and provides connectivity to Java Message Service(JMS) systems.
The JMS Provider has the following configuration properties:
• agentThreadCount – The maximum number of threads that can work simultaneously to delivermessages to the destinations.
• cleanUpServiceSleepInterval – The time interval in milliseconds after which the Clean Up service iscalled.
• messageExpirationDelta – Removes all expired messages before (currentTime – messageExpirationDelta). The time interval is in milliseconds.
• clientMemorySize – The total amount of memory the client can distribute in the buffer.
• clientConsumerBuffer – The size of the buffer the client can use.
• countLimitInMasterQueue – The limit of the number of messages in the master queue.
• sizeLimitInMasterQueue – The total size of the messages in the master queue.
• fetchSizeOnStartupInMasterQueue – The number of messages that are loaded at startup of adestination.
• maxFetchSizeInMasterQueue – The maximum size of the loaded messages at startup of a destination.
• transactionStorePath – Defines the directory with enough free space where the transactions are to bewritten.
Note: Each working destination (the one with at least one producer/consumer) may take up tosizeLimitInMasterQueue bytes, which means that you should ensure that N * sizeLimitInMasterQueue(where N is the number of expected working destinations) does not exceed the virtual machine heapsize.
The class loader references can be viewed easily using the ClassLoader Viewer Service . This service graphically displays the relations betweendifferent loaders on a selected cluster element.
The ClassLoader Viewer provides a Runtime that enables you to browse easily between the
elements. You can view all registered class loaders and the full path to their resources. The loader’sresources are shown in a tree view on the left-hand side of the Runtime tab, together with their short
names. The class loaders are displayed in a tree view separated in several groups: Interfaces ,Libraries , Services , Applications , and Common (contains a list of common@ <x> sub-nodes, eachrepresenting a different reference cycle).
The references are visualized on the right-hand side of the Runtime tab in the sequence in which theyare loaded. This can be useful, for example, if you are tracing an application (if there are similar
classes in two different JAR files, you can see which one it is loaded from).
1. From the Components tree structure, choose Interfaces , Libraries , Services , Applications , or
Commons .The Application group is available only when there is a deployed application.
2. Choose the required loader from the list:
• A list of resources is displayed under the selected loader. Choose one of the resources.
A pop-up message appears with the full path to the resource.
• The right-hand pane displays the relations between the selected loader and other loaders. The selectedloader is always displayed in the middle of the screen.
The different types of relations are situated as follows: at the top is the parent loader, on the right side areloaders references, and on the left side are its referees. If you choose a reference or a referee, it becomesthe one to be monitored – it is moved to the middle of the screen and its references and referees aredisplayed as described above.
3. In the fields “Program ID”, “Gateway Host ” and “Gateway Service” enter the same data
as in the RFC destination created in ABAP
Note: For the field “Program ID” please specify the “Program ID” that you entered in
ABAP not the “ RFC Destination name”, they are completely different characteristics of
the ABAP destination.
4. For “ Number of Processes ” enter a number between 1 and 205. In the “ Application Server ” field specify the host of the SAP Web AS for the repository
(should be the same as the “Gateway Server ”)
6. Choose the Client field to specify the client used to connect to the repository.
7. Choose the Language field and specify the language for the specific connection (for
example – En).
8. Choose the User field and enter the user name for the client connection to the repository.
9. In the Password field, enter the user password for the client connection to the repository.
The SAP Web Java provides the complete infrastructure to run SAPNetWeaver components, and J2EE 1.3 compliant applications.
Availability is very critical, especially if no fallback options are
available.
Precautions have to be done to ensure that the Web AS Java can berecovered in case of e.g. Hardware Failure
File system corruption
Logical inconsistencies in the data
Software Damages cause from Viruses
Problems when installing Updates, Patches or new Software
A detailed backup and recovery concept is a must.
The recovery must be tested to show the success of the concept.
Note: The SAP Web Application Server (ABAP + java) is the technical platform for SAPNetWeaver, providing the complete infrastructure to develop, deploy and run all SAP
NetWeaver components, the mySAP Business Suite, customer-developed applicationsand 3rd-party J2EE 1.3 compliant applications.
Del ta : Server Data Storage Web AS Java 6 .20 – 6.40
J2EEEngine6.20
DB
Web AS 6.20 writes Application data
Application Software
Configuration Files
into various locations:
FS and DB
DB
BOOTSTRAP:File Systemsynchronizedwith DBcontent
Web AS 6.40 writes
Application data
Application Software
Configuration Files
into DB only!
[Applications on Web AS Java 6.20] [Applications on Web AS Java 6.40]
ApplicationsApplications
J2EEEngine6.40
Note:
The SDM repository stores its files during deployment on the file system intodirectory /usr/sap/<sid>/<instance>/SDM.
The SDM repository cannot be restored by using the bootstrapping mechanism.
The SDM only keeps 'old versions' of packages and versioning information. Otherthan during deployment, there is no activity on the SDM file system. Therefore it canbe backed up like a simple static file content.
The backup tools for your database must be installed and available.
The backup of the database can be executed during online operation.
Documentations for backup strategies of different databases in theonline-documentation:
MySQL MaxDB (SAP DB) refer to SAP NetWeaver→ Application Platform→ Databases→ MySQL MaxDB→ Basic Information→ DatabaseAdministration → Security Concepts→ Backup→ Backup Strategy.
Oracle database, refer to SAP NetWeaver→ Application Platform →
Databases→ SAP Database Guide: Oracle→ Approach to Oracle DBA →Database Backup.
SQL Server 2000 DBA, refer to SAP NetWeaver→ Application Platform →
Databases→ SAP/MS SQL Server 2000 DBA in CCMS → DatabaseBackup.
IBM DB2 Universal Database, refer to SAP NetWeaver→ ApplicationPlatform → Databases→ IBM DB2 Universal Database for iSeries → SAPDatabase Guidelines: IBM DB2 Universal Database for iSeries → Backupand Recovery..
One key element of the security concept for your database system is the making of
regular backups of your data.
Note - Oracle DB:
In case you run an Oracle database and want to use the SAP BR Tools for yourbackup procedure, refer to SAP Note 320457.
Perform Backup of the necessary directories and databases.
Motivation:Making a quick Snapshot and write that to a tape while the Applicationserver runs again
Offline Backup
„Quick“ Offline Backup
Procedure:
Shut down all services on each application server
Copy all files quickly to a fast storage device e. g. special hard disks (offlinefile copy)
Start up the applications immediately after the files are copied.
Perform a real (slow) backup to tapes from the temporary Directories
Alternative: Use Hardware which can do Snapshots of the hard disks
Effect: Downtime is minimized and backup is consistent
Normally an offline Backup is done when there is no processes that can change the files.The easiest solution is to shutdown all servers and if necessary the dependant
components. After that the files are copied to the tapes. The only disadvantage is a longtime that required for such a procedure.
A workaround can be implemented by using a “Quick” offline Backup. The idea is to use aspecial hardware that allows to perform a quick snapshot of the necessary directories orcomplete hard disks (several seconds or a minute). After this snapshot the Applicationserver can be started again and the files are moved to the tapes via standard (slow)backup tools. In this case the downtime required for offline Backup is equal to the time ofserver restart but the backup is consistent.
To restore your J2EE Engine after breakdown follow the steps described below:
Install a new system using the installation wizard SAPinst as described in the installation manual.
The installation guide for SAP Web Application Server Java can be found on the SAP Service Marketplace:http://service.sap.com/instguides Choose SAP NetWeaver → Release 04 → Installation → SAP Web AS Java 6.40 on <Platform>: <Database>
Use exactly the same parameters as in the previous installation you want to restore!
Overwrite the mentioned parts of the system by the backup-copies as described below
Java Instances
Overwrite the installed Java Instance (standard path: /usr/sap/<SID>/JC<inst-nr>)
Databases
Import the backup using the database specific management tools (e.g. SAPDB: Database Manager, Oracle:brrestore).
After the database has been imported, you also have to import the available log backups.
You find detailed documentation for SAPDB under SAP help ->The SAPDB Database System → Security Concepts → Restartability .
SDM
Overwrite the installed SDM.
Applications
Follow the description in the corresponding Solution Management Guides to recover your SAP applications. You findthese guides on the SAP Service Marketplace.
Load Balancing Between many SAP Web AS Instances (1)
You can also start a system with many J2EE dispatchers, for which the SAP WebDispatcher or another load balancer is already activated as a Web switch. Moreinformation about this Load Balancing can be found in the documentation of the SAPWEB Dispatcher.
Load Balancing by J2EE Dispatcher (2)
In the J2EE Instance the J2EE Dispatcher distributes the incoming requests amongthe Server Processes it is connected to. When the first request arrives at thedispatcher for distribution, the dispatcher executes the load balancing function. Thenthe dispatcher can guarantee that subsequent requests will be distributed to theserver process that is processing this session.
The graphic above shows a system with several J2EE dispatchers, to which the SAP Web Dispatcher
is the entry point in the DMZ. This executes the load balancing between the J2EE dispatchers, which
then distribute the requests to their server processes.
Instead of the SAP Web Dispatcher you can use any other load balancing device. You have to registerit on the server and ports. The communication with the message server and the mapping to the SAP
logon group are then no longer required.
The SAP Web Dispatcher fetches the information it needs from the Message Server:
All J2EE dispatchers with their HTTP ports to which the SAP Web Dispatcher can forward requests.
The capacities of the connected J2EE engines, so that the SAP Web Dispatcher can use the weighted round-robin procedure.
For this the SAP Web Dispatcher simply needs, in its profile file, the port where it can reach the Message Server (parameterms/http_port). See also Example: Profile File of a SAP Web Dispatcher.
The SAP Web Dispatcher is delivered with Central Services (Enqueue Service and Message Service).In the standard installation you will find this in the directory /usr/sap/<SID>/SYS/exe/run
The SAP Web Dispatcher can be used for load balancing in the following scenarios:
J2EE-only scenario, as described here. As all requests are forwarded to J2EE, all the distribution procedures using the URL prefixesin the SAP Web Dispatcher documentation are not relevant.
The SAP J2EE Engine Load Balancing System implements the following functions:
Load balancing of system (cluster) resources using the “Round Robin” algorithm.
Monitoring each server process for a particular service that can process the incoming request.
The Load Balancing system includes only the server cluster elements that are not stopped or marked forshutdown:
When a server element is shut down, it is excluded from the Load Balancing system. When a new element is started, it is included inthe system.
When there is a server process marked for shutdown, it is excluded from the Load Balancing System. The mark for shutdown option isused if you want to stop a particular server process without terminating the work of the clients that are currently connected to it. TheSAP J2EE Engine waits for the current requests to be processed and then stops the corresponding element. After the element isstopped the Load Balancing System stops sending requests to it.
Load Balancing is only used by distributed Services. These are Services where one part of the serviceis running on the J2EE dispatcher and a other part of theses Service is running on a J2EE Server
The description of HTTP Requests load balancing can be found on one of the next slides.
The load balancing mechanism for RMI-P4 and RMI-IIOP requests is based entirely on the functions of
the Load Balancing System. Load balancing for this type of requests is performed on the J2EEdispatcher when remote clients attempt to obtain initial context references to the remote server-side
object. After obtaining the initial context, the ID of the server process on which the remote objectresides is encoded into the request, so that consequent requests to the same object are dispatched to
prerequisites of homogeneous Load Balancing:All applications must run on each server process (default by deploying)
If on one server the application should not run, then you have to consider using the heterogeneousLoad Balancing
When the HTTP Provider Service is not configured for heterogeneous load balancing, it relies entirelyon the Load Balancing System to determine the appropriate server process to dispatch the request to.When an HTTP request reaches the J2EE Dispatcher, the Load Balancing System chooses a serverprocess from the cluster elements that have an HTTP Provider Service running on them. The state ofthe HTTP Provider Service is monitored by the Load Balancing System to prevent it from choosing aserver with a stopped HTTP Provider Service for processing the request
Heterogeneous Load Balancing
The HTTP Provider Service running on the dispatcher parses client requests. Based on its records (as
described above), it directs the request to the appropriate cluster element to be processed. Threescenarios are possible:
The incoming request has an application cookie attached. The HTTP Provider Service gets the value of the cookieand directs the request to the server with the corresponding ID.
The incoming request has no application cookie attached. The HTTP Provider Service checks its records for runningapplications with the application alias that matches the alias used in the request URL. If a single record is found, therequest is directed to the server process where the application is running. If more then one record is found, theserver process that will process the request is chosen randomly.
The incoming request has no application cookie attached and the HTTP Provider Service finds no records that matchthe requested application alias. Then the request is directed to the least busy server process in the cluster.
The graphic above shows the cluster elements and the communication between them. The single
points of failure are shown at the bottom.
A J2EE cluster has the following single points of failure (SPOF):
Database
Enqueue Service
Message Service
The other cluster elements (dispatcher and server processes) represent no SPOFs in the sense that abreakdown in one of them would not affect the entire system.
The dispatcher is stateless, this means that running transactions are not hindered. It can be restarted, orfrom the outset, two dispatchers can be started.
If a server process fails, the session is terminated. One way of getting round this problem is to make the
session persistent.
There are ways for providing session persistent Applications, but these opportunities have toconsidered during application design.
With J2EE Engine 6.20 there were no Central Services, and each cluster element communicated withall other cluster elements. With a large number of cluster elements, system performance was
significantly lower, which is why SAP has changed the architecture for 6.30.
You can see that the server processes do not communicate with each other. The advantage of thiscommunication schema is that the number of connections only increases linearly with the number ofserver processes and not quadratically as in the earlier procedure.
With SAP Web AS, SAP continues to provide its own technology for web load
balancing, the Web dispatcher. Similarly to web switches, it enables load distributionof requests to multiple Web ASs. Configuration and load distribution are based oninformation that the Web dispatcher regularly receives from the message server. Incontrast to message-server based load balancing (redirect), this setup has theadvantage that only one address and one host name have to be known externally, forwhich bookmarks can be used. Also, separate, official IP addresses and servercertificates do not have to be provided for each server. In the event of SAP Web ASfailure, rerouting to an available web server occurs automatically.
The SAP J2EE Engine provides a high degree of fault tolerance for the J2EE Web applications that aredeployed on it, by implementing an effective mechanism for replicating sessions. At the end of each
request-response cycle, the HTTP session is replicated to a persistent storage. If the system crashes,the storage is used to retrieve all lost session states. Replication is done using standard Javaserialization techniques, which is the only possible way of doing it within a Java Virtual Machine. Thistechnique has certain tradeoffs – performance on the one hand, and restrictions to the application onthe other.
Programming Requirements for HTTP Sessions Persistency
Store only serializable objects in the session. Exceptions to this rule are the following objects:
References to enterprise beans interfaces.
Reference to javax.ejb.SessionContext.
References to naming contexts.
Reference to javax.transaction.UserTransaction.
Do not store database or network connections – they cannot be serialized. If you are using JDBCconnections, they must be closed and set to null, so that session is serialized. You can use thesessionWillPassivate method of the HttpSessionActivationListener interface to receive events when thesession is about to be switched in passive state.
Enterprise JavaBeans serialization is done by the EJB Container. Enterprise beans are serialized bythe EJB Container when they are involved in an HTTP session that is serialized. There are alsoProgramming requirements that have to be kept.
Do not store large objects into the session because the application overhead becomes significant.
The SAP J2EE Engine provides failover services for RMI-P4 applications that run on it. These services
refer to the mechanism of migrating remote objects from the crashed server process to an available
server process in the cluster.
RMI-P4 provides a transparent failover for clustered remote objects (all actions are performed on theserver side and the client is not aware of any of them). It implements a mechanism for migrating
instances of those objects to other available server processes within the SAP J2EE Engine cluster incase a server process crashes.
This mechanism does not deal with preserving any state of the remote object after migration, thisremains the developer’s responsibility.
The process of migration of the remote object between cluster elements is depicted in the diagramabove:
In order to call methods on a remote object, a client must obtain a reference to that object. Thereference to the object contains information about the identifier that is associated to the remote
object by the naming system. If a server process crashes, the remote object is no longeravailable. Therefore, when the J2EE dispatcher receives a request from the client to thatserver process, it uses the load balancing mechanism to direct the request to another server
process. In this case, there is no instance of the remote object there. The P4 broker object onthe new server process gets the identifier of the remote object from the request and contacts
the cross system. The latter looks up the remote object and provides the P4 broker withaccess to the class loader of the remote object. This way, an instance of the remote object is
created on the new server process, and client-server communication continues as usual.
After completing this lesson, you will be able to:
Understand the SAP Web infrastructure.
Understand the role it plays for the robustness,performance and cost of ownership of a businesssolution.
You will learn some solution approaches forbuilding a business-ready Web Infrastructure forWeb AS.
Web inf rast ruc tu re for the SAP Web AS: Lesson Object ives
First, we will explain briefly how the SAP Web AS works and what we mean by Webinfrastructure (or HTTP infrastructure) in the first place. (In short, everything needed toget HTTP requests from the browser or any other Web client to the server and theresponse back).
It is important to realize that the infrastructure plays a crucial role for the robustness,performance and cost of ownership of a business solution. We will talk about how therequirements that business Web applications impose upon the infrastructure differ fromthose of other Web applications.
In the second half of the lesson we will outline some solution approaches for building abusiness-ready Web infrastructure for Web AS. One way of building a Web infrastructurefor SAP Web AS is based on components that SAP delivers as part of its technologyoffering (most notably, a software called Web Dispatcher). The other way is to use
standard, third party Web infrastructure components, which is just as well since SAPWeb AS is based on HTTP as a standard protocol.
SAP's modern Web applications are based on SAP Web Application Server (Web AS). Hereis a high level picture of its architecture. It supports both ABAP as well as J2EE based
applications. A specail process, the ICM, is responsible for HTTP communication.
Web AS is like any old SAP Application server except that it can serve HTTP requests.
SAP Web AS 6.40 has an integrated Java Server, which implements the Java 2 EnterpriseEdition (J2EE) standard. Technical infrastructure (as discussed I this presentation) is notaffected
There is also a J2EE-only version of Web AS, which consists of only the green part of thegraphic above.
The remainder of the lesson will focus on using SAP Web AS as an HTTP server.
What has to be done in order to offer a business web application in a productive way, e.g. inthe Internet? Seems like a trivial question: You find yourself an Internet provider, by a routerand then you are online. However, living and surviving in the Internet is little morecomplicated than that. Especially with a business critical application...
What you need is what we call a Web infrastructure. What we mean by this term iseverything that is needed to get HTTP requests from the browser or any other Web client tothe server and the response back. Some components involved in this are networks androuters, wide area network connections, load balancing devices, caches, DNS servers andmany more.
Session state persistent between requests ("roll area")
HTTP is a stateless protocol
Successive requests may open a new network connection
SAP Web AS uses session ID to recognize user session
Session cookie
Part of the request URL ("URL rewriting")
Stateful applications impose special requirements on load balancing.
HTTP is a stateless protocol, because the network connection does not last for the durationof a user session. The protocol itself offers no provisions to return a subsequent request toan already established session.
he Web AS uses a session ID which is returned with every request in order to recognize theuser session in which each request has to be processed.
SSL encrypts entire communication between browser and server
Server authentication (mandatory)
Browser verifies, that server certificate matches URL
Client authentication with X.509 certificates (optional)
Server takes identity of user from browser certificate
End point of SSL session is either Application Server (end-to-end security)
Web infrastructure component (in-depth security)
Encrypted traffic cannot be looked at or even modified by the load balancing device.
Way out: Load balancer acts as the end point of SSL encryption. This enables bettersession persistence mechanisms and also inspection of requests before they reach theapplication server. This is sometimes called "in-depth security".
A different security philosophy is "end-to-end security". It assumes that the server itself issecure and the connection between client and server is the most vulnerable asset. Thisphilosophy prohibits the termination of SSL sessions by any intermediary.
Therefore, end-to-end security does not go together well with load balancing, as it does notallow the use of session ID or cookies for session persistence. IP based persistence is notrecommended in the Internet.
Other App l ica t ion Spec i f ic Requ i rements (Exam ples)
All servers belonging to one portal "domain" should be in one
DNS domain, and only them.
DNS domain restrictions for Single Sign-on (SSO) cookie
(workaround available)
Security considerations for SSO cookie
Cross-frame JavaScript (Portal)
SSL should be re-encrypted if terminated in load balancer.
Some applications react on the incoming protocol.
HTTP header "Host:" should be preserved.
Beware of Apache 1.3. Use 2.0 with ProxyPreserveHost directive.
Random list of some special requirements of some SAP applications. Not meant to becomplete. This is just to make you aware that there are more things to care about. These
requirements do not apply to all applications. We are currently working on a comprehensivelist of requirements.
The SAP Web dispatcher is located between the Web client (browser) and your SAPsystem that is running the Web application.
The architecture is the same as the Internet Communication Manager, see the InternetCommunication Manager (ICM). It uses the same HTTP framework and is likewisestructured modularly from subhandlers. But unlike the ICM, the SAP Web Dispatcher doesnot directly pass incoming requests to a work process – it passes them to the ICM of theapplication server or to a dispatcher of a SAP J2EE Engine. The response from theapplication server does not pass via the Web dispatcher again to the client – it goes direct tothe client (via a proxy, if the network is configured with one).
I m plem e nt a t i on A re a o f t h e SA P We b Di sp at c h e r
The SAP Web Dispatcher was first delivered with SAP Web AS 6.20 (although it can also beused with SAP Web AS 6.10 systems). Its configuration and operation are simple.
The customer receives here a product that is designed for a throughput up to around 3000hits per second (HTTP). The SAP Web Dispatcher handles SAP-specific load distributionand is sufficient for the vast majority of cases. In cases of extremely high throughput, acustomer can, of course, purchase hardwareWeb switches from third-party vendors.
This often offer additional features such as hardware SSL acceleration.
The SAP Web Dispatcher is a small program (closely related to the ICM) without need of anadditional server with a database in the DMZ are therefore entirely
SAP Web Dispatc her : Server Selec t ion & Load Balanc ing
The SAP Web dispatcher ultimately forwards an HTTP(S) request to a specific application server.
1. The SAP Web dispatcher first uses a cookie to identify whether the request concerns a stateful application. If this isthe case, the request is sent to the application server that is processing this session.
2. Otherwise, the SAP Web dispatcher must determine whether this is a request for the ICF (“abap”) or the J2EE Engine(“j2ee”).
3. In the case of a J2EE request, the request is sent to the (internally defined) !J2EE server group, which contains allapplication servers with SAP J2EE Engines. If the request is an ABAP request, the !DIAG group is selected. Thisgroup consists of all application servers with dialog work processes. A logon group is only used if this logon group(maintained in transaction SMLG) is explicitly specified in the ICF service.
Thee SAP Web dispatcher distributes the requests in turn within the selected server group, weighted according to thecapacity of the individual servers. The capacity is calculated in the case of an ABAP request from the number of dialogwork processes and, in the case of a J2EE request, from the number of server processes. The SAP Web dispatchercollects the information about the server groups from the message server. The HTTP interface of the message serverallow you to display the information with a Web browser.
The internal structure of the SAP Web dispatcher is based on the ICM process. A profile file is also used in this caseto determine the settings with which the SAP Web dispatcher is started. You can easily copy and use the executablefile (sapwebdisp.exe) that SAP makes available for all supported operating systems to a separate host, together withthe profile.
The SAP Web dispatcher essentially only needs to know the port at which it should receive HTTP(S) requests(parameter icm/server_port_<x> ) and on which host (rdisp/mshost ) and with which HTTP port (ms/http_port ) it canaccess the message server.
You start the SAP Web dispatcher with the operating system command sapwebdisp pf=<profile file>, where you canset additional options such as trace file and trace level (see the online documentation). You stop the SAP Webdispatcher using a kill command at operating system level.
Detection of application type (ABAP / J2EE), select correct server Request parsing and URL Filtering
System can be reached using different names
SSL re-encryption is possible
Contra
Harder to configure
Web Dispatcher becomes "trusted component"
Make sure Web Dispatcher does not become performance bottleneck
SSL re-encryption does not triple the CPU load for SSL processing. Reason: The most expensive operation in SSLprocessing is the key exchange during handshake. Afterwards, the bulk encryption/decryption is not so expensive. Keyscan be re-used in subsequent SSL sessions, but only between the same communication partners. Therefore, Web
Dispatcher and backend application server have to do the expensive handshake only once (every couple of hours) andonly have the load of bulk encryption in the mean time.
Since there are usually many browsers accessing the system at once, Web Dispatcher has to do the handshake withthem much more frequently, typically once per logon.
To evaluate how many users the SAP Web dispatcher can serve, you must take the following factors into account:
When a user sends a request, this request can open more than one HTTP connection. Depending on theapplication a request can open between one and 10 or 20 HTTP connections. The user cannot see how manyconnections the request opens.
The “think time” is also crucial to the capacity of the Web dispatcher. The think time is the time between two userdialog steps (clicks). During this time there is no active HTTP connection (depending on the timeout).
Another important parameter is the keepalive timeout (icm/server_port_<xx> or icm/keep_alive_timeout), which
specifies how long the Web dispatcher keeps the connection open for further inquiries from the request.
For more information see the online documentation SAP Web dispatcher -> Management of theSAP Library -> SAPNetWeaver-> SAP NetWeaver Configuration -> SAP Web Application Server-> Management of SAP Web Dispatcher ->
The SAP Web Dispatcher Profile Parameters -> Configuration for Large Number of Users. And note number 715400.
Web Dispatcher on central instance server for fail over
High AvailabilityCluster
Like traditional HA for SAP systems
CI must be reachable by clients at all times under same address (IP takeover)SSL termination imposes high load, this may not be desirable on central instance.
A separate fail over cluster for Web dispatcher is the high end solution.
Another solution is shown later in the presentation: Using a network load balancer todistribute requests between multiple Web Dispatcher hosts. The load balancer also ensuresthe high availability by health checks of the Web Dispatcher nodes.
Multiple Web Dispatchers on different (virtual) IP addresses
Recommended
https://web1
SAP WebDispatcher
Corporate
Network
SAP Web
AS
SAP Web
DispatcherCorporate
Network
SAP WebAS
443
443
IP1
IP2
https://web2
Need one Web Dispatcher for every system.
Need separate certificates, because server names differ.Really need separate IP addresses for SSL, because Host header cannot be used withSSL. For clear text HTTP you can do with one IP address and DNS aliases.
Cookies do not distinguish between servers on the same host but on different ports.
J2EE engine sets session cookie to path "/", therefore the cookies will overwrite each other.Perhaps there is a way to configure this.
Another reason holds for systems in the Internet: Internet proxies often block outgoing SSLtraffic to ports other than 443. For example, SAP's proxy does this.
Too bad, because we could use the same server certificate for both systems.
Reverse proxy (optionally with authentication etc.)
Standard Web server integrates SAP Web AS services
Pro
Additional features
Re-use existing infrastructure
Unified Web infrastructure for all Web systems (SAP and non-SAP)
Contra
Cost
Less integrated with SAP Web AS
Configuration, operation, maintenance requires special expertise
In customers networks you usually find already existing infrastructure were the SAP WebAS can be integrated.
These infrastructures are building up by alternative technologies to the SAP InfrastructureTechnologies like the SAP Web Dispatcher.
The main advantages of reusing the existing technologies are generally associated withthe homogenization of these Web technologies across the enterprise.
The main disadvantages reside in the lack of integration with SAP NetWeaver scenarios interms of resource optimization and configuration knowledge.
Why? Re-use existing Web switch infrastructure, but no need for complicated configuration,because Web Dispatcher handles all the intricacies of the Web AS server selection and load
balancing between several SAP Web AS.
SSL termination on Web switch OK, re-encryption by Web Dispatcher possible
SSL session ID stickiness necessary, otherwise excessive SSL handshakes.
Use load balancing with fail over capability if present.
Second firewall could also be between Web switches and Web Dispatchers, in other words,the Web Dispatchers could also be located in server network.
Could install Web dispatchers on application servers.
Apache can handle this out-of-the-box with mod_proxy.
Web switches often have this possibility, too.IIS does not have reverse proxy functionality. You can use SAP's J2EE plug-in for Web ASJ2EE-only. Does it work for BSP applications???
BSP applications have a specialty: When you start /sap/bsp/app/start.html, BSP frameworkwill redirect you to /sap(QBSCXKJQB=)/bsp/app/start.html (with some variable charactersinside the parentheses, that constitute language, theme and possibly the session ID). TheWeb server must be prepared to handle this.
For load balancing, you can use the Web server, but watch out for complicatedrequirements of SAP Web AS session persistence. Or you use an additional WebDispatcher, either on the Web server host, or in the server network.
General problems with cookie overwriting (see description on slide "Web Dispatcher ForMultiple SAP Web AS" above)
Additional requirements:
In the second Web AS configure the application you are using to run on /shop using ICF. InJ2EE-only servers, make sure the application URL prefix does not conflict with first server.
Do not alter the URL path component in the Web server, for example, map all incomingrequests /C11/sap/bsp/app/start.html to /sap/bsp/app/start.html. This will break, becauseWeb AS uses path-absolute URLs to access some resources. There is no way to configureit to prepend the "/C11" to the absolute paths it generates.
Therefore, all applications must have separate paths configured in the server itself.
Consider also the MIME repository paths!
Some applications do not allow configuring their paths, most notably, J2EE application likeenterprise portal, for example. In this case it is not possible to run two such applicationsover the same Web server.
Course: TADMJ1 – SAP Java EngineAdministration - Exercises
Unit 5: SAP Web InfrastructureLesson 2: Installing the SAP WebDispatcher
Topic: Installing the SAP Web Dispatcherand configuring as a Windows service
At the conclusion of this exercise, you will be able to:
• Install the SAP Web Dispatcher• Set up the SAP Web Dispatcher to run as a Windows
service
The SAP Web Dispatcher is recommended as a software loadbalancing mechanism when you use an SAP system with severalSAP Web Application Servers for web applications. This lessondescribes how to install the SAP Web Dispatcher.
Lesson Overview
This lesson describes how to install the SAP Web Dispatcher and set it up to run as aservice on Windows.
Lesson ObjectivesAfter completing this lesson, you will be able to:
• Install the SAP Web Dispatcher
• Set up the SAP Web Dispatcher to run as a Windows service
Once web applications are up and running, more SAP Web Application Servers may beadded to the landscape to help process the load. To balance the web application loadacross several SAP Web Application Servers, SAP offers the SAP Web Dispatcher as asoftware load balancing mechanism.
Business Example
ABC Limited, a petrochemical company, installed the latest version of SAP system, SAPWeb Application Server. They now have several web applications running and haveadded dialog instances to help handle the load. As system administrator, you would liketo balance the load on these systems by installing the SAP Web Dispatcher.
Lesson ContentsTopic: Installing the SAP Web Dispatcher and configuring as a Windows service.Solution: Installing the SAP Web Dispatcher and configuring as a Windows service.
Topic: Installing the SAP Web Dispatcher and configuring as aWindows service
Steps to Install the SAP Web Dispatcher
The SAP Web dispatcher lies between the Internet and your SAP System. It is the entrypoint for HTTP(s) requests into your system, which consists of one or more Webapplication servers. As a "software web switch", the SAP Web dispatcher can reject oraccept connections. When it accepts a connection, it balances the load to ensure aneven distribution across the servers.
You can use the SAP Web dispatcher in ABAP/Java systems and in pure Java systems,as well as in pure ABAP systems.
• It is also beneficial to use the SAP Web dispatcher, if you do not needsecurity functions (entry point in the DMZ, SSL, URL filtering), but you simplywant to balance the load between several SAP Web AS instances.
The SAP Web dispatcher is a program that you can run on the machine that isconnected directly to the Internet. It requires minimal configuration - you just have toenter the following data in the profile file:
• Port, on which the HTTP(s) requests are to be received (parameter
icm/server_port_<xx>)• Host and HTTP port of the SAP message server (parameter rdisp/mshost
and parameter ms/http_port)
If you want to be able to call the Web application externally, for example using the URL www.shop.acme.com, this host name must be mapped internally to the SAP Web
dispatcher. This then forwards the HTTP(S) request to a suitable SAP Web AS.
Prerequisites for operating:
• There is a profile for the SAP Web Dispatcher.
• The HTTP port for the SAP message server is configured in the profileparameter of the SAP Web Dispatcher (profile parameter ms/http_port)
• The SAP Web Dispatcher must be able to contact the HTTP port of the SAPmessage server.
• The following services are activated in the HTTP services tree (TransactionSICF):
Figure 1: Web Dispatcher Prerequisites and Profile
See the online help for information on the SAP Web Dispatcher profile and profileparameters.
Importing the SAP Web Dispatcher
If you do not have the executable sapwebdisp on your kernel CD or you want to usethe latest version, fetch the current SAP Web dispatcher from the SAP Service
Marketplace under http://service.sap.com/patches under SAP Web AS → SAP Web AS
6.40 → Binary Patches → SAP KERNEL → <OS Platform> → Database Independent .Here you can download the packet DW.SAR, this contains the SAP Web dispatcher(sapwebdisp).
Although the SAP Web dispatcher can run in any directory, SAP recommends that youinstall it in a separate directory:
Windows: C:\Program Files\SAP\SAPWebDisp
UNIX: /usr/sap/<SID>/sapwebdisp
Create the directory for this and unpack program sapwebdisp into this directory. Alsocopy the associated profile file into this directory.
Figure 2: Activating ICF Service (transaction SICF)
In transaction SICF the services /sap/public/icman and /sap/public/icf_info must beactive. If either service is inactive it can be activated by selecting it and choosing menuService -> Activate .
Starting the SAP Web Dispatcher
You start the SAP Web dispatcher with the command:
1: Delete the shared memory of the SAP Web dispatcher (cleanup )
2: Try to connect to the shared memory (attach )
4: Create a new shared memory (create )
This results in the following possible options:
1: The shared memory is cleaned up and the SAP Web dispatcher ends.The behavior is the same as with the option of –cleanup.
2: The SAP Web dispatcher connects to the existing shared memory(attach). If this does not exist, the SAP Web dispatcher ends with an error.
3: Not useful
4: The SAP Web dispatcher creates a new shared memory. If this existsalready, the SAP Web dispatcher ends with an error. This is also thedefault value, that is, the SAP Web dispatcher behaves in this way if theoptions -shm_attach_mode <mode> and -cleanup are not used.
5: If a shared memory exists already, it is deleted. A new shared memoryis then created.
6: The system tries to attach it to an existing shared memory. If a sharedmemory does not exist, a new one is created.
7: As 5
• -auto_restart:With this option you can enable high availability for the
SAP Web dispatcher at process level. The process is described in the helpsection High Availability of the SAP Web Dispatcher.
• -version displays the version of the SAP Web dispatcher. The program is
not started.
Example: you usually start the SAP Web dispatcher as follows:
sapwebdisp pf=<Profile name>
Installing the SAP Web Dispatcher as a Windows Service
1. Download the latest version of the SAP Web Dispatcher to the Web DispatcherDirectory (for example C :\SAPWebDispatcher ):
a) Fetch the current SAP Web Dispatcher from the SAP Service Marketplace
under http://service.sap.com/support under Downloads → SAP Support
Packages → SAP Support Packages and Patches → Entry by
Application Group → SAP NetWeaver Components → SAP NetWeaver -> Kernel -> Database Independent . Here you can download the packetDW.SAR , this contains the SAP Web dispatcher (sapwebdisp.exe ).
b) Create directory C:\SAPWebDispatcher .
2. Unpack the SAP Web Dispatcher.
a) Use the following command: sapcar –xvf DW.SAR
Note: sapwebdisp.exe can be found under the folder:
usr/sap/DEV/SYS/exe/run as well.
Note: sapcar can be downloaded from http://service.sap.com/support under
Downloads → SAP Support Packages → SAP Support Packages and
Patches → Entry by Application Group → Additional Components -> SAPCAR -> SAPCAR 6.20
If you have an access to training system: sapcar is underG:/Additional_Files
3. In transaction SICF , check that the following services are active and, if they arenot, activate them:
4. Create a profile for the SAP Web Dispatcher (sapwebdisp.pfl ) and save it in theWeb Dispatcher directory.
Use the following values for the parameters:
SAPSYSTEMNAME <SID> of your SAP systemSAPSYSTEM System number that is unique on the hostrdisp/mshost Host name of your server twdf####
ms/http_port HTTP port of the message server
icm/server_port_0 PROT=HTTP,PORT=80
icm/server_port_1 PROT=ROUTER,PORT=443
Note: The shared memory segment where the SAP Web Dispatcher operatesmust be different from the segments of the ABAP and the Java stacks, there forthe SAPSYSTEM should be unique on this host, neither the ABAP nor the Java
SID can be used!
a) Create file (sapwebdisp.pfl ) using Notepad with above values and save inWeb Dispatcher directory.
Note: The sapwebdisp.pfl can be created also automatically. Start the WebDispatcher with the following option: sapwebdisp.exe –bootstrap and follow thewizard.
b) Answer the following questions for your SAP system:At which port will your SAP Web dispatcher receive requests?To which SAP system are these requests forwarded?
The following parameters answer the questions:• icm/server_port_<x>: Specifies the port at which the SAP Web
dispatcher listens for each protocol (for example, PROT=HTTP )• rdisp/mshost : Name of the host on which the message server is
addressed
• ms/http_port : Port at which the message server is queried using HTTPThe last two parameters specify the addressed SAP system uniquely.
Note: The SAPSYSTEM parameter is used to create shared memory areas andmust be differentiated from all other SAP instances on the host of the SAP Webdispatcher.
5. Start the SAPWeb dispatcher with the prepared profile file. The trace should bewritten to a file, dev_sapwebdisp<##> , where ## is your group number.
a) Run the command sapwebdisp pf=<profile file> -f dev_sapwebdisp<##> in the command prompt.
To do this, you must either specify the profile file with a complete path name,or call the command from the installation directory C:\SAPWebDispatcher .
The SAP Web dispatcher outputs a message saying that it has successfully
a. Determine the process ID (PID ) of your SAP Web dispatcher at operatingsystem level of your server.
You can find this number, for example, from the output when starting theSAP Web dispatcher, from the trace file dev_sapwebdisp<##> or from theWindows Task Manager.
b. Open another command prompt (in Microsoft Windows, choose Start ->Run... and enter cmd ).
Run the command sapntkill -INT <PID> with the process ID that youhave just identified.
10. Check that the service is installed in the list of services.
a) Open the services by going to the Windows Start -> Control Panel -> Administrative Tools -> Services . Check that sapwebdisp is now inthe list of services.