Está en la página 1de 74

Portal Purpose

This chapter provides a starting point for managing your mySAP components and keeping them up and running optimally. It contains specific information for various tasks, and lists the tools that you can use to carry them out. It also refers to documentation required for these tasks. You can use this guide only in connection with other guides such as the Master Guide, Technical Infrastructure Guide, Solution Management Guide for mySAP Solutions and the SAP Library. This guide does not replace the daily operations handbook that we recommend customers to create for their specific productive operations.

Target Groups
Technical consultants System administrators Solution Consultants Business Process Owner Support Specialist

Important SAP Notes


Check regularly, which SAP Notes are available for the Technical Operations Manual. You can find important SAP Notes in the Portal under System Administration Support Support Desk. For every listed topic you are provided the central SAP Note.

Monitoring
Purpose
Different components, applications and services are shipped with the portal. There are various monitoring and log applications available for monitoring these objects. These applications check and monitor the portal in the background. Applications such as performance monitoring and activity tracing provide information about the status and help locate critical system events. Using the information obtained through monitoring, logging and tracing, you can analyze the system and initiate any necessary measures. For more information see the Portal Administration Guide under Monitoring Technology and Logging.

Process Flow CCMS Monitoring


Proactive, automatic monitoring is the basis for the reliable operation of your SAP system environment. SAP provides you with the infrastructure and recommendations for defining alert monitoring in order to detect critical states in the portal platform as fast as possible. The following features for monitoring the portal platform are provided in the CCMS by Transaction RZ20:
Function Description

Monitoring system

of

the

operating

The virtual store, physical store, CPU, file system management, physical hard disk, and network can be monitored. You can display the performance data of the portal server. Each CCMS agent can analyze log files for a given text pattern and pass the results to the monitoring architecture as an alert of a given severity. You can monitor processes. the availability of any

Monitoring of the performance Monitoring of log files with CCMS agents

Monitoring of selected processes with SAPOSCOL Heartbeats

You can display the availability of portal backend systems, portal servers or cluster nodes, and URL connections. You can display configuration parameters and the status.

Reporting of configuration parameters of the Portal Runtime and Portal Content Directory

For detailed information about the implementation and configuration of SAP Enterprise Portal Monitoring in the CCMS see Configuration of the Monitoring Architecture.

Monitoring with the SAP Solution Manager


If the corresponding prerequisites are satisfied, you can monitor parts of the portal platform with the SAP Solution Manager. For more information see the Portal Administration Guide under Monitoring with the SAP Solution Manager.

Performance Monitoring
The performance monitoring functions give you an overview of the current system and application-specific data of the running portal on a Java Virtual Machine. With this partially computed data you can identify areas that cause performance problems. The performance monitoring functions handle all requests of the portal server that are instrumented. You can access the following performance monitoring functions in portal navigation with System Administration Monitoring Portal:
Function Description

Request Summary Request Overview Component Overview Thread Overview

Contains the most important performance data for a portal server, accumulated according to different categories. Contains an overview of the requests that have the greatest effect on performance. Contains an overview of the individual components that have the greatest effect on performance. Contains a snapshot of the threads currently being used. Performance

For more information see the Portal Administration Guide under Monitoring.

User Overview
The user overview service gives you a list of the logon and logoff data. For more information see the Portal Administration Guide under User Overview.

Activity Tracing
You can sequentially record the activities of individual users for a defined time span and then analyze these activities in the Log Viewer. For more information see the Portal Administration Guide under Activity Tracing.

Parameter Reporting
You can display the configuration parameters of the Portal Runtime (PRT) and the Portal Content Directory (PCD). You can also check if all the necessary services and filters have been loaded. You can call the function in the Visual Administrator, CCMS or Portal. For more information see the Portal Administration Guide under Parameter Reporting.

Portal Activity Report


With this function you can create the statistics about user activities (what content they are using iViews or pages).

For more information see the Portal Administration Guide under Report.

Portal Activity

Logging
The following tools are available:
Tool Description

Log Viewer

With the Log Viewer you can view and analyze all the log data of the portal, the data from activity tracing, and the log data of the J2EE Servers from one central location. For more information see the Portal Administration Guide under Viewer. Log

J2EE Standard Logging

Portal logging is performed in the central standard logging system of the J2EE Engine, consisting of the Log Manager, Log Configurator Service and Log Viewer. For more information see the Portal Administration Guide under Logging.

CCMS Agent

See the section about CCMS monitoring above.

Management Purpose
Management of the portal platform is divided into: Administration Tools Starting and Stopping

Backup/Restore and Recovery Logon and Load Balancing User Management

Administration Tools
The main topics for administration of the portal platform include system landscape, creating and managing portal content, assembling a portal page, working with roles, navigation, and user management, as well as performing branding and design changes. To facilitate the administration tasks, these tools are assigned to different with the portal: Role Super Administration Administration Task Set up at least the minimal management configuration. user Description See Configuration of User Management in the Enterprise Portal. See See Delegated Administration. Security Zones. pre-configured roles shipped

Assign users to administration roles, distribute administrative responsibilities. Assign default permissions to the Security Zone folder in the Portal Catalog. Distribute the initial content shipped with the portal. User Administration Content Administration Includes all tasks relevant to management and role assignments. user

See Standard Portal Content and Default Permissions. See User Management in this guide. Portal content consists primarily of iViews, which are generally displayed through portal pages. Worksets bundle related pages, iViews, and roles. Business packages are generally groups of related worksets. See also iViews, Portal Pages, Roles and Worksets and Business Package Administration.

Create and maintain portal objects and components that directly provide information to portal end users.

System Administration

Export and import content objects. Upload content and actions. Monitor. Define portal user access rights to portal objects in the Portal Content Directory (PCD). Configure the lock mechanism for PDC objects. Create and edit systems, and maintain the system alias. Configure portal services using the Service Configuration Editor. Create and manage portal desktops to suit your business scenario. Configure DQE performance properties, control DQE sessions, and preload system

See See

Transport of Content Objects. Content/Action XML Uploader.

See Monitoring in this guide. See Permission Editor.

See See See See See

Object Locking. System Landscape. Service Configuration. Portal Display. Distributed Query Engine (DQE).

metadata to improve runtime performance. Access various support tools that help you with troubleshooting in the portal. See Troubleshooting and Support Desk.

Clearing the Portal Runtime Cache


Use
At runtime, you can view the portal objects that are in the cache in order to monitor runtime objects. By doing so, you can detect which ones need fine-tuning for improved response time and performance. The cache mechanism uses the memory (RAM) and the database for the portal. Inconsistencies can occur between the cached objects in the memory and the cached objects in the database. You can detect this condition only by viewing the cached contents. You resolve these inconsistencies by deleting the portal runtime cache in the database. This operation clears both the cached objects in the memory and the database.

Procedure
To delete PRT cache table: 1. In the browser, enter the following URL:
http://<portalhostserver>:port/irj/servlet/prt/portal/prtroot/com.sap.por tal.prt.cache.PRTRegionDBClear

2. At the prompt, logon to the portal.


Make sure that you receive a notification about clearing the cached content.

3. Restart the J2EE Engine.

Starting and Stopping


This section describes the sequence in which you stop and start the components in the portal landscape. The explanation includes components of the portal: Unification, and Connector Framework, and other SAP NetWeaver components, such as Knowledge Management and Collaboration. In a secure and highly available production environment, other third party tools, such as a proxy server, also play a role in the portal environment.

Purpose
Use the information in this section to stop and start portal processes in your system landscape: in which all the components of the portal reside on a single machine, or in a production environment within which the portal has been clustered and made highly available.

Prerequisites
The portal works with the following systems:
A relational database management system (RDBMS) An existing users-related storage mechanism, Users Persistence Storage, such as a directory service (LDAP). These systems are prepared before the portal is installed. SAP Web Application Server

Before you stop or start components in the portal landscape, make sure that:
The portal runs without any issues You have administration rights and privileges to start and stop the processes of the components of the portal

Workflow: Stopping Environment

and

Starting

Components

in

the

Portal

There are occasions when you may need to shut down the portal environment, for example, to perform system maintenance such as offline backup and so on.

Stop Sequence
To shut down the portal environment, you must stop the processes of the various portal components. The following is the sequence for stopping the components in the portal landscape: 1. J2EE instances of the SAP Web Application Server 2. Database 3. User Persistence Store

Search and Classification (TREX) Start Sequence


Start the 1. 2. 3. 4. following components in the numbered sequence: Search and Classification (TREX) User Persistence Store Database J2EE instances of the SAP Web Application Server

Starting and Stopping the Web Server


A Web server deployed in the portal environment as a proxy server is the first component to be stopped, and the last to be started. Always start the Web server service, such as the IIS Admin Service.

Starting and Stopping J2EE Engine


The portal is installed on an instance of the J2EE Engine of the SAP Web Application Server, as such, starting and stopping the J2EE instances affect portal functionality. SAP Web Application Server provides tools for starting and stopping its cluster elements. Detailed information about starting and stopping J2EE instances, refer to Starting and Stopping the SAP System.

Starting and Stopping J2EE Instances with the J2EE Startup and Control Framework
For more information about the J2EE startup framework, refer to Java Startup and Control Framework.

Backup/Restore and Recovery


Backup refers to the activity of copying files, data, or network volume, with the intention of preserving them for later use in case of hardware failure, or other disaster. When you retrieve files that have been backed up earlier, you are restoring them. Backup and restore strategies relate to specific backup and restore solutions offered by specific vendors, therefore detailed information on various backup strategies is not discussed in this guide.

Purpose
The many reasons for backing up data include hard drives crashing, viruses infecting your system and destroying your data, human error wreaking havoc on your business, or a stolen system with your data on

it. It is important to implement a backup-and-restore strategy that protects your system against data loss, and enables you to restore the system to its correct and consistent state. The most important part of any security strategy is to backup the system at regular intervals. This means the system (files, databases, etc.) must be copied to another storage medium. When the system is damaged, the stored duplicate can be re-loaded to restore it.

Prerequisites
Backup effectively contributes to safeguarding your system if it is performed as part of an overall backupand-restore strategy. It is therefore important to carefully plan, prepare, and test the backup-and-restore system before applying it in a productive system. In planning for backup and restore, define details for performing backups: What should be backed up When should backup occur Which media to use

How to verify backups, to make sure that you have meaningful stored duplicate data that can help you to restore your systems later. In addition, when planning your strategy, you need to take into account the following: Transaction workload Maximum permissible downtime Available hardware Amount of tolerable data loss

Backup Processes
Online and Offline Backups
Online backup takes place during system operations (while various components and services are running). Files that are opened are not backed up during online backup of databases and file systems. You may choose to employ additional software to complement the online backup. Offline backup is performed after system operations have been stopped, and a snapshot of the system's state at a point in time is mirrored onto a media. The advantage of offline backup is your ability to preserve the consistent state of the backed up system, and then to restore the system to the same state. Online and offline backups each have advantages and disadvantages. Therefore a good backup strategy must include both online and offline backup to enable 24 x 7 support for restore or recovery if needed.

Media Rotation Methods


Media rotation is the use of multiple media devices to perform backup. There are different rotation schemes suitable for different systems. Backup strategies using media rotation differ mostly by the number of media required and the scheduled retention period for each media. Two common media rotation methods are:
Full Backup: Full backup refers to the activity of backing up everything on your system. This backup method must be performed regularly, at least once a week, depending on your work volume. The advantage of full backup is that files are easy to find, and you do not have to search through several media for requested files. In addition, it provides the most current backup of your entire system, and easier to restore. The disadvantage is redundancy, since most of the files on your file server rarely change. In addition, each full backup includes a copy of what has already been backed up.

Also, full backup requires more media, and takes longer to perform. Since it affects the speed of your system, you should perform this backup at a time when the workload is low. Modified Backup: Modified backup can be either incremental or differential. Incremental backup is backing up only new files created, or those that have changed since the last backup was performed. To restore a system from an incremental backup, you need the last full backup and each incremental backup performed. Advantages of incremental backup include better usage of media and less time required for backup. The main disadvantage is that backups are spread across multiple media. Differential backup is similar to incremental backup in that it copies new files created, or those that have changed since the last backup. However, to restore a system from a differential backup, you need the full backup and the last differential backup performed. Some of the advantages of differential backup are that it takes less time, fewer media devices are used, and the level and risk of media errors are minimal for backup and restore.

The following are some of the possible backup strategies you can combine:
Son: - The son involves doing a full backup every day. Father and Son: - The father and son combination involves both full and differential, or incremental backup scheduled fortnightly. Grandfather: - The grandfather scheme uses several media devices over a period of time:

a. Four media devices are used from Monday - Thursday for incremental or differential backup. b. A set of three media devices is used every Friday for full backup. c. 12 media devices are used for monthly full backups and are kept off-site. Before implementing a backup strategy, you need to decide whether you want to perform only full backup, or use a strategy that includes full backup and one of the modified types (differential or incremental). There are advantages and disadvantages to each backup type.

Backup Strategy
An effective planning strategy that provides adequate insurance against data loss is always based on appropriate hardware and system configuration, and describes a backup cycle of one month. The backup plan usually identifies the following: Parts/area (drives, directories, files) of the system to backup Suitable type of backup, see Backup Processes Recovery mode to set for the SAP system and databases The frequency with which you perform backups Appointed times for performing backups Type of storage media (devices) for backup Backup management, and maintenance issues How to monitor and verify backups

You implement a backup strategy using the operating system as a basis.

Windows
On Windows, the following components should be considered when defining a backup strategy: J2EE Engine Web Server Windows NT/2000 services Windows NT/2000 applications Database shared by the SAP Web Application Server and the portal

User Persistence Store

UNIX Platform
On UNIX, the following critical components should be considered when defining a backup strategy: J2EE Engine Web Server UNIX services UNIX applications Database shared by the SAP Web Application Server and the portal User Persistence Store

Portal Backup and Restore Strategy


Carefully develop your backup-and-restore strategy for the portal infrastructure in order to achieve a consistent state upon recovery. The strategy may involve backup at the component level, or a full backup of the entire system. The portal infrastructures differ for customers; therefore performing a full backup is a comprehensible solution. This solution can easily restore portal components and enable the portal to recover from a complete system loss. In addition, portal components and their configurations are interdependent, and need to be backed up together.

Application Data (Business Information)


All operations of the portal that use some type of storage for saving business information must be considered for backup. The backup type to be defined for individual components depends on the type of data storage. Data, or information stored in different storage types can be regenerated by the component itself. Therefore, for components that use only database-like storage, database backup is sufficient, but in some system landscapes, a component can use multiple storage types for storing business information. To address all possible problems, sources of the problem must be identified. In most cases, backing up just the database shared by the portal and SAP Web Application Server is sufficient. See Backup and Recovery of the SAP Web Application Server (Java) for detailed information about online backup and restore of the database for the portal.

Software and Configuration Data


The system and application software are worth backing up to prevent re-installation in case all, or a part of the software is destroyed. As re-installation is always possible, backup is not mandatory. Backing up the application at least once after it has been installed or after it has been upgraded is recommended. Note that restoring a backup of the system or application is only possible if it is restored to exactly the same hardware. Installing the software often takes time and requires different configurations and customization, thus saving this kind of information may be important to provide a fast restore and to avoid time and effort after possible failures. As configurations may change more often than the application itself, the configuration files must be backed up on a regular basis, or each time the configuration is modified.

Instead of identifying all relevant files, and configuration entries, a full system backup will probably be the easiest option for backing up software and configuration data.

The following should be considered when planning a backup-and-restore for the portal, and its configuration files:
Operating system Relational Database Management System (RDBMS) software J2EE Engine Web server Other SAP software and file systems Log files (SAP and other) Other system components

Provide a backup procedure for SAP Enterprise Portal and its configuration data, such as, providing the specific folders for the J2EE Engine (specified during EP installation), and other components. In some cases, you must exercise caution, as most configuration data for components in the portal are stored in databases. Such data can be stored in the file system, too. Providing a consistent backup of configuration data in such cases is only possible using off-line mode. Also, note that most components of the portal can regenerate the configuration data again on loading, but special attention must be given to the J2EE Engine.

Identifying Critical Components


Identifying the critical components in a backup strategy also depends on the configuration of the deployed portal. Furthermore, knowing the critical components of the portal can be helpful in the implementation of an appropriate backup strategy. Such strategy must consider the following:
The backup method to implement, and the scheduled interval for performing backup of the component. The restoration cost and time of the component.

Knowing the portal components is helpful in planning your backup strategy. The following are the critical components for the portal.
Components J2EE Engine Cluster Portal Framework iView Runtime Java (IRJ) application Database Description

The Portal Runtime runs on top of the J2EE Engine of the SAP Web Application Server.
The Portal Framework is a logical environment comprised of a collection of software applications for running and managing the portal. The iView runtime application is a runtime environment for processing iViews.

This is a relational database management system (RDBMS) shared by the portal and SAP Web Application Server.
The database is usually on a separate machine. It stores data for the Portal Content Directory (PCD), which is based on the database repository. The database stores runtime objects, including role definitions, page-torole relationships, deployable (PARs), and iView templates, together with their personalization data and derivations.

User Persistence Store

Refers to user related data stored in one or more repositories. Such user related data repositories might be a database, Lightweight Directory Access Protocol (LDAP) directory server, or SAP R/3 System.

As the portal interrelates with other components, these must be backed up too. They can include:
Web servers User Persistence Store Java applications and their configuration files Native applications and their configuration files Relational Database Management System (RDBMS) and their data

Relational Database Management System (RDBMS) and their data


The portal related data on a database makes the specific database a critical component. A customer cannot afford to lose any of the user specific data or configuration data stored in a database.

Applications and their Configuration


Depending on the layout of the portal, and the effort that goes into restoring an application, it can be categorized as a critical component.

Portal Components
The portal does not include utilities for performing backup and restore, however, the system administrator can use third-party backup and restore tools. Within SAP environment, there are existing tools, and a backup and restore strategy that can be used for some specific components. Such backup can also be used to create a fully functional duplicate of the server at a point-in-time. A successful backup strategy for the portal requires an understanding of how the portal is organized and configured for the specific customer. The portal runs on the SAP Web Application Server, which implements the J2EE Engine based on the Java 2 Enterprise Edition (J2EE) standards. Generally, the out-of-the-box portal consists of the following components: Built on top of the Portal Runtime, the portal components include Portal Content Directory (PCD), database (repository database) Unification components

Connectors Framework may include deployed adapters that provide connectivity between an Enterprise Information System (EIS), the J2EE Engine, and a specific enterprise application. In addition, take note of other SAP NetWeaver components that have been integrated into the portal, such as Knowledge Management, which includes Content Management, and Search and Classification (TREX) components. For more information about TREX backup and restore, see SAP Note 697949, TREX 6.1: Solution Management / Monitoring TREX.

Portal Framework
Portal Framework is a logical environment, holding a collection of various software components for running and managing the portal. For instance, among the collection are portal objects that create pages and their defined layouts, manage styles and themes, and provide access to the resources needed at runtime. Elements used by the runtime components are in the Portal Content Directory (PCD), and these are cached. In this way, the portal runtime can gather information from the PCD cache, and obtain the list of iViews related to each page. Data used by portal and the Portal Content Directory (PCD) is stored in Database.

Documenting your work while implementing a backup for the first time is always recommended.

Software Backup
The most comprehensive solution is to implement a full system backup after installation, and configuration. Re-installing the portal is always an option too.

Data Backup
All application and configuration data for the portal can be backed up using a standard backup and restore procedure.

Restoring
A successful backup is good to have; however, a successful restore is the key. Restoring a system from an online backup can present problems; therefore, restoring a system based on an online backup must be followed by verification tests.

What Can Be Restored?


The answer to this question lies in the type of backup implemented. Since there are no system-wide checks, data losses must be taken into account, especially when restoring databases. Consider a situation where a database holding the archive database has to be restored after a crash. For databases, the databases built-in point-in-time recovery and log recovery can be used. The mechanism allows an almost consistent recovery of the data close to the time of crash. Databases usually store configuration data for some of the components as well. The applications that store their configuration data in the database would be safe. In addition, these same components store their configuration data on the local file system, so the files would have to be restored to the same point in time, to be consistent. This is not possible using file system backup, and inconsistencies have to be expected. In such situations, you have to weigh the losses. In scenario 1, a point in time recovery of the archive database has been implemented. All the other components will keep running. Data loss is then restricted to the archive database only, but the impact of the data loss may be severe. Scenario 2 shows the complete consistent recovery. All components are affected by the data loss, which might be more severe than in scenario 1. Scenario 3 shows the situation where a point in time of all affected components was possible. This will be difficult to achieve since some components have been backed up via file system backups. So probably, scenario 3 will not happen for products landscapes. The main issue for database recoveries in the future will be the restoration of other dynamic data not stored in a database like the LDAP directory information. That is, some components also hold dynamic configuration data, which should be restored as close as possible to the point in time of the crash. However, since that data does

not change, frequent partial offline backup or online backup is sufficient to get a near consistent state. Complete tests have not been done, and some of the issues are likely to change upon testing.

Post - Recovery Checks


After successfully implementing a restore, you must verify whether the restored component works as expected. Use the following guidelines to check the restored components: Can the component be started properly? You can check if the component is working properly by monitoring the corresponding components operating system (OS) processes using the operating systems built-in tools, or a professional monitoring tool, or by checking the log files. Does the restored and restarted component work properly in the product?

Logon and Load Balancing Initial Logon and Default Users


Information about using the default user logon, and logging on to the portal for the first time is available in the section Logging On to / Off the Portal in the Portal Administration Guide.

Load Balancing
For information on hardware and software load-balancing solutions in the portal, refer to the guide, SAPEnterprise Portal 6.0 on WebAS 6.40 Technical Infrastructure Guide in the SAP Service Marketplace at: service.sap.com/instguidesNW04.

User Management Purpose


The User Management Engine (UME) used by the portal platform runs as a service in the J2EE Engine of the SAP Web AS Java and is defined as the default user store of the J2EE Engine. All tasks that are relevant to user management and role assignments in the portal platform are performed by the user administrator with the UME User Management Administration Console in the portal environment. For more information, see Identity Management User Management in the SAP NetWeaver guide. The following administration functions and features are specific to the portal: Feature Companies UME Actions in the Portal Assigning Roles to Users and Groups Description Information about how to use companies to define a form of delegated user administration in the portal. A brief description of how UME actions are integrated in the portal. Roles are managed by the Portal Content Directory (PCD). For detailed information on the pre-configured administration roles, see Pre-Configured Roles. Relevant for single sign-on. User Management

User Mapping

For information on how to configure user management in the portal, see Configuration.

Software Change Management


Purpose
Software Change Management standardizes and automates software distribution, maintenance, and testing procedures for complex software landscapes and multiple software development platforms. These functions support your project teams, development teams, and application support teams. The goal of software change management is to establish consistent, solution-wide change management that allows for specific maintenance procedures, global rollout including localization, and open integration with third-party products. The following topics are covered:
Transport and Change Management - Enables and secures the distribution of software changes from the development environment to the quality assurance and productive environment. Support Packages and SAP Notes Implementation Provides standardized software distribution and maintenance procedures. Release and Upgrade Management Reduces the time, costs, and risks associated with upgrades.

Process Flow
Transport and Change Management
For detailed information about content transport in the portal see Portal Objects in the portal administration guide. Transport of

Support Packages and SAP Notes Implementation


For details on support packages and SAP Notes for the portal platform, see the Master Guide on SAP Service Marketplace at service.sap.com/instguides SAP NetWeaver.

Release and Upgrade Management


In order to display the version of the portal with which you are working, navigate as follows in your portal: System Administration Support Support Desk Version. You can find information about release and upgrade plans see SAP Service Marketplace at service.sap.com/instguides SAP NetWeaver.

Troubleshooting Process Flow


Regularly check the SAP Notes for component EP-PIN. They contain information about program corrections and provide additional documentation. The System Analyzer, which is supplied as part of the portal installation, provides important preinstallation information if run prior to installing the portal. Running the System Analyzer with the appropriate tests verifies that all the portal prerequisites are in place. For information about problem analysis scenarios for this component, see Portal Platform Problem Analysis Scenarios in the SAP NetWeaver Problem Analysis Guide (PAG).

SAP Exchange Infrastructure Purpose


This chapter provides a starting point for managing your mySAP components and maintaining optimal performance. It contains specific information for various tasks, and lists the tools that you can use to carry them out. It also refers you to the documentation required for these tasks. This guide is to be used in conjunction with other guides such as the Master Guide, Technical Infrastructure Guide, Solution Management Guide for mySAP Solutions, and the SAP Library. This guide does not replace the daily operations handbook that we recommend customers create for their specific productive operations.

Target Groups
1. 2. 3. 4. 5. Technical consultants System administrators Solution consultants Integration process owners Support specialists

Important SAP Notes


Check regularly which SAP Notes are available for the Technical Operations Manual. Important SAP Notes SAP Note Number 701097 Title SAP NetWeaver '04 Documentation Comments Contains information about corrections made to the SAP Library documentation of SAP NetWeaver '04 after its release.

Technical System Landscape


Documentation on SAP components such as SAP Exchange Infrastructure (XI) can be found in the SAP Library. Additional documentation is available on the SAP Service Marketplace at service.sap.com, where it is updated as required. The following table gives you an overview of the available topics: Topic Installation and configuration of SAP XI and integration with existing system landscapes Sizing Technical configuration Scalability High availability Security Guide/Tool Master Guide Quick Link xi, instguidesNW04

Quick Sizer Configuration Guide Technical Infrastructure Guide High Availability Guide Security Guide

sizing xi, instguidesNW04 xi, instguidesNW04 xi, ha, instguidesNW04 SAP Library

The main components of an SAP XI installation are shown in the figure below:

Monitoring of SAP Exchange Infrastructure


SAP Exchange Infrastructure (XI) can be monitored using SAPs standard monitoring solution CCMS (Computing Center Management System). Depending on the implementation basis (ABAP or Java technology) for the respective SAP XI component, different tools for detailed monitoring and problem and performance analysis are available: The Runtime Workbench Trace and log files 1. Data growth and data archiving monitors 1. Software component monitors In addition, specific monitoring functions for integration processes are also available: 1. You can monitor the execution of integration processes by using the monitoring functions of the Business Process Engine. When an integration process is executed, the system creates corresponding work items, just as it does during the execution of an SAP Business Workflow. You can display and analyze these in the workflow log. As part of error analysis, you can check in the runtime cache whether the system can create a runtime version for an integration process. 1. You can also set up error notifications for administrators to inform them when an integration process has an error status. The following figure gives an overview of the Java and the ABAP parts of SAP XI.

Runtime Workbench
SAP Exchange Infrastructure (XI) offers a central entry point for monitoring purposes: the Runtime Workbench (RWB). You can start the RWB from the XI start page by entering: http://<XI host>:<port>/rwb For more information about the RWB, see Central Monitoring. With the RWB the following monitoring functions are supported for SAP XI: Component monitoring The Computing Center Management System (CCMS) of SAP Web Application Server is used to monitor the different SAP XI components (Java and ABAP parts). The RWB user interface enables easily configuration of the component monitoring instead of directly using CCMS for this purpose. For example, you can specify the component to be traced. Message monitoring Message monitoring focuses on tracking the message processing status within an SAP XI component and on error detection and analysis. End-to-end monitoring End-to-end monitoring focuses on the monitoring of a message lifecycle from the SAP XI point of view. The RWB offers a user interface to configure the end-to-end message monitoring. For example, you can specify the components for which the trace should run and which trace level (degree of detail for the tracing) to use. Performance monitoring Statistics about different performance aspects of SAP XI can be accessed through the RWB. Here, you can select and aggregate performance data, for example, by component, time range, or message attributes.

The RWB provides an SAP XI-specific performance monitoring. The RWB user interface offers several ways to create performance statistics. The main parameters are the message throughput and the latency. For more information on performance, see the Tuning Guide SAP XI 3.0 on SAP Service Marketplace at service.sap.com/instguidesNW04 Operations SAPXI. Index administration By administering and monitoring the indexing of messages per SAP XI component, you enable an index-based message search that you can use in message monitoring. This kind of message search offers you enhanced selection criteria including adapter-specific message attributes and terms or phrases from the message payload. To be able to index messages, you require the search and classification engine TREX. See also Technical Operation of Search and Classification (TREX). Alert configuration By using the Alert Framework, central monitoring in XI can be provided with all errors reported during message processing in ABAP and Java. This enables an improved reaction to such errors in both the ABAP runtime and the Java-based Adapter Engine. For this purpose, the Alert Framework is provided with rules based on certain events and on information from the header of the XI message protocol. These rules determine whether alerts are send or not. If an alert is sent, it can be used for error analysis. Alert inbox The alert inbox is user-specific and displays all the alerts for each alert server that have been generated based on the alert configuration. Cache monitoring Cache monitoring displays objects that are currently in the runtime cache. Different cache objects are monitored depending on the cache instance concerned.

Trace and Log Files


Trace and log files are essential for analyzing problems. They are offered for all components of SAP Exchange Infrastructure (XI).

ABAP Parts of SAP Exchange Infrastructure


The Integration Engine does not usually persist message data in the file system. For diagnostic purposes you may, however, want to write message trace information to a file. You can configure this in the Integration Server by choosing Exchange Infrastructure Administration Integration Engine Administration Error Analysis Settings in your SAP Easy Access user menu. As a result, the following files are written:
Trace Files Content Detailed information for each message <msgid> sent using the Integration Engine Versions of message <msgid> sent using the Integration Engine, with pipeline ID <pid> and logged message version <msgvs> File TRC_<msgid>.txt Path As defined in the SAP Web Application Server profile parameter DIR_GLOBAL (see transaction AL11), typically: /usr/sap/<SAPSID>/SYS/global As defined in the SAP Web Application Server profile parameter DIR_GLOBAL (see transaction AL11), typically: /usr/sap/<SAPSID>/SYS/global

MSG_<msgid>_<pid>_<msgvs>.txt

Depending on the specific settings and size of messages sent using the Integration Engine, the number of files and the space occupied in the file system may become very large. Therefore, you should monitor the growth and remove trace information that is no longer required.
Trace level 1 is recommended for productive use. You can set the trace level on the Integration Server by choosing Exchange Infrastructure Administration Integration Engine Administration Integration Engine Configuration in your SAP Easy Access user menu.

J2EE Parts of SAP Exchange Infrastructure


The J2EE parts of SAP XI, that is the Integration Builder (IB), the Adapter Engine (AE), and the Runtime Workbench (RWB), as well as the System Landscape Directory (SLD), all use the standard logging of the SAP J2EE Server. This can be configured through the Log Configurator service in the Visual Administrator Tool of the SAP Web Application Server. On the Integration Server host (Integration Repository and Integration Directory may be installed on another server), <J2EEdir>stands for the following in the table below: /usr/sap/<SAPSID>/<instance_name>/j2ee/cluster/server
Content Technical trace information XI-specific application log Default server trace File tracefile.txt Path <J2EEdir>/services/servlet_jsp/work/jspTemp/ MessagingSystem/root/admin/ <J2EEdir>/log/applications/com.sap.xi <J2EEdir>/log

xi.log defaultTrace.trc

Tracing 1. 2. 3. 4. 5.

is not activated by default. To activate tracing, perform the following steps: Call the Log Configurator service. Switch To advanced mode. Select the Location tab page. Select a location. Change the Severity from None to the required value, for example, Debug.

Available Locations: Component Integration Repository Integration Directory Mapping Runtime Runtime Workbench Adapter Engine Messaging Runtime Proxy Framework Location XIREP XIDIR XIRUN XIRWB com.sap.aii.af com.sap.aii.messaging Com.sap.aii.proxy.framework defaultTrace.trc <J2EE>/log File Path

Logging is activated by default. To change the preset log level, perform the following steps: 1. Call the Log Configurator service. 2. Select the Categories tab page. 3. Choose Applications Exchange Infrastructure.

4. Change the Severity to the required value. You can view traces and log files by using the Log Viewer service in the Visual Administrator. For more information, see the SAP J2EE Engine Administration Manual under Log Viewer.

Plain J2SE Adapter Engine


In addition to the J2EE-based Adapter Engine, SAP XI 3.0 still supports the J2SEbased Adapter Engine. This Adapter Engine includes the File/FTP, JMS, JDBC, and SOAP adapters. In the following table, <Javadir> stands for the directory where the Plain J2SE Adapter Engine is installed.
Multiple Plain J2SE Adapter Engines can be installed in one XI landscape. Trace Files Content Technical logging information for all installed adapters File adapter_1.log adapter_2.log adapter_3.log adapter_4.log adapter_5.log Path <Javadir>/tech_adapter/LOGFILES

You can view the log on the host that runs the Plain J2SE Adapter Engine by choosing Traces from the main menu under the following HTTP address: <Adapter Engine host>:<port> You can set the trace level under the same HTTP address. Select the adapter in question under Available Adapters and then choose Configure. The default logging settings produce a set of five trace files, each 2 MB in size. These files are used in rotation for logging, effectively limiting the file system space used for log files to 10 MB. The file names above represent the default logging settings. The trace files can be viewed under the same HTTP address by choosing available trace files under Traces in the main menu.
Trace level INFO is recommended for productive use.

Data Archiving
This section provides you with information on data archiving specific to a process integration environment. For general information on this subject, see Data Archiving.

Integration Engine
The message store on the Integration Engine is the component for which data archiving is most critical. Depending on the integration processes that are running on the Integration Server, large numbers of messages with large message sizes may be persisted in the Integration Engine. Therefore, the archiving of (processed) messages must be carefully planned and monitored. Standard archiving processes are available to be scheduled as needed based on the Archive Development Kit and on the Archive Administration transaction (SARA). It is possible to run archiving jobs in parallel, which means that archiving is scalable. For more information, see Defining Interfaces and Retention Periods for Archiving and Archiving and Deleting. Fast growing tables to be monitored are those holding message processing data. To prevent these tables from growing too much, several jobs are scheduled automatically. These either archive outgoing messages or execute single-record deletion (every time a message is processed, it is subsequently

deleted from the related tables). In addition, the complete tables can be dropped by activating a dropdelete job. Make sure you save any entries from the respective tables that are still required. The fastest growing tables are those that contain the application payload in a compressed form. SXMSCLUP SXMSCLUR

Business Process Engine


Work items are created when an integration process is executed by the Business Process Engine. This is similar to the execution of a business workflow. If you want to archive an integration process, you therefore must archive the corresponding work items. See Archiving Work Items for further information. Archiving work items enables you to display the archived work items for a specific object. You can use this function, for example, if you want to display the archived integration process with which a specific message was processed. Fast growing tables to be monitored are: SWWLOGHIST All information about one process step. SWWWIHEAD Header information for processes. SWWCNTP0 Context information for processes, for example, references to messages.

Adapter Engine (J2EE)


The following table represents the persistence layer of the Adapter Engine, which means that it stores incoming and outgoing messages. XI_AF_MSG A full archiving solution is provided for this table. For more information, see Background Processing.

Security Archiving
Messages with S/MIME security settings can be archived by using the Runtime Workbench.

Data Archiving
This section provides you with information on data archiving specific to a process integration environment. For general information on this subject, see Data Archiving.

Integration Engine
The message store on the Integration Engine is the component for which data archiving is most critical. Depending on the integration processes that are running on the Integration Server, large numbers of messages with large message sizes may be persisted in the Integration Engine. Therefore, the archiving of (processed) messages must be carefully planned and monitored. Standard archiving processes are available to be scheduled as needed based on the Archive Development Kit and on the Archive Administration transaction (SARA). It is possible to run archiving jobs in parallel, which means that archiving is scalable. For more information, see Defining Interfaces and Retention Periods for Archiving and Archiving and Deleting. Fast growing tables to be monitored are those holding message processing data. To prevent these tables from growing too much, several jobs are scheduled automatically. These either archive outgoing messages or execute single-record deletion (every time a message is processed, it is subsequently deleted from the related tables). In addition, the complete tables can be dropped by activating a dropdelete job.

Make sure you save any entries from the respective tables that are still required. The fastest growing tables are those that contain the application payload in a compressed form. - SXMSCLUP - SXMSCLUR

Business Process Engine


Work items are created when an integration process is executed by the Business Process Engine. This is similar to the execution of a business workflow. If you want to archive an integration process, you therefore must archive the corresponding work items. See Archiving Work Items for further information. Archiving work items enables you to display the archived work items for a specific object. You can use this function, for example, if you want to display the archived integration process with which a specific message was processed. Fast growing tables to be monitored are: SWWLOGHIST All information about one process step. SWWWIHEAD Header information for processes. SWWCNTP0 Context information for processes, for example, references to messages.

Adapter Engine (J2EE)


The following table represents the persistence layer of the Adapter Engine, which means that it stores incoming and outgoing messages. 1. XI_AF_MSG A full archiving solution is provided for this table. For more information, see Background Processing.

Security Archiving
Messages with S/MIME security settings can be archived by using the Runtime Workbench.

Software Component Monitors


The Runtime Workbench offers component-oriented monitoring, which enables you to check and customize the runtime settings for the different components, for example. This also includes an is-alivecheck for the components of an SAP Exchange Infrastructure.

Management of SAP Exchange Infrastructure


Management of SAP Exchange Infrastructure (XI) includes various aspects: Administration tools of software components Starting and stopping Backup/restore and recovery Periodical tasks Logon and load balancing User management Exchange Profile

Administration Tools of Software Components


Administration Tools Software Component System Landscape Directory Transaction/Tool Choose Administration at http://<XI host>:<port>/sld Detailed Description See Administrative Activities. Prerequisites Web Browser (Internet Explorer 5.0 or higher, Netscape Communicator 4.7x) Web Browser (Internet Explorer 5.0 or higher, Netscape Communicator 4.7x) the Same prerequisites apply as for SAP Web Application Server 6.40. Web Browser (Internet Explorer 5.0 or higher, Netscape Communicator 4.7x)

Integration Builder

Access http://<XI host>:<port>/rep/start/index.jsp

N/A

Integration Engine

Choose Exchange Infrastructure Administration Integration Engine Administration in your SAP Easy Access user menu Access http://<Adapter engine host>:<Adapter engine port>

See Configuring Integration Engine. See Configuration.

Plain J2SE Adapter Engine

Starting and Stopping


Since the Integration Builder, Integration Server, and System Landscape Directory (SLD) are all based on the standard SAP Web Application Server (with SAP J2EE Engine), they are started together with the SAP Web Application Server (SAP Web AS) when installation procedures are followed.

Tools for Starting and Stopping Software Component System Directory Landscape Tool Choose Administration Start/Stop Server at http://<XI host>:<port>/sld Detailed Description After you have installed SAP Exchange Infrastructure you must configure the SLD and then start it manually. Afterwards it restarts automatically if it stops at any point (see Installation Guide SAP Exchange Infrastructure Release 3.0). You can also start the SLD explicitly, for example, when the SAP J2EE Engine is restarted or when there is a request for the SLD. After the SLD is started, you must ensure that the self registration tool for the technical systems is running. When the Integration Server is started, it registers itself in the SLD.

Integration Server (including Business Process Engine and Integration Engine) Integration Builder

No special tool; started/stopped automatically when its SAP Web AS host starts/stops. No special tool; started/stopped automatically when its SAP Web AS host starts/stops. No special tool; started/stopped automatically when its SAP Web AS host starts/stops. No special tool; started/stopped automatically when its SAP Web AS host starts/stops. Starting: In the installation directory of the Adapter Engine, execute run_adapter.bat (Windows) or run_adapter.cmd (Unix). Stopping: Choose Shutdown Adapter Engine in the main menu at http://<Adapter engine host>:<Adapter engine port>. This must be performed from a browser running on the <Adapter Engine host>.

When the Integration Builder is started, it registers itself in the SLD. The Runtime Workbench registers itself in the SLD when it is started. When the J2EE-based Adapter Engine is started, it registers itself in the SLD. The Plain J2SE Adapter Engine registers itself in the SLD when it starts. For instructions on setting up the Plain J2SE Adapter Engine for continuous operation, see Installation.

Runtime Workbench

Adapter Engine

Plain J2SE Engine

Adapter

Adapters running within the Plain J2SE Adapter Engine

Starting: Choose the adapter in question under Available Adapters at http://<Adapter engine host>:<Adapter engine port> and then choose Start. Stopping: Choose the adapter in question under Available Adapters at http://<Adapter engine host>:<Adapter engine port> and then choose Stop.

When an adapter starts, it registers itself in the SLD.

Basic configuration steps are performed during the installation of SAP Exchange Infrastructure 3.0. The SAP Exchange Infrastructure 3.0 Installation Guide and the SAP Exchange Infrastructure Configuration Guide explain these steps and describe checks to verify that the XI landscape is functioning properly.

Stop Procedure
To stop the various components of your XI system, perform the following steps: 1. If you use the Business Process Engine (BPE), first refer to Starting and stopping the BPE. 2. Stop the message flow from your sending systems where possible. If the sending system uses proxies, you can follow steps 3 to 6 to stop the message flow. 3. Lock the Integration Server for incoming messages by calling the transaction Integration Engine Administration (SXMB_ADM) and choosing Integration Engine Configuration Specific Configuration Change New Entries. Select the category RUNTIME and then the parameter ENTRY LOCK: Set the current value to 1 (LOCKED) and choose Save.
If you set this parameter, messages that have already been received will still be processed.

4. Deregister the queues of your XI system by calling the transaction Integration Engine Administration (SXMB_ADM) and choosing Manage Queues. Select Deregister Queues and choose Execute action. 5. Monitor the remaining entries in the queues by calling the qRFC Monitor Inbound Queue (transaction SMQ2) until no more queues are listed. 6. Check the tRFC entries by calling the transaction Transactional RFC (SM58) until the list is empty. 7. Stop the Plain J2SE Adapter Engine (if used). 8. Decide if you want to stop the non-central Adapter Engine (if used at all). This is an optional step with the following advantages/disadvantages: Advantage of stopping No errors occur during the downtime of the Integration Server. However, the sending systems will not be able to address the Adapter Engine and no files will be polled from the file system. Advantage of not stopping All messages with quality of service EO (Exactly Once) and EOIO (Exactly Once in Order) that enter the non-central Adapter Engine are persisted during the downtime of the Integration Server. However, they have to be manually restarted afterwards. 9. Decide if you want to stop the Partner Connectivity Kit (PCK) (if used at all). This has the same advantages/disadvantages as those outlined in step 7. 10.Stop the Integration Server.

Start Procedure
To start the various components of your XI system, perform the following steps: 1. If the SLD is running on a different host and has been stopped for maintenance reasons, you need to start it. 2. Start the Integration Server. 3. Wait until the J2EE Engine and all XI-related services are started.
This process can be monitored with the Visual Administrator.

4. 5. 6. 7.

8. 9.

1. Choose Server Services Deploy. 2. Choose Applications on the right-hand side. Start the Plain J2SE Adapter Engine (if used). Restart the non-central Adapter Engine and/or PCK (if used and stopped at all). If you did not stop them, access the message monitor and manually restart the messages with errors. Register the XI queues by calling the transaction Integration Engine Administration (SXMB_ADM) and choosing Manage Queues. Select Register Queues and choose Execute action. Open the Integration Server for incoming messages by calling the transaction Integration Engine Administration (SXMB_ADM) and choosing Integration Engine Configuration Specific Configuration Change New Entries. Select the category RUNTIME and then the parameter ENTRY LOCK: Set the current value to 0 (NOT LOCKED) and choose Save. Call the qRFC Monitor Inbound Queue (transaction SMQ2) and check the status of the queues. The correct status is "RUNNING". It might take several minutes before this status appears. Check for messages with an error status in the Adapter Engine, in the Integration Server, and in your business systems (if used) as follows: 3. Call the Runtime Workbench from the XI start page. 4. Choose Message Monitoring. 5. Select the following options as required: Adapter Engine <host> Integration Server Proxy Runtime <business_system>

10.Check your integration processes (if used) by calling the transaction Business Process Engine Monitoring (SXMB_MONI_BPE) and choosing Restart Process After System Crash. 11.If a cache refresh was performed and was still running when the Integration Server was shut down, call the transaction XI Directory Cache (SXI_CACHE) and check for errors by choosing XI Runtime Cache Display Refresh Error. 12.If your sending systems were stopped, you need to restart them; if they use ABAP proxies, apply steps 6 to 8. 13.Check for errors on all sending systems. 14.If you use the Business Process Engine (BPE), also see Starting and stopping the BPE.

Backup/Restore and Recovery


All parts of SAP Exchange Infrastructure (XI), except J2SE, use the persistence layer (ABAP or Java) provided by SAP Web Application Server (AS). Thus, for Backup/Restore and Recovery, the standard tools of SAP Web AS are used. For more information, see Backup and Recovery for the ABAP part and Backup and Recovery of the SAP Web Application Server (Java) for the Java part. The Plain J2SE Adapter Engine uses the specific tool of the corresponding operating system (with its file system persistence). Backup and Recovery for Individual System Components Software Component System Landscape Directory Integration Builder Integration Engine Data Type Original Original Original (messages) and cache (Integration Directory) Original (messages) and copy (cached configuration data from Integration Directory) Original Backup and Recovery Method Database and log backup. Database and log application log backup. backup;

Database backup. Data consistency with sender and receiver systems must be taken into account. Database and log backup; application log backup. Data consistency with sender and receiver systems must be taken into account. Adapter configuration and log file backup, possibly files to be processed or having been processed by the File/FTP adapter. Database and log application log backup. backup;

Adapter Engine (J2EE)

Plain J2SE Adapter Engine

Runtime Workbench

Original

The standard installation for SAP XI is all-in-one, which means that data of all SAP XI components is stored in one database. Exceptions are the Plain J2SE Adapter Engine and the System Landscape Directory if they already exist on the customer side. If the Adapter Engine (J2EE) is installed separately (as a non-central Adapter Engine) on a separate database instance, backup and recovery must be handled separately, too. For more information about backup and recovery in distributed system landscapes, see SAP Service Marketplace at service.sap.com/atg Backup & Restore.

Periodical Tasks Scheduled Periodical Tasks


No periodical tasks need to be scheduled for the System Landscape Directory, the Integration Builder, and the Adapter Engine of SAP Exchange Infrastructure (XI). The following periodical tasks are recommended for the Integration Server/Engine of SAP XI:

Standard/Housekeeping Jobs Task / Program Name Message queue processing Recommended Frequency Automatically started by the qRFC scheduler. Detailed Description The standard qRFC scheduler is used. Standard SAP Web Application Server procedures regarding housekeeping of qRFC tables apply. For more information, see Queued Remote Function Call (qRFC) This job is used to delete messages. Schedule this job with transaction SXMB_ADM, Schedule Deletion Jobs. See Deletion of history data: SAP_BC_XMB_HIST_DELETE _<client> Once every week Archiving and Deleting XML Messages. This job is used to delete history data. History data consists of a small amount of header information from deleted messages. This history data is stored in a separate table with a minimum retention period of seven days. Schedule this job with transaction SXMB_ADM, Schedule Deletion Jobs. See Archiving messages: SAP_BC_XMB_ARCHIVE<clie nt> Once daily Archiving and Deleting XML Messages. This job moves messages to be archived to the archive and deletes archived messages from the database. Schedule this job with transaction SXMB_ADM, Schedule Archive Jobs. See Defining Interfaces for Archiving and Retention Periods and Archiving and Deleting XML Messages. Cache update/refresh With the release of change lists, a cache update job is automatically started in a background task. Every 3 minutes It is very important that this task is scheduled for the Business Process Engine (BPE). The frequency can be changed by using transaction SWWD. It is very important that this task is scheduled for the BPE. The frequency can be changed by using transaction SWWA.

Deletion of messages: SAP_BC_XMB_DELETE_<clie nt>

Once daily

Monitoring error situations of processes: Job SWWERRE (automatically scheduled by transaction SWF_XI_CUSTOMIZING) Monitoring of deadlines for processes: Job SWWDHEX (automatically scheduled by transaction SWF_XI_CUSTOMIZING) Managing the correct processing of the event queue: Job SWEQSRV (automatically scheduled by transaction SWF_XI_CUSTOMIZING) Clean-up of workflow system: Job SWWCLEAR

Every 3 minutes

Every 1 minute

This is an optional periodical task for the BPE. The frequency can be changed by using transaction SWEQADM.

Deletes job logs for the SWWDHEX and SWWERRE.

transactions

(automatically scheduled transaction SWF_XI_CUSTOMIZING)

by

Processing of delayed messages (transaction: SXMSJOBS): SXMS_DELAYED_MSG_PRO C<client> Check status of IDoc adapter: SXMS_REFRESH_ADAPTER_ STATUS

Every 5 minutes

This job tests (for a given client) the conditions for time and event-controlled processing of messages.

Between 1 hour and 1 day, depending on the intensity of the usage of the IDoc adapter Once daily (possibly more frequently depending on content of the table) Every 5 minutes (10 times)

This job checks the status of messages that were sent to the IDoc adapter. Since the IDoc adapter does not send response messages, it is not automatically known whether a message was processed or not. This program deletes all messages from a table by deleting the whole table and creating it again. Individual messages that cannot be deleted are saved in a temporary table in the meantime. This program searches for failed (could not be processed correctly) or missing (were deleted manually from the queue) messages and tries to restart these automatically. The maximum number of restart attempts and the interval between these attempts is set with the qRFC scheduler. After this maximum number of restarts, the restart is canceled if it was not successful. Aggregates auditing data and runtime data.

Delete message table: RSXMB_TABLE_SWITCH

Find and restart failed messages: RSXMB_RESTART_MESSAG ES

Performance monitoring, aggregation: SAP_XMB_PERF_AGGREGAT E (use transaction SM36 to schedule job) Performance monitoring, reorganization: SAP_XMB_PERF_REORG (use transaction SM36 to schedule job) Performance monitoring, PMI: SAP_XMB_EXTRACT_PMI_D ATA (use transaction SM36 to schedule job) Performance monitoring, PMI: SAP_XMB_GET_PMI_DATA (use transaction SM36 to schedule job)

Every hour

Every hour

Deletes aggregated runtime data after a specified time period (parameter DAYS_TO_KEEP_DATA).

Depending on the configuration of PMI Depending on the configuration of PMI

Extracts runtime data collected by the Process Monitoring Infrastructure (PMI).

Retrieves runtime data collected by the Process Monitoring Infrastructure (PMI) and previously extracted by SAP_XMB_EXTRACT_PMI_DATA.

Required Manual Periodical Tasks


No periodical manual tasks are required for the System Landscape Directory and the Integration Builder of SAP XI. A periodical cleanup of all processed messages is recommended to avoid a waste of memory space. Required manual periodical tasks Task / Program Name SARA Recommended Frequency Weekly or monthly (depending on data volume) Regularly (depending on data volume) Detailed Description Transaction for archiving, for example, data from the BPE. Program for deleting process data that is no longer required. This enables you to release the occupied memory. To avoid deleting data unintentionally, it is recommended that you first determine and check the data to be deleted by using the program RSWF_XI_INSTANCES_SHOW (see also Deleting Process Data No Longer Required).

RSWF_XI_INSTANCE S_DELETE

Logon and Load Balancing


For components of SAP Exchange Infrastructure (XI) based on SAP Web Application Server (AS) (including SAP J2EE Engine), that is, for the System Landscape Directory, Integration Builder, Integration Engine, and Business Process Engine, refer to the respective SAP Web AS documentation. The Plain J2SE Adapter Engine component does not provide any load balancing functions.

User Management
The Integration Builder, Integration Engine, Runtime Workbench and Adapter Engine use the standard user management tools offered by SAP Web Application Server. For more information, see Central User Administration. For the Integration Repository, a specific authorization concept can be used. It provides a Java-based user interface, with which you can maintain roles and authorizations for user-defined object sets. For more information, see User Roles. For the Plain J2SE Adapter Engine, a separate user management is provided, which you can activate in the main menu of this Adapter Engine. For more information, see User Management. For further details on user management, see the and the SAP Security Guide XI. SAP Exchange Infrastructure Configuration Guide

Exchange Profile
The exchange profile is an XML document that is stored in the main database of the SAP Exchange Infrastructure (XI). The parameters contained in this document define certain basic technical settings. Most of them are initialized automatically during the installation phase, but in some cases the administrator may need to maintain them. You can access the maintenance screen at: http://<host:port>/exchangeProfile In this HTTP address host and port are the host name and connection port of your Integration Server. You are prompted for a user name and a password. A user with the J2EE security role administer is required. By default this J2EE role is mapped to role SAP_XI_ADMINISTRATOR_J2EE on SAP Web AS 6.40.

The HTTP address provides you with a browser-based interface for editing the exchange profile. For more information about editing the exchange profile and for a list of available parameters, see the SAP Exchange Infrastructure Configuration Guide under Exchange Profile Parameters. After any modification of the exchange profile, you must restart the Integration Server for the changes to take effect.

High Availability
All aspects of using SAP Exchange Infrastructure in a high availability environment are described in the SAP Exchange Infrastructure in High Availability Environments guide (see SAP Service Marketplace at service.sap.com/ha, service.sap.com/xi, or service.sap.com/instguidesNW04 Planning).

Software Change Management


Software change management standardizes and automates software distribution, maintenance, and testing procedures for complex software landscapes and multiple software development platforms. These functions support your project teams, development teams, and application support teams. The goal of software change management is to establish consistent, solution-wide change management that allows for specific maintenance procedures, global rollouts, including localizations, and open integration with third-party products. The following topics are covered: Transport and change management Enables and secures the distribution of software changes from the development environment to the quality assurance and productive environment. Development request and development release management Enables customer-specific maintenance procedures and open integration with third-party products. Support packages and SAP notes implementation Provides standardized software distribution and maintenance procedures. Release and upgrade management Reduces the time, costs, and risks associated with upgrades.

Transport and Change Management


Change management of the Integration Repository and Integration Directory content is supported by automatically generated change lists. The transport to quality and productive systems can be done by following the standard export/import procedure. The generally known way is to export all modified files (that are relevant for the transport and can be determined in the change lists), move the exported content to the destination system (development or productive system, or both), and import the content there. For more information about the export and import of integration objects, see Transporting Using the File System. In addition to this standard process, you can use SAP Change Management Service (CMS) to transport design or configuration objects between various Integration Repositories or Integration Directories, respectively. If you want to use CMS, you have to perform some configuration steps beforehand. These are explained under Configuring the Change Management Service in the SAP Exchange Infrastructure Configuration Guide. You can use the CMS Transport Studio to monitor the status of your transports. Transport using the Change For a detailed description of CMS and how to use it for XI, see Management Service.

Development Requests and Development Release Management


For SAP Exchange Infrastructure, development requests are handled by adhering to the standard development request processes. Requests are gathered by product definition and then forwarded to development at SAP. After decision on the development side, a feature list with the approved requests is created and the customers are informed. Additional changes on the customer side are not supported.

Support Packages and SAP Notes Implementation


For more information about currently available support packages for SAP Exchange Infrastructure (XI) 3.0, see SAP Service Marketplace at service.sap.com/patches. The SAP Note assistant is supported for the ABAP parts of SAP XI. A description of how to add support packages is available in SAP Note 670388. Updates can be done by using standard procedures. For the ABAP parts of SAP XI this is the implementation of support packages. For the Java parts, the deployment with the Software Delivery Manager (SDM) is used.

Release and Upgrade Management


For SAP Exchange Infrastructure (XI) 3.0 it is necessary to install the new version rather than to upgrade. This helps to reduce downtime and therefore smoothes the transition to the higher version. To migrate from an existing SAP Exchange Infrastructure 2.0 system to the new 3.0 version, you must install SAP XI 3.0 in parallel (on the same server or on another server) and migrate the content in a second step. The migration of content from a SAP XI 1.0 installation directly to SAP XI 3.0 is not supported. For more information, see the Installation Guide SAP Exchange Infrastructure 3.0 or the Upgrade Guide SAP Exchange Infrastructure 3.0. For more information about the release plan, see the service.sap.com/xi, under SAP XI in Detail Release Plan. Component Release Software Component SAP Exchange Infrastructure Release 3.0 Tool SAPInst, SDM, file transfer (for content migration) SAP Service Marketplace at

Troubleshooting
In the event of problems or error situations, it is recommended that you turn on tracing by using transaction SWELS.

For information about problem analysis scenarios for this component, see Exchange Infrastructure Problem Analysis Scenarios in the SAP NetWeaver Problem Analysis Guide (PAG).

SAP Business Information Warehouse


This manual does not replace the manual for daily operations that the customer is to create for their own productive operation.

Purpose
Designing, implementing and running your SAP BW so that you achieve top performance 24 hours a day has never been more important to the success of your company than it is today. This manual provides a starting point for the management and optimum maintenance of your SAP BW. It contains SAP BW-specific information for various tasks and lists the tools that you need to carry them out. It also refers to the documentation that you require for these tasks. You can only use this manual in connection with other manuals, such as other Technical Operation Manuals for SAP NetWeaver, the Master Guide and the SAP Library.

Target Groups
Technical consultants System administrators Solution consultants Business process owners Support specialists

Technical System Landscape


The following graphics illustrate the important components that are used when SAP BW is implemented and the communication between these components. Technical system landscape for SAP BW without external data sources

Technical system landscape for SAP BW with external data sources

More information on the technical system landscape Topic Guidelines / Tool Quick link to SAP Service Marketplace (service.sap.com) instguides

SAP BW 3.5

Master Guide

Monitoring SAP BW
Monitoring is a significant task in the administration of SAP BW. In SAP BW, various SAP Web Application Server monitoring tools are used for the ABAP components and the Java components. For more information on these tools, see the Technical Operations Manual for SAP NetWeaver under General Administration of SAP NetWeaver Administration of the SAP Web Application Server (ABAP) Monitoring and Management of the SAP Web Application Server (Java) Monitoring and Error Handling for SAP Web AS Java.

Other SAP BW-Specific Monitoring Functions and Tools: Monitoring Function or Tool BW Monitor in CCMS Description The Computing Center Management System (CCMS) has an alert monitor that supports you in monitoring and operating your SAP systems. The CCMS monitor sets of the alert monitor, together with the BW monitor, contain a selection of BW-relevant standard SAP contexts and context process chains. In process chain maintenance under Process Chain Attribute Monitoring, you can determine that a process be removed from automatic monitoring by the CCMS. You do this by setting the indicator in the Remove Chain from Automatic Monitoring? dialog box. In the default settings, automatic process chain monitoring by CCMS is switched on. For more information, see BW Monitor in the CCMS in the SAP BW documentation. Availability check for UB Connect The central monitoring system in the CCMS uses the Generic Request and Message Generator (GRMG) to check the availability of the J2EE Engine at set intervals. If the availability check fails, an alert is triggered in the central monitoring system. This helps you to establish whether servers or processes in the J2EE Engine have failed. You can use the CCMS Alert Monitor to check whether alerts have been triggered for the UD Connect scenario. For more information, see Checking Availability for UD Connect in the SAP BW documentation. SAP BW Load Monitor The load monitor is the monitoring tool for the Administrator Workbench. With the help of the monitor, you can observe the data requests and further data processing in SAP BW. For more information, see documentation. Open Hub Monitor Monitor in the SAP BW

The open hub monitor is a component of the open hub services. A request is generated when you activate and execute your InfoSpoke. This request is displayed in the open hub monitor where you can check the status. For more information, see SAP BW documentation. Open Hub Monitor in the

Analysis Process Monitor

The Analysis Process Monitor is a component of the Analysis Process Designer (APD). It provides an overview of your analysis processes. For more information, see Additional Functions in the APD in the SAP BW documentation.

Log view of process chain maintenance

In the log view of process chain maintenance, you can check the process chain runs. For more information, see Process Chain Log Display in the process chain documentation of SAP BW.

Administration of data targets

The administration of data targets allows you to trace the status of a request in the respective data target as well as allowing you to verify the data target contents. For more information, see Administration of Data Targets in the SAP BW documentation. Particularly sections: Requests in the InfoCube and Content InfoCube ODS

Requests in the ODS-Object and Object Content Managing InfoObjects

Overview of change runs

the

hierarchy/attribute

For more information, see Attribute Change Runs documentation.

Adjusting Hierarchy and in the SAP BW

Status overview of ODS objects Status overview of aggregates

For more information, see Status Overview of ODS Objects in the SAP BW documentation. For more information on the status overview of the aggregates, see Displaying an Aggregate and Its Components in the SAP BW documentation. The BEx Monitor offers you various options to check the execution of queries or query views in the back end of the BW system. For more information, see BW documentation. BEx Monitor in the SAP

BEx Monitor with OLAP trace tool, query monitor, OLAP cache monitor and ICM monitor

Trace and log files: OLAP trace tool BW Statistics

The OLAP trace tool allows data to be listed that is passed on to the BW system when actions are performed in the front end. For more information, see OLAP Trace Tool in the SAP BW documentation. BW Statistics is a tool for analyzing and optimizing processes in SAP BW. For more information, see BW documentation. BW Statistics in the SAP

Delta queue

The delta queue is a data store for change records in the SAP BW source system. In the delta queue of a DataSource you can check whether, how much, and what data it contains. For DataSources that support generic deltas, you can display the current value of the delta-relevant field in the delta queue. For more information, see Checking the Delta Queue in the SAP BW documentation.

Overview of requests in persistent staging area tables (PSA tables)

The PSA tree in the monitoring view of the Administrator Workbench provides you with an overview of the requests booked to the PSA tables. For more information, see Persistent Staging Area in the SAP BW documentation.

Overview of InfoPackage groups

The InfoPackage group tree in the monitoring view of the Administrator Workbench provides you with an overview of the InfoPackage groups (bundles of InfoPackages). For more information, see SAP BW documentation. InfoPackage Group in the

SAP BW log files when using Java components

The SAP BW log files can be found in the Log Viewer under ./log/Application/BI/* See the Technical Operations Manual for SAP NetWeaver under General Administration of SAP NetWeaver Management of the SAP Web Application Server (Java) Monitoring and Error Handling for SAP Web AS Java Monitoring and Displaying Log Files

Status server

overview

for

precalculation

For the status of the precalculation server and more information on it, see Customizing (transaction SPRO) under SAP Reference IMG SAP NetWeaver SAP Business Information Warehouse Reportingrelevant Settings Settings for Information Broadcasting Administrate Precalculation Server. For more information, see Administration of the Precalculation Server in the documentation on Information Broadcasting.

Managing SAP BW
You have the following options for managing SAP BW: Tools for Administration of SAP BW Starting and Stopping Saving Data and Restoring the SAP BW System Migration and System Copy User Management Printing

If you want to use the NetWeaver scenario for information broadcasting, make the additional administrative settings. For more information, see System Administration Tasks

Tools for Administration of SAP BW


Trasaction / Tool Administrator Workbench Visual Administrator with Use of SAP BW Java Components Description Administrator Workbench Administration Tools for the SAP J2EE Engine

Starting and Stopping


Because SAP BW is based on SAP WAS, procedures for starting and stopping correspond to those of SAP WAS. You can find more information in the SAP NetWeaver Technical Operations Manual under General Administration of SAP NetWeaver Administration of the SAP Web Application Server (ABAP) Management Starting and Stopping SAP-Systems and Instances or under Administration of the SAP Web Application Server (Java) Management of the SAP Web Application Server (Java) Starting and Stopping SAP Systems (Windows).

Saving Data and Recovering the SAP BW System


SAP BW is based on the ABAP and Java platform of SAP Web AS. Therefore standard SAP Web AS tools are used for saving data and recovering an SAP BW system. For more information, see the Technical Operations Manual for SAP NetWeaver under Backup and Recovery Backup and Recovering for the J2EE Engine

You extract data in the delta process from a source system into a SAP BW system. Installing a backup on a SAP BW system or on a source system connected to it can cause irreparable damage to cross-system data consistency. Active delta processes between the SAP BW system and the source system are most affected. For this reason, SAP recommends that you only perform synchronous backups in systems that are networked with each other and (in the most serious case) that you always run a synchronous recovery. If this is not possible, be sure to follow SAP Note 731682. The note contains information on the risks of a backup and recommendations for the backup in regard to active delta processes. You can call up the note from the SAP Service Marketplace ( http://service.sap.com), alias notes.

Migration and System Copy


In order to make full use of opportunities that current economy provides, companies must be confronted with faster and faster growth of the solution landscapes. This growth often requires changes to operating systems and/or databases. To find out how to proceed for a system copy, look in the System Copy for SAP Systems Based on SAP Web AS 6.40 guide. This guide can be found on the SAP Service Marketplace at the Internet address service.sap.com/instguides. Choose SAP NetWeaver Release 04 Installation. Also see SAP Note 771209 NW04: Homogeneous and Heterogeneous System Copy (supplementary SAP note) for any supplements to the guide.

User Management
SAP BW uses the user management delivered for SAP NetWeaver application platforms ABAP and Java (see the tables on user administration tools under User Management in the SAP NetWeaver Security Guide). You can find information on user management within SAP Enterprise Portal (SAP EP) under Security Identity Management User Management Engine in the documentation for the SAP NetWeaver components. For more information on user management with SAP EP 5.0, see the SAP EP documentation in the SAP Help Portal (help.sap.com), for example, for SP 5 look under Administration Guide User Management.

Users
Standard users created when the SAP BW system is installed
See also: SAP Web Application Server Security Guide SAP Web AS Security Guide for ABAP Technology User Authentication Protecting Standard Users.
Change initial passwords after installation to ensure that standard users cannot be misused.

Standard users specified when the SAP J2EE Engine is installed


See also: SAP Web Application Server Security Guide SAP Web AS Security Guide for Java Technology Users and User Management Standard Users and Groups.
Change initial passwords after installation to ensure that standard users cannot be misused.

Users in the SAP BW and SAP source system


The following table provides an overview of additional users required when using SAP BW: These users are not delivered and do not have default passwords.
The following table provides an overview of the users required when using SAP BW: System User Type Description

SAP BW

Database user

SAP BW

Background user in SAP BW (BWREMOTE)

Technical user

For more information on database users, see Operating System and Database Platform Security Guides The background user in SAP BW is used for communicating with the SAP BW source systems, for extracting data, and for background processes in SAP BW. You create the background user in Customizing in SAP BW and assign it a password (see Administration Settings Customizing Business Information Warehouse Automated Processes Create User for Background Processes. SAP recommends that you call the BW background user BWREMOTE. The system asks for a background user password when connecting to the source system. The authorization profile for the background user is S_BI-WHM_RFC. See also: Authorization Profile for Background Users. The background user in the SAP source system is used for communicating with SAP BW and for extracting data. If you connect an SAP source system to an SAP BW, the background user is to be created in the source system. You can create the user directly in the source system in user maintenance. You can enter a name in Customizing in SAP BW

SAP source system

Background Technical user in SAP user source system (ALEREMOTE)

that will be used as the default name for the background user when you connect a new source system. (See Administration Settings Customizing Business Information Warehouse Connections to Other Systems Connections Between SAP Systems and BW Default for Users in the source system (Maintain ALE Communication). SAP recommends that you call the BW background user for the source system ALEREMOTE. If the source system you are using is also a BW system, SAP recommends that you create the background user for BW and the background user for the (BW) source system completely separately. The authorization profile for the background user in the source system is S_BIWX_RFC. See also: SAP BW Administrator Individual user Authorization Profile for Background Users. The SAP BW administrator is responsible for the connection to source systems, loading of metadata and implementation of BW statistics, among other things. This user develops the data model and plans and monitors the processes in SAP (such as the loading process). See also: Authorization Profile for Working with the AWB Authors and analysts require advanced analysis functionality and the ability to examine ad-hoc data. In order to accomplish their tasks, they required useful, manageable reporting an analysis tools. See also: Authorizations for Working with the Business Explorer Executives and Knowledge Workers require personalized, context-related information that is accessible via an intuitive user interface. They generally work with pre-defined navigation paths, but require the option of analyzing the summary data more deeply. See also: Authorizations for Working with the Business Explorer Information Consumers require specific information (snapshot of a specific data set) in order to be able to execute their operative tasks. See also:

SAP BW

Authors analysts

and Individual user

SAP BW

Executives and Individual Knowledge user Workers

SAP BW

Information consumers

Individual user

Authorizations for Working with the Business Explorer

Printing
SAP BW uses print function of the SAP spool system at the back end. You can find more information in the SAP NetWeaver Technical Operations Manual in the section on general administration of the SAP Web Application Server (ABAP) under Printing. In addition, there are other BW-specific functions and recommendations for printing queries or Web applications: You can print queries using the Reporting Agent. The Reporting Agent gives you the open of determining the display of query data as a Reporting Agent setting for printing in the background. You can find more information under Defining Print Settings in the Reporting Agent section of the SAP BW documentation. You can use EXCEL functions to print queries in the BEx Analyzer. For Web applications, you can use Web browser functions for printing. The document How to... Enhance Web Printing shows you how you can enhance printing options in the Web to adapt the layout of printouts to your needs. For example, it includes information on how to print the header and footer on every page instead of only on the first page, or how page breaks can be created. You can find more information in the SAP Service Marketplace under Alias BW Services & Implementation HOW TO... Guides Guide List BW 3.x How to Enhance Web Printing.

Software Change Management


Software change management standardizes and automates software distribution, software maintenance and test processes for complex software landscapes and multiple software development platforms. This functions support your project, development and application support teams. The goal of software change management is to set up a consistent, cross-solution change that offers multiple procedures for maintenance, global rollouts, including localizations, and open integration with products from external sources. The following topics are dealt with in the next sections: Transport and Change Management - Enables and guarantees the distribution of software changes from the development environment to quality assurance and productive environments. Quality and Test Management - Saves time, decreases costs and risks that are connected with software changes. Support Packages, Front-end Patches and SAP Note Implementation Offers standardized software distribution and maintenance procedures. Release and Upgrade Management - Saves time, decreases costs and risks that are connected with updates.

Transport and Change Management


Transport system
Development projects for SAP BW are usually not performed in a productive system in most cases. Instead, they are carried out in one or - depending on your scope - in several development systems. If your development projects are done in one development system you have to transport the developments to the target system (a test or productive system). You can collect the newly created or changed objects of SAP BW in the respective development system using the transport connection. Then you can transport them with the Change and Transport Organizer (CTO).

You can choose between two strategies for transport:


Standard transport system BW transport system

For more information, see

Transport System.

Object changeability
In order to be able to change objects of a specific object type that are globally set to not changeable in such BW systems as well, you can set the individual object types to changeable in the Transport Connection function area.
Note that these objects are no longer connected to the transport system. Thus we recommend that you only use this process in productive systems.

You can find more information under documentation.

Object Changeability in the SAP BW

Quality and Test Management


eCATT is available in limited form for SAP BW. eCATT can be used for all transactions that are executed on the BW server - with the exception of transaction RSA1. Transaction RS1 cannot be used for tests for technical reasons. However, you can test most of the function areas of RSA1 using transaction RS_AWB_REMOTE. The front end of SAP BW can not be tested using eCATT because it is not based on ABAP technology. Up to now there were no test plans or eCATT scenarios available for delivery with SAP BW.

Support Package, Front-End Patches and SAP Note Implementation


Updates for ABAP components for SAP BW are performed with the implementation of Support Packages. Updates for the front-end are done with front-end patches. For Java components, the deployment takes place with the Software Delivery Manager (SDM). You can download the Support Packages available for SAP BW from the SAP Service Marketplace at the Internet address service.sap.com/patches SAP BW. Here you find information about how you can implement the Support Packages and which plug-ins are available. We recommend that you implement the Support Packages for the components included in a product version according to the Support Package stacks. You can find more information on the SAP Service Marketplace at the Internet address service.sap.com/maintenance SAP Support Package Stacks. You can find information on contents and schedules for Support Packages and front-end patches for a product version, as well as jumps to the download area for Support Packages and front-end patches at the SAP Service Marketplace at the Internet address service.sap.com/bw. SAP BW <Product Version> Patching Information SAP BW <Product Version> . Information about contents and any specific, binding dependencies between Support Packages can be found here in the SAPBWNEWS. Hot News let you know about potential critical situations. Hot News appear as a system message in the OSS system. The SAP Note Assistant is supported for ABAP components of SAP BW.

Release and Upgrade Management


SAP BW follows the standard SAP processes for maintenance of the release. You can find more information on the SAP Service Marketplace at the Internet address service.sap.com/maintenance.

Troubleshooting
For information about problem analysis scenarios for this component, see the Problem Analysis Guide under Business Intelligence Problem Analysis Scenarios. Please note that this documentation is only available in English.

SAP Knowledge Management


Purpose
Knowledge Management comprises the following subcomponents: Content Management (CM) Search and Classification (TREX) Technical Operation of Content Management Technical Operation of Search and Classification (TREX)

Below you will find information on the technical operation of the two components.

Technical Operation of Content Management


This guide does not replace the manual for daily operation which we recommend customers create for their specific productive processes.

About this Guide


It is more important than ever that your mySAP solution can be used at optimum performance levels 24 hours a day. This guide offers you a starting point for managing and maintaining your mySAP components. It contains specific information for various tasks and introduces the appropriate tools. It also refers to the documentation that you need for your tasks. You can only use this guide in conjunction with other guides such as the master guide, technical infrastructure guide, solution management guide for mySAP solutions, and SAP Library.

Target Groups
Technical consultants System administrators Solution consultants Business process specialists Support specialists

Important SAP Notes


Check frequently to see whether SAP notes for solution management are available. Important SAP Notes SAP Note Number 701097 Title SAP NetWeaver Documentation '04 Comments Contains information on corrections to the documentation after it has been delivered.

Technical System Landscape


For more information about the technical service.sap.com/instguidesnw04. system landscape, see the master guide at

Monitoring
Various components, applications, and services are delivered with the Knowledge Management platform. The KM platform provides several monitoring and logging applications as iViews so that you can monitor these objects. These applications check and monitor the KM platform in the background. They deliver information

about the status and function of the various items and contribute to the recognition of critical system events. Functions of the portal platform are used to execute performance monitoring and activity tracing for the KM platform. You can use the information delivered by the monitoring, logging, and tracing applications to analyze the system and take appropriate action where necessary. The monitoring and logging applications of the KM platform are integrated into the Monitoring workset. This workset is available to system administrators by default. If all relevant prerequisites are met, you can monitor parts of the KM platform and TREX using the SAP Solution Manager (see SAP NetWeaver 04 Supportability Setup Guide in the SAP Service Marketplace at service.sap.com/instguides SAP NetWeaver Release 04 Operations). For more information, see the section Monitoring, Logging, and Tracing in the KM Administration Guide and Monitoring Technology and Logging in the Portal Administration Guide.

Alert Monitoring with CCMS


Proactive, automatic monitoring is the basis for reliable operation of your SAP system environment. SAP provides you with the infrastructure and recommendations for the setup of alert monitoring. This allows you to recognize critical situations in the Knowledge Management platform as quickly as possible. The following monitors are available for monitoring the KM platform. You access them using transaction RZ20 in CCMS.
Monitor KM Version KM Config KM State Detailed Description See Monitoring KM with SAP Solution Manager in the KM Administration Guide.

Detailed Monitoring, Problem, and Performance Analysis Tools Trace and Log Files
Trace and log files are needed to analyze problems. Knowledge Management uses the logging mechanisms of the J2EE Engine. System information is written to the file defaultTrace.trc.
Important Log and Trace Files Content System information Audit information on repository events Configuration changes File defaultTrace.trc applications.log config_audit.<n>.lo g Path .../usr/sap/<SAP_System ID>/JC<J2EE Engine Instance>/j2ee/cluster/server<n>/log/ .../usr/sap/<SAP_System ID>/JC<J2EE Engine Instance>/j2ee/cluster/server<n>/log/ .../usr/sap/<SAP_System ID>/JC<J2EE Engine Instance>/j2ee/cluster/server<n>/log/

For information about these files, see

Trace and Log Files.

For more information about monitoring the trace and log files, see Displaying Log Files.

Monitoring and

Operating System Monitors


No operating system monitors are included in the KM standard delivery. However, you can set up a monitor in CCMS that displays the free memory space on the server used for managing the documents and folders of a file-system repository manager. The required data for this can be provided by the program SAPOSCOL.

Workload Monitors
No workload monitors are included in the KM standard delivery. However, you can set up a monitor in CCMS that displays the workload of all nodes in a KM load-balancing environment. The required data for this can be provided by the program SAPOSCOL.

Software Component Monitors


Monitors for technical components are needed to analyze problems.
Monitor Component monitor Description Displays the status of objects in the KM platform and enables the identification of incorrect configurations.

This monitor is suitable for individual installations of Knowledge Management. We recommend the cluster monitor for cluster installations.
Cluster monitor Displays the status of objects in a distributed system landscape with multiple KM nodes and allows you to identify configurations with errors. It functions in a similar manner to the component monitor. You can use the cluster monitor to monitor all nodes in your KM system landscape centrally. Displays statuses and statistics for active caches and allows you to empty caches manually. Displays information on the active crawlers and allows you to control them. Returns information on the status of current indexing processes. Displays error messages, warnings, and information generated by KM applications and services. Note that this information is not logged in the J2EE Engine log (see above).

Cache monitor Crawler monitor Indexing monitor Application log

Administration
SAP offers you an infrastructure that your technical support consultants can use to manage all SAP components effectively and execute all tasks connected to Middleware Technology. The management of mySAP Technology has the following aims:
Provide a central interface for managing administration tasks for Middleware Improve the process flow of troubleshooting for the entire solution Standardized management of the user interface

Management Tools for Software Components


Tool Detailed Description

Configuration iView
Index Administration iView

See
See

Content Management Configuration


Index-Administration

Starting and Stopping Components


For more information about starting and stopping the system, see Starting and Stopping SAP Systems and Instances. The subcomponent Search and Classification (TREX) is started and stopped independently of CM and the portal. For more information, see Starting and Stopping TREX. If you want TREX to be temporarily unavailable, you do not need to stop CM or the portal. However, you cannot use searching and indexing functions during this time. These functions are available again as soon as TREX is restarted.

Periodic Tasks Scheduled Periodic Tasks


In the Knowledge Management platform, scheduler tasks are automatically started and executed at predefined times by the scheduler service. The tasks originate from different CM applications and services.
Standard/Routine Tasks Program Name/Task CmdbGarbageCollector, WebGarbageCollector TimeBasePublishingPublish, TimeBasePublishingUnpublish ICETaskQueueReader IndexServiceTaskQueueReader DailySubscriptions, WeeklySubscriptions, MonthlySubscriptions, ReportScheduler Recommended Frequency See standard configuration See standard configuration See standard configuration See standard configuration See standard configuration See standard configuration Detailed Description See Garbage Collector Scheduler Tasks See Scheduler Tasks for TimeDependent Publishing See Content Queue Reader Exchange Task

See Index Service Task Queue Reader See Polling Scheduler Task

See

Report Scheduler Task

Necessary Manual Periodic Tasks


In addition to automated tasks, there are some tasks that you have to start manually.
Necessary Manual Periodic Tasks Tasks or Transactions Reindexing and incremental update of data sources Description You have to update Web repository indexes to update or Recommended Frequency The frequency depends on how often document changes

repair them. For more information, see Reindexing and Incremental Updates

take place on the remote Web server. If regular updates are necessary, you can set up an automatic cycle.

Reports
In Knowledge Management, there is a series of reports available for various roles, which you can use for analyses. Reports can provide statistics functions and administration functions. For example, there are reports that search the database for orphaned objects that originate in CM repositories. For more information about reports and their recommended frequencies, see Reports.

Logon and Load Balancing


Like the portal, the subcomponent Content Management can be operated in a distributed system landscape. For information about load balancing for Content Management, see the Technical Infrastructure Guide - SAP Enterprise Portal 6.0 at service.sap.co/nw04 Documentation Planning SAP EP.

User Management
Like the portal, Content Management uses the user management of the J2EE Engine. For more information, see User Management Engine.

Data Backup and Restore AS Java-Based Data Backup and Restore


The procedures for backing up and restoring Knowledge Managementare the same as those described in the portal technical operations manual, in the Backup/Restore and Recovery section.

Special Features of Data Backup and Restore in Knowledge Management


Backing Up and Restoring Internal Repositories Repositories in DB Mode and CM

KM content in internal repositories and CM repositories in DB persistence mode is stored in the database along with most of the KM configuration data. To back up KM content, you have to back up the database. For information about backing up and restoring the database, see Backup and Recovery of the SAP Web Application Server (Java).

Backing Up and Restoring Objects Outside the Database


As well as backing up the database, you have to back up the directory hierarchy of the /etc file system repository. This contains system and configuration data. By default, this repository is located at .../usr/sap/<SAP System ID>/SYS/global/config/cm/etc. Include this directory in the data backup and restore process for KM. Use standard mechanisms for this.

Partial Restore of Documents From a Database Backup


If you only want to restore individual files in your productive system (with their properties and ACLs) instead of restoring the entire database, proceed as follows: 1. Import the backed up database into a second portal installation (backup system). This can be a test system, for example. 2. Create a WebDAV repository manager to cater for the CM repository in question in the backup system. 3. You can now use the WebDAV repository manager in the productive system to access the required files and copy them to the required folders in the productive system, thereby restoring the files in question.
When using WebDAV to restore files, you can only include the properties and ACLs of the documents in question. You can only restore additional metadata such as feedback, ratings, and read flags by restoring the entire database.

Backing Up and Restoring CM Repositories in DBFS Mode


If you are operating CM repositories in DBFS persistence mode, you must use an adapted procedure for backing up and restoring data. For more information, see Backing Up and Restoring CM Repositories in DBFS Mode.

Content on Remote Servers


Content on remote servers that you have included in Knowledge Management using repository managers is not normally backed up using the procedures for backup and restore described by SAP. Take this into account when planning your data backup and restore. Use the usual procedures of the IT department in your company.
We recommend storing an overview of all connected remote servers with your project documents. To subsequently create this overview, you can find the required information (address of the remote server and path details) in the Knowledge Management configuration. To call up the configuration, choose System Administration System Configuration in the portal. Then choose Knowledge Management Content Management Repository Managers in the detailed navigation pane. Note the information relevant for the server (for example, the entries in the Root Directoryparameter) for the CM, file system, and WebDAV repository managers, as well as all other repository managers used in your scenario. You can then use this overview when backing up the data.

Data Backup and Restore for TREX


Also bear in mind the Data Backup and Restore for TREX section. You should note that you must suspend all KM crawling tasks in the indexing monitor before starting a complete data backup (offline) for TREX. After restoring the data, you must resume the crawling tasks.

Backing Up and Restoring CM Repositories in DBFS Mode


If you are operating CM repositories in DBFS persistence mode, note the special features of the data backup procedure. You have to back up the data in the file system as well as the database.

Backup
Carry out the following steps: 1. First back up the data in the file system. 2. Then back up the database. 3. In the final step, you back up the new data in the file system that was added since the first step was completed.

If you are using DBFS persistence mode, file changes are characterized by the creation of a new file and then the deletion of the old file. Old files that need to be deleted are marked as such and deleted by means of the garbage collector scheduler task called CM repository GC the text time the task runs.

All data that is added after step three is taken into account during your next data backup.

Restore
Proceed 1. 2. 3. 4. as follows to restore data: Import the data backed up in step one. Then import the database. Then import the data backed up in step three. In the final step, run the CM repository file system check report.

This report finds files that were deleted after you backed up the file system data but before you backed up the database and that are now available in the file system following the data import procedure. You can use this report to delete these orphaned entries.

Software Logistics
Software Logistics standardizes and automates software distribution and maintenance as well as test procedures for complex software landscapes and various software development platforms. These functions support your project, development, and application support teams. Software Logistics aims to implement a consistent, cross-solution change management that provides several procedures for maintenance, global rollouts, and localization, as well as open integration with products offered by third-party organizations. This section gives additional information on the most important software components. The following topics are included: Development requests and development release management. This enables customer-specific procedures for maintenance and the open integration of third-party products. Support packages and SAP note integration. This offers standardized software distribution ad procedures for maintenance. Release and upgrade management. This saves time and reduces the costs and risks related to upgrades.

Development Requests and Development Release Management


The handling of development requests for Knowledge Management keeps to the standard processes for development requests. Requests are collected after product definition and are then forwarded to SAP development. After the development team makes a decision, a list of functions with approved requests is created and customers are informed.

Support Packages and SAP Note Integration


For information on available KM support packages and their deployment, see the SAP Service Marketplace at service.sap.com/patches.

Release and Upgrade Management


For SAP release and upgrade service.sap.com/netweaver. plans, see the SAP Service Marketplace at

To display the version of Knowledge Management and Collaboration, choose System Administration Support Version in the portal. The following application is available for installing and upgrading Knowledge Management: Component Release Software Component Knowledge Management Release SAP NetWeaver 13
TM

Tool SP Stack SAPinst, SDM

Troubleshooting
Regularly check the SAP Notes for the component EP-KM. They contain information on program corrections and provide additional documentation. SAP Note 743130 contains information on known problems in Content Management and Collaboration. For more information on problem analysis scenarios for this component, see Problem Analysis Guide under Knowledge Management and Collaboration Problem Analysis Scenarios. Please note that this documentation is only available in English.

Appendix
Relevant Guides
For more information on installation and configuration, see the master guide.

Relevant Information
The table below contains links to information on this guide. Content Master guide, installation guide, and upgrade guide Relevant SAP Notes Released platforms Security SAP Solution Manager Quick Link on the SAP Service Marketplace (service.sap.com) instguides notes platforms security solutionmanager

Technical Operation of Search and Classification (TREX)


Introduction
This guide does not replace the manual for daily operation which we recommend customers create for their specific productive processes.

About this Guide


It is more important than ever that your mySAP solution can be used at optimum performance levels 24 hours a day. This guide offers you a starting point for managing and maintaining your mySAP components. It contains specific information for various tasks and introduces the appropriate tools. It also refers to the documentation that you need for your tasks. You can only use this guide in conjunction with other guides such as the master guide, technical infrastructure guide, solution management guide for mySAP solutions, and SAP Library.

Target Groups
Technical consultants System administrators Solution consultants Business process specialists Support specialists

Important SAP Notes


Check regularly for SAP Notes about the technical operation of Search and Classification (TREX). Important SAP Notes SAP Note Number 701097 Title SAP NetWeaver '04 Documentation Comments

Contains information on corrections to the documentation after it has been delivered.

Technical System Landscape


TREX is made up of the following central components: Java client ABAP client Web server with TREX extension Queue server Preprocessor Index server Name server

The graphic below shows the individual components and the communication between components:

The table below tells you where you can find further information on the technical system landscape. Topic Technical configuration Guide/Tool Installation Guide for Search and Classification (TREX) 6.1 Quick Link on the SAP Service Marketplace (service.sap.com) For more information, see the SAP Service Marketplace at service.sap.com/instguides Installation & Upgrade Guides SAP NetWeaver Release 04 Installation For more information, see the SAP Service Marketplace at service.sap.com/instguides Installation & Upgrade Guides SAP NetWeaver Release 04 Installation

Technical configuration

Distributed Search and Classification (TREX) 6.1 Systems

Security

Search Classification Security Guide

and (TREX)

Monitoring TREX
Monitoring SAP NetWeaver is an important part of managing SAP NetWeaver. A section has therefore been devoted to this subject alone.

Alert Monitoring with CCMS


Proactive, automatic monitoring is the basis for reliable operation of your SAP system environment. SAP provides you with the infrastructure and recommendations for the setup of alert monitoring. This allows you to recognize critical situations in Search and Classification (TREX) as quickly as possible.

Availability Monitoring with the SAP Solution Manager


You can use SAP Solution Manager to monitor the availability of individual TREX servers. Availability monitoring is based on the technology of the SAP CCMS Generic Request and Message Generator (GRMG). A TREX GRMG server runs on every TREX host. CCMS sends a request to the TREX GRMG server at regular intervals. The TREX GRMG server analyzes the request and starts tests to check the availability of the individual TREX servers (index server, queue server, preprocessor, name server, and Web server). The TREX GRMG server then transmits the result to the CCMS.

Prerequisites
You use the configuration file installed.xml to control which TREX servers of a TREX installation are checked. You determine which TREX installation is to be checked by the CCMS (SAP system) by uploading a GRMG configuration file to transaction GRMG in SAP system. This configuration file is provided as a template. For more information about availability monitoring, see Monitoring TREX with SAP Solution Manager.

Availability Monitoring with the TREX Daemon and the Name Server
After the TREX installation, a TREX daemon runs on every host. The daemon is a central service that starts the actual TREX servers (index server, queue server, and so on) and monitors them during routine operation. If a server becomes unavailable, it is automatically restarted by the daemon. The daemon starts all servers that were selected for the installation. A minimal TREX system has a standard configuration with no RFC or HTTP server. The TREX name server offers a watchdog function for monitoring active TREX servers. The watchdog regularly checks whether the active TREX servers can be reached. If a server does not respond, the name server marks it as inactive in the central configuration file topology.ini.This prevents the name server from passing on the address of a server that is currently unavailable. The watchdog only checks active TREX servers. It does not check whether it can reach servers that have been recorded as inactive. This is not necessary, since when an unavailable server is restarted, it reports to the name server and is recognized as being active again. You can use the TREX administration tools and the TREX monitor to check the availability of TREX servers on the Knowledge Management Platform of SAP Enterprise Portal.

Monitoring System Status and Configuration


The SAP Solution Manager provides you with information on operating system resources, content of the TREX trace files, and the TREX configuration. You use this information in the following situations:
To check whether TREX is optimally configured for your requirements before going live. To monitor trace files and operating system resources and to recognize critical system events during routine operation.

For more information about monitoring the system status and configuration, see Monitoring TREX with SAP Solution Manager.

Prerequisites

The SAPCCMSR and SAPOSCOL agents are installed and configured on your host. You have installed a TREX-specific plug-in for the SAPCCMSR and SAPOSCOL agents for monitoring the system status and the configuration.

Activity Tracing for TREX


You can use the function Activity Tracing to record processing steps made in the system when a user carries out an action. You can display the results in the Log Viewer of the J2EE Engine and analyze them for performance information and errors (for more information, see Log Viewer). If you activate activity tracing, TREX processing steps that take place internally are also recorded. TREX data is particularly useful if you want to analyze actions such as searching, classifying, or creating an index.

Prerequisites
You have to register the paths of the TREX activity traces on the log viewer server before you can display them in the Log Viewer.
For more information about activity tracing for TREX, see Solution Manager. Monitoring TREX with SAP

Detailed Monitoring, Problem, and Performance Analysis Tools Trace, Log, and Alert Files
In the standard configuration, TREX writes all error messages that occur during routine operation to trace and alert files. The TREX daemon, the individual TREX servers, and other TREX components all write their own trace files. As soon as a new process starts, a trace file is generated for the process in question. An alert file is written for each TREX server. In the standard configuration, the alert files contain all error messages that the index server, name server, preprocessor, queue server, and Web server produce. Monitoring systems such as CCMS can analyze these files and make system administrators aware of new error messages. If TREX is connected to the SAP Solution Manager, a CCMS agent analyzes the alert files and makes the monitoring system aware of changes. The monitoring system handles the alerts reported to it and makes a system administrator aware of them. Trace files contain messages that the TREX components return during routine operations. In the standard configuration, the trace files only contain error messages. By default, trace files are located in the directory <TREX_directory>\trace. The file names are formed as follows so that you can distinguish between the various trace files: <prefix>.<process_ID>.<sequential_number>.trc
TrexIndexServer.1468.001.trc TrexIndexServer.1468.002.trc ... TrexIndexServer.982.003.trc TrexIndexServer.982.001.trc Important Trace and Configuration Files

TREX Component Attribute engine Daemon Filter Index provider Index server Name server Preprocessor Queue server Python extensions RFC server Search engine Text-mining engine Index server clients Web server Path to the trace file

Trace File TrexIndexServer.<number>.trc TrexDaemon.<number>.trc TrexFilter.<number>.trc TrexWebServer.<number>.trc TrexIndexServer.<number>.trc TREXNameServer.<number>.trc TrexPreprocessor.<number>.trc TrexQueueServer.<number>.trc PythonExtension.log TREXRfcSvr.<number>.trc TrexIndexServer.<number>.trc TrexIndexServer.<number>.trc TrexTCPClient.<number>.trc TrexWebServer.<number>.trc

Configuration File TREXIndexServer.ini TREXDaemon.ini TREXFilter.ini TREXWebServer.ini TREXIndexServer.ini TREXNameServer.ini TREXPreprocessor.ini TREXQueueServer.ini imsconfig.cfg TREXIndexServer.ini TREXIndexServer.ini TREXTcpipClient.ini TREXWebServer.ini

The configuration files contain the following trace settings:


Maximum size of a trace file Maximum number of trace files for a process Trace level Specification as to whether performance is measured

You can also use the TREX administration tools to display the TREX trace and log files. You can record a Python trace for certain TREX components. If you activate the Python trace, all calls that the TREX components receive are logged. You can use the Python trace function to record actions as executable Python script that you can make available to TREX Support for troubleshooting. By default, the Python traces are located in the directory <TREX_Directory>\trace. The table below gives an overview of the TREX components that write a Python trace, the name of the trace files, and the configuration files in which you can activate the Python trace.
Python Trace TREX Component Index server, search engine, text-mining engine Attribute engine Content store Index server clients Python Trace servertrace.py Configuration File TREXIndexServer.ini

attrtrace.py contentStoreTrace.py clienttrace.py

TREXAttributes.ini TREXContentStore.ini TREXTcpipClient.ini

For a list of the most important error messages, see SAP Note 649574: TREX 6.0: List of Error Codes and Messages.

Operating System and Workload Monitors SAP Solution Manager


The SAP Solution Manager monitors the system status and configuration (SAPCCMSR and SAPOSCOL agents) and provides information on operating system resource, load, and running processes when using TREX. You use this information in the following situations:
To check whether TREX is optimally configured for your requirements before going live. To monitor trace files and operating system resources and to recognize critical system events during routine operation.

For more information about monitoring the TREX system status, see with SAP Solution Manager.

Monitoring TREX

TREX Admin Tools


You can also use the TREX administration tools to monitor the system status and operating system resources. The TREX administration tool displays your memory usage and the CPU load for each host and each TREX process.

TREX Alert Monitor


The TREX Alert Monitor is another tool that you can use to monitor TREX. The tool checks central TREX functions at regular intervals and notifies you about the system status by e-mail.

Other Important Problem Analysis Tools TREX Monitor


The TREX monitor is a Web-based administration interface that you can use to monitor TREX during routine operation on the Knowledge Management Platform of SAP Enterprise Portal. You can use the TREX monitor to administrate the TREX queue server and index server in the portal, to monitor their availability and function, and to take appropriate action if errors occur. The TREX monitor is included in the portal as an iView. This iView is available to all uses who are assigned to the role of system administrator in SAP Enterprise Portal. For more information on using the TREX monitor, see TREX Monitor in the Knowledge Management administration guide.

Administrating TREX
SAP offers you an infrastructure that your technical support consultants can use to manage all SAP components effectively and execute all tasks connected to Middleware Technology. The administration of SAP NetWeaver has the following aims:
Provide a central interface for managing administration tasks for Middleware Improve the process flow of troubleshooting for the entire solution

Starting and Stopping TREX


For the detailed procedure for starting and stopping TREX, see Stopping TREX. Starting and

Administration Tools of Software Components


You can administrate TREX using the tools in the table below. Overview of TREX Administration Tools Tool TREX Monitor Function You manage TREX indexes and monitor the availability of TREX servers on the Knowledge Management Platform of SAP Enterprise Portal. You use the Visual Administrator of the J2EE Engine to configure the TREX caches and the parameters for communication between the TREX Java client and the TREX servers (especially the TREX name server). You administrate the queues of the TREX queue server and the indexes of the TREX index server. You administrate the central TREX configuration file topology.ini, which contains all information on the structure of a TREX installation and stores the TREX server indexes and queues. You can also display the TREX trace and log files and monitor the system status and operating system resources. There are two TREX admin tools: TREX Admin Tool in the SAP System TREX Admin (Stand-Alone) Tool Use You must have installed Knowledge Management (KM) to use the TREX monitor.

TREX Configuration in the J2EE Engine

TREX Admin Tools

Data Backup and Restore


For the detailed procedure for data backup and restore, see Restore for TREX. Data Backup and

Changing the TREX Installation)

Host

Name (Single and

Multiple

Hosts

For the detailed procedure for changing the host name of a TREX installation, see the attachment to SAP Note 921454: TREX 6.1: Change TREX Host Name (Single and Multiple Hosts).

Software Logistics
Software logistics standardizes and automates software distribution and maintenance as well as test procedures for complex software landscapes and various software development platforms. These functions support your project, development, and application support teams.

Software logistics aims to implement a consistent, cross-solution change management that provides several procedures for maintenance, global rollouts, and localization, as well as open integration with products offered by third-party organizations.

Quality and Test Management


New TREX releases are always tested internally using a predefined test package with a standard test landscape and with verifiable test data. In particular, the handling of mass data (mass tests), load restrictions (stress tests), and the performance of TREX are checked. The test package calls test atoms in the form of Python scripts that test the basic functionality of TREX and are stored in the directory <TREX_Directory>\python_support. When you have installed TREX you execute the Python script runInstallationTest.py used to test the basic functions of TREX. This script calls a subset of TREX test atoms to check the functional correctness of TREX. If the Python script is executed successfully, you know that TREX has been installed properly, the configuration files contain the necessary entries, and the TREX servers are running.

Release and Upgrade Management and Support Packages


The documentation below supports you in the installation, upgrade, and migration of TREX.
Make sure that you use the current version of the TREX guides. You find this in the SAP Service Marketplace at service.sap.com/instguides Installation & Upgrade Guides SAP NetWeaver Release 04 Installation TREX Guide Distributed Search and Classification (TREX) 6.1 Systems Installation of TREX 6.1 Migration from TREX 6.0 SP1 to 6.1 Description Guide for installing distributed TREX systems Installation guide for release TREX 6.1 Migration guide

Implementation of SAP Notes


The following SAP Notes contain current installation information and corrections to the installation documentation.
Make sure that you use the current version of SAP Notes. SAP Notes can be found in the SAP Service Marketplace at service.sap.com/notes. Relevant SAP Notes SAP Note Number 691509 Title Installation of TREX 6.1 Comments Contains current information on the TREX

installation. 492305 INST: SAP J2EE Engine / Dialog Inst. / Gateway Inst. 6.20 TREX 6.0/6.1: Additional Information About TREX ABAP Client Relevant for an installation with an RFC connection: Contains current information on the SAP Gateway installation. Relevant for an installation with an RFC connection: Contains recommendations for using the queue server and information on which application uses which version of the ABAP client. This information is relevant for configuration steps after the TREX installation.

658052

Troubleshooting
For information on the problem analysis scenarios (PAS) for TREX, see Search and Classification (TREX) Problem Analysis Scenarios in the SAP NetWeaver Problem Analysis Guide.

Appendix
Relevant Guides
For more information on installation and configuration, see the master guide for SAP NetWeaver. The master guide is located at service.sap.com/instguides Installation & Upgrade Guides SAP NetWeaver Release 04 Installation

Relevant Information
The table below contains links to relevant information on the technical operation of Search and Classification (TREX). Content Master guide, installation guide, and upgrade guide Relevant SAP Notes Released platforms Network security Technical infrastructure SAP Solution Manager Quick Link on the SAP Service Marketplace (service.sap.com) instguides ibc Notes platforms securityguide network ti solutionmanager

SAP Mobile Infrastructure


This section contains information about the administration tasks required to operate the SAP NetWeaver component SAP Mobile Infrastructure. It provides an overview of the tools required to perform specific tasks, with references to the relevant, detailed documentation. Since SAP Mobile Infrastructure requires the components SAP Web Application Server ABAP and Java, you must also refer to the information provided in the sections Management of the SAP Web Application Servers (ABAP) and Management of the SAP Web Application Servers (Java).

Technical System Landscape


The Technical System Landscape shows the main technical components of SAP Mobile Infrastructure as well as the communication between these components.

Tools
You use the following tools to administer and monitor SAP Mobile Infrastructure: You use the SAP MI Web Console or the SAP NetWeaver Mobile Administrator (depending on your configuration) to carry out your tasks. For more information, see Configuration of SAP Mobile Infrastructure. Tool SAP MI Web Console Task In the SAP MI Web Console, you manage and monitor mobile components, users, and mobile devices. The SAP MI Web Console runs on the SAP MI J2EE Server Component. Launch the SAP MI Web Console with the following link: http(s)://<Server>:<Port>/me/WebConsole/login For more information, see SAP NetWeaver Mobile Administrator Starting the SAP MI Web Console. You use the Mobile Administrator to manage mobile devices. You can find the relevant functions in SAP NetWeaver Administrator in the Administration area under Mobile Infrastructure. You also have access to SAP MI in the Computing Center Management System (CCMS) in the Monitoring area of SAP NetWeaver Administrator. The administration toolkit provides the following functions for the administration of Smart Synchronization: Profile Dialog: Maintenance of Smart Synchronization configuration data Monitoring Display of synchronization messages with different views Log Display of processing logs Purge Deletion of obsolete runtime history data from the system Migration Transport of SyncBO definitions from one SAP Web AS to another Tool: Tool: Tool: Tool:

Administration Toolkit

Tasks
The tasks required for the administration of the MI environment can be grouped as follows: Monitoring

In this section you can find more information on central monitoring of your system landscape. Administration In this section you can find more information on editing tasks that are performed on either a regular or an ad hoc basis. Software Change Management In this section you can find more information on Support Package Stacks and SAP Note implementation, as well as transport and change management. Troubleshooting

Technical System Landscape


This section describes the technical system landscape of SAP Mobile Infrastructure and lists the related components. The following figure shows the main components of an MI landscape and the communication between these components:

The infrastructure consists of a server component and a client component. The client component provides a runtime for the mobile applications and the mobile device. It offers generic services by means of an API, which the mobile applications can access. The server component incorporates the application server for ABAP and Java and handles the receipt and transfer of data to and from the client and application back end. It also contains all the monitoring and software logistics tools for Mobile Infrastructure. The following table contains more information on the components in the landscape: Components Application Back End See The back end of a mobile application comprises Customizing and repository objects. Both kinds of objects are transported using the standard mechanisms of the SAP Change & Transport System.

MI Server Component

The MI Server Component consists of the SAP MI J2EE and the SAP MI ABAP Server Component. It covers the following functional areas: Software logistics Synchronization System monitoring Generic services

MI Client Component

The MI Client Component provides a mobile application with the following services: UI programming models Framework services

For more technical information, see the Technical Infrastructure Guide for Mobile Infrastructure on the SAP Service Marketplace at service.sap.com/nw-mi Media Library Documentation and Guides.

Monitoring
Monitoring is divided into the following areas:
Monitoring the mobile devices Monitoring Smart Synchronization

Various monitoring applications and log applications are provided for these areas. The applications check and monitor the mobile devices and Smart Synchronization in the background and supply information about the status of these two areas. Consequently, they can help to identify critical system events. Since SAP Mobile Infrastructure requires the components SAP Web Application Server ABAP and Java, you must also refer to the information provided in the sections Monitoring and Monitoring and Error Handling for SAP Web AS Java. The following functions are available:
General monitoring functions

The additional monitoring functions differ depending on the administration tool you have configured for use with SAP Mobile Infrastructure:
Monitoring functions with the SAP MI Web Console Monitoring functions with the SAP NetWeaver Mobile Administrator

General Monitoring Functions:


Function Description MI is connected to the monitoring architecture of the CCMS (Computing Center Management System). The concept of this monitoring architecture is to provide all the required information (for example, availability, configuration data, log and trace files) in a single, central monitoring system. As soon as problems occur, they are displayed in the alert monitor. For more information, see Call CCMS: Transaction RZ20 For information about SAP MI see SAP Mobile Infrastructure Monitor Templates Mobile Infrastructure. SAP NetWeaver Administrator: Monitoring MI Server: Alert monitor: Transaction MI_ALMON Reorganization tool:

SAP MI in the Computing Center Management System Checking Synchronization Processes

Monitoring. Special MI tools that support working with the CCMS: Alert monitor To display the alerts registered by the CCMS Reorganization tool To clean alert files, when required

Transaction MI_ALBACK

Performance tracing ( Measuring System Performance on the Mobile Device)

If problems occur with the Log Viewer: Display system performance, you and analysis of data can register all the (trace format) relevant activities on the mobile device and then send the log file to the server to be evaluated. Refer to SAP Note 851831 for further information.

Monitoring functions with the SAP MI Web Console


Function Status overview for mobile components ( Displaying the Status of Mobile Components) Description In the SAP MI Web Console, you can track the status of the mobile components on a mobile device. Each time the mobile device synchronizes it sends its current status to the Web Console. trace file, send it to the server, and analyze it there. You can activate tracing on the mobile device using the server. The system records the events on the mobile device and writes them to the file trace.txt. They are then saved under <installation directory>\log on the mobile device. Call SAP MI Web Console: Administration Administer Mobile Devices CCMS: Transaction RZ20 For information about SAP MI see SAP Mobile Infrastructure Monitor Templates Mobile Infrastructure Logs and Traces. Log Viewer: Display and analysis of the data (trace format). CCMS: Transaction RZ20 For information about SAP MI see SAP Mobile Infrastructure Monitor Templates Mobile Infrastructure.

Tracing in SAP MI Client

the You can write events and errors into a

Tracing on SAP MI Server

the You can perform tracing for the MI sync servlet and for the SAP MI Web Console. The following trace files are created:
<WebAS_InstFolder>./log/ applications/sap.com/ com.sap.ip.mi.misync/mi.trc and <WebAS_InstFolder>./log/ applications/sap.com/ com.sap.ip.me.webconsole/wc.trc

Log Viewer: Display and analysis of the data (trace format).

Monitoring functions with the SAP NetWeaver Mobile Administrator


Function Status overview for mobile components ( Displaying the Status of Mobile Components) Description You can track the current status of a mobile component on a particular mobile device in the SAP NetWeaver Mobile Administrator. Each time the mobile device synchronizes, it sends its current status to the server. If problems occur on the mobile device you can activate the tracing function. Different trace levels are available. The system records the events on the mobile device and writes them to the file trace.txt. They are then saved under <installation directory>\log on the mobile device. If it is possible to synchronize with the mobile device, the trace file is sent to the server with the next synchronization. Call SAP NetWeaver Administrator: Administration Mobile Infrastructure Device Maintenance MI Server: Transaction ME_RTRACE CCMS: Transaction RZ20 For information about SAP MI see SAP Mobile Infrastructure Monitor Templates Mobile Infrastructure Logs and Traces. Log Viewer: Display and analysis of the data (trace format). SAP NetWeaver Administrator: Administration Mobile Infrastructure Generic Sync Queue Monitor Technical Sync Monitor Smart Synchronization Replication Monitor SyncBO Processing Statistics

Tracing ( Activating Tracing on Mobile Device)

the

Monitoring synchronization ( Monitoring Synchronization Process)

The following monitors are available to monitor synchronization: the Generic Synchronization Queue Monitor (allows you to monitor the server queue for Generic Synchronization) Technical Synchronization Monitor (allows you to monitor the entire synchronization process from the moment it is triggered by the user to the completion message on the client at the end). Smart Synchronization Replication Monitor (allows you to monitor replication runs for SyncBOs of the types back-end-driven (T51) and timed 2-way (T01)). SyncBO Processing Statistics (You monitor how long it takes to process the individual SyncBOs. You specify the devices you want to monitor in the transaction MEMON_CUST.)

Monitoring functions when using the administration toolkit


Function Description Call

Synchronization overview ( Displaying the Synchronization Overview)

In the Monitoring Tool, you have an overview of synchronization for which you can generate different views. You use the monitoring tool if you want to check the processing of particular worklist items, for example.

MI Transaction MEREP_MON

server:

You can view the details about Synchronization synchronization messages from the message display inbox or outbox. ( Displaying Synchronization Messages (Inbound / Outbound)) Logging ( Log Tool) You can use the log tool to find errors that occurred in Smart Synchronization. To optimize performance and system resources, you can configure different log levels. You use the log tool, for example, if you want to check worklist itemindependent processes (for example, the replicator).

MI Transaction MEREP_MON: Data

Server: Worklists

MI server: Transaction MEREP_LOG

Administration
Tasks
The administration tasks are listed according to the tool you use to complete the relevant task:
Tasks performed when using the SAP MI Web Console Tasks performed when using the SAP NetWeaver Mobile Administrator Tasks performed when using the administration toolkit

Tasks performed when using the SAP MI Web Console


Tasks On Demand
The following administration tasks are to be performed as and when required:
Task Uploading Components Mobile Further Information In the SAP MI Web Console, you can see all the mobile components for which a Mobile Component Descriptor (MCD) was created. If the corresponding MCD for the newly developed mobile component exists, you must upload the files for the mobile component that you want to deploy to the mobile devices. The following three options are available: Assignment of user roles (standard) Manual assignment to a mobile device Assignment to a new mobile device version

Assignment of Mobile Components to Users

Displaying the In the SAP MI Web Console, you can track the status of the mobile Status of Mobile components on a mobile device. Each time the mobile device synchronizes it sends its current status to the SAP MI Web Components
Console.

Synchronizing Data Carriers with the Back End Select drivers for mobile peripheral devices ( Driver Selection Tool)

Synchronization of data with the back end that the user of the mobile device stored on one or more data carriers. You use the driver selection tool to choose peripheral drivers that meet your requirements for mobile peripheral devices. This selection process also considers the mobile application target device operating system, processor, virtual machine, and available transports. The configuration of SAP MI on the mobile device is stored in the MobileEngine.config file. You can make changes to the configuration using the device configuration or the configuration file. You can delete the data of mobile devices and users that no longer exist from the server.

Configuration of Mobile Devices Deleting Server Data for Mobile Devices and Users

Managing System You can send short system messages to all mobile devices to inform the users about important events, such as the dates and Messages
times server maintenance is due to take place. You can stop the client on the mobile device. Stopping the Client on the Mobile Device

Tasks performed when using the SAP NetWeaver Mobile Administrator


Tasks On Demand
The following administration tasks are to be performed as and when required:
Task Assign device configurations to groups/users ( Creating a Hierarchy) Configuration of Mobile Devices Further Information The hierarchy reflects your organization structure. You assign device configurations to groups of users. The system automatically assigns the mobile devices used by the users to synchronize. You can also determine which users or roles are allowed to manage the various groups of users. You configure: The behavior of the SAP MI Client Component on mobile devices The mobile components that are to be installed on the mobile device The mobile device itself (for example, the start-up parameters and battery capacity monitoring) The drivers installed on the mobile device Creation of short system messages and distribution to all mobile devices to provide the users with important information (for example, server maintenance times and dates). Deployment of mobile components on the server and uploading the data required for these mobile components to the mobile device.

Creating and Managing System Messages Administration Mobile Components of

Assignment of The following three options are available: Assignment using the device configuration (standard) Mobile Components to Users Direct assignment to mobile device
Setting Up the SAP MI on the Mobile Device Assignment of user roles The following options are available: Installing the MI Client Component using the URL Installing the MI Client Component using setup packages Single and mass installation of MI Client Component on Compact Flash Cards Synchronization of data with the back end that the user of the mobile device stored on one or more data carriers.

Synchronizing Data Carriers with the Back End

Installation of You can automatically install corrections (upgrades, support Corrections on the packages, support package patches) for the SAP MI Client (SAP MI Client Component) on the mobile device. Mobile Device Searching for and You use the Device Removal function to check which mobile Deleting Obsolete devices are no longer used. You then delete the relevant data on the server. Mobile Devices
Uninstalling Devices Mobile If a mobile device no longer exists or the client is no longer used on a particular device, uninstall SAP MI on the mobile device.

Checking Client You can check the configuration files for the client in the Mobile Administrator. You can determine how often the files are updated Configuration Files
and how many versions of the files are stored on the server.

Tasks performed when using the administration toolkit


Tasks On Demand
The following administration tasks are to be performed as and when required:
Task Edit configuration data of Smart Synchronization ( Profile Dialog) Further Information Control and start of processing of messages that are exchanged between the mobile devices and the SAP MI Server Component. With the migration tool you can transport the SyncBO definitions from one SAP Web AS to another. You can delete mobile IDs that are no longer required. Inconsistencies can occur with type T51SyncBOs between the middleware and back end if one of the two systems crashes. You can use the consistency check to track down and resolve inconsistencies.

Transport SyncBO definitions ( Migration Tool)


Deletion of Obsolete Mobile IDs Consistency Check for SyncBOs of Type T51

Upload and Download of BWAFMAPP Entries

As part of a system upgrade, it may be necessary to transport BWAFMAPP entries to a temporary storage medium to update the entries after the upgrade.

Periodic Tasks
The following tasks must be completed periodically:
Task Delete runtime data ( Purge Tool) history Further Information Deletion of obsolete runtime history data from the SAP MI Server Component (as this can have a negative impact on performance). How often this has to be done depends upon various factors, such as: The log level setting The number of mobile devices The frequency with which the mobile devices are synchronized

Data Backup and Recovery


The different synchronization and recovery processes are performed using three systems: the client, the MI server, and the back-end system. Under certain circumstances, it is not possible to execute some of the processes. This is the case, for example, during system downtime. In this case, a backup is essential. For more information on backups, see the documentation for the back-up system. When all the systems are working again, it may be necessary to perform additional steps to recover the data and ensure its consistency. The following system error scenarios describe the steps to be performed depending on the situation at hand:
Temporary Unavailability of Back End Temporary Unavailability of MI Server Incomplete Recovery of Back End Incomplete Recovery of MI Server

The above applies to Smart Synchronization applications based on Mobile Infrastructure as of Release 2.5. For generic synchronization applications running on Mobile Infrastructure as of Release 2.5, the scenarios described do not apply as no business data is stored on the MI server. However, if you assign applications during an incomplete MI server recovery, you must reassign these applications.

Software Change Management


Support Package Stacks and SAP Note Implementation
Support Package Stacks offer regular updates of SAP NetWeaver. Within the stacks themselves there are MI client-specific Support Packages for software updates. The SAP Notes are provided for urgent corrections and solutions to smaller problems. Perform the following tasks as and when required: Task Description

Software maintenance for SAP Mobile Infrastructure: Import available Support Packages and patches

Updates for the SAP MI Client Component are performed when Support Packages are implemented. The available Support Packages can be found in the SAP Support Portal at service.sap.com/swdc by choosing the path: Download Support Packages and Patches Entry by Application Group SAP NetWeaver SAP NETWEAVER SAP NetWeaver <name of release> Entry by Component MI Client. We recommend reading the respective Support Package Stack Guide before importing a Support Package Stack. You can find this documentation in the SAP Support Portal at service.sap.com/swdc by choosing the path: Download Support Packages and Patches Entry by Application Group SAP NetWeaver SAP NETWEAVER SAP NetWeaver <name of release>. Choose the Documentation link for the stack you want. For more information on the installation itself, see Installation of Corrections on the Mobile Device.

Implement individual corrections

To solve smaller problems you can use the SAP Notes for individual corrections. SAP Notes can be found in the SAP Service Marketplace at service.sap.com/notes. The Note Assistant is supported for the ABAP components of Mobile Infrastructure.

Transport and Change Management


Using the migration tool for Smart Synchronization, you can transport SyncBo definitions from one SAP Web Application to another. You can use this tool, for example, to transport to the production system when you have completed your tests in the test system. In doing so, you can export and import SyncBOs (flat file or transport file). For more information, see Migration Tool.

Troubleshooting
Check the SAP Notes for the component BC-MOB regularly. They contain information on program corrections and provide additional documentation. In the SAP NetWeaver Mobile Administrator, you can monitor mobile devices using the function Device Maintenance. You can display the status, filter according to devices with errors during Smart Synchronization, and switch to the detailed error display (see Using the Expert Tool for Error Analysis).
Check the availability, configuration data, log files, and trace files in the central monitoring system CCMS (for more information, see SAP MI in the Computing Center Management System).

Use the Log Tool if errors occur during Smart Synchronization to trace the problem. Logs can contain technical debugging information, application messages, or descriptive messages sent from the SAP MI Server Component. For more information on this topic, see the Smart Synchronization Troubleshooting Guide in the SAP Service Marketplace at service.sap.com/nw-mi Media Library Documentation and Guides.

You can find information on problem analysis scenarios for Mobile Infrastructure in the SAP NetWeaver Problem Analysis Guide (PAG) under Mobile Infrastructure Problem Analysis Scenarios.

Remote Support
The Windows Mobile Developer Power Toys tool allows access to all clients remotely and can help to analyze problems. With the ActiveSync remote display tool and Symantec pcAnywhere, the administrator can access the mobile device and investigate the file system. The Windows Mobile Developer Power Toys tool is available at www.microsoft.com/windowsmobile/downloads/powertoys.mspx.