Best Practices for Implementing a Global Portal Using SAP NetWeaver Portal

SAP NetWeaver How-To Guide

Best Practices for Implementing a Global Portal using SAP NetWeaver Portal

Applicable Releases:

SAP NetWeaver '04, SAP NetWeaver 7.0

IT Practice:

User Productivity Enablement

IT Scenario: Running an Enterprise Portal

Version 1.0

September 2008

© Copyright 2008 SAP AG. All rights reserved.

No part of this publication may be reproduced or

transmitted in any form or for any purpose without the

express permission of SAP AG. The information contained

herein may be changed without prior notice.

Some software products marketed by SAP AG and its

distributors contain proprietary software components of

other software vendors.

Microsoft, Windows, Outlook, and PowerPoint are

registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, OS/2, Parallel

Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390,

OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP,

Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix,

i5/OS, POWER, POWER5, OpenPower and PowerPC are

trademarks or registered trademarks of IBM Corporation.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader

are either trademarks or registered trademarks of Adobe

Systems Incorporated in the United States and/or other

countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered

trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame,

WinFrame, VideoFrame, and MultiWin are trademarks or

registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or

registered trademarks of W3C®, World Wide Web

Consortium, Massachusetts Institute of Technology.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems,

Inc., used under license for technology invented and

implemented by Netscape.

MaxDB is a trademark of MySQL AB, Sweden.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP

NetWeaver, and other SAP products and services

mentioned herein as well as their respective logos are

trademarks or registered trademarks of SAP AG in

Germany and in several other countries all over the world.

All other product and service names mentioned are the

trademarks of their respective companies. Data contained

in this document serves informational purposes only.

National product specifications may vary.

These materials are subject to change without notice.

These materials are provided by SAP AG and its affiliated

companies ("SAP Group") for informational purposes only,

without representation or warranty of any kind, and SAP

Group shall not be liable for errors or omissions with

respect to the materials. The only warranties for SAP

Group products and services are those that are set forth in

the express warranty statements accompanying such

products and services, if any. Nothing herein should be

construed as constituting an additional warranty.

These materials are provided “as is” without a warranty of

any kind, either express or implied, including but not

limited to, the implied warranties of merchantability,

fitness for a particular purpose, or non-infringement.

SAP shall not be liable for damages of any kind including

without limitation direct, special, indirect, or consequential

damages that may result from the use of these materials.

SAP does not warrant the accuracy or completeness of the

information, text, graphics, links or other items contained

within these materials. SAP has no control over the

information that you may access through the use of hot

links contained in these materials and does not endorse

your use of third party web pages nor provide any warranty

whatsoever relating to third party web pages.

SAP NetWeaver “How-to” Guides are intended to simplify

the product implementation. While specific product

features and procedures typically are explained in a

practical business context, it is not implied that those

features and procedures are the only approach in solving a

specific business problem using SAP NetWeaver. Should

you wish to receive additional information, clarification or

support, please refer to SAP Consulting.

Any software coding and/or code lines / strings (“Code”)

included in this documentation are only examples and are

not intended to be used in a productive system

environment. The Code is only intended better explain and

visualize the syntax and phrasing rules of certain coding.

SAP does not warrant the correctness and completeness of

the Code given herein, and SAP shall not be liable for

errors or damages caused by the usage of the Code, except

if such damages were caused by SAP intentionally or

grossly negligent.

Disclaimer

Some components of this product are based on Java™. Any

code change in these components may cause unpredictable

and severe malfunctions and is therefore expressively

prohibited, as is any decompilation of these components.

Any Java™ Source Code delivered with this product is only

to be used by SAP’s Support Services and may not be

modified or altered in any way.

Document History Document Version Description

1.00 First official release of this guide

Typographic Conventions Type Style Description

Example Text Words or characters quoted from the screen. These include field names, screen titles, pushbuttons labels, menu names, menu paths, and menu options.

Cross-references to other documentation

Example text Emphasized words or phrases in body text, graphic titles, and table titles

Example text File and directory names and their paths, messages, names of variables and parameters, source text, and names of installation, upgrade and database tools.

Example text User entry texts. These are words or characters that you enter in the system exactly as they appear in the documentation.

<Example text>

Variable user entry. Angle brackets indicate that you replace these words and characters with appropriate entries to make entries in the system.

EXAMPLE TEXT Keys on the keyboard, for example, F2 or ENTER.

Icons Icon Description

Caution

Note or Important

Example

Recommendation or Tip

Table of Contents

1. Executive Summary............................................................................................................. 1

2. Introduction.......................................................................................................................... 1 2.1 What is Global Portal?.................................................................................................. 1 2.2 Why Global Portal?....................................................................................................... 1 2.3 What does SAP offer? .................................................................................................. 1 2.4 Who should read this document? ................................................................................. 2

3. Implementing a Global Portal............................................................................................. 3 3.1 Setting up a Central Portal ........................................................................................... 3

3.1.1 SAP Corporate Portal ...................................................................................... 3 3.2 Setting up Federated Portal Network ......................................................................... 25

3.2.1 Why Federated Portal Network?.................................................................... 25 3.2.2 Central Portal Vs Federated Portal Network.................................................. 25 3.2.3 B2B, Information Portal and Legacy Applications ......................................... 27

3.3 Setting up an External Facing Portal .......................................................................... 31 3.3.1 What is external-facing Portal?...................................................................... 31 3.3.2 Making Portal available on Internet ............................................................... 32

3.4 Stability ....................................................................................................................... 35 3.5 Security....................................................................................................................... 36

3.5.1 Authentication ................................................................................................ 38 3.5.2 Single Sign-On............................................................................................... 40 3.5.3 Authorization .................................................................................................. 41 3.5.4 Secure Communication.................................................................................. 42 3.5.5 Integrated User Management ........................................................................ 42 3.5.6 Secure Network Architecture ......................................................................... 43

3.6 Performance Monitoring and Troubleshooting ........................................................... 45 3.6.1 Monitoring Set-up........................................................................................... 45 3.6.2 Analysis Worksheet ....................................................................................... 48 3.6.3 Portal Workload Analysis ............................................................................... 55 3.6.4 Single Activity Trace ...................................................................................... 56 3.6.5 Portal Infrastructure Analysis with J2EE Tools .............................................. 58 3.6.6 Java VM Thread Analysis .............................................................................. 59 3.6.7 Java VM Analysis........................................................................................... 60 3.6.8 HTTP Request Analysis................................................................................. 63

4. Further Information ........................................................................................................... 65 4.1 Web Infrastructures and Architecture......................................................................... 65 4.2 Federated Portal Network........................................................................................... 65 4.3 External Facing Portal ................................................................................................ 65

4.4 User Management and Security ................................................................................. 66 4.5 Performance and Monitoring ...................................................................................... 66 4.6 Sizing .......................................................................................................................... 66 4.7 Development Infrastructure ........................................................................................ 67 4.8 Accelerated Application Delivery (AccAD) ................................................................. 67 4.9 Product Availability Matrix (PAM) ............................................................................... 67


1. Executive Summary A wide range of approaches and solution architectures can be thought of and deployed to implement a Global Portal. The main objective of this guide is to get you familiarized to the best practices of implementing a Global Portal.

With the help of this guide, you will be able to understand the difference between each of these approaches and solution architectures. This guide would help you to analyze and select an approach that is best suited for your business requirements.

2. Introduction

2.1 What is Global Portal? Global Portal is a unified SAP portal-based network supporting global organizations, facilitating optimal and seamless runtime access to remote back-end systems, and enhancing content sharing between portals at multiple geographical sites.

2.2 Why Global Portal? The large business enterprises of today are global - serving employees, customers, and an IT infrastructure that is dispersed in numerous geographical locations worldwide. Global Portal network reduces Total Cost of Ownership (TCO) while increasing the autonomy of business units. Sharing content between sites when back-end systems are distributed worldwide improves overall performance, and decreases bandwidth usage.

The advantages of Global Portal are:

No local installation of IViews is required, meaning reduced downtime for production systems, particularly when new or updated IViews have to be installed

IViews can be shared by several different portals, enabling departments to share information and applications

When upgrading to a new version of the portal software, the iViews do not need to be re-installed or re-configured

The portal becomes interoperable with other portals. In fact, the portal only needs to communicate with other portal interfaces enabling the sharing of different portlet technologies including Java, C# and .Net

2.3 What does SAP offer? SAP offers NetWeaver Portal-based solution that is able to share, integrate and display multi-lingual information located in applications and persistence layers all over the world, so that portal clients at any geographical location can access this information. The solution enables live and direct access to global applications without the need to deploy replication and synchronization mechanisms for content repositories.

September 2008 1


SAP NetWeaver Portal drives SAP’s current Global Portal Solution. The portal provides the framework, tools, and services for setting up a global portal network. Global Portal enables the central portal to optimally retrieve up-to-date data from remote backend systems, regardless of their geographical location, and offer it to any portal user worldwide.

2.4 Who should read this document? This document provides an end-to-end view of Global Portal at a technical level. Accordingly, it focuses mainly on Portal Solution Architects and Portal Consultants who want to learn the best practices of implementing a Global Portal. However, the guidance provided may also be valuable for Portal Administrators. This guide will take you through real time scenarios and discuss in detail the solution architectures aligned to the best practices. This guide consolidates information, inputs and learning from various implementations of Global Portal for different clients at different geographical locations and hence brings to you the best offerings in terms of solutions for implementation of Global Portal.

September 2008 2


3. Implementing a Global Portal Under this section, we would discuss about the most frequently implemented real time scenarios. To start with, let us consider the scenario of SAP Corporate Portal. The solution architecture for SAP Corporate Portal would act as a base.

This base architecture is scalable and we would discuss this in detail by taking up a scenario and would show how this base architecture could be enhanced to cater to other requirements and scenarios.

3.1 Setting up a Central Portal In a Central Portal set-up, all the systems in the system landscape would be integrated to one Portal System and this single portal system would cater to the requirements of all the end users. SAP Corporate Portal is a classic use case of Central Portal. We would focus on this use case and explain in detail how the customer requirements can be met using a Central Portal. In this section, we would emphasize more on the solution architecture and discuss different factors that influence the deployment of this architecture.

3.1.1 SAP Corporate Portal

3.1.1.1 Business Scenario A company has its presence globally and wants to launch a Corporate Portal for all the employees. The Corporate Portal would be accessed only within the intranet or through Virtual Private Network (VPN) or WTS if it has to be accessed through internet. The Corporate Portal should be robust, stable and secure.

The employees should be able to access the corporate information, global and regional news, global and regional corporate policies through the Corporate Portal. The employees should have online access to Self Services Applications like time recording application, leave management applications, IT and network related requests etc. The employees should be able to maintain their personal information, bank details, and family details and should be able to access all the finance related applications forms like tax declaration, tax exemption etc. and should have access to salary slips. The employees should have access to all the necessary human resources, personal development, e-learning and performance management applications like employee referral, internal job opportunities, internal transfers and movements, appraisals, training schedule, registrations for different training programs etc. The HR team should have access to e-recruitment and other HR related applications.

The Corporate Portal would also host applications for knowledge enablement and sharing. Apart from Knowledge Management, the employees should have access to applications like Discussion Forums, Board for announcements, Quick Polls etc. for employees to collaborate.

The Corporate Portal would host workflow based applications for approvals of requests.

3.1.1.2 Positioning Servers in Network Zones The following are the recommendations to position servers in network zones:

Application Servers

Any communication between the client and the application server should happen through a reverse proxy and the application servers should be placed in “High Secure Backend LAN”

Web Portal Applications that get called by the client should reside in the “Inner DMZ”

September 2008 3


Database Server

Database Servers Should be located “close” the respective Web AS to optimize performance, session stability and latency. Therefore it’s recommended to install the database in the same network zone as the application server.

LDAP Directory

If the LDAP Directory is used to as a persistence store for storing authentication credentials of External Users, then it should be placed in a DMZ. If the LDAP Directory is being used to store the authentication credentials of internal users or if the LDAP is being used by other applications as well, then it should be placed along with the backend systems.

TREX

As TREX interacts only with servers in the DMZ, it can be considered a backend server and therefore should be positioned in the backend LAN

KM Repositories

CM-Repository is normally located in the database (e.g. DB Only). For other repositories, depending on the repository type and the access that is provided, it could be located in backend LAN or Inner DMZ

3.1.1.3 Logical Solution Architecture The figure below shows the logical architecture for a Central Portal Set-up. This architecture would stand as a base architecture and enhancements can be made to cater to any requirement that comes up in the future.

Figure 3-1 : Logical Solution Architecture .

September 2008 4


3.1.1.4 SAP Corporate Portal Landscape Design A landscape is a logical grouping of systems. The grouping of landscape can be horizontal or vertical.

Horizontal landscapes comprise of two or more SAP systems (System IDs – SIDs) that support “promote to production” of software for a particular piece or set of functionality – for example, the development, quality assurance and productive systems for the Portal functionality is the “Portal landscape”.

Figure 3-2 : Portal Landscape Design

Development All customizing and development work is performed in this system. All system maintenance including break-fixes for productive processes is also performed in the system. After all the changes have been unit tested, these changes can be transferred to the Quality Assurance System (QAS) for further system testing. The customizing, development and production break-fix changes are promoted to the Quality Assurance System using the change management system. This ensures consistency, management, tracking and audit capabilities thus minimizing risk and human error by eliminating manual repetition of development and customizing work in each system.

Testing and Quality After unit testing the customizing, development and break-fix changes in the development system (DEV), the changes are promoted to the Quality Assurance System (QAS). Here, the configuration, development or changes undergo further tests and checks to ensure that they do not adversely affect other modules. When the configuration, development or changes have been thoroughly tested in this system and signed off by the quality assurance team, it can be promoted to the production system (PRD).

In order to ensure that changes do not negatively impact the existing performance and functionality of the Corporate Portal, extensive regression testing on all bug fix and code-related transports should be employed on the Quality System.

September 2008 5


The following outline describes this process:

Regression tests should be initiated to measure the top ten Key Performance Indicators (KPI) scenarios measured in the Corporate Portal

These regression tests consist of KPI gathering during a 3 hour load test

The results are then compiled and compared against previously recorded baselines

Any regression identified is then analyzed to determine the impact it represents to the overall KPIs being monitored

If severe regression is verified then we should stop any code related transports determined to cause this effect. Changes will be backed out one by one until the offending change is properly identified.

Load Testing Automation

Load tests can be automated by custom interface and application framework

Custom application can initiate pre-recorded tests and collect all test results and system data

KPIs are gathered where they can be easily compared to previous results to determine impact to system

Production A company uses the Production system (PRD) for its live, productive work. This system - containing the company's live data - is where the real business processes are executed. The other systems in the landscape provide a safe approach to guaranteeing that only correct and tested (that is not defective) new developments and/or customizing configurations get deployed into the productive system. Additionally they ensure that changes to productive developments and configuration by either project enhancements or maintenance do not adversely affect the production environment when deployed. Therefore the quality of the DEV and QAS system and the implemented change management processes directly impacts the quality of the production system.

3.1.1.5 Software Release Versions The following software release versions are being used for SAP Corporate Portal. The releases have been be clearly stated for all the components involved and have been listed in a table below:

SAP Corporate Portal Landscape

Component Version

SAP NetWeaver Portal 7.0 SPS14 Knowledge Management Collaboration (KMC) 7.0 SPS14 (latest patch levels) SAP Enterprise Search (TREX) 7.00.36.00 Microsoft SQL Server 2005

September 2008 6


SAP Corporate Portal – Java Landscape

Component Version

SAP NetWeaver Portal 7.0 SPS14

Microsoft SQL Server 2000

SAP Corporate Portal – Server OS Versions

Component Version

Portal/Database Servers Microsoft Windows 2003

TREX Servers Linux

3.1.1.6 Sizing Good performance can only be achieved if there are no resource bottlenecks by the system and configuration of the system itself. Though sizing is not the only factor which affects the performance and scalability but an appropriate sizing does play a very critical role in having a successful implementation. It is very important that we take into consideration all the scenarios and we use the right statistics to get a proper sizing of hardware and network.

In a complex infrastructure there are different components besides the portal that may influence the performance:

Backend systems and databases

Network, firewalls, router or dispatcher, etc.

Concrete portal sizing recommendations depend on:

Number of users (named and anonymous)

User types (active, concurrent)

User activities (navigation steps per time unit)

Amount and structure of customer-specific content (HTML, GUI, Webdynpro and J2EE Application, UI Components on a single page etc.)

Sizing Process Initial Sizing with SAP QuickSizer

QuickSizer tool is used for initial sizing and it delivers SAPS number which is an input for hardware vendors. Hence it helps in providing first suggestions for hardware budgeting & planning.

Configuration and landscaping

Set up of the infrastructure and configuration of the systems or servers.

Expert Sizing: Customer Performance Tests

After performing Stress Tests, Volume Tests and Performance Load Tests and evaluating the results, an expert sizing can be performed to boost the performance or to meet the hardware requirements to achieve a better performance. It is detected that about 80% of all larger

September 2008 7


performance issues in test systems are due to unrealistic sizing of the server. An expert sizing is highly recommended before “Going Live”.

Re-Sizing or Optimization

Hardware Sizing should also be reviewed periodically whenever new customer specific developments come into picture or whenever new business packages or scenarios are deployed.

3.1.1.7 SAP Corporate Portal Infrastructure The figure below shows the SAP Corporate Portal Infrastructure. As shown in the figure below, there are 15 Physical Servers which are clustered and configured in a High Availability (HA) Set-up. There are 2 server nodes on each of these physical servers and hence there are 30 server nodes in total. The Portal Version as discussed above is SAP NetWeaver 7.0 SPS14.

There are 2 physical servers for database which are in HA set-up.

There are 8 physical servers in place for TREX Search and these servers are in HA set-up. The SAP TREX version is 7.00.36.00

There is a hardware load balancer on top of Portal Servers which receives the requests from the clients, looks for Web AS Dispatcher with the least connections and accordingly forwards the request. This helps to boost the performance of SAP Corporate Portal.

A firewall is place around this infrastructure to make the infrastructure secure.

Figure 3-3 : SAP Corporate Portal Infrastructure

September 2008 8


3.1.1.8 Change and Transport

SAP’s solution for Change and Transport The functions of the Change and Transport System (CTS) have been enhanced to enable the transport of non-ABAP objects. Non-ABAP objects can be attached to transport request. In the portal use case deployment takes place using the Software Deployment Manager (SDM). The transport routes have to be defined in the transport system. CTS+ also provides capabilities for transporting PI objects, J2EE developments, and for enriching transportation using the NWDI.

CTS+ enables the transportation of non-ABAP objects using the ABAP transport system. The following transport mechanisms of the SAP NetWeaver Portal (usage Type EP and EP Core) provide a tight integration of CTS+:

Package Export Editor

Export of KM configurations

Export of KM documents

Note In SPS 13, the tight integration is available for the Package Export Editor only, not for KM. In SPS 13, KM Documents that have been exported via the new transport tool can be attached manually to a transport request. KM configurations can only be transported starting with SPS 14. You need an SAP NetWeaver AS Java and an SAP NetWeaver AS ABAP. We recommend that you use the SAP Solution Manager. The system’s Support Package Stack must be NetWeaver 7.0 (2004s) SPS13 or higher. This system acts as the CTS+ domain controller and manages the transport requests. We recommend that you use a system which has SAP NetWeaver 7.0 SPS 14 installed.

CAUTION KM documents are not imported directly to the repositories of KM. The file containing the documents has to be imported from the import queue of KM. Refer to this link for details on importing KM documents.http://help.sap.com/saphelp_nw70/helpdata/EN/46/7786c59c5759d9e10000000a1553f6/frameset.htm

CAUTION KM configurations are imported directly. KM configurations might require a system restart. Schedule the import of KM configurations carefully. For details, refer to the following link: http://help.sap.com/saphelp_nw70/helpdata/EN/e1/029c414c79b25fe10000000a1550b0/frameset.htm

September 2008 9


Figure 3-4 : Change and Transport System

Transport Categories The transports can be categorized into four categories:

1. Category 1 – Any changes which bring new functionality, roles, or technologies into the Portal could be categorized under this category. These changes will be planned and approved by the Portal Business Group and scheduled for a specific pre-determined release date of the Corporate Portal.

2. Category 2 – Any changes which require a restart of the Corporate Portal. These changes pose an additional risk to the stability as they affect core components of the system. They cannot be delivered as emergency transports without proper communication and planning of downtime.

3. Category 3 – Any changes which include binaries or modifications of code or configurations of content already in production. These changes are classified as medium to low risk but due to the inclusion of par files, will be scrutinized by the change board.

4. Category 4 – Changes are solely content changes which pose little or no risk to system stability or current functionality. These transport requests require LOB approval and are then scheduled for release on the next production transport window.

September 2008 10


Transport Process Overview A good change and transport process helps in avoiding overheads and enables easy tracking of changes done in the past.

Portal content and bug fix transports are released to production weekly.

Portal Change Board (PCB) established to review/approve transports to production

All Change Requests intended for production must be submitted prior to the weekly PCB Meeting. Approval for transport will only be given if the appropriate Documentation, Testing and Business Sign-off has been completed.

All transport requests are categorized according to predetermined criteria like Scheduling, documentation requirements, testing requirements and level of approval are category dependent.

Release dates for enhancements and new applications are projected for the year. (~6 times per year). These are considered the highest risk releases and require checkpoints at various stages through development and testing.

3.1.1.9 System Integration Enterprise portal interface is characterized by device-agnostic formatting, single password security, role-based access management, and content and workflow personalization. In the most developed examples seen at large corporations, enterprise portals offer six categories of functionality.

Consolidated Corporate Communications: A unified source of internal and external information to improve the coherence of corporate communications.

Customized Employee Self-Service: Personalization, aggregation and search technologies used to facilitate and boost the effectiveness of employee self-service.

Embedded Applications: Core business applications embedded in portal interface; less-critical applications are accessible via one-click links.

Just-in-Time E-Learning: Customized, on-demand online training modules to enhance sales force preparedness and increase time spent with customers.

Collaboration and Knowledge Management: Enterprise knowledge repositories and staff expertise directories deployed to leverage both distributed and tacit knowledge.

Enterprise Dashboard: Real-time enterprise performance tracking.

In order to have all these functionalities on Enterprise Portal, we would need to integrate different systems and applications to our Portal System. SAP provides connectors to integrate different SAP and non-SAP systems to Portal. Legacy or in-house applications can also be integrated to Portal. All these systems together form a System Landscape.

System Landscape A landscape is a logical grouping of systems. The grouping of landscape can be horizontal or vertical.

We have already discussed the definition and significance of Horizontal landscapes in section 3.1.1.3.

Vertical landscapes comprise of the systems in a particular area of the landscape – for example, all of the systems that run productive services are the “production landscape”.

As shown in figure 3.1, we have ERP, BI, Solution Manager, TREX and CRM systems in the Production Landscape and Portal acts as a single point of access to all these systems. Hence, services like Employee Self-Services, Manager Self-Services, e-Recruitment, e-Learning etc. can be

September 2008 11


accessed through a single point of access i.e. Portal. The content or information displayed for these services are retrieved from the HR Module in the ERP system. Similarly, BI system provides reporting services and these reports and dashboards are rendered on Portal. TREX system helps to search for content in any system across the system landscape. The Solution Manager System helps in monitoring the other systems.

Distributed Applications

Distributed applications can either be integrated by using an Application Integrator (App Integrator) or the other way round is to set up a federated portal network. Since we have a central portal set-up for SAP Corporate Portal, we would only discuss about integration using Application Integrator.

Application Integrator With the application integrator service you can integrate remote Web applications into the portal. The service creates portal components that serve as template for iViews which represent the remote application.

The application integrator service provides portal components, focused on SAP applications:

SAP Transactions (SAP backend transactions)

Internet Application Components (IAC)

Business Server Pages (BSP)

BEx Web Applications (former BW Report)

Crystal Reports

Workplace 2.x MiniApps

HTTP based web applications

Figure 3-5 : Application Integrator

CAUTION For security reasons, the following is recommended:

Requests from the Application Integrator should not include user IDs and passwords for remote systems that the portal user should not see. Otherwise, malicious but otherwise legitimate users with an HTTP sniffer could determine the user IDs and passwords to which they are mapped. For example, do not map all portal users to a single administrator or super user.

Use SSL and HTTP POST for communication between systems.

September 2008 12


3.1.1.10 High Availability and Disaster Recovery SAP Corporate Portal uses a central portal set-up and the integration of other SAP and non-SAP systems in the system landscape is done by using Application Integrator. The Portal servers and the SAP and non-SAP SAP systems which are integrated to the Portal system are located in the datacenters at Walldorf and Rot. There is tight synchronization between these two datacenters.

High Availability (HA) is the requirement to maximize system availability from an end-users point of view. Highly available Technical Infrastructure reduces “unplanned downtimes” which can be caused by hardware crashes, application failures/crashes, operational mistakes, etc. From a technical infrastructure point of view, the architectural and technical single points of failures (SPOF) need to be identified and secured in an appropriate manner.

Figure 3-6 : Causes of unplanned downtime

(Source: Gartner Group)

System Availability Measurements

Availability Description Availability Percentage Downtime per year

Conventional 99.0 3.7 days

Highly Reliable 99.9 8.8 hours

Highly Available 99.99 52.6 minutes

Fault Resilient 99.999 5.3 minutes

Fault Tolerant 99.9999 32 seconds

Disaster Tolerant 99.99999 3 seconds

Availability Percentage: Percentage of System Uptime during a given time period

Figure 3-7 : System Availability Measurements

(Source: Harvard Research Group)

September 2008 13


Crucial Criteria for evaluation HA Setups The following crucial criteria determine the value of an HA Setup:

Degree of High Availability functionality

- Are all SPOF secured and thus eliminated?

- How many of them are remaining?

Implementation effort

- How long does it take to implement the HA solution?

Failover Detection

- How does the switch-over software detect that it needs to switch-over?

Failover Time

- How long does it actually take to bring all resource online after a switch-over?

Number of necessary machines

- How many servers (machines) are necessary to implement the HA Setup?

Architectural sustainability

- Is the chosen HA Setup future proof?

Implementing an HA Landscape To implement an HA Landscape with SAP NetWeaver, it is best to take a stepwise approach to ensure that you choose the most appropriate HA Setup and achieve an optimal balance between cost and availability. The following steps are important to implement a HA setup.

1) Understand the architecture

2) Find the SPOFs that you need to isolate

3) Understand ways to isolate the SPOFs

4) Choose a setup that isolates SPOFs

5) Implement the system landscape

September 2008 14


Figure 3-8 : Recommended HA Design Patterns

Who is responsible for ensuring System Availability? Creating highly available SAP NetWeaver systems is a joint responsibility of SAP, the platform partner and the customer.

SAP's responsibility is to provide an HA-capable integration and application platform (i.e. SAP NetWeaver) and application scenarios that run on top of SAP NetWeaver. SAP systems must be able to utilize the HA-capable computing infrastructure you have in place.

HA-capable computing infrastructure elements (hardware, operating system, database system, files system, etc.) are provided by SAP platform partners, who must also provide their platform specific HA procedures. This includes the HA configuration and switchover ability, and support of the implementation at the customer site.

The customer must define the suitable and required HA levels for their systems. It must also provide the proper IT management concepts and guidelines, and ensure the appropriate operating procedures and training of their IT staff.

SAP NetWeaver Application Server – Java The SAP NetWeaver AS Java architecture contains many features that customers may not be familiar with. The Java Central Instance (Java CI) contains the Java dispatcher, which, similar to the ABAP dispatcher, receives client requests and forwards them to the appropriate server processes. It is the Java server process that actually processes the requests and holds the session data. Also included in the Java CI is Internet Graphics Service (IGS) for rendering graphics and Software Deployment Manager (SDM) for managing an SAP Java development landscape.

The SAP Central Services (SCS) Instance contains the Java ENQUE (ENQ) server and message (MSG) server, which are also similar to their ABAP counterparts. The Java ENQUE server manages the logical locks in the system and ensures server synchronization. The Java message server is the central service for internal cluster communication (such as event notifications, broadcasts, or an

September 2008 15


exchange of cache content) and provides state information to the SAP Web Dispatcher, which processes and routes Web requests (via HTTP/HTTPS) from external clients/applications to application servers in the SAP system, and balances the load between application server instances. The database (DB) instance contains a single Java schema.

Figure 3-9 : SAP NetWeaver AS Java Architecture

HA Set-up Recommendations

HA Setup Type SAP NetWeaver AS Java

DB only in switchover group Possible

CI, SCS, and DB in one switchover group Not recommended

CI and SCS in one switchover group, DB in another

Possible

DB and SCS in one switchover group Not recommended

DB and SCS, each in its own switchover group Recommended

Figure 3-10 : HA Setup Recommendations

September 2008 16


3.1.1.11 Persistence and User Management SAP Corporate Portal uses a Corporate LDAP and Portal Database as its persistence data stores. The figure below illustrates the User Management Engine Architecture and would help you understand how the User Management works in Portal.

Figure 3-11 : User Management Engine

3.1.1.12 Accelerated Application Delivery (AccAD)

Challenges In an expanding global market, the demand for communication across geographical boundaries is critical to a company’s success. As a result enterprise organizations are spread world wide with multiple offices, systems and applications. But physical distribution poses the following challenges:

High maintenance costs

Difficult to manage, configure and secure the remote offices applications from the center.

Difficult to modify business processes

September 2008 17


Figure 3-12 : (A) AccAD – Challenges with Physical Distribution

In order to overcome the distribution challenges, Global enterprises, focused on TCO reduction, are moving from duplicate, locally managed and geographically dispersed systems to consolidated and service-oriented IT environments.

Nevertheless, when the enterprise organizations consolidate their applications in data centers, the remote offices must connect to the applications using the wide area network (WAN) connections and have new challenges.

How to overcome the WAN Latency and Bandwidth limits?

No availability for users everywhere

Difficult to assure an end-to-end security

September 2008 18


Figure 3-13 : (B) AccAD – Challenges with Consolidation

What is AccAD? Accelerated Application Delivery (AccAD) is an SAP soft appliance solution for NetWeaver customers, which enables you to turn a standard Hardware and Operating System into an application delivery appliance in a secured and centrally managed way.

The balance between centralized managed of enterprise applications and optimal end-user access to those applications is achieved by using SAP NetWeaver Application Delivery over WAN solution.

Capabilities of AccAD Optimized Access to Enterprise Applications

AccAD manages delivery of SAP applications service to multiple remote locations with:

- Application aware optimizations: Adaptive transaction messages compression, caching pattern etc.

- Offloading commodity processing

AccAD solution is managed centrally

- End-to end landscape configuration is automatically derived out of a single central “Delivery Policy”.

- Deployment of new services by “one click” delivery rule activation

End to End Security

AccAD provides an end to end security with SSL encryption for the AccAD tunnel and remote office SSL termination (SSO) and application classification.

Compression

Ratio compression (x10+ comparing to http compression)

September 2008 19


WAN Optimizations

- TCP termination

- Buffering

- Multi streams tunneling

HTTP Processing

- Application transactions detection

- Caching patterns rules

- Forward and reveres proxy

- Load Balancing friendliness also with SSO

- Enabled Content Delivery (with central scripts)

Traffic Redirection

- DNS, Web and transparent proxy

- Automatic failover

Figure 3-14 : (C) AccAD – How does AccAD help?

September 2008 20


Performance Statistics The following figures show the Performance Enhancement Statistics. The comparisons here have been made between performances achieved when AccAD Solution is used versus the performance achieved without AccAD Solution. The performance measured within the LAN is used as a benchmark. The figures indicate a substantial increase in performance when AccAD Solution is used within WAN.

Figure 3-15 : (D) AccAD Performance – Portal Login

September 2008 21


Figure 3-16 : (E) AccAD Performance – KM 5MB Download

Figure 3-17 : (F) AccAD Performance – Latency

September 2008 22


3.1.1.13 Real Time Monitoring and Analysis Real Time Monitoring of SAP Corporate Portal is done through HP Sitescope, Wily Introscope, and Solution Manager Diagnostics. These tools are used to monitor portal server availability as well as key application indicators. These tools also help to alert administrators about unwanted system behavior / downtime

The Key Performance Indicators monitored include:

Server Availability

HTTP Round Trip Time

Application Thread Usage

Database Thread Usage

ENQUE Lock Monitoring

URL Monitoring to load balancer and all nodes

Wily Introscope is used for real time analysis of memory, response time, activity etc. Solution Manager Diagnostics used for thread and heap dump analysis and assisting with root cause analysis and determination.

Regional Transaction Monitoring Regional Transaction Monitoring of the SAP Corporate Portal is done via HP Business Activity Center.

HP Business Activity Center is used to monitor portal transaction availability and response time. Data is used to view trends in data from major regions. Transactions are monitored using AccAD and direct to portal over WAN to provide transparency of impact. Transactions monitored include:

Login

Top 10 visited pages and applications in portal

Navigation

Collaboration Rooms

File Download

Logoff

Incident Reaction, Communication, Analysis and Action Real Time Monitoring tools and mechanism raises an alert to the administrators that an incident is occurring or has occurred. Communication is sent informing Key Portal Stakeholders about the severity, scope and any details currently known. The data is then gathered from affected server nodes using automated data collection scripts.

Data is analyzed by Portal Architects and technicians in IT Operations team. If the root cause is unidentified or if standard components are involved, then a Customer Message is opened with Support. After sufficient incident data is collected from the system it is then stabilized as early as possible. Root cause is determined and permanent fixes or workarounds are applied to ensure problem cannot reoccur.

September 2008 23


3.1.1.14 SAP Corporate Portal Statistics The table below shows the statistics achieved by SAP Corporate Portal

Usage Statistics

Total Named Users ~ 60,000

Unique logins per hour (average) 3500

Unique logins per hour (peak) 7500

PCD hits per month 48 million

Knowledge Management and Collaboration document hits 21.5 million

Page hits per hour 20,500

Response Time Statistics

Local Login Response Time (Average) 1.5 seconds

Regional Login Response Time (Average) 5 seconds

Regional Login Response Time (via Accelerated Delivery over WAN)

< 2 seconds

September 2008 24


3.2 Setting up Federated Portal Network A global company has an existing portal and some legacy applications for different business cases. To increase user productivity, the company would like to provide one central portal access i.e. SAP NetWeaver Portal. The company wants to integrate these portal and legacy applications to the SAP NetWeaver Portal. The company would like to enable the user to access information, services and applications distributed on portals throughout the entire organizational network.

A Federated Portal Network (FPN) allows organizations to share content between independent portals (SAP and non-SAP). All of the Federated Portal Network use cases assume that content needs to be shared between different portal servers.

3.2.1 Why Federated Portal Network? A Federated Portal Network could be considered as an option to meet the following business requirements:

Business organizational requirements

Central portal with standalone portals for business units

Autonomous portals for different business units

The following technical aspects can come into picture:

Separation of content and functionality

Interoperability with non-SAP WSRP-compliant portals

Service Level Agreement considerations sometimes might be a reason for this setup as well. You could spread the risk of downtimes to different producers, so that only the individual producer to be restarted is down and not the whole landscape.

You could for example consider splitting business-critical content (like billing systems) from non-critical but self-developed content (e.g. custom implementations for bulletin boards) to different portals, to make sure a downtime does not influence crucial content.

You might even consider that different portals have different backup cycles or SPS cycles, and thus you split them to different servers. Frequent backups and related downtimes of one portal do not influence the whole federation then.

Before diving into the details of implementing Federated Portal Network, we should try to understand the difference between Central Portal and Federated Portal Network. This would help you to understand when and why should we go for either of these options.

3.2.2 Central Portal Vs Federated Portal Network

Central Portal Federated Portal Network

In a Central Portal Setup, all users connect to this portal and all content and connections to backend systems are available through this portal.

The Federated Portal Network (FPN) could provide an option to increase end user productivity by defining one central login portal which serves as an entry point for users to content which is spread over various portals.

It offers a lean setup and central administration. FPN can help to leverage on existing investments

September 2008 25


and portal development. Existing Portals or web applications can be easily integrated. It handles services for Session Management, Eventing and Themes & Languages centrally.

With a Central Portal Set-up, there is no flexibility to independently carry out maintenance activities like back-ups, restores, upgrades etc.

With FPN you might even consider that different portals have different backup cycles or SPS cycles. Frequent backups and related downtimes of one portal do not influence the whole federation. Individual business units can maintain their own independent portal without influencing the availability or performance of the central portal.

Central Portal Set-up might lead to redundancy of content. The content needs to be created again; existing content cannot be re-used or shared as it is in the case of FPN.

FPN leads to lower redundancy as we can use content from other producer portals. The content from Producer portals can be shared or re-used.

Figure 3-18 : Central Portal Vs Federated Portal Network

September 2008 26


3.2.3 B2B, Information Portal and Legacy Applications

3.2.3.1 Business Scenario A global organization wants to have a single point of access to all their backend applications, legacy applications, business to business operations and scattered information. The organization has various existing portals for different business units and wants these portals to be accessed through a central portal. The organization wants to retain these existing portals so as to achieve higher business unit autonomy. The organization also wants to achieve flexibility in maintaining different Service Level Agreements (SLA) and maintaining back-up and SPS cycles. This business scenario can be achieved by using Federated Portal Network.

Pre-requisites Before really covering the use cases, let us have a short look at the pre-requisites for implementing a federated portal network. This sometimes already shows whether FPN covers your scenario or whether the boundary conditions don‘t match your planned setup.

FPN uses SAP Logon Tickets and thus the single sign-on capabilities of the portal in order to execute a seamless redirect between different portals. This has several implications:

All portals must have the same user basis: At least the user id has to be identical in all connected portals in order to have single sign-on working properly (recommended is that all portals are connected to the same user store, e.g. a central LDAP)

Both producer and consumer portal have to trust each other. Reason for that is, that the producer portal imports and accepts the ticket of the consumer portal – that means, that super administrators of the consumer portal can easily gain full control over the producer portal too since they control the Logon Tickets. Moreover, the consumer portal visually integrates content „as-is“from the producer portal – thus the consumer should be sure that the producer portal always contains the content that should be displayed there.

One Consumer Portal and Multiple Producer Portals This is the most common setup that we find with federated portal networks: One consumer portal connects to multiple producer portals that contain specific content. Different Business Units already own or would like to own there own portals. Reason for that might be for example the requirement to deploy content (like Business Packages) individually or extensive custom development in some business units. Maybe a mushrooming of different portals took place historically, e.g. no central unit covered the portal requirement so far. With setting up a federated portal network, portal content spread onto different autonomous servers can be integrated into one central content offering. Service Level Agreement considerations sometimes might be a reason for this setup as well: You could spread the risk of downtimes to different producers, so that only the individual producer to be restarted is down and not the whole landscape. You could for example consider splitting business-critical content (like billing systems) from non-critical but self-developed content (e.g. custom implementations for bulletin boards) to different portals, to make sure a downtime does not influence crucial content. You might even consider that different portals have different backup cycles or SPS cycles, and thus you split them to different servers. Frequent backups and related downtimes of one portal do not influence the whole federation then. Thus overall, individual business units can maintain their own independent portal without influencing the availability or performance of the central portal.

September 2008 27


In some cases, it might become necessary to set up a federated portal network. Again here we are talking mainly about the ability to integrate portal content from different portals into one unified end user experience and access through a central portal. This applies specifically to BI Java: Here we have a strong relationship to portal and KM - every BI Java instance comes with usage type Enterprise Portal. If you would like to integrate the portal UIs from a separate BI Java instance into a central corporate portal, FPN tools offer possibilities to do so.

Figure 3-19 : One Consumer Portal & Multiple Producer Portals

A similar situation applies to Composition Environment: the portal content located in CE is on a different code line (SAP NetWeaver CE 7.1) in comparison to a common central corporate portal (SAP NetWeaver 7.0). Sometimes portal content like xApps or certain business packages come with certain portal requirements to release and SPS. In case some portal content excludes each other with regards to system requirements, it might be useful to set up a federation with content running on the appropriate producer portals on different levels. For Ramp-up of Collaboration Portal there is a special case and reason for recommending an FPN setup: Collaboration Portal features will enable end users to collaborate interactively in workspaces and to work together on documents, projects, own business cards … Since the expected load on collaboration portal is unclear, during ramp up it will be recommended to run this functionality on a separate producer portal. Thus new functionality will not harm or influence an existing stable portal installation. Overall, in some cases it might be sensible to set up a federated portal network to fulfill product requirements e.g. from Business Packages.

September 2008 28


Depending on the content that is being shared and accessed, the following two approaches can also be adopted.

One Central Producer Portal and Multiple Consumer Portals Units can keep their business autonomy and utilize central company services or content. Sharing content and systems can reduce total cost of ownership.

An alternative landscape of setting up a federation is creating one central producer portal and providing central content for multiple autonomous portals. If the idea is to provide common portal content from a central portal to fully autonomous consumer (front-end) portals, then you can use this model. This model also comes handy when the intent is to divide between common global content and regionally individual content. However, you should be aware that FPN will not solve any long distance issues e.g. due to bandwidth or latency problems.

Thus companies can keep autonomous portals and use them as the entry point for end users – however, some shared (central) content can be offered, which reduces the need to recreate content in various portals. This might potentially reduce the total cost of ownership of a large portal landscape.

Figure 3-21 : Equal Consumer – Producer Portals

Figure 3-20 : One Central Producer & Multiple Consumer Portals

September 2008 29


Equal Producer – Consumer Portals You might set up a federation as well where all portals are both consumer and producer portal at the same time (but for different content). Thus all portals play an equal role in the federation and they share common content. This might be the case for example if you have different internal autonomous portals (e.g. after mergers & acquisitions you don‘t want to take the step to set up one central portal, but keep existing portals and link between them).

Another use case might be to set up a federation between an external and internal portal to share common content – although here you should be careful whether your security requirements really allow this, since direct communication from the end users browser to both portals will take place. The benefit of exchanging content between different autonomous portals is again a reduced effort since you there is no need for double-maintenance of the same content in different portals.

3.2.3.2 Logical Solution Architecture As discussed in section 3.1.1.3, the architecture for Central Portal still stands as a base architecture. We can now enhance or scale this architecture to cater to the requirements of FPN Set-up. This is demonstrated in the figure below.

As displayed in the diagram below, the BI Reports are now being published by the BI Reporting Portal. The BI Reporting Portal acts as a Producer and the Main Portal acts as the Consumer.

Similarly, the ESS-MSS applications can also be hosted on a Producer Portal which can act as a Self Services Portal and can be rendered to the end users by the Main Portal.

One more scenario can be that of a Supplier Portal. The Supplier Portal can act as a Producer Portal and the Main Portal can act as a Consumer Portal.

Similarly, an Information Portal can act as a Producer Portal and the information can be rendered on the Main Portal, which can again act as a Consumer Portal. Likewise, all the use cases or FPN alternate solutions discussed above can also be implemented depending on the business requirements.

Figure 3-22 : Logical Solution Architecture for FPN Set-up

September 2008 30


3.3 Setting up an External Facing Portal As discussed above in section 3.2.3.2, Supplier Portal, Web Information Portal, Partner Portal can act as a Producer Portals and the Main Portal can act as a Consumer Portal. The Main Portal can now render reports or other content, which reside on the Producer Portals to the end users.

But for the Supplier Portal or Partner Portal to be implemented, we would need to expose these applications over the internet. Likewise, as the term suggests, Internet Sales Portal also needs to be exposed to the public world through internet.

3.3.1 What is external-facing Portal? An external-facing portal is an implementation of SAP NetWeaver as a public website. An external-facing portal is open to the internet, providing content to anonymous users, internal and external employees, business partners, vendors, suppliers and enabling users to self-register in order to gain access to additional content and to personalize the portal.

An external-facing portal uses the features of portal that provide Web-like behavior (for example, use the browser navigation buttons) and reduce the amount of resources required to view the portal pages.

Although not always appropriate for certain resource-rich applications, the external-facing portal can boost ROI and reduce TCO by using the same platform for the company’s internet and intranet implementations.

The SAP NetWeaver Portal provides tools for implementing an external-facing portal for a variety of business scenarios allowing both anonymous and registered user access The tools and set of guidelines provide the means to create:

Public Web portals which provide informational content for anonymous users. Utilizing a solution that performs well in low-bandwidth networks and offers a familiar web experience.

Business-to-Business and Business-to-Employee Web portals which provide business partners, employees and other registered users with a Web portal that fully supports SAP application functionality (business applications, KM, etc.).

The SAP NetWeaver Portal capabilities enable and ease the creation of a Web portal. The following portal features were enhanced

Light framework page

Server cache

Advanced navigation features

Tag libraries for creating and adapting navigation iViews

Documentation and best practices

September 2008 31


3.3.2 Making Portal available on Internet

3.3.2.1 Business Scenario A global organization which manufactures hi-tech electronic devices wants to launch a corporate portal which will cater to the organizational business requirements and meets the demands of suppliers, vendors and partners to collaborate smoothly. The whole idea of launching a corporate portal is to enable:

Access to public information about the products, contacts, company news etc. to Internet users or Customers globally

Access to detailed information about products, contacts, availability status, orders etc. to vendors and suppliers

Access to information to all business partners

Access to corporate information, Employee Self-Services, Reporting, Project Management and workflows, and collaboration with colleagues worldwide for all the internal and external employees

The organization has optimized business processes and improved productivity by using SAP NetWeaver. The organization now offers a portal which meets all the business requirements.

Internet users and customers can access a public information portal with information about the company, its products and contacts.

Additionally, the organization interacts with partners or suppliers via the Internet offering a central place for collaboration and business scenarios.

To allow easy access to relevant information and collaboration between employees, the company has enabled knowledge management, user collaboration and workflows in various aspects. All the information is available in the central corporate portal.

To improve the availability and performance of portal applications, the organization is hosting a federated portal network. Thus departments can manage their portals and the applications autonomously (e.g. perform reporting without affecting the performance of the corporate portal server)

3.3.2.2 Logical Solution Architecture The figure below shows the Logical Solution Architecture for an external facing portal. As discussed above, the architecture clearly shows the adoption of Federated Portal Network. The BI Reports are being generated and published by the BI Reporting Portal which is the Producer Portal and the reports are being rendered by the Main Portal which is the Consumer Portal.

As mentioned earlier, the base architecture is scalable and hence the architectures for Federated Portal Network and External Facing Portal have been derived by few enhancements or additions.

The Web Information Portal, Partner Portal, Supplier Portal and Sales Portal are being exposed on internet. Partner and Supplier Portals and Sales Portal are integrated to the ERP System and the CRM System respectively.

September 2008 32


Hardware Infrastructure

Application Gateway Application Gateways protect applications from direct access by clients. Application Gateway acts as a “middle man” between your computer and the Internet resources. Application Gateway makes sure that there is no direct connection between:

Client and the local network

Server and the Internet

Application Gateway relays traffic between actual client and actual server. It performs checks and access controls that typical client & server software does not support. It can also provide performance improvements when used in combination with caching.

Figure 3-23 : External Facing Portal - Solution Architecture

Load Balancers

Load Balancers Provide means to scale your application infrastructure and facilitate HA and switchover solutions by distributing load to clusters of servers.

Firewalls

Firewalls provide security for access control, user authentication, and network and application-level attack protection.

September 2008 33


Web Appliances

Web Appliances provide a scalable approach to accelerate application performance, increase WAN capacity and enable application prioritization and visibility.

Web Information Portal

The business case to launch a public website and share information with internet users and customers is achieved by this architecture. The Web Information Portal shares mostly static HTML-content e.g. facilitating the KM Repository framework. The Web Information Portal will have no access to backend systems. The Network Infrastructure is highly secure with the use of multiple network zones and application gateways to protect the application. The Portal Infrastructure has a switchover cluster and is highly scalable to incorporate Adaptive Computing setup in the future. The User Management is done by LDAP which is available in DMZ. The performance is enhanced with the use of Load Balancer and the workload is distributed between instances. To make the set-up more secure, application gateways or reverse proxies are used for securing internet access.

Partner and Supplier Portal

Partner Portal provides access to relevant information and collaboration platform to all the partners and suppliers. The following applications are integrated to the Partner Portal.

Collaboration rooms

TREX Search

mySAP ERP Transactions (e.g. FI / CO)

WebDynpro application

A secure infrastructure has been provided by using multiple network zones and application gateways to protect the application. As shown in the figure, no backend system is placed in the DMZ and hence no direct access is provided to the backend systems. The Portal infrastructure for Partner and Supplier Portal would not have a HA set-up. The usage of Adaptive Computing infrastructure provides possibility to shift additional instances from Partner Portal to Public Portal if needed. The User management is managed by LDAP which is available in DMZ and hence there is a re-use of existing directory which leads to increase in ROI and reduces the TCO. As clearly shown in the figure, the TREX Installation is within the Intranet which leads to shared usage and classification as backend component.

Sales Portal

The Sales Portal exposes the content of CRM business Package through internet. The applications accessed are Business Server Pages and WebDynpro Applications. The Sales Portal doesn’t communicate or access the CRM Server directly as the CRM Server is placed in a highly secure area and the Sales Portal is placed in a DMZ. A secure infrastructure has been provided by using multiple network zones and application gateways. There is no HA Set-up available as in the case of Partner and Supplier Portal. The User management is managed by LDAP which is available in DMZ and hence there is a re-use of existing directory which leads to increase in ROI and reduces the TCO. As clearly shown in the figure, the TREX Installation is within the Intranet which leads to shared usage and classification as backend component.

September 2008 34


3.4 Stability Stability of the Portal System mainly depends on the following factors:

Solution Architecture

Hardware Infrastructure and Secure Network Infrastructure

Robustness of J2EE Engine

Robustness of the Database Engine

Development of custom applications and programs

It is very important to adopt or implement appropriate and scalable solution architecture. The solution architecture should be designed with all the business requirements in mind and should be designed to cater to all the business requirements. It is also important that the all the below mentioned critical factors are taken into consideration while designing the solution architecture.

Scalability

Stability

Performance

Security

Once we have the Hardware and Software Infrastructure in place, it is important to follow guidelines to complete the J2EE Fine Tuning exercise. Finally, make sure that you are using the right parameters for the configuration of iviews and pages.

September 2008 35


3.5 Security To maintain a competitive advantage in today's global business environment, leading companies understand the need for an enterprise portal that unifies company resources into one cohesive system, providing unprecedented access to information, applications, and services. However, when it comes to sharing vital business information with partners, suppliers, and customers, security remains of the utmost importance. This is why SAP NetWeaver Portal solution employs state-of-the-art security technology that strictly controls access to all of your enterprise resources. What you receive is industry-leading security measures that protect your systems from nefarious attacks, while simplifying user experience and providing safe ground for you to fully leverage your enterprise resources for maximum competitive advantage.

IT systems store a multitude of data and functionality critical to the success of your business. To remain competitive and capitalize on the efficiencies of e-business, your company must expose these resources to partners, suppliers, and customers, while maintaining rigorous confidentiality for restricted business information. This is why SAP NetWeaver Portal provides a centralized, simplified security system that strictly governs user access to applications and data resources – giving your enterprise the ability to operate both openly and securely.

Security features of the SAP NetWeaver Portal solution include:

Authentication – Confirms or denies user identity through user ID and password, X.509 digital certificates, or external authentication services.

Single Sign-On (SSO) – Authenticates users to multiple data resources and applications without requiring users to reenter user credentials.

Authorization – Provides role-defined content and functionality to the user, enforcing access control policies for unstructured information set by a central portal administrator.

Secure communication – Delivers strong encryption and integrity protection for all communications among users, portal components, and enterprise applications using security standards such as the Secure Sockets Layer (SSL) protocol or the Generic Security Services (GSS-API) interface.

Integrated user management – Employs directory services, which integrate user information to ensure a universal, seamless security solution.

To access enterprise resources, you must first establish your identity with the SAP NetWeaver Portal through the portal server, which serves as the main point of contact for accessing the portal. You do so with a simple logon procedure: user ID and password, digital certificates, or any other third-party authentication service (Windows authentication, SAP® Web Application Server, or SAP® R/3® system authentication, Netegrity SiteMinder and others).

Logon information, along with all client-server communication, can be encrypted using the SSL protocol – allowing employees, customers, partners, and suppliers to access the portal through the industry-standard encryption protocol.

After establishing user identity, a Single Sign-On (SSO) mechanism logs you on to various data resources and applications based on a ticketing system and account aggregation – predetermined either by the portal administrator or through user self-registration. SSO obviates the need to continuously log on to different applications, vastly improving the end-user's portal navigation experience.

For busy portals serving multiple users, a robust user-management system helps identify users for the support of authentication mechanisms, SSO, role assignment, and personalization. To this end, the

September 2008 36


SAP NetWeaver Portal solution uses directory services based on the Lightweight Directory Access Protocol (LDAP) to integrate numerous user-data repositories and simplify user management tasks and responsibilities.

Once authenticated and mapped to the appropriate resources through SSO, you are set to access data, applications, and services within the portal. For enterprise applications, user access rights and authorizations are controlled by the applications themselves. For unstructured information, however, the knowledge-management capabilities of the SAP NetWeaver Portal solution control access rights according to predefined permissions set at the portal level.

Finally, for the secure exchange of sensitive business data, every portal needs to employ security mechanisms that protect against interception. To meet this requirement, SAP NetWeaver Portal employs both the SSL protocol and GSS-API interface for encryption, authenticity, and integrity protection. Thus, a secure channel is built for all communications among your Web browser, the enterprise portal, and enterprise applications.

Figure 3-24 : SAP NetWeaver Portal Security Features

September 2008 37


3.5.1 Authentication Because a portal provides access to a wide range of sensitive business information, the process of authenticating user identity marks the first and most important step in securing your competitive resources. Failure at this junction could place enterprise assets in the wrong hands.

SAP NetWeaver Portal takes into account the central importance of authentication and provides portal administrators with significant flexibility for implementing a mechanism that corresponds to the needs of the enterprise. These include:

User ID and password

X.509 digital certificates

External authentication services:

- Windows 2000 authentication

- SAP Web Application Server or R/3 system authentication

- Netegrity SiteMinder authentication – A COM interface for connecting to external authentication services

3.5.1.1 User ID and Password Supporting the most widely implemented means of authentication, the enterprise portal calls on the portal server to verify the user ID and password entered against that stored in a corporate directory. Based on the Basic Authentication feature of the HTTP protocol, this mechanism encrypts passwords using SSL. If a user ID or password match fails against the corporate directory, access is denied.

Figure 3-25 : Authentication Mechanism – User ID and Password

3.5.1.2 Digital Certificates For environments requiring more stringent security, the SAP NetWeaver Portal solution enables certificate-based authentication through the SSL protocol using standard X.509 digital certificates. This approach eliminates the need for passwords, while providing a higher degree of security. The process unfolds as follows:

The client presents a certificate along with a digital signature of some random data to the Web server.

The Web server then determines whether or not a trusted server has issued the certificate.

If so, the Web server verifies the digital signature by extracting the public key from the user's certificate.

September 2008 38


Successful verification of the digital signature assures that the client indeed possesses the correct private key belonging to the public key contained in the certificate. Thus, the client achieves authentication. User information can then be extracted from the certificate and compared against user data stored in the corporate LDAP directory. If a match is made, portal access is granted.

Figure 3-26 : Authentication Mechanism – Digital Certificates

While increasingly popular in a security-minded business world, certificate-based authentication does require the implementation of a public key infrastructure (PKI) within the portal context. A PKI creates and manages trust relationships using a Certification Authority (CA), run by a trust center, which builds links between people and digital identities using digital certificates.

Before requesting a certificate from a CA, a user must register with a trustworthy registration authority (RA). Ideally, this registration process integrates directly into the portal's user management solution and provides the ability to pass user data directly to a trust center. SAP NetWeaver Portal solution delivers just this kind of integrated RA functionality – allowing users to request certificates by passing user data straight to the SAP Trust Center Service.

Provided free of charge for SAP users, the SAP Trust Center Service creates a trust community for collaborative business – issuing X.509 digital certificates and offering simple, secure registration and revocation functionality. Alternatively, companies can set up their own internal PKI by installing a CA software solution from an independent vendor, or using an external trust center service from one of the numerous service providers available on the market.

3.5.1.3 External Authentication The SAP NetWeaver Portal solution supports the use of external authentication services for access to the portal itself, making the reuse of existing mechanisms highly secure and easy to incorporate. These include:

Windows 2000 Authentication – For authenticating users accessing the portal from outside enterprise boundaries, SAP NetWeaver Portal seamlessly integrates the use of the Windows 2000 Domain Controller. The portal user enters user name and password information into a browser dialog box and the Domain Controller manages the authentication process using the HTTP Basic Authentication feature. In the context of pure intranet portals – where access to the portal is granted from within the enterprise – a previously successful logon to the Windows operating system can be reused for portal authentication through the Windows LAN Manager (NT challenge response).

SAP Web Applications Server or SAP R/3 System Authentication – By synchronizing with the corporate LDAP directory, SAP NetWeaver Portal can authenticate users based on data stored in the SAP Web Application Server or another SAP R/3 system. Portal users simply

September 2008 39


enter their SAP user ID and password information to gain access. In such a scenario, passwords remain in the previously existing SAP system and are not written to the corporate LDAP directory.

Netegrity Authentication – Netegrity SiteMinder is a solution for securely managing user access to e-business Web sites. The SAP NetWeaver Portal solution seamlessly integrates portal authentication into existing mechanisms supported by the SiteMinder product. When used in the portal environment, SiteMinder authenticates the user and returns a user ID to the portal server as part of the HTTP header. The portal server compares this returned user ID against the user profile stored in the corporate LDAP directory and grants authentication upon finding a match. (Other similar Web access-management tools can be integrated on a project-specific basis).

Third-party External Authentication Services – By way of an integrated COM interface, the enterprise portal can delegate authentication to external services. The portal server simply passes user information onto the external service. Once authenticated by the external service, user information is compared against that stored in the corporate LDAP directory. If a match is made, access is granted.

3.5.2 Single Sign-On Single Sign-On (SSO) provides secure access to multiple systems without requiring users to reenter ID and password information for each application. In a portal environment, an SSO mechanism maps portal authentication information to each application for which a user holds predefined access permissions. This reduces user frustration, providing enhanced interaction with enterprise resources via the portal.

The SAP NetWeaver Portal solution employs two SSO mechanisms, depending on security requirements and the supported enterprise applications: SAP logon tickets and account aggregation. These are discussed in the sections that follow.

3.5.2.1 SSO and SAP Logon Tickets SAP systems can authenticate users through SAP logon tickets. Under this mechanism, the user first logs onto the portal using a portal ID and password, for example. After authentication, the ID is mapped to the corresponding user ID in the SAP systems. Stored as a non-persistent cookie on the client side, the ticket then authenticates the portal user for all subsequent access to the portal itself as well as to SAP systems – without requiring further logons.

Figure 3-27 : SSO Mechanism

September 2008 40


SAP logon tickets contain the following information:

Portal user ID – and optionally mapped user ID in SAP systems.

Validity period – adding an extra element of security through session expiration parameters defined by the portal administrator.

Issuing system – identifying the source.

Digital signature – ensuring integrity protection and providing the means for applications to verify the trust status of the issuing portal server.

Notice that SAP logon tickets hold no password information. Furthermore, all tickets are stored per session in the browser's memory rather than on the client's hard disk, which would run the risk of unnecessarily exposing authentication information. Finally, all logon tickets get encrypted through the SSL protocol while in transport to protect them from unauthorized use by eavesdroppers.

To assure the utmost security, each enterprise application verifies the validity of the contents of a ticket when called. This process requires the digital certificate of the issuing portal server. The application verifies if a trusted portal server has issued the logon ticket, verifies the digital signature, and extracts the appropriate user ID.

Portal administrators can implement a similar logon ticket mechanism for non-SAP systems using two tools integrated into the SAP NetWeaver Portal solution. First, a Web-server filter can perform the necessary verification steps and write the portal user ID into the HTTP header. Second, an application programming interface (API) and a corresponding verification library allow for validation of the logon ticket and extraction of the application's user ID.

3.5.2.2 SSO and Account Aggregation Account Aggregation associates a portal user (or group of users) with a user name and password in an enterprise application, providing a useful alternative for enterprise applications unable to take advantage of SAP logon tickets. Once in the portal and mapped to the appropriate applications, the portal user no longer needs to manually log in to any external systems. Instead, the portal components connect directly to the external systems with the mapped user's credentials.

User mapping information is entered by the portal administrator, or directly by the portal user through a provided graphical interface. The portal itself then stores this data in the portal LDAP directory. For security reasons, all password information is encrypted (Triple DES algorithm).

3.5.3 Authorization Upon achieving authentication, the user needs authorization to access certain applications or perform specific tasks. To this end, SAP NetWeaver Portal provides a role-based interface that simplifies application and information access. An administrator assigns roles to the user, who receives a personalized display depicting a navigation hierarchy of pages, work sets, iViews, services, and user interfaces for particular applications – all corresponding to the permissions defined by the assigned role.

For structured data, authorization is enforced by the corresponding enterprise application, not by the portal. For standard SAP roles from R/3 systems, SAP provides a migration tool that imports the roles into the Portal Content Directory (PCD), including menus of authorized transactions. A synchronization feature also enables administrators to change or create roles within the portal environment and export them back to the SAP R/3 systems where permission definitions ultimately reside.

Through the use of Access Control Lists (ACLs), the knowledge management capabilities of SAP NetWeaver Portal control all authorization for unstructured data – files, documents, Web pages, and

September 2008 41


so on. Here, authorizations take the form of “create,” “read,” “write,” and “delete” controls, attributed either to specific documents or entire folders. New documents and folders inherit the authorization of the home folder in which they are created. Additionally, “full control” authorization allows administrators to set and change permissions for specific documents or folders.

3.5.4 Secure Communication To protect business confidentiality in an enterprise portal environment, all exchanges of mission-critical business data require secure channels of communication protected by standards such as the SSL protocol or the Generic Security Services (GSS-API) interface. Both SSL and the GSS-API interface provide the following security features:

Confidentiality of communication – Encryption of all messages between client and server prevents eavesdroppers from accessing private enterprise content.

Authenticity – Digital certificates authenticate all messages between client and server, confirming the identities of communication partners.

Integrity – Message Authentication Codes (MACs) provide integrity protection that allows receiving parties to immediately recognize any manipulation of exchanged messages.

Secure communication between the user and the enterprise portal requires SSL and encrypted logon information using algorithms with strong key lengths. For communication between the portal and content-providing components, the security mechanism used is context-specific: HTTP communications use the SSL protocol, whereas communications specific to SAP-systems (such as RFC) use the GSS-API interface. Both the corporate and portal LDAP directories, furthermore, hold highly sensitive user information requiring strong security measures. Therefore, all messages between the portal server and these directory servers employ SSL.

3.5.5 Integrated User Management Consistent user management requires the integration of the numerous data repositories scattered through the IT enterprise. To this end, the mySAP Enterprise Portal solution integrates LDAP directory services that centrally store user information, simplifying user management in an environment of proliferating applications.

With simple replication, synchronization, and direct access mechanisms, LDAP directories provide convenient user management for distributed systems and easier means for implementing tighter security. The following shows the data repositories and their contents as it relates to user management for SAP NetWeaver Portal. Prior to the implementation of a portal, many system landscapes already employ a Corporate LDAP Directory. To avoid redundancy, SAP NetWeaver Portal accesses user information at its original location in this corporate directory. Where each company defines a unique attribute schema for storing user information in directory servers, the portal maps the logical attribute names used by the portal to the physical attribute names used by the corporate directory.

Portal Database or a separate Portal LDAP Directory maintains portal-specific information such as the assignment of roles to users and groups and Single Sign-On user mapping information.

Alternatively, administrators can set up a separate branch in the corporate directory to hold portal-specific information, assigning write-access rights to the portal for that branch alone. Currently, the SAP NetWeaver Portal solution supports the following LDAP directory server products:

Novell eDirectory

iPlanet Directory Server

September 2008 42


Microsoft Active Directory Service

A third directory – the Portal Content Directory – contains roles and their metadata, information for the assignment of content to roles, and user profiles employed for personalization purposes. This directory uses the existing file system for data storage. For the user management tasks associated with these directories, the SAP NetWeaver Portal solution provides easy-to-use tools for:

Administering role information (metadata)

Assigning roles to users and groups

Mapping Single Sign-On user information

The SAP NetWeaver Portal solution also integrates with user management information defined in pre-existing SAP systems using the Central User Administration (CUA). This component enables administrators to store all SAP user data in a central system that can be synchronized with the corporate LDAP directory.

3.5.6 Secure Network Architecture All of the security mechanisms outlined above – Authentication, Single Sign-On, Authorization, Secure Communication and User Management – work best in the context of a secure network infrastructure focused on preventing unauthorized access to confidential business information. Above and beyond these mechanisms, corporate security strategists should locate highly sensitive systems and components – such as the portal server and unification server – in a separate area, sealed off from outside attacks. Likewise, access to sensitive application and database servers should be granted only through a demilitarized zone protected by numerous firewalls and proxy gateways serving different purposes.

In such a configuration, firewalls and the proxy gateway protect the portal server, the unification server, and persistence layer data (repository, portal LDAP directory, portal content directory) from network attacks. System administrators need only open a single port on the external firewall, which allows only TCP connections from client machines to access the port running the proxy gateway. The proxy gateway translates the IP address of the server holding the desired information or functionality and opens a separate connection. In this way, client machines can never directly access sensitive servers and repositories – greatly reducing the risk of attackers obtaining confidential business information.

September 2008 43


Figure 3-28 : Secure Network Architecture

September 2008 44


3.6 Performance Monitoring and Troubleshooting Performance typically results in two metrics:

Response time which is the speed of task completion

System throughput which is the amount of work done in a given amount of time

The basis for scalability and performance modeling is the measured resource consumption, which is influenced by the following four KPIs:

CPU time consumed

Peak memory used

Disk space

Network load

The following exercise would help to improve the performance of Portal System:

Tune the application through customizing, configuration and functionality

Re-schedule load to distribute it more evenly across servers and time

Tune the system via profile parameters and buffer sizes

Add hardware, e.g. additional application servers (but consider impact on DB server) and additional CPUs/memory on server(s)

Programming for good performance means making conservative use of critical resources, keeping response time at a minimum, taking into consideration aspects of network communication, as well as ensuring the scalability of the software. Optimize the coding can help to increase the performance of Portal System

3.6.1 Monitoring Set-up If the details of a performance problem are not yet known, it is advisable to activate the collection of monitoring data with several tools.

All operating systems maintain counters to keep track of critical system resources. The reports based on these counters are an indication of how the major subsystems are performing. SAP NetWeaver Portal and J2EE Engine and the JVM also maintain performance information for important resources in their own scope. These two types of counters described above are forming our monitoring setups.

In this guide, we will focus on operating system-based tools since these are always available. SAP also offers monitoring integration into the Solution Manager.

The setup of the monitoring infrastructure is exemplified for all platforms supported by SAP NetWeaver Portal. Only common OS tools are described, as well as monitoring tools provided by the portal and J2EE Engine. However experienced users are also recommended to use tools of their own choice as long as they collect the data described in this section. When available at customer side, commercial or freeware automated tools for system performance analysis could be used as well.

In general, the monitoring setup should not only be established for the portal machines, but – as far as applicable – also for all kinds of backend systems like database machines, SAP WAS-based backend systems, custom storage systems, customer specific backend systems, etc.

This section is split into one part that describes operating system independent steps to activate monitoring and into one subsection per supported operating system that covers the collection of configuration and monitoring data specific for this operating system.

September 2008 45


All important counters defined here could be collected automatically in a productive customer environment with no risk and minimum performance degradation. We recommend you perform regular system monitoring, by applying the monitoring setup, even if the system is working fine for the moment. This may serve as a base of comparison. We also recommend that customers keep the monitoring setup activated as long as possible.

3.6.1.1 Checklist As a quick reference, check that the following monitoring tools are in place.

□ Collect performance data on operating system level (CPU consumption etc.)

□ Collect configuration data on operating system level (CPU power, memory etc.)

□ Activate -verbose:gc Java VM option

□ Enable creation of full thread dumps for J2EE Engine nodes

□ Start J2EE monitoring

□ Make sure that portal monitoring is active (is active by default).

□ Activate the extended HTTP log to record response time and response size

3.6.1.2 OS Independent The following monitoring tools are available with all supported operating systems.

JVM Garbage Collection Trace

The Java VM can be commanded to write a garbage collection trace. Use –verbose:gc as Java VM parameter in the startup script (e.g. go or go.bat) of each application node, state controller, and dispatcher node. This parameter works for all Java VM versions that are supported by SAP NetWeaver Portal. The location of the VM parameter settings depends on the mode you use to start the J2EE nodes.

Enable creation of Full Thread Dumps

Depending on the startup mode of the J2EE Engine nodes, preparatory steps may be necessary to trigger full thread dumps and to capture the VM output that contains these dumps.

J2EE Engine Monitoring

The J2EE Engine Monitor Server provides measurements for the J2EE Engine runtime environment and can be included in the monitoring setup defined here because of the negligible performance impact.

A single Monitor Server is sufficient for the whole cluster. The Monitor Server can be located on any machine with a fast network connection to the machines with installed J2EE Engine cluster nodes. The Monitor Server automatically registers or un-registers cluster nodes which have been just started or have dropped.

September 2008 46


Monitor Response Times and Throughput per URL

The best and easiest way to narrow down the area of a slow response time to a single slower URL is to use the http service logs on server nodes. At log level “INFO” the http service writes information about the URL that was accessed, together with the response code, body length and response time for this URL. The valuable log is located in the file <installation-folder>/cluster/server/services/http/log/INFO. log.

The option to write the response times in the log is activated in the file server/services/http/properties. Use LogRequestTime=enableall (and EnableLoging=true) to have the response times for each URL which was called. A sample log line would look like

2004-07-05 14:10:58 | http | INFO | | 127.0.0.1 | 127.0.0.1 - - [05/Jul/2004:14:10:58 +0100] "GET /irj/servlet/prt/portal/prtroot/com.sap.portal.navigation.portallauncher.default" 200 2878 [5318] |

The number in square brackets [] is the time in milliseconds spent on the request on the server node. The number of the position before the execution time is the number of bytes sent to the dispatcher node as the body of this reply.

SAP Enterprise Portal Monitoring

SAP Enterprise Portal monitoring must be active for problem analysis. You can check this by navigating to System Administration - Monitoring - Portal - Component Overview. If the displayed table is not empty, monitoring is active and no further steps are necessary. If monitoring is disabled, reactivate it by navigating to System Administration - System Configuration - Monitoring Configuration and select the checkbox Collect monitoring data.

3.6.1.3 OS-Specific The following data and counters help in monitoring.

Collection of configuration data

CPU and Memory Performance Counters

Network Performance Counters

Disk Performance Counters

September 2008 47


3.6.2 Analysis Worksheet The following analysis worksheets guide you through the interpretation of the collected performance counters. In many cases, however, the OS-level performance data is not sufficient to derive conclusions. Instead, it only provides indicators that must be correlated with data from other parts of the monitoring setup (e.g. verbose: gc trace, portal monitoring etc.).

3.6.2.1 Health System Worksheet If the following metrics are achieved, you can consider your Portal Systems to be healthy.

Performance Counter Thresholds

Total CPU time (User + system [kernel] time) (related to CPU)

85%

For Unix systems, where the load is relative to the number n of CPUs (for example 4 CPUs fully loaded = 400% CPU) , use the formula load average < 85%*n

User time related to System Time (related to CPU)

System time <= 10% of user time

CPU busy due to disk IO operations (related to CPU)

10%

Context switches (related to system faults) If n is the number of CPUs, then 1500*n is the targeted value. Values above 5000*n are considered a problem

Pages in and pages out (related to memory) Ideally, there should not be activity. It may be a memory problem if the values are higher than 200 memory pages per hour. But conclusions can only be drawn if proven against other memory counters.

Free memory (related to memory) There must always be some free memory available on the machine.

Percentage of active disk time (related to Physical disks)

The percentage of disk active should not be higher than 10%, and the single operation time should not last more than 30 ms for Portal activities. If it is a database or other kind of persistence storage machine, the busy time could be different.

Connections handling (related to network) The number of connections in all phases of the connection “close” process must be tracked. Times for closing connections on different OS are configurable, and the faster the old connections are closed, the more room will be available for new connections.

No “expired” connections are allowed in keep–alive mode, no refusals are allowed for connection at OS level.

September 2008 48


Bytes transferred (related to network) Heavy traffic means high overall throughput, so the closer to the network card abilities, the better.

Several architectural facts about Portal and J2EE Engine are discussed below.

CPU The targeted CPU ratio for system and user time can only be achieved if dispatcher activities are not intensive. For a J2EE dispatcher node, the system CPU time is almost equal to the user CPU time. For J2EE server nodes, the ratio described can be achieved with proper thread count configuration (normally reducing client threads to less than 10, and the system thread around 20 improves the ratio of user to system CPU usage).

Low CPU usage (or alternating quite high and quite low CPU usage) in combination with an overall slow portal may also be caused by frequent full garbage collections. During garbage collection, only a single CPU is used by a Java VM.

Two possible reasons for high system CPU time are heavy I/O activity (disk or network) and lock contention. Lock contention means that many Java threads are blocked from execution since they are waiting to get access to some resource. To investigate lock contention, see Section Java VM Thread Analysis.

Memory The total amount of memory allocated by all Java processes and other processes relevant to the portal (e.g. database processes if running on the same host) has to fit into main memory.

In particular, the sum of the heap size (Xmx, Xms) and the maximum PermSize for all JAVA processes must be configured to fit completely into main memory (RAM) since the effect of paging will be much more intensive than in any other program. When calculating the sizes, also consider memory needed by all other active processes and by the operating system itself.

Disk I/O The Portal and J2EE Engine can easily be configured to collect a lot of information in log files. If you observe high disk I/O, carefully review the log configuration to reduce log levels to a minimum. Most of the logs are designed to be used for troubleshooting only, and not for being active permanently on a high log level during productive use. To get a quick idea of expensive portal log files, see the portal log directory. Based on the timestamp of files and the log lines contained in the files, estimate how much data was written during the last hour or day. There should not be more than a few MB of log data per hour (except for HTTP access log). Other locations to check for log traffic:

Server/managers/console_logs

VM output log

Access log of a reverse proxy (IIS, Apache)

Log of an IIS filter (e.g. iisproxy.dll)

We recommend that you put unavoidable logs on the fastest disk drive available on the machine or in a sufficient I/O buffer configured to prevent the I/O from slowing down the complete system.

Network In terms of networking, everything depends on the scenario throughput per single user. However, bear in mind that because of the dispatcher/server architecture, the whole throughput is sent through

September 2008 49


sockets twice – once between dispatcher and server node and once between dispatcher and client. Additional proxies, firewalls, Web dispatchers, or load balancers make the network situation more complicated. You can ignore normal traffic between dispatcher and server nodes for keeping the cluster available.

3.6.2.2 Operating System Memory Worksheet Memory templates can be applied in instable situations, accompanied by “Out of memory”, in cases of low and unstable CPU usage, in reported blocking situations, or if there is just bad performance.

Value Reported By

Used, Free Memory OS

Paging OS

Is there a main memory shortage?

If there is shortage of main memory, the system starts swapping memory pages to and from the extended memory. Paging activities are observed in the OS monitoring. Calculate the overall needs of all relevant portal and system processes. If this value exceeds the amount of RAM, more physical memory has to be added on the machine – this is the only recommended permanent solution.

Are there enough server nodes configured?

If free main memory is available on the machine, and at the same time the server node is using all the memory that was allocated for the Java heap, and in parallel there are intensive GCs and slow responses, then an additional server node could be joined to the cluster. Redistribution of the Java heap for all cluster node JVMs running on the box might be necessary. The total heap size of all dispatcher and server nodes plus some tolerance for OS resources must fit within the available main memory.

Is the problem inside the dispatcher?

Memory consumption of the dispatcher in general is a function of load. Generally the dispatcher consumes less memory resources than server nodes, but if memory is not sufficient, this could slow down the overall performance. Check the GC activities trace of the dispatcher nodes. There should not be any full GCs and the times for small GCs must be < 0.01 second.

3.6.2.3 CPU Worksheet The CPU template is applicable in situations of unsatisfying performance in general or performance degradation.

Value Reported By

CPU usr, sys OS

Context switches OS

System threads J2EE Engine monitoring

Client threads J2EE Engine monitoring

September 2008 50


Response times of http requests J2EE Engine monitoring

Http sessions J2EE Engine monitoring

DB Pools J2EE Engine monitoring

Logged users Portal Monitoring

Response time statistics for Iview Portal Monitoring

The statistics history for CPU-related performance counters could answer the following questions.

Is the CPU overloaded and why?

If the CPU is more than 85% loaded, the portal runs in an overload condition and an erratic behavior is expected. Correlate the information with the number of logged users, number of http sessions, response times of the request, number of users when the CPU was in 85% range, and how the number of users increased since then. Check the INFO log of the http service and look for different URLs that are not derived from the usual set of components. Possibly some other non-typical URLs were called more often to components which require more intensive CPU processing at the time when CPU usage increased.

Do you observe unstable CPU usage and blocking situations? Has the JVM heap been configured properly?

If the GC activity trace contains many records of full GC calls with different durations, this could reflect an unstable CPU usage curve, because when full GC is in progress, CPU activities for all threads inside JVM are stopped. In such cases the JVM heap is considered to be configured properly or there is severe memory leak. Even worse - if GC lasts longer or at some levels of memory usage stops repeating in very short intervals, this results in “portal freeze” complaints at the customer side.

Is CPU used effectively for customer requests or is system reconfiguration required due to high system CPU times?

Unfortunately, with the J2EE Engine architecture one cannot really eliminate system CPU time. On machines where the dispatcher is running, you may observe increased system CPU times. If monitored per process and if the dispatcher is busy, the system time for the dispatcher process could be even 150% of the user time for the dispatcher process. A problem for the system is indicated if the system times of server node processes are high. If the system time is too high – above 8 % - check the memory template with regard to paging activities, the disk template with regard to hard disk activities, or the network with regard to delayed backend responses. High system CPU time could be due to disk IO contention or synchronizations in JVM. If this behavior is observed with a recently deployed customer application, it would be worthwhile to check if there is heavy synchronization implemented there.

Is performance degradation over time related to changes in the CPU usage?

Observe at what percentage of CPU load the user response time gets slower. Correlate this using the OS CPU monitoring and response times of http service INFO log in the extended J2EE Engine monitoring setup. Has the ratio between user and system CPU time changed at this point? Check if you encounter an overload condition or are there any wrong configurations indicated as discussed above? If not, you may have to look on application level.

September 2008 51


Are there idle JAVA threads that raise unnecessary counts of context switches?

Check against the idle statistics for running client threads (from J2EE monitoring) and system threads. If there are many threads in idle status, reconfigure the engine thread pools to the number of threads actually running. We recommend that you leave some requests in the request queues rather than having idle threads.

A small example would be that 1 dispatcher and 3 server nodes are running on a system, each server node having 40 application threads. The number of context switches per second is 70 000 and system CPU time is 40% for server processes. Reducing the number of threads on the server nodes to 5 in the same scenario reduces the number of context switches to 30000 and the system time for server processes to 8%. In general the large number of threads makes scalability of an application difficult due to GC, synchronizations, IO waits, socket calls, etc., and is not recommended.

Are there sufficient database or backend connections, or is the system waiting for connection resources indicated by de-scheduling threads?

Check the J2EE Engine monitoring of database connection pools. There should be no threads waiting for database connections. If you see any, slowly increase the number of connections until you reach a balance.

3.6.2.4 Network Worksheet An improperly configured network could damage portal performance. A slow network has such effects as inadequate CPU usage, scalability problems, and other symptoms that push the search of the problem in the wrong direction. It is important to know that on UNIX systems OS experts usually reconfigure TCP-related parameters if the machine is going to be used as a Web server.

Value Reported By

TCP connection statistics OS

Connections manipulator (connections count) J2EE Engine monitoring

Database pools (connections count) J2EE Engine monitoring

TCP connections to R/3, LDAP, other backend SAP Info and Niping tools

Byte transfer rate OS, Niping Tools

Body length of http responses J2EE Engine monitoring

Cluster communication and number of bytes J2EE Engine monitoring

The network template maps connection management information and network traffic information. The network template is suitable to answer the questions:

Do customers encounter connection problems to the machine or is there just a problem with the J2EE Engine dispatcher?

The J2EE Engine dispatcher node has a connection capacity that is proportional to the physical memory of the dispatcher node. It could be that either the dispatcher node has reached its capacity level or that the OS is configured to maintain limited (too few) connections. You can reconfigure the last two until the limits of physical capacity are reached.

September 2008 52


Is there accumulation of keep-alive connections?

Recently browsers tend to establish keep-alive connections. Some OS settings could prevent the machine itself from establishing and destroying huge numbers of connections in a short interval. Making and breaking too many connections at one time could be a problem due to slow recycling of invalid connections. Another problem might be that the dispatcher delays discarding “dropped” keep-alive connections from its connections list. Sometimes the dispatcher maintains “phantom” connections for a short time, limited by the keep-alive expiration timeout property of the J2EE Engine, and then refuses new connection requests if the capacity has been exceeded. For a limited time fewer users are able to actively send requests to the server.

Does the number of connections correspond to the number of http sessions?

In recent browsers there is usually an average of 2 connections opened from the browser to the dispatcher. Since the expiration time of a keep-alive connection is normally considerably shorter than the expiration time of a user session, the number of keep-alive connections is probably approximately the same as the number of active http sessions.

How is the throughput of the system?

By monitoring the network interface, the complete throughput of the system becomes clear. To summarize the length of response bodies of http requests form the complete outgoing traffic, one may use the http INFO log over the whole runtime or only for the specified interval and correlate the information with that from the network interface.

Dispatcher and server nodes are not really consuming CPU, but the response times at the client side are very slow

This might be caused by the proxy and the network configuration in general. The values collected with NIPING would be very useful.

Network seems to be slow

Check the number of packages and the package size. The portal produces bigger data packages. The average number of bytes transferred for a page load is more than 4K. Check the TCP settings for the system. An increase in the size of TCP send-receive packages would reduce the number of sends/receives and therefore could speed up performance.

3.6.2.5 Disk Worksheet High system load is indicated even if user activity is not very high or under normal conditions a degradation of response time is encountered. Traditionally, I/O performance tuning has less significance than for example CPU power. The convenience of a garbage collector resulted in careless object generation, especially in generic application designs. So our initial thoughts about performance concern the processor load and memory consumption. This is unfortunate, because the significance of I/O tuning is exceedingly high. Since disks are about six orders of magnitude slower than physical memory, avoiding disk access and making those disks that are necessary as fast as possible can have a huge impact on application performance.

Unfortunately, there are no direct high-level indications about disk problems in the customer complaints. Misbehavior in this area can be detected by correlating CPU activities with disk activities. That is why it is best to look at the data collected for disk IO and analyze it directly.

September 2008 53


Value Reported By

Percentage disk busy time OS

Time for single disk read/ write operation OS

Amount of data transferred (KB) per second OS

Number of transfers per second OS

Paging OS

Disk queue length OS

Log and trace levels Administration tools of J2EE Engine and Portal

System threads and client threads J2EE Engine monitoring

What is the impact of the disk queue?

Hard disk activity monitoring is extremely important for database machines or other persistent storages machines. If there is a disk queue on a database machine, this could be quite a problem for the whole landscape. The database volumes have to be at on different physical disks to minimize writing synchronizations.

Does the portal log a lot and could result in a performance slowdown in the response times?

Check the data collected for the drive on which the portal is installed. It is recommended that no other component is configured to write to the same drive, because the portal itself uses the hard disk actively. A log action or couples of log actions take place at one portal request, so the time per log operation, if too high, is pure degradation. Consult with development which minimum level of logging is possible. Some performance guides state “If the disk IO is too high, re-architecture the application.” One way with portal is to reconfigure the log levels. Another way is to decrease the number of system or client threads if this is too high, ensuring fewer logs per interval. If possible, create a dedicated file system for HTTP logs. Striping is also a good recommendation, and RAID 5 arrays are an excellent choice, as they provide some fault resilience while maintaining good performance.

Is the disk cache well configured?

The default side of disk cache on almost all platforms is 2% of main memory. For simply Portal logging this would be sufficient. For database machines it is not.

Are processes blocked on disk I/O?

Look for disks that have a “service time” greater than 50 ms and a disk that is busy more than a few percent of the time. An overloaded disk could reach response times over 1000 ms.

Service Time: The service time is a historic dimension. It measures the delay between a process issuing a read request and that request being completed, so it could also be called response time.

Is it necessary to reconfigure the number of pages that are flushed to the disk with a single operation?

On database machines and perhaps on the portal machine, the number of pages per single IO operation could be increased. For example, on Solaris increasing the maxpgio property 3 times brought 500% performance improvement on a database machine.

Check for real-time virus protection with a high number of I/Os

September 2008 54


Is any process causing a high number of I/O operations?

Use the task manager and activate the additional column I/O Reads. Sort by this column and watch the processes with the top number of I/Os. If you see more than 50 operations per second, this is definitely an indication of high I/O. In particular, real-time file protection by antivirus software may trigger such a high number of I/Os. To be on the safe side, completely uninstall the antivirus software from the machine. Some antivirus programs (e.g. Netshield) even have a performance impact if they are disabled.

3.6.3 Portal Workload Analysis The monitoring infrastructure of SAP Enterprise Portal measures response times and data volume for all requests. This can be used to analyze the portal workload in detail and to identify the most expensive iViews.

JARM Basics

The portal monitoring infrastructure is based on JARM (Java Application Request Measurement). Strategic locations in the portal infrastructure are instrumented to measure the elapsed time to process requests. Time measurements include calls to modules of the portal infrastructure (user management, PCD etc.) and the invocation of (standard or custom) portal iViews to render portal content. Thus, portal monitoring can be used to identify expensive iViews and to a limited extent to identify problems in the portal infrastructure.

Overview of Portal Monitoring iViews

Portal monitoring provides several different iViews to display the monitoring data collected with the monitoring infrastructure. To access portal monitoring, you need assignment to the system_administrator role. Within this role, navigate to System Administration - Monitoring in the top-level navigation and choose Portal in the detailed navigation. There you find the iViews that are useful for workload analysis. We will see that portal monitoring can be used to identify expensive iViews and to identify problems in the portal infrastructure.

Identifying Expensive Content with the Component Overview

The component overview lists the aggregated elapsed time for each component and the number of component executions (from which you can derive the average execution time per component). Based on the fact that typically most of the processing time for an iView is spent in the PRT_render top-level component, this component can be considered as representative for iView execution time. Thus, by filtering the component overview to the component prefix EP:PRT_render, we get the cumulated and average execution times per iView (If you want an even more precise drilldown, filter to the prefix EP:PRT. This also includes the other two top-level components EP:PRT_init and EP:PRT_action).

Request Overview: Most Expensive Request Executions

The request overview lists the most expensive requests since startup of the portal node. If a specific user complains about performance, filter the overview to this user ID.

The request overview is only useful in some cases. Frequently, the most expensive requests are processed directly after portal startup since the Hotspot compiler of the Java VM, filling caches, and classloading require some “warmup” time. These requests are not of interest, since they yield a much lower response time once the system is warmed up. To identify these requests, compare the request execution time with the “time of first request” in the request summary. If these timestamps are similar, the requests are ignored. Even if the timestamps are not similar, there may still be a user that performs a specific request as the first user after a system restart (e.g. system restart at midnight after an offline backup and first user

September 2008 55


accessing the system at 7 AM). Furthermore, single requests may suffer accidentally from a full garbage collection and show up as the most expensive request for this reason. To filter out the first requests after startup, you can also filter the display by the start time of request, e.g., removing the first 30 minutes after startup or restricting the display to the last few hours.

Given these limitations, expensive requests can only be identified with the request overview if you see several requests with the same name distributed over a period of at least one hour. For example, there may be administrators who repeatedly perform a search for a user without specifying enough details about the user, thus returning a list of several thousand user accounts. To identify the expensive requests of interest, try different sort orders and filters for the display. For example, can you detect that the same user ID or user group always causes expensive requests? Are the expensive requests concentrated on a certain time frame (during which some other activity like background jobs or garbage collection took place)? Does the user ID belong to some background service?

Snapshot Monitoring with the Thread Overview

The thread overview is similar to Transaction SM50 of the ABAP stack of the SAP Web Application Server. It lists all requests and components that are currently being processed. For each active thread, the user ID, the portal component, the Java class for the component, and the elapsed time for the request are listed. The vertical line in the figure in Section 5.1.1 gives an example of how the thread overview is calculated: The thread overview uses the JARM instrumentation and simply grabs all requests and components that are not yet completed.

Active Users

The Active Users iView lists all users for which there is still a user session in the cache. If the user has logged off explicitly or if his user session was removed from the cache, it will not be listed here. Note also that this iView is not based on JARM.

If you find a very large number of users in this iView and at the same time observe memory problems, the number of users may be the reason for memory shortage. Check the workload distribution or try adding more J2EE nodes to the EP cluster. A large list may also be an indicator that most of the users did not log off from the portal. In this way memory in the Java VM is wasted for the session.

Workload Distribution

Note that all iViews only display data for one single portal server node at a time. Compare the workload between different server nodes (such as number of users in Logged On Users, requests per second and total number of requests in Request Summary), especially if there is a custom load balancer in front of several J2EE dispatchers. In well-behaved load balancing, these numbers should be very similar for all server nodes.

3.6.4 Single Activity Trace SAP NetWeaver Portal offers a drilldown of the activities of a single user. The technology is know as Single Activity Trace (SAT) or user activity trace. Major features of the trace are that activating this detailed trace for one user has hardly any performance impact on other active users and that the trace uses the same (JARM) infrastructure as the portal monitoring iViews explained above. Thus the trace can be activated (without restart) on productive systems without high impact and correlates to the data from the component overview etc.

The trace data is stored in file.../cluster/server/log/sat.trc.0. It can be read in the Log Viewer of the J2EE Engine. The Log Viewer displays the single activity trace formatted: Different colors are used for requests and components, and nesting is indicated by different levels of indentation.

September 2008 56


Creation of the Trace

1. Start the single activity trace in the browser by choosing System Administration - Monitoring - Portal - Activity Tracing for a specific user account that can be used to experience the performance problem.

2. Perform the critical clicks in a browser session that belongs to the traced user.

3. Hint: While creating a trace for a user, write down the activities that the traced user performs. This simplifies analysis of the trace:

- Timestamp of the click

- Rough estimation of the response time for the click

- Screenshot of the resulting browser display

4. Deactivate the single activity trace for that user.

By default the trace is stored in file cluster/servern/log/sat.trc.0. Either use the Log Viewer directly to display the trace or copy the trace file to a different machine (e.g. in case of firewall issues).

Hint: If you did not get a trace file sat.trc.0, this may be because of a common configuration error. Check the configuration change that is recommended in SAP Note 655823.

Understanding the Trace

The different colors serve as high-level structuring of the trace. Red lines indicate requests, which are the most coarse-grained level of the trace. Only the gross elapsed time is reported for a request. There are two different kinds of requests:

- External requests (i.e. HTTP requests from a browser) are given the prefix EP:PRT:. The name is then followed by the name of the root iView contained in the request. External requests and the components called from these requests are processed by Client_Threads.

- An external request may trigger one or more internal child requests, e.g. to render iViews that are part of a page. Internal requests are given the prefix EP:PRT:ASYNC: and processed by threads from the pool PRT-Async. The complete PCD URL (pcd:/portal_content/…) is listed in the request name.

Blue lines denote (JARM) components. The gross time and the net time (net time = gross time – sum (time for sub-components)) are reported for each component. Nesting of components is marked by indentation.

Grey lines indicate action calls in JARM, i.e. these lines provide additional information in the description field (e.g. Java class implementing an iView or an event name) without performing time measurement (gross and net time is always -1).

September 2008 57


3.6.5 Portal Infrastructure Analysis with J2EE Tools

3.6.5.1 J2EE Monitoring

Type of Cluster Node Performance Item Notes

Dispatcher and server Threads->Server threads Server threads are an essential resource with a strong influence on system stability and performance

Dispatcher Connection manipulator TCP connections established to the J2EE Engine dispatcher are counted

Dispatcher and server Memory Total memory consumption in the Java VM.

Server Threads->Client threads

Server HTTP session summary

Server DB Pools

Mapped together give overview of customer request execution environment on the server node

Cluster Heartbeat Checks availability of the cluster

Monitor Pool Sizes

When started in console mode or accessed via telnet, the J2EE Engine a set of console administration commands.

Use the command lp

The command lists the pool sizes for the byte array pools (on dispatcher node only). All kinds of requests are represented in dispatcher memory like byte[]. A lack of objects in the pool could be the reason for slow system performance with a low CPU usage of server nodes, because the dispatcher cannot put enough load on them due to this bottleneck.

Monitor Cluster Communication

In the administration command console of J2EE Engine type

add debug

debugmanager ClusterManager 1

debugmanager ClusterManager 2

This command is available on server and dispatcher nodes. When used with parameter “1”, it prints cluster communication statistics on the dispatcher node. When used with parameter “2”, it resets the cluster statistics counters. The output of the command appears on the console, structured conveniently to allow an immediate overview of the most cluster communicating protocols with information about the number of messages exchanged and sum of bytes sent and received.

September 2008 58


Monitoring the Details of Http Sessions

In the administration command console of the J2EE Engine type

add servlets_jsp

httpsessions

This command is available on server nodes only. Verbose output about all alive http sessions for the concrete server node with the user name, time of creation, and expiration time. It is helpful for debugging the reason for session accumulations detected with Http Session Summary information in the basic monitoring of the J2EE Engine (for example if they do not expire properly).

3.6.6 Java VM Thread Analysis All Java VMs used for SAP NetWeaver Portal provide a built-in mechanism to dump a snapshot of the states of all Java threads. This dump is called full thread dump. For each Java thread, you get the Java thread name, the native thread ID of the OS, and the Java call stack of the thread. Furthermore, information on Java-level deadlocks is displayed, including the stack traces of the involved threads. A great benefit of full thread dumps is that they impose no performance overhead on the system.

3.6.6.1 Benefit from Full Thread Dumps Full thread dumps can be used to analyze several kinds of problems:

Discover deadlocks or starvation situations: Full thread dumps can tell you the reason why the complete J2EE Engine or the portal application (all requests to /irj/servlet) or any component of the portal is no longer responding.

Identify “CPU burner”: You may observe that the Java VM is consuming CPU time (permanently >= 1 processor) although there is no load (incoming http requests) on the portal. To analyze this problem and identify the busy Java thread, you need full thread dumps and supplemental information from the operating system about which thread is consuming CPU time.

Snapshot monitoring during normal operation and during load testing: It is also very valuable to create full thread dumps during normal operation of the portal. The full thread dumps can provide very precise hints about where hotspots and bottlenecks prohibit better performance, especially during periods of higher load on the system. In contrast to other performance analysis tools that plug into the Java VM via the profiling interface (JVMPI), full thread dumps do not have any measurable performance impact on the system. Thread dumps should be supplemented with an overview of CPU-consuming threads (e.g. pslist output) and a thread overview from portal monitoring. Typical problem areas that can be detected with thread dumps are wait situations for an input/output operation (file system access, database access, HTTP access to back ends, waiting JCo calls), lock situations due to serialized coding (synchronized statements in the Java code), and complex Java coding (deeply nested loops, recursion).

Even if there is no direct indication of a lock situation, a full thread dump yields useful insight into the current load of the Java VM. In some respects, the thread overview can be compared to the “work process overview” (Transaction SM50) from the ABAP stack of the SAP Web Application Server.

Unfortunately you do not directly get a tabular overview for all threads in combination with a clear location for each thread. This must be calculated manually. However, for many cases it is sufficient not to calculate exact statistics on how many threads are busy in which module and to just browse over the dump and get an impression of frequently appearing patterns.

September 2008 59


While full thread dumps are a very powerful performance analysis tool, they do not help in the following problem areas:

Response time or CPU time measurements are not possible with full thread dumps: You do not get any information on the processing time. The only way to achieve this with full thread dumps is to create several dumps in short intervals.

All kinds of memory problems: Full thread dumps do not contain any memory information. Memory consumers can only be identified indirectly from the dumps by trying to derive information from the active threads. Without knowing the code being executed it is nearly impossible to guess the memory consumption from the thread dump.

Functional problems and debugging: Unfortunately, full thread dumps contain very little context- and instance-specific information. All kinds of variables and attributes, method parameters, and session information is not available in a full thread dump. Only class-level information (class name, method name, line number in the source file) is provided.

Getting self-contained VM snapshots: Unfortunately, some very useful information is not stored in full thread dumps: For example, a timestamp of dump creation is very useful, and also the CPU occupation at the moment of dump creation would be useful. As a workaround this information can be obtained and recorded with other operating system tools.

CPU usage per thread allows you to identify which threads really require processing and which threads are idle or waiting, without wasting CPU time. Furthermore, portal monitoring may deliver additional information via the Thread Overview and the Component Overview. Also, the exact timestamp of creating dumps should be recorded to allow matching of the dump, e.g., with entries in the portal log files.

To identify which threads actually consume CPU time and which are just blocked / waiting, it is important to know which Java threads inside the Java VM actually consume CPU time. This is fundamental if the Java VM is consuming CPU time although there is no load on the system. The commands to obtain this information are specific to the underlying operating system.

3.6.7 Java VM Analysis There are two groups of performance problems related to Java VM memory. First, garbage collection may consume too much time, not leaving enough room for processing the user workload. Secondly, high workload may also result in OutOfMemory errors, which put the Java VM into an undefined state. Before trying to analyze the memory behavior, make sure that the latest recommendations for the Java VM parameters are implemented as recommended in SAP Note 723909

3.6.7.1 Memory Model To analyze performance problems related to the memory of the Java VM, it is necessary to have a high level of understanding of the Java memory model. The complete user address space of the Java VM is called heap and it is divided into three major parts. Depending on the size and lifetime of a Java object, an object can be relocated inside these memory areas by the JVM. If the total heap fills up and cannot be extended, you will get an OutOfMemory error.

September 2008 60


Figure 3-29 : Memory Model

Newly created Java objects are put in the Eden area. If this area fills up, a (minor) garbage collection (GC) is triggered by the VM to remove obsolete objects and to clear the Eden space. During a minor garbage collection the VM analyzes the Eden space and first removes all objects that are no longer referenced by the applications. The JVM then moves all objects that are still alive from Eden to one of the survivor spaces. Finally, the JVM analyzes the survivor spaces. Objects that are no longer referenced are removed from the survivor spaces, and objects that have survived a certain number of GC cycles in the survivor spaces as well as objects that do not fit this area because of their size are moved to the old generation space. After each minor GC, one of the survivor spaces and the Eden area do not normally contain any Java objects.

If the old space fills up (or if some other precondition applies), a full garbage collection is started by the VM. In this case the complete heap is analyzed, i.e. the VM also scans the complete old generation for garbage. Because of the larger amount of memory to be scanned, a full GC normally lasts substantially longer than a minor GC.

Both types of garbage collection are run synchronously: All other activities in the Java VM are stopped for the garbage collection that is if a full garbage collection runs for 60 seconds, the portal node will not respond to requests and appear “frozen” for 60 seconds! This behavior is sometimes called a “stop the world” garbage collection.

As entry point for the analysis of the memory situation you need two important values:

The total memory that is still available for the portal within the Java heap. This is calculated as the difference between the maximum heap size and the amount of memory currently used. In more detail, the Eden space and the survivor space of the heap are not permanently available for the Java application. The memory available for the Java application is calculated as follows:

Memory available = Size of old generation + size of one survivor space – memory used

The Eden space is not considered as permanently available since the JVM cleans the Eden space during each garbage collection (minor and full). Long-lived objects, i.e. objects that are

September 2008 61


still alive at least after one GC, are always moved to the old generation area sooner or later. For this reason, a Java application can only use the Eden space as a temporary container for newly created objects.

The time spent for garbage collection activities. Since garbage collection stops all portal activities, only the remaining time (elapsed time – GC time) is available for portal operation.

Both values can be obtained from the verbose:gc trace. Memory usage is reported also by J2EE monitoring.

3.6.7.2 Understanding an OutOfMemory Error If the situation is characterized by “Out of Memory” problem, you are probably looking for a memory leak. From the memory analysis template, extract the following information:

Is it an accumulative memory leak? What is the accumulation step in Mbs?

If the GC activities trace of JVM monitoring indicates that the basic heap get bigger and bigger after each GC, then it is a suspected memory leak situation. The accumulation step is calculated as a subtraction of the basic heap before and after each GC activation, but just in case if there are not an increased number of users on the system. To find this out check the http sessions summary data for the number of http sessions and number of active users in Portal basic monitoring setup. Map the number of http sessions to the memory monitoring in the J2EE Engine by the timestamps.

Is the memory problem a function of time and how much is that time?

Check the memory statistics of J2EE Engine monitoring to get the heap size value and timestamp for the occurrence. From the J2EE monitoring one cannot see exactly how big the heap was before the Out Of Memory crash, and the moment of crash is visible in the console logs of engine.

Does memory accumulation start at the beginning of the load, or after some time, or at some specific event?

In the J2EE Engine monitoring, check the memory statistics as well as the number of running threads, request queue sizes, database pools, waiting queues, number of http sessions, number of http connections at the moment when the memory started to increase. It is possible that slow backend replies block the client processing threads, and as a result lots of incoming requests that also could be huge byte arrays fill the request queue.

Is the problem on all server nodes in the cluster? Is it specific for a concrete server node?

Compare the GC activities traces to see if the other portals JVMs are also subject to increasing memory, at the same or a different rate, and if the same number of users (Portal basic monitoring) is running on those servers.

Is performance degradation related to deployment of new customer content on the system?

Check the memory which the server node occupies at start up. If it is more than 300 Mb, ask a system administrator or check how many and what kind of applications are deployed on the system lately. If more initialization memory is used for simply starting applications, then fewer users will be able to process with the rest of the JAVA heap. If the same number of users is still expected to load the node, then the more intensive GCs are probably the reason for performance degradation.

September 2008 62


Determine how many users could be processed with this memory?

With J2EE Engine monitoring, determine the last stable ratio of users – memory for this server node.

Did some portal cache structures grow too much?

Check the report for cache sizes in the Basic Portal monitoring setup.

At what point does the memory accumulation result in performance degradation?

Determine how the memory problem influences the response times. To do so use the GC activity trace and http service INFO log. Select a URL calling an iView of your choice and see if and how the response times for this specific URL increase. Do they increase in parallel to increasing memory and at what memory level do they start growing?

3.6.8 HTTP Request Analysis A trace of the HTTP protocol stream provides insight into the details of communications between the client (browser) and portal server (and also other HTTP servers). It delivers an overall view of the client activities, including access to static content and other Web servers. This is a more complete view than we got during the Portal Workload Analysis. On the other hand, a single HTTP request (consisting for example of a page with many iViews) cannot be drilled down further than it was with the Single Activity Trace. The two approaches Portal Workload Analysis and HTTP Analysis can therefore be considered as complementary.

3.6.8.1 Basics of HTTP Protocol Analysis The observed end-user response time is caused by several factors, as depicted in the diagram below: Network delay and client-side rendering time are added to the server processing time, and the total of these times are the end-user response time. Client rendering time is not covered here.

The HTTP protocol stream can be traced at three different locations, as shown in the diagram: directly on the client as a plug-in to the Internet Explorer, somewhere on the network via a tracing HTTP proxy, or directly on the server. Each location has advantages and disadvantages:

The server-side HTTP trace gives an overall impression of all HTTP requests from all users. To activate the trace, you need system access, restart the server, and there may be a minimum performance impact due to the trace. Since it would be too expensive to capture the complete stream, only summary data e.g., URL, response time, size etc. is traced.

The proxy-based HTTP trace is normally restricted to a single user and therefore has no performance impact on the server. Only normal end-user access is needed. It is not a performance problem to capture the complete HTTP stream, including all headers and bodies. However, putting a proxy between browser and server for tracing may change communication details of the HTTP protocol (e.g. keep-alive), such that you do not necessarily get the original behavior. Another advantage is that the proxy can be put on any machine in the network, including server and client machine. In this way you can decide if you want to include network delay in your measurements.

The client-side HTTP trace has almost the same advantages as the proxy-based trace. An additional advantage is that a browser plug-in can also capture HTTP requests that are directly handled by the browser cache. These requests are not visible via a proxy. Disadvantages of the browser plug-in are that an additional installation step is necessary, that there is no flexibility for choosing the location where to trace, and that no free tools are currently available.

September 2008 63


Figure 3-30 : HTTP Protocol Analysis

3.6.8.2 HTTP Status Code Each HTTP response contains a 3-digit status code that describes the result of a request. 2xx status codes indicate that the client’s request was successfully received, understood and accepted. 3xx status codes indicate that the client’s request is redirected to a different URI. 4xx status codes indicate a client error and 5xx status codes indicate a server error.

The most important status codes are:

200 OK The request has succeeded

302 Found The requested resource has been found under a different URI. This will result in a follow-up request of the browser to the new URL. For high-latency networks, it is important to keep the number of these redirects at a minimum, since it incurs extra requests, and – even worse – closes down and re-opens the HTTP connection.

304 Not Modified The server states that the requested resource has not been modified since the last request. If you observe many of these requests, investigate browser cache configuration / behavior. The browser should only check at most once per session if a document was modified.

401 Unauthorized Authentication is required for the URL. This status code triggers authentication in the browser (basic or NTLM) and may occur once (Basic) or three times (NTLM) during login. After that, it should not occur again.

404 Not Found The most frequent error, indicating that the URL path of the request is not valid. Must be resolved even if there’s no functional problem visible in the browser. Since there is no negative cache to remember which documents are missing, missing documents are requested repeatedly by the browser.

In general, all status codes 4xx and 5xx should be investigated. Also, 3xx should get some attention.

September 2008 64


September 2008 65

4. Further Information

4.1 Web Infrastructures and Architecture

Link to URL

Amazon http://www.amazon.de/Building-Infrastructures-NetWeaver-Application-Server/dp/1592291619/ref=sr_1_2?ie=UTF8&s=books-intl-de&qid=1210936392&sr=8-2

Galileo http://www.sap-hefte.de/katalog/hefte/titel/gp/titelID-1588

SAP Press http://www.sap-press.com/product.cfm?account=&product=H2911

4.2 Federated Portal Network

Link to URL

SDN https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/3018eac9-6b90-2a10-019d-be96b4139fee

SDN https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/a03376e4-9da4-2a10-158c-e29acba3ed63

SDN https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/703cfbbd-e85e-2a10-00a3-ecd502c08e82

SDN https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/80891da2-6c90-2a10-8d89-e7b36c9b6a8f

SDN https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/b08d3aef-1ac1-2a10-abb0-c4e1c4be5e30

SDN https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/20381950-f8c0-2a10-54ae-ab9861ddb370

4.3 External Facing Portal

Link to URL

SDN https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/5fac3df3-0901-0010-42b1-cce17c4b484c

SDN https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/60fd3fc2-e0a4-2910-80bc-a45987574922

SDN https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/30eb732a-2448-2a10-7aa6-8fd0849b6f20

http://www.amazon.de/Building-Infrastructures-NetWeaver-Application-Server/dp/1592291619/ref=sr_1_2?ie=UTF8&s=books-intl-de&qid=1210936392&sr=8-2



http://www.sap-hefte.de/katalog/hefte/titel/gp/titelID-1588

http://www.sap-press.com/product.cfm?account=&product=H2911

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/3018eac9-6b90-2a10-019d-be96b4139fee

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/3018eac9-6b90-2a10-019d-be96b4139fee

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/a03376e4-9da4-2a10-158c-e29acba3ed63

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/a03376e4-9da4-2a10-158c-e29acba3ed63

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/703cfbbd-e85e-2a10-00a3-ecd502c08e82

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/703cfbbd-e85e-2a10-00a3-ecd502c08e82

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/80891da2-6c90-2a10-8d89-e7b36c9b6a8f

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/80891da2-6c90-2a10-8d89-e7b36c9b6a8f

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/b08d3aef-1ac1-2a10-abb0-c4e1c4be5e30

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/b08d3aef-1ac1-2a10-abb0-c4e1c4be5e30

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/20381950-f8c0-2a10-54ae-ab9861ddb370

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/20381950-f8c0-2a10-54ae-ab9861ddb370

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/5fac3df3-0901-0010-42b1-cce17c4b484c

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/5fac3df3-0901-0010-42b1-cce17c4b484c

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/60fd3fc2-e0a4-2910-80bc-a45987574922

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/60fd3fc2-e0a4-2910-80bc-a45987574922

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/30eb732a-2448-2a10-7aa6-8fd0849b6f20

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/30eb732a-2448-2a10-7aa6-8fd0849b6f20


September 2008 66

SAP Notes SAP Note 877188 and SAP Note 853509

Help Portal SAP NetWeaver 7.0: SAP NetWeaver Library - IT Scenarios at a Glance - Running an Enterprise Portal - Implementing an External-Facing Portal

SAP NetWeaver 2004: SAP NetWeaver Library - SAP NetWeaver - People Integration - Portal - Special Topics - Implementing an External-Facing Portal

4.4 User Management and Security

Link to URL

SDN https://www.sdn.sap.com/irj/sdn/security?rid=/webcontent/uuid/0d908ddd-0901-0010-c8b1-a2eac60954b3

SDN https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f0ad23d3-3664-2a10-8aa7-e9c3c8616d48

SDN https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/409ba431-7eaa-2a10-f490-97624f76543e

SDN https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/7037d982-40aa-2a10-e283-a76a9dfc93ab

SDN https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/706065c4-3564-2a10-2382-a52fcbd7eefb

4.5 Performance and Monitoring

Link to URL

SDN https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f08287c4-a4ee-2a10-b0a2-c863755fdb94

SDN https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/b08443bc-75fd-2a10-3da0-8ef1d4f7c622

SAP Service Market Place

For general information, access the following quicklinks on SAP Service Marketplace: /sizing, /benchmark and /performance

4.6 Sizing

Link to URL

SAP Service Market Place http://service.sap.com/quicksizer

SAP Service http://service.sap.com/sizing

https://www.sdn.sap.com/irj/sdn/security?rid=/webcontent/uuid/0d908ddd-0901-0010-c8b1-a2eac60954b3

https://www.sdn.sap.com/irj/sdn/security?rid=/webcontent/uuid/0d908ddd-0901-0010-c8b1-a2eac60954b3

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f0ad23d3-3664-2a10-8aa7-e9c3c8616d48

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f0ad23d3-3664-2a10-8aa7-e9c3c8616d48

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/409ba431-7eaa-2a10-f490-97624f76543e

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/409ba431-7eaa-2a10-f490-97624f76543e

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/7037d982-40aa-2a10-e283-a76a9dfc93ab

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/7037d982-40aa-2a10-e283-a76a9dfc93ab

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/706065c4-3564-2a10-2382-a52fcbd7eefb

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/706065c4-3564-2a10-2382-a52fcbd7eefb

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f08287c4-a4ee-2a10-b0a2-c863755fdb94


https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/b08443bc-75fd-2a10-3da0-8ef1d4f7c622

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/b08443bc-75fd-2a10-3da0-8ef1d4f7c622

http://service.sap.com/quicksizer

http://service.sap.com/sizing


September 2008 67

Market Place


Sizing Guide for NetWeaver Portal can be found on SAP Service Marketplace under Hardware Sizing -> Sizing Guidelines -> Solutions & Platform -> “Sizing SAP NetWeaver Portal”.

4.7 Development Infrastructure Link to URL

SDN https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/b0ebf83b-6201-2b10-b58b-c14d3d3b6f61

SDN https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/e0249083-c0ab-2a10-78b8-b7a7854b1070

SDN https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/10456aac-44f7-2a10-1fbe-8b7bcd7bcd58

4.8 Accelerated Application Delivery (AccAD) Link to URL

SDN https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f08287c4-a4ee-2a10-b0a2-c863755fdb94

SDN http://sdn.sap.com/irj/sdn/nw-accad

Service Market Place

https://service.sap.com/rkt-netweaver - Go to Accelerated Application Delivery 2.1 for SAP NetWeaver

Service Market Place

You can find the download of the software as well as the documentation in http://service.sap.com/swdc - Download - Installations and Upgrades - Entry by Application Group - SAP Development Projects - ACCEL. AD FOR SAP NETWEAVER - AAD 2.1 for SAP NetWeaver.

4.9 Product Availability Matrix (PAM) Link to URL

SDN https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/30179afb-d90e-2b10-ceb3-d2e441d6407b


https://websmp105.sap-ag.de/pam

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/b0ebf83b-6201-2b10-b58b-c14d3d3b6f61

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/b0ebf83b-6201-2b10-b58b-c14d3d3b6f61

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/e0249083-c0ab-2a10-78b8-b7a7854b1070

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/e0249083-c0ab-2a10-78b8-b7a7854b1070

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/10456aac-44f7-2a10-1fbe-8b7bcd7bcd58

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/10456aac-44f7-2a10-1fbe-8b7bcd7bcd58



http://sdn.sap.com/irj/sdn/nw-accad

https://service.sap.com/rkt-netweaver

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/30179afb-d90e-2b10-ceb3-d2e441d6407b

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/30179afb-d90e-2b10-ceb3-d2e441d6407b

https://websmp105.sap-ag.de/pam

www.sdn.sap.com/irj/sdn/howtoguides