PRINT FROM SAP HELP PORTAL

Document: Administrative Tasks URL: http://help.sap.com/saphelp_nw73ehp1/helpdata/en/0e/77d8255ffa49bbb4e4c476c87376db/content.htm Date created: July 17, 2013

2013 SAP AG or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Please see www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.

Note This PDF document contains the selected topic and its subtopics (max. 150) in the selected structure. Subtopics from other structures are not included.

PUBLIC 2013 SAP AG or an SAP affiliate company. All rights reserved.

Page 1 of 8

Administrative Tasks
Operating SAP NetWeaver PI covers both the technical operation of an SAP NetWeaver PI installation and the administration of all its technical components, as well as the execution and monitoring of integration scenarios that you have set up based on SAP NetWeaver PI.

Procedure
Administering and Maintaining SAP NetWeaver PI More information: Administering and Maintaining SAP NetWeaver Process Integration Monitoring Integration Processes SAP provides various tools for monitoring the Advanced Adapter Engine, the Integration Engine, and other components in SAP PI. More information: Monitoring Integration Processes. Saving Message Versions You can store messages at runtime in the Advanced Adapter Engine (AAE) and the Integration Engine (IE) for administrative purposes. More information: Saving Message Versions Tasks Related to Software Logistics

Transporting Design and Configuration Objects Process Integration landscapes in general consist of development systems, consolidation or test systems and production systems. Therefore, several ES Repositories and Integration Directories also come into play when you plan and maintain your system landscape and your processes end-to-end. Setting up transport scenarios and transport paths is therefore a key task for administrators. More information: Transporting ESR Content and Objects of Integration Directory

Note
Objects are not shipped from the Integration Directory because they reflect the configuration settings in a specific system landscape. However, you can have different Integration Directories installed in your landscape when you differentiate between test landscapes and productive landscapes, for example. In this case, you can transport from the test Integration Directory to the productive Integration Directory.

Change Management for Design and Configuration Objects You can create different versions of design objects in the ES Repository and configuration objects in the Integration Directory. When you save an object for the first time, you create its first version. The object (still in edit mode) is stored in a user-specific change list (tab Change List in ES Repository or Integration Directory). The version ID is only closed when you activate the object. A new version is created when you start editing the object that is already activated. The ES Repository and the Integration Directory provide different options for version conflict management.

Note
Object versions are treated in the same way in both the ES Repository and the Integration Directory. More information: Change Lists (ES Repository) Working with Change Lists (Integration Directory) Administering Back-End Systems To administer the back-end systems involved in an integration scenario as well as the AS ABAP or AS Java part of the Integration Server, you can use the SOA Manager or SAP NetWeaver Administrator, respectively. Using these tools, you can perform the following administrative tasks: Monitoring services locally in the back-end system Publishing services from the back-end system into the Services Registry (for more information: Services Registry) SOA Manager is the administration tool for ABAP-based backends involved in integration scenarios. You can access the SOA Manager by using the transaction code SOAMANAGER in the back-end system. More information: Working with the SOA Manager SAP NetWeaver Administrator is the administration tool for Java-based backends involved in integration scenarios. You can access the SAP NetWeaver Administrator by entering the following data in a Web browser: http://<host><port>/nwa Here the following represents: <host> the host where the Application Server Java is installed. <port> the HTTP port of the Internet Communication Manager. It consists of 5<Java instance_number>00. For example, if the instance number of the Java instance is 60, the HTTP port is 56000.

PUBLIC 2013 SAP AG or an SAP affiliate company. All rights reserved.

Page 2 of 8

Monitoring Integration Processes

SAP provides various tools for monitoring the Advanced Adapter Engine, the Integration Engine, and other components in SAP NetWeaver Process Integration (PI). You can use SAP Solution Manager for central monitoring, as well as several other local monitors on Advanced Adapter Engine Extended (AEX) and dual-stack systems. Central Monitoring When you have SAP Solution Manager in your landscape you can use it as a central tool for monitoring the integration processes. Within the PI Monitoring dashboard in the Technical Monitoring Work Center you can obtain an overview of all PI components in your landscape. If you find that certain processes or messages on a particular component have to be reviewed more thoroughly, you can navigate to the corresponding local monitor on the system where the component is running. Accessing and Using Local Monitors On each system in your PI domain you can use a local monitoring tool to monitor a PI component running on this system. Within a local monitor, you can obtain detailed information about a specific process. Local monitors also allow you to control the process execution. To access all local monitors in a quick and easy way use the configuration and monitoring home page: http://[host]:[port]/pimon The monitoring frequency depends on the volume of messages processed. We recommend checking the various monitors at least once a day. It is also important that you frequently check the message queues to make sure that the overall message flow is working. If there are problems in a specific queue, no messages in this queue are processed. Local Monitoring on AEX Systems The local monitors on an AEX system are available in SAP NetWeaver Administrator. They can be accessed at: http://[host]:[port]/nwa Local Monitoring on Dual-Stack Systems SAP provides the following local monitoring tools on dual-stack systems: Identically to AEX systems, you can monitor the processes on the Advanced Adapter Engine and the Business Process Engine using the tools available in SAP NetWeaver Administrator. These tools can be accessed at: http://[host]:[port]/nwa You can monitor the processes on an Integration Engine using the tools available in transaction SXMB_MONI. These tools can be accessed in SAP GUI, as well as with a browser using SAP GUI for HTML. You can monitor the processes on an Integration Engine using the tools available in Runtime Workbench. These tools can be accessed at: http://[host]:[port]/rwb

Note
On AEX systems the Runtime Workbench cannot be used for monitoring purposes.

More Information
Monitoring the Advanced Adapter Engine Monitoring the Integration Engine Monitoring Integration Processes using NetWeaver Administrator

Saving Message Versions

You can store versions of messages at runtime in the Advanced Adapter Engine (AAE) and the Integration Engine (IE). You can specify after which processing step in the pipeline of the AAE and the IE the message version is to be stored.

Procedure
You have the following options to store messages at runtime: Staging Versions of asynchronous messages can be stored after specific steps at runtime. An administrator can then edit the message, for example, in order to correct faulty data in the payload, and then restart and process the message again. This function is only available for messages processed by the AAE. Message logging Versions of synchronous and asynchronous messages can be stored after specific steps at runtime to make them available for logging purposes at a later point in time. Logged messages are only available in display mode and cannot be restarted any more. Global Configuration of Staging Find below more information on how to configure staging globally, that means, for all scenarios running in a PI landscape. This function is available for asynchronous messages processed by the AAE.

PUBLIC 2013 SAP AG or an SAP affiliate company. All rights reserved.

Page 3 of 8

Configuring Staging on the Advanced Adapter Engine When you use the dual-stack implementation option of SAP NetWeaver PI, you can configure staging on the AAE for two different kinds of message processing scenarios: Dual-stack message processing (including the IE) In scenarios of this type, both AS ABAP and AS Java are involved for message processing at runtime. This kind of message processing has been available in the very first releases of SAP NetWeaver PI. It is configured using the configuration objects receiver determination, interface determination, and sender/receiver agreement in Integration Directory. More information: Saving Message Versions in the Advanced Adapter Engine (Dual-Stack Message Processing) Local message processing on the AAE This kind of message processing involves only the Advanced Adapter Engine at runtime, the ABAP stack is not involved at all. Scenarios of this type are configured using the integrated configuration in Integration Directory. This kind of staging is also the only available option in case you use the Advanced Adapter Engine Extended. More information: Saving Message Versions in the Advanced Adapter Engine (Local Message Processing) Global Configuration of Logging Find below more information on how to configure this function globally, that means, for all scenarios running in a PI landscape. This function is only supported for synchronous messages. Configuring Logging on the Integration Engine More information: Logging and Tracing (Integration Engine). Configuring Logging on the Advanced Adapter Engine You can log messages either in the pipeline of the Advanced Adapter Engine or within the processing of a chain of modules of an adapter. Configuring Message Logging (Within AAE Pipeline) Configuring Message Logging (Within Adapter Module Chain) Scenario-Specific Configuration of Staging and Logging You can configure staging and logging of messages for specific scenarios that are covered by an integrated configuration.

Note
This option is only available for AAE-only message processing. To perform scenario-specific configuration of staging and logging, open the corresponding integrated configuration in Integration Directory and choose tab Advanced Settings . Proceed as described under: Configuring Advanced Settings for Message Storage

Note
For more information on how to display logged messages on the AAE, see: Monitoring Messages

Displaying Message Versions on the Integration Engine You can display versions of messages processed by the IE. You can compare message versions in order to analyze what changes to the message were made by the individual processing steps of the pipeline. More information: Displaying Message Versions (Integration Engine).

Transporting ESR Content and Objects of Integration Directory

Use
Objects in the Enterprise Services Repository (ES Repository) are referred to as design objects , while objects in the Integration Directory are referred to as configuration objects . The transport consists of an export from the source repository or source directory and an import to the target repository or target directory. These transports can be used as follows: To copy design objects from one ES Repository to another ES Repository. The software component version must be the same in the source and target repository in this case. In this way, you provide the design objects of the ES Repository using export files. Importing ESR Content briefly describes how customers import this ESR content to their ES Repository. To copy configuration objects from one Integration Directory to another Integration Directory. In this way, you can copy a test configuration to a productive landscape.

Prerequisites
You have set up a system landscape with several ES Repositories and Integration Directories. The system landscape usually consists of development systems, consolidation systems and production systems.

PUBLIC 2013 SAP AG or an SAP affiliate company. All rights reserved.

Page 4 of 8

The system terminates the process in certain cases with an error message when you import or transport large object sets. For more information about solving this problem, refer to SAP Note 1004684.

Procedure
1. On the basis of your system landscape consider a transport landscape with which you set out between which systems ESR content or configuration objects are to be transported. 2. Transport the ESR content. More information: Transporting ESR Content

3. Transporting configuration object. More information: Transporting Configuration Objects of the Integration Directory

Objects in the Integration Directory reference objects in the ES Repository. We therefore recommend that you first transport the required ES Repository objects followed by the Integration Directory objects. The configuration is not complete if the Integration Directory references objects in the ES Repository that have not yet been imported. You can also import the missing objects into the ES Repository at a later date.

Further Information
Process Integration Transports PI Transports Using the Change Management Service (CMS) Transporting Objects using CTS

Process Integration Transports

General
When you develop your applications you must differentiate between two types of development objects: Design objects from the ES Repository and configuration objects from the Integration Directory. Objects in the different application systems. These are Java and ABAP classes, client and server proxies generated using proxy generation, ABAP programs, and other development objects that implement the actual application logic. The functions for transporting design and configuration objects described in this section can only be used to transport ES Repository objects or Integration Directory objects. All objects that are developed in the application systems (proxy objects included) must be shipped using their infrastructure. In particular, you must ensure that the objects of your application from the ES Repository are shipped together with the objects of the application system. More information: For more information about the organization and transport of ABAP development objects, see For more information on the organization and transport of Java development projects, see before you transport this data into the productive directory. Change and Transport System Overview (BC-CTS).

Tasks

Integration Directory content is not shipped. The export and import functions in the Integration Directory enable you to test your configuration data in a test directory

A topic that is related to transports is that of release transfer (more information: Transferring Design Objects). This involves the transfer of design objects of different software component versions within a single Enterprise Services Repository.

Transport Support for PI Transports

You can perform ESR content transports and Integration Directory Transports in the following ways: You manually export the contents as a file from the initial system and then import this file into the target system (file system-based transport). Using the Change Management Service (CMS). More information: PI Transports Using the Change Management Service (CMS)

PI Transports Using the Change Management Service (CMS)

General
PUBLIC 2013 SAP AG or an SAP affiliate company. All rights reserved. Page 5 of 8

Use the following tools for PI transports using Change Management Services (CMS). Landscape Configurator - allows you to set up the transport landscape using XI tracks. Enterprise Services Builder - to export ESR content of the development system or of the consolidation system (for emergency corrections) and to track completed transports. Integration Builder for Integration Directory transports - to export configuration contents of the development system or of the consolidation system (for short notice changes) and to track completed transports Transport Studio - to perform transports using CMS: This section focuses on the basic steps and options for CMS transports. More detailed procedures are referenced at the relevant points.

Configuration of the Transport Landscape

CMS supports the defintion of different transport landscapes using the definition of XI tracks in the Landscape Configurator. The following scenarios are supported:

In the case of transport scenarios with linked tracks, the objects versions in PROD1 must be identical to those in DEV2. You can only link XI tracks from different system landscapes (see also: Connecting Tracks); this means if you link two tracks, A and B, a system from track A may not appear in track B. You can enter the systems for both system landscapes in a System Landscape Directory.

PI Transports within a Transport Landscape

In CMS mode, you perform transports using the ES Builder (for design objects) or the Integration Builder (for configuration objects) and the CMS Transport Studio. The tools focus on the following transport areas: Transport Functions in the ES Builder/Integration Builder and Transport Studio ES Builder/ Integration Builder Determining the object set for transport Status Display Resolving conflicts in imports Finding Transports Transport Studio: Importing change requests to the target system (Development, Consolidation, Assembly) Assembling software component versions (Assembly) Quality assurance step (Approval) We will assume that the software component version of the objects that are to be transported is released for transport using the CMS. SAP provides a software component version for the entire content of the Integration Directory.

Transport Entities in ES Builder/Integration Builder

PUBLIC 2013 SAP AG or an SAP affiliate company. All rights reserved. Page 6 of 8

You define the object set of a transport for design objects in the ES Builder and for configuration objects in the Integration Builder. You can transfer either change lists or transport lists to the CMS. Once the change or transport list has been exported from the Integration Builder or ES Builder, it appears as a change request in the Transport Studio.

Change Lists
Both the ES Builder and the Integration Builder collect all changes to objects in a change list. It stands to reason that these are the changes you will want to transport (from the development system, for example). Once you have released the change list, its status changes from Open to Transportable. To transfer it to the CMS, choose Release for Transport in the context menu on the Change Lists tab page. All changes at the time of release are transported in a change list.

Transport Lists
To compile a list of objects independently of change lists, you use the transport wizard to create transport lists. To create a transport list, proceed as follows: 1. Choose Tools Export Design Objects (Enterprise Services Builder) or Tools Export Configuration Objects (Integration Builder). 2. Select the Transport Using CMS mode and determine the object set in the next step.

You can use change lists as a filter when determining the object set in the transport wizard. Objects lists compiled in this way nevertheless have all the normal properties of a transport list. Both the ES Builder and the Integration Builder display the transport list on the Change Lists tab page. This list is transferred directly to the CMS and has the status Waiting for export until the process is complete. Object versions that are active at the time the transport list is compiled are transported in a transport list.

Interaction with the Transport Studio

Within an XI track you can transport objects from a development system (DEV) to a consolidation system (CONS) and then from the consolidation system (CONS) to a productive system (PROD). Both the ES Builder and the Integration Builder offer different options for defining the transport entities depending on the target system: Transport Units by XI Track and Transport Scenario Type of XI Track From DEV to CONS ES Repository Change and transport lists Supported Transport Units (Depending on Transport Scenario) From CONS to PROD Usually: Software component versions (in the Transport Studio) Change and transport lists (emergency corrections in the ES Builder) Integration Directory Transport lists (objects of a party, service, or configuration scenario) Usually: Change lists (after their import and manual release in the Integration Builder or further changes in the consolidation system) You can also create new transport lists. Complete copy (in the Transport Studio; for example, for an initial distribution of the entire directory content) As shown in the table, the usual transport units and the necessary steps depend on the type of the XI track (Enterprise Services Repository or Integration Directory) and the transport scenario. In the CMS Transport Studio, there are a number of tab pages for each track, which you work through one after the other during a transport. The tab page on which your exported change or transport lists are shown depends on the Integration Builder or ES Builder you are working with (development, consolidation, or productive system). The following figure shows the process for the Integration Builder. The process is the same for the ES Builder.

You usually export transport requests from the development system, which appear in the import queue of the Transport Studio for the consolidation system. You control the rest of the transport from here. Exceptions: In the consolidation Integration Directory, change lists are usually generated when changes are imported. You must check and release these change lists in the Integration Builder before you can transport them further with the Transport Studio. If you have to make emergency corrections in the ES Repository of the consolidation system, you export change or transport lists, which appear in the Transport Studio (as in the Directory case). You can then either reassemble the whole software component version (in the Assembly step) or create a package containing just the changes for the productive system. More information: a track. Development Status of the XI Track in the Transport Studio Transporting Design Objects and Transporting Configuration Objects The table below summarizes the transport procedures in the CMS. The sequence of the tab pages in the Transport Studio corresponds to the transport route within

PUBLIC 2013 SAP AG or an SAP affiliate company. All rights reserved.

Page 7 of 8

Step

Tab Page Check-In

Use You use check-in to make archive files with the extension .PRA that you have received from an external source known to the Change Management Service, and make them available for transport through the development landscape. Checked-in archives are added to the import queue on the Development tab page. Integration Builder or ES Builder users do not use this function at present because both tools have their own import function (file systembased import).

Development

This import queue contains checked-in archives and exports from other XI tracks connected to this track (more information: Connecting Tracks). Once a transport request has been exported in the development ES Builder/Integration Builder, this is where the change requests appear for each software component version for import to the consolidation system (ES Repository or Integration Directory). After import in the consolidation system, this is where you assemble transports of software component versions. This tab page displays assembled software component versions. You use this step for quality assurance, to decide which changes to import to the productive system. After approval, the transport is ready for import to the productive system. The corresponding tab page is only displayed if you have entered a productive system in the corresponding track.

1 2 3 4

Consolidation Assembly Approval Production

Transporting Configuration Scenarios

You can transport a configuration scenario together with all the configuration objects assigned to it. This enables you, for example, to transport all the configuration objects belonging to one configuration scenario from a test environment to a productive environment.

Procedure
1. To transport configuration scenarios, define groups of business systems in the System Landscape Directory in which the business systems that have been pre-defined for different areas of use (for example, testing and production operation) are grouped together. For more information, see: Tasks in the System Landscape Directory 2. To ensure configuration content can be imported and exported without any problems, in the System Landscape Directory, you must define (prior to import) which business systems correspond to each other in the various business system groups. For more information, see: Configuring Groups and Transport Targets 3. You can now transport the configuration scenario. Additional Information Transporting ESR Content and Objects of Integration Directory

PUBLIC 2013 SAP AG or an SAP affiliate company. All rights reserved.

Page 8 of 8