TADMJ1+ +SAP+Java+Engine+Administration

TADMBO Implementation&Operation II

TADMJ1

SAP Java Engine Administration

THE BEST-RUN BUSINESSES RUN SAP SAP AG 2004 © SAP AG©2004

2005/Q1

Material number: 50069563

© SAP AG

Course Overview - 1

Course: SAP Java Engine Administration

Units: 1. Web AS Standalone Java Installation 2. Java Startup & Control Framework 3. Web AS Java Administration Tools Overview 4. SAP Java Administration 5. SAP Web Infrastructure

© SAP AG 2004, Web AS Java Installation and Upgrade

1

Unit: Web AS Standalone Java Installation

Lesson: Installation of the SAP J2EE Engine


2

Installation of the SAP J2EE Engine

SAP AG

3

Installation of SAP Web AS Java: Lesson Objectives

After completing this lesson, you will be able to: Plan your Web AS Java Installation. Understand the document changes Understand the changes in the SAPInst process Migrate/upgrade your previous Web AS Java Installation. Understand the J2EE Engine installation steps


4

Introduction Document Changes SAPInst Changes J2EE Engine Migration and Upgrade

5

The Web App Server provides a common foundation for NetWeaver The Web Application Server is the complete infrastructure to develop, deploy and run: All SAP NetWeaver components mySAP Business Suite

mySAP Business Suite ERP

CRM

Customer-developed applications 3rd-party Java 2—Enterprise Edition-compliant applications

SRM

SAP NetWeaver™ BW

Integrates the proven ABAP and the innovative internetdriven Java technology in one application server

EP

XI

MI

MDM

Web Application Server 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 3rdparty 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.

6

Basic System Variants of SAP Web AS For SAP Web AS 6.40, the following basic system variants exist: • SAP Web AS ABAP (ABAP Engine, but no J2EE Engine) • SAP Web AS Java (J2EE Engine, but no ABAP Engine) • SAP Web AS ABAP+Java (ABAP Engine and J2EE Engine)

SAP Web Application Server Central Instance J2EE Engine

ABAP Engine

Central Services Instance (SCS) SAP Web AS Java

Detailed view: central instance consists of both ABAP and Java parts, SCS instance only required for Java

SAP Web AS ABAP

Database Instance Java Schema

ABAP Schema


The SCS (Central Service Instance) is required only for Web AS Java. The SCS consists of several Central Services which run on one physical server. The Central Services comprise the message service and the enqueue service. The SCS forms 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 server with their own system number and the system ID (SID) of the whole system.

7


8

Main SAP documentation types

Documentation types in the software life cycle © SAP AG 2004, Web AS Java Installation and Upgrade

An overview of the most important documentation types that are needed in the various phases in the life cycle of SAP NetWeaver.. The changes to these guides are released as OSS notes, before going to the documents, you should look for released notes.

9

Documentation Roadmap 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 components and 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 immediately before 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.

10

Concept of Installation Checklists in Installation Guides 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 step to the corresponding section. You perform the procedure described there. After successfully completing the installation step, you mark the corresponding entry in the printed table with ! to log the progress of your installation. You proceed with the next step in the checklist Installation Guide

Concept not new, but essential for navigation in installation guides

General Information Installation Checklists

Print

Step 1

Planning Preparation Installation

Installation Checklists

References

Step 2 … Step n

Post-Installation Additional Information © SAP AG 2004, Web AS Java Installation and Upgrade

This is not new but convenient way to follow the Installation steps.

11

Evaluation of Planning Guide for UNIX/Oracle All planning steps shifted to new guide You choose a basic system variant of SAP Web AS. You choose the SAP instances you want to install. You choose how you want to distribute the SAP instances to installation hosts. You decide if you want to perform a MCOD installation. You decide if you want to use the LDAP for SAP Logon or the Microsoft Management Console (MMC). For every SAP instance, you collect the values of the installation parameters listed in the corresponding parameter tables.

In the present installation guides, only tasks will remain that have to be performed ‘on the system‘ There is one parameter table for every installation service of SAPinst, contains description of the SAPinst dialogs for your installation

Usage of this documentation is mandatory for installations on UNIX/Oracle © SAP AG 2004, Web AS Java Installation and Upgrade

This Planning Guide is new, and evaluated only for Unix/Oracle, evaluations for other platforms will come with the next releases. The Planning Guide is mandatory for Unix/Oracle, because the planning information is removed from the normal installation guide..

12

Where are all the documents stored?

http://service.sap.com/instguides

-> SAP NetWeaver -> Release 04 NetWevaer 04 - Planning / Installation / Upgrade / Operation

-> SAP Components -> SAP Web Application Server Releases - 6.10 / 6.20 / 6.30


All the required documentation you can find under http://service.sap.com/instguides

13


14

Shipment-Specific SAPinst Changes

SAP NetWeaver gets delivered exclusively on DVD DVDs are only used as data carriers If SAPinst prompts for a CD, it will be possible to select the corresponding 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 be used for the installation of the J2EE Engine.

15

Tool-Specific SAPinst Changes

You start SAPinst directly from the Master CD/DVD, manual creation of an installation directory is no longer required (but still possible) SAPinst normally creates sapinst_instdir/ automatically under: UNIX: the temporary directory ($TEMP or $TMP or /tmp) Windows: %ProgramFiles%

JRE is still required for the SAPinst GUI. Nevertheless, JRE is part of the SAPinst executable for Windows IA64, HP-UX, and Sun Solaris. For all other operating systems, you must still install JRE (or JDK, see below) as prerequisite.


16

Product-Specific SAPinst Changes

SAP System Landscape Directory (SLD) is part of SAP Web AS Java 6.40 installation Possibility to configure User Management Engine (UME) of an SAP Web AS Java system against the user management of a separate SAP Web AS ABAP system JDK 1.4 is required for SAP Web AS Java 6.40. For exact version, see SAP Service Marketplace at http://service.sap.com/platforms On Windows, setting of JAVA_HOME is no longer a prerequisite as SAPinst checks the registry for installed JVMs. If the environment variable JAVA_HOME points to a JVM with a valid version, it is used by default. If not, the JVM with the highest version in the required version range is used.


When only one central User Management is going to be used, the connection can be configured during the installation. However this connection can be established later as well. This feature is suitable for large cluster installations where every server is installed on different box.

17

Corresponding Installation Services

SAP Web AS Java System

SAP Web AS ABAP+Java System


When installing the Add-In installation, the ABAP installation is first, after comes the Java stack. Different installation options are possible. Central Instance on one box, Dialog instances on another. Also you can install the Web AS Java on different box but the Database.

18

Installation Options Add Support Package Default Installation Add additional server instance

Installation options for different databases


The installation provides possibility to install Web AS Java + Java Developer Workspace at once. This is fast and very convenient way for developer, where they have 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 be used for the installation of the J2EE Engine.

19

Installation Options Specific SAPinst Changes


Simplified installation in default mode: Default values are used for most of the installation parameters: Enables you to set up an SAP Web AS Java system in a more quick and easy way, if the default values are sufficient for your purposes. Default Installation, doesn’t support all Data Bases yet only Oracle and MaxDB. The non supported will come in the next releases. Although you can still change some values you like – flexible easy install mode.

20

Post Installation: Apply NetWeaver ´04 SP Stack

SAP NW `04 SP Stack

Released

NW ABAP stack

WebAS JAVA

NW Dev. Studio and JDI

Stack 04

Aug. 2004

SP4 + new Kernel patch

J2EE 6.30 SP7

NWDS 2.0 SP7 JDI 6.30 SP7

Stack 05

Sept. 2004


J2EE 6.40 SP8


Stack 09

Oct. 2004


J2EE 6.40 SP9


Renumbering of all SAP NetWeaver `04 Support Package Stacks


NW Component – Overview NetWeaver 04 ABAP stack SAP_KERNEL 6.40 (incl. ITS) / SAP IGS 6.40 SAP_BASIS 6.40 (incl. XI 3.0 ABAP and KW 7.0) SAP_ABA 6.40 (incl. MI 2.5 ABAP) PI BASIS 6.40 (PlugIn Basis) SAP_BW 3.5 (incl. BI Content for BW installation option) NetWeaver 04 JAVA stack WebAS 6.40 JAVA stack SAP JAVA runtime 6.30 (J2EE, WebDynpro, UME, …incl. MI (Mobile Infrastructure) middleware) ADOBE (optional installation) SAP DEV. INFRASTRUCTURE (JDI) (optional installation) NW JAVA Applications XI Java 3.0 (divided into 4 sub-components + XI-Partner Connectivity Kit) BI 3.5 Java component (UDI / MMR for WebAS) EP 6.0 (PP + KM) / incl. Unification as of FP (SP stack 04), BI Broadcasting contained in KM KW 7.0 Java components (PAW 7.0, SAP IKS 1.0) NW Development Studio 2.0 (incl. Plug-Ins from all NW Java Applications) MI 2.5 client (NOT based on WebAS Java) NetWeaver 04 other components SAP GUI 6.20 available / 6.40 to be released as accessible WinGui mid 2004 SAP TREX 6.1 / SAP CS 6.30 PlugIns PI_BASIS (for BW) and WP_PI (for EP) available Various NW content packages (BI, XI, EP) or SAPgui extensions (KW, BI) not considered here

21

Post Installation: Check Ports SAP Web AS Java port calculation: 50000+100*snr+port_index

0

HTTP port

Port_index= left table column

1

HTTP SSL port

Examples:

2

IIOP Initial Context port

3

IIOP SSL port

4

P4 port

5

P4 HTTP Tunneling port

6

P4 SSL port

7

IIOP port

8

Telnet port

9

Monitor port

10

JMS port

snr= instance number

AdminTool: port 50004 Telnet: port 50008

This way port conflicts should be avoided. You can individually configure every port the J2EE Engine uses Port numbers are configured in Visual Administrator Remember that all requests go through dispatcher!

Message Server port: 3600+instance number of the central services instance © SAP AG 2004, Web AS Java Installation and Upgrade

22

Directory Structure of WEB AS 6.40 ABAP+Java

j2ee


The Java Instances are using in general the same filesystem layout as it is known from the ABAP Instances. The only different is the directory j2ee. In this directory most Java related files are stored (other directries are /usr/sap//sys/profile /usr/sap//>InstnaceName>/work). /usr/sap/CCMS is the monitoring file tructure not shown in the graphic (see TADMJ5 for details)

23

Java Only Instance on File System Different types of Instances JC J2EE Engine Instance

SCS Central Services Instance

DVEBMGS ABAP Instance


/usr/sap/// data

Data directory e.g. Cachefiles

exe

executables e.g. startsap, stopsap, saposcoll

j2ee log

Log files

SDM

Executables and Data of SDM / SDM Repository

sec

Security files

work

Workdirectory

/usr/sap/// data

Data directory e.g. Cachefiles, Enqueue File

exe

executables e.g. startsap, stopsap, saposcoll

log

Logfiles e.g. Syslog

sec

Security files

work

Workdirectory

24

Directory Structure of J2EE Instance


/usr/sap/C11/JC00/j2ee admin

Executables Visual Administrator

cluster

J2EE Cluster Executables and Configuration

configtool deploying

Executables ConfigTool Directory of Deploytool

j2eeclient

jar files for a P4 client

os_libs

operating system dependend libraries and executables e.g. jcontrol, jlaunch …

/usr/sap/C11//j2ee/cluster bootstrap

JAR Files and properties for bootstrap

dispatcher

JAR Files, logfiles and propertie files of the Dispatcher

server JAR Files, logfiles and propertie files of the Dispatcher /usr/sap/C11/JC00//cluster/dipatcher bin

JAR Files of Dispatcher

cfg

propertie files for manager

dtd

Data type definitions

log

log Files of Services and Managers

temp

temporary files

/usr/sap/C11/JC00/j2ee/cluster/server apps

JAR Files of Applications

bin

JAR Files of Server

cfg

propertie files for manager

dtd

Deployment Descriptoren

log

log Files of Services and Managers

META-INF temp

temporary files

25

System Profiles


DEFAULT.PFL

Default profile of the Systeme

START_JC00_P65028 Instancenumber 00

Start profile of J2EE Instance with

START_SCS01_P65028 Instancenumber 01

Start profile of Central Services Instance with

C11_JC00_P65028 Instancenumber 00

Instance profile of J2EE Instance with

C11_SCS01_P65028 with Instancenumber 01

Instance profle of Central Services Instance

26

SAP License Key You need a valid SAP license to log on to the SAP Web AS. When the SAP Web AS is installed, a temporary license (29 days) is also installed which you must replace with a permanent license. With an ABAP + J2EE installation you need an ABAP license! In the Visual Administrator choose Server 0 → Services → Licensing Adapter. The system data appears that you need to request the license from the SAP Service Marketplace. 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


You need a valid SAP license to log on to the SAP Web AS. When the SAP Web AS is installed, a temporary license is also installed, which you must replace with a permanent license. Note that with a J2EE+ABAP installation (SAP Web Application Server with ABAP and J2EE), you have to import the ABAP license (see SAP License). 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 to request the license from the SAP Service Marketplace appears.

Installation number (if it exists) System ID, System number (if it exists) Hardware key Current release 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 request license keys. Enter your e-mail address in the request. The license key will be sent to you promptly by e-mail. Alternatively, you can also download the license key from the SAP Service Marketplace. 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.

27


28

J2EE

J2EE

6.20

6.20

6.20

6.20

Patch

No Upgrade

ABAP

ABAP

ABAP

J2EE

6.20

6.20

6.30

6.30

≥SP25

≥SP2

≥SP2

ABAP

2E E

6.40

ABAP

Java Engine

6.30

6.40

Patch Add-In

ad dJ

Patch

de +

Upgrade

≥SP25

J2EE

No Upgrade

J2EE only

ABAP

Up gr a

WebAS 6.40

ABAP + Java optional

ABAP only

Patch

WebAS 6.30

WebAS 6.20

Status 6.20 / 6.30 / 6.40

Java Engine

6.30 ≥SP4

≥SP4

Dependency APAB -> J2EE in WAS 6.40


ABAP and Java Engine version release of the Web AS 6.20 to 6.40 installations, and possible upgrades. The Web AS 6.20 and 6.30 support 3 installation options: ABAP only; ABAP + Java; Java only The Web AS 6.40 – supports only 2 installation options: Add-In (ABAP + Java) and Java only. The ABAP only installation in not possible any longer, because of dependency of the applications on the Java Engine. Upgrades of the Web AS (ABAP only) installations: Web AS 6.20 (ABAP 6.20) can be upgraded to Web AS 6.30 (upgraded ABAP 6.20) Web AS 6.30 (ABAP 6.20) -> the last Web AS (ABAP only) installation option. Upgrade to Web AS 6.40 should be carried by upgrading the ABAP 6.20 to 6.40 and installing Java Engine. (The Web AS 6.40 Add-In installation consists of ABAP 6.40 + Java Engine 6.30 ≥ SP3) Upgrades of the Web AS (Add-In) installations: • Web AS 6.20 (ABAP 6.20 and optional J2EE Engine 6.20) – patch of the ABAP kernel to ABAP 6.20 SP 25 or newer, and full migration of the J2EE Engine 6.20 to 6.30 (upgrade of the J2EE Engine not possible!) • Upgrade of Web AS 6.30 to 6.40 – ABAP kernel upgrade from 6.20 to 6.40; J2EE 6.30 to 6.30 ≥ SP4 patch with workarounds (see support package guide SP2 - SP4)! Upgrades of the Web AS (Java only) installations: • Web AS 6.20 (J2EE 6.20) can only be migrated to Web AS 6.30 (J2EE 6.30)! • Web AS 6.30 (J2EE 6.30) can be patched with workarounds to Web AS 6.40 (J2EE 6.30 ≥ SP4) J2EE Engine 6.20 -> 6.30 is a migration not an upgrade

(Add-In and Java only installations)

J2EE Engine 6.30 -> 6.40 is a upgrade/patch procedure with some workarounds (Add-In and Java only installations)

29

Migration Scenarios – Next Releases

A direct migration of 6.20 to > 6.40 release is not planed! The required steps are: Migration of the engine + applications 6.20 – 6.40 The applications on 6.40 need to comply with several rules to enable future upgrade. An upgrade 6.40 – NextRelease will be provided.


Direct migration from 6.20 to newer but 6.40 release is not planed. The required steps are: 6.20 – 6.30/6.40 migration and afterwards a 6.30/6.40 – NextRelease upgrade. Upgrade of Web AS Java 6.30 to 6.40 should be carried by these steps. Installation of Web AS Java 6.30 SP 0/1 Upgrade to SP2 Upgrade to SP4 (Web AS 6.40) Upgrade to latest SP release. Upgrade of Web AS 6.30 SP 0/1 to latest Web AS 6.40 SP is not planned. Always going to 6.30 SP2 and SP4 first! SP3 is the first Web AS 6.40 release – available as installation option.SP3 is not released for productive usage, always upgrade to the latest SP release.

30

J2EE Migration 620 – 630/640 6.20 – 6.30/6.40 is a migration and not an upgrade: Application data has to move to the standard SAP schema Application tables need to fulfill the conditions of SAP JDDI Namespace rules Table and field name conventions Type restrictions due to portability

Major technological changes in the J2EE engine architecture 620 has file system persistency 630 has the engine data in DB tables

All application data has to be copied! All engine configurations and data has to be copied / replaced!


Web AS Java 6.20 – 6.40 migration guide, and documents can be found in the documentation path: SAP Library -> SAP NetWeaver -> Application Platform -> Java Technology in SAP Web Application Server -> Migration Manual

31

Migration 6.20 – 6.30/6.40 Scenarios Stand alone J2EE engine: Migration procedure available and tested Converter Tool

J2EE add-in installation in ABAP DB: Additional steps in the migration needed XI migration scenario is in development

J2EE + ABAP with two databases: Migrate the J2EE DB into the ABAP DB

Migrate to another DB vendor: Not all migration scenarios are supported yet.


The Converter Tool is used for converting J2EE applications developed to be deployed and run on the J2EE Engine 6.20 into applications that can be deployed and run on the J2EE Engine 6.40. The tool updates the standard deployment descriptors and creates the necessary J2EE Engine-specific deployment descriptors. The Converter Tool can be started with the convertor script file from the /deploying directory. The XI migration scenario will be available for the Mass Shipment (General Availability) of NetWeaver ‘04

32

Overview: Java component & technology upgrade SAP J2EE 6.20 1. Customermodification & extension

2. Application data (FS, DB)

3. Application config (FS, R/3)

SAP J2EE 6.30/6.40

a

diff & merge

a a migrate (if nec.)

merge & migrate

1. Customermodification & extension

a

SAP J2EE 7.0

diff & merge Modif Modif adjust adjust tool tool ??

2. Application data (DB)

1. Modification & extension framework

2. Application data (DB)

3. Application config (FS, R/3,DB)

Standard Standard ?? Framework Framework ??

SAPInst

Standard Standard ?? Repository Repository ??

merge & migrate import import tool tool ??

3. C2-Server

Legend: Application specific Tools

4. Security / User man.

Engine config

migrate (if nec.) import import tool tool !!

manual ?

4. UME 4.0

4. UME

or ABAP backend

or ABAP backend

Engine config

Engine config

import import tool tool ??

Standard / Generic Tools Conflict

a: standard vs reality


This slide shows the efforts made to consolidate the different areas of the SAP J2EE Engine into a common infrastructure, so that the Java upgrade tools can work in a similar way to the Abap upgrade tools. In SAP J2EE 6.20 to 6.30/6.40 migration mostly all areas are should be handle by application specific procedure. In SAP J2EE 7.0 onwards the Java upgrade tools would be able to upgrade the most of the engine and applications with minimal manual interaction.

33

Applications running on J2EE Engine 6.20 Most customers … only use one or two SAP Java apps productively have modified .jsp, .css files (not .java) have used app specific enhancement framework(s) have developed their own J2EE apps using SAP J2EE 6.20 run Java apps on separate WebAS (with Java stack only)

Hard to tell exactly which source versions customers have delivery hard to reconstruct without DTR

Only few applications have >100 customers EP5/6 CRM SRM (mostly use of UME)


This is the typical use of SAP in our customers J2EE Engine, and thus has been taken into account to the current development of J2EE upgrade technology.

34

Appendix – J2EE Engine Installation Steps

35

J2EE Engine Installation Steps 0 Engine CI

Steps of Engine Installation SAPInst


36


Steps of Engine Installation SAPInst

1)

Database


37

Install Database


Steps of Engine Installation JControl

SAPInst

Database


38

1)

Install DB

2)

Install SCS + bootstrap component



SAPInst

SDM (standalone)

SDM Repository

Database


39

1)

Install DB

2)


3)

Install SDM



SAPInst

SDM (standalone)

SDM Repository

Database


40

1)

Install DB

2)


3)

Install SDM

4)

Configure SDM targets



SAPInst

SDM (standalone)

SDM Repository

Database


41

1)

Install DB

2)


3)

Install SDM

4)


5)

Configure JControl for SDM



SAPInst

SDM (standalone)

Offline Deploy Tool SDM Repository

Database


42

1)

Install DB

2)


3)

Install SDM

4)


5)


6)

Deploy Offline Deploy Tool, …



SAPInst

SDM (standalone)


Config DB:

Database


43

1)

Install DB

2)


3)

Install SDM

4)


5)


6)


7)

Deploy tables for Config-DB



SAPInst

SDM (standalone)


Config DB: Engine comp's Database


44

1)

Install DB

2)


3)

Install SDM

4)


5)


6)


7)


8)

Deploy Engine Components



SAPInst

J2EE Dispatcher J2EE Server deploy service...

SDM (standalone)


Config DB: Engine comp's Database


45

1)

Install DB

2)


3)

Install SDM

4)


5)


6)


7)


8)


9)

Start J2EE Engine



SAPInst


SDM (standalone)


Config DB: Engine comp's

1)

Install DB

2)


3)

Install SDM

4)


5)


6)


7)


8)


9)

Start J2EE Engine

10) Deploy Applications Appl DB: Appl data

Database


46



SAPInst


SDM Server (integrated)



1)

Install DB

2)


3)

Install SDM

4)


5)


6)


7)


8)


9)

Start J2EE Engine

10) Deploy Applications 11) Start SDM Server

Appl DB: Appl data

Database


47



SAPInst SAP Netweaver Developer Studio


SDM Server (integrated)



1)

Install DB

2)


3)

Install SDM

4)


5)


6)


7)


8)


9)

Start J2EE Engine

10) Deploy Applications Appl DB:

11) Start SDM Server

Appl data

12) Install Developer Studio (Optional)

Database


48

Installation of SAP Web AS Java: Lesson Objectives

You should now be able to: Plan your Web AS Java Installation. Understand the document changes Understand the changes in the SAPInst process Migrate/upgrade your previous Web AS Java Installation. Understand the J2EE Engine installation steps


49

SAP Java Engine Administration – Exercises Unit 1: Web AS Standalone Java Installation Lesson 2: J2EE Engine Installation

At the conclusion of this exercise, you will be able to: • Install Web AS Java Engine with MaxDB

1. Installation of JDK 1.4 SUN JDK 1.4 latest SP is required for installing Web AS Java Engine. http://java.sun.com/j2se/1.4.2/download.html J2SE JRI is not enough to run Web AS Java, you must install JDK. 1-1 Check is the JDK installed on the box. To check whether a JDK is installed in command prompt run command java –version

Note: The latest SP of the SUN JDK 1.4 may be newer than the shown on the screenshot.

1

1-2 Install JDK 1.4 if is not installed. Take the JDK installation from the trainer. Or download it from SUN website.

2

2. Start the Web AS Installation Go to the Web AS installation folder, provided from the trainer, or start the provided CD.

3

2-1 Install with SAPInst After SAPInst has started navigate to -> SAP NetWeaver ’04 Java System (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 folders in the DVD storage.

Choose SAP NetWeaver ’04 -> J2EE System -> Central System -> Install a J2EE Server in Custom Mode

Click on the icon

in the white label bellow Package Location

and navigate to the installation CD: 4

G:/setup/SAP_NetWeaver_04_Java/J2EE

Choose the Installation CD label: G:/setup/SAP_NetWeaver_04_Java/J2EE/LABEL.ASC And press OK. On the next screen type ABC as a System ID

and press Next On the next screen navigate to the correct JDK version: 5

G:/j2sdk1.4.2_03 (chosen by default) and press Next On the next screen choose Local installation!

and press next. On the next screen type the passwords of the users: SAP Administrator Account: abcadm Password: abcabc SAP Service Account: SAPServiceABC Password: abcabc

6

Press Next

On the next screen choose 40 as SCS instance number. Leave empty the Message Server port.

and press Next 7

On the next screen type 43 for the ABC J2EE Engine instance number Change the Number of J2EE Servers to 2.

Press Next On the next screen choose J2EE DB as User Management Data Base.

8

and press Next. On the next screen type the passwords of the users: J2EE Administrator and Guest: User: Administrator Password: abcabc User: Guest Password: guest

9

and press Next On the next screen type the password of the SAP J2EE Engine schema DB user: User: SAPABCDB Password: abcabc

10

and press Next On the next screen choose No SLD available.

11

and press Next. On the next screen click on the Package Location label

and navigate to the IGS installation folder G:/setup/SAP_NetWeaver_04_Java/IGS

12

Press OK, and press OK to go to next screen MaxDB CD: On the next screen MaxDB CD

13

Choose the folder: G:/setup/MAX_DB_7.5.0_Build 07_RDBMS for the Package Location of MaxDB

and press OK to go to the next screen. On the next screen MaxDB CD

14

Choose the folder: G:/setup/MAX_DB_7.5.0_Build 07_RDBMS for the Package Location of MaxDB

15

and press OK to go to the next screen. Leave the values as default on the next screen and press next.

16

On the next screen choose G:/ as DB Log folder and 500 MB as volume size:

and press Next. On the next screen choose G:/ as DB Data folder and 500 as volume size:

17

and press Next Leave the next screen with the default values and press next.

18

Check all the values on the next screen and press Start if everything is fine:

Press Start to start the installation process. 19

You see the installation screen:

You can monitor the installation process clicking on the Log button:

20

If you get this message just press OK

The message saying that the installation has finished:

After opening the SAPMMC you’ll se the new instance as well.

21

Note: You can monitor the installation steps and the SAPInst log file during the installation process. Use the SAPInst log files if a troubleshooting required.

22

3-1 Check installation. When the installation finish start SAPMMS Go to : Start -> Programs -> SAP Management Console

Check is the SAP Java engine up and running.

23

4-1 Installation of NetWeaver Developer Studio. If the SAP NetWeaver Developer Studio is not installed on the master system…

…you can install it from: Navigate to the installation folder of Web AS -> sapinst -> opt -> J2EE-CD -> IDE Click on JDTsetup.exe 24

Note: When performing SAP NetWeaver ’04 Developer Workplace Installation, the NetWeaver Developer Studio is also installed!

25

4-1 Installation of SP7. Now you have to continue with the upgrade to Support Package SP7. The SP7 upgrade for MaxDB is available under folder: G:\setup\ATP_Web_AS_6.40_TC_Track\TADMJ1\WAS_Installa tion\SP7_Upgrade Start the sapinst.exe from folder: G:\setup\ATP_Web_AS_6.40_TC_Track\TADMJ1\WAS_Installa tion\SP7_Upgrade\SAPINST-CD\SAPINST\NT\I386\sapinst.exe

Navigate to

26

and click Next. On the next screen click Browse and navigate to the ABC Central instance profile: G:\usr\sap\ABC\SYS\profile\ABC_SCS40_xxxx

and press OK. 27

and press Next. On the next screen fill the Windows Domain name, And the passwords of abcadm and SAPServiceABC users: The passwords should be abcabc if you haven’t chosen different ones during the previous installation.

28

and press Next Press Start on the installation screen.

You see the upgrade running.

29

Check whether the ABCDB is running (with the SAPMMC), if it not - start it. And press OK

You can monitor the upgrade pressing the log button.

30

31

The upgrade finishes successfully. You can call the ABC main page using URL: http://localhost:54300/index.html The Web AS Java SP7 is up and running.

32




1


Lesson:

Java Start & Control Framework


2

Java Startup and Control Framework

SAP AG

3

Java Startup and Control Framework: Lesson Objectives

After completing this lesson, you will be able to: z Understand the startup process of SAP Web Application Server Java z Understand the bootstrapping procedure. z Understand what role they do play to locate and identify errors during server startup.


4

Java Cluster Architecture J2EE Startup Framework

5

Overview Architecture Web AS ABAP and Java


This system provides the following functions: Operation using SAPGUI z Users log on to the dispatcher and work processes perform the users’ tasks. Processing Web requests. z Web requests are received by an Internet Communication Manager (ICM). These HTTP(S) requests may be designated for the Internet Communication Framework (ICF), that is, processed in an ABAP work process (for example, BSP Applications), or they may be J2EE requests, designated for the J2EE Engine. z For each incoming HTTP request, the ICM must decide whether it should forward the request for processing to the ABAP engine (the ICF) or to the SAP J2EE engine. This decision is made using the URL 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 is requested, 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 as HTML 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 sent to the client. When the page is next called, then the application gets the page directly from the ICM and sends it to 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 HTTP service 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.

6

Web AS Java Cluster Architecture SAP Web AS Java Cluster

J2EE Instance Consists of a dispatcher process and one ore more server processes Processes run on one host Are started and stopped together All server processes of all instances of a system are grouped in a cluster

SAP SAP Web Web AS AS Java Java Central Central Instance Instance J2EE Dispatcher Server Process Server Process Server Process

SAP Central Services

SDM

Cluster wide communication Central locking objects

DB J2EE schema

SAP SAP Web Web AS AS Java Java

Central Database System Software Applications All configuration data

Central Services

J2EE Dispatcher Server Process Server Process Server Process

Software Delivery Manager

SAP SAP Web Web AS AS Java Java J2EE Dispatcher Server Process Server Process Server Process

keeps track of distributed software


One Java Engine installation consists of: One or more Java instances (Java Dispatcher, Server) and the Software Deployment Manager (SDM) The Central Services (Messaging Service, Enqueue Service), which also create an instance (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 Service Instance is required in the J2EE Cluster. The Configuration of the J2EE Engines are now stored in a Database. Not any more stored 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 onto the different Java dispatchers.

7

Central Service - Message Service

Tasks of the Message service: Notification of events that arise in the cluster. Communication between different services Forwarding of messages and requests to all participants (broadcast) Prepare logon information for the SAP Web Dispatcher Support for message server failover Guaranteed message transmission Exchange of cache information in the cluster


The Central Services run on one physical server and are one Java instance. They comprise the Message 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 server with 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 the program JControl The message service is a separate program used for communication between the elements of a Java cluster. It keeps a list of all processes (dispatchers and server) of the Java cluster. It represents the infrastructure for data exchange (small datasets only) between the participating nodes. The message service also supplies information to the SAP Web Dispatcher about Load Balancing. 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 the message Info Service in Visual Administrator described bellow. Message server and Message Service are used synonymously. The correct expression would be that the Message Server is a process or program that provides the Message Service.

8

Message Info Service in the Visual Administrator


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 is started. If should be started manually: zUsing the SAP J2EE Engine visual administrator. 1. Choose Cluster → Server 0 → Services 2. Choose Message Info 3. Choose Start Service in the toolbar zUsing 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, be careful

9

Central Service - Enqueue Service Enqueue Service manages logical database locks, which are set by the executed application program in a server process. Enqueue Service synchronizes data across the cluster.


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 or releasing locks. It also maps the logical locks to the database. The Enqueue service can be configured for high availability, by setting it up with the replication server and a platform-independent high availability solution. The status of the Enqueue service are made accessible to the administrator via the Locking Adapter Service in the Visual Administrator. The terms Enqueue server and Enqueue service are used synonymously. The correct expression is that the Enqueue server is the program or process that provides the Enqueue service. Enqueue Service is represented by an en.sap process

10

Locking Adapter in the Visual Administrator

With the Locking Adapter checks and tests of the Enqueue Service can be done. © SAP AG 2004, Web AS Java Installation and Upgrade

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 the Enqueue 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 which server 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 is locked

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: z To display existing locks; choose Display Locks. z To set and release locks, choose Create/Release Lock. z To delete existing locks, select the locks and choose Delete Selected Locks. z To run test programs, choose Run Tests. To run functional tests choose Execute Functional Tests, and to load tests choose Execute Load Tests). z To display files, choose View Files. You can view the profile data or the trace file of the lowest layer of the enqueue service. This is useful for looking for errors. z To display statistics, choose Time Statistics.

11

Java Instance – Java Dispatcher Java Dispatcher components: Connection request handler receives the first request from a client. From this time point on, the client has a fixed connection to the dispatcher. Connection manager manages the existing connections to the clients. Session level services are services that are assigned to a session. Communication handler forwards the request to the server process. Accumulating requests are stored in the request queue.


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 possible to 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, the Central 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 process with the lowest capacity usage. If there is already a connection to the client, the request 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 applications used for load balancing to the local servers only. Interprocess communication Dispatcher on one box – Server on other box is not possible.

12

Java Instance – Server Process

Server Process components: Connection request handler receives the first request from a client. From this time point on, the client has a fixed connection to the dispatcher. Session level services are services that are assigned to a session. Application-level services or the actual application program.


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 of requests simultaneously. Java Dispatcher assigns requests to the server processes. The identification of the jlaunch processes can be easy done with their PID, the PID is also represented in the monitoring tools as the SAP Management Console.

13

SDM Instance

J2EE Dispatcher

Software Deployment Manager (SDM) J2EE Server process

SDM Server

started automatically as part of WEB AS 6.40

one SDM Server per WEB AS 6.40 with J2EE Engine is necessary

SDM

SDM Interfaces

Commandline Interface (sdm.bat or sdm.sh) z A new SDM process is started each time a command is executed z No SDM Server may run at the same time (this is checked).

JAVA API (SDMclient.sda) needs a running SDM Server

SDM Gui (sdmgui.bat or sdmgui.sh) needs a running SDM Server


Another special instance is the one that installed the SDM (Software Deployment Manager). This one usually runs with the database and Central Services on the same machine and is then indicated as the central instance. The Software Deployment Manager (SDM) is a tool with which you can manage and deploy software packages that you receive from SAP or created with NetWeaver Developer Studio. The Software Deployment Manager (SDM) groups several different deployment types in a single network interface for the deployment of any software that you develop with the SAP NetWeaver Developer Studio. In all modes SDM is only able to handle one access at a time.

14

Java Cluster Architecture J2EE Startup Framework

15

J2EE Startup Framework – Overview

The J2EE Startup and Control Framework … is an infrastructure, situated between the operating system and the Java VM … is used to start, stop, and monitor a Java Instance … loads the JVM and restarts processes, which have died/crashed … comprises the programs Jcontrol, Jlaunch and Jcmon


The Java startup and control framework comprises the programs JControl and Jlaunch. JLaunch is started by JControl and itself starts the bootstrap Java program or an element of the Java Instance (dispatcher or server process). Whereas the Jcmon is a command line monitor program and is used to administrate the framework. Java startup and control framework is used to start, monitor, and stop a Java instance:

Integration of Java Processes into the SAP instance concept Inherit all management concepts from the ABAP stack Integration into existing SAP instance management Control and Restart functionality of J2EE processes (Watchdog) Daemons for NT (sapserv.exe) Remote Control of all J2EE instances in the cluster Cluster wide management (shutdown, restart ...) Integration of the Startup Framework Client into the IDE Preparation of Remote Debugging Support

16

Starting and Stopping

The Java startup and control framework is called in different ways according to the operating system and the installation type: Under Windows the SAP Management Console is used. If you choose an instance containing a J2EE engine Action → Start, the JControl program is called. Under UNIX platforms and OS/400 the scripts startsap and stopsap are used, which call the program.


17

Start and Stop with SAPMMC (Windows)

J2EE Engine System ID = C11

Database Central Services:

Start/Stop with Context Menu

Process List with State sign

Process Table with detailed info

Message Server Enqueue Server

J2EE Instance: Dispatcher Server 0...n SDM


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 system after the installation. You can use also the SAP NetWeaver Developer Studio when in development 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) J2EE instances Software Deployment Manager (SDM)

18

Starting and Stopping with scripts (UNIX & Windows) Starting the SAP System startsap [db|r3|j2ee|ccms|all|check] [] []

Examples startsap - to start the whole system startsap j2ee DVEBMGS00 - to start the J2EE-Engine of the instance DVEBMGS00. The instance name is required if more than one instance is configured. startsap r3 - to start only the ABAP part of the system

Stopping the SAP System stopsap [db|r3|j2ee|ccms|all|check] [] []

Examples stopsap - to stop the whole system stopsap j2ee DVEBMGS00 - to stop the J2EE-Engine of the instance DVEBMGS00. The instance name is required if more than one instance is configured. stopsap r3 - to stop only the ABAP part of the system


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 adm. If there are multiple SAP instances on one host – for example, a central instance and a dialog instance you have to add an extra parameter to the scripts: startsap ; stopsap For example, enter: startsap DVEBMGS00 SAP Web AS J2EE only system: The instance name (instance ID) of the central instance is JC, the instance name of a J2EE dialog instance is J. To view all the processes use command:

ps -ef | grep jlaunch

19

Starting the SAP Web AS Java with the ABAP System

Open RZ10 and choose the profile of your SAP Web AS.

Double click the parameter rdisp/j2ee_start Set the parameter value to 1 Go back to the parameter maintainance. Check the paths to the startup framework, e.g. exe/j2ee, exe/jlaunch, jstartup/instance_properties © SAP AG 2004, Web AS Java Installation and Upgrade

You can manage the Java Engine from the SAP Web AS ABAP, however the Java Engine it is not started automatically. 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 specific number of attempts to start the server failed (rdisp/j2ee_error). Profile parameter within the J2EE Engine in transaction RZ11: icm/HTTP/j2ee_

Determines the ICM’s communication with the J2EE Engine.

Exe/j2ee

full path to JControl

rdisp/j2ee_error before the restart is deactivated.

Number of incorrect attempts to start a J2EE Engine

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 runtime environment has been fully initialized. This avoids problems that are caused by a long initialization phase. 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.

20

Start/Stop of Java Engine processes in ICM Monitor

SMICM


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 initial screen. The following functions are available: Sending a Soft Shutdown (With or Without a Restart): z The (ABAP) dispatcher of the SAP Web Application Server sets the restart flag for the J2EE Engine and sends the SOFTSHUTDOWN message to the J2EE Engine. The dispatcher does not actively close the connection, the J2EE Engine must close itself instead. If the application server is restarted, the J2EE Engine is restarted by the dispatcher. Sending a Hard Shutdown (With or Without a Restart): z The (ABAP) dispatcher of the SAP Web Application Server sets the restart flag for the J2EE Engine and sends the HARDTSHUTDOWN message to the J2EE Engine. The dispatcher does not actively close the connection, the J2EE Engine must close itself instead. If the application server is restarted, the J2EE Engine is restarted by the (ABAP) dispatcher. Ending the Process (With or Without a Restart): z The SAP Web Application Server’s dispatcher sets the restart flag for the J2EE Engine and sends a signal to the process (shell or Java process). If the application server is restarted, the J2EE Engine is restarted by the dispatcher. Restart Yes/No z This sets the J2EE Engine’s restart flag.

21

JCMon – Monitor Program Command line tool Overview about the instance and process state Local administration menu for the local instance and their processes Cluster administration menu for remote operations -----------------------------------------------------------SAP System Name : C11 SAP System : 00 MS Host : pcj2ee01 MS Port : 3601 Process Count : 4 PID of JControl : 7244 State of JControl : All processes running State inside MS : All processes running Admin URL : -----------------------------------------------------------|Idx|Name |PID |State |Error|Restart| |---|--------------------|--------|--------------------|-----|-------| | 0|server0 | 5784|Running | 0|yes | | 1|server1 | 2216|Running | 0|yes | | 2|dispatcher | 4748|Running | 0|yes | | 3|SDM | 436|Running | 0|yes | ------------------------------------------------------------


Jcmon is a J2EE instance monitor program. To start jcmon enter with the adm user jcmon pf=/usr/sap//sys/profile/__. Enter command ‘20’ to display the main menu.

22

JCMon – Command descriptions 0

Exit

11 Process list

1

Refresh list

12 Port list

2

Shutdown instance

13 Active debug session

3

Enable process

14 Deactivate debug session

4

Disable process

15 Increment trace level

5

Restart process

16 Decrement trace level

6

Enable bootstrapping on restart

17 Enable process restart

7

Disable bootstrapping on restart

8

Enable debugging

9

Disable debugging

18 Disable process restart 98 Synchronize instance properties 99 Extended process list on/off

10 Dump stack trace


These all the commands, which can be used to administrate the processes using the JCMon Monitoring tool.

23

SAP WebAS Java System 6.40 – SAP J2EE Details

startsap (UNIX) / SAP Service (Windows)

starts 1 instance of …

SAPOsCol Database Instance (if local) J2EE Message Server J2EE Enqueue Server JControl • Reads J2EE instance description from profile and instance.properties • Create SHM segment holding administrative instance data • Starts/Stops JVM hosting processes (JLaunch)

starts n instances of …

JLaunch (J2EE Dispatcher, J2EE Server, SDM)

SAP J2EE Startup Framework

• Reads process specific properties • Attach to SHM segment created by JControl • Parametrizes, loads and hosts JVM


Startsap and stopsap have to be launched by user 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 the JLaunch processes. JLaunch: Starts a Java program. It loads the JVM into its own address space and then represents the required cluster element. The program can receive notification from the JControl process via named pipes to stop the cluster element, and terminates, if the JControl stops running (fork emulation under Windows). Bootstrap: This JLaunch process synchronizes the binary data from the Java database with the local file system and creates a property file, which describes the configuration of the Java instance. Note 710663 shows the different modes configurable 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 adm user.

II.

Signal handling - JControl initializes the SAP signal handling to be able to handle signals received. Signal can be send via 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///j2ee/cluster/bootstrap The instance.property can be found under the folder: /usr/sap//< InstName >/j2ee/cluster

24

Architecture of SAP J2EE Startup Framework 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 file instance.property (3). The file instance.property contains the description and the arguments of the J2EE 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, which ends the JLaunch process, if the parent process, JControl, fails.

Creates JVM arguments and initializes hosting of the VM.

Loads the VM into its own process, initializes the VM and starts the Java cluster element. This executes the following steps:

Starts the “ offline“ configuration manager to read the properties for the Java Enterprise runtime from the database and to save them in various hash tables (6).

Stops the “offline“ configuration manager and starts the Enterprise Java runtime with the saved properties.

Starts the service framework and the services. 25

Stopping a Java Instance


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

26

JControl – Java Instance Controller


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 the JLaunch processes. JControl controls J2EE processes … is the master process of all J2EE worker processes controls the lifecycle of the J2EE instance z Restart of crashed processed z Termination of hanging processes z 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

27

JLaunch – Java Program Launcher

JLaunch has following tasks: Read the properties of the program to host Read the VM properties from the database during startup process Attach to the administration shared memory segment Load the shared library of the Java VM


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 notification from the JControl process via named pipes to stop the cluster element, and terminates, if the JControl stops running (fork emulation under Windows).

28

How to check the correct startup using JCMon JCMON displays the server process in status “Running” only, if all applications have been started up successfully. If an application is still in the startup process, JCMON will describe the status as “Starting up”. SAPMMC has to change the server status from “RED” to “GREEN”.


Additional information in trace-files: 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, if status 3 is reached: JLaunchISetState: change state from 2 to 3

29

Troubleshooting and Support Most relevant information about startup of the different Java processes can be found in the jlaunch traces: dev_server

= Trace-file of the jlaunch process

std_server.out

= output of the JVM

jvm_server.out

= output of J2EE engine (like error.log and output.log in SAPJ2EE 6.20)

Trace files and JVM output files are in the work directory of the instance (e.g. /usr/sap///work) Low level process trace in the SAP developer trace files dev_* All processes are started with the SAP instance profile Single

point of management

Profile

parameters for the startup framework

Profile

directory /usr/sap//SYS/profile


Only 2 versions of the log files are kept representing the last 2 restarts. After the restart the new log files are stored, and the previous ones are renamed as .old. The previous .old files are lost.

30

Logfiles Startup J2EE Instance Work Directory: /usr/sap//JC/work dispatcher

Jcontrol

dev_dispatcher

dev_jcontrol bootstrap

std_dispatcher.out

dev_bootstrap

jvm_dispatcher.out

std_bootstrap.out

server

jvm_bootstrap.out

dev_server

dev_bootstrap

std_server.out

std_bootstrap.out

jvm_server,out

jvm_bootstrap.out SDM dev_sdm std_sdm.out jvm_sdm.out © SAP AG 2004, Web AS Java Installation and Upgrade

Log files: The important log files involved in the startup process. Most of the log files are located in the directory z Unix : /usr/sap//< INSTANCE_NAME >/work z Windows : c:\usr\sap\\< INSTANCE_NAME >\work Some of the sapstart logfiles are located in the home directory of the user directory The startup process has run correctly for the dispatcher and server instances if status 3 is reached z in dev_dispatcher : JLaunchISetState: change state from [Starting (2)] to [Running (3)] z in dev_server0 : JLaunchISetState: change state from [Starting applications (10)] to [Running (3)] Log files types: z dev*

Tracefile of Process

z std* Standardoutput z jvm* Messages of the Java VM

31

Developer Trace Files of the Startup Framework

dev_jcontrol – Trace file of JControl

Detailed property description

Description of the processes started by JControl

dev_bootstrap – Trace file of the initial bootstrap process dev_bootstrap_ID.... – Trace file of the node bootstrap process dev_dispatcher - Trace file of the J2EE dispatcher node dev_server - Trace files of the J2EE server nodes dev_sdm – Trace file of the SDM process


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///work folder.

32

Update of the Startup Framework I.

Shutdown the already running J2EE instances. 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 ”). Kill first the jcontrol process and afterwards the jlaunch processes, if there are such processes running. III. Copy the latest Startup Framework into the os_libs directory of the J2EE instance: I.

Unix: /usr/sap//< INSTANCE_NAME >/j2ee/os_libs

II. Windows: c:\usr\sap\\< INSTANCE_NAME > \j2ee\os_libs

IV. Cleanup the administration shared memory. Execute “jcontrol pf= -c” to invoke the shared memory cleanup. V. Start the J2EE instance. © SAP AG 2004, Web AS Java Installation and Upgrade

Execute the following steps to update the Startup Framework. Use SAPInst normally, only use this manual procedure in case of problems

33

Stack Trace Creation

Windows Start the SAP Management console Find the process you want to dump Open the context menu and choose ‘Dump Stack Trace’ The result is written to STDERR (c:\usr\sap\\\work\std_.out)

Unix Start the JCMon Find the pid of the j2ee process you want to dump (Command 11) Execute kill -3 You find the result in the file /usr/sap///work/std_.out


Execute these steps to perform stack trace.

34

Java Startup and Control Framework: Lesson Summary

You are now able to: z Startup & Stop the SAP Web AS Java. z Describe the bootstrapping procedure. z Locate and identify errors during server startup.


35




1


Lesson:

Java Engine Administration Tools


2

Java Engine Administration Tools

SAP AG

3

Web AS Administration Tools Overview: Topic Objectives

After completing this lesson, you will be able to: z Get an overview of all the Administrative tools around the J2EE Engine in the Web AS 6.40. z Explain the main purpose and restrictions of each tool. z Choose the right tool for the each task.


4

Administration Tools Overview System Info Web Page Visual Administrator Shell Console Administrator Config Tool Configuration Editor Deployment Tools Appendix

5

Administration and Configuration Options Administration and Configuration Needs Add, delete, configure additional server processes Configure pool sizes, thresholds, etc. VM settings Stop/Start services Deploy applications Performance recommendations Memory settings


Visual Administrator: Remote monitoring and management of managers, services, libraries, and interfaces of each element of an instance. GUI Config Tool: Offline configuration of the J2EE Engine cluster elements. Text-Only Config Tool: Offline configuration of the J2EE Engine cluster elements. Configuration Editor: Configuration of the current state of the Configuration Database. Shell console Administrator: Text based alternative to the Visual Administrator. Software Deployment Manager: Manage and deploy software packages. System Info Page: Overview of System Configuration and its state.

6

Administration Tools Comparison TOOL

MAIN FEATURES

UI

Conn.

J2EE ENGINE

REQ.

Visual Administrator

- Start/Stop and configure Services and Managers at runtime. -Start/Stop nodes. -Runtime administration of Services

Java GUI

Remote

Online ONLY

JVM

GUI Config Tool

- Add/Delete instance nodes. - Java memory settings. - Permanent configuration changes

Java GUI

Local

Online or Offline

JVM

Configuration Editor

Configuration of the current state of the Configuration Database.

Java GUI

Local

Offline ONLY

JVM

Shell console Administrator

- Start/Stop and configure Services and Managers. - Start/Stop nodes.

Text

Remote

Online ONLY

Telnet client

Software Deployment Manager

- Deploy/Undeploy SCA/SDA. - Manage Applications Repository

Java GUI

Remote

Online ONLY

JVM

System Info Page

- System/instance/Node properties info.

Web GUI

Remote

Online ONLY

Web Browser


The “J2EE Engine” column refers to the status of the server node while working with the tool. In same cases even an Online tool would have to restart the node so the changes take effect.

7

SAP J2EE Engine Ports SAP J2EE Engine Dispatcher ports default to 50000+100*instance_nr+port_index Index

Dispatcher Service

0

HTTP Port

1

HTTP SSL Port

2

IIOP Initial Context Port

3

IIOP SSL Port

4

P4 Port

5

P4 HTTP Tunneling Port

6

P4 SSL Port

7

IIOP Port

8

Telnet Port

9

Monitor Port

10

JMS Port


The following ports are used by the Administration tools: HTTP(S) Port is used by the Web Browser to access the System Info Web Page: P4 Port is used by the Visual Administrator to access the server P4 with SSL Port is used by the Visual Administrator to access the server securely P4 over HTTP(S) Port is used by the Visual Administrator to access the server through firewalls and proxies Telnet Port is used by the Telnet client to access the Telnet Service in the dispatcher node (default configuration)

8


9

System Information Web Page Database Info.

Java Message and Enqueue Server Host and Port number.

License Info.

Dispatcher node main ports

Node version Info.

SDM Server Info.


This is a good starting point to see a overview of the most important information of the SAP 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://:50000 -> System Information The VM Parameters link shows the Java Virtual Machine (JVM) settings for the selected node. This is the better place to see these settings for a running node.

10


11

Visual Administrator: Login on

Log in using a user name with administrator permissions Standard Login: User: Administrator Password: sap Host: or other P4 Port: default 50004


Connect → Login: Allows you to connect to the server. If there isn’t any connection created, you need to follow these 4 steps to log on to a SAP J2EE Engine: 1. Choose a name for the connection and a Lookup Method to use (via Message Server or Direct Connection to Dispatcher). 2. Configure and save the connection properties (user name, host, port, protocol…). 3. Select a connection from the list of previously configured entries. 4. Specify the password of the user and log on.

If a Connection has already been created just go to step 3.

12

Visual Administrator: Connecting via Message Service

Transport Layers Default: use Java RMI / P4 NI: SAP Network Interface Load Balancing Method Random: The Message Server will select a dispatcher randomly Manual: The Message Server will select a dispatcher manually © SAP AG 2004, Web AS Java Installation and Upgrade

Use this type of Connection if you like to balance your administration connections between the different server 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 a direct 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 message server of the Java Central Instance). 3. Choose a load balancing method for the connection – that is, whether the dispatcher to connect to will be selected 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 Remote Method 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 choosing Settings . 5. Choose Save.

13

Visual Administrator: Connecting to a Dispatcher

Transport Layers Default: use Java RMI / P4 SSL: Provides privacy over the Internet using cryptographic security HTTP Tunneling: Allows communication through proxies and firewall HTTPS: Using SSL with HTTP Tunneling NI: SAP Network Interface © SAP AG 2004, Web AS Java Installation and Upgrade

Use this type of Connection if you know the host name and port number of a running dispatcher and/or you want to use 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 and firewalls, using cryptographic security. If you use this layer, you have to specify the HTTP Tunneling proxy host and port by choosing Settings.

4.

To use the SSL or HTTPS layer you must have the Key Storage Service and SSL Provider Service running. To use 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 by choosing Settings. Choose Save.

14

Visual Administrator: Main Features Runtime/Properties/Additional Info Tabs Log in/out of the Visual Administrator Shutdown/Restart Node or Service System ABC Dispatcher Node Server Node

Information of the node selected

WINDOWS: :\usr\sap\\j2ee\admin\go.bat UNIX: /usr/sap//j2ee/admin/go © SAP AG 2004, Web AS Java Installation and Upgrade

SAP J2EE Engine Visual Administrator is a graphical user interface (GUI) that enables administration of the whole cluster, all cluster elements, and all modules running on them. It provides remote monitoring and management 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 so on) 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.

15

Visual Administrator: Accessing Local Configuration Runtime tab of the Class Loader Service Info tab of the Web Service Interface Additional Info tab of the HTTP Provider Service Properties tab of the HTTP Service

Dispatcher node components (Managers expanded)

Local Properties

Server node components (Services expanded)


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, JARs contained and a description. The Additional Info tab shows the name, version, references to other services and startup information of the selected service. The Properties tab shows, and let you edit, the static parameters of the selected service (to change a property 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). Interfaces and Libraries only show an Info tab.

16

Visual Administrator: Changing Properties Working on the Dispatcher 0 3.- Click on Save Cluster Tab

to commit changes on the node selected

Custom Values

Default Values

1.- Click on a property to edit its custom value

2.- Press Update when done editing


The J2EE Engine components have two types of properties: global and local. Global properties are common for all cluster elements while local properties are only valid for 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 with the 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 a specified 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 value exists, this is the actual value of the property, else the default value is used.

17

Visual Administrator: Accessing Global Configuration Working on the Global Configuration of a Dispatcher 3.- Click on Save to commit changes on all dispatcher nodes

1.- Click on a property to edit its custom value

2.- Press Update when done editing


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 local properties of the selected cluster elements only. 3. Choose Yes to save the changes (If you deselect all the cluster elements or just choose No, the changes made to the global properties will still be valid). The properties of the services and managers are formed by posting their local properties upon their global ones. The property priority is as follows: 1. global default – the lowest priority 2. global custom 3. local default 4. local custom – the highest priority

18

Administration Tools Overview System Info Web Page Visual Administrator Shell Console Administrator Config Tool Configuration Editor Deployment Tools

19

Shell Console Administrator telnet

Username and Password MAN without parameters list all available commands

ADD without parameters list all available command groups


The Console Administrator enables remote administration through Telnet clients. This function provides Telnet clients with a distributed, scalable Telnet server that supports remote shell administration using the Telnet protocol. Telnet administration function is implemented in SAP J2EE Engine using the Telnet Provider Service. By default, the Telnet shell is opened on the dispatcher. Once you are connected you can access and use all shell commands available on the different J2EE Engine cluster elements. Use the LSC command to display all server components with their ID, component name, host, port, and type. The first component displayed is the current one. To pass over from one component to another, use the JUMP command and specify the ID of the target element. 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 displays a short explanation of a command. The commands are grouped into a number of groups that can be activated and deactivated. You can obtain an overview of the groups with the command ADD. To activate a group of commands, enter the command ADD . 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. 20


21

Config Tool: Overview

The Config Tool enables offline configuration of the J2EE Engine cluster elements.

The Config Tool connects directly to database to apply the changes, thus it is not required to have a SAP J2EE Engine running. When you run the J2EE Engine Config Tool via a GUI or text-only interface, it connects to the database and scans the server configuration. The information provided is passed to the corresponding interface that is used for configuration. All modifications made using the J2EE Engine Config Tool can be exported to an XML file for later use.


22

Config Tool: Connecting Secure store file – contains the path to the secure store properties file. This file contains secure data for connecting to the database or visual administrator. It is encrypted for security reasons. Secure store key file – contains the path to the secure store key file. The key file contains the password for the encrypted store file. System name – displays the name of the system to which this data applies. Secure store lib – contains the path to the IAIK package. It enables the encrypting of the properties file. RDBMS connections – contains a property key of which the value contains the DB connection settings. RDBMS driver location – contains the path to the RDBMS driver. RDBMS initial connections. RDBMS maximum connections.


To start the tool use: usr/sap///j2ee/configtool or :\usr\sap\\\j2ee\configtool.bat The database is initialized and the connection to it is configured for the first time at installation. The installation procedure creates the tables in the database, copies all the necessary data to it, and sets the proper parameters for establishing a connection. You can configure a DB connection manually. If you want to switch to another database, you must make sure that the database has been properly initialized and 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 Enter the password for this user

3. Choose Load

23

Config Tool: Managers/Services Configuration Add/Remove instance nodes

Switch to Configuration Editor mode

Use the “Connect to DB” button to refresh the information Global Dispatcher and Global Servers Configuration All instances in the Web AS Java System Configure connection encryption and UME data © SAP AG 2004, Web AS Java Installation and Upgrade

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 and displayed 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 properties reflects to all cluster elements. The global properties include default and custom values. You cannot change the default values, you can set a new custom value and it will has a lower priority than the local values (default or custom) for this property. All instances listed Each instance contains one Java dispatcher and a specific number of server processes. Each node contains a list of managers and services. You can change them according to your needs. To delete the local values of a property, so the global values are taken, use the SET TO GLOBAL button. For more information on UME and LDAP configuration refer to the TADMJ8 course.

24

Config Tool: Creating/Deleting Server Nodes You can Add or delete Server nodes in an already created instance

To create new J2EE Engine instances you 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 new instances, thus, the Config Tool doesn’t allow to create any dispatcher node.

25

Config Tool: Instance Configuration


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 contained in 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, the Instance/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 process. 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.

26

Config Tool: Instance Configuration


Node tabs (see appendix for details) General: Startup Framework custom settings and Java custom settings of the node selected (same configuration options than the Servers General tab of the Instance properties). Bootstrap: Java settings of the Bootstrap process of this node. Log configuration: Logging and tracing configuration of this node (see TADMJ5 or the documentation 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 than the Servers Debug tab of the Instance properties) .

27


28

Configuration Manager The Configuration Manager enables Java Engine modules to access and store data from the Java Engine DB. It uses the Open SQL for Java to connect and work with the RDBMS. rdbms.connection

The name of the secured property entry where the database connection settings are stored.

rdbms.driverLocation

The location of the driver archive file in the file system.

rdbms.initial_connections

The database connections that are initially established and stored in a connection pool to be used by request

rdbms.maximum_connections

The maximum number of connections that can be established to the database simultaneously

secstorefs.keyfile

The location of the file that contains the secret key used for encryption of the data for the default database connection.

secstorefs.lib

The location of the libraries used by the J2EE Engine to encrypt the data.

secstorefs.secfile

The location of the file that contains the encrypted data for the default database connection

system.name

The name of the J2EE Engine system, such as C11.


The Configuration Manager is related to all J2EE Engine modules. In addition, there are services that store 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 are deployed on the server. Configuring a Database Connection The rdbms.maximum_connections property defines how many connections can be established to the database at a time. These connections are used by the Configuration Manager to access the underlying database. If you set a small number of connections such as one, some of the services will have 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 the cluster elements to the same database. Server and dispatcher nodes do not need the same number of initial and maximum connections, but they must access the same When connecting to the database, the J2EE Engine as well as the applications deployed on it authenticate 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 is initialized with the supplied credentials and uses them for the authentication of all physical connections that it provides. The user name and password for the default DataSource are stored encrypted in a secure store. The parameters for this secure store are the following properties of the Configuration Manager: secstorefs.keyfile secstorefs.lib secstorefs.secfile 29

Configuration Adapter Service This component enables you to manage the Configuration Manager and the configuration objects in the database. It uses the interfaces that the Configuration Manager provides, enabling you to access and modify configurations. The Configuration Adapter Service provides the following means for administration: Graphical user interface (GUI)

The GUI part of the service is available in the Visual Administrator and in the Configuration Editor tool for offline editing.

Shell commands

The service is running both on Java dispatcher and on server processes.


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 the structure and its substructures as well as the configuration objects themselves directly in the database using the means provided by the Configuration Adapter Service.

The Service Manager communicates with the Configuration Manager to enable storage of configuration data about the services.

30

Configuration Editor: Main Functionality Online/Offline access to the Configuration Database. Configuration

All J2EE Engine nodes must be offline.

Property Sheet

File entry containing a Binary file

Can be started by: •Visual admin: •Config Tool: •UNIX script: •Windows script:

Configuration Adapter Service of the Server nodes. Switch to Configuration mode button. /usr/sap//JC/j2ee/configtool :\usr\sap\\JC\j2ee\configtool.bat


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 Configuration Adapter 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 suspected missing or corrupted configurations) deleting/changing/updating configuration entries (to be used carefully)

The shell commands in the CONFIGURATION group enable you to view details about configurations and locks.

31

Configuration Editor: changing the configuration

Right-click to edit the Configurations

Double-click to edit the Property Sheet


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 this properties are situated in the following configuration Propertysheets (this Propertysheets can be seen using the Configuration Adapter Service): 1.

2.

Dispatcher elements: a.

for managers: cluster_data/dispatcher/cfg/kernel/

b.

for services: cluster_data/dispatcher/cfg/services/

Server elements: a.

for managers: cluster_data/server/cfg/kernel/

b.

for services: cluster_data/server/cfg/services/

32


33

Deployment Overview IDE

• 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.

DB Schema Data

DB Schema Deploy Tool

DB Content

J2EE App

DB Content Deploy Tool

J2EE Engine Deploy Tool

Filesystem Content

Filesystem Content Deploy Tool

J2EE Server

Database

Filesystem


The word deploy has roots as a military term, used to describe the placement of equipment and troops in a battlefield. As a J2EE term, is the final step in the software delivery process; it’s used to describe the process (automatic or manual) of placing the files and other resources in the correct runtime repository (Database, File system, J2EE system) and assuring that all the information the J2EE Server needs to run the application is available. The information the Deploy tool needs to deploy an application is contained in an XML file called Deployment Descriptor (DD) The standard deployment API included in the J2EE specification is described in http://www.jcp.org/en/jsr/detail?id=88 (see the appendix for more information of the J2EE standard deployment process).

34

Deployment Tools Overview Various deployment scenarios require different ways to perform the deployment tasks. The following 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


• The Deploy Tool is another solution suitable for generating, assembling and deploying J2EE applications and application components. • It was the only deployment tool on WAS 6.20 but on Web AS 6.40 The software Deployment Manager is recommended. • It will not be supported on NetWeaver’05

35

Deployment: SDM Overview

IDE

IDE

DB Schema Data

DB Content

J2EE App

Filesystem Content DB Schema Data

DB Content

J2EE App

DB Schema Data SDA DB Content SDA

DB Schema Deploy Tool

DB Content Deploy Tool

J2EE Engine Deploy Tool

Filesystem Content Deploy Tool

Software Deployment Manager

J2EE Server

J2EE Server

Database

FilesystemContent

J2EE App SDA Filesystem Content SDA

Database

Filesystem

Filesystem


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 of different content types by providing a unique deployment interface for all these types and by using a standardized delivery/transport format. SDM serves as a single access point for SAP tools like CMS, IDE, SAPINST which need to deploy content into different runtime systems.

36

SDM: Software Components

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 deployable parts of a Software Component

Support Packages and products are concepts put on top of the component model.


Software Deployment Archive (SDA): The Software Deployment Archive (SDA) is the delivery format for SAP applications in programming languages other than ABAP. An SDA is the smallest unit that you can deploy. Furthermore, the SDA is the smallest unit for which patches can be created and delivered. Software Component Archive (SCA): A Software Component Archive (SCA) is the physical representation of a version of a software component. It contains a specific number of SDAs, whose quantity describes a precisely-defined version level. An SCA update always results in a new version level of the software component.

Refer to the course TADMJ8 “Java Development Infrastructure Administration” or to the online help: Architecture Manual -> SAP NetWeaver Java development Infrastructure -> Component Model for more information about the Component Model.

37

SDM: Files and Components


SDA It is an archive format that is compatible with ZIP and that can be used as a container 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 other things, 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 an SAP manifest, it is also an SDA. The SDM recognizes the EAR archive as an SDA, but does not rename the archive extension as .sda. Larger entities can be created in SCA format in the second step from the different SDAs.

38

SDM: Operation Modes SDM Server Server handles requests sent by a SDM Client Lib or a SDM Remote GUI Simple Web Server to browse log files written by SDM

Remote GUI Requires a running SDM Server Swing based (as of SP3 using frog Look and Feel)

Command line interface A new SDM process is started each time a command is executed No SDM Server may run at the same time (this is checked)

Java Client API Requires a running SDM Server Delivered as one jar: SDMClient.jar (and one required jar: Net.jar) Very lightweight implementation (using generic Proxy-mechanism)

IN ALL OPERATIONS MODES SDM IS ABLE TO HANDLE ONE ACCESS AT A TIME


The Command line interface is used by SAPInst The command line interface is found in: /usr/sap///SDM/program/sdm.sh :\usr\sap\\\SDM/program/sdm.

The Java Client API is used by the IDE and CMS SDM can also work in Auto install / update Mode, this means that the software delivered 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

39

SDM: starting and stopping the SDM server

SDM Integrated Server on windows Java only instance: Right click to Enable/Disable Server SDM Integrated Server on UNIX (or windows): StartServer.sh and StopServer.sh StartServer.bat and StopServer.bat To exclude SDM of the Java Startup Framework: 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 Java Startup framework of the SAP J2EE Engine, which means that it is started and stopped automatically with the Engine. Situations can arise in which you need to start and stop the SDM independently of the SAP J2EE Engine. For example, for security reasons, you may want to run the SDM during the current deployment only. SDM Server can also run in an standalone mode with the help of the command line interface (sdm.bat for Windows or sdm.sh for UNIX). Remember that, in standalone mode, the SDM is no longer started and stopped automatically with the SAP J2EE Engine. You can then only use the command line to control the SDM (for more information, see the file SDM_Commandline_en_final.pdf in the directory /doc).

40

SDM: connecting with the Remote GUI Start \\SDM\program\SDMserver.bat and …\remoteGUI.bat Choose Connect

and login with the standard password “SDM” and port 50018.


When exiting the SDM, you have the option of choosing Logout to disconnect the SDM GUI, or Shutdown SDM Server and Exit to shut down both the SDM GUI and the SDM Server. The Exit option will close the SDM GUI.

41

SDM GUI: Repository by Target System Showing Repository contents grouped by Target Systems

Information on Target System SAPJ2EEEngine

Component Model Information

Possible Deployment types for this Target System © SAP AG 2004, Web AS Java Installation and Upgrade

When deploying SDAs/SCAs, the Software Deployment Manager stores the data in the SDM Repository, where it then manages the installed archives. The SDM recognizes dependencies between archives and provides support when you install and maintain shared applications A Target System represents a physical runtime system in conjunction with its deployment relevant configuration. The following target systems are possible: File system, Database or SAP J2EE Engine.

The SDM Repository tab on the initial screen gives you an overview of the installed target systems and the archives they contain. When you expand the target systems node, you see the SCAs and SDAs that are assigned to the corresponding target systems. Expanding and SCA you see all the SDAs contained in it.

42 The following tab pages appear in the right screen when you select a target system:

Information: This tab page shows information about the selected target system and

SDM GUI: Repository by Archive Showing Repository contents grouped by Archive

Right click to see more information

Component Model Information SDA (DC) dependencies


Each SDA is assigned a Software Type which is declared within the SDA-DD inside the SDA – the Software Type determines the kind of deployment which is executed for the SDA Software Types: DBSC: Database content JDDSCHEMA: Database schema objects J2EE: J2EE applications (Servlet, JSP, EJB, ...) engine-bootstrap, engine-kernel, primary-service, primary-library, primaryinterface: engine components to be deployed offline library single-module: rar archive for standalone deployment connector FS: File system content

43

SDM GUI: Repository. Configuration Substitution Variables

Ports in used by the SDM Server

Connection with the SLD for version updating


The Configuration tab shows information about the current settings of the SDM server The Substitution Variables tab shows the catalog of Deploy time Substitution Variables that SDM understands. Deploy time Substitution Variables can be referenced by name inside the SDA Deployment descriptor. To distinguish a parameter reference from a fixed string the Deploy time Substitution Variables has to be enclosed in a pair of start and stop delimiters "${" and "}". Substitution Variables can be used for file system and engine deployment.

44

SDM GUI: Deployment 1 .- Select the Archives from the file system

2.- Choose archives to be deployed

3.- Information of Target System

4.- Confirms finished deployment 3.- Starts deployment © SAP AG 2004, Web AS Java Installation and Upgrade

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. To delete 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 the data in the archive list. The Repository Preview shows how the SDAs are distributed in the 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 successfully performed are not repeated.

4. A success message appears at the end of the deployment process. Choose Confirm to confirm the deployment You can always go back during the deployment steps

45

SDM GUI: Deployment settings

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 been completed 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 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 been completed 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 until the end.

46

SDM GUI: Undeployment

1.- select the SDAs to undeploy and press Start Undeployment

2.- Confirm when finish successfully


Your SAP J2EE Engine contains SDAs of applications that you can select to be undeployed. You can only undeploy applications that do not have dependencies on other SDAs.

47

SDM GUI: Log Viewer Choose between Server/GUI or other log

Here you can see a deployment of an SDA (Encyclopaedia_Pages_DDIC) with DB content (table PAGES)


You use the Log Viewer tab to display the log for the SDM work steps. You can also Choose Other Log to display other logs created by the SDM. You can choose from the following logs: sdm_server.out: Server output to Stdout sdm_server.err: Server output to Stderr sdm_remotegui.out: GUI output to Stdout sdm_remotegui.err: GUI output to Stderr sdmlogYYYYMMDD.log: SDM log created by SDM Server sdmguiYYYYMMDD.log: GUI log created by SDM Server sdmclYYYYMMDDHHMMSS.log: Client session log. For example, deployment with SAP NetWeaver Developer Studio. jddilogYYYYMMDDHHMMSS.log: Log of a JDDI deployment. The content of this log is also included in sdmlog. The logs are all located under /log. 48

Deploy Service The Deploy Service manages the deployment of J2EE applications and the distribution of their modules to the corresponding containers across the cluster. It controls all actions that can be performed on applications during their lifecycle, such as requesting containers for information about deployed applications and their modules, or initiating a demand to modify them. It also ensures that all deployed applications in the cluster are homogeneous and up-todate. The Deploy Service runs only on server processes.


49

Deploy Service Runtime


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 your applications. As a response to your actions in the runtime management, the Deploy service performs deployment operations. They change the application status of the targeted applications.

Go to the documentation for more information of the Deploy Service (Administration Manual -> Server Administration -> SAP J2EE Engine Administration -> Deploy Service)

50


51

Shell Console Commands Servers Configuration Configuration Manager J2EE Deployment

52

Shell Console: Important Commands 1 z

MAN [Command]

Dexcription: Provides help on a command. If no parameters are specified, it shows all available commands z

LSC [-state]

Description: Lists all active cluster machines z

JUMP [ClusterID]

Description: Jump to the specified Cluster element z

STARTSERVICE [ClusterID]

Description: Starts a service on the specified cluster element z

STOPSERVICE [ClusterID]

Description: Stops a service on the specified cluster element z

RESUME[-status]

Description: Resumes a cluster element. If no parameters are specified, the current status is shown z

SUSPEND [-status]

Description: Suspends a cluster element. If no parameters are specified, it shows the current status z

SHUTDOWN [-mark ] [ClusterID]

Description: Shuts down a cluster element or the whole cluster


53

Shell Console: Important Commands 2 z

LSM [ClusterID]

Description : Lists all managers running on the specified cluster element z

LISTMP [clusterID]

Description : Lists the properties of the specified manager z

SETMP <[[-f ] [-f ]...] [[-p ] [-p ]...]> [clusterID]

Description : Loads the new property values for the specified manager z

LSS [-d] [ClusterID]

Description : Lists all services installed on the specified cluster element z

LISTSP [clusterID]

Description : Lists the properties of the specified Service z

SETSP <[[-f ] [-f ]...] [[-p ] [-p ]...]> [clusterID]

Description : Loads new property values for the specified service.


54


55

Detail Servers configuration 1/3


Message Service & Bootstrap Tab View or edit the message server host and port Message server host Message server port

view or edit the Java settings of the Instance Bootstrap process Max heap size – The maximum size of heap memory used by the JVM Java parameters – Contains additional parameters to be passed to the JVM. By default, no additional Java parameters are available Classpath – Holds the classpath to the bootstrap launcher file for a particular cluster element Parameters – Specifies additional Java parameters that will be appended to the existing Java parameters

56



Servers General Tab Startup Framework default settings of every Server node created in this instance: Execute – specifies whether the selected cluster element is executable. Show console – to see the console for starting a server process

Java default settings of every Server node created in this instance: Max heap size – The maximum size of heap memory used by the JVM Java parameters – Contains additional parameters to be passed to the JVM. By default, no additional Java parameters are available Classpath – Holds the classpath to the bootstrap launcher file for a particular cluster element Parameters – Specifies additional Java parameters that will be appended to the existing Java parameters

57



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. By default, it is set to 33561

58


59

General Configuration Manager Architecture Central Infrastructure

ConfigChangedEvent R

R

Other cluster nodes

Enqueue Server

R

Cache Invalidation Event R

Message Server

Configuration Handler

R

Hierachy Lock

getConfigurationForRead(...) getConfigurationForWrite(...) releaseConfiguration(...) commitModifications()

R

open / close configuration

Configuration Cache readData(...)

R

R

R

getDelta()

Read Access Configuration

Write Access Configuration

Modifications

open configurations of Configuration Handler R

Read & BatchUpdate R

Persistency Handler

R

RDBMS

Open SQL Configuration Manager one cluster node


Configuration Manager Main functionality: Provides an Infrastructure for global (cluster wide) hierarchical storage for configuration data Cluster wide change event notification Provides transactional access 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

60

Central Cluster Configuration Cluster Admin R

Cluster Configuration Tool Offline ConfigurationManager

Bootstrap Settings

Bootstrap Binaries

R

BootStrap

JControl

instance.properties

Config Manager

R

DB

Cluster_data Binaries Global settings Instances Host 1 Settings cluster node 1 Settings cluster node n

Binaries Server/ Dispatcher Process

Host n Cluster Node Settings

Instance Host1 Installed by SAPInst © SAP AG 2004, Web AS Java Installation and Upgrade

61


62

J2EE Deployment 1/4 Development Bean developer

IDE Archive (.jar)

Assembly

Deployment

Application Assembler Archive (.ear)

System administrator

Deployer

Deployment tools

AdminTools

Archive (.jar) Service

Archive (.war)

Web Container EJB Container J2EE Server

EJB components (Enterprise Bean)

Server Provider Container Provider

Web components (e.g. Servlet, JSP etc.) © SAP AG 2004, Web AS Java Installation and Upgrade

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 their components as jar-archive files, which contain meta data in an XML file (deployment descriptor) in addition to the compiled classes and interfaces. Component features and their requirements of the (as yet unknown) runtime environment are contained in a declarative format. Application Application assemblers use the components provided for a specific application by combining several components as larger conglomerates. They have the option of adding additional Java beans here. The overall archive created here is also known as a Deployment Unit or EJB Module.

assembler

Deployer

Deployers are experts for a specific system environment and are familiar with the server and container products used. They use deployment tools to integrate the deployment unit in the server.

Container Provider

Container providers provide the specialist tools for the respective container and server.

System Admin

The system administrator is responsible for the infrastructure required to operate the server, configures and binds the system services and resources required and uses tools provided by the Container Provider here.

63

J2EE Deployment 2/4 Enterprise Java Beans contain business logic or represent data from a database. Development

Assembly

Deployment

Bean developer

IDE Archive (.jar)

Archive (.jar)

Archive (.war)


Separation of Business Logic and Platform J2EE 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 for a J2EE Server). EJBs communicate with the container for the application server via standard interfaces and are therefore platform-independent. Enterprise Java Beans EJBs are the smallest components within the EJB architecture. This means that they can only be forwarded or exchanged as a total unit. An additional significant characteristic here is 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 bean developer uses the corresponding entries in the deployment descriptors to determine whether they can use the runtime logic for the container. Bean developers can also implement the runtime logic themselves.

64

J2EE Deployment 1/4 Runtime logic such as transaction control or security checks is requested via entries in deployment descriptors. Development

Assembly

Deployment

Application Assembler

Bean developer

IDE

Archive (.ear)

Archive (.jar)

Archive (.jar)

Archive (.war)

web.xml

ejb-jar.xml

application.xml

Each archive contains a deployment descriptor (XML format). © SAP AG 2004, Web AS Java Installation and Upgrade

WAR/JAR/EAR: Declarative Specification by Deployment Descriptors A series of formats in which the compiled form of J2EE applications (class-files, JSP, HTML files, pictures etc) are packed, have been defined for J2EE so that these can be installed on an application server for execution. EJB-JAR All (auxiliary) classes and interfaces for EJB are saved here with a standardized XML 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 Deployment Descriptor is also available here. EAR JAR and WAR files are bundled ("assembly") as a J2EE total application in J2EE E(nterprise) AR(chive) files.

65

J2EE Deployment 4/4 Deployment descriptors contain information on how components are installed on the respective application server (declarative specification). Deployment EJB Verifier Container Compiler Remote Compiler EAR file

Deployer

Deployment tools

Entries in the DD are used to generate additional classes

Remote Object 1 2 3 4 5 6 7 8 9

. . . public String doSomething() { // authentificate user // start transaction String s = bean.doSomething(); // stop transaction return s; } . . .

Web Container EJB Container


Deployment This work step has not been standardized in the J2EE Specification. Each container product has its own solution here. During deployment of an EJB Jar file, the following steps are usually executed by the container: The system checks whether components in the EJB Jar file adhere to the rules in the EJB specification. 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 the deployment 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.

66

Web AS Administration Tools Overview: Topic Summary

You should now be able to: z Start/Stop the Visual Admin, Config Tool, SDM, Shell console and Configuration Editor z Change the configuration of the J2EE server using the Visual Admin. Config Tool, and Shell Console. z Offline configuration of the J2EE Engine with the Configuration Editor z Mange the J2EE Engine Repository with the SDM z Do (Un-)Deployments with the SDM


67

SAP Java Engine Administration – Exercises and Solutions Unit: Web AS Java Administration Tools Overview. Lesson: Exercise – Work with Web AS Java Administration Tools. At the conclusion of this exercise, you will be able to: • Start the Visual Administrator • Log on to the Visual Administrator Use a tool to manage online the J2EE Engine

SIDNumber 0 for DEV, 1 for QAS Sysnr.: 00, 01 for DEV; 10, 11 for QAS ABAPInstance: D, DVEBMGS Visual Administrator 1-1

Start the Visual Administrator Tool. 1-1-1 Double click on G:\usr\sap\\DVEBMGS\j2ee\admin\go.bat

1-2

Create a new Connection 1-2-1 Choose New in the pop-up window Connect to SAP J2EE Engine Field Name

Value

Display name

J2EE_Admin by Dispatcher

Lookup method

Connection to a dispatcher node

1-2-2 Choose Next 1

Field Name

Value

Username

J2EE_Admin

Host

localhost

Port

50004 for DEV 51004 for QAS

Transport Layer

Default

1-2-3 Choose Save 1-3

Log on as Administrator 1-3-1 Double click on the J2EE_Admin entry. 1-3-2 Enter the password (enjoy) 1-3-3 Click on Connect

1-4

Which are the ID numbers of the instances and nodes in your system and with which ABAP instance are they related? 1-5-1 Select the node in the left tree and you will see and Info tab with information on the node on the right panel. 1-5-2 Open the JControl trace file at: G:\usr\\\work\dev_jcontrol Find the Worker nodes section to find the nodes associated with that particular ABAP instance ABAP Instance

DVEBMGS

37030

D

Node Type

Dispatcher

3703000

Server

3703050

Dispatcher

15769700

Server

15769750

157697

For the rest of the exercise use the Java Instance associated with the central ABAP Instance. 1-4

List all the Managers that are not in the Dispatcher and Server nodes ApplicationThread Manager is only in Server nodes ConnectionsManipulator is only Dispatcher nodes 2

1-5

Find information about these managers 1-5-1 Go to http://help.sap.com → Search Documentation on Area SAP NetWeaver, Application SAP NetWeaver, Release 04 1-5-2 Enter “ApplicationThread” → Narrow by BACKGROUND Info-Class and Select “ApplicationThread Manger” 1-5-3 This manager supplies the threads in which client applications’ source code is executed. It provides a set of properties for starting and managing client threads in the Java Virtual Machine. This manager runs on servers only. 1-5-4 In the left hand side tree, under click on the Connections Manipulator Manager” 1-5-6 This manager is responsible for managing client connections to the cluster. It provides a set of properties for managing the pools where the TCP connection objects are stored. The Connections Manipulator Manager runs on dispatchers only

3

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 SAPDB (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 for QAS 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://:50000 for DEV http://: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: G:\usr\sap\\\work\dev_dispatcher Look for “Telnet Port”.

4

Shell Console 2-1

Log on to the Shell Console with an administrator user 2-1-1 execute in a command prompt telnet where is 50088 for DEV and 51088 for QAS. 2-1-3 Log on with Administrator and password provided by your instructor

2-2

Which commands are available? 2-2-1 Type MAN to see the available commands and commands groups: ADMIN, SYSTEM and TELNET

2-3

List all active Cluster Elements. 2-3-1 use the LSC to get and overview of the nodes in the current instance Node

ID

Dispatcher

00

Server

50

Dispatcher

00

Server

50

2-4 Use the GET_FREE_CONN command of the DBPOOL group of the server node to find the free available DB connections of the DB pool. 2-4-1 Jump to the Server node of the J2EE Engine: JUMP 2-4-2 Add the DBPOOL commands group: ADD DBPOOL 2-4-3 Ask for the free connections of the DB pool : GET_FREE_CONN SAPDB (you can also use GET_DS to get the available datasources)

5

Config Tool 3-1

Connect to the default database with the Config Tool 3-1-1 Start the config tool on the server: G:\usr\sap\\ DVEBMGS\\j2ee\configtool\configtool.bat 3-1-2 Once the tool is started you are already connected to the default database

3-2

Check the Local and Global custom/default properties of the Dispatcher Telnet Service. 3-2-1 Click on the Telnet Provider service of your instance dispatcher.

3-3

Property

Values

Global custom

blank

Global default

2323

Local custom

50088 for DEV, 51088 for QAS

Local default

50008 for DEV, 51008 for QAS

Change the Telnet port of every dispatcher of every instance of the system to 50089 for DEV or 51089 for QAS. 3-3-1 Click on the Telnet Provider service of one dispatcher of your System (. 3-3-2 Select the Local property Port and click on Restore to Global 3-3-3 Click on the Telnet Provider service of the global dispatcher. 3-3-4 Select the Port property and edit its value to 50089 for DEV or 51089 for QAS. 3-3-5 Press SET then APPLY CHANGES and confirm the information popup. 3-3-6 Go the Visual Administrator, check that the Telnet Port value of the appropiate Dispatcher hasn’t change yet, and Restart the Dispatcher node. 3-3-7 After the restart of the Dispatcher check the Telnet port is 50089 for DEV or 51089 for QAS.

6

3-4

Check the Local and Global custom/default properties of the Telnet Service of the Dispatcher node in the Config Tool. 3-4-1 Click on the Telnet Provider service of the instance dispatcher. Property

Values

Global custom

50089 50089 for DEV or 51089 for QAS.

3-5

Global default

2323

Local custom

Blank

Local default

Blank

Modify the Max Heap Size of the JVM of any server node in your Java instance 3-5-1 Go to the Servers General tab of your instance, increase the Max heap size (in MB) value to 333. 3-5-2 Click Apply Changes and confirm both information pop ups (do not restart the instance yet)

3-6

Add a new node. Write down the new node ID, the name of the node and the path associated with the binary files. Finally check the existence of the new node 3-6-1 Select your instance in the right tree of the config tool (or one of its components) and click on the Add Server button 3-6-2 Confirm the information pop-up 3-6-3 The log pop-up shows the information asked: Property

Values

Name

Server 1 0_

Node ID

51

Path

G:\usr\sap\DEV\DVEj2ee\server1

3-6-5 Apply Changes and Restart the instance. 3-6-6 To check the existence of the new node, check the System Info page. 3-7

What’s the Max Heap size of each server node? 3-7-1 You can read it in the Config tool, General tab of the selected node. Or looking for the –XMx parameter in the JVM propertoes of the System Info Page:

7

Node ID

Max Heap Size

50

333 Mb

51

333 Mb

8

Offline Configuration Editor 4-1

Start the config tool in the server box. 4-1-1 You can start it directly with a script: G:\usr\sap\\JC00\j2ee\configtool\offlinecfgeditor.bat 4-1-2 Or from the Config Tool: Switch to Configuration Editor button. 4-1-3 Or from the Configuration Adapter service in the Visual Administrator

4-2

Write down the Global/Local custom/default values for the Port property of the Dispatcher Telnet Service and the path of the PropertySheet that contains it. Try with the instance you have been working during the previous exercises and with the instance that you haven’t used. For example if you have been only using the Java instance associated with the Central Abap Instance of the DEV System (Java instance number 3703000) you should find the following Property Sheetes and values:

Editor Path

Property

Values

Cluster_data/dispatcher/

Global custom

50089

cfg/services/PropertySheet telnet

Global default

2323

Cluster_data/dispatcher/

Local custom

50108

ID15769700/services/PropertySheet telnet

Local default

2323

SDM GUI 5-1

Verify that the SDM Server is running 5-1-1 In the Web info page 5-1-2 Connecting to the http port of the SDM Server: http://hostname:50019

5-2

Start the SDM GUI: 5-2-1 Execute: G:\usr\sap\\JC00\j2ee\SDM\program\RemoteGUI.bat

5-3

Connect to the SDM Server 5-3-1 Click on the Connect to the SDM Server button 5-3-2 Use the password provided by your instructor (sdm) 5-3-3 Use the standard port 50018 9

5-4

What’s the Port number for Admin-Communication? 5-4-1 In the Repository Æ Configuration you’ll find an entry showing 50017 for DEV and 510017 for QAS as the Admin port.

5-5

Add the CustomerEAR.ear archive in N:\setup\ATP_Web_AS_6.40_TC_Track\TADMJ1\WAS_Admin_Tools to the deployment list and find information about the vendor and the software type of the application. 5-5-1 Go to the deployment tab. 5-5-2 Select Hello.ear file provided by your instructor. 5-5-3 Add an archive to the list with the Add SCD/SDA to the Deployment list (Local file Browser). 5-5-4 You can right click of the SDA to be deployed to find out that the vendor is sap.com and that the software type is J2EE (it will be deployed against the J2EE Target System)

5-5

Deploy the CustomerEAR application, but be sure that it stops if an error occurred. 5-5-1 Check the settings option:

5-5-2 Choose Next to Go to step 2/4. 5-5-3 Choose Next to go to step ¾ 5-5-4 The SDA is ready for deploy 5-5-5 Choose Next to start. 5-5-6 Confirm after the deployment is finish correctly

5-6

Did the deployment switch off the J2EE engine after the deployment? 5-6-1 In the Log tab you’ll find the information. The SDM Server didn’t change the previous status of the J2EE Engine. So if the engine was online it should be still online. (In some cases the deployment has to be done with the Engine offline, so the SDM Server might need to change the state of the J2EE Engine).

5-7

Execute the application. 5-7-1 open the following URL: http://:/Hello 10

Unit 4: SAP Java Administration Lesson 2: Configure different system services Topic 4: Exercise for working with the Deploy service At the conclusion of this exercise, you will be able to: • Work with the option provided by the Deploy service runtime GUI • Deploy and manage a deployed application, and to remove an application from the J2EE Engine Your company wants to implement a new web application. As system administrator, you would like to deploy this application.

Deploying and Updating an Application 1-1

Choose Server -> Services -> Deploy -> Runtime.

1-2

Choose Deploy The Deploy dialog window appears. Note: If you choose “Deploy”, the application will be deployed but will be placed in stopped mode. If you choose “Deploy&Start”, the deployed application will be started automatically. If you choose “Update”, the application will be started after the update finishes, only if it was started when the update began. The dialogs of the “Deploy”, “Deploy&Start”, and “Update” options are absolutely the same, so the procedure below can be relevant for each of them.

11

1-3

In the “File” field, specify the application EAR file. You can also browse to it in the file system.

1-4

Specify a new “Work dir”, if you want to change the default one. This is the folder in which the application file will be extracted. Caution: All files in the folder that you specify as a “Work dir” will be deleted! Back up the content of the folder in advance.

1-5

If some additional class files are necessary for loading and deploying or updating the application, modify the list of “Additional Class Path”.

1-6

For “Remote Support” of the application, specify a transport protocol. Note: If you do not choose a transport protocol, P4 is set by default.

1-7

Choose “OK”.

12

1-8

The “Deploy Dialog” appears. If you have missed to make some of the deployment configurations during the time you have created the application, you have one more time a chance to set some of the application properties. In our case there is no need for this, so directly choose “OK”.

The successful deployment is marked with green on the status bar:

13

Note: An application is assumed to be deployed/ updated in the cluster if it is successfully deployed/ updated on one server process in the cluster. The Deploy service is responsible for its deployment/update on the other cluster elements. If the deploy/update is not successful, the cluster is not homogeneous. With each restart of the server processes, the Deploy service tries to synchronize the applications, their versions and their status in the cluster, until it is successful. 1-9

Choose “Applications” from the bottom of the screen to list the deployed applications on J2EE Engine.

14

You will see that our application (Calculator) is deployed but is in a stopped mode. 1-10

Select the application and choose the “Start Application” option:

15

The “Start Application” dialog box appears. It provides a list of the server processes on which this application is available. 1-11

Select the server process where the application should be started by selecting the appropriate checkboxes. You can also use the “Select All” option:

1-12

Choose “OK”. If the application is started successfully, a green icon will appear on the statusbar and the application will be marked with a blue check:

1-13

Choose the container option on the screen to assure that the application is successfully started in the containers of the different server processes:

16

Our application contains both EJBs and Web components and has to be deployed only on one server process. As can be seen from the screenshot above, the application is startied both in the web conatainer (servlet_jsp) and in EJBContainer of one server process. Comparing the server process number with the one we have selected on step 11, we can see that this is the same server. Therefore, the deployment has finished successfully.

Setting a Failover Mode This option enables you to set a failover mode for the application. 2-1

Select the “Calculator” application from the “Deployed Components” list.

2-2

Choose the “App Info” option:

17

2-3

From the “Fail Over Mode” drop-down list, select a mode. The possible values are: •

disable – failover is disabled.

• on_request – the HTTP session is serialized after completing each HTTP request. • on_attribute – the HTTP session is serialized every time an attribute us added, changed or removed from the HTTP session.

2-4

Choose “OK”.

Removing an Application

3-1

Select the “Calculator” application from the Deployed Components tree.

3-2

Choose “Remove”:

18

The “Remove” dialog box appears. It contains fields with the name of the application and list of the components to which it belongs and the servers on which it is deployed:

3-3

Choose “OK”. The application is removed from the J2EE Engine.

19



© SAP AG 2004, Java Engine Administration

1

Unit: SAP Java Administration

Lessons:

Java Engine Administration

Configure different system services

Web AS Java Backup & Recovery

J2EE Engine Configuration and Tuning


2


SAP AG

3

Java Engine Administration: Lesson Objectives

After completing this lesson, you will be able to: z Point out the basic J2EE Engine components and their role in the system z Work with their main properties and runtime GUIs z Differentiate and work with the J2EE Engine core system components z Differentiate the J2EE Engine basic services z Explain the main functionality and features of each service and handle its properties and runtime GUIs


4

Introduction J2EE Engine Managers J2EE Engine Services

5

Java Instance A Java instance is a unit in the SAP Web AS Java cluster, which can be started, stopped, and monitored separately. It runs on a physical server; but it is also possible to run several instances on one server. An instance is identified by the system ID (SID) and the instance number.

Structure A Java instance contains at least one Server Process, but normally it comprises one Java Dispatcher and several server processes. A Java instance is started and stopped by the Java Startup and Control Framework.


Server Process 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 of requests simultaneously. Java Dispatcher assigns requests to the server processes. The server process consists of the following components: Some of these are the same as 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 process with the lowest capacity usage. If there is already a connection to the client, the request goes to the server process that processes this client.

6

Web AS Java - System Architecture

1. Java Enterprise Runtime – comprises low-level subsystems that provide functions such as class loading, cluster communication, persistent configuration data management. The layer is built of several low-level subsystems called Managers. 2. J2EE Engine Components – consists of interfaces, libraries and services components that provide various runtime functions and programming APIs.

Startup order

Java Engine logical layers:

3. Applications – refers to the applications that are deployed and run on the Java Engine. © SAP AG 2004, Java Engine Administration

Managers simplify the administration of the Java Virtual Machine, using thread management or memory management. 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 complete system 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 work together. Those components do not provide any runtime functions. At runtime, they provide the system with their name 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 when it loads the library, or when an object is first requested. Other library components or services components usually access 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 components classes have been loaded. Service components can access and utilize functions of the runtime through the Framework API. Some of the services support runtime administration and have runtime view in the Administration console. 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 level and 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 the system. The SAP Enterprise Portal for example is a J2EE Application.

7


8

Thread System

The Java Engine thread system is responsible for handling system and client threads. It comprises two managers – Thread Manager and Application Thread Manager. Application Thread Manager

Handles client/application requests.

Thread Manager

Handles system activities such as making backup, background jobs, optimizations for load/store data.


A thread is a thread of execution in a program. The Java Virtual Machine allows an application 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 threads in 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 request queue. 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 AS Server.

9

Configuring the Thread System 1/2 Configuring the Thread Pool InitialThreadCount

Sets the initial size of the thread pool.

ChangeThreadCountStep

Changes the step size of the thread pool.

MaxThreadCount

Change the maximum number of threads that the Thread Manager will manage.

MinThreadCount

Sets the absolute minimum number of the threads in the Thread Manager’s pool.


InitialThreadCount - Specifies the number of threads that will be started during the initialization of the Thread Manager. ChangeThreadCountStep - If the current number of running threads is not sufficient, this number of threads will be raised or destroyed during the next resize of the Thread Pool. MaxThreadCount - This limit is necessary to avoid overload due to too many running threads. MinThreadCount - Even if the Java Engine has absolutely no requests, this will be the minimum number of threads that will be kept running/idle.

10

Configuring the Thread System 2/2 Configuring the Request Queue InitialRQSize

Set the initial size of waiting objects in the Request Queue.

ChangeRQSizeStep

Change the resize step of the Request Queue.

MaxRQSize

Change the maximum size of the Request Queue.

MinRQSize

Set the minimum size of the Request Queue.


InitialRQSize - This is a structure that holds the requests to start a thread, until a free thread is available and able to process the request. ChangeRQSizeStep - This approach eliminates the number of small resizes by making one big resize. MaxRQSize - This property can be used to avoid infinite wait. MinRQSize - Set the minimum size of the Request Queue.

11

ClassLoader Manager The ClassLoader Manager is the central instance for registering, removing and accessing loaders and references between them. It registers the loaders of all components and applications in the J2EE Engine. The references are used by the Service Manager to manage the component’s startup order and integrity. Available reference types: notify weak hard strong


Two types of references are available: component and application. Each type has a different way for registering references. Modifying Component References You can register references at runtime using the Configuration Adapter service in the J2EE Engine Visual Administrator. 1. Choose Server -> Services -> Configuration Adapter Runtime -> Display Configuration tab. 2. Choose the Edit mode option. 3. Select cluster_data -> server/dispatcher -> cfg -> ext/interfaces/service -> 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 are loaded each time the application is started. You can add, edit and remove these references at runtime through 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 and runtime objects that B provides. Hard Reference - is equal to the “Strong Reference ” type, however, “Hard Reference ” is deprecated!

12

Cluster Manager The Cluster Manager is responsible for handling the elements in the cluster. It updates the information about the status of each cluster element and the services running on it. You can use the Cluster Manager to configure the properties of each element in the cluster.

element.clusterId Specifies the identification number of the cluster element.

element.groupId

Specifies the group ID of the element.

element.joinPort

Specifies the port on which the server process listens for connections.

element.name

Specifies the name of the cluster element.

element.type

Specifies the type of the cluster element – server or dispatcher.


There are two different cluster element types – dispatcher and server. These elements can be organized in groups according to their GroupID. Configuring Cluster Elements Modify the required property values depending on the tasks you want to perform: element.clusterId - The ID is unique for the cluster. The value of this property must be greater than zero. element.groupId - The value of this property must be greater than zero. element.joinPort - The port value must not be: greater than 65535, less than 1024, or a “well known” port. This property is available only on servers. element.name - There are no restrictions about the name. element.type - Specifies the type of the cluster element – server or dispatcher. Choose Save Properties icon on the toolbar to save your changes.

13

Connections Manipulator Connections Manipulator manages the client connections in the cluster. MaxParallelUsers

Defines the number of users that can be processed in parallel. When this number is exceeded the users are rejected.

MaxRepeatConnections

Specifies the maximum number of connections for Mode 2.

MaxSoTimeOut

Specifies the maximum time for reading the data from a socket.

MaxSoTimeOutConnections

The number of connections, after which the system starts working in Mode 2.

MaxThreadRepeatCount

Specifies the maximum number of checks one thread can make to one connection before going to a “sleep” mode.

MinSoTimeOut

Specifies the minimum value of socket timeout in milliseconds.


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 the MaxSoTimeOutConnections property is reached. • Mode 2 - the number of client connections is bigger than the number of the threads. In this case a common 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 free connection (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 in the 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 data in the connection. If there is data, it is processed; if there is no data, the thread passes to the next connection. The Connection Manipulator switches automatically between the working modes when the boundary marks 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.

14

IpVerification Manager The IP Verification manager controls the access of IP addresses to cluster elements. It stands between an incoming request and the requested resource. IpVerification Manager advantages: The client establishing the connection is unaware that the manager is running. Users in the allow list will connect to the resource without noticing any peculiarities. Users in the deny list will never receive any (additional) information as to why their connections failed.

Hosts File Contains a list of allowed and denied IP addresses.


Hosts File If the file specified as a value for the HostsFileName property is missing, the system creates default hosts.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: allow / deny= hostIP / hostRange / mask [, port [ , protocol]] These components have the following semantics: 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) and the 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 is created, or must exist, in the corresponding ../dispatcher or ../server directory. The IpVerification Manager enables many resources to share the common configuration file for easier management. 15

Service Manager The Service Manager acts as a container in which all services in the cluster work. The Service Manager defines the main control implementation for each service through which the administration of a separate service is accomplished.

Load timeout

The maximum time for which one service has to be started.

Event timeout

The time the Service Manager waits for the event to be processed before undertaking another action.


Setting Service Load Timeout 1. From the list of properties, select LoadTimeout. 2. In the Value field, set the required timeout in minutes. 3. Choose the Save Properties icon from the toolbar to save the changes. Setting Event Timeout 1. From the list of properties, select the EventTimeout. 2. In the Value field, set the required timeout in minutes. 3. Choose the Save Properties icon from the toolbar to save the changes.

The Service Manager is a distributed module that runs on both servers and dispatchers.

16


17

Administration Services Web Container EJB Container JNDI Registry Service Transactions and Resource Handling Deploy Service JCo RFC Provider Service JMS Provider Service Remote Objects Communication Services ClassLoader Viewer Service Configuration Adapter Service

18

Administration Services The Web AS Java administration is based on the Java Management Extensions (JMX) 1.1. Services which provide a means for working with MBeans: Provides instrumentation of the kernel and the Basic Administration server components (services, libraries and interfaces). Service

Administration Provides a remote connector to the MBean server based on RMI/P4 and convenient interfaces for Adapter working with the MBeans registered by the Basic Service Administration Service.

JMX Adapter Service

Manages the configuration and lifecycle of the MBeanServer and provides access to it for applications, services, and libraries.

JMX Notification Service

Provides notifications for events connected with the MBeans.


Basic Administration Service - Registers MBeans that can be used for managing a single cluster node or the whole cluster.

Administration Adapter Service - These interfaces can be used to invoke operations on the MBeans. They also provide 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 (in milliseconds)

[NotificationQueue] – Within the J2EE Engine JMX notifications are usually sent asynchronously. The notifications 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 workerthread

[ObjectNameCompletion] – JMX ObjectNames have to meet certain conventions. There is a factory which supports the creation of ObjectNames that include the necessary location information. The factory uses a cache to 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 done using shell commands.

19


20

HTTP Provider Service HTTP Provider Service provides the low-level communication and transportation services for the Web AS Java - Web Container to work properly. Features of the HTTP Provider Service:

Supports communication through proxy environment Supports multipart requests parsing Integrated mechanism for heterogeneous load balancing for requests to web applications Supports virtual hosting Supports applying gzip transfer encoding to requests and responses to static Web resources Provides efficient configurable HTTP cache


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 balancing algorithms and fast requests processing. From a client’s point of view, HTTP Provider Service represents a server socket that listens for client HTTP connections to the Java Engine. HTTP is a request-response protocol. Based on that paradigm, HTTP Provider Service takes care of parsing the URL of the incoming HTTP requests, dispatching them to the proper SAP WebAS Java Engine’s module for processing, and returning the generated responses back to the client. It provides important features to secure a robust, high performance communication infrastructure for running highvolume 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, this guaranties that the client request to that application is dispatched to the correct server where the application is available.

21

HTTP Provider Service on Java Dispatcher


You can perform the following tasks with the HTTP Provider Service running on the Java Dispatcher: • Configuring Heterogeneous Load Balancing • Setting up HTTP Provider Service to Accept Incoming Requests • Mapping Ports • Tracing HTTP Requests • Setting Timeout for Persistent Connections • Limiting the Length of the Requests Headers

22

HTTP Provider Service on Server Process


You can perform the following tasks with the HTTP Provider Service running on the Server Process: • Certificate Login When Using SSL-enabled Proxy • Configuring Application Zones • Configuring Rules for HTTP Responses Compression • Specifying the Size of the File Buffer • Update the HTTP Cache Content • Configuring the HTTP Cache • Configuring HTTP Responses Caching by Client Caches • Logging in Common Log File Format • Managing MIME Types • Specifying Welcome Files

23

Web Container Service The Web Container service is an implementation of a container of J2EE Web components. The Web Container service: Enables the life cycle management of Web applications Helps developing and running session-aware and security-aware Web applications. Complies with Java Servlet 2.3 Specification and JavaServer Pages 1.2 Specification.

Integration of the Web Container service: The Web Container service has a strong reference to the HTTP Provider Service. Runs only on server processes.


Task and the properties of the service: • 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 the client. It is an important feature when transferring responses with large message bodies. • Specifying Compilation Time of JavaServer Pages – use the CompileOnStartUp property - Configures the Web Container Service behavior concerning compiling JSP files of your web applications into servlet implementation classes. • Specifying Servlet Execution Destroy Timeout – use the DestroyTimeOut property • Setting up the Compiler – use the Internal Compiler property or the External Compiler property depending on type of compiler you want to use • Configuring the Header Preventing Dynamic Responses Compression – use the HeaderForNoCompression 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 the ApplicationStoppedFile property • Isolating Running Web Applications from Productive Client Requests – use the ApplicationStoppedAliases property Using Telnet you can list the HTTP sessions and the security policy domains in all running applications of the Web Container. Strong reference - If the referenced service stops for some reason, the correspondent services stops as well.

24

Runtime Administration of Web Applications


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 running within 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-j2eeengine.xml deployment descriptors. Those configuration settings have greater priority over the global settings 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: • Name and class of the component • Initial parameters • Mappings • Security settings

25


26

EJB Container Service The EJB Container Service manages all enterprise bean instances deployed on the server. The EJB Container Service provides all services that are required by an EJB application: Transaction and security management Clustering Persistence Network distribution of remote clients Scalable management of resources and so on…

The service provides options for runtime administration of the enterprise beans running on the J2EE Engine EJB Container. The EJB Container service runs only on server processes.


You can use the EJB Container Service to: 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 standard interoperability 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. To enable the IIOP support, use the runtime tab of the EJB Container service, select the desired application and choose the “Deploy IIOP Support” option.

27

Runtime Changes in Deployed Enterprise Beans The Runtime tab of the EJB Container service displays a tree structure of all EJB applications that are deployed on the server.


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 may destroy 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 to obtain 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 will receive.

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 onMessage message if the message-driven bean uses bean-managed transaction demarcation.

28


29

JNDI Registry Service JNDI Registry Service provides a way by which names are associated with objects, and objects are found based on their names. The service performs binding, rebinding, and unbinding operations. JNDI Registry Service basic concepts:

Naming concepts

Associating an object with a particular name as binding it in the J2EE Engine naming system. Once the object is bound, it can be accessed through the lookup operations and through the operations for working with names (rename, rebind, unbind).

Directory concepts

Operations are provided, through which can be associate not only an object with a specified name, but also with specified attributes.


The SAP J2EE Engine naming system is developed in accordance with the JNDI 1.2 Specification to meet the Java 2 Enterprise Edition (J2EE) requirements. The system provides functions based on the JNDI 1.2 Specification, as well as some additional features related to its work in a cluster.

30

JNDI Registry Service Specific Features

Information collection

The JNDI Registry service stores the data in a nonpersistent storage (the data is stored in the memory).

Tree-like structure

The naming contexts and objects are arranged in a hierarchy. In every context object can be placed bindings or other contexts called sub-contexts.

Global objects The JNDI Registry service enables each naming operation to be replicated in the cluster – the so called global operations.

Nonserializable objects

All bindings in the naming system consist of an object name, serialized object data, and attributes (if provided). Only serializable objects can be kept in the naming storage.


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 all following operations in the naming system. Global objects – The global operations in all servers’ naming systems objects appear with the same name and 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 be bound 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 in the 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, the next 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 connection between the client side and one of the servers in the cluster. This server is chosen with the load balancing mechanism of the P4 Provider service.

31

Browsing the Naming Tree


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. The information 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 an object value. When the object is non-serializable, this is displayed in the [Object Value] sub-node (nonserializable means that only server-side clients can look it up).

32


33

Transactions and Resource Handling The Transactions and Resource Handling component enables the execution of local and distributed transactions and the usage of resources within 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: Transaction Service

Manages all transactions on the SAP J2EE Engine server elements.

Connector Container Service

Manages the overall connectivity to back-end resource systems.

JDBC Connector Service

Enables databases connectivity and provides functions for creating and managing DataSource objects.

JMS Connector Service

Enables the use of JMS resources in both local and distributed transactions.


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 the container 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 J2EE Engine 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 Engine.

34

Transaction Service The Transaction Service component manages all transactions on the Java Engine server processes. Modules of the Transaction Service: Java Transaction API (JTA)

Enables communication between the managing modules of the service, the application server and the other components that participate in a distributed transaction (the application components and resource managers).

Java Transaction Service (JTS)

Enables management and execution of transactions from other servers (either J2EE Engine server processes or application servers by other vendors) by providing a low-level Java mapping of the Object Transaction Service (OTS) standard by Object Management Group (OMG).


Features With the implementation of both JTA and JTS, Transaction Service offers a broad range of functions regarding 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

35

J2EE Connector Architecture The J2EE Connector Architecture enables connectivity to backend systems such as Enterprise Information Systems (EIS), using resource adapters. The Connector Architecture involves integration of three underlying mechanisms: Connection pooling Transaction management Security management

The J2EE Connector Architecture comprises services: Connector Container JDBC Connector JMS Connector


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 a relational database using a DataSource created with the JDBC Connector service, or your messagedriven 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 the connector services provide. the deployment of resource archives (RAR files) on the J2EE Engine. It also provides overall connection 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 to develop and deploy a resource adapter following the requirements of the J2EE Connector Architecture 1.0 standard.

36

Connector Container Service

The Connector Container Service is service manages the overall connectivity to back-end resource systems. It provides a runtime environment for resource adapters that enable you to connect to heterogeneous Enterprise Information Systems (EIS). The Connector Container service: Implements the J2EE Connector Architecture 1.0 Enables access to various resource systems in a unified way, using resource adapters. Enables connection pooling. Runs only on server processes


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 (configurable properties). 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, which may also affect other applications that use it. Therefore, you must be careful when modifying the MCF properties. • 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 to external resources that the adapter uses. • clone the resource adapter - when deploying the resource adapter, you can only register a single MCF instance. 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 you bind in the JNDI registry by a different name and can configure with the appropriate settings for your application. 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.

37

Connector Container Runtime


You can check the following settings: • 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 is required 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 to the resource adapter classloading. • Managed Connection Factory – the configuration of the ManagedConnectionFactory (MCF) that provides a ConnectionFactory, which the applications can lookup from the JNDI registry and use to obtain 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 by the MCF and registered in the JNDI registry. • Security – you can check the authentication type of the resource adapter and the identity subjects defined for it. • Drivers – you can check if any JDBC drivers have been registered with the resource adapter.

38

JDBC Connector Service

The JDBC Connector Service is a resource adapter based on the Java Database Connectivity (JDBC) standard to enable databases connectivity. It provides functions for creating and managing DataSource objects, as well as database connection pooling. JDBC Connector Service enable easy and fast connectivity to databases by various vendors:

Support for both JDBC 1.x and JDBC 2.0 drivers Connection pooling and re-using Support for both local and distributed transactions Database independence using the Database Interface (DBI)


Using the JDBC Connector Service, you can: • Create either JDBC 1.x or JDBC 2.0 compatible DataSource objects • Import and export DataSource objects • Manage the connection pools • Manage the transaction isolation levels for the connections • Manage DataSource aliases • Deploy and remove JDBC drivers • Define and un-define JDBC drivers • Define the type of connections using the SQL Engine • Initialize your database • Monitor DataSource objects

39

JMS Connector Service

The JMS Connector Service provides connectivity to Java Message 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 an environment 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.

40

JMS Connector Runtime


The functions that JMS Connector Service provides enable you to: • Register ConnectionFactory objects using either JNDI-based or object-based providers • Register JMS destination objects • Import and export JMS objects • Edit JMS objects • Deploy and remove JMS libraries • Define and un-define JMS libraries • Manage connection number

41


42

JCo RFC Provider Service The JCo RFC Provider service processes RFC requests - ABAP to Java. A feature is provided for receiving calls from the SAP systems – the J2EE Engine should be registered as an RFC destination.

SAP J2EE Engine

Repository

1

R

JCo RFC Provider Service

JCO

5

R

2 4 6

R

R

7

JNDI Context

R

3

R

Gateway

EJB

R

8

Web AS

R


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 to a 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 a shared 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 is possible 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.

43

Registering a Destination


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 JCO functions. d. Choose the Number of processes (1 to 20) field and specify the number of JCO Servers simultaneously running 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 right-hand pane to add it as a new bundle. 44


45

JMS Provider Service

The JMS Provider Service enables you to manage the JMS destinations and connection factories on J2EE Engine. The JMS Provider Service provides functions to: Manage Instances. Manage Topics and Queues. Manage JMS Connection Factories.

It runs on both the server and dispatcher processes.


The JMS Provider Service is the administration service of the Java Message Service (JMS), than the JMS Connector 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 deliver messages to the destinations. • cleanUpServiceSleepInterval – The time interval in milliseconds after which the Clean Up service is called. • 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 a destination. • 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 be written. Note: Each working destination (the one with at least one producer/consumer) may take up to sizeLimitInMasterQueue 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 heap size.

46


47

P4 Provider Service The P4 Provider Service provides the implementation of the SAP specific P4 protocol for communication between Java remote objects. This protocol is an alternative of the standard Java RMI protocol for Java-to-Java remote communication. It runs on both the server and dispatcher processes. P4 Provider Service dispatcher processes part

Accepts requests from the remote clients and dispatches them to the appropriate cluster element, where the implementation of the remote object resides.

P4 Provider Service server processes part

Contains the implementation of the P4RemoteObject broker and is responsible for executing methods on the implementation of the remote object and returning the results.


The P4 Provider Service dispatcher part uses the Load Balancing mechanism to dispatch the requests. Customization of the P4 Provider Service by: • Managing the underlying transport layers: If you want to use P4 : • with no underlying transport layer – assign value to the port property • over HTTP Tunneling – assign value to the httptunneling property • over SSL – assign value to the ssl property • over secure HTTP – assign value to the https property • Allowing access to a host – use the bindHost property • Limiting the size of P4 requests – use the MaxRequestSize property • Determining how is the communication between remote objects in a single JVM conducted – use the Instantiate Local Stubs property The service also provides runtime information about active remote objects and brokers.

48

IIOP Provider Service IIOP Provider Service provides an implementation of the standard Internet Inter-ORB Protocol (IIOP) used for interoperability between CORBA and Java objects. It is also capable of serving Java-to-Java remote objects communication. It runs on both the server and dispatcher processes. IIOP Provider Service - Dispatches the client requests to the dispatcher processes appropriate server process where the remote object resides. part IIOP Provider Service - Provides the parameters of the remote call to server processes part the actual method of the implementation of the remote object and returning the results of the method call to the client. This part contains the implementation of the ORB object that takes major part in the remote objects communication.


The IIOP Provider Service - dispatcher part uses the Load Balancing mechanism to dispatch the requests. The service provides the following properties to be configured: • port – specifies the port on which SAP J2EE Engine listens for IIOP connections • ssl_socket – specifies the port on which the server socket for SSL connections is opened

49

Remote Object Container Service The Remote Object Container service is a container for the implementations of the server-side remote objects. It manages the life-cycle of those objects and provides them with access to the existing protocols for remote objects communication on the Java Engine (such as P4 and IIOP protocols). The service facilitates also the runtime generation of communication support for remote objects (that is, stubs and skeletons for RMI-P4 objects and stubs and ties for RMI-IIOP objects).


50


51

ClassLoader Viewer Service The class loader references can be viewed easily using the ClassLoader Viewer Service. This service graphically displays the relations between different loaders on a selected cluster element.


52

ClassLoader Viewer Service The class loader references can be viewed easily using the ClassLoader Viewer Service. It graphically displays the relations between different 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’s resources 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@ sub-nodes, each representing a different reference cycle).

The references are visualized on the right-hand side of the Runtime tab in the sequence in which they are 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 selected loader 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 are loaders references, and on the left side are its referees. If you choose a reference or a referee, it becomes the one to be monitored – it is moved to the middle of the screen and its references and referees are displayed as described above.

53

J2EE Engine Services: Lesson Summary

You should now be able to: z Point out the basic J2EE Engine components and their role in the system z Work with their main properties and runtime GUIs z Differentiate and work with the J2EE Engine core system components z Differentiate the J2EE Engine basic services z Explain the main functionality and features of each service and handle its properties and runtime GUIs


54

Appendix – Services index

55

Appendix: J2EE Engine Services 1/4 z Services: ABAP communicator Administration Adapter Application Client Application locking (*) Basic Administration Classloader Viewer (*) Classpath Resolver Configuration Adapter (*) Connector Container (*) Deploy (*) Destinations Distributed Statistics (*) EJB container (*) File transfer © SAP AG 2004, Java Engine Administration

(*) This Service has a Runtime tab

56

Appendix: J2EE Engine Services 2/4 z Services: HTTP Provider (*) IIOP Provider Java Mail Client JCo RFC Provider (*) JDBC Connector (*) JMS Connector (*) JMX Adapter JMX Notification JNDI Registry (*) Key Storage (*) Licensing Adapter (*) Locking Adapter Log Configurator (*)



57

Appendix: J2EE Engine Services 3/4 z Services: LogViewer (*) Memory Info Message Info Monitoring P4 Provider (*) Performance Tracing (*) PMI Remote Object Container Runtime Info Provider SAML Secure Storage (*) Security Provider (*) Session Failover SLD Data Supplier (*) © SAP AG 2004, Java Engine Administration


58

Appendix: J2EE Engine Services 4/4 z Services: SSL Provider Tc/eCATTPing/service Telnet Provider Timeout Transaction TREX Service UME Provider USER Storage Virus Scan Provider (*) Web Container (*) Web Dynpro Runtime Web Services Container (*) Web Services Security (*)



59

SAP Java Engine Administration – Exercises Unit 4: SAP Java Administration Lesson 2: Configure different system services Topic 1: Exercise for working with the HTTP Provider service At the conclusion of this exercise, you will be able to: • Work with the runtime GUIs of the HTTP Provider service on both the server process and the Java dispatcher. ABC Limited, a petrochemical company, installed the latest version of SAP system, SAP Web Application Server. They now have several web applications running and have added dialog instances to help handle the load. As system administrator, you would like to integrate the new dialog instance to the web switch adapting its HTTP port, to allow support of HTTP 1.0 protocol and to create virtual hosts and aliases for the web applications.

Setting up HTTP Provider Service to Accept Incoming Requests 1-1

Open the Properties tab of the HTTP Provider Service running on the dispatcher.

1

The default http port is Port:50000. 1-2

Edit the Ports property. Change the http port to 50200 (or other). The value of the Ports property is a list of separate ports’ configurations, each contained within brackets. For example, the default value of this property contains two port configurations: (Port:50000,Type:http) and (Port:50001, Type:ssl).

To apply these changes, choose the Save Properties icon on the toolbar. 1-3

Execute the localhost with the new port on your browser to check whether the new port has come into force:

2

You now have basically configured your HTTP Provider service running on the Java dispatcher to forward incoming HTTP requests to the appropriate server modules (HTTP Provider service, and Web Container service if the request is directed to a J2EE web application). Note: To continue with the next exercises, turn the port value back to Port:50000.

Virtual Hosting After we have set up the HTTP Provider service running on the Java dispatcher to accept incoming calls (“Ports” property), you can start configuring virtual host on your system. 2-1

Open the “Runtime” tab of the HTTP Provider service running on a server process.

2-2

Choose “New Host” at the upper part of the screen:

3

2-3

Enter the name of the new host and choose “OK”.

Note: The name of the new virtual host must be equal to the IP or the domain name with which it will be access from outside. This will create a new host with default settings. You can then set it up differently by changing the values of some of its properties, set new aliases, root directory, and so on.

4

Note: You can also use Telnet to create new virtual host. Use the HOST shell command with its –add option. The command must be executed on the server process. Note: The most important thing you have to do after you have created the new virtual host is to map the new host’s name to an existing IP address in the DNS server. Now, when you try to access this host via a browser using the host name in your URL, the host name is resolved to the IP address that you have mapped to it. 2-4 Simulation of virtual host mapping to IP. Using Notepad open file C:\WINNT\system32\drivers\etc\hosts add this virtual host to the host file. Example: 127.0.0.1

testhost

5

after saving this file, test the new (local) virtual hosting. Call the server with the new host name: http://testhost:50000/index.html

6

Defining HTTP Aliases on a Virtual Host 3-1

Choose the virtual host, for which you want to define alias, from the list.

3-2

Choose the Aliases tab:

3-3

Enter the name of the alias and the corresponding path to a directory on the local file system. Example: Create a folder G:/test Inside create a file myhtml.html With some content “This is my test page” Choose “Add” The name of the alias and the directory path it points to must appear in a list on the screen.

7

Make sure you choose “Save Properties” to permanently save your changes.

3-4 In the browser, execute http://localhost:50000/test/ to test how the new alias works.

Note: You can also use the HTTP_ALIAS command from the HTTP shell command group to define new and remove existing aliases with Telnet. 8

Activating and Deactivating Application Aliases Specify whether or not a Web application is available on a particular virtual host. You must first have the J2EE Web applications deployed so that their aliases are added to the list of available application aliases. Then you can decide which one to remove from it. 5-1

Open the “Runtime” tab of the HTTP Provider service running on server process.

5-2

Choose the “Application Aliases” tab for the appropriate virtual host.

5-3

Select or deselect an indicator (for the example, of the Hello alias) under the Active column:

5-4

Choose “Save Properties”. Note: You can use the APPLICATION_ALIAScommand with Telnet to activate or deactivate application aliases on a particular virtual host.

9

Unit 4: SAP Java Administration Lesson 2: Configure different system services Topic 2: Exercise for working with the JDBC Connector service At the conclusion of this exercise, you will be able to: • Add drivers for all kinds of databases • Add and configure standalone DataSource objects ABC Limited, a petrochemical company, deployed a new web application which requires an access to external database via JDBC. As system administrator, you would like to establish the database connectivity.

Deploying JDBC Drivers To can create a DataSource, you must first deploy the JDBC driver you want to use. The J2EE Engine provides support for both JDBC 1.x and JDBC 2.0-compliant drivers. Note: When you first log on to the system, there is already a defined driver. This is the system driver used by the Configuration Manager. For the sake of this exercise, we will deploy the same system driver but under a different name just to show how you can deploy a driver and then use this driver to create a DataSource. However, in real live you do not need to deploy the system driver to create to the Max DB which goes by default with the J2EE Engine. This driver is there by default. But if your DataSource uses another database, you will have to have this database running and you have to deploy a driver for this database to connect your DataSource to it. 1-1

Choose Server -> Services -> JDBC Connsector -> Runtime.

1-2

Choose Resources -> Drivers.

1-3

Choose the “Create New Driver or DataSource” icon on the toolbar.

10

1-4

Specify an arbitrary name for your driver entry. example: myDriver

1-5

Browse to the archive file that contains the classes of the driver. You can choose more than one files additionally.

The new driver is added to the “Drivers” tree structure:

11

Creating a DataSource with JDBC 1.x Driver You can use the administration tools that the J2EE Engine provides to create a standalone DataSource. It is deployed on the server as an application that actually contains only the deployment descriptor for the DataSource object. The installation procedure for the J2EE Engine creates a JDBC 1.x compatible DataSource that is used by the services running on the engine. This DataSource is available immediately after the JDBC Connector service is started. If your applications use the system database schema, we recommend that you use the default DataSource. However, if you want to use other database schemas, you should create a separate DataSource for each of them. 2-1

In the Runtime tab of JDBC Connector service, choose Resources -> DataSources.

2-2

Choose the “Create New Driver or DataSource” icon on the toolbar.

12

2-3

Complete the following fields. All required fields are marked with an asterisk (*): 2-3-1 Application Name – specify a name to which the DataSource is associated. Do not enter the name of an application already deployed on the server. This leads to re-deployment of the application and data loss. example: myApplication 2-3-2 Name – specify a unique name for the DataSource. It is used when you look up the DataSource in the naming. When creating a standalone DataSource, make sure the name is unique. example: myDataSource 2-3-3 Aliases – aliases are alternative to the name of the DataSource and enable the usage of a single DataSource by multiple applications. You can specify unlimited number of aliases. example: myDS 2-3-4 Driver Name – choose a 1.x-compatible driver we previously deployed (myDriver) from the drop-down menu with registered drivers. 2-3-5 JDBC Version – choose 1.x from the drop-down menu 2-3-6 Driver Class – enter the fully Java qualified name of the driver’s main class. example: com.sap.dbtech.jdbc.DriverSapDB

13

2-3-7 Database URL – the JDBC URL consists of three parts: a protocol identifier (always JDBC), a driver identifier (for example, IDB, Oracle, and so on), and a database identifier (the format is driver specific). MaxDB URL:

jdbc:sapdb:///

example: jdbc:sapdb://localhost/DEV?timeout=0 2-3-8 User – specify the username that you use to log in to the database server Password – specify the password for your database user example: User: SAPDEVDB

2-4

PW: enjoy

In the Additional tab manage the connection pooling – JDBC Connector service offers connection pooling to enable better performance of the system. Re-using connections is less time- and resource-consuming than creating new ones each time your application or client sends a request for connection. You can manage the number of pooled connections, as well as their lifetime to achieve best performance by your application or client. Specify the following parameters, if necessary: 2-4-1 Initial Connections – the number of connections that are obtained initially when the DataSource is created. We recommend that you have a few (1-2) connections created initially to enable fast connectivity to the database once your application sends a request for connection. example: 2 14

2-4-2 Maximum Connections – the number of maximum connections from a single DataSource that are kept in the pool. If you need to connect multiple times, or there are many clients working with the database simultaneously, set a higher value for the number of connections that your pool contains. example: 30 2-4-3 Maximum Time to Wait for Connection – when the maximum number of supported connections is reached and there are no free connections in the pool, the client waits the specified interval to obtain a connection. If the system does not return a connection to the pool during the interval, you get an exception thrown. 2-4-4 Expiration – enables the parameters for connection life control – that is, Connection Lifetime and Cleanup Thread. 2-4-5 Connection Lifetime – a period in seconds, after which the connection expires if it is not in use 2-4-6 Cleanup Thread – an interval in seconds between two consecutive threads run by the system to clean up unused connections

15

2-5

Set the SQL type support:

16

2-6

To save your entries, choose the “Save Changes” icon on the toolbar. The new DataSource appears on the screen:

DataSource with JDBC 2.0 Driver The process of creating a DataSource with JDBC 2.0 driver is quite similar, however you first have to deploy a JDBC 2.0 compatible driver. Then, when creating a DataSource, you will be prompted to enter the classname of the DataSource object factory, the DataSource Type (ConnectionPoolDataSource or XADataSource), and depending on the DataSouorce type, specify the name of the ConnectionPoolDataSource or of the XADataSource class used to provide a database connection. In the Additional tab you then can specify, for example, ServerName, PortNumber, DatabaseName, User, and password as additional properties.

17

Unit 4: SAP Java Administration Lesson 2: Configure different system services Topic 3: Exercise for working with the JMS Connector service At the conclusion of this exercise, you will be able to: • Register a JMS ConnectionFactory using a JNDI-Based provider • Register a standalone JMS Destination • Deploy a JMS library This exercise will register a JMS ConnectionFactory when your JMS provider also provides a naming system. It applies both to the JMS Provider service in the J2EE Engine and to any external JMS provider with naming provided. With the administration tools of J2EE Engine you can register a standalone ConnectionFactory. It is deployed on the server as an application that contains only the deployment descriptor for the JMS object.

Registering a JMS ConnectionFactory using JNDI-Based Provider You must have obtained a ConnectionFactory instance from your JMS Provider. The JMS Connector service wraps the instance and provides transaction and resource management within the application server. Thus you do not need to manage the transactions and resource handling programmatically in your application. If you use the JMS Provider service of the J2EE Engine, see the JMS Provider service exercise (section “Working with JMS Connection Factories”) for more information about creating connection factories. 1-1

In the Runtime tab of JMS Connector Service, choose Resources -> Factories.

1-2

Choose the “New” icon on the toolbar.

18

1-3

In the right-hand tab complete the following fields: 1-3-1 Application Name – Specify a name to which the ConnectionFactory is assigned. example: myApplication 1-3-2 Factory Name – Enter a name for your ConnectionFactory. The system uses it to bind the factory in the naming system. example: myConnFactory 1-3-3 Client ID – Enter a client identifier. It is also assigned to the connection that is created with this ConnectionFactory. The Client ID is not a required field. If you leave it empty, it defaults to the client ID of the connection factory from the JMS provider. 1-3-4 User – Enter a username for authentication to the JMS provider. example: Administrator 1-3-5 Password 1-3-6 Description – You can enter descriptive text for the ConnectionFactory. This field is optional. example: This is an example for a JMS ConnectionFactory. 1-3-7 Provider Type – Choose JNDI Based from the drop-down menu.

19

1-3-8 Library – From the drop-down menu choose a library that the JMS Connector service uses to obtain a connection factory instance. You need a JMS library when you use an external JMS provider instead of the JMS Provider service in the J2EE Engine. To use a JMS library, you must first deploy and define it on the J2EE Engine. 1-3-9 Aliases – You can add an unlimited number of aliases, which are alternative names of the connection factory. They enable the factory to be used by multiple clients and prevent you from having to create many equal connection factories only with different names. example: myJNDICFactory Note: The type of the ConnectionFactory (Queue or Topic) is automatically determined after you start the application associated to the factory.

1-4

Choose the Provider tab. Complete the following fields: 1-4-1 JNDI Path – Enter a string that denotes a reference to the ConnectionFactory object in the naming tree of the JMS provider. example: jmsfactory/default/TopicConnectionFactory 1-4-2 Initial Context Factory – Enter the implementation of javax.naming.spi.InitialContextFactory that your client uses to obtain initial naming context. example: com.sap.engine.services.jndi.InitialContextFactoryImpl 1-4-3 Provider URL – Enter provider URL in [:] format. 20

1-4-4 Security Principal – Enter the name of the entity (user) that is authenticated when the connection to the JMS provider is established. example: Administrator 1-4-5 Security Credentials – Enter the credentials (typically a password) that authenticate the security principal to the JMS provider. Note: You can add more properties using the Additional tab. Enter the name and the value of the additional parameter(s) in the Property and Value fields respectively, and choose Add. 1-5

To save the changes, choose the “Save” icon on the toolbar.

1-6

To start the new factory, choose the “Start” icon on the toolbar:

21

The following message will appear:

1-7

Choose “Yes” to continue. The new factory will be activated:

22

Note: You can also register a JMS ConnectionFactory using a Non-JNDI Provider. For more information, see the J2EE Engine official documentation.

Registering a JMS Destination The J2EE Engine enables you to register a standalone JMS Destination. It is deployed on the server as an application that contains only the deployment descriptor for the Destination object. 2-1

In the “Runtime” tab of JMS Connector service, choose Resources -> Destinations.

2-2

Choose the “New” icon on the toolbar:

23

2-3

In the right-hand tab complete the following fields: 2-3-1 Application Name – Specify a name to which the Destination is assigned. example: myNewApplication 2-3-2 Destination Name – Specify a name for the object that you create. example: myTopicDestination 2-3-3 Factory Name – Specify the name of a Queue- or TopicConnectionFactory. example: myConnFactory 2-3-4 Description example: This is a Topic JMS Destination for provider. 2-3-5 User example: Administrator 2-3-6 Password Note: If you want to create a JMS Destination similar to an already existing one, use the Copy icon on the toolbar to copy the properties of the existing JMS Destination. Then choose the New icon and the Paste icon to paste the properties. Modify the parameters and save the JMS Destination object with a new name or in another application. 24

2-4

Choose the “Save changes” icon on the toolbar to save the object.

Result

25

Deploying a JMS Library You deploy and register a JMS library when you want to use an external JMS provider. A JMS library includes the client JAR file of the provider. It enables you to create ConnectionFactory objects using the relevant JMS provider. 3-1

In the Runtime tab of JMS Connector Service, choose Resources -> JMS Libraries.

3-2

Choose the “New” icon on the toolbar.

3-3

Enter an arbitrary name for the JMS library, such as myLibrary”

3-4

Browse to the archive file (ZIP or JAR) that contains the classes of the JMS library.

26

You can choose several files consequently. When you confirm the selection of a file, you can either choose to add another archive file or finish the process by choosing “Cancel”. 3-5

Confirm the deployment of the library.

27

Result

28

Unit 4: SAP Java Administration Lesson 2: Configure different system services Topic 5: Exercise for working with the JCo RFC Provider Service At the conclusion of this exercise, you will be able to: • Perform a function call from ABAP backend system to the J2EE Engine. Your company has implemented a new SAP NetWeaver application which requires an RFC destination to be established between the ABAP and the Java Engines. As system administrator, you would like to register this RFC connection.

Prerequisites: You should have the application “STFC_CONNECTION” deployed on the J2EE Engine.

Establishing a connection between ABAP and J2EE Engine In order to establish the connection you should create RFC destinations on both sides – ABAP and J2EE Engine

Registering an RFC Destination in ABAP 1. Go to transaction SM59 2. Click on “create” to create a new RFC connection.

29

On the next screen: 3. Enter a name in the “RFC Destination” field example: RFCTEST 4. Enter a connection type “T”

30

Double click on “New Entry” 5. Select “Registered Server Program” for Activation Type 6. Fill out the “Program ID” field example: RFCTest 7. Fill out the “Gateway Host” and “Gateway Service” example: Gateway Host: Gateway Service: sapgw25 8. Write a short description (obligatory) example: Function call test.

9. Change the Character set in the target system to Unicode. (Under the Special Options Tab)

31

10. Save the destination

32

Registering an RFC Destination on the J2EE Engine 1. Open the Visual Admin Tool of the J2EE Engine 2. Choose Server->Services->JCo RFC Provider->Runtime 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 20 5. 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. 33

10. Check the “Unicode” box if the ABAP system is a Unicode System 11. Press the “Set” button to save the destination

If you see the RFC destination to appear in the list of Available RFC Destinations with the icon as on the screenshot then the destination has been created and started successfully.

Testing the connection between ABAP and J2EE Engine 1. 2. 3. 4.

Go to transaction sm59 Expand the TCP/IP connections list Find your destination there and open it with double click Click the “Test Connection” button

34

If the connection has been establish you should get the following screen:

35

Executing the STFC_CONNECTION function module 1. Go to transaction se37 2. Enter the name of the function module – in your case STFC_CONNECTION 3. Press the third button in the toolbar (Single Test)

On the next screen: 4. In the “RFC target sys” field enter the name of the RFC Destination in ABAP Note: The names of the RFC destination in ABAP and in the J2EE Engine are not identical The name of destination in the J2EE Engine is identical with the “ProgramID” of the destination in ABAP In this field you need the “RFC destination name” not the “ProgramID” 5. In the “REQUTEXT” field enter any text 6. Press the first button from the left side

36

If the function call has been successfully executed you should see the following screen

37

Unit 4: SAP Java Administration Lesson 2: Configure different system services Topic 6: Exercise for working with the JMS Provider service At the conclusion of this exercise, you will be able to: • Create and configure a JMS instance • Work with JMS connection factories Your company has implemented a new J2EE application which uses JMS. As system administrator, you would like to create a new JMS instance.

Creating a New Instances 1-1

Open the JMS Provider service and choose the “Runtime” tab.

1-2

Choose “Create”:

38

1-3

Specify the name of the instance – the name cannot be more than 100 characters. The following names are forbidden: browsers, connections, sessions, destinations, consumers, producers. The same restriction is relevant for the names of the topics and queues. When you create an instance it is started automatically.

1-4

Restart the JMS Provider in the whole cluster in order to start the new instance. Choose the “Stop service” icon:

When the service is stopped, choose the “Start service” icon nest to the “Stop service” one, to start the service again. 1-5

Configure an instance – select the instance to configure from JMS Server Instance and specify the start up mode in Start up Mode. You can choose one of the following modes: • STARTUP_ALWAYS – the instance is always started • STARTUP_MANUALLY – the instance is started only manually

39

1-6

Create a new topic or queue 1-6-1 Choose an instance from the left-hand side pane (“JMS Server Instance”) and choose “Create” from the right-hand side pane:

40

1-6-2 Specify the name of the topic and choose “OK”:

1-6-3 Lookup name for both topic and queue – when a destination (queue or topic) is selected, the lookup name displays the actual lookup name for this destination. For example, a testTopic destination on the server instance default will have the lookup name jmsqueues/default/testTopic.

Note: When you create a new destination or remove an existing one, a resource instance is created in (or removed from) the Security Provider Service. You can view this resource in the Security Provider -> Runtime -> Policy Configurations tab. From the “Components” pane, select service.jms.instance."instance_name".authorization and choose the “Resources” tab. This resource is required to grant users rights over the destination. Each time an instance is added to or removed from the JMS Provider, a new resource entry for the instance is added or removed.

Working with JMS Connection Factories The default bound JMS connection factories are: 41

•

jmsfactory/default/TopicConnectionFactory

•

jmsfactory/default/QueueConnectionFactory

We recommend that you use these two factories. Note: When you update a factory using the Visual Administrator tool you have to authenticate to the J2EE Engine to be able to use the connection factory. 2-1

Open the JMS Provider service and choose the Runtime -> Connection Factories tab.

2-2

Create a new connection factory or choose an existing one to manage its settings:

2-2-1 If you are creating a new factory, specify the name of the new connection factory in JNDI Name. Caution: The name cannot be more than 100 characters. The following names are forbidden: browsers, connections, sessions, destinations, consumers, producers. 2-2-2 Select the type of the connection factory from Factory Type. 2-2-3 You can specify a user name under which to manage the connection factory later. Specify a password for this user. 42

2-2-4 To create a new factory choose “Create”, to update an existing one, choose “Update”.

43

Unit 4: SAP Java Administration Lesson 4: Java Engine Configuration and Tuning Topic 4: Use of Template Configuration Tool At the conclusion of this exercise, you will be able to: • Work with the Template Configuration Tool • Size your Web AS Java installation, using different tuning/sizing templates. Your company wants to implement a new SAP Enterprise Portal. As system administrator, you would like tune and size your Web AS infrastructure.

1-1

The Management Console before applying the Template Configuration Tool template.

2 Java server processes are running. 1-2

Run the Template Configuration Tool from 44

G:\usr\sap\ABC\SYS\global\TemplateConfig\cfgtemplategui.bat

Note: The Template Configuration Tool is available from Web AS 6.30 SP7 on. You should have ABC (Web AS 6.30 SP7 stand alone) already installed. click Next

45

click Next

46

Click Browse to navigate to the template you want to apply.

47

Choose J2EE-Engine-only.zip template and click Open

48

Change the instance directory to the Java instance (JC40) Click on Instance dir, Browse button and navigate to JC40 folder:

49

Click Open.

50

Click Next:

51

Click Next:

52

Click Next:

53

Click Next:

54

Activate the Backup and click Next

55

Click on the Finish button:

56

Press OK. 1-3

Restart the ABC the changes to take effect.

57

The Java server instances are 3. Also you can use the Config Tool to check the new Java parameters.

58



© SAP AG 2004, Web AS Java Backup and Recovery

1


Lessons:






2

Web AS Java Backup and Recovery

SAP AG

3

Web AS Java Backup and Recovery: Lesson Objectives

After completing this lesson, you will be able to: z Plan you Web AS Java Backup process z Perform Backup and Recovery every time when it’s needed z Recover a J2EE Engine after a disastrous breakdown of the system


4

Introduction The SAP Web Java provides the complete infrastructure to run SAP NetWeaver 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 be recovered 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 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.

5

Aspects of a Backup and Recovery Concept A Backup and Recovery concept should answer the following general questions:

Which system components and which data need to be backed up? Which backup methods shall be used (online/offline) depending on the data storage type (File system, Database)? What is the backup time and frequency (how often backup should occur, how long to save the tapes, etc)? Which tools and media should be used (amount of media required, available resources)? What are the test and verification procedures?

What backup strategy should be used under what situation? What measures have to be taken to enable a recovery after a disastrous breakdown of the system?

What are the recovery method and recovery windows?

How the recovery has to be carried out?


Use - The backup of the J2EE Engine and the concerning database prevents you from data loss and is essential for a recovery after a breakdown of the system. For Backup following factors must be considered: System components Type: online/offline Cycle (number of tapes needed, at most 1 month as cycle ..) Time & frequency (dep. On OnLine<->OffLine: affect on performance, …) Tools & media. Recovery method, recovery time windows Testing and Verification Strategy for backup

6

Which Backup Methods shall be used (online/offline)? TREX

1. Physical distribution?

WebAS JAVA

Directory path

2. What to backup?

Application data

Configuration data

Software data

3. Where stored? DB

24x7

File system

Database

4. Risks and dependencies?

R/3 CRM

Online

Availability of the component

Actions that should be avoided

Dependant systems

5. Backup type

Offline


The backup method and requirements of a specific system component mainly depends on the: Type of data that the component holds Data storage location Requirements to this component

7

Delta: Server Data Storage Web AS Java 6.20 – 6.40 Web AS 6.20 writes

Web AS 6.40 writes

Application data Application Software Configuration Files

into various locations:

Application data

Application Software

Configuration Files

into DB only!

FS and DB BOOTSTRAP: File System synchronized with DB content

Applications Applications DB

DB J2EE Engine 6.20

J2EE Engine 6.40

[Applications on Web AS Java 6.20]

[Applications on Web AS Java 6.40]


Note: The SDM repository stores its files during deployment on the file system into directory /usr/sap///SDM. The SDM repository cannot be restored by using the bootstrapping mechanism. The SDM only keeps 'old versions' of packages and versioning information. Other than during deployment, there is no activity on the SDM file system. Therefore it can be backed up like a simple static file content.

8

Backup Strategies

Online Backup

Offline Backup

All components are stopped and their files can be copied easily

Consistent restore should be successful every time

Downtime necessary

All components are up and running Online backup procedures are vendor specific No Downtime required Consistency of some administration data needs to be ensured organizationally Note: Not all complex persistence write operations (to DB or FS) of Java/J2EE applications have top level 'enclosing transactions‘.


The backup strategies all depend from the life scenarios and system landscapes. Both the offline and the online backups must be performed on a regular basis for every productive system.

9

SAPJ2EE Backup How distributed

Usually in Production environment SAPJ2EE is installed as a cluster

All SAP J2EE engine files and deployed applications (Portal, CM) are located in the DB and synchronized to the local directory /usr/sap//*

Important data for backup:

Location

1.

WebAS Database (SAPJ2EE, Applications DB)

1.

Database

2.

J2EE Engine Cluster

2.

(a) /sapmnt/* (b) /usr/sap//*

file system on all the application servers Deployed applications

LogFiles

3.

Software Deployment Manager (SDM) file system

3.

SDM under /usr/sap//*

4.

In case of an disk image: Operating system

4.

File system (operating system specific)


A file system backup of the Software Deployment Manager (SDM) should be performed after software deployment and after the implementation of patches. If SAP J2EE Engine is mostly used for development, include the SDM backup in your daily routine!

Note: Locations: 1. Database: If deployed applications are using other but the Web AS Database, a regular backup of them should be performed as well.

10

Databases - Backup Strategies

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 the online-documentation:

MySQL MaxDB (SAP DB) refer to SAP NetWeaver → Application Platform → Databases → MySQL MaxDB → Basic Information → Database Administration → 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 → Database Backup.

IBM DB2 Universal Database, refer to SAP NetWeaver → Application Platform → Databases → IBM DB2 Universal Database for iSeries → SAP Database Guidelines: IBM DB2 Universal Database for iSeries → Backup and 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 your backup procedure, refer to SAP Note 320457.

11

MaxDB - Backup Strategies SAPDB SAPDB home home directory directory :\sapdb :\sapdb

When When backup backup data: data:

When When restore restore data: data:

Perform Perform aa complete complete data data backup backup on on each each day day of of production. production.

The The more more up-to-date up-to-date the the data data backup is, the fewer log backup is, the fewer log entries entries need need to to be be reproduced. reproduced.

Or Or do do incremental incremental data data backup backup on on each each day day of of production use of the production use of the database. database.


Ensure enough disk space for MaxDB operation!!! The MaxDB stops to operate if there is not enough space a log file to be written.

Activate automatic log backups (autosave log mechanism). If automatic log backups is not in use: Make regular checks to see whether there is enough memory in the log area. Make at least one interactive log backup on each day of production use of the database.

Tapes containing backups should not be directly overwritten with the next backup.

Here is only given the Backup strategy of MaxDB. The Backup strategies for other databases should be taken from the Online Help. For more information regarding MaxDB Backup refer to the online help.

12

SAPJ2EE: Prepare for DB Online Backup

Recommended Steps for a DB online backup:

SDM should not be running during backup (no Deployment)

Schedule a short period of inactivity of Web AS administrators to reduce the probability of inconsistencies.

Schedule a short period of inactivity of end users to reduce the probability of inconsistencies

For every SAP application running on your SAP J2EE Engine refer to the corresponding Solution Manager Guide and carry out the described backup procedures.


Note: For Enterprise Portal 6.0 on Web AS 6.40 backup strategy refer also to the EP documentation !!!

13

File System Backup The following directories should be backed up regularly:

/sapmnt// * (Central directory to store centrally essential executables, configuration and profile)

/usr/sap// *

The SDM repository, which resides once on the central instance, needs to be backed up after any installation, upgrade, patching, deployment:

/usr/sap///SDM/*

For backups of logfiles, do a file system backup of

/usr/sap//* - log file directories are located under the path of each dispatcher | server per instance

In case of a recovery, restore the file system /usr/sap/
Delete the following directories /usr/sap/ / /j2ee/cluster/server/ apps | bin | cfg | dtd | temp /usr/sap/ / /j2ee/cluster/dispatcher/ bin | cfg | dtd | temp


14

SAPJ2EE OFFLINE Backup OFFLINE Backup is fully supported with WebAS 6.40. SAP assures, that a correctly performed OFFLINE backup is consistent and thus can be restored successfully. When performing an OFFLINE Backup the following components of an installation must be shut down:

All J2EE Engine processes on all machines

All DB processes

All TRex processes (for EP)

SAP recommends strongly to perform OFFLINE backup on a regular basis (e.g. weekly or bi-weekly).


The offline back up requires “down time”. Usually all requests in this timeframe must be redirected to kind of “Sorry page”. Please read the Enterprise Portal Backup strategy if you run EP on this Application Server.

15

Offline Backup Procedures Offline Backup Shutdown all services on each application server. Perform Backup of the necessary directories and databases.

„Quick“ Offline Backup Motivation: Making a quick Snapshot and write that to a tape while the Application server runs again Procedure:

Shut down all services on each application server

Copy all files quickly to a fast storage device e. g. special hard disks (offline file 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 long time that required for such a procedure. A workaround can be implemented by using a “Quick” offline Backup. The idea is to use a special hardware that allows to perform a quick snapshot of the necessary directories or complete hard disks (several seconds or a minute). After this snapshot the Application server 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 of server restart but the backup is consistent.

16

Restore J2EE Engine after breakdown

Recommended Steps for a J2EE Engine restore:

Restore Java Instances

Restore Databases

Restore SDM

Restore Deployed Applications

Restart J2EE Engine


Restore 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 : 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//JC) 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 find these guides on the SAP Service Marketplace. Restart Restart the J2EE Engine. Result The J2EE Engine is restored with the last backup.

17

Web AS Java Backup and Recovery: Lesson Summary

You should now be able to: z Plan you Web AS Java Backup process z Perform Backup and Recovery every time when it’s needed z Recover a J2EE Engine after a disastrous breakdown of the system


18



© SAP AG 2004, J2EE Engine Configuration and Tuning

1


Lessons:






2


SAP AG

3

Java Engine Administration: Lesson Objectives

After completing this lesson, you will be able to: z

Understand the Web AS load balancing concepts

z

Understand the Web AS high availability and failover scenarios

z

Use the Template Configuration Tool


4

Load Balancing High Availability and Failover OutOfMemory Troubleshooting Template Configuration Tool

5

Load Balancing Goal: optimal distribution of load on all available resources

2 Types of Load Balancing

Load Balancing between SAP WEB AS Instances

Load Balancing by J2EE Dispatcher


Load Balancing Between many SAP Web AS Instances (1) You can also start a system with many J2EE dispatchers, for which the SAP Web Dispatcher or another load balancer is already activated as a Web switch. More information about this Load Balancing can be found in the documentation of the SAP WEB Dispatcher. Load Balancing by J2EE Dispatcher (2) In the J2EE Instance the J2EE Dispatcher distributes the incoming requests among the Server Processes it is connected to. When the first request arrives at the dispatcher for distribution, the dispatcher executes the load balancing function. Then the dispatcher can guarantee that subsequent requests will be distributed to the server process that is processing this session.

6

Load Balancing between different J2EE Instances


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 register it 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: z All J2EE dispatchers with their HTTP ports to which the SAP Web Dispatcher can forward requests. z The capacities of the connected J2EE engines, so that the SAP Web Dispatcher can use the weighted round-robin procedure. z For this the SAP Web Dispatcher simply needs, in its profile file, the port where it can reach the Message Server (parameter ms/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//SYS/exe/run The SAP Web Dispatcher can be used for load balancing in the following scenarios: z J2EE-only scenario, as described here. As all requests are forwarded to J2EE, all the distribution procedures using the URL prefixes in the SAP Web Dispatcher documentation are not relevant. z ABAP-only scenario z Integrated scenario (J2EE+ABAP)

7

Load Balancing by J2EE Dispatcher

J2EE Dispatcher is using Load Balancing System for load balancing of various request types

Load Balancing is used by distributed services only

Detailed procedure of Load Balancing depends on the distributed Service

HTTP Requests z

Homogeneous Load Balancing

z

Heterogeneous Load Balancing

RMI/P4 Requests

RMI/IIOP Requests


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

Load Balancing is only used by distributed Services. These are Services where one part of the service is 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 J2EE dispatcher 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 object resides is encoded into the request, so that consequent requests to the same object are dispatched to the same server process.

8

Load Balancing by WEB Application (HTTP) 2 different types of load balancing are possible Homogeneous Load Balancing

Request reaches Dispatcher

Load Balancing System choose a server process that have a HTTP Provider running

State of HTTP Provider are monitored by Load Balancer

Heterogeneous Load Balancing (default method)

WEB Applications are invoked and identified by a unique application ID

HTTP Provider keeps a list of application ID’s an server where the applications are running on

WEB Container notifies the HTTP Provider if Applications are started

Use of Cookies for providing session related information


Homogeneous Load Balancing 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 heterogeneous Load Balancing When the HTTP Provider Service is not configured for heterogeneous load balancing, it relies entirely on 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 server process from the cluster elements that have an HTTP Provider Service running on them. The state of the HTTP Provider Service is monitored by the Load Balancing System to prevent it from choosing a server 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. Three scenarios are possible: z The incoming request has an application cookie attached. The HTTP Provider Service gets the value of the cookie and directs the request to the server with the corresponding ID. z The incoming request has no application cookie attached. The HTTP Provider Service checks its records for running applications with the application alias that matches the alias used in the request URL. If a single record is found, the request is directed to the server process where the application is running. If more then one record is found, the server process that will process the request is chosen randomly. z The incoming request has no application cookie attached and the HTTP Provider Service finds no records that match the requested application alias. Then the request is directed to the least busy server process in the cluster.

9


10

High Availability and Failover A J2EE cluster has the following single points of failure (SPOF):

Database

Enqueue Service

Message Service

dispatcher and server processes) represent no SPOFs in the sense that a breakdown in one of them would not affect the entire system


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 a breakdown in one of them would not affect the entire system. The dispatcher is stateless, this means that running transactions are not hindered. It can be restarted, or from the outset, two dispatchers can be started. If a server process fails, the session is terminated. One way of getting round this problem is to make the session persistent.

There are ways for providing session persistent Applications, but these opportunities have to considered during application design. With J2EE Engine 6.20 there were no Central Services, and each cluster element communicated with all 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 this communication schema is that the number of connections only increases linearly with the number of server processes and not quadratically as in the earlier procedure.

11

High Availability for SAP Web AS

CI

CI

Message Server Enqueue Server

Replicated enqueue cluster

repl. enqueue

Appl. Server DB

Appl. Server

Load balancing (redirect)

Appl. Server

DB

Cluster or standby DB. DB reconnect

Multiple application servers © SAP AG 2004, J2EE Engine Configuration and Tuning

The database, enqueue, and message services in a standard SAP system cannot be made redundant by configuring multiple instances of them on different host machines: this means that they are single points of failure (SPOFs). With NetWeaver Technology, SAP provides a proven, scalable, fault-tolerant, multi-tier architecture. The individual components can be protected either by horizontal scalability – that is, the use of multiple components that tolerate the failure of individual components – or by cluster and switchover solutions. The database is a central building block in the SAP component. There are different methods of protecting databases against failures. Cluster; two opposite nodes of a cluster - If one of the nodes fails, its resources are transferred to the remaining node, so that the database host and the central instance then run on this remaining host. Standby; A copy of the primary database is replicated on a second database host and can be used if the primary database fails. The enqueue service is a critical component of the SAP system. The enqueue replication service enables the lock table to be replicated on a second server, the replication server. A copy of the lock table is maintained on this server. If the enqueue service fails, a new enqueue service is started on the replication server using a fail over solution (cluster, partner solution) and this replication service creates a new lock table from the copy of the lock table. To avoid the single point of failure with the message server, this server must simply be restarted quickly. It can be restarted automatically in a few milliseconds using cluster technology. The assignment of user logons to application servers occurs during logon. Application servers can be combined in logon groups, whereby logon assignment depends on the load. In the event of application server failure, the user can log on to another application server in the logon group. However, the data from the user session on the original application server is lost. In a high availability SAP system, you can protect vulnerable services, such as the enqueue, message, and database services by using, for example, cluster environments with switchover solutions. High availability for the database should be part of a system-wide strategy for improving the availability of your SAP system.

12

High Availability for SAP Web AS

No single point of failure

CI Message Server Enqueue Server

Transparent load balancing

CI

Replicated enqueue cluster

repl. enqueue

Web Disp. Appl. Server DB Web Disp. Appl. Server

Load balancing (redirect)

Appl. Server

DB

Cluster or standby DB. DB reconnect

Multiple application servers © SAP AG 2004, J2EE Engine Configuration and Tuning

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 distribution of requests to multiple Web ASs. Configuration and load distribution are based on information that the Web dispatcher regularly receives from the message server. In contrast to message-server based load balancing (redirect), this setup has the advantage that only one address and one host name have to be known externally, for which bookmarks can be used. Also, separate, official IP addresses and server certificates do not have to be provided for each server. In the event of SAP Web AS failure, rerouting to an available web server occurs automatically.

13

Failover for J2EE WEB Applications J2EE Engine provides fault tolerance for J2EE Server

J2EE Engine implements a mechanism for HTTP session replication (Session Failover Service)

At the end of a request-response Cycle the HTTP session is replicated in a persistent storage (file)

In case of system crash the storage is used to retrieve all lost session states

Replication is done by Java Serialization Technique

certain tradeoffs – performance on the one hand, and restrictions to the application e.g.. JDBC Connection

Failover has to enabled by deployment descriptor / or by HTTP Sessions via setting an Attribute in the Application


The SAP J2EE Engine provides a high degree of fault tolerance for the J2EE Web applications that are deployed 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 Java serialization techniques, which is the only possible way of doing it within a Java Virtual Machine. This technique has certain tradeoffs – performance on the one hand, and restrictions to the application on the 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 JDBC connections, they must be closed and set to null, so that session is serialized. You can use the sessionWillPassivate method of the HttpSessionActivationListener interface to receive events when the session is about to be switched in passive state.

Enterprise JavaBeans serialization is done by the EJB Container. Enterprise beans are serialized by the EJB Container when they are involved in an HTTP session that is serialized. There are also Programming requirements that have to be kept. Do not store large objects into the session because the application overhead becomes significant.

14

Failover for RMI-P4 Applications failover services for RMI-P4 applications RMI-P4 provides a transparent failover for clustered remote objects It implements a mechanism for migrating instances of those objects to other available server processes mechanism does not deal with preserving any state of the remote object after migration, this remains the developer’s responsibility


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 the server 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 in case a server process crashes. This mechanism does not deal with preserving any state of the remote object after migration, this remains the developer’s responsibility. The process of migration of the remote object between cluster elements is depicted in the diagram above: z In order to call methods on a remote object, a client must obtain a reference to that object. The reference 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 longer available. Therefore, when the J2EE dispatcher receives a request from the client to that server 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 on the 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 with access 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.

15


16

Problem Case: OutOfMemory Error Message: OutOfMemory What does it mean? In the SUN virtual machine there are two reasons why an OutOfMemoryError might occur, because the SUN VM uses two different memory blocks for allocating objects and for loading classes. So possible reasons are: The VM cannot allocate memory for a new object because there is no space in the heap available. A classloader tries to load a new class but cannot do so because the perm space of the memory is full. As the second reason has appeared to be more likely, we have a look at the problem analysis and solution for “running out of perm space”. http://java.sun.com/docs/hotspot/gc1.4.2/


17

Analysis Procedure 1) Start the Config Tool -> Instance -> Server 2) Configure the Java Settings with the following parameters: -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps 3) Restart the cluster 4) View the log \sysID\instID\work\std_server0.out and search for the garbage collector output, containing values for the Perm size:

space allocated before the GC

space after the GC

free space If the perm space is running full, this number will go towards 0 and you will see frequent long lasting GCs!


18

Troubleshooting: Change Configuration

In the Config Tool adapt the Java parameters of the server to your needs. Default: -Xms <$heapSize/2>m -XX:NewSize=<$heapSize/12>m -XX:MaxNewSize=<$heapSize/6>m -XX:NewRatio=3 -XX:+DisableExplicitGC -XX:MaxPermSize=128m © SAP AG 2004, J2EE Engine Configuration and Tuning

19

Problem Case: JVM Crash Problem: JVM Crash Possible Reason: C2 Just-in-Time Compiler (JIT) causes problems The C2 JIT compiler shipped with the SUN Java VM 1.4.2_x is used when the -server option is specified for the VM. Most of these problems do not occur when the client VM is used (-client)!

1.) Toggle between -server and -client VM option. (two different JIT compilers). 2.) Try -Xint option. 3.) Enable compilation tracing: Add the parameter -XX:+PrintCompilation Run the VM with JIT option -server -client The VM now traces all compiled methods at the console. The last compiled method is probably the one which causes the problem!

Try: -client -Xint -XX:+PrintCompilation


Java Engine running an Enterprise Portal 6.0 should be started with –server option!

20


21

How to use the Template Configuration Tool

The Template Configuration Tool is a tool used for configuring the J2EE Engine. To configure the system properly, the tool uses specially designed templates for each component.

The Template Configuration Tool provides wizards that guides through the process of choosing which function to use, selecting the appropriate templates, and filling in the required parameters.

The Template Configuration Tool is instance-based – that is, it configures the J2EE Engine based on the available hardware resources on a particular host, as well as some additional settings such as allocated memory. The tool should be started separately for each Java instance.


The latest information about the Template Configuration Tool and the related configuration templates can be found in SAP Note 739788. The Template Configuration Tool is started using a script file cfgtemplategui.bat located in the installation directory /usr/sap//SYS/global/TemplateConfig

22

Configuration tool with component adapters Template

1

Component 1 parameters

read

2 call

Component 2 parameters

Java Java Java Interface Interface Interface

J2EE engine parameters

Server Configuration Tool J2EE engine config

J2EE Template processor Component 1 adapter

3

apply

Component 2 adapter

Component 1 config Component 2 config

Template based server configuration tool configures J2EE engine Components adapter: Java class that implements a simple Java interface

Loaded and called by Server configuration tool

Adapter reads component section and applies it to component config

Content and format can be chosen freely (responsibility of component) Access API and logic can be chosen freely (responsibility of component) Prefer: Limit semantic knowlege in adapter, prevents modification and harder to update


The template configuration tool makes technical setup of Java components easier and safer. It uses so called "templates“ and adjusts low level settings of the engine and Java VM as well as higher level settings of NetWeaver components running within the engine. The values are: low level settings of the engine and Java VM, like number of server processes and memory consumption settings of NetWeaver components

23

Covered Scenarios and Deployment Options NW Scenario

Deployment option

Template

Portal

Portal

Portal with KM

Portal

Portal with KM and RTC

Portal

Standalone UWL

Portal

BW

BW

BW

BI broadcasting

BI broadcasting

Portal

MI

MI

J2EE

XI production system

XI

XI development system

XI-Dev

Standalone Adapter Engine prod

XI

Standalone Adapter Engine dev

XI-Dev

XI with JDI

XI-with-DTR

JDI

JDI-DTR-and-CBS

EP

XI

Developer workplace

KW

JDI with separate build server IKS production system

JDI-DTR-only JDI-DTR-and-CBS J2EE White: Duplicates


24

J2EE Engine Services: Lesson Summary

You should now be able to: z Understand the load balancing concepts z Understand the high availability and failover

scenarios z Use the Template Configuration Tool


25



© SAP AG 2004, Web Infrastructure for SAP Web AS

1




2

Unit: SAP Web Infrastructure

Lessons:

Web infrastructure for the SAP Web AS

Installing the SAP Web Dispatcher


3

Web Infrastructure for the SAP Web AS

SAP AG

4

Web infrastructure for the SAP Web AS: Lesson Objectives

After completing this lesson, you will be able to: z Understand the SAP Web infrastructure. z Understand the role it plays for the robustness, performance and cost of ownership of a business solution. z You will learn some solution approaches for building a business-ready Web Infrastructure for Web AS.


First, we will explain briefly how the SAP Web AS works and what we mean by Web infrastructure (or HTTP infrastructure) in the first place. (In short, everything needed to get HTTP requests from the browser or any other Web client to the server and the response back). It is important to realize that the infrastructure plays a crucial role for the robustness, performance and cost of ownership of a business solution. We will talk about how the requirements that business Web applications impose upon the infrastructure differ from those of other Web applications. In the second half of the lesson we will outline some solution approaches for building a business-ready Web infrastructure for Web AS. One way of building a Web infrastructure for SAP Web AS is based on components that SAP delivers as part of its technology offering (most notably, a software called Web Dispatcher). The other way is to use standard, third party Web infrastructure components, which is just as well since SAP Web AS is based on HTTP as a standard protocol.

5

Introduction SAP Web AS Technical Requirements

SAP’s Load Balancing Solutions Web Dispatcher Scenarios Alternative Technologies Summary

6

Introduction Applications require appropriate technical infrastructure

Technical infrastructure must ensure Performance and scalability High availability

Web infrastructure plays a crucial part

Security Smooth network integration Low cost of ownership

Technical infrastructure depends on the application Consider technical infrastructure at an early stage in a project!


In order to run an application stable, with high performance, security and low costs, the technical infrastructure must support the application in an optimal way. Technical infrastructure has a very broad range from computer hardware, operating systems, storage devices, high availability solutions to networks, load balancing devices, firewalls etc. Web infrastructure – consisting of every piece of equipment needed to convey HTTP requests between browser and server – is a crucial part of the technical infrastructure. It deserves special treatment, especially since the subject is both complex and new to most SAP users. Applications impose special requirements upon the technical infrastructure. This was obvious in the days of proprietary protocols. However, even when using Web standard protocols, the way in which the protocol is used differs strongly between different applications. Therefore we have to describe the requireme7nts of SAP Web applications and describe solutions for these requirements.

Please: Give the IT folks a chance and integrate them into Web projects at an early stage. Integration of new applications into corporate IT infrastructure is a task that does not happen with a snip of your fingers.

7

SAP Web Application Server

ABAP based Web applications

Internet Communication Manager for HTTP access

J2EE based Web Applications


SAP's modern Web applications are based on SAP Web Application Server (Web AS). Here is a high level picture of its architecture. It supports both ABAP as well as J2EE based applications. A 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 Enterprise Edition (J2EE) standard. Technical infrastructure (as discussed I this presentation) is not affected There is also a J2EE-only version of Web AS, which consists of only the green part of the graphic above.

8

SAP Web Application Server

This presentation is about HTTP infrastructure

It applies both to Web AS 6.40 ABAP and J2EE Web AS 6.40 J2EE-only


The remainder of the lesson will focus on using SAP Web AS as an HTTP server. What has to be done in order to offer a business web application in a productive way, e.g. in the Internet? Seems like a trivial question: You find yourself an Internet provider, by a router and then you are online. However, living and surviving in the Internet is little more complicated than that. Especially with a business critical application... What you need is what we call a Web infrastructure. What we mean by this term is everything that is needed to get HTTP requests from the browser or any other Web client to the server and the response back. Some components involved in this are networks and routers, wide area network connections, load balancing devices, caches, DNS servers and many more.

9



10

Requirements of Business Web Applications CPU intensive ÄScalability achieved by load balancing Transactional ÄStateful user sessions require session persistence Access control ÄUser authentication required Security ÄEncryption of communication (Secure Socket Layer – SSL) ÄApplication servers and networks need protection Dynamic content ÄLow fraction of cacheable content


CPU intensive Î Load balancing

CPU usually dominates throughput

Transactional Î Requires session persistence

Almost every SAP application

Access control Î Authentication

Variety of methods

SSO Î influence on DNS domain structure

Security of communication Î SSL

Everywhere

Option X.509 client Certificate

Security of application servers Î Firewalls

Currently: HTTP Access to business systems required

Dynamic content Î Low fraction of cacheable content

Depends on application and usage patterns

11

Load Balancing Mechanisms (Client Side) Redirections Simple Bad user experience and maintenance

DNS based methods Perhaps OK for intranet OK for global load balancing Generally not OK for server load balancing


12

Load Balancing Mechanisms (Server Side) Load balancing device Transparent for client Always the same URL One official IP address for all application servers One server certificate for all servers Technically challenging Usually preferable

Application Server Load Balancer Application Server

Application Server


13

Stateful User Sessions Complex applications are usually stateful Hold database locks Store intermediate SQL results etc. 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 duration of a user session. The protocol itself offers no provisions to return a subsequent request to an already established session. he Web AS uses a session ID which is returned with every request in order to recognize the user session in which each request has to be processed.

14

Load Balancing + Stateful User Sessions Requirement: Session persistence (Load balancer must ensure that user gets back to same server)

Session State

Load Balancer

1st

2nd

u req

re q

est

ue s

t

Application Server

Application Server


First request from user establishes session in application server. If subsequent request would be directed to a different server, session context is not known there so context would be lost. Worse, if the first context holds any locks, second session would not be able to access locked items. There is a conflict between application (stateful) and protocol (stateless) Load balancing device must ensure that all requests belonging to an application session are directed always to the same application server!

15

Persistence Mechanisms Session ID (Cookie or URL) Detect actual application need for session persistence Requires no state in load balancer, because SAP session ID contains application server instance name Requires access to clear text HTTP request

IP address of client Works also with encrypted traffic Problems with proxies Î not good for Internet No way to detect stateless requests Problems with alternative host names

Cookies inserted into the data stream by load balancer Works "out-of-the-box" Problems with some SAP applications Requires access to clear text HTTP request


These mechanisms can be used to ensure session persistence. Two of the mechanisms need to look at the data or even modify data passing through.

16

Secure Socket Layer Encryption is required for business applications Protect user credentials (e.g. passwords) Data security

Secure Socket Layer (SSL) SSL encrypts entire communication between browser and server Server authentication (mandatory) Browser verifies, that server certificate matches URL

Client authentication with X.509 certificates (optional) Server takes identity of user from browser certificate

End point of SSL session is either Application Server (end-to-end security) Web infrastructure component (in-depth security)


Encrypted traffic cannot be looked at or even modified by the load balancing device. Way out: Load balancer acts as the end point of SSL encryption. This enables better session persistence mechanisms and also inspection of requests before they reach the application server. This is sometimes called "in-depth security". A different security philosophy is "end-to-end security". It assumes that the server itself is secure and the connection between client and server is the most vulnerable asset. This philosophy prohibits the termination of SSL sessions by any intermediary. Therefore, end-to-end security does not go together well with load balancing, as it does not allow the use of session ID or cookies for session persistence. IP based persistence is not recommended in the Internet.

17

Load Balancing Design Criteria Load balancing mechanism (client or server side) End-to-end SSL or SSL termination in load balancer. Criteria: In-depth vs. end-to-end security, need to inspect traffic Persistence mechanism (session ID or IP address) Client certificate authentication

Cost of device Performance Robustness and high availability Ease of configuration and operation (TCO) Integration into existing infrastructure and security policy


18

Other Application Specific Requirements (Examples) All servers belonging to one portal "domain" should be in one DNS domain, and only them. DNS domain restrictions for Single Sign-on (SSO) cookie (workaround available) Security considerations for SSO 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 be complete. This is just to make you aware that there are more things to care about. These requirements do not apply to all applications. We are currently working on a comprehensive list of requirements.

19



20

Message Server Based Redirections

om m e .c eb.ac e . c om w / / : 2 .a c m http b e w / http:/ tion: Loca

Message Server Central Instance

RDBMS

Dialog Instance http

R em

://we

a in in

b2.a c

g us

m e .c

er se

om

ssio

n

Dialog Instance


A disadvantage of the Message server load balancing is the redirection of the request, and difficulties to store the Website as favorite.

21

Message Server Based Redirections Works out-of-the-box (add one profile parameter) Just like SAPlogon No problems with session persistence & SSL But: user experience not optimal Confusing No bookmarking Superfluous password dialogs

Each server needs own SSL certificate Administration overhead

Suitable only for internal systems


Simple load balancing built into SAP Web Application Server based on redirections Not well suited for the Internet because of general problems with redirections Not easy to integrate into firewall Need dedicated servers for internal and external (server certificate!) Perhaps OK for intranet, but consider inconvenience for the users Not generally recommended for production systems

22

Web Dispatcher

Message Server

SAP Web Dispatcher

Central Instance RDBMS

http://web.acme.com Dialog Instance

Dialog Instance


The SAP Web dispatcher is located between the Web client (browser) and your SAP system that is running the Web application. The architecture is the same as the Internet Communication Manager, see the Internet Communication Manager (ICM). It uses the same HTTP framework and is likewise structured modularly from subhandlers. But unlike the ICM, the SAP Web Dispatcher does not directly pass incoming requests to a work process – it passes them to the ICM of the application server or to a dispatcher of a SAP J2EE Engine. The response from the application server does not pass via the Web dispatcher again to the client – it goes direct to the client (via a proxy, if the network is configured with one).

23

Web Dispatcher Software load balancing server

Automatic configuration retrieval from Message Server Message Server

One URL for all AppServers of one system


SAP Web Dispatcher

http://web.acme.com Dialog Instance

Either End-to-end SSL or SSL termination Optional re-encryption

Load Balancing Session Persistence Request Filtering © SAP AG 2004, Web Infrastructure for SAP Web AS

24

Dialog Instance

Web Dispatcher Features Web Dispatcher is a software load balancer and application layer gateway for SAP Web AS No full reverse proxy – not meant to be! Software delivered free of charge as part of SAP Web AS "Near zero" configuration and administration Retrieves system state from message server

Supports SAP Web AS features "out-of-the-box" Persistence mechanisms (cookie formats, URL rewriting) Logon groups, distinguish J2EE and ABAP application ...

Both end-to-end SSL and SSL termination possible Simple request filtering


Web Dispatcher is not meant to compete with hardware loadbalancers for high end applications. It is not meant to compete with fully fledged reverse proxies. It is not a general purpose piece of Web infrastructure. Web Dispatcher is meant to be an easy solution for SAP customers that need a Web infrastructure solution without massive investments.

25

Implementation Area of the SAP Web Dispatcher


The SAP Web Dispatcher was first delivered with SAP Web AS 6.20 (although it can also be used with SAP Web AS 6.10 systems). Its configuration and operation are simple. The customer receives here a product that is designed for a throughput up to around 3000 hits per second (HTTP). The SAP Web Dispatcher handles SAP-specific load distribution and is sufficient for the vast majority of cases. In cases of extremely high throughput, a customer can, of course, purchase hardwareWeb switches from third-party vendors. This often offer additional features such as hardware SSL acceleration. The SAP Web Dispatcher is a small program (closely related to the ICM) without need of an additional server with a database in the DMZ are therefore entirely

26

SAP Web Dispatcher: Server Selection & Load Balancing


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 is the 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 all application servers with SAP J2EE Engines. If the request is an ABAP request, the !DIAG group is selected. This group consists of all application servers with dialog work processes. A logon group is only used if this logon group (maintained in transaction SMLG) is explicitly specified in the ICF service.

Thee SAP Web dispatcher distributes the requests in turn within the selected server group, weighted according to the capacity of the individual servers. The capacity is calculated in the case of an ABAP request from the number of dialog work processes and, in the case of a J2EE request, from the number of server processes. The SAP Web dispatcher collects the information about the server groups from the message server. The HTTP interface of the message server allow you to display the information with a Web browser.

The internal structure of the SAP Web dispatcher is based on the ICM process. A profile file is also used in this case to determine the settings with which the SAP Web dispatcher is started. You can easily copy and use the executable file (sapwebdisp.exe) that SAP makes available for all supported operating systems to a separate host, together with the profile.

The SAP Web dispatcher essentially only needs to know the port at which it should receive HTTP(S) requests (parameter icm/server_port_) and on which host (rdisp/mshost) and with which HTTP port (ms/http_port) it can access the message server.

You start the SAP Web dispatcher with the operating system command sapwebdisp pf=, where you can set additional options such as trace file and trace level (see the online documentation). You stop the SAP Web dispatcher using a kill command at operating system level.

27

Web Dispatcher End-to-end SSL Mode Pro Client authentication with X.509 certificates End-to-end data security Load balancer is "untrusted" component

Contra Persistence based on client IP address only Load balancing problems

Proxies

End-of-session

But: IP address based persistence usually OK in intranet

No logon groups No distinction between J2EE and ABAP applications Only one Web Dispatcher for every group of servers


28

Web Dispatcher SSL Termination Mode Pro Persistence based on application session ID Logon groups 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 SSL processing is the key exchange during handshake. Afterwards, the bulk encryption/decryption is not so expensive. Keys can be re-used in subsequent SSL sessions, but only between the same communication partners. Therefore, Web Dispatcher and backend application server have to do the expensive handshake only once (every couple of hours) and only have the load of bulk encryption in the mean time. Since there are usually many browsers accessing the system at once, Web Dispatcher has to do the handshake with them much more frequently, typically once per logon. To evaluate how many users the SAP Web dispatcher can serve, you must take the following factors into account:

When a user sends a request, this request can open more than one HTTP connection. Depending on the application a request can open between one and 10 or 20 HTTP connections. The user cannot see how many connections the request opens.

The “think time” is also crucial to the capacity of the Web dispatcher. The think time is the time between two user dialog steps (clicks). During this time there is no active HTTP connection (depending on the timeout).

Another important parameter is the keepalive timeout (icm/server_port_ 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 -> SAP NetWeaver-> SAP NetWeaver Configuration -> SAP Web Application Server-> Management of SAP Web Dispatcher -> The SAP Web Dispatcher Profile Parameters -> Configuration for Large Number of Users. And note number 715400.

29



30

Web Dispatcher on Application Server Web Dispatcher on central instance server or other app. server

On CI not generally recommended for SSL termination © SAP AG 2004, Web Infrastructure for SAP Web AS

SSL termination imposes high load, this may not be desirable on central instance. Can use other application server or separate computer as well. Possible scenario for Internet also, behind a reverse proxy, for example.

31

Simple Web Dispatcher High Availability Web Dispatcher on central instance server for fail over

High Availability Cluster


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.

32

Advanced Web Dispatcher High Availability

SAP Web Dispatcher

Redundant Network Infrastructure

FailOver

Corporate Network SAP Web AS

SAP Web Dispatcher

High availability cluster © SAP AG 2004, Web Infrastructure for SAP Web AS

A separate fail over cluster for Web dispatcher is the high end solution. Another solution is shown later in the presentation: Using a network load balancer to distribute requests between multiple Web Dispatcher hosts. The load balancer also ensures the high availability by health checks of the Web Dispatcher nodes.

33

Web Dispatcher In DMZ Web Dispatcher is an application layer gateway, but does not have full reverse proxy functionality.

SAP Web Dispatcher

Firewall

Firewall

Internet

Possibly filter requests End-to-end SSL or SSL Termination

Encrypted or clear text traffic


34


Layered Security Zones Enhanced Security for internal network DMZ

Internet Service Network

Internet

Internal Network

SAP Web AS

Firewall

SAP Web Dispatcher

Firewall

Firewall

1

Database

R/3, FI, HR etc.

Internet systems

Recommended © SAP AG 2004, Web Infrastructure for SAP Web AS

35

Back-end systems

Web Dispatcher For Multiple SAP Web AS Multiple Web Dispatchers on different (virtual) IP addresses

IP1 443

SAP Web Dispatcher


IP2 443

SAP Web Dispatcher


https://web1 https://web2

Recommended © SAP AG 2004, Web Infrastructure for SAP Web AS

Need one Web Dispatcher for every system. Need separate certificates, because server names differ. Really need separate IP addresses for SSL, because Host header cannot be used with SSL. For clear text HTTP you can do with one IP address and DNS aliases.

36

Web Dispatcher For Multiple SAP Web AS (II) Multiple Web Dispatchers on different TCP ports

https://web

443

SAP Web Dispatcher


444

SAP Web Dispatcher


IP

https://web:444

Not recommended J2EE session cookies overwrite each other. SSL to port other than 443 often not possible © SAP AG 2004, Web Infrastructure for SAP Web AS

Cookies do not distinguish between servers on the same host but on different ports. J2EE engine sets session cookie to path "/", therefore the cookies will overwrite each other. Perhaps there is a way to configure this. Another reason holds for systems in the Internet: Internet proxies often block outgoing SSL traffic to ports other than 443. For example, SAP's proxy does this.

Too bad, because we could use the same server certificate for both systems.

37



38

Other Web Infrastructure Technologies Alternative Technologies Hardware load balancer ("Content Delivery Networking") 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 Web AS can be integrated. These infrastructures are building up by alternative technologies to the SAP Infrastructure Technologies like the SAP Web Dispatcher. The main advantages of reusing the existing technologies are generally associated with the homogenization of these Web technologies across the enterprise. The main disadvantages reside in the lack of integration with SAP NetWeaver scenarios in terms of resource optimization and configuration knowledge.

39

Network Load Balancer

Manual configuration Message Server

Same URL for all AppServers


Web Switch http://shop.abc.com Dialog Instance

Either End-to-end SSL or SSL termination, possibly re-encryption

Load Balancing SSL Session Persistence


40

Dialog Instance

Network Load Balancer Technology Options Simple load balancing switch (layer 2-4) SSL

Î End-to-end

Web Switch (layer 2-7) without SSL termination SSL

Î End-to-end

Web Switch (layer 2-7) with SSL accelerator Termination

Î SSL

Off-the-shelve solutions, appliance type Integrated with network management systems Standard high availability solutions


41

Direct Access to Web AS Through Web Switch End-to-end SSL or SSL termination

Web Switch

Firewall

Firewall

Internet

SAP Web AS

High availability solution

Load Balancing Session Persistence Request Filtering


42

Web Dispatcher with Web Switch End-to-end SSL or SSL termination Network Load Balancer SAP Web Dispatcher Firewall

Firewall

Internet


SAP Web Dispatcher

Load Balancing Session Persistence Request Filtering

No need for session persistence © SAP AG 2004, Web Infrastructure for SAP Web AS

Why? Re-use existing Web switch infrastructure, but no need for complicated configuration, because Web Dispatcher handles all the intricacies of the Web AS server selection and load balancing between several SAP Web AS.

SSL termination on Web switch OK, re-encryption by Web Dispatcher possible SSL session ID stickiness necessary, otherwise excessive SSL handshakes. Use load balancing with fail over capability if present. Second firewall could also be between Web switches and Web Dispatchers, in other words, the Web Dispatchers could also be located in server network. Could install Web dispatchers on application servers. Not useful for SSL end-to-end

43

Integration Into Web Server / Reverse Proxy Integrate SAP Web AS services into Web site

Web Server Internet Static Web Pages

other

/sap*

Reverse Proxy Module

Forward requests for /sap* to Web AS

Firewall

Firewall

443 SAP Web AS

Optional Web Dispatcher for Scaling


Apache can handle this out-of-the-box with mod_proxy. Web switches often have this possibility, too. IIS does not have reverse proxy functionality. You can use SAP's J2EE plug-in for Web AS J2EE-only. Does it work for BSP applications???

BSP applications have a specialty: When you start /sap/bsp/app/start.html, BSP framework will redirect you to /sap(QBSCXKJQB=)/bsp/app/start.html (with some variable characters inside the parentheses, that constitute language, theme and possibly the session ID). The Web server must be prepared to handle this. For load balancing, you can use the Web server, but watch out for complicated requirements of SAP Web AS session persistence. Or you use an additional Web Dispatcher, either on the Web server host, or in the server network.

44

Integration Into Web Server / Reverse Proxy Integrate multiple SAP Web AS into Web site

Web Server Internet other

Static Web Pages

/sap*


/shop*


Firewall

Firewall

443

SAP Web AS

SAP Web AS

Not recommended © SAP AG 2004, Web Infrastructure for SAP Web AS

General problems with cookie overwriting (see description on slide "Web Dispatcher For Multiple SAP Web AS" above) Additional requirements: In the second Web AS configure the application you are using to run on /shop using ICF. In J2EE-only servers, make sure the application URL prefix does not conflict with first server. Do not alter the URL path component in the Web server, for example, map all incoming requests /C11/sap/bsp/app/start.html to /sap/bsp/app/start.html. This will break, because Web AS uses path-absolute URLs to access some resources. There is no way to configure it to prepend the "/C11" to the absolute paths it generates. Therefore, all applications must have separate paths configured in the server itself. Consider also the MIME repository paths! Some applications do not allow configuring their paths, most notably, J2EE application like enterprise portal, for example. In this case it is not possible to run two such applications over the same Web server.

45



46

Summary

SAP Web AS requires HTTP infrastructure.

Business Web applications are more demanding than ordinary Web apps.

Web Dispatcher is SAP's Web Infrastructure offering.

SAP Web AS works also with standard Web infrastructure technologies.


47

Web infrastructure for the SAP Web AS: Lesson Summary

You should now be able to: z Understand the SAP Web infrastructure. z Understand the role it plays for the robustness, performance and cost of ownership of a business solution. z Build a business-ready Web Infrastructure for Web AS.


48

Course: TADMJ1 – SAP Java Engine Administration - Exercises Unit 5: SAP Web Infrastructure Lesson 2: Installing the SAP Web Dispatcher Topic: Installing the SAP Web Dispatcher and 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 load balancing mechanism when you use an SAP system with several SAP Web Application Servers for web applications. This lesson describes 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 a service on Windows.

Lesson Objectives After 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 be added to the landscape to help process the load. To balance the web application load across several SAP Web Application Servers, SAP offers the SAP Web Dispatcher as a software load balancing mechanism.

Business Example ABC Limited, a petrochemical company, installed the latest version of SAP system, SAP Web Application Server. They now have several web applications running and have added dialog instances to help handle the load. As system administrator, you would like to balance the load on these systems by installing the SAP Web Dispatcher.

Lesson Contents Topic: 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 a Windows service Steps to Install the SAP Web Dispatcher The SAP Web dispatcher lies between the Internet and your SAP System. It is the entry point for HTTP(s) requests into your system, which consists of one or more Web application servers. As a "software web switch", the SAP Web dispatcher can reject or accept connections. When it accepts a connection, it balances the load to ensure an even distribution across the servers. 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 need security functions (entry point in the DMZ, SSL, URL filtering), but you simply want 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 is connected directly to the Internet. It requires minimal configuration - you just have to enter the following data in the profile file: • Port, on which the HTTP(s) requests are to be received (parameter icm/server_port_) •

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 profile parameter of the SAP Web Dispatcher (profile parameter ms/http_port) • The SAP Web Dispatcher must be able to contact the HTTP port of the SAP message server. • The following services are activated in the HTTP services tree (Transaction SICF): /sap/public/icman /sap/public/icf_info/*

Figure 1: Web Dispatcher Prerequisites and Profile

See the online help for information on the SAP Web Dispatcher profile and profile parameters.

Importing the SAP Web Dispatcher If you do not have the executable sapwebdisp on your kernel CD or you want to use the 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 → → 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 you install it in a separate directory: Windows: C:\Program Files\SAP\SAPWebDisp UNIX: /usr/sap//sapwebdisp Create the directory for this and unpack program sapwebdisp into this directory. Also copy the associated profile file into this directory.

2. Activate

1. Select service

Figure 2: Activating ICF Service (transaction SICF)

In transaction SICF the services /sap/public/icman and /sap/public/icf_info must be active. If either service is inactive it can be activated by selecting it and choosing menu Service -> Activate.

Starting the SAP Web Dispatcher You start the SAP Web dispatcher with the command: sapwebdisp pf= [-f -t -cleanup shm_attach_mode -auto_restart -version] The optional parameters have the following meaning: • You can use -f to determine the name of the trace file. The standard is dev_webdisp. •

You can use option -t to set the trace level.

•

-cleanup means that common resources (shared memory and so on) are released. This is necessary if the SAP Web dispatcher ran was not stopped in an orderly manner the last time it ran, but was terminated by a crash. -shm_attach_mode determines what should happen to the shared memory of the SAP Web dispatcher. Here, is a number that is a combination of the following values (bit mask):

•

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 exists already, the SAP Web dispatcher ends with an error. This is also the default value, that is, the SAP Web dispatcher behaves in this way if the options -shm_attach_mode and -cleanup are not used. 5: If a shared memory exists already, it is deleted. A new shared memory is then created. 6: The system tries to attach it to an existing shared memory. If a shared memory 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 help section 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=

Installing the SAP Web Dispatcher as a Windows Service

Figure 3: Installing SAP Web Dispatcher as a Windows Service

In Windows you can start the SAP Web dispatcher as a service. It will then always be started automatically whenever the computer is restarted. Call the following: ntscmgr install sapwebdisp -b \sapwebdisp.exe -p "service pf= " stands for the path in the file system where the program is stored, for more parameters as described above. You then see the SAP Web dispatcher sapwebdisp in the list of services.

Solution: Installing the SAP Web Dispatcher and configuring as a Windows service Tasks: 1. Download the latest version of the SAP Web Dispatcher to the Web Dispatcher Directory (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 packet DW.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 under G:/Additional_Files 3. In transaction SICF, check that the following services are active and, if they are not, activate them: /sap/public/icman /sap/public/icf_info

4. Create a profile for the SAP Web Dispatcher (sapwebdisp.pfl) and save it in the Web Dispatcher directory. Use the following values for the parameters: SAPSYSTEMNAME SAPSYSTEM rdisp/mshost ms/http_port icm/server_port_0 icm/server_port_1

of your SAP system System number that is unique on the host Host name of your server twdf#### HTTP port of the message server PROT=HTTP,PORT=80 PROT=ROUTER,PORT=443

Note: The shared memory segment where the SAP Web Dispatcher operates must be different from the segments of the ABAP and the Java stacks, there for the 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 in Web Dispatcher directory. Note: The sapwebdisp.pfl can be created also automatically. Start the Web Dispatcher with the following option: sapwebdisp.exe –bootstrap and follow the wizard.

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_: 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 HTTP The last two parameters specify the addressed SAP system uniquely.

Note: The SAPSYSTEM parameter is used to create shared memory areas and must be differentiated from all other SAP instances on the host of the SAP Web dispatcher.

5. Start the SAPWeb dispatcher with the prepared profile file. The trace should be written to a file, dev_sapwebdisp<##>, where ## is your group number. a) Run the command sapwebdisp pf= -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 started.

6. Check which is the release of the SAP Web dispatcher.

a) Open the command prompt (under Microsoft Windows: Start -> Run... and then enter cmd) and run the command: sapwebdisp –V The system displays output, in which the information that you require appears at the start (patch number). At the end of the list, all problems that are solved with the current release status are listed (with associated SAP Notes).

7. Send a request that is distributed using the SAP Web dispatcher. Call the SAP

J2EE application /Calc using your SAP Web dispatcher. a) In your local Web browser (in the training room), call the following URL: http://:/Calc Note: The application Calculator should already be deployed or you can use some other already deployed application.

8. Stop the SAP Web dispatcher using operating system tools.

a. Determine the process ID (PID) of your SAP Web dispatcher at operating system level of your server. You can find this number, for example, from the output when starting the SAP Web dispatcher, from the trace file dev_sapwebdisp<##> or from the Windows Task Manager.

b. Open another command prompt (in Microsoft Windows, choose Start >Run... and enter cmd). Run the command sapntkill -INT with the process ID that you have just identified.

The SAP Web dispatcher has been stopped correctly.

9. Install the SAP Web Dispatcher as a Windows service with the following command: ntscmgr install sapwebdisp –b \\sapwebdisp.exe –p “service pf=\\ -shm_attach_mode 6” You have to see an appropriate message saying that the Web Dispatcher is properly installed as a service. Note: Do not use relative paths in the installation command, always use full paths.

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 in the list of services.

Note: You can delete the SAP Web Dispatcher Windows service with the command: ntscmgr remove sapwebdisp

Lesson Summary You should now be able to: •

Install the SAP Web Dispatcher and configure it as a Windows service.

TADMJ1+ +SAP+Java+Engine+Administration

Recommend Documents