210772345-5-sap-xi-operations.pdf

8/10/2019 210772345-5-SAP-XI-Operations.pdf

1/105


2/105

2

SAP AG 2003, Title of Presentation, Speaker Name / 2

Maintenance and Operations

Maintenance and Operations


3/105

3


Maintenance and Operation

EP 6.0 Portal

Backup & Restore

Monitoring and support

Deployment

Change Management


4/105

4

For Backup following factors must be considered:

Type: online/offline (SAP J2EE 6.20: data stored in the FS, data belonging to the Portal CONTENT is stored in the

DB. With 6.30 ALL data J2EE and portal data will be stored in the DB). All portal relevant data is stored in the DB with6.20 already.

Cycle (number of tapes needed, at most 1 month as cycle ..)

Tools & media

Time & frequency (dep. On OnLineOffLine: affect on performance, )

Areas (FS, ..)

Monitoring and Verification

Recovery method, recovery time windows

Also, the following EP Components need consideration for design of backup processes:

EP Server

KM

Unification

Connectors

Critical Components are:

SAP J2EE

Portal Server Application

Portal System DB

PCD

User persistence store


Components

Web Application Server (SAP J2EE)

Portal RuntimePortal Runtime

Portal ServerPortal Server

Portal Components Portal Services

Page BuilderPage Builder

Single Components

(iViews)

Single Components

(iViews)

Web ServicesWeb ServicesCachesCaches

User ManagementUser Management

Portal

Content Directory

Portal

Content Directory

ConnectivityConnectivity

Connectors

(JCA)

Connectors

(JCA)

Portal

DatabaseSystem

(repository)

Portal

Database

System

(repository)

User

PersistenceStore

UserPersistenceStore

R/3R/3 EISEIS DatabasesDatabases WebWeb DocumentsDocuments AppsApps

User Man. (WS)User Man. (WS)

iViewiView

RolesRoles

Pages/SystemsPages/Systems

From browser

Knowledge

Management

Knowledge

Management

Unification

Server

Unification

Server

Web

Server

Web

Server

UnifierUnifier

UnifierUnifier

TREXTREX

CMCMCollaborationCollaboration

ACLACL


5/105

5


Comparison EP 5.0 and EP 6.0

Unix platform

SAP J2EE Engine

WEB Server

Unix services

Unix applications

Database Data

LDAP Directory Backup

EP 6.0

Backup Objects

EP 5.0

Backup ObjectsC:\Enterprise Portal\

C:\WINNT\system32\sapportals\

C:\INETPUB\WWWROOT\SAPPortal\

C:\INETPUBPUB\WWWROOT\CommonTools\

\\irj\WEB-INF\

Registry

Database Repositories

TTPSys

TTPRep

Portal-LDAP

Roles, UserMapping and customattributes

Improvement in EP 6.0: Reducing complexity of backup procedures!


6/105

6


B&R of application data

The portal has many physical components, and therefore a

comprehensive utility for backing up the portal is not

deliverable.

The Enterprise Portal consists of the following components:

Portal Server (with UME)

Knowledge Management (CM, TREX)

A Backup and Recovery Guide will be made available to address

what is necessary to create a sound data recovery policy


7/105

7

Although the portal stores some configuration and log files outside of the database,

these are not considered critical to system operation.


B&R of application data

Cases where B&R of database will be sufficient:

Portal Server (DB)*

UME (DB)*

KM CM (DB)

Cases where B&R of database will not be sufficient:

UME (LDAP & DB)

KM CM (DB & FS)

KM TREX (time needed to recreate index files is too long)


8/105


9/105

9


What we have / not

EP 6.0 B&R Doc

Description of how to backup & restore EP 6.0 using any sw tools

Online backup All consistency / inconsistency problems are addressed and

description of how avoid them are described in EP 6.0 B&R Doc.

To completely avoid present and future problems with consistency,

every component inside EP must have mechanism for consistency

checking

support most common B&R strategies

Using EP 6.0 B&R Doc, customer can easily create (support) B&R

strategies, or include in exiting B&R strategy he already has inside a

company.


10/105

10



EP 6.0 Portal

Backup & Restore


Deployment

Change Management


11/105


12/105

12


Logging & Monitoring

Inside

The Portal


13/105

13


Logging&Tracing inside the Portal: Overview

Logging&Tracing functionalities are available inside the Portal:

Multiple monitors for different type of performance/load information

Activity Tracing can be switched on per user to measure the

performance of single components. The results are displayed in anexternal Log Viewer.

Logging console to display all logging messages of portal

components.

Furthermore the portal provides some monitoring functions:

Monitoring iViews to monitor the performance of Java components

of the portal.

User overview monitoring to analyze number of users logged onto

the portal.


14/105

14


Enterprise Portal 6.0

Monitors


15/105

15

You can look at the performance data for each portal server in the cluster:

In the Select Server dropdown list, select the portal server and choose Display.

Here you find the most important performance data displayed via different categories:

e.g.

Accumulated Amount of Outbound Data: Amount of all out going data in byte.

Time for all Requests: Overall amount of time used to proceed all requests in the

backend system.

Average Time of a Request: The average amount of time used to proceed a

request in the backend system.

Time Stamp of First Request: Start time of the monitoring.

Please check the documentation for a detailed expalantion of the collected

monitoring data.


Portal UI: JARM Request Summary

JARM as infrastructure for portal monitoring


16/105

16

An overview is given here of the completed requests of a portal server in the cluster that had the

greatest effect on the performance.

A request can consist of a number of components and subcomponents. The overview lists the

requests, including the name of the first component of the request (main component). By clicking on

this name you get detailed information about all the components involved and their hierarchy within the

request.

Detailed view on a request can be received by clicking on the component name. Under Executed

Components, all components in this request (main component including ins subcomponents) are

displayed with the following information

Component Name: Name of the main components or subcomponents

Gross Time of Component: Total time of the component (including time for all subcomponents)

Net Time of Component: Net time of a component (computed from its gross time less the gross

time of the subcomponents).

Amount of Outbound Data (Bytes): Amount of outbound data for the component

Starting Time / Starting Date: Time when the component was started

Nesting Level: Nesting level 0 corresponds to the main component. Nesting level 1 means that this

component was called from the main component, etc.


Portal UI: JARM Request Overview


17/105

17

Here you find an overview of the portal components running in the cluster node that

have the largest load on the resources. The components are displayed without takingthe corresponding requests into consideration.

Example:

Calling the component overview tells you if a component only created a time load

once, or if the component is generally slow and reduces system performance. A

component can, for example, be slow the first time it is called. If it is called

repeatedly, the net time will generally be shorter because data is kept in the cache.

If you sort the slow components by their average net time and the average net time is

approximately the same as in the first call, the component will generally reduce

performance. In custom components you should check the coding in such cases.


Portal UI: JARM Component Overview


18/105

18

An overview of the threads currently used by the portal applications in the cluster

node is displayed here. The active threads and running components that arecurrently involved are displayed.

The Thread Overview is a snapshot of the data collected for the Request Overview

and Component Overview. The current state of the thread is shown. It is not possible

to display a history of the thread for the entire runtime of the request.


Portal UI: JARM Thread Overview


19/105

19

The Portal Runtime creates a session in the cluster node for each active user. This

session is displayed in the overview of logged on users. Active User means:

The user has a valid logon ticket (for example if the user did not log off but just

closed the browser window the ticket may be still valid;

A valid user management session exists for the user.

In SP0 the user was shown as long as the PRT cache was not flushed (happened e.

g. in case of a restart of the portal application)

Configuration of this component can be done in the the service

com.sap.portal.runtime.application.monitor (see above). Here the total number of

tracked tickets/users can be limitted, for example.


Portal UI: Logged On Users


20/105

20

You can sequentially record the activities of individual requests and their components

for a defined period of time, and then analyze their performance and errors in theLogViewer of the SAP J2EE Engine.

Technically, activity tracing is based on the Java Application Responsetime

Measurement (JARM).

If you want to record the activities of components that you have developed yourself,

you must follow the example of the interfaces provided for this purpose so that the

data can be transferred correctly to the Monitoring Service.

In a cluster environment, activity tracing is activated automatically for all cluster

nodes.

All trace data is written to file sat.trc.0 in directory\cluster\server\log. New trace data is

constantly added to this file.

For details about the configuration, see the Administration Guide for the SAP J2EE

Engine. You can find this guide at http://help.sap.com SAP NetWeaverSAP

Web Application Server SAP Library mySAP Technology Components SAP

Web Application Server J2EE Engine


Log

File

Activity Tracing Portal UI

In case of performance problems Activity Trace is used to analyze a single

component in detail. The Tracing is activated on a user base, the results

are written to a trace file.

In case of performance problems Activity Trace is used to analyze a single

component in detail. The Tracing is activated on a user base, the results

are written to a trace file.


21/105


22/105

22

The Log Viewer allows end-users to quickly get access to the log files of one or more

J2EE WebAS servers in order to search and view logs, and change loggingproperties such as severity settings through an UI. There is an API to connect Log

Viewer client and server.

To launch the LogViewer change to the directory /usr/sap//j2ee/j2ee_/tools

Start the "logviewer" shell script


Connect the LogViewer to the server


23/105

23

Test connection to check whether it has been established succesfully.


Define Server Data and Test the connection


24/105

24

The sat trace log written can now be seen through the LogViewer Client.

The sat-trace-file is written until it has reached the size of 1,2 MB.

The list of sat-trace-files starts with sat.trc.0 and creates a new file whenever 1,2 MB

are reached. The Maximum size of all Trace-Files is 10 MB.

The sat-trace file displayed in the log-viewer is the result of merging the separated

trace-files.


Activity Tracing LogViewer

Activity Tracing files can be displayed

through the Log Viewer*

*LogViewer available in SAP J2EE 6.20 (PL14)

Activity Tracing files can be displayed

through the Log Viewer*

*LogViewer available in SAP J2EE 6.20 (PL14)

Log

File


25/105

25

The LogViewer is a standalone component for checking Logs form SAPJ2EE engine

as well as portal logs. Applications like Trex can register their logfiles at the logviewer to have a central tool

for displaying logs.


Check Logs in LogViewer


26/105

26

The Logging Console can be accessed through the administrator role in the

Enterprise Portal. The Logging Console allows the administrator to display the contents of different

loggers (log files) and change the logging configuration for each server of the SAP

J2EE cluster. It consists of a user mode and an administrator mode. In user mode,

the administrator can display the contents of loggers according to various verbosity

levels. In administrator mode, the administrator can change the logging configuration.

The log files are stored in file system.


Portal UI: Logging Console (1)

The Java iView Runtime provides a logging mechanism that

allows the administrator to diagnose problems more easily. This

consists of:

A Java API that developers of iViews can use to allow their iViewsto log all relevant information.

A Logging Console that can be accessed through the

administrator role in the Enterprise Portal. This allows

administrators to view the content of loggers and to configure

logging in the portal.

Configuration files in which the administrator can create new

loggers and assign logging classes to loggers.


27/105

27

Log-Files in the portal can be viewed centrally by using the log viewer available

through SAPJ2EE 6.20 (PL14).


Portal UI: Logging Console (2)

The Logging Console displays the contents

of different loggers (log files). Alternatively the logs could

be displayed in the Log Viewer.

The Logging Console displays the contents

of different loggers (log files). Alternatively the logs could

be displayed in the Log Viewer.


28/105

28

To launch the "file viewer" choose:

System Administration -> Support -> Portal Java Runtime -> Log Viewer

then choose "Browse" to hit the required directory. You can access the complete

directory srtucture under /usr


Portal UI: Log & File Viewer


29/105

29


Configuration of the

Monitoring Infrastructure

Inside the Portal


30/105


31/105

31

SATExpirationLength: If tracing is enabled for a specific user the default length of the

trace is 30 minutes.


Configuring the "Single Activity Trace"


32/105

32

Property Meaning:

MaxNumberOfUsers : Maximum number of users included in the User Overview.When this value is reached, the user with the oldest logon is removed.

MaxNumberOfLoginsPerUser : Maximum number of logons for a user. If this value is

reached and the user logs on again with a valid ticket, the oldest logon is removed.

UserIDsToIgnore : User ID of users who should not be displayed in the User

Overview. The individual entries should be separated by commas.

user.monitoring.switch : Activates (on) or deactivates (off) the UserMonitor service. If

the value is off, no data is collected for the User Overview. The display is empty,

whatever the current values of the other properties. Following the changes, the

service must be started again.


Configuring the "User Monitor"


33/105


34/105

34


Configuration of "CCMS Parameter Reporting"


35/105

35

After configuring monitoring services the service needs to be restarted to update all

cluster nodes. Navigate to System Administrator -> Support -> Portal Java Runtime -> Application

Console. Select com.sap.portal.runtime.application.monitor and refresh all services.


Restarting Monitoring Services after Configuration

After configuring monitoring services the service needs to

be restarted to update all cluster nodes

After configuring monitoring services the service needs to

be restarted to update all cluster nodes


36/105

36


SAP Solution Manager


37/105

37

Functionality in SAP Solution Manager 3.1

Graphical User Interface and graphical core business processes management

Self Services, such as SAP EarlyWatch Health Check

New checks in SAP EarlyWatch Alert for SAP componentes that use SAP Web

Application Server 6.10 and 6.20.

New functionality in Service Level Reporting

Improved service delivery through SAP Solution Manager

Monitoring for SAP components that use SAP Web Application Server 6.10 and

6.20 and SAP components without SAP Basis


Supportability Overview & Goals

A bunch of components has been developed to establish a

support infrastructure for SAPs Java applications.

The support infrastructure is integrated into the SAP SolutionManager and offers various functionalities e.g.

Error analysis through enhance monitoring functionalities

Detailed performance analysis

Logging and Tracing capabilities

Availability Checks

Parameter Reporting

Help Desk functionalities


38/105

38

The SAP Solution Manager is SAP's next generation service & support platform that helps you to

implement and operate your SAP solution efficiently.

Together with the SAP Service Marketplace, the SAP Solution Manager represents SAP's strategic

service infrastructure that guides our customers through all stages of their SAP solution life cycle.

Today, the SAP Solution Manager consists of:

Central documentation of system landscapes and core business processes

Implementation tools, key functional implementation aspects such as blueprinting, configuration

and testing

(formerly known as AcceleratedSAP or ValueSAP)

Access to SAP Support services and Best Practices

Periodic service level reporting and real-time monitoring of system components and business

processes

Advanced message handling for fast problem analysis and resolution including the SAP Note

Assistant and a direct connection to the SAP Support Back Office.

http://service.sap.com/solutionmanager


SAP Solution Manager Life-Cycle Approach

Functional Implementation

Technical Implementation

Implementation ofOperations

Support Desk

Services for Operations

Solution Monitoring

Implementation

of SAP Solutions

Operation

of SAP Solutions

Project

Preparation

Project

Preparation

Business

Blueprint

Business

Blueprint RealizationRealization Go Live

& Support

Go Live

& Support

Final

preparation

Final

preparation

SAP SolutionManager

Life-Cycle Approach for Implementation

and Operation of SAP Solutions

Focus of this presentation


39/105


40/105

40


SAP Solution Manager: Overview

SAP R/3SAP

EP Others J2EE

Monitoring

Frontend

Central Monitoring System

SolMan History

Perfor-

manceStatisticsAlerts

Service

Level

Management


41/105

41


SAP Solution Manager Infrastructure

Analysis

Method

DB OS SAP

Monitoring

Object

Others

Monitoring

Object

Data

Supplier

Data

Supplier

Monitoring

Object

Monitoring

Object

Data

Supplier

Data

Supplier

Data

Supplier

Monitoring

Object

Data

Collection

Data

Storage

Admini-

stration

Local Monitoring Segments

SAP Monitors3rd Party Product

Non-

SAP

DB

A P I

Auto-

Reaction

Method


42/105

42


Solution Manager Requirements

The Solution Manager is an Add On for the WAS basis system

and can be downloaded from SAP ServiceMarketplace (no

additional charging for customers)

Support requires productive usage of SAP solution manager

For Web AS 6.20 Solution Manager Version 3.1 is required


43/105

43

Monitoring functionality is oriented to achievement the Quick Wins of the Java Supportability Task Force. The

Quick Wins:

Monitoring of heartbeat and functional availability of a component

Reporting of version and critical configuration data

Reporting of critical performance values

Monitoring of component log files

The CCMS uses several techniques to realize this monitoring:

Heartbeat data is collected primarily using the CCMS GRMG (Generic Request and Message Generator)

component, which exchanges XML status messages with small control programs over HTTP communication

channels.

Version, configuration, and state information are reported by the J2EE engine to the CCMS SAPCCMSR agent

using a JMX interface prepared by the CCMS for Web AS Release 6.20. Non-Java components can be

monitored using agent DLLs which plug into the SAPCCMSR agent and then gather information by way of

component management interfaces.

Logfile monitoring by the SAPCCMSR agent, which can easily be configured to monitor log files for component

error strings. Since most J2EE components use the standardized Java Logging API, setup of log file monitoring

can usually be standardized and simplified.

Backend and other SAP Systems in the landscape are of course fully integrated in the CCMS monitoring

architecture and can be centrally monitored.

SAP Support and the CCMS recommend the customers to set up a separate monitoring system in which to

centralize monitoring of an EP landscape. This system can also be the platform for Supports Solution Manager.


SolutionManager

GRMG

Infrastructure

SAP Web AS

GRMG

Application

SAP J2EE Engine

with

EP components

CCMS

Central Monitoring

Console

SAP System

Local

CCMS

Other Components

(IPC, TREX - IMS, ...)GRMG

Application

Host 1

Host 2

Remote System

Monitoring

Shared

Memory

SAP Web AS

CCMSR

Agent

JMX MonitoringInterface

Log file

Shared

Memory

Log file

DLL

Interface

CCMSR

Agent

Version, config.,

state, logfile data

Heartbeat

CCMS: Monitoring External Systems


44/105

44

SAPOSCOL is a stand alone program available for almost all operating system

platforms, which determines operating system data like CPU idle/used, paging ratesor filesystem filling level and stores this data in a shared memory segment of its host.

SAPOSCOL runs only once per host (normally as a service for NT). The data of

SAPOSCOL can be analyzed by using the local SAP system or transferred to CEN

by usage of the CCMS agent SAPCCMSR. In CEN, the data can be analyzed in

transaction OS07 or RZ20.

SAP Note 451166 describes, how to configure SAPOSCOL to monitor the existence,

CPU and memory consumption of single processes. For example, the existence of

the process java.exe or the TNS listener of a stand alone oracle database located on

an non-SAP host could be checked. Doing so, SAPOSCOL checks a new

configuration file dev_proc, where you can specify the process name and the

operating system user of the process. The information is transferred via the agent

and can be analyzed in CEN using transaction RZ20.

All agents have a logfile adapter. They can analyze logfiles to find specific strings

and to transfer those logfile rows to CEN. For instance, you can scan the logfile of an

Oracle database for ORA-600 errors. You can define, if the matching lines are

transferred as errors or as "normal messages" (green lines).

Detailed information about installation of agents can be found in SAP Note 209834.


Non-ABAP SAP ComponentsCentral Monitoring

System

Monitoring: Agents for SAP Java Components

Log

Application

SAPCCMSR

DLL

ApplicationSAPOsCol

SAP

Solution

Manager

SAP

Solution

Manager

SAPCCMSR = Agent for SAP Java Components

SAPOsCol = Operating System Resource Collector

SAPCCMSR = Agent for SAP Java Components

SAPOsCol = Operating System Resource Collector

dev_proc


45/105


46/105

46


SAP Solution

Manager

Satellite

Systems

System Monitoring

Service Level

Reporting

Continous Monitoring:

Service Data Download

(SDCC)

Continous Monitoring:

Service Data Download

(SDCC)

Real-time Monitoring:

CCMS Monitoring

Infrastructure (RZ20)

Real-time Monitoring:

CCMS Monitoring

Infrastructure (RZ20)

Solution Monitoring Data Collection

SAP

EarlyWatch

Alerts

Business Processes

Detailed

Reporting:

Critical Alert

Situations:

Business Process

Monitoring


47/105

47


Service Level Reporting Workflow Example

Alert

Overview

Alert

Overview

Alert

Details

Alert

Details

Service

recommen-

dations

Service

recommen-

dations

Link to SAP

Service Catalog

Link to SAP

Service Catalog

Measures and communicates

agreed service goals defined in

your service level agreements

Triggers reports regularly, e.g.

once a week or month

Configuration without expert

knowledge

Evaluates key performance

indicators

Preconfigures recommen-

dations to be individually tailored

Facilitates forecasting

Service Level Reporting


48/105

48


System Monitoring Workflow

Open task overviewOpen task overview

System monitoring of core components to

detect critical situations as early as possible

Support administrators working with new

SAP products

System monitoring and Central System

Administration complement each other

Expert monitors directly

linked in satellite systems

Expert monitors directly

linked in satellite systems

Alert graphicsAlert graphics

System-related tasks

with integrated and

automated log

System-related tasks

with integrated and

automated log


49/105

49


Business Process and Interface Monitoring

Alert graphicsAlert graphics

Alerts overview of

business process step

Alerts overview of

business process step

Expert monitors

directly linked in

satellite systems

Expert monitors

directly linked in

satellite systems

Detailed procedures for error handlingand problem resolution

Precise definition of contact personsand escalation paths

Tight integration of the customerssupport organization

Monitoring session with

detailed information in the

step related check

Monitoring session with

detailed information in the

step related check


50/105

50


Solution Management

&

Enterprise Portal 6.0


51/105


52/105

52

1. Reporting of relevant operating system data

2. Parameter Reporting into CCMS using CCMS agents

3. Single Activity Tracing results displayed in the Log Viewer

4. Component Heart Beat


PORTALSERVER

CCMS Integrated Monitoring Concept in EP 6.0

SAP J2EE 6.20 PL 14

SAPOSCOL

CCMS-Agent

PRT

PCD

UME

KM

Logging and Tracing API

Log Viewer

WAS 6.20

Solution Manager

CCMS

PCD UM KM PRT OS

SAT

3

Component Heart Beat

4

Shared Memory

2

1


53/105


54/105

54


Integrating EP 6.0 into Solution Manager

1. Install the sapccmsr agent (already done by SAPInst as of SP1) The sapccmsr agent must run on every host that runs a monitor server of the SAP J2EE

Engine. The sapccmsr agent is also required if the monitor server runs on the same host asthe SAP system which you are reporting to.

As a requirment forsapccmsragent the saposcol must be installed first (refer to note

371023 )!!

2. Install the jmonapi.jar and jmon CCMS library (already done by SAPInst as of SP1) The monitor server requires the Java Monitoring API (jmonapi.jar) and the native code

library jmon.dll (or libjmon.so for unix platforms), which must be downloaded from SAP

3. Install and setup the JARM-Consumer-Thread JARM, the monitoring service collects system and appl. data, which can be sent to the

sapccmsr agent via a "Data-Provider" (JARMCCMS).

4. Configure and start the monitor server The Monitor server can be executed in two different modes:

1. Manual startup via the batch file tools\monitor.bat

2. Automatic startup when the J2EE Engine is launched.

5. Configure the J2EE Engine

Add a directory name (./additional-lib) to the classpath parameter of the J2EE Engine usingthe "SAP J2EEngine config tool".

6. Define a CCMS monitor for the SAP J2EE Engine (RZ20)

For detailed information please refer notes 547024, 498179 and 619460.


55/105


56/105

56


System Monitoring

Overview of all systemswithin a Solution LandscapeOverview of all systemswithin a Solution Landscape


57/105

57


System Details

Detail view of Portal ServerDetail view of Portal Server


58/105


59/105

59


Operating System Data Monitoring

Monitoring of

System Data

Monitoring of

System Data

Customization

of Alerts

Customization

of Alerts HistoryHistory


60/105


61/105

61

Request Summary: Here you find the data that is relevant for the Portal Web Server,

organized into a number of categories. Request Overview: Here you can find an overview of the individual requests sent to

the Web server.

Component Overview: Here you can find an overview of the components currently

running in the portal.

User Overview: Here you can find an overview of the users currently logged onto the

portal.


Performance Monitoring

Overview of the Top 10

requests in the cluster node

sent to the Portal Server

Overview of the Top 10

requests in the cluster node

sent to the Portal Server


62/105


63/105

63

For displaying the different monitors call transaction RZ20 in a WAS 6.20 system.

There are two main monitor collections where you find portal relevant data:

J2EE Applications

J2EE Engine

As well operating system data is collected here and can be viewed under monitor

collection Operating system.

Please have in mind that for other parts of the EP 6.0 landscape like Trex additional

monitors can be configured.

Monitors for the EP 6.0 portal platform:

Checking configuration data is done during startup of SAP J2EE engine.

For updating the configuration data a request needs to be sent out from CCMS

(Refresh).

The version parameters are also collected during startup of the SAP J2EE engine.


CCMS: Parameter Monitoring PRT, PCD, UME, KM

In CCMS the followingmonitors can becustomized:

PRT Configuration

State

Version

PCD

Configuration

State

Version

UME

Configuration

State

Version KM

Configuration

State

Version


64/105


65/105

65


Log File Monitoring

Log files are being scannedfor certain values

(here: error, table corrupt)

Log files are being scannedfor certain values

(here: error, table corrupt)


66/105

66


Process Monitoring

Checks availability

of Portal Services

Checks availability

of Portal Services


67/105

67


Monitoring ofSAP Partner Components: LDAP

LDAP Directory

Monitor

LDAP Directory

Monitor


68/105


69/105


70/105

70

1. Web Server transfers GRMG request as HTTP POST request to a servlet or iView on a servlet

engine or PRT.

2. This request will be received and processed by a GRMG application (JSP, Servlet, iView) on the

J2EE Server, Web Server or PRT.

3. The GRMG application tests a certain set of technical components or business processes (

GRMG Scenario): e.g. availability of EJBs, web pages, DB, SAP Systems (R/3), PRTs in cluster

environment etc.

4. The results of the different checks are collected by the GRMG application and assembled in a

GRMG response.

5. The GRMG response is transferred back to the GRMG framework typically the contents of the

GRMG response may be uploaded into the HttpServletResponse of the servlet or iView.

6. The GRMG framework in the CCMS interprets the response and displays the results in the

monitoring tree of CCMS.

GRMG Framework (in the CCMS) (1) periodically sends GRMG request (2) to the (central) Web

Server (3) which transfers to the Servlet Engine (4) the GRMG request by an HTTP POST (5). In the

example the GRMG Application checks the availability of a SAP System (6) the availability of an EJB

(7) and the availability of a Servlet (8). The GRMG Application sends back the GRMG response to

the GRMG Framework (9,10). The result is then displayed in a CCMS monitoring tree (11).


Typical Web Server Situation

TX rz20

TX grmg

Web Server

GRMG Infrastructure

GRMG application

Servlet

EJB

1

Servlet Engine

J2EE Server

SAP System (R/3)

SAP System (R/3)

CCMS Monitoring

3

2

45

8

6

7

9

10

11

Uploaded GRMG

configuration file


71/105

71

To load your configuration file into your central monitoring system, use transaction

code GRMG and click Upload GRMG customizing. The scenario name and description will appear in the list of scenarios.

To start the available scenarios, click Start GRMG scenarios.

The requested availability information of each scenario is displayed in the GRMG

Scenario Monitor (see slide 19):

Scenario description (Parameter ), here: Availability of System DKS

(using GRMG)

Component description (Parameter ), here: ABAP Stack

Component name (Parameter ), here: Host

Component version (Parameter ) allows you to have separate

versions of a component with different configurations

Note that the scenario description will appear as the description of a newly created

GRMG monitoring tree node in the Alert Monitor in the SAP CCMS Technical Expert

Monitors under All Monitoring Contexts.


Availability Monitoring: Using GRMG

Configuration

What is a GRMG Configuration File?

A well defined XML document

Required for generating a request

Available via quicklink MONITORING

Must be loaded into central

monitoring system

File Contents:

Scenario information Technical name

Uniform Resource Locator

Description of each scenario

for display in the Alert Monitor

Monitored components At least one component

Description of component(s)

Parameters (Properties) At least one parameter per component


72/105

72


What is a GRMG Application ?

Processes the request and the input data stream

in accordance with XML syntax

Performs the actual monitoring functions

Generates the GRMG response as an XML document

Implementation for ABAP

Implementation for J2EE



73/105

73

The GRMG request contains the requested availability information for each

component in each scenario, as defined in the configuration file.



The GRMG Request

...is an XML document created in the central monitoring system and sent

to a monitored component.

It contains information obtained

from the GRMG configuration file:

Scenario

Component(s)

Other parameters to be sent

to the GRMG application


74/105

74

The response contains the requested availability information for each component in a

each scenario. It is displayed in the GRMG Scenario Monitor


The GRMG Response

...is an XML document created by the GRMG application. It is sent to the

GRMG infrastructure, interpreted and displayed in a monitoring tree of the

Alert Monitor.

It contains availability information obtained

from the GRMG application:

Scenario

Component(s)

Message(s) on

component

availability



75/105


76/105


77/105

77


Supportability in EP 6.0 SP1: Summary

Supportability Overview & Goals

Information Resources

Integration into Solution Manager 3.1

Monitoring Features visible in Portal UI

JARM (Java Application Responsetime Measurement)

SAT

Logged on Users

Monitoring Features

LogViewer available in SAP J2EE 6.20 (PL14)

GRMG Heartbeat

Parameter Reporting into CCMS

Helpdesk Functionality:

iView: Sedning Messages to Help Desk and Support


78/105


79/105

79



EP 6.0 Portal

Backup & Restore


Deployment

Change Management


80/105

80

SDM is used as a central tool for importing SDAs (Software Delivery Archive). The

SDA includes among other things the .PAR file. It contains complete javaapplications.

The Software Delivery Archive (SDA) is the delivery format for SAP applications in

programming languages other than ABAP

It is a ZIP-compatible archive format that can be used as a container for other

archives. The SDA contains the manifest information of its archives (such as jar, war,

ear) and an SAP manifest, which contains additional software logistics information.

An SDA can also contain configuration files (.ini files)

An SDA that does not contain any other archives is an atomic SDA. This is also the

smallest unit that you can deploy

The SDA is the smallest unit for which patches can be created and delivered


Deployment Overview

Upgrade of Enterprise Portal 6.0

Software Delivery Manager (SDM) for deploying Service Packs,

Patches and Hotfixes

Hot Reload

Par-Upload into PRT

Versioning

Version Control of Service Packs, Patches and Hotfixes

Version Control of Par-Files

Version Control of Portal Content


81/105

81

The Software Delivery Manager (SDM) is a tool within you can manage and deploy

software packages that you receive from SAP Terminology:

Software Delivery Archive (SDA)

Software Delivery Catalog (SWC)

Software Component Archive (SCA)

The main goal of the Software Delivery Manager is to automate the deployment

process based on configuration data and data provided by the IDE

The Software Delivery Archives include the description of dependencies of

development components .

The Software Delivery Manager prohibits the deployment of inconsistant

deployments or patches.


Software Delivery Manager

Web Application Server 6.20

Deployment of Patches and

Support Packages

Deployment of Installations

and Upgrades

Deployment of custom

development with Web

Application Server 6.30

Extension of J2EE native

deployment like dependency

management on one server

Extended Deployment

Types:

J2EE

File system

Database structure

Database content

Download: http://cts.wdf.sap-ag.de:1080/logs/Slj/installSDMfull/SDMKit.jar

Documentation: http://upgrade.wdf.sap-ag.de:1080/slj/software/src/data/doc/SDM_Doku_EN.pdf


82/105

82

The SDM uses the Deployment Manager to control the deployment of SDAs for the

following: J2EE applications

File system content

Database content

SAP J2EE Engine Additional Libs

If you want to deploy your applications with the SDM, you must register the relevant

software packages in the SDM. The data is then stored in the SDM Repository,

where it is used for Software Lifecycle Management.

A Software Delivery Archive (SDA) is the physical representation (.sda file) of aversion of a software component. It contains a specific number of SCAs, whose

quantity describes a precisely-defined version level

A SDA update always results in a new version level of the software component


Software Deployment Archives (Types)

SDA zip-compatible archive format

Contains META-INF folder with

special sapmanifest.mf and DD

DB

Content

DB

Schema

File

System

JAVA

LIBJ2EE

.txt

.dat

.xml Number Of

File Sets

JAR Files Content of

EAR File

Initial DB

Content Data

DB Schema

Description

Delivery of

Filesystem

Structures

InQMy

Library

Extensions

J2EE

ApplicationsPurpose

Content


83/105

83

In the manifest.mf file alle dependencies upon OTHER SDAs are specified. SDM will

check that while deploying the SDA.


Software Deployment Archives (SDA Descriptors)

SDA zip-compatible archive format

Contains META-INF folder with

special sapmanifest.mf and DD

SDA Generation Properties:

JarSAP attributes

Perforce attributes

SDA Type

SDA Dependencies:

For installation order

For Application or Library

References on InQMy

sapmanifest.mf SDA Deployment Descriptor

SDA Type

SDA Deployment Information:

FS Target Directory

J2EE EAR Deployment Parameter

manifest.mf

Java Package Versioning


84/105


85/105

85

The SDM Repository contains the registered Software Component Archives (SCAs), Software Delivery

Catalogs (SWCs) and Software Delivery Archives (SDAs).

The SDM Repository tab page shows you a hierarchy of all SCAs, SWCs and SDAs in the SDM

Repository, and also their location in the corresponding deployment target.

Expand and collapse the structure by selecting hierarchy nodes.

The Deployments window contains the target systems that are ready for deployment, grouped by type.

You can select from the following types:

File system

Database

SAP J2EE Engine

In this display, the SCAs, SWCs and SDAs are assigned to the appropriate target systems.

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 its archives.

Configuration

- You enter target system-specific information on the Configuration tab page. After you have

changed the configuration data, save the SDM Repository.

- Note: The icon on the Configuration tab page turns green when the configuration data is

complete.


SDM Repository SAP J2EEngine


86/105

86


Service Packs, Patches and Hotfixes

To install patches the SDM will be used.

Click on the deployment tab an then load the sda-file.

Click next on the screen.

The SDM will check for dependencies. If the sda-file is already installed

the SDM will stop and show a message screen.

Dont forget to make a backup of the SDM.


87/105


88/105

88


Hot Reload of par files

For questions regarding the upload of par-files:

Please refer to UNIT 9 Portal Development!

Go to http://:50000/irj/servlet/prt/portal/


89/105

89


Versioning

Version numbers in SDM are listed for SDA files:

Service Packs

Patches

Hotfixes

Version control for par-files can be checked in the portal:

http://:50000/irj/servlet/prt/portal/


90/105

90



EP 6.0 Portal

Solution Manager@EP 6.0

Backup & Restore

Monitoring

Deployment

Change Management


91/105


92/105


93/105

93


SDM : Deployment of a SDA (1)

Click on the Deployment tab


94/105


95/105

95



Choose the SDA file


96/105

96



Click on start


97/105

97




98/105

98




99/105

99




100/105

100


Appendix B: Coming

Appendix B:

What's next?


101/105

101


Software Logistics / Transports

SAP J2EE Deploy Tool Software Distribution Manger Today basis 6.20 !!!


102/105


103/105

103


Coming: SAP J2EE 6.30


104/105

104


Coming: SAP J2EE 6.30


105/105


Change Management Coming: WAS 6.30

For SAP J2EE Engine further enhancement in the area of change

management will be available.

Using the change management functionality of SAP J2EE 6.30 for

the Enterprise Portal is in process of definition.

[Please treat this information confidentially!]