BIT480 - PI – Operations(Col74)

7/21/2019 BIT480 - PI – Operations(Col74)

http://slidepdf.com/reader/full/bit480-pi-operationscol74 1/406

BIT480PI – Operations

SAP NetWeaver Process Integration

Date

Training Center

Instructors

Education Website

Participant HandbookCourse Version: 74Course Duration: 3 Day(s)

Material Number: 50089240

An SAP course - use it to learn, reference it for work



Copyright

Copyright © 2008 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose

without the express permission of SAP AG. The information contained herein may be changed

without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software

components of other software vendors.

Trademarks

Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are

registered trademarks of Microsoft Corporation.

• IBM®, DB2®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®, AIX®,

S/390®, AS/400®, OS/390®, and OS/400® are registered trademarks of IBM Corporation.

• ORACLE® is a registered trademark of ORACLE Corporation.

• INFORMIX®-OnLine for SAP and INFORMIX® Dynamic ServerTM are registered

trademarks of Informix Software Incorporated.

• UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group.

• Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®,

VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarks

of Citrix Systems, Inc.

• HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World

Wide Web Consortium, Massachusetts Institute of Technology.

• JAVA® is a registered trademark of Sun Microsystems, Inc.

• JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under license for

technology invented and implemented by Netscape.

• SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP

EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.com

are trademarks or registered trademarks of SAP AG in Germany and in several other countries

all over the world. All other products mentioned are trademarks or registered trademarks of

their respective companies.

Disclaimer

THESE MATERIALS ARE PROVIDED BY SAP ON AN "AS IS" BASIS, AND SAP EXPRESSLY

DISCLAIMS ANY AND ALL WARRANTIES, EXPRESS OR A PPLIED, INCLUDING

WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A

PARTICULAR PURPOSE, WITH RESPECT TO THESE MATERIALS AND THE SERVICE,

INFORMATION, TEXT, GRAPHICS, LINKS, OR ANY OTHER MATERIALS AND PRODUCTSCONTAINED HEREIN. IN NO EVENT SHALL SAP BE LIABLE FOR ANY DIRECT,

INDIRECT, SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES OF ANY

KIND WHATSOEVER, INCLUDING WITHOUT LIMITATION LOST REVENUES OR LOST

PROFITS, WHICH MAY RESULT FROM THE USE OF THESE MATERIALS OR INCLUDED

SOFTWARE COMPONENTS.

g200881711145



About This Handbook

This handbook is intended to complement the instructor-led presentation of this

course, and serve as a source of reference. It is not suitable for self-study.

Typographic Conventions

American English is the standard used in this handbook. The following

typographic conventions are also used.

Type Style Description

Example text Words or characters that appear on the screen. Theseinclude field names, screen titles, pushbuttons as well

as menu names, paths, and options.

Also used for cross-references to other documentation

both internal (in this documentation) and external (in

other locations, such as SAPNet).

Example text Emphasized words or phrases in body text, titles of

graphics, and tables

EXAMPLE TEXT Names of elements in the system. These include

report names, program names, transaction codes, tablenames, and individual key words of a programming

language, when surrounded by body text, for example

SELECT and INCLUDE.

Example text Screen output. This includes file and directory names

and their paths, messages, names of variables and

parameters, and passages of the source text of a

program.

Example text Exact user entry. These are words and characters that

you enter in the system exactly as they appear in the

documentation.

<Example text> Variable user entry. Pointed brackets indicate that you

replace these words and characters with appropriate

entries.

2008 © 2008 SAP AG. All rights reserved. iii



About This Handbook BIT480

Icons in Body Text

The following icons are used in this handbook.

Icon Meaning

For more information, tips, or background

Note or further explanation of previous point

Exception or caution

Procedures

Indicates that the item is displayed in the instructor's

presentation.

iv © 2008 SAP AG. All rights reserved. 2008



Contents

Course Overview ........ ...... ........ ...... ........ ..... ........ ...... .. vii

Course Goals ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .vii

Course Objectives .................................................... viii

Unit 1: SAP NetWeaver PI 7.1 Landscape and OperationConsiderations ....... ...... ........ ...... ........ ...... ........ ....... ..... 1

The Technical Architecture of SAP NetWeaver ProcessIntegration .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Overview - SAP NetWeaver PI Operation Tasks and Tools . . . . . 28Administration of SAP NetWeaver PI Components . .. .. .. .. .. .. . 50Distribution Options of SAP NetWeaver PI Components........ 95

Message Load Considerations..................................... 109

Unit 2: SOA Management – Web Services Configuration &Services Registry ....................................................... 151

Setup Web Service Runtime ....................................... 152

Configuration of Web Services.. .. ... .. .. .. .. ... ... .. .. .. ... .. .. ... 157Services Registry ....................................................169Mass Configuration ... ... .... .... ... .... ... ... ..... ... ... .... ... .... .188

Unit 3: SOA Management – Monitoring. ... .. ... .. .. ... ... .. ... .. .. 201

SAP NetWeaver PI Monitoring Landscape .. .. .. .. .. .. .. .. .. .. .. .203System & Component Monitoring.. ... .. .. ... ... .. .. .. .. ... .. .. ... .228

Monitoring Activities - On Demand or Alerting Based........... 259

Performance Monitoring .... .... ... .... ... ... .... .... ... .... ... ... .. 279

Unit 4: Error Handling and Resolution... ... ... .. .. ... .. ... ... .. .. . 289

Error Detection ....................................................... 290Error Resolution......................................................313

Unit 5: Message and BPE Archiving & TREX Integration...... 327

Message Archiving & Deletion on Integration Server (ABAP) . 328Message Archiving on Adapter Engine (JAVA) ..................342Integration Process Administration (BPE) ........................ 348TREX Integration.....................................................352

Unit 6: Security Aspects . .... .... .... ... .... .... .... ... .... .... .... ... 359

Security Considerations..... .... ... .... ... ... ..... ... ... .... ... .... .360

Adapter-Specific Security ... ... .. .. ... .. .. .. ... ... .. .. .. .. ... .. ... .. 370

2008 © 2008 SAP AG. All rights reserved. v

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-



Contents BIT480

PI User and Tool Security.... .... ... ... .... ... .... .... ... ... ... ..... 374

Unit 7: Software Logistics ..... .... .... .... ... .... .... .... ... .... .... . 381SPS and Patch Procedure.. ..... ... ... .... ... .... .... ... ... ... .... .382

Change Management for SAP NetWeaver PI. .. .. .. .. .. .. .. .. .. .387

vi © 2008 SAP AG. All rights reserved. 2008

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-



Course Overview

BIT480 SAP NetWeaver Process Integration 7.1 – Administration and

Operation allows the user to operate a SAP NetWeaver PI system in a way that is

most beneficial to your enterprise environment.

Through this course, the participants will become familiar with PI landscape

planning considerations, monitoring concepts, and ways of handling PI in case of

error situations. The course provides an overview of the administration tasks in an

SAP NetWeaver PI 7.1 system, which builds a solid foundation for the SAP system

administrator taking care of a SAP NetWeaver PI 7.1system in operation. Since

Process Integration is the entry point for SOA enablement, the course addresses

features of a SAP NetWeaver PI 7.1system to successfully manage servicesavailable in the landscape. In order for the administration staff to be able to keep

the system in a healthy operating state, PI-specific housekeeping tasks as well as

update procedures are laid out. To complete the picture from the operational point

of view, security aspects and software logistic aspects are discussed.

Target Audience

This course is intended for the following audiences:

• Consultants and administrators who want to administrate and monitor an

SAP NetWeaver Process Integration 7.1 system (SAP NetWeaver PI 7.1)

• SAP system administrators responsible for keeping the system in a runningstate at customer site

• SAP operation and maintenance consultants

Course Prerequisites

Required Knowledge

• BIT100 SAP NetWeaver Process Integration – Overview

• BIT400 SAP NetWeaver Exchange Infrastructure

• ADM100 Administration AS ABAP I

• ADM200 Administration AS Java

Recommended Knowledge

• JA100 SAP J2SE Fundamentals

• BIT140 XML in SAP Solutions

2008 © 2008 SAP AG. All rights reserved. vii



Course Overview BIT480

Course Goals

This course will prepare you to:

• Perform the administration and monitoring activities specific to an SAP

NetWeaver PI 7.1 system

• Diagnose performance issues and error situations and determine ways to

resolve these

Course Objectives

After completing this course, you will be able to:

• Explain the architecture and the components of SAP NetWeaver PI 7.1

• Know how which necessary components to need to be set up for a monitoringenvironment

• Know how to monitor the operational state of the system and how to monitor

the processing of messages and service interfaces

• Know how to pinpoint and resolve error situations within the system and

address system performance and message throughput issues

viii © 2008 SAP AG. All rights reserved. 2008



Unit 1SAP NetWeaver PI 7.1 Landscape and

Operation Considerations

Unit Overview

At the conclusion of this unit, you will be able to understand thearchitecture of SAP NetWeaver PI components and have a notion of the

distribution options for planning a whole SAP NetWeaver PI landscape.

You have an understanding of which SAP NetWeaver PI relevant tasks are to be

considered, beside of regular SAP Basis administration tasks.

Unit Objectives

After completing this unit, you will be able to:

• Outline the technical architecture of SAP NetWeaver PI 7.1

• Name the components of an SAP NetWeaver PI 7.1 system• Be aware of SAP NetWeaver PI specific administrative tasks

• Name the tools used for SAP NetWeaver PI system configuration and

maintenance tasks

• Be able to select the appropriate tool for a certain administration task

• Describe which parts of an SAP NetWeaver PI system need to be

administered

• List the administration tasks in the SAP NetWeaver PI system

• Name the components of a SAP NetWeaver PI 7.1 system that can be

distributed throughout the landscape

• Tell if the distribution of SAP NetWeaver PI 7.1 components will benefityour setup

• Know about features of SAP NetWeaver PI addressing high-volume

scenarios

• Recommend resource optimizing features to your PI scenario implementation

team

• Describe the capabilities of the components to leverage certain PI

configuration options

2008 © 2008 SAP AG. All rights reserved. 1



Unit 1: SAP NetWeaver PI 7.1 Landscape and O peration Considerat ions BIT480

Unit Contents

Lesson: The Technical Architecture of SAP NetWeaver ProcessIntegration.... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

Exercise 1: Check URL Information and Installed Usage Types .. . . . . 25Lesson: Overview - SAP NetWeaver PI Operation Tasks and Tools...... 28

Exercise 2: SAP NetWeaver PI Operation Tasks and Tools . . . . .. .. . . . 47

Lesson: Administration of SAP NetWeaver PI Components .. .. .. .. .. .. .. . 50Lesson: Distribution Options of SAP NetWeaver PI Components ........ 95Lesson: Message Load Considerations ... .. .. .. ... .. .. .. ... ... .. .. .. .. ... ..109


http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-



BIT480 Lesson: The Technical Architecture of SAP NetWeaver Process Integration

Lesson: The Technical Architecture of SAP NetWeaver

Process Integration

Lesson Overview

This lesson describes the technical architecture and components of an SAP

NetWeaver PI 7.1 system.

Lesson Objectives

After completing this lesson, you will be able to:

• Outline the technical architecture of SAP NetWeaver PI 7.1

• Name the components of an SAP NetWeaver PI 7.1 system

Business Example

Your company wants to implement SAP NetWeaver PI 7.1. Therefore, a clear

understanding of the technical architecture is needed. As an SAP system

administrator you are responsible for maintaining the system landscape, so you

want to get an overview what the PI system consists of from a technical point

of view.

Introduction

To enable application-to-application processes, SAP NetWeaver provides one

platform to centrally manage the design, configuration, and execution of business

processes.

SAP NetWeaver PI delivers a message- and standard-based integration of

processes within a company by seamless connecting both SAP and non-SAP

applications.

Using SAP NetWeaver PI, you can centrally design, configure, and

execute application-to-application processes (A2A processes) as well as

business-to-business processes (B2B processes) both within and beyond your

company.

The shared collaboration knowledge is based on open standards. This ensures

openness and interoperability for communication with existing integration

solutions and connection to non-SAP applications or third-party systems. SAP

provides content to allow an out-of-the-box integration of SAP solutions with

other SAP or non-SAP applications.

Using one common infrastructure for the integration of business processes

between SAP and non-SAP applications, the complexity of a company’s system

landscape is reduced. This promotes synergies between IT building blocks and

offers the chance to increase the company’s overall performance. In addition,





maintenance costs are reduced by supporting all phases of the solution life cycle.

This means support for configuration and execution as well as the phase of change

at the end of the life cycle.

Relying on SAP NetWeaver, IT organizations are enabled to use standards-based

Web services to form new and innovative business solutions that meet their

changing business needs quickly. In particular, SAP NetWeaver provides

service-oriented architecture (SOA) middleware that facilitates communication

between disparate applications. From a logical point of view, SOA middleware

consists of an Enterprise Services Repository and Services Registry, an

enterprise services bus, and SOA management tools. With SOA middleware, IT

professionals can rely on an open and standards-based platform to accelerate

business integration.

SAP NetWeaver PI is SAP's implementation of SOA Middleware thus SAP

NetWeaver PI is at the heart of an SOA System Landscape.

The following figure shows the building blocks of an SOA Landscape.

Figure 1: Enterprise SOA Infrastructure Building Blocks

SAP NetWeaver Process Integration

The architecture of SAP NetWeaver PI 7.1 is based on an established architecture

for realizing cross-system business processes, and is a further development of

preceding releases (SAP NetWeaver 7.0 usage type Process Integration and

SAP XI 3.0 as part of SAP NetWeaver 2004). SAP NetWeaver PI 7.1 plays an

important role in supporting an service-oriented architecture (SOA). The focus is

on the service-based integration of applications.





SAP NetWeaver PI is based on general standards to enable 3rd-party systems

to be integrated. At the center of SAP NetWeaver PI there is an XML-based

communication that uses HTTP (Hyper Text Transfer Protocol). Regardless of the used scenario, the application-specific contents are transferred in user-defined

XML (eXtensible Markup Language) messages from the sender to the receiver

either directly, or via the Integration Server.

The figure below gives an overview of the key capabilities of SAP NetWeaver PI:

Figure 2: SAP NetWeaver PI – Key Capabilities Overview

SAP NetWeaver PI 7.1 enables the integration of the applications of the following

communication parties:

• B2B Party: Any business partner who wishes to integrate their application

with other applications outside their own system landscape. Scenarios that

require industry standards are supported as well as any scenarios that do not

adhere to a particular industry standard.

• SAP: Applications that run on SAP systems. This includes the processing of

events by using the BAM infrastructure.

• 3rd-Party Application: Applications from 3rd-party providers within one

system landscape, for example database or file system-based.

• 3rd-Party Middleware: Middleware systems from 3rd-party providers that

are required for the integration of applications within a company and across

company boundaries.





SAP NetWeaver PI also supports internal company scenarios and cross-company

scenarios. It enables you to connect systems from different vendors (non-SAP and

SAP) in different versions and implemented in different programming languages(Java, ABAP, and so on) to each other. Like the rest of the SAP NetWeaver

platform, SAP NetWeaver PI is based on an open architecture, uses open standards

(in particular those from the XML and Java environments) and offers services that

are essential in a heterogeneous and complex system landscape.

SAP uses a scenario-based approach that addresses the customer's most important

business issues in a flexible way by providing them with modular industry-specific

solutions, with a fast total return on investment (ROI) and predictable investment

levels that support their end-to-end business processes.

SAP NetWeaver PI represents a particular usage type, selected at installation

time. It determines the capabilities offered by a collection of the installed and

configured (technical) software components specific to the role as a Process

Integration system.

Figure 3: IT Scenarios and Software Units

SAP NetWeaver PI and IT Scenarios

IT scenarios supported by SAP NetWeaver PI address the requirements of IT

management, developers, consultants, and other members of the technical

community, and also demonstrate the capabilities of the technology platform.





IT scenarios help customers, partners, and ISVs to install and operate SAP

NetWeaver PI, to run business applications, including both custom-built and

packaged applications, or to implement a defined IT concept, such as evolving acompany’s system landscape into a service-based architecture.

Figure 4: Evolution towards an SOA-based Business Process Platform

IT scenarios focus on major IT challenges, such as the need to combine different

integration technologies, to develop composite applications leveraging existinginvestments, or to build new business processes in a flexible way. Business

Process Management is a typical example of an IT scenario in this context.

An IT scenario consists of multiple IT processes which are grouped into scenario

variants. Implementation guidance is provided by reference models and the

visualization of end-to-end-processes.





SAP NetWeaver PI can be used to carry out various IT scenarios:

• Enabling Application-to-Application processes

By enabling application-to-application processes, organizations can

seamlessly connect SAP and non-SAP applications within the enterprise,

orchestrating the process flow between them using message-based and

standards-based methods for process integration. Using SAP NetWeaver PI,

a single platform can manage the design, configuration, and execution of

all business processes within the heterogeneous system landscape of an

enterprise.

• Enabling Business-to-Business Processes

Organizations can seamlessly connect their own business processes with

those of their partners using message-based and standards-based methodsfor process integration. SAP NetWeaver PI supports various communication

channels as well as process coordination and surveillance.

• Business Process Management

Business process management (BPM) with SAP NetWeaver PI covers

business process modeling, configuration, execution, and monitoring, with

process models executed by either the business applications or the central

integration server. Organizations can use predefined content to configure

business processes and can relate application-embedded settings to business

process models.

• Enabling Enterprise ServicesWith SAP NetWeaver PI, organizations have a single infrastructure for

uniform service definition, implementation, and usage based on Web

services technology and standards. SAP NetWeaver PI supports enterprise

services for user interaction as well as application-to-application and

business-to-business interactions using synchronous, asynchronous, stateful,

and stateless communication models.

Software Units

SAP NetWeaver delivers software units which are to be installed on hosts within

an IT landscape. These software units are systems, standalone engines and clients.





SAP systems are the main building blocks of SAP NetWeaver. They are identified

by unique SAP system IDs (SAPSIDs) and configured for a certain purpose,

as indicated by usage types. SAP NetWeaver PI comprises the usage typesApplication Server ABAP (AS ABAP), Application Server Java (AS Java), and

Process Integration (PI).

• AS ABAP is used to provide the ABAP foundation of SAP NetWeaver

PI. Application Server ABAP provides a complete development and

runtime environment for ABAP-based applications. It is optimized for

the development of highly scalable business applications. The ABAP

development and runtime environment makes it possible to develop complex

business applications, without having to worry explicitly about technical

details, such as process or memory administration, multi-user capability,

database connections, or similar issues. These are provided in the basis

services or are integrated directly in the ABAP runtime. The applicationdevelopment is similarly independent of the underlying platform. The

application server decouples the application coding completely from the

operating system and database in use.

• AS Java is used to provide the Java foundation of SAP NetWeaver

PI using the Java Engine, a Java EE-compliant application server for

running enterprise applications. In addition to the pure Java EE standard

technologies, the Java Engine implements complementary technologies, such

as Web Dynpro or Web Services that are targeted at supporting large-scale,

real-business application development projects.

• PI consists of core components that model, design, automate, and integrate

processes in one or more application systems. For the integration of internal and cross-company processes, PI is used to incorporate all the

functions of what was formerly known as Exchange Infrastructure (XI). In

addition, PI contains core components for Business Process Management for

application-embedded and application-unbounded processes. The Advanced

Adapter Engine is also part of usage type PI. You use Advanced Adapter

Engine to connect to SAP systems (RFC adapter) and external systems.

You use the various adapters in Advanced Adapter Engine to convert XML

and HTTP-based messages to the specific protocol and format required

by these systems, and the other way around. You can use the Advanced

Adapter Engine that is part of your PI system as a central Advanced Adapter

Engine. Optionally (for performance reasons), you can install a non-centralAdvanced Adapter Engine separately as a system with AS Java and parts of

the usage type PI on a separate host.

Standalone engines of SAP NetWeaver are additional installable software units.

They do not work as full-blown systems of SAP NetWeaver, but as standalone

engines that provide a specific (server) functionality in combination with one or

more SAP NetWeaver systems.





In conjunction with SAP NetWeaver there are several standalone engines available

such as Gateway, Search and Classification (TREX), Web Dispatcher, Advanced

Adapter Engine, Adapter Engine (Java SE), and the SAP Partner Connectivity Kit.

• On a Gateway instance there are no normal work process types (dialog,

background, update, enqueue, or spool). Only the gateway process (gwrd)

is started. If there is an SNA connection to an R/2 system, gateway work

processes (gwwp) are also started. In this way, it is possible to install an SAP

instance of an SAP NetWeaver system based exclusively on a standalone

gateway.

• You can use Search and Classification (TREX) to search for indexed

messages on an SAP NetWeaver PI system. Message search using an index

provides additional methods of searching for specific messages. If the

messages are indexed, you can also use adapter-specific message attributes

and data from the message payload for the search in addition to search forstatic header attributes. You can apply the index-based message search to one

or all indexed components of an integration landscape domain: Integration

Server, Adapter Engines, and ABAP business systems.

• The SAP Web Dispatcher resides beneath the Internet and your SAP system.

It is the entry point for HTTP(s) requests aiming at your system, which may

consist of one or more SAP NetWeaver application servers. As a "software

web switch", the Web dispatcher can reject or accept connections. When it

accepts a connection, it balances the load to ensure an even distribution of

requests between the servers. You can use the Web dispatcher in ABAP/Java

systems and in pure Java systems, as well as in pure ABAP systems.

Set aside security aspects (i.e. entry point in the DMZ, SSL, URL filtering),

you can use the Web dispatcher simply as a load balancer between multiple

SAP NetWeaver Application Server instances. Since the Web Dispatcher is

optional for every SAP system, it is not contained in the system landscapes

and the implementation sequences of the IT scenarios.

• The Advanced Adapter Engine is used to connect to SAP systems (RFC

adapter) and external systems. You use the various adapters in the Advanced

Adapter Engine to convert XML and HTTP-based messages to the specific

protocol and format required by these systems. For specific sender/receiver

combinations, messages can be processed without invoking the central

Integration Engine. In principle, you connect external systems using theadapters that are installed centrally or non- centrally in the Advanced

Adapter Engine. You can use the Advanced Adapter Engine that is part

of your PI system as a central Advanced Adapter Engine. Optionally (i.e.

for performance reasons), you can install a non-central Advanced Adapter

Engine separately as a system with AS Java and components of the usage

type PI on a separate host.

• The (plain) Adapter Engine (Java EE) is a separate software unit. You

can only use it if you have SAP NetWeaver systems with usage type PI in

your system landscape. It has to be installed manually. You use Adapter





Engine (Java SE) to connect to external systems. Using the various adapters

in Adapter Engine (Java EE), XML and HTTP-based messages can be

converted to the specific protocol and format required by such systems.Adapter Engine (Java EE) only provides some of these adapters as a

standalone version with restricted functions for operating systems that do

not support SAP NetWeaver PI 7.1, but that do have at least a Java Runtime

Environment 5.0. Therefore, you should only use the Adapter Engine (Java

EE) if the platform prerequisites do not allow you to use the Advanced

Adapter Engine.

• The Partner Connectivity Kit (PCK) runs on AS Java with parts of the usage

type PI. It enables a system of a smaller company or subsidiary that does not

run SAP NetWeaver PI to connect to your SAP NetWeaver systems.

Clients are additional installable programs or tools. They either reside on local

front-end PCs accessed by users or on back-end systems where they act as clientprograms within an SAP NetWeaver system landscape.

SAP NetWeaver PI provides a number of front-end clients and tools including

SAP GUI and SAP NetWeaver Developer Studio.

For the APAP part of the SAP NetWeaver PI system, SAP offers three different

client applications for accessing ABAP applications: SAP GUI for HTML, SAP

GUI for Java, SAP GUI for Windows.

The SAP NetWeaver Developer Studio is SAP’s Integrated Development

Environment (IDE) for Java and is based on the open-source tools framework

Eclipse 3.3. With the SAP NetWeaver Developer Studio, you can develop Java

EE 5 applications from scratch using the built-in support for new technologies,such as EJB 3.0 and JSF 1.2.

Architecture Overview

The SAP NetWeaver PI system architecture includes components that are used

at design time, configuration time, and runtime. Information about the systems

and software components used in an integration scenario are stored in the System

Landscape Directory.

The Enterprise Services Builder and the Integration Builder are the tools for

accessing the design and configuration-time components. Developers and

configurators use these to access the Enterprise Services Repository and Registryand the Integration Directory.

The Enterprise Services Repository is the central repository where models and

enterprise services are modeled and their metadata is stored.

The Integration Directory is used to work with all of the configuration options for

an integration scenario in the SAP NetWeaver PI system.





Figure 5: Architecture Overview of an SAP NetWeaver PI System

The Integration Server provides the runtime environment for processing messages

received by the SAP NW PI system. It includes the following components:

• The Business Process Engine for executing Integration Processes

(cross-component business processes)

• The Integration Engine for processing all messages for all scenarios in aconsistent way

• The Central Adapter Engine for connecting to application systems that are

not based on the SAP Web Application Server version 6.20 or higher

The PI Monitor (NWAPI) and Runtime Workbench are used for central monitoring

and management of the SAP NetWeaver PI and all of its components.

Design Components

Pre-delivered integration content for SAP solutions open for collaboration

knowledge of non-SAP systems, using open standards (e.g. WSDL) provision for

customers/partners to enhance PI design time objects Java-based graphical tools

Overview of the design components in an SAP NetWeaver PI system.





Figure 6: The Enterprise Services Builder with its ESR

Configuration Components

Within SAP NetWeaver PI, the following options and possibilties for the

configuration and handling of the components are offered.

Adapt integration content to specific configuration

Derive integration content from Enterprise Services Repository

Open for customer to add collaboration knowledge relevant to non-SAP

components

Java-based graphical tools

Central configuration for B2B processes

BPM centralized adapter configuration





Figure 7: Overview of the Configuration Components in an SAP NetWeaver

PI 7.1 system

The Enterprise Service Builder contains the Enterprise Services Repository

(ESR) and Services Registry. The ESR is the central repository in which service

interfaces and enterprise services are modeled and their metadata is stored. It

is an integral part of SAP NetWeaver.

The repository is open for customers and partners to also enrich this content with

additional services that they would need for their own use. So, if you look at

the ESR in some more detail you see that there are two parts: the ESR and the

Services Registry. The ESR is really the master data repository of service objects

for Enterprise SOA. What do we mean by “Design Time Repository”? This refers

to the process of designing services.

Additionally, the ESR supports the whole process around contract first or the

well known outside in way of developing services. It provides you with a central

modeling and design environment which provides you with all the tools and

editors that enable you to go through this process of service definition. It provides

you with the infrastructure to store, manage, and version service metadata.

Besides service definition, the ESR also provides you with a central point

for finding and managing service metadata from different sources, including

application deployments – this is where the Services Registry comes in. The

Services Registry is the UDDI part of the ESR which enables service consumers

to find services. Once these two components are in place, visibility is controlled,

versions are managed, proposed changes are analyzed and communicated, usage is

monitored; other parts of the SOA foundation can thus access service metadata.





Figure 8: Enterprise Services Repository and Services Registry – Overview

The ESR evolved from the Integration Repository. It stores objects, such as global

data types (GDTs) and service interfaces. It allows re-use of existing data and

leverages existing investment. It also stores new and enhanced objects, such as

process component models and service interfaces.

Figure 9: Enterprise Services Repository evolved from the Integration

Repository

The Enterprise Services Repository and Registry has several usage scenarios:

• Process Visibility and Design Governance

• Service Provisioning

• Process Integration

• Composition





Process Visibility and Design Governance enables for SOA design governance.

There are Process Component architecture models in the Enterprise Services

Repository which can be used to drill down to standards based service interfacedesign.

Service Provisioning delivers service metadata. This can be used to model

message interfaces and service interfaces based on GDTs. Using the ESR, the

service metadata is stored in one central repository.

Process Integration is used for enabling A2A and B2B processes. The services

defined in ESR can be accessed for consumption in A2A and B2B scenarios.

The composition scenario refers to the possibility of developing composite

applications. Consumer applications may query the Services Registry for services

that were designed in the ESR.

Figure 10: Enterprise Services Repository Usage Scenarios

The Adapter Framework

The Integration Server processes messages that are received in the XI-SOAP

format; systems that are capable of producing messages in this format (forexample, mySAP components based on SAP Web Application Server v. 6.20 or

higher) can communicate natively with PI. All other systems, including older SAP

releases, communicate through adapters. The Central Adapter Engine is based on

the integrated SAP J2EE engine. It includes functionality for message handling,

queuing, and security. There is an included module processor that lets you extend

the basic functionality of adapters by calling additional modules for processing

messages in the adapter. Individual resource adapters are “plugged in” to the

adapter framework. These can be delivered by SAP, or developed by partners or

customers using the Java Connector Architecture. Some adapters are built into





the Application Server ABAP; for instance, the IDoc adapter is part of the ABAP

layer, and all IDocs are processed by the IDoc Adapter. For any IDocs that you

wish to process at the ALE layer of the Integration Server, you must maintainan exception table that specifies which IDocs are processed in the normal way.

Further adapters residing on the ABAP stack are the XI (Plain) Adapter and the

WS (WS-RM) Adapter.

Additional adapters based on the J2EE framework can be installed non-centrally,

and can be configured and monitored centrally.

The resource adapters that are available with the Adapter Framework (Application

Server JAVA) include:

• RFC Adapter

• JDBC Adapter

• JMS Adapter

• Marketplace Adapter

• SAP BC (header extension for support of Quality of Service)

• RosettaNet (RNIF 2.0) Adapter

• CDIX (RNIF 1.1) Adapter

• File/FTP Adapter

• SOAP Adapter

• Mail Adapter

PI includes extensive and growing B2B support for communication with business

partners using industry standards such as RosettaNet, CIDX, PIDX, and UCCNet.Collaboration agreements in the Integration Directory configure B2B scenarios,

including aspects such as certificate handling, partner ID, and so on.





Figure 11: The Architecture of the Adapter Framework

Business Process Engine

Integration Processes are Business Processes that can run across multiple systems

and are expressible in the standard web protocol for Business Process execution,BPEL4WS (Business Process Execution Language for Web Services). You will

also see Business Processes referred to as Business Process or cross-component

Business Processes in the documentation. If you are familiar with SAP Business

Workflow, then you can think of these Business Processes as workflows that run

across multiple components. The Integration Server includes a built-in Business

Process Engine.

It includes:

• A persistence layer (the process/message store)

• The runtime for process execution

• The logic for correlation handling

Business Processes allow you to send and receive multiple messages relating to a

single document; for instance, line items for a purchase order may be gathered

from several sources. Correlations let you relate the incoming documents to a

unique key, for instance a PO number so that incoming documents are processed

only with the master document to which they belong.





Figure 12: Cross-component Business Process Management with the

Business Process Engine

System Landscape Directory

SAP System Landscape Directory (SLD) is a central information provider that

contains two sorts of information about landscape topology:

• Landscape description (catalog of physical and logical systems in the datacenter)

• Component information (description of all software products from SAP

and other vendors)

PI components are client applications to SLD; for instance, an integration engine

can determine its role by reading it from the System Landscape Directory. SAP’s

Solution Manager is another client application to SLD. SLD is populated with data

about SAP software by SAP; that is, an administrator uploads a file to the SLD

that contains the description of all currently supported SAP products and software

components. ABAP and Java systems in the system landscape register themselves

automatically by using data suppliers. Customers are then to add entries for

non-SAP products and software components. Additionally, other vendors that

support the CIM model can provide software descriptions of their products. You

can access SLD by pointing a browser to http://<full qualified hostname>:<HTTP

port> /sld. You will be prompted for a user name and password.





Figure 13: System Landscape Directory in the PI Landscape

The SAP NetWeaver PI 7.1 system can run against an SLD 7.0 or a SLD 7.1

installed and configured on the together with an SAP NetWeaver PI 7.1 system.

This course does not cover SLD specific landscape considerations. If you need

more information and help regarding the SLD planning, please refer to the SLD

Planning Guide available on the SDN at https://www.sdn.sap.com/ir j/sdn/nw-sld.

SLD related administration tasks consists of regularly updating the CIM modeland SAP Component Repository (SAP CR content). Important information about

the necessary administration steps are explained in SAP Note 669669 - Updating

the SAP Component Repository in the SLD.

Monitoring Components

Monitoring a system landscape is a complex task of significant importance for

every company that operates one or more SAP systems. The complexity increases

with every additional system, component, or extension.

With the monitoring architecture of the Computing Center Management System

(CCMS), SAP provides a flexible and universally usable infrastructure with which

you can monitor your entire IT landscape centrally, and which reports problems

quickly and reliably.


https://www.sdn.sap.com/irj/sdn/nw-sld








Figure 15: Solution Manager Plays a Central Role in the Monitoring

Landscape

Looking at the big picture, the SAP Solution Manager is the central platform

for managing your SAP System Landscape. It provides means for alerting you

proactive with real-time monitoring before problems become severe.

Looking solely at Process Integration it also offers several central monitoring

tools, which permit the administrator to get a central view of all components and

messaging of the PI System. Architectural components include:

• Computing Center Management System (CCMS)

• Process Monitoring Infrastructure (PMI)

• Alerting Framework

The Runtime Workbench allows an administrator to access central monitoring

information for all components as well as configuration for the monitoring

architecture.





Figure 16: Monitoring Components









Exercise 1: Check URL Information and

Installed Usage TypesExercise Objectives

After completing this exercise, you will be able to:

• know how to determine the necessary URL parts

• know how to check for installed usage types on your system

Business Example

Task:

Execute the following steps in the training system.

1. Call transaction SMICM and check HTTP port and full qualified hostname

information.

2. Call URL consisting of http:<full qualified hostname>:<HTTP Port> with

suffix /utl/UsageTypesInfo.





Solution 1: Check URL Information and

Installed Usage TypesTask:

Execute the following steps in the training system.

1. Call transaction SMICM and check HTTP port and full qualified hostname

information.

a) SMICM → Button: Services

2. Call URL consisting of http:<full qualified hostname>:<HTTP Port> with

suffix /utl/UsageTypesInfo.

a) When you call the URL on your training system, you should see thefollowing usage types information:

Active Usage Types

Product Name UT Code Short Name Description

SAP

NetWeaver

2007

PI PI Process

Integration

SAP

NetWeaver2007

AS AS Java Application

Server Java

SAP

NetWeaver

2007

AAS AS ABAP Application

Server ABAP





Lesson Summary

You should now be able to:• Outline the technical architecture of SAP NetWeaver PI 7.1

• Name the components of an SAP NetWeaver PI 7.1 system





Lesson: Overview - SAP NetWeaver PI Operation Tasks

and Tools

Lesson Overview

This lesson introduces the mandatory administrative tasks and tools required for

SAP NetWeaver PI Operation.

Lesson Objectives


• Be aware of SAP NetWeaver PI specific administrative tasks

• Name the tools used for SAP NetWeaver PI system configuration andmaintenance tasks


Business Example

A SAP NetWeaver PI system has recently been installed in the system

landscape of your company. You, as a system administrator, want to

know which additional SAP NetWeaver PI relevant tasks are needed.

And you are interested to know which tools are available for system maintenance

and operational tasks, and you want to know which tools are necessary for what

type of task.

Overview of Administrative Tasks

We assume that your SAP NetWeaver PI 7.1 system is installed and

configured based on the necessary Post Installation tasks. Information

about operation tasks and descriptions is rovided by SAP in the

the Technical Operations Manual (TOM) that can be accessed

in the SAP library at http://help.sap.com/saphelp_nwpi71/help-

data/en/45/dc863f455f3417e10000000a114084/frameset.htm.


http://help.sap.com/saphelp_nwpi71/helpdata/en/45/dc863f455f3417e10000000a114084/frameset.htm

http://help.sap.com/saphelp_nwpi71/helpdata/en/45/dc863f455f3417e10000000a114084/frameset.htm



BIT480 Lesson: Overview - SAP NetWeaver PI Operation Tasks and Tools

A dedicated section is available for PI specific

tasks at http://help.sap.com/saphelp_nwpi71/help-

data/en/57/08bb3f23823c17e10000000a114084/frameset.htm

• Monitoring Tasks

– Component Monitoring

– Performance Monitoring

• System Management Tasks

– Starting and Stopping of System(s) , Instances, and failing messages

– Backup and Restore

– Archiving and Deletion of Messages

• Troubleshooting PI Messaging

– Error Detection

– Error Resolution

• Software Logistic

– Release and Upgrade management

– Transport and Change management

For monitoring, archiving and deletion of messages, troubleshooting and software

logistics we have dedicated units to come. In this unit we will introduce shortly the

available operation relevant tools and provide you with an basic understanding of

which tasks should be considered on a daily, weekly or only if necessary activityto be covered by our SAP NetWeaver PI operations organization.

Introduction - SAP NetWeaver PI Tools

The SAP NetWeaver PI tools page provides a central entry point to access the

several components of the SAP NetWeaver PI system:


http://help.sap.com/saphelp_nwpi71/helpdata/en/57/08bb3f23823c17e10000000a114084/frameset.htm

http://help.sap.com/saphelp_nwpi71/helpdata/en/57/08bb3f23823c17e10000000a114084/frameset.htm




Figure 17: SAP NetWeaver PI Tools Startscreen

• Enterprise Services Builder and the Services Registry (accessed using the

Enterprise Services Repository)

• The Integration Builder (accessed using the Integration Directory)

• The System Landscape Directory• The SAP NetWeaver PI Monitor (Link: NetWeaver Administrator) and

Runtime Workbench

To access the SAP NetWeaver PI tools, you can use transaction SXMB_IFR from

the SAP GUI. Alternatively, you can navigate in a browser window directly to

the URL http://hostname:port/dir/start/index.jsp. In this case, hostname is the

fully-qualified name of the Integration Server, and port refers to the http port of

the address of the Integration Server (ICM).

To access the Java components for NetWeaver SAP NetWeaver PI 7.1, you need an

SDK (Java 2 Software Development Kit), version 1.5 or higher, on the front end.

The SDK installation includes the installation of Java Web Start (JWS). JWS isa caching application for fat Java clients. The Enterprise Services Builder and

the Integration Builder applications are each approximately 20-30 MB in size,

therefore they have to be cached in the local machine's memory, to prevent them

from being downloaded every time they are called.

The following figure gives an overview of the components accessed through the

SAP NetWeaver PI tools.





Figure 18: Components Directly Accessible Through the Start Screen

Enterprise Services Builder

The Enterprise Services Builder is a Java application that is used to design and

edit SOA objects, such as models, interface services.

Figure 19: Enterprise Services Builder Gives Access to the Enterprise

Service Repository





The Enterprise Services Builder provides the tool for the design time SAP

NetWeaver Process Integration. Its capabilities include:

• Navigation and object handling

• Drag&Drop editing

• Versioning and history

• Selection (F4) help

• Un-docking and docking of editors

• Editing documentation

• Importing and exporting objects

Changes are saved locally to user-specific change lists. Upon activation of the

change list, an activation check is performed and, if passed, the objects are created

in their active version on the Integration Server, and the cache of the IntegrationServer is updated.

The ES Repository provides a comprehensive metadata repository that can be used

for SOA provisioning. Objects in the ES Repository include:

• Integration scenarios

• Process component models

• Service interfaces (Enterprise Services)

• Global data types (based on core component technical specification)

• Interface mappings

• Executable integration processes (BPEL)





Figure 20: Enterprise Services Repository - Objects

Services Registry

A registry is usually identified as one of the first requirements of SOA adoption,

and registries play an important role in governance. In simple terms, a registry

is a catalog or index that acts as the “system of record” for the services within

an SOA. A registry is not designed to store the services themselves; rather, it

indicates their location by reference.

Having a centralized catalog of services is significant from an organizational

perspective because it enables the easy discovery, reuse, and management of

services.





Figure 21: The Service Registry Start Page

Registry capability adds location information to the Enterprise Services Repository

necessary for consumption (UDDI standard). A single source for discovery

enables simple mass configuration and runtime governance. The taxonomy puts

services in a business context.

There are two communication scenarios: P2P and brokered communicationP2P is used if services within backends can communicate directly; if additional

integration services are required, then brokered communication through the

SAP NetWeaver PI Runtime (Integration Server) is used. For all service related

communications the same Service Runtime is used.

The Service Registry can be accessed through the SAP NetWeaver PI Tools start

page or directly by calling http://<full qualified hostname>:<HTTP port> /sr.

Integration Builder

The Integration Directory is accessed by means of the Integration Builder, which

is used for carrying out configuration time activities. It has the same look andfeel as the Enterprise Services Builder.







The following are the main functionalities available in SAP NetWeaver

Administrator for PI:

• Message monitoring

• Performance monitoring

• Cache monitoring

• Alert inbox/rules

• End-to-end monitoring

• Adapter monitoring

• Communication channel monitoring (Adapter Engine)

• Sequence monitoring

• Web service logging and tracing

It can be reached through the SAP NetWeaver PI tools start page or directly by

calling http://<full qualified hostname>:<HTTP port> /nwapi.

Figure 23: SAP NetWeaver Administrator for PI

Note: Here we solely describe the NWAPI, as it is a tool specific for the

SAP NetWeaver Process Integration. We describe the SAP NetWeaver

Administrator as the more general tool for administration in the following

lesson.





Before you can use the SAP NetWeaver Administrator for PI, some configuration

settings need to be performed. The SLD must contain the systems and

components, basic CCMS configurations must exist in your system landscape.Further configuration is done with the help of the SAP NetWeaver Administrator

Configuration Wizard.

The administrator has to execute the configuration template from: SAP NetWeaver

Administrator → Configuration Management → Scenarios → Configuration

Wizard

The exact configuration steps can be found under SAP NetWeaver Process

Integration Library → Administrator's Guide → Configuration of SAP NetWeaver

→ Configuration of SAP NetWeaver Systems → AS Java Configuration →

Configuration Wizard → Wizard-Based Configuration of the NWA → Configuring

the Central NWA.

SAP Notes 1122868, 1160261 and 1115280 include more details about the

necessary configuration steps to run the SAP NetWeaver Administrator for PI. We

recommend to wait until official release of NWA for PI (currently planned with

SAP NetWeaver PI 7.1 enhancement package 1 earliest).

Figure 24: Execute Configuration Wizard Templates to Setup the SAP

NetWeaver Administrator for PI Monitor





The Runtime Workbench is still available through the start page and currently

contains functionality, that is now yet available with NWAPI. It is mentioned here

to underline that both the NWAPI and the RWB address an mostly equal set of functionalities, but the focus will be set on NWAPI for administration purposes in

upcoming SPs of SAP NetWeaver PI.

Figure 25: The Runtime Workbench (RWB)

Further Tools and Configuration Components

There are various components of the SAP NetWeaver PI that are not or not

fully covered by the central tools. Several tools are available to access these

components.

The System Landscape Directory is a central repository of information about

software and systems in the data center called the Common Information Model

(CIM).

The SLD can be accessed via http://<full qualified hostname>:<HTTP port>/ sld.





Figure 26: System Landscape Directory Start Screen

The Exchange Profile is an XML document that is stored in the main database

of the SAP NetWeaver Process Integration. The parameters contained in this

document define some basic technical settings. Most of them are initialized

automatically during the installation phase, but in some cases the administrator

may need to maintain them.

The SAP NetWeaver PI provides a maintenance interface for this file. The

maintenance screen for the Exchange Profile can be accessed at:

SAP NetWeaver PI Tools page→

Administration→

Repository Tab; Properties

Administration→

Exchange Profile.

Settings that are maintained in the Exchange Profile include connection parameters

such as hostnames, ports, users, and passwords that allow the various components

of the SAP NetWeaver PI to communicate.





Figure 27: Exchange Profile maintenance interface

The Integration Server is used primarily to process XI messages. The Integration

Engine is the runtime engine for XI messages. The Integration Engine processes

messages that are rendered in the special XI-SOAP format.

It is important to distinguish between the terms Integration Engine and Integration

Server. The Integration Engine running on the central Process Integration system

is configured as the Integration Server. The other Integration Engines runningon different Application Systems are acting as clients communicating with the

Integration Server with XI messages.





Figure 28: Integration Server Components

Transaction SXMB_ADM is the entry transaction to various configuration and

administration possibilities.

Figure 29: SXMB_ADM for Integration Server and Application System







Figure 31: Transaction SXI_CACHE

Out of the PI configuration tools page (http://<full qualified hostname>:<HTTP

port>/dir) the cache status can be checked by selecting Administration and

selecting the tab Repository or Directoryand navigating down to Lock and Cache

Administration → Data Cache Overview.

For general administration purposes, further tools are used. There may be tasks

such as adding or deleting of additional server processes. The configuration of

thread pool sizes and thresholds are examples of advanced administration tasks.





Figure 32: SAP AS Java: Config Tool and Telnet Console

The main tools for these basis administration and configuration tasks on operating

system and database level are the Config Tool and the Telnet Console. The Config

Tool is a Java application that has to be started locally on the host of the SAPNetWeaver PI system. The Telnet Console is a connection via the telnet protocol

accessing the Java Application Server on port 5XX08 (XX has to be filled in wit

the system number). In the figure above, you can see screenshots of these tools.

These are mentioned for reasons of completeness. For a detailed explanation of

these tools, refer to course ADM200 Administration AS Java.

For system oriented operation the SAP Management Console (SAP MC) provides

a common framework for centralized system management. It allows you to

monitor and perform basic administration tasks on the SAP system centrally, thus

simplifying system administration. Starting with SAP NetWeaver 7.1 the SAP MC

is available as a Java applet that can be run from any Web browser supporting Java.

Thus, you can administer remote systems without needing a local installation.To be able to start the SAP MC applet make sure that you have fulfilled the

following requirements:

• You have Java Runtime Environment (JRE) 1.4.2 or higher installed.

• Your Web browser supports Java.

• Your Web browser’s Java plug-in is installed and activated.





In your Web browser, execute the following URL: http://hostname:5xx13. For

example, if the instance number is 60, in this case the port is 56013. This starts the

SAP MC Java applet.

Figure 33: SAP Management Console - Java Applet









Exercise 2: SAP NetWeaver PI Operation

Tasks and ToolsExercise Objectives


• get familiar with the NetWeaver Administrator for PI

• start up the SAP Management Console

• check the CIM model version and the CR version on your SLD

• check the existing parameters of category MONITOR - Integration Engine

Configuration

Business Example

Get familiar with various tools.

Task:

[Enter a high level description of the task the learner will perform in this exercise.]

1. Start the NetWeaver Administrator for PI from the Tools page nad browse

around.

2. Start the NetWeaver Administrator for PI directly in the Internet Browser

via suffix /nwapi.

3. Start the SAP Management Console for stack administration of the training

system.

4. Open the SLD and navigate to the Administration part to check which

CIM model version and CR versionl is installed on the SLD assigned to

the training system.

5. Check with transaction SXMB_ADM the Integration Engine Configuration

- Category MONITOR.





Solution 2: SAP NetWeaver PI Operation

Tasks and ToolsTask:

[Enter a high level description of the task the learner will perform in this exercise.]

1. Start the NetWeaver Administrator for PI from the Tools page nad browse

around.

a) Logon via SAPGUI to the training system and call transaction

SXMB_IFR. Start NetWeaver Administrator under Configuration and

Monitoring.

2. Start the NetWeaver Administrator for PI directly in the Internet Browser

via suffix /nwapi.

a) URL: http://<full qualified hostname>:<HTTP port>/nwapi

3. Start the SAP Management Console for stack administration of the training

system.

a) URL: http://<full qualified hostname>:5xx13 with xx = Instance

Number.

4. Open the SLD and navigate to the Administration part to check which

CIM model version and CR versionl is installed on the SLD assigned to

the training system.


SXMB_IFR. Start System Landscape Directory under System

Landscape. . Alternative you can call the URL with suffix /sld directly.

Goto Administration.Select Server →

Details.Select tab Data. Here

you will find the Model Version (3.1.4) and the CR content version

(1.5.32 and SAP_CR 4.3)

5. Check with transaction SXMB_ADM the Integration Engine Configuration

- Category MONITOR.


SXMB_ADM. Select Integration Engine Configuration. Choosecategory MONITOR and press button Configuration.

Check the existing entries and get familiar with the available parameter

information by pressing the in front of the parameter. Check the

possible values for the parameters.





Lesson Summary

You should now be able to:• Be aware of SAP NetWeaver PI specific administrative tasks

• Name the tools used for SAP NetWeaver PI system configuration and

maintenance tasks






Lesson: Administration of SAP NetWeaver PI

Components

Lesson Overview

This lesson gives you the knowledge of the components, tools and the specific

tasks which are part of PI administration.

Lesson Objectives


• Describe which parts of an SAP NetWeaver PI system need to be

administered• List the administration tasks in the SAP NetWeaver PI system

Business Example

There are several components of a PI system that require administration. As a

system administrator you need to have an understanding of these components

and the tasks to be performed.

Administration with the SAP NetWeaver Administrator

SAP NetWeaver Administrator (NWA) is a tool for administration and monitoring.

The NWA combines the most important administration and monitoring tools for

Java and ABAP systems in a browser-based user interface.

You can start the NWA using the following URL: http://<full qualified

hostname>:<HTTP port>/ nwa




BIT480 Lesson: Administration of SAP NetWeaver PI Components

Figure 34: SAP NetWeaver Administrator

The NWA categorizes following features:

• Administration

Starting and stopping systems, instances, services, and applicationsUser administration

• Technical Configuration

• Monitoring

System and Component Monitoring

Log information

• System Analysis

Performance analysis

Application trace and performance trace

The NWA is used to administer one particular system and is therefore bound

to a certain host.

Note: The current version of the NWA does

not allow the administration of ABAP systems.

The monitoring functions can be used for ABAP and Java

systems.





The interface allows for the seamless navigation to other SAP NetWeaver

administration tools (User Management Engine, also System Landscape Directory

and Adaptive Computing).

The management functions included in the SAP NetWeaver Administrator are

grouped in work centers according to the type of functionality that they provide.

The following work centers (represented as tabs) are available:

• Operation management

• Configuration management

• Availability and Performance Management

• Problem management

• SOA management

In the Operation Management work

center, the following functions are available:

Users and Access (Identity Management)

Systems (instance information display, start and stop functions)

Data and Databases (Java Archiving tasks)

Jobs (Access to the Java Scheduler)

The Configuration Management work center includes the following options

for configuring your system:

Virtual Host Configuration (create new virtual hosts and configure existing

ones for your system)

Managing Login Modules

Managing Authentication Policy for AS Java

JMS Server Configuration (view and manage JMS provider server

configurations)

Java System Properties (view the system properties)

Viewing Application Modules’ Configuration (contains details of the

deployed applications and modules)

Application Resources Management (create and configure Application

resources)

UDDI Server Configuration

Web Services Configuration (information about the configuration of Web

services and Web service clients)





Figure 35: NWA Operation Management & Configuration Management

In the Availability and Performance Management area in the NWA, you canmonitor different system information relevant for the system operation.

• Java System Reports

• Log Viewer

• Locks





The Problem Management section of the NWA includes the following

administration options:

• Java Class Loader Viewer

• JNDI Browser

• Log Viewer

For systems 7.1, you can use the SAP Host Control Agent. It gives you

the ability to:

View ABAP log messages

Manage with debugging

Control the amount of displayed log data

Filter and view logs and traces

Search log and trace records

Merge list-formatted logs and traces

View archives of logs and traces

Create your own custom views to view a certain set of log records

Import and export custom views

• Log Configuration

In the SOA Management section the following features can be found:

• Destination Template Management

• Mass Configuration

• Services Registry Configuration

• Profile Management

• System Global Settings

• Business Administration Mass Configuration

• Web Services Administration

• Publication Restrictions

• Web Services Logging & Tracing• PI Adapter Monitoring

• PI Message Monitoring

• PI Background Processing (for the Adapter Engine only)

• Sequence Monitoring





Figure 36: NWA Availability and Performance Management, Problem

Management & SOA Management

User Administration and Authentication

All components of SAP NetWeaver PI that run on the Application Server use the

underlying infrastructure provided by the SAP NetWeaver AS for the following:

• User management

• Administration

• Authorizations

• Authentication

The only exception may be adapters on the J2SE based Adapter Engine.

User Store

Users are maintained in the ABAP user store. This can also be integrated with

LDAP-based user administration. Each SAP NetWeaver PI component that resides

on an SAP NetWeaver AS refers to the user management of the ABAP part of this

SAP AS. PI Java applications running on an SAP AS authenticate against the users

maintained in the ABAP part. This is the standard case for SAP NetWeaver PI.

Certificate Store

XI and RNIF protocols support message level security-based on digital signature.

The RNIF protocol also supports encryption. The required certificates to be

used need to be entered into the key store of the AS Java engine. In





the Integration Directory these certificates are referred by the name of

the key store view and the certificate name. It is recommended to store

CA certificates in the TrustedCAs view.

SAP NetWeaver PI makes use of the Application Server Add-In Installation User

Concept. Application Server Java uses one client of its AS ABAP as its user

master. This means for the user concept of SAP NetWeaver PI: Roles defined in

AS ABAP are available as Groups in AS Java. The authorization concept of AS

Java components within SAP NetWeaver PI is based on AS ABAP roles.

Figure 37: Application Server Add-In Installation User Concept

Dialog Users Roles

Each dialog user role has authorizations for multiple components of SAP

NetWeaver usage type PI. The roles contain task specific authorizations and they

all contain at least display authorizations in all PI components.





The following dialog user roles are provided:

• SAP_XI_DISPLAY_USER

• SAP_XI_SUPPORT

• SAP_XI_DEVELOPER

• SAP_XI_CONFIGURATOR

• SAP_XI_CONTENT_ORGANIZER

• SAP_XI_MONITOR

• SAP_XI_MONITOR_ENHANCED

• SAP_XI_ADMINISTRATOR

• SAP_SLD_ADMINISTRATOR

• SAP_SLD_CONFIGURATOR

To make changes to authorizations on the ABAP side, proceed as follows for

each dialog user role:

1. Call transaction PFCG

2. Copy the single role SAP_XI_ -ROLE- _ABAP into the customer namespace

(replace the prefix SAP)

3. Create a new composite role in the customer namespace (for example,

*_XI_ -ROLE-)

4. Assign the new single role (suffix _ABAP) to the new composite role

5. Assign the new SAP single role (suffix _J2EE) to the new composite role

6. Make changes to the new single role (suffix _ABAP)7. Generate an authorization profile for the new single role (suffix _ABAP)

Service User for Communication

User and connection for internal communication are read from the Exchange

Profile. Therefore, changes to the Service Users also have to be reflected in the

Exchange profile if used there. Users for external communication (system user)

must have role SAP_XI_APPL_SERV_USER. External communication means

external from a Process Integration point of view. Users for external

communication should not be service or dialog users, because these users

could be used to log on to PI in dialog mode.

For each connected application system create a copy of a system user to send

messages to the Integration Server. It is recommended to use the PIAPPLUSER

as a template for that purpose.





Further roles are available for Service Users:

• SAP_XI_BPE_SERV_USER_MAIN

• SAP_XI_ID_SERV_USER_MAIN

• SAP_XI_IR_SERV_USER_MAIN

• SAP_XI_IS_SERV_USER_MAIN

• SAP_XI_RWB_SERV_USER_MAIN

Figure 38: Communication and Service User

Available Service Users in SAP NetWeaver PI:

• PIREPUSER: Used for Enterprise Services Builder (ESR) and SLD

Requests.

Necessary roles:

SAP_SLD_CONFIGURATOR,

SAP_XI_IR_SERV_USER,

SAP_XI_IR_SERV_USER_MAIN

• PIDIRUSER: Used for Integration Builder Configuration with the tasks of:

– SLD Requests

– Integration Builder Design Requests

– Cache Update

Necessary roles:SAP_SLD_CONFIGURATOR,

SAP_XI_ID_SERV_USER,

SAP_XI_ID_SERV_USER_MAIN,

SAP_BC_WEBSERVICE_PI_CFG_SRV

• PIISUSER: Used for the Integration Server with the following tasks:

– SLD Requests

– Messaging to Adapter Engine







Necessary roles:

SAP_BC_JSF_COMMUNICATION_RO

Due to the user naming changes from previous XI* users now to PI* users, you

might have to change the XI/PI relevant users in your back-end systems as well.

ESR and Integration Directory

From the PI Tools start page, select the Administration link. You will be prompted

to enter your user id and password. This will take you to the tabs Repository,

Directory and Runtime.

Figure 39: From the PI Tools Page, choose Administration.

With respect to Repository, the relevant sections for administration are:

• System Information

• Administration of Properties• Administration of Locks

• Caches

• Java Web Start

On the right side the Software Build Information contains support information

about:

Release Version

Service Pack Number





JDK Version

Figure 40: Software Build Information

General Information:

The Repository has two key sections that are made up of application and systeminformation. The application section highlights file access for system root

directory and transport directories for both export and import files. The system

environment highlights general information on server ID, server version of J2EE,

memory and file access for local directories. It also contains information about the

Java Runtime environment with version level, Java Virtual Machine with version

level, and the operating system platform with an associated version level.





Figure 41: General Information

Properties Administration:

Aii Properties contains a broad range of useful system

information.





Figure 42: Aii System Properties & Exchange Profile

There is a folder structure in the Exchange Profile for settings of specific for

the Adapter Framework, Application System, Connections, Integration Builder,

Integration Server, and Runtime Workbench.The Lock and Cache Administration provides you with locks overview with

respect to removing selected locked objects set by users.

Concerning the Repository and Directory alike is the Java Web Start

Administration part. The Restore Archives function will cause a refresh of

the client at the next click on its start link. All necessary resources will be

collected and signed. A lock will be set, so that only one restore can happen at

the same time. Use this function if you are sure that no reconfiguration thread is

currently running; for example, after a restart of the J2EE server. If more than one

restore thread is running, problems may occur.

Essential for runtime and also important for build and design time activities is theintegrity of the caches. Both the Java Virtual Machine Caches and the Data Caches

can be administered. From here, you can trigger a partial or a full cache refresh.





Figure 43: Data Cache Administration & Virtual Machine Cache

Administration

When Integration Directory objects are activated, the changes are replicated in

the Integration Server runtime cache (accessed via SXI_CACHE) and in the CPA

cache of each adapter engine (central and non-central). Information about the

adapter engines is obtained from the SLD and therefore you can use this option to

refresh the SLD cache here.

Adapter Framework Administration

The Adapter Framework is part of every SAP NetWeaver PI installation. In

addition, another Adapter Framework can be installed on a separate host, and

be configured and monitored centrally. The AF is also part of the Partner

Connectivity Kit, where it brings its own configuration and monitoring tool.





Figure 44: SAP PI 7.1 Architecture

The Adapter Framework is based on the SAP J2EE Engine and the J2EE

Connector Architecture (JCA). It provides interfaces for configuring, managing,

and monitoring adapters.

You can find the Services in the SAP NetWeaver Administrator under: Operation Management → Systems → Start & Stop → Java EE Services. Search for XPI

using the filter function.

Figure 45: Services of the Adapter Framework in the NWA





For configuration purposes, a restart of the services may become necessary. If you

want to stop the adapter service, click on the service name and choose Stop from

the context menu that opens on the bottom of the screen. An inactive service canbe started with Start from the context menu.

Figure 46: Start and Stop the Entire XPI Service

If there are any problems with a certain channel communication, then turning

the dedicated communication channel off is the better choice than stopping thewhole service.





Figure 47: Activate/Inactivate the Communication Channel in the Integration

Directory

Afterwards ensure that the changes recorded in a changelist are finally activated.

As an alternative the communication channels can be administered using the

Communication Channel Monitoring accessible from the RWB → Component

Monitoring and selection the Adapter Engine. Select in the Status tab the

Communication Channel Monitoring. Search for the dedicated channel and click

on the details to Start or Stop the channel.





Figure 48: Use Start/Stop in Communication Channel Monitoring

XPI Service CPA Cache Facts:

• Cache for Directory & Repository data (CPA Cache)

• Cache is filled during activation within directory

• Contains objects from directory

Services

Parties

Bindings (inbound/outbound; sender/receiver agreements)

Channels

Adapter metadata

Module configuration

• Used in Adapter Framework during runtime

You can access these parameters through the NWA: Configuration

Management → Infrastructure → Java System Proper-

ties.Underneath the separator Details choose Services.

Select XPI Service: CPA Cache.

Extended Details contains the parameters for the CPA

Cache Service.





Figure 49: Properties of CPA Cache Example: SLD.selfregistration.hostName

Parameters for the CPA Cache Service:

cacheType:

DIRECTORY for Adapter Engine, PCK for Partner Connectivity Kit. This

property can only be modified offline, using the configtool.

directoryPwd, directoryURL, directoryUser:

These connection parameters are taken for the cache refresh,

when SLDAccess is set to false. Otherwise, the settings are taken from the

ExchangeProfile.

SLDAccess:

This parameter is set to true for the Adapter Engine and set to false for

Partner Connectivity Kit (usually no SLD available). If the parameter is set

to true: the SLD address is taken from the central Exchange Profile.





Figure 50: Parameters for the CPA Cache Service

The Parameter SLD.selfregistration.hostName is used normally in HA setups

to force the CPA cache service to register with the host name of the SAP

WebDispatcher (or any other used loadbalancer). It can also be used in caseswhen network communication requires for the use of fully qualified host names

(FQDNs), because local host names are not always resolved properly.

You can perform a CPA Cache refresh manually using the URL

http://host:port/CPACache/refresh?mode=full or via the menu with PIDIRUSER.

You can reach the menu by navigating to PI Tools startpage → Administration →

(Repository tab/Directory tab) Data Cache Overview.

You may use the cache refresh functions only if configuration requires you to reset

the content of the PI caches and for testing purposes, because a working cache

refresh is crucial for a properly configured system.





Figure 51: Manual CPA Cache Refresh

Audit Log Configuration in the Adapter Engine:

During message processing on the AAE the AuditLog information is per default

only kept in memory and only up to 2000 entries per server node.

AuditLog relevant properties of 'XPI Service: Messaging System'

Property Description

messaging.auditLogEnabledValue type: Boolean

Default value: true

This property enables or disables

the audit log. You can modify this

property online.

messaging.auditLog.memoryCache Value type: Boolean

Default value: true

This property enables or disables the

audit log caching. You can modify this

property online.





The first decision you take is to enable or disable the AuditLog in general. Usually

in developement and test systems you would like to see what is going on, but on a

productive system you might want to have better performance with the drawback if less analysis information. Especially for the AAE with local processing

mode, writing audit logs is relatively expensive and depending on needs the

disabling of the audit log entries can be reasonable on a productive system.

The next decision is how many AuditLog data and where you want to keep

the AuditLog data. If you decide for the new Memory Cache functionality

than only 2000 entries are kept per J2EE Engine Server Node for successfully

processed messages. For failing message the AuditLog data is always stored

and persisted in the database. Only if you want to record also for successfully

processed messages the AuditLog data, you will have to switch the value of the

messaging.auditLog.memoryCache property to false.

Important differente between J2EE Engine 7.0 and 7.1 in regards to serviceparametrization:

Figure 52: JEE Properties Maintenance Option - 7.1 versus 7.0

Installing JDBC and JMS drivers:

For the JDBC and JMS adapters, you need external drivers that have to beprovided as Java archives (jars) by the provider of the database or messaging

system, respectively. For SAP NetWeaver 7.1 it is mandatory to use JEE5

compliant external drivers.

You have to deploy these drivers to enable them to be used by the adapters in

the SAP J2EE Server. The Adapter Engine installation provides the archive

aii_af_jmsproviderlib.sda, to which you have to add the required driver(s).





Figure 53: Vendor Specific Driver (JMS, JDBC)

• Add driver(s) (jar) to aii_af_jmsproviderlib.sda

• Unpack, modify and pack provider.xml from/to aii_af_jmsproviderlib.sda;

for packing: use the same path/server

• Deploy aii_af_jmsproviderlib.sda (ignore version)

• JMS only:

Remove the javax/jms classes from the driver jar first – this is because the

javax/jms classes belong to the J2EE server base classes and confuse the

class loader in the server when deployed more than once





Figure 54: Example: provider.xml with IBM WebSphere MQ

In the picture above you can see an example of IBM WebSphere MQ Java libraries

to be added to aii_af_jmsproviderlib.sda:

• com.ibm.mq.jar

• com.ibm.mqbind.jar

• com.ibm.mqjms.jar

• connector.jar

After you have carried out these steps, deploy the resulting SDA file using the

JSPM. You can check the deployment in the SAP NetWeaver Administrator.

For additional information, refer to SAP Notes on the Service Marketplace:

• 1138877: PI 7.1 : How to Deploy External Drivers JDBC/JMS Adapters

• 831162: FAQ: XI 3.0 / PI 7.0 / PI 7.1 JDBC Adapter

Integration Engine AdministrationThe Integration Engine, as a runtime component of SAP NetWeaver PI, has the

following tasks:

• Receive XML messages

• Process XML messages

• Forward XML messages





During message processing, collaboration agreements are evaluated, the receivers

are determined, and mapping activities are executed. Collaboration agreements

define which communication channel to use to process messages for particularcombinations of senders and receivers. In a collaboration agreement, senders and

receivers can also agree on additional security settings, which refer to the content

of the messages.

The Integration Engine provides additional features like:

• Time Controlled Processing

• Special queue for large messages

• Message Prioritization

• Balancing between parallel queues

• “Switch Procedure” for message deletion

To use the Integration Engine, it must be configured for the current system

landscape, keeping in mind the Integration Processes involved.

Figure 55: PI Start Menu for Administrator User

Call the Integration Engine – Administration (SXMB_ADM) and the system

displays the screen Integration Engine: Administration.





The screen Integration Engine: Administration. contains a menu that comprises

two areas: Administration and Configuration. Administration and configuration

are mainly system administrator tasks used to set up the processing of XMLmessages. This enables you to make changes to SAP default settings or to

configure test settings.

Figure 56: Transaction SXMB_ADM

The following functions are available to help you manage and administer the

functions of the Integration Engine:

• Under Manage Queue

you will find features for registering, de-registering, and activating queues.

These changes take effect while the Integration Engine is online.

• Scheduling jobs for archive and deletion of PI messages

• Configure settings to support Error Analysis

You cannot execute options in the menu that have the locked symbol, if you do not

have the required authorization. The authorizations for the individual functions

are tailored to requirements and are assigned as derivations of the composite role

SAP_XI_ADMINISTRATOR. They are all based on the authorization object

S_XMB_ACT.





The following functions are available to help you configure an Integration Engine:

• Maintaining filters for event-driven processing and queue prioritizations

• Configure Sender/Receiver IDs

• Setting Integration Engine global and specific configuration

• Defining the procedures for deletion of PI messages persisted on the

Integration Engine

• Defining the interfaces to be archived and the retention period of PI messages

persited on the Integration Engine

• Displaying pipeline definitions

Maintaining filters for event-driven processing:You can define filters to select messages that you do not wish to

process immediately but for a later event by:

• Assigning filters to sender and receiver IDs already configured

• Defining jobs to schedule the processing of messages that have been sorted

by a filter and not processed immediately

To schedule the processing of messages explicitly, you have to:

• Define the required senders and receivers

• Define a filter for selecting the required messages

• Define a job that schedules the processing of the filtered messages ormessage packages

Note: This only applies to messages with quality of service EO

(Exactly Once) or EOIO (Exactly Once In Order). All settings here are

client-specific.

From the main screen of transaction SXMB_ADM Integration Engine -

Administration, select Configure Event-Driven Message Processing. This will

bring you to the Maintain Message Filter screen.





Figure 57: Transaction SXMB_ADM: Event Driven Processing

Figure 58: Schedule Message Processing

For Job Maintenance, traffic light above the job list shows the status of thescheduled job.

• A green light signals that the scheduler job is scheduled.

• An amber light signifies that the scheduler job is scheduled, but overdue.

• A red light signifies that the scheduler job is not scheduled.





A job is started as soon as the relevant criteria are met. The job is active and the

scheduler job used to schedule the jobs for message processing is running. If

necessary, you have the option to reschedule the scheduler by selecting Scheduler Overview from within the Job Maintenance view.

Defining Sender/Receiver IDs:

You define IDs for senders and receivers so that you can use them in other

functions, for example, in event-driven message processing.

Figure 59: Transaction SXMB_ADM: Configure Sender/Receiver ID





Figure 60: Creating a Sender/Receiver Definition

Creating a new sender/receiver definition:

• Switch to change mode.

• Select New Entries.

• Enter a sender/receiver ID (be as descriptive as possible).

• Make the remaining entries for the sender/receiver definition.

An input help containing normalized addresses is available on the Integration

Server to assist you when making these entries. You are not permitted to use other

address data here. IDocs are an exception as no normalized data is available.

There is no input help available in an Integration Engine. You have to maintain

the communication channel data specified in the Integration Directory manually

in this case. You can enter an asterisk as a wildcard.

Changing an existing sender/receiver definition:

• Enter transaction SXMB_ADM.• Select Configure Sender/Receiver ID.

• Switch to change mode.

• Make the required changes (you can change all properties except for the

sender/receiver ID).





Setting up the Integration

Engine's configuration data:There are two types of configuration data:

• Global configuration data

• Specific configuration data

The specific configuration data to define parameters, which you use to configure

your Integration Engine.

The configuration data for the Integration Engine is client-specific. This means

that you can configure multiple business systems in different ways in one SAP

system. You use the global configuration data to define the role of your current

business system (i.e. Integration Server). You can load the global configuration

data from the System Landscape Directory, if it is already maintained there.You can also define a configuration locally, for example for test purposes, using

configuration data that differs from that of the System Landscape Directory.

Loading the global configuration data from the System Landscape Directory:

Choose Edit → Change Selected Configuration Data → Choose System

Landscape - Load Configuration (save the loaded data, F6).

To undo the loading of global configuration data from the System Landscape

Directory, choose Revoke Changes (Ctrl. F6).

Figure 61: Loading Configuration Data

Changing the configuration data displayed:

Choose Edit → Change Selected Configuration Data.

To change the usage type of your business system, in the field Role of Business

System, select an option using the input help.

A business system can have one of the following roles:





Integration Server:

This is a centrally configured Integration Engine that is not able to execute

application logic. It receives XML messages, determines the receiver, executesmappings, and routes the XML messages on to the corresponding receiver system.

There can only be one Integration Server in an SAP system. This means that only

one client can be defined as the Integration Server.

Application system:

The system can act as a sender or receiver of XML messages, but it does not

contain any integration logic. Therefore, neither routing nor mapping can be

executed locally. Instead, they must be executed by the Integration Server, which

is called by the application system. Even though it is equipped with a local

Integration Engine it requires the Integration Server to execute the integration

logic (the Integration Server can run in another client of the same SAP system).

In changing Selected Configuration Data, there are two ways of specifying an

address:

• http://hostname:port/sap/xi/engine?type=entry, where hostname is the host

name of the Integration Server and port is the HTTP port.

• Dest://IntegrationServer-Destination, where IntegrationServer-Destination is

an RFC destination of type HTTP Connection (type H) for the Integration

Server in the current system. In this case, the RFC destination contains the

host name, port, and path prefix. In other cases, it may also contain logon

information.

If you want to call an Integration Server, but do not want to configure your

business system as an Integration Server, enter the address for the particular

Integration Server in the field Corresponding Integration Server . The name of the

user and the password must be defined with the HTTP service (/sap/xi/engine) in

the target system. The user is the person who processes the XML messages on

the Integration Server. First, create an RFC destination of type H with the host

name and the HTTP port of the Integration Server.

Enter the following path prefix: /sap/xi/engine?type=entry.

In changing the Specific Configuration Data, input help is available for the field

category of parameters to which you want to apply the changes.

Choose Change Configuration Data. This displays the view Configuration of

the Integration Engine. The view displayed contains a table with configuration

parameters that have already been defined for the selected category.

For more information about the individual parameters, choose the information

icon (input help) in the corresponding line. If you did not select a category of

parameters for the field Category in the previous step, the table contains all

configuration parameters that have already been defined.





Mark the checkbox in the column Prefix to define the corresponding subparameter

as a prefix. This way it is possible to define a configuration value generically

for a set of subparameters. Parameters are local parameters and therefore arenot automatically transported.

Message Restart Administration

The message processing might fail due to temporary

failure situations, like network connection issues. For such cases it is

recommended to schedule a message restart job on the Integration Engine. The

program searches for failed (could not be processed correctly) or missing (were

deleted manually from the queue) messages and tries to restart these messages

automatically. The maximum number of restart attempts and the interval between

these attempts is set with the qRFC scheduler. After the maximum number of

restarts, the restart of the messages is canceled if it was not successful.

Job Name Report Recommended Interval

SAP_XMB_RESTART_

MESSAGES

RSXMB_RESTART_

MESSAGES

Every 5 minutes

IDOC Adapter Refresh Status Administration

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.


SAP_XMB_REFRESH_

ADAPTER

SXMS_RE-

FRESH_ADAPTER_

STATUS

Create your own Variant

to be scheduled

Every hour or only evey

day, this is depending

on your IDOC Adapter

usage

BPE Configuration and Administration

The Business Process Engine is based on the Workflow Engine. The SAP

NetWeaver PI version of workflow works just the same as the normal workflow

component in any SAP NetWeaver AS. All integration (business) processesdefined in SAP NetWeaver PI generate at runtime workflows on the ABAP stack.

However, in Process Integration there are unique step types that are normally not

part of the workflow definition environment (Transform, Send, Map). Most of

these unique step types use ABAP classes at execution time. Even though the

design layer of workflow has unique features for SAP NetWeaver PI, the runtime

layer is the same as the normal workflow runtime layer.

Before you can start using Integration Processes initial BPE configuration is

required.





Transaction code SWF_XI_CUSTOMIZING is used to configure the BPE. You

can automatically generate the configuration by choosing Perform Automatic

Workflow Customizing.

The item Start Verification Workflow will start a workflow that verifies if

workflow has been setup correctly. Automatic customizing (transaction

SWF_XI_CUSTOMIZING) must be performed on every client where you want to

execute workflows, and this should be part of your post-installation process. It

only has to be executed once for each client where workflows will be executed.

Not every item in SWF_XI_CUSTOMIZING must be green in order for the

workflow engine to work.

The most important item that must be in green status is item Configure RFC

Destination. No workflows will execute if this setting is not green.

Further important settings include:

Active Plan Version:

This ensures you are reading the current version of

the organization chart. This is critical in an ERP system where workflows

may be routed to people based on their organizational chart. This setting is

not as critical for SAP NW PI.

Schedule Background Job for Missed Deadlines:

If the workflow will have deadlines, a background job runs peri-

odically to detect the deadlines. This job is normally set to run at certain

intervals. This background job calls report RSWWDHEX.

Figure 62: Required configuration for the BPE/Workflow





When a workflow is created, it is saved with a unique number. It is saved with the

letters WS followed by a number (WS########). Workflows provided by SAP

are identified in the same way.

One important part of configuration is setting up a number range. All workflows

(and workflow components) created by your company will start with the same

number. The number range is used for the first three digits of the workflow

number.

In SAP NetWeaver PI you do not create workflows directly. However, for

integration processes created in the ESR and Integration Directory, a workflow is

created. This workflow has a unique number assigned to it. This configuration

creates the number range used for the generated workflows.

To look at the number ranges in SWF_XI_CUSTOMIZING, do the following:

• Select Maintain Definition Environment.

• Select Maintain Prefix Numbers.

The number range configuration is not included in the Automatic Customizing.

You have to create the number range manually.

Figure 63: Required Configuration: Number ranges

For runtime, the most important configuration is the creation of the user ID

WF-BATCH. WF-BATCH is the “behind the scenes” user for workflow.

WF-BATCH is created as a System user, and SAP recommends that this user has

complete authorization (SAP_ALL). Since WF-BATCH executes all steps that

run in the background, there is no way to determine everything that WF-BATCH

might be required to do.





The following are examples of when WF-BATCH logs in:

• When an event is triggered and a workflow starts, WF-BATCH logs in to

start the workflow.

• When a method is executed in the background.

• When a terminating event is raised.

Figure 64: Required Configuration: RFC Destination

Figure 65: Integration Process defined in ESR

The picture above shows an example of a simple Integration Process defined in

the Enterprise Services Builder. The first (Start) step is the triggering event. The

second step (Receive) enables us to wait for a specific message to arrive. The third

step (Map) enables us to transform from one message to another. The fourth step

(Send) enables us to send the message out. This process is built in the Enterprise

Services Builder and generates a workflow.





Figure 66: Workflow defined in the ESR

This is the workflow generated from the Integration Process shown in the previous

figure. The actual generated workflow can be seen in transaction SWDD. When

a workflow gets created, it is stored on the database as WS (workflow template)

and a number. For example, WS74900023. In the configuration section, we will

discuss the required configuration for the number ranges. You can see that some

icons are the same as in the Enterprise Services Builder. The first step (Start)

becomes the triggering event step. The second step (Receive) becomes a wait

for event step. The third step (Map) becomes an activity step. This is the mostcommon type of step in a workflow. Behind this step type, normally a call to

a business object or an ABAP class takes place. The fourth step (Send) calls

another workflow.





Figure 67: View-Generated Workflows using TA: SXI_CACHE

You can display and analyze the runtime version of an Integration Process in

the runtime cache. This can be useful in an error situation, for example, when

an Integration Process could not be started. If you want to analyze the runtime

version, you can display it either as an XML representation or in the Process

Builder.

The runtime version of an Integration Process is created automatically from the

definition of the integration process in the Enterprise Services Repository and the

entries for service and party in the Integration Directory. The runtime version is

created as soon as you have activated the change list in the Integration Directory.

In the user menu, choose Process Integration → Configuration → Integration

Directory Cache (SXI_CACHE). If the contents of the cache are currently being

updated (amber status traffic light), wait until the cache has been updated. If you

choose not to wait, you take the risk of accidentally locking an Integration Process.





Figure 68: Find the WS Workflow Number in SXI_CACHE

Double-click on Integration Processes. You will then see all the workflows that

have been generated. Workflows are generated whenever the change lists are

activated in the Integration Directory (Configuration).

Note: You can see the actual WS number that is assigned to the new

workflow.

Figure 69: CACHE Updated when Change Lists Activated





In the Enterprise Services Builder, the Integration Process is created. The changes

are then activated. Afterwards, the Integration Process is used in the Integration

Directory. Once these changes are activated, the workflow is generated. Theworkflow is then updated each time the Integration Process is changed in the

Enterprise Services Builder. The workflow may be updated, or a new version

may be generated. A new version is always generated after the current version is

migrated to production.

Figure 70: From SXI_CACHE to the Process Builder

To display the process definition, select the runtime version and click the icon with

the quick info Display Active Version. The process definition is displayed in the

Process Builder (transaction code SWDD).





Figure 71: Return Codes for Workflow Runtime Versions

The screen area on the right displays the following information for each runtime

version: Partner and service from the Integration Directory

• Workflow task:

During processing by the Business Process Engine, the runtime version of

the Integration Process is represented by a workflow task.

• Release:SAP Web AS release that was being used when the cache was updated.

• Return Code:

Return code for the creation of the runtime version -0: The runtime version

was created without errors. If not equal to 0: Errors occurred. You can

update the runtime version and then analyze the error messages. When you

do so, the system displays detailed messages about the problems that

occurred. You can also save the XML output as a file, which you an then

pass on to SAP Support for further analysis.

• Date and time of last update.

• XML representation:

XML representation of the runtime version of the integration process. To

display the XML representation in a clearer, more structured way,

double-click a line.





Stopping and Starting the SAP NetWeaver PI System

In this section we provide you with useful cheat sheets in regards to recommended

activities for stopping and starting the SAP NetWeaver PI system.

1. Call transaction SWF_XI_ADM_BPE and stop BPE processing (if ccBPM

is used).

2. If possible, stop the message flow from your sending systems.

3. Stop the Communication Channels on the Central Adapter Engine.

4. Monitor the Central Adapter Engine till all inbound messages are processed.

5. Optional: Lock the Integration Server.

6. Deregister the PI Queues of the Integration Engine(s).

7. Check and process tRFC entries via transaction SM58 on the IntegrationServer.

8. Stop the connected J2SE Adapter Engines (if used)

9. Decide if you want to stop the Communication Channels on your Non-central

Adapter Engines (if used).

10. Decide if you want to stop the Partner Connectivity Kit (PCK) (if used).

11. Shutdown your SAP NetWeaver PI system.

1. Start SLD (if stopped).

2. Start the SAP NetWeaver PI system and wait for ABAP and JAVA Stack

startup including all Java Services.

3. Unlock the Integration Server (if locked).

4. Start all Non-Central Adapter Engines / J2SE Adapter Engines (if used)

5. Register the PI Queues in the Integration Engine(s) and check queue

processing status.

6. Call transaction SWF_XI_ADM_BPE and check that all BPE components

are running.

7. If stopped, start Sender Communication Channels.

8. Check Integration Processes: Call transaction SXMB_MONI_BPE →

Restart Process After System Crash.

9. Check Cache Status: Call transaction SXI_CACHE.10. Start the Sending/Receiving Systems (if stopped).

11. Check messages/IDocs/tRFCs in error status on SAP NetWeaver PI and

Sending Systems.

A more detailed step list regarding Starting and Stopping, including

information about the tools to be used, is available in the Technical Operations

Manual in the SAP Library at http://help.sap.com/saphelp_nwpi71/help-

data/en/12/5dd23aaad7b3408dde3c1577fda5b3/frameset.htm


http://help.sap.com/saphelp_nwpi71/helpdata/en/12/5dd23aaad7b3408dde3c1577fda5b3/frameset.htm

http://help.sap.com/saphelp_nwpi71/helpdata/en/12/5dd23aaad7b3408dde3c1577fda5b3/frameset.htm




If you are using Integration Processes (ccBPM) in your environment,

you will find detailed information about starting and stopping of the

BPE in the SAP Library at http://help.sap.com/saphelp_nwpi71/help-data/en/44/4a11b6668d02bfe10000000a11466f/frameset.htm


http://help.sap.com/saphelp_nwpi71/helpdata/en/44/4a11b6668d02bfe10000000a11466f/frameset.htm

http://help.sap.com/saphelp_nwpi71/helpdata/en/44/4a11b6668d02bfe10000000a11466f/frameset.htm




Lesson Summary

You should now be able to:• Describe which parts of an SAP NetWeaver PI system need to be

administered

• List the administration tasks in the SAP NetWeaver PI system




BIT480 Lesson: Distribution Options of SAP NetWeaver PI Components

Lesson: Distribution Options of SAP NetWeaver PI

Components

Lesson Overview

In certain cases, the distribution of PI components allows a company to meet their

specific requirements. This lesson explains the available options and connects

them to the corresponding landscape requirements.

Lesson Objectives


• Name the components of a SAP NetWeaver PI 7.1 system that can bedistributed throughout the landscape

• Tell if the distribution of SAP NetWeaver PI 7.1 components will benefit

your setup

Business Example

In your company, a complex network of systems needs to be connected to

your SAP NetWeaver PI system. You want to know what options you have

concerning the setup of the SAP NetWeaver PI components in order to meet your

requirements.

Distribution Options for SAP NetWeaver PIComponents

In this section, we describe how you can distribute the SAP NetWeaver PI building

blocks on physical hosts to provide stability, performance, and scalability for

production systems.





The following topics are covered:

• Outline all hosts that are necessary to run the SAP NetWeaver PI usage type

• The assignment of installable software units to the hosts

• The Web infrastructure

Note: This section mainly addresses the distribution of SAP NetWeaver

PI components for the purpose of scalability, not for high availability. For

setting up HA environments, refer to the respective guide on the Service

Marketplace or on SDN. It is strongly recommended that you read the

SAP High Availability documentation available in the SAP Developer

Network (SDN): www.sdn.sap.com/ir j/sdn/ha.

For information about specific switchover products, contact your hardware

and switchover software vendor. If you have any questions regarding the

integration of SAP NetWeaver AS with a specific switchover product,

contact the Competence Centers of SAP’s hardware partners.

As a prerequisite, you have to know which installable software units and

standalone engines you need and how your system landscape will look like. This

was covered by a previous section.

An SAP system consists of SAP instances. An SAP instance is a group of

processes that are started and stopped at the same time. In SAP NetWeaver, the

following instances are avilable in general:

• Application server instance

• Central services instance

• Database instance

All instances, except for the database instance, are identified by an instance

number, which is a two-digit number between 00 and 97 that is unique on a host.

Instances can reside on one host, or they can be distributed on several hosts.

Application Server Instance – the application server of usage type AS ABAP

includes:

Dispatcher

Work processes (dialog, background, spool, or update)

Gateway

Internet Communication Manager (ICM) - optional

Internet Graphics Service (IGS) – optional


http://-/?-

http://-/?-

http://-/?-




The minimum installation comprises the central services instance and one

application server instance.

Note: SAP recommends to avoid primary application server instances

(with enqueue work process and message server on the same host) in

cluster environments.

Additional application server instances are optional and can be installed on

separate hosts. A cluster always needs a load balancing solution, such as SAP Web

Dispatcher or any other third-party Web Dispatcher.

Central Services Instance – The ABAP central services instance (ASCS) forms the

basis of communication and synchronization for ABAP clusters. The ASCS can

only be installed for a high availability system with AS ABAP.

A central services instance consists of the message server and the enqueue server:

Message server: Only one message server can run on each AS ABAP usage

type. The message server handles the communication between the additional

application server instances and also supplies information to the SAP Web

Dispatcher about load balancing.

Enqueue server: The enqueue server contains a lock table that handles

logical database locks.

SAP NetWeaver supports Server Central Services (SCS) – An instance that

consists of the essential enqueue and message system services only. This has been

standard for AS Java installations and is now possible for AS ABAP as well.

The benefit of having a separate SCS instance is high availability. This approach

concentrates the possible single points of failure of a system into a single instance

and, therefore, ensures isolation just on them. Before the SCS entities were

located on a separate functional instance, it was necessary to extend protection

to a complete system.

To reflect this development the, term “dialog instance” is no longer used. From

now on, instances running functional services are named "application server"

(AS) instance.

This means that highly available SAP NetWeaver systems have only two kinds of

instances, either an SCS or an AS instance. However, as there are currently still

two central services instances in a SAP NetWeaver Add-In installation – one forABAP and one for Java – they are called SCS and ASCS.

Database Instance – The database instance is a mandatory installation component

for the installation of an SAP system. AS Java and AS ABAP have separate

database schemes. When AS ABAP with AS Java (also known as Java Add-In)

is installed, the AS ABAP and the AS Java database schemes are installed in the

same database. It is not recommended to use separate databases for the AS Java

and AS ABAP scheme. The ABAP scheme is named SAP<SID>.

Strategies for Scaling:





The scenario that is installed on an SAP system can require the application

server to be scaled up for performance reasons. Therefore, scalability is very

important for efficiency, performance, and cost reduction. One strategy is todistribute the components to different physical machines, avoiding multiple

uses of resources, such as memory and CPU.

Another strategy for distributing the load is using vertical and horizontal scaling in

a cluster environment:

Vertical scaling is a technique for a cluster arrangement that includes many

additional application server instances created on one physical machine. The

single machine needs enough resources to handle this configuration. We

recommend that you monitor performance and memory before adding a

new application server instance. You can set up vertical scaling whenever

required as it does not need any special installation steps.

Figure 72: Vertical Scaling

Horizontal scaling is another clustering technique that distributes the

additional application server instances across multiple physical machines.

This configuration provides failover support and so ensures high availability

of the application server processes. The disadvantages of this strategy are the

increased installation and maintenance effort and also the cost of additional

machines.

Figure 73: Horizontal Scaling





A single machine topology describes a configuration where all components reside

on the same machine. It is easy to install and maintain and is therefore appropriate

for first-time installations when you want to test and familiarize yourself with thefunctions of the application server. At this stage, it is easy to determine what kind

of topology is needed and to plan the system landscape.

Although this topology is easy and inexpensive to configure, it has some

drawbacks that you must consider. Since all components are located on a single

machine, they compete for resources, and this affects the performance processes.

In addition, the components cannot be additionally secured with firewalls, and

high availability is not supported. This configuration can be enhanced with

horizontal scaling.

Separating the database instance to a separate host avoids multiple uses of the

same resources, as we discussed above in the drawbacks of a single machine

topology. Apart from the improved performance, locating the database instance

on another physical machine lets you implement high availability solutions. The

database is a critical component and it is therefore very important to ensure high

availability for it.

Nevertheless, hosting the database instance on a separate machine adds to the

complexity because you need to configure, maintain, and back up another entity.

A SAP NetWeaver PI system which consists of an Application Server Java (AS

Java) and an Application Server ABAP (AS ABAP) as an ABAP+Java System

has the following mandatory instances:

• ABAP Central Services instance• JAVA Central Services instance

• Database instance

• One or more dialog instances

You can install an ABAP+Java system in one installation run (new system), or you

can enhance an already existing AS ABAP system with a Java Add-In. The AS

ABAP part communicates with AS Java using standard RFC calls.

For High Availability or for Scaling purposes it is possible to distribute the

Instances to separate physical hosts.





Figure 74: Distributed System

Central System – In a central system, the database instance is placed on the same

host as the Add-In central instance of the ABAP+Java system.

High Availability – The critical components of this scenario include the critical

components for AS Java and AS ABAP.

In this scenario, the database instance and central services instances are each in

their own switchover group. This variation keeps the Add-In central instance

outside of the hardware cluster, thus only running necessary parts for switchover

in such an environment.





Figure 75: A Dialog Instance for an ABAP+Java System

Note: This is only one of several possible configurations.

Considering scalability, the recommendation for an Add-in is to have an AS

ABAP and an AS Java Add-in on it. However, it is possible to add an Add-In

Dialog Instance that only contains AS ABAP in case the NetWeaver system needs

more AS ABAP resources. A load balancer is needed whenever HTTP/HTTPS

requests have to be processed.

When distributing the instances of a SAP NetWeaver Process Integration system,

the following needs to be taken into account: The default installation variant for

a Process Integration system is the All-in-One installation where all the central

components, namely the central Integration Server, Integration Builder, and

System Landscape Directory (SLD) are installed on one host.





Figure 76: SAP NetWeaver PI All In One - Java Part

All ABAP parts of the Process Integration system run on the AS ABAP. The AS

Java components are also installed together in one AS Java instance. AS ABAP

and AS Java can be secured as one unit. For scalability reasons, additional dialog

instances for AS ABAP and AS Java can be added on different hosts.

Start with the all-in-one scenario and securing all components of the all-in-one

installation together by using switchover software. Thus, there are no additional

actions required to consider the communication between those components when

a switchover is initiated.

Note: Using the all-in-one scenario as your starting point reduces the

post-installation tasks for enabling switchover to a reasonable number and

it keeps the administration of the server cluster as simple as possible.

Process Integration scales with AS Java and AS ABAP. Normal Process

Integration message traffic enters the Integration Server using the HTTP protocol.

However, if the IDoc adapter is used, message data enters the Integration Server

by using the standard RFC protocol.

Load balancing is also available for the RFC protocol. The AS Java and AS

ABAP message server is used as the call dispatcher. RFC load balancing offerstwo major benefits for the PI system:

• Improved scalability – Calls are parallelized and forwarded to several

different AS Java and AS ABAP instances.

• Improved availability – Any AS Java and AS ABAP of the Integration

Server can be the target of the incoming call.

Therefore, it is not necessary that a specific AS Java and AS ABAP instance is

working. With RFC load balancing activated, the sudden failure of one AS Java

and AS ABAP will not affect the accessibility of the PI system by IDocs.





RFC load balancing can also be used with the RFC adapter of an Adapter Engine.

The adapter then registers several threads at the SAP Gateway of an RFC client

system. The client system can then make use of load balancing by means of multiple SAP Gateway registration.

Figure 77: Overview - SAP NetWeaver PI Components

With SAP NetWeaver PI, standalone engines can be installed as additional

software units. They do not offer the complete functionality of an SAP NetWeaver

system, but provide specific server functionality in combination with one or more

SAP NetWeaver systems.

Note: A complete list of the standalone engines is available

in the Master Guide on SAP Service Marketplace at

http://service.sap.com/instguidesNWPI71.

Additionally, the Web infrastructure has to be considered. In order to run an

application with stability, high performance, security, and low cost, the technicalinfrastructure must provide optimal support for the application. The infrastructure

includes many different components, from computer hardware, operating systems,

storage devices, high availability solutions to networks, load balancing devices,

and firewalls.

The Web infrastructure is a crucial part of the technical infrastructure. It consists

of every piece of equipment needed to convey HTTP(S) requests between the

browser and server. The Web infrastructure plays a meaningful role in the stability,

performance, and cost of ownership of a business solution.


http://-/?-

http://-/?-




The most important technical requirements that must be considered when building

a Web infrastructure are:

Load balancing mechanisms – With load balancing, client requests are

distributed across multiple servers in one SAP NetWeaver system. Load

balancing solutions have to be used to scale a SAP NetWeaver AS system

and to improve its overall performance. SAP offers the SAP Web Dispatcher

as a software load balancing device. Other third-party software or hardware

load balancers can be used as well. The load balancing product has to

be compatible with your Web infrastructure components and technical

requirements.

Security – Certain security considerations must be taken into account when

designing a Web infrastructure. The most important considerations are the

use of http versus https (SSL encryption), the use of reverse proxies and

firewalls. Other considerations may cover the use of IDS (intrusion detectionsystems).

The SAP Web Dispatcher is located between the Web client (browser) and your

SAP system that is running the Web application. It forwards each incoming

HTTP(S) request to an appropriate SAP NW Application Server for processing,

as illustrated in the following figure.

Figure 78: Load Balancing with SAP Web Dispatcher





The Web dispatcher is a load balancing solution that retrieves system

administration and configuration from the message server.

Note: It is not recommended to install a SAP Web Dispatcher on an

Application Server as it might cause overload of the hardware and may

therefore pose a security risk. A better solution is to have the SAP Web

Dispatcher on a separate host, running on dedicated hardware.

The SAP Web Dispatcher performs the following tasks:

• Check the session ID to pass subsequent requests for stateful sessions to the

processing server (session stickiness)

• Decide whether the request is an ABAP request (e.g. a BSP application) or

a Java request (for example, a JSP or a servlet)

• Load Balancing

• HTTPS scheduling or end-to-end SSL

• URL filtering

The Process Flow is that first the SAP Web Dispatcher checks the type of the

incoming request. If the request is not an administration request, it is processed

in two stages:

1. The SAP Web Dispatcher decides whether the incoming HTTP request is to

be forwarded to an ABAP or a Java server. It determines a group of servers

in the SAP system that can execute the request. It gets the information about

the groups from an application server.

2. The load is balanced within this group. When the load balancing process

has decided on the server that the request is to be sent to, the SAP Web

Dispatcher forwards it to the ICM of this application server.

When using a third party loadbalancer for SAP NetWeaver PI communicatin,

make sure that the loadbalancer supports session stickiness, which is used for

RWB functionality.

There is always a danger of malicious access, particularly in an Internet scenario.

Therefore, a certain area of the network is defined as a demilitarized zone (DMZ).

The DMZ is protected by firewalls to prevent unauthorized access.

If the SAP Web Dispatcher is used as a reverse proxy, it is highly recommended toinstall it inside a DMZ. A DMZ can be quite simple, as shown in the figure below;

however, depending on the security requirements, a multi-layer DMZ can be used.





Figure 79: SAP Web Dispatcher in DMZ

There are further configuration steps that need to be performed which apply to

HA, and mere load balancing setups.

The connection to the User Management Engine has to be configured.

To enable local RFC connections between the user management engine (AS Java)

and AS ABAP, the variable $$ is used for addressing. Perform the following steps:

• Start the SAP NetWeaver Administrator.

• Choose Configuration Management → Security Management →

Destinations.

• Select the destination UMEBackendConnection.

• Specify the following values:

– Target host: localhost

– System number: $$

The Pipeline URL of the Integration Server needs to be maintained.

To enable load balancing for SAP applications that retrieve the URL of the

Integration Server from the System Landscape Directory (SLD), for example,

Adapter Engines, the pipeline URL registered in SLD needs to be adapted.

To change this, go to Business Systems in SLD and select the Integration Server’s

business system. Enter the virtual hostname and the port of the SAP Web

Dispatcher in the field Pipeline URL.





The HTTP Service Port of the Adapter Engine needs to be adjusted.

To enable load balancing between the Integration Server and the central Adapter

Engine, the hostname property used for the SLD registration of an AS Java node

needs to be adapted. Perform the following steps:

• Start the SAP NetWeaver Administrator.

• Choose Configuration Management → Infrastructure Management → Java

System Properties → Details → Services.

• Select the service XPI Service: CPA Cache.

• Enter the virtual hostname and the ports of the SAP Web Dispatcher for the

properties:

– SLD.selfregistration.hostName

– SLD.selfregistration.httpPort– SLD.selfregistration.httpsPort

• Restart the XPI service. This should automatically trigger a SLD

publishing of the new hostname and port inforamation pointing to the SAP

WebDispatcher.

• Call transaction SXI_CACHE and choose Goto → Adapter Engine Cache.

Delete the current entry for the Adapter Engine. When a message is sent to

the Adapter Engine, the entry is reread from the SLD. Verify that the new

hostname pointing to the WebDispatcher host is used in Adapter Engine

URL.

The RFC Destinations between AE and IE should be changed to local bundle.

• On the IE call transation SM59 and delete existing gateway settings on tab

Technical Settings for RFC destinations AI_RUNTIME_JCOSERVER and

AI_VALIDATION_JCOSERVER.

• On the AE side start NWA → Configuration Management → Infrastructure

→ JCo RFC Provider.. Modify destinations AI_RUNTIME and

AI_VALIDATION with gateway host information localhost and sapgw$$.

The $$ will be replaced by instance number during runtime.

Without configuring scalability, even after adding a new instance, the load will

not be distributed among the instances. Thus, previously mentioned steps needs

to be carried out and the SAP WebDispatcher (or any other loadbalancer) is usedin this case to distribute load.





Lesson Summary

You should now be able to:• Name the components of a SAP NetWeaver PI 7.1 system that can be

distributed throughout the landscape

• Tell if the distribution of SAP NetWeaver PI 7.1 components will benefit

your setup

Related Information

For more details about HA Setup of SAP NetWeaver PI 7.1 refer to SAP Note

1052984.




BIT480 Lesson: Message Load Considerations

Lesson: Message Load Considerations

Lesson Overview

This lesson deals with the configuration considerations for a SAP NetWeaver PI

system to properly support the designated message load.

Lesson Objectives


• Know about features of SAP NetWeaver PI addressing high-volume

scenarios


team



Business Example

Your company assesses the use cases introduced along with the SAP NetWeaver

PI implementation. You are asked by your operating department if the coming PI

system is technically capable of supporting certain scenarios of usage in regards to

high-volume requirements. Now you need to get the information on what are the

possibilities to address specific requirements regarding a best-performing system,

that can provide really good message throughput.

Performance Matters

There are basically two different motivations that normally bring out the

performance topic in a customer installation. One is the need to increase

processing speed of messages, especially regarding synchronous scenarios.

Of special interest is, for example, the processing speed of queries, used to retrieve

information like descriptions, listings or other object-related information. Another

demand may be an increase in throughput of messages, which means an increase

of the data volume processed over a fixed period of time.

This does not necessarily also mean an increase in absolute message processing

speed, but in a high load situation a more stable system behavior also increases

the overall message processing speed.

On the other hand, while increasing message processing speed by reduction of

latency times is likely to benefit the overall throughput of messages, but this

cannot always be achieved in an easy way.





The most typical way to achieve throughput increase is by increasing the number

of parallel tasks in execution. This is not always the case, but a fairly common

solution.

Throughput is normally more frequently linked to asynchronous processing,

whereas an increase of message processing speed is more often an approach used

in synchronous scenarios.

Put in general terms, the way to achieve an improvement in message processing

speed increase usually differs from the way to achieve an increase in volume

throughput.

Performance requirements viewed from a different angle addresses another

important issue. That is to consider performance as one topic within the

requirements you have to meet for the integration scenarios.

In B2B scenarios, performance topics are prioritized lower in comparison to, for

example, the reliability of the message exchange.

In contrast, scenarios of Application Integration (A2A) are often required to be

both fast and reliable at the same time.

For synchronous human interaction scenarios (H2A) guaranteed low latency

times may be obligatory and not reaching a particular service level could leave

the scenario being not usable.

Regarding the particular use case, a particular performance topic could range

from a nice-to-have type of requirement up to being absolutely critical for the

scenario. Therefore, performance topics should be considered from the beginning

of the implementation.

Here are some examples of performance requirements to be met, depending on

the use case:

B2B: Exchange of documents with Business Partner has to be more reliable

and secure than fast.

A2A: Application Integration has to be fast and reliable.

H2A: User expects near to real-time or synchronous communication.

There are several considerations regarding performance requirements.

Most important is a proper integration design. This is a genericconcern regarding integration scenarios. SAP NetWeaver PI represents

the middleware system at the center of the integration scenario which

has to be analyzed as a whole. A methodology should be used

considering all the required steps and roles to minimize possible

design errors. For more Information, refer to the following blog:

"Important documentation for your process integration projects" at

https://www.sdn.sap.com/ir j/sdn/weblogs?blog=/pub/wlg/5356.


https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/5356







Another important thing that needs to be considered is the environment

that SAP NetWeaver Process Integration communicates with. Not only

the database, operating system, and network connections must be set upand working correctly, any connected middleware or back-end system,

receiving or sending data has to comply with the required performance,

stability, QoS, and service level agreement. During and after design time,

you should be aware of SAP NetWeaver PI features to fully exploit your

design, configuration, and monitoring options.

Figure 80: Performance Improvement Options in General

The methods to optimize high volume support can be split into three different

groups. Namely they are divided intp

• General SAP NetWeaver PI methods

• ccBPM specific enhancements and

• Adapter Specific enhancements.





The first group includes "General SAP NetWeaver PI methods”:

• Message Packaging: This is a throughput-increasing mechanism based on a

message processing in groups inside each pipeline step. This provides for the

benefits of loaded ABAP program re-execution and massive database access.

• Message Prioritization: Some interfaces are more important than others,

depending on the immediate business need. If you have a very critical

interface you would like to ensure that this interface is prioritized over

other interfaces in the processing on the Adapter Engine as well as on the

Integration Server side.

• Advanced Adapter Engine: The adapter engine supports integration engine

capabilities like routing and mapping locally, resulting in a simplified

architecture and message handling.

• Delayed Message Processing: Depending on your business needs, youmight want to collect noncritical messages in the Integration Server and

schedule the message processing into time intervals of general low message

processing on your PI system.

• Large Message Handling: On the Integration Server large messages could

be processed by separated large message queues, so that on one hand the

parallel processing of large messages is reduced and that these queues do

not interfere with smaller messages.

• Direct calls (formerly named “P2P connections”): This configuration

allows back-end systems to contact each other directly bypassing the SAP

NW PI middleware system. The benefits of this method are both an increase

in messaging speed and throughput, due to the fact that a direct connectiondoes not spend processing time on message mediation.

The second group addresses ccBPM-specific enhancements.

• Packaging: Message Packages can be transferred to the BPE, extending the

message packaging features to the area of Integration Processes.

• Parallel Processing: This feature allows specific Integration Processes to be

executed with the Quality of Service EO, instead of EOIO and is thus able

to process them in parallel.

• Enhanced Transaction Handling: Allows design time optimization of

transaction handling, spanning one transaction over several Integration

Process steps instead of having to use one transaction per process step.





The third group relates to Adapter-specific enhancements.

• IDOC Adapter – Packaging and IDoc tunneling: The IDoc packaging

functionality allows several IDocs to be handled together on the outbound

side. This functionality has been replaced by message packaging, which

basically uses the same principle. No XML transformation (or IDoc

tunneling) allows IDocs to be kept in original format whenever there is no

advantage expected from translating them to the internal PI message format.

• File Adapter: File Splitting makes use of a content conversion utility that

allows you to split one file into several PI messages based on the specific

configuration.

• Maximum Concurrency for File and JDBC Receiver Adapter: This

method is mostly use to reduce parallel processing for slow performing

back-end systems, keeping adapter-specific threads on the Adapter Engine

free

• RFC Adapter: Parallel connections are possible for RFC Sender and RFC

Receiver channels. Depending on the parallel message processing needs

and the capacities on the back-end multiple parallel connections can be

configured here.

An overall correct system configuration is an important prerequisite before

any optimization option mentioned above will bring any benefit to message

performance.

In order not to go beyond the scope of this course, only the (new) features

of Message Packaging, ccBPM Packaging, Message Prioritization and local

processing on the Advanced Adapter Engine, Maximum Concurrency for

File/JDBC Adapter, and Direct Connections will be covered in the following

sections.

Message Packaging

To understand how message packaging works, you need to know how message

processing generally works in an SAP NetWeaver PI system.

1. If a message arrives at the Integration Engine, it is persisted in a message

queue.

2. Then, the message enters the pipeline process.3. After the process step is finished, it is stored in the message queue again.

4. The last two actions are repeated for each pipeline step until the message is

eventually delivered to the receiver.

Every single message is treated in isolation. That means that every time a message

is persisted in the message queue, it is also stored at database level. Additionally,

every time the message resumes execution in a pipeline step, the required





programs have to be loaded into the ABAP memory (rolled-in) and also have to be

removed from memory after execution. Having to repeat these steps over and over

for every single message results in significant resource consumption.

Message processing is improved by using a packaging concept.

• Several messages are received at the message queue.

• The scheduler starts message processing and checks if there are any

additional messages that can be processed as well.

• If so, they are grouped and processed together in the same package, loading

the ABAP programs into memory. After the pipeline process is executed for

all messages of the group, they are updated and committed to the database

as a whole.

• This procedure is used for every pipeline step, until the messages can be

delivered to the receiver.

This is a far more efficient way of message processing in comparison to the

standard processing technique, since context switch operations and database

access are reduced drastically.

Message Packaging brings several advantages.

• One call is able to process several messages, thus reducing overhead which

leads to less context switch operations.

• All changes during a message processing step are committed at the same

time in one single call.

• From the application perspective, there is no change at all, single messagesare kept on an atomic level as before. This means there is no impact in

any monitoring transaction. Furthermore, if a message inside the package

generates an application error, the package is broken down into single

messages and is executed in isolation.

Figure 81: Message Packaging Feature Overview





Packaging is based on the integration engine message queues. This means that

steps that read and process messages from the queues are able to be packaged.

Therefore packaging supports asynchronous messages with qualities of serviceexactly once (EO) and exactly once in order (EOIO) in the following steps:

• Sender and receiver proxies

• Integration Engine internal steps (like receivers determination or mapping)

• Receiver IDocs

• Receiver Adapter-Engine-based adapters

Figure 82: Message Packaging Scope

To activate packaging, you have to start to Integration Engine administration

transaction SXMB_ADM.

Then execute “Integration Engine Configuration”.

Select the category “RUNTIME” and execute “Configuration”.

Add a row for the parameter “PACKAGING” and set the current value to 1.

Save to activate changes.





Figure 83: Global Configuration - Activation

“Configuration Types” define the way packaging will be working for either

general or specific service interfaces. Use transaction SXMS_BCM to access the

“Configuration Types”.

There are two built-in configurations. One is called “DEFAULT” and is the

configuration delivered in the standard product to execute the different steps. You

can create as many configurations as you want and configure their use for each

filter as defined in transaction SXMSIF.

The other built-in configuration is called “NO” and should be used to avoid

packaging. It might be used for particular scenarios where packaging makes no

sense, even when packaging is globally switched on.

Each “Configuration Type” has three parameters:

The “Wait Time” parameter specifies how long a running process has to waitif it did not reach the maximum number of messages configured for this type.

The “Number” parameter specifies the maximum number of messages that

should be collected prior to starting the message selection and size analysis.

It corresponds to the number of messages for each package.

The “Maximum package Size in KB” parameter describes the size of the

package measured in KB.





Figure 84: Global Configuration – “Configuration Types” Customizing

“Configuration Types” have to be assigned to either global package configurations

or specific package configurations. Run transaction SXMS_BCONF to carry

out global and specific configuration:

For the global configuration, select “Global Package Configuration” in the tree

on the left. Specify the desired “Configuration Type” for the applications:

“IS_IN” for inbound processing or “IS_OUT” for outbound processing. If you

don’t perform any configuration, the “DEFAULT” configuration type will be

automatically used. You will also use the other applications for acknowledgement

handling, ccBPM packaging and sender proxy on application system level.





Figure 85: Global Configuration – “Configuration Types Usage” Customizing

How are packages built and what is the relationship with the “configuration types”

parameters?

Assume that the package creation has two major blocks or procedures. The first

procedure is used to read the queue. When a message from the queue starts to

process the first function module, first of all, it checks if there are more messages

in the queue, if so, they are also read considering the “Maximum Number” for the

“Configuration Type”.

Should the number of messages not reach the “Maximum Number” for the

“Configuration Type” in use, the process is set to sleep the number of seconds

specified in the “Maximum queue Time” parameter.

Afterwards, this package will appear in the monitoring transaction as “Timeout”

since this process had to be set to sleep a certain amount of time, trying to enlarge

the number of requested messages by checking the queue for additional messages.

The second block analyzes the set of messages previously retrieved. It checks

the message attributes for every message if a message should be assigned to the

package, it is assigned. Afterwards, the process makes sure not to exceed the

“Maximum package size” configured, if not it keeps on reading the following

message from the set. After reaching the limit or retrieving all the messages,

the package is set to execution.





Also, special conditions apply if the parameters are configured to 0. If there is

no “Maximum Queue Time”, there will be no further aggregation if the package

sizes are smaller than desired (from the number of messages point of view). If “Maximum Number” or “Maximum Package Size” are set to 0, the corresponding

limit is not checked and everything is processed.

Figure 86: “Configuration Type” Influence in Package Creation Process

• M ax. Queue Time = 0:

No additional accumulation.

• Maximum Number = 0:

The whole queue content is processed.

• Max Package Size = 0:

No size limit.

If you want to create a new “Configuration Type” either for a general or interface

specific reason (as simulated here), access transaction SXMS_BCM and switch

to Edit Mode.





Figure 87: Creating Component or Interface-Specific Configurations Types I

Hit “New Entries” and create a meaningful name for your purpose. The figure

above and the one below show a configuration example. Here, it is assumed there

is no need for aggregation, since each time a message is processed, there are a lot

of messages already waiting in the queue, so the “Wait Time” is set to 0 seconds.Another assumption for the example was that the number of average messages

required to create the desired message size will contain about 1,000 sales orders

in it, thus the “Number” parameter is set to 1,000. Finally, the default package

size is kept to 1MB.





Figure 88: Creating Component or Interface-Specific Configurations Types II

The last step in the interface-specific “Configuration Type” creation is to

configure the package creation. Start transaction SXMS_BCONF again. Now,

mark the “Inbound Processing from Request Packages in IS” row. Double-click on “Specific Package Configuration”. Create a new entry (not shown here) and

specify the “Inbound Processing from Request Packages in IS” application and the

“Portal_SalesOrder” Sender ID. The “SLS_ORD” configuration type has to be

used. Repeat the configuration for the “IS_OUT” application to package also the

outbound processing. Save to activate the interface-specific configuration type.

From now on, every time a sales order appears in the integration engine, it will be

packaged according to the previously defined rules.





Figure 89: Creating Component or Interface-Specific Configurations Types III

When a message goes to a business system through a proxy, the system will

automatically control if packaging is supported by the target system by taking

a look at the software component versions for the Business System described

in the SLD (System Landscape Directory); since release 7.0 SPS 12 packaging

is supported.In contrast, if the Communication Component is a Business Component (what we

used to call “Business Service” in XI and PI), there is no information at SLD level.

For that reason, table SXMS_LCR_VERS was created. Using transaction SM30

(the typical customizing table maintenance transaction), you can create an entry

for the Business Component and specify the current version.







Figure 91: IDocs: Message Packaging Versus IDoc Packaging

How will we monitor the packages or how will the packages affect current

message monitoring?

Packaging has no impact on monitoring; furthermore, if an error occurs inside the

package, the messages will be treated as before, losing the packaging benefits but

without impact at processing or monitoring level. Obviously, if the quality of

service is Exactly Once in Order, the queue will have to be stopped as before.

For development system or error analysis, you can switch on the Integration

Engine parameter “RUNTIME-> LOGGING_AMF_ERR” in transaction

SXMB_ADM→ Integration Engine Configuration, to receive some packaging

information in transaction SXMB_MONI.

In the runtime properties of each particular message, the field

“EOReferenceOutbound” will have the package ID used for that message.

To configure packaging monitoring, use transaction XMSPKSTATCNF, which

corresponds to report SXMS_BLK_STAT_CNF and allows you to configure how

statistical information will be collected, the level of aggregation desired, and

the reorganization information.





Figure 92: Message Packaging Monitoring – Configuration

Message Packaging ...

... Increases throughput for asynchronous messages on Integration Server

... Is switched on globally, but can be configured specific to a scenario

... Provides detailed Monitors

... Requires virtually no visible changes in monitoring and error handling.

ccBPM Packaging

The feature of ccBPM packaging is very much related to the feature of Message

Packaging. Basically, the message packages containing all the messages already

assembled are transferred from the integration engine to the Business Process

Engine for processing.





Figure 93: ccBPM Packaging

To enable ccBPM packaging, you proceed in a similar way as the configuration

of Message Packaging.

• Execute transaction SXMB_ADM.

• Choose Integration Engine Configuration.

• Select BPE for Category.

• Click Configuration.

• Create a new parameter PACKAGING and set the value to 1.

• Save to enable.

.

In contrast to message packaging, ccBPM packaging is not automatically

activated, the reason for that being that there are normally special requirements for

each integration process, so the activation is integration process-specific.





Figure 94: Global Configuration of ccBPM Packaging - Transaction

SXMB_ADM

Another performance-oriented recommendation is to configure the parameter

DISPATCHER with subparameter MIN_DURATION_PROCESSING. The effectof the parameter is that the dispatcher will be kept awake for some additional

seconds after finishing processing, checking for any new messages. Afterwards, it

will stop waiting for the job scheduler to start it over again.





Figure 95: Global Configuration of ccBPM Packaging MIN_DURATION_PRO-

CESSING

One more required configuration step is to schedule a background job for ccBPM

packaging.

Execute transaction SWF_XI_CUSTOMIZING for that purpose.

Expand the branch “Maintain Runtime Environment”.

Execute “Schedule Background Job for Packaging”.





Figure 96: Global Configuration of ccBPM – Scheduling the Background Job

One more required configuration step is to schedule a background job for

reorganization for ccBPM packaging.

Execute transaction SWF_XI_CUSTOMIZING for that purpose.

Expand the branch “Maintain Runtime Environment”.

Execute “Schedule Background Job for Reorganization”.





Figure 97: Global Configuration of ccBPM – “Maintain Runtime Environment”

Each integration process needs to be configured individually regarding packaging.

Start configuration transaction SWF_INB_CONF. Browse and open the integration

process to configure inside the corresponding software component version.

Check the message packaging configuration section:

Activate it and configure the other three parameters as you did before for regular

message packaging.

The following settings are available in message packaging:

Maximum Number of Messages – Defines the maximum number of

messages in a message package.

Maximum Package Size in kB – Defines the maximum amount of memory

for a message package, that is the total size of all messages added together.

Maximum Wait Time in Seconds – Defines the maximum time that a message

can be held by the packaging job before being sent in a message package.

The first two criteria both determine when a message package is considered to be

complete because it has reached the defined size limit, either with the maximum

number of messages or the sum of the message sizes. The maximum wait time

is a subordinate criterion that you can reduce with latency. Before the maximum

wait time of at least one of the messages is exceeded, the first two criteria alone

determine whether a message package is complete and can be sent to inbound

processing by qRFC.





Figure 98: Integration Process specific Configuration for Packaging

Summing up ccBPM Packaging:

• Message packages are transferred from and to ccBPM.

• Configuration is done process-specific.

• ccBPM package monitoring is available.

• No visible changes in Monitoring and error handling.

Message Prioritization on the AAE

In previous releases, adapter-specific queues exist and they still exists in SAP

NetWeaver PI 7.1. The number of max. threads can be configured per direction

(sender, receiver), server node and adapter type with the help of the NWA or for

server node individual with the Config Tool. In former releases it was not possible

to prioritize messages on the Adapter Engine itself.





Figure 99: No Message Prioritization in XI 3.0/PI 7.0 on the Adapter Engine

Message prioritization is designed to avoid that priority high messages get stuck

due to a backlog of other messages on the same node To “see it working” at all,

you need a backlog in the messaging system. To see the expected ratio in message

delivery you need in addition comparable fast back-ends.

Figure 100: Message Prioritization in 7.1 on the Advanced Adapter Engine





Message prioritization is now also available for the Adapter Engines. For message

processing on the Adapter Engine you can define rules according to which

messages with different priorities (low, normal, or high) are processed. Use theattributes from the message header to define such rules.

Figure 101: RWB - Component Monitoring - Message Prioritization

Figure 102: Prioritization Maintenance for AAE

• Rules within Component Monitoring with 3 different categories (high,

low, normal) per sender/receiver party/component, interface, namespace

• Corresponding to properties messaging.prioritization.high,messaging.prioritization.low and messaging.prioritization.norma of XPI Service: Messaging System that can be set (online modifiable)

• All QoS supported (EOIO serial per scenario)

• Prioritization during runtime takes place in principle whenever for a given

adapter type and at a given moment of time all worker threads are occupied





You now might want to know how to control and monitor the dispatcher queues

and the occupied threads per adapter type. This real-time monitoring can be

achieved by the Engine Status functionality in the RWB for Adapter Engines.

Figure 103: RWB - Adapter Engine - Engine Status

Figure 104: Engine Status - Dispatcher Process per JEE Server Node

On this screen during normal production runtime you will see the currently, at that

time, queued up messages per J2EE Server node. Futher to the right you will seehow many threads are currently processing the data - for the dispatch queue of the

AAE node only one thread is used to distribute messages for further processing

to the adapter specific worker threads.

Local Processing on the AAE

First let us have a look at the XI and PI architecture prior to release 7.1. From a

“technology” perspective, the product is a combination of a Java and ABAP world.





Inside the Java stack, we had the Adapter Engine and the mapping runtime

environment.

On the Adapter Engine, we had the Adapters (like RFC, FILE, JDBC, JMS,

etc…), the Module Processors and the messaging system.

On the ABAP stack, we had the Integration Engine and the Business Process

Engine. Inside the Integration Engine we had the Pipeline Services, the message

queues and a few adapters.

Figure 105: SAP NetWeaver PI Architecture in Detail – Prior to 7.1





A typical message flow in the architecture version described above was looking

like the following.

1. The message arrives at the sender adapter where it is parsed.

2. Then it is sent to the module processor.

3. he message goes to the messaging system, where it is persisted.

4. Later, the message is transmitted to the Integration Engine (therefore it has

to be transformed into XML format, replicated, authenticated, and parsed

again).

5. Then, the message is logically routed to the destinations and persisted again.

6. For every destination, the message is mapped (usually executing a JCO

call to the Java stack).

7. Then, the XI adapter starts the transmission back to the Adapter Engine

executing all the internal steps from above.

8. After that, the module processor takes action again and finally it is sent to the

receiver adapter and to the target system.

Figure 106: Classical Message Processing in Detail

In the new PI 7.1 architecture, routing and mapping functionalities have been

added to the Advanced Adapter Engine, which makes it possible to execute

end-to-end scenarios just there on the JAVA stack, without having to go over

the Integration Engine.





Figure 107: SAP NetWeaver PI 7.1 Architecture in Detail

Now we look at a typical message flow, using the local processing functionalities

of the Advanced Adapter Engine.

1. The message arrives at the Sender Adapter where it is parsed.2. Then, it is sent to the module processor.

3. Then, the message is logically routed to the destinations.

4. Subsequently, it goes to the messaging system, where it is persisted.

5. For the destination, the message is mapped locally in the Java stack.

6. After that, the module processor takes action again.

7. Finally, it is sent to the receiver adapter and to the target system.

Compared to classical processing, there is a significant reduction in the number of

steps that have to be executed. Many internal latency-producing steps are removed.





Figure 108: New Message Processing Capability – Processing takes place

entirely on Advanced Adapter Engine

The new features introduced with the Advanced Adapter Engine include:

• Perform end-to-end message processing without any help from theIntegration Engine.

• Increase in message processing speed and throughput by reducing latencies

and resource consumption (both memory and processing time).

• Local processing is probably most feasible for existing Java-based adapters,

and it delivers an improvement in performance and resource usage.

Features of the AAE:

• Supports synchronous and asynchronous messages

• Supports Non-central Adapter Engines

• All Java-based adapters already in use are supported, in the future some otheradapters will be supported as well

• Integration processes (ccPBM) are not supported

• Normal one-to-one Java-based mapping types

• Static routing

In upcoming enhancement packages, additional functionality will be added, such

as IDoc and Web services adapters on the JAVA stack, further adapter availability

for integration scenarios, more routing and mapping functionalities, and additional

optional persistence step after mapping to satisfy regular SOX requirements.





Also, you can use the Runtime Workbench or the forthcoming SAP NetWeaver

Administrator to monitor the messages ( RWB → Message Monitoring). Of course,

the ABAP based transaction SXMB_MONI won’t be able to show messagesresiding on the Java part.

Figure 109: Advanced Adapter Engine Scope – Monitoring the Messages

in RWB

Other features that are already included in the AAE are sequence mappings in the

operations mappings, access control lists, lookups, principal propagation, value

mappings, XML schema validations, header mappings, and virtual receivers.





Figure 110: Advanced Adapter Engine Scope – Further Features

The system has to be configured to do the local processing in the AAE instead of

going through the integration engine. Automatic detection is not supported.

At configuration time, instead of creating a Sender Agreement, Receiver

Determination, Interface Determination and Receiver Agreement, you have to

create an “Integrated Configuration” object, formerly referred to as “all-in-one”

configuration.







Figure 112: Integrated Configuration in Detail

During preliminary performance testing sessions, with a SOAP-to-SOAP scenario

processing small 8Kb messages, it was possible to boost message processing

throughput up to 10 times, evidently increasing message processing speed with the

help of the local processing in the AAE.

Figure 113: Throughput Comparison Analysis for Local Processing in the

AAE





Summary of Advanced Adapter Engine Features:

• Increase in Message Processing speed (improved response time) and

throughput.

• Reduces resource consumption.

• Supports Synchronous and Asynchronous Messages.

• Sender and receiver adapters located on the same Adapter Engine,

Non-central Adapter Engines are also supported.

• Available for adapter types hosted on the Adapter Engine only

Maximum Concurrency for File/JDBC Adapter

This new feature is useful for back-end systems with unreliable, unstable network

connections or with bad performance. Instead of occupying always the maximumnumber of adapter type threads for such back-end systems, the maximum parallel

connectivity can be maintained now in the AAE.

This feature is implemented in XI 3.0 SP20, XI 7.0 SP 13 and SP 14 (via the

latest patches of AFCORE) and in PI 7.1 SP6.

1. The number of concurrent messages treated PER RECEIVER.

There is a global parameter that affects all the queues of type Asynchronous

Inbound. This parameter could affect other types of queues, but is makes

no sense to change it.J2EE Engine service: XPI Service: Messaging System

Property: messaging.system.queueParallelism.maxReceivers

Default value: 0 (means: No limitation)

2. The number of concurrent processed messages by

a communication channel of type File and JDBC.

The parameter is only available for Receiver Communication

Channels.

Processing tab in Integration Directory - Receiver Communication Channels

of type File and JDBC.

Parameter name: Maximum Concurrency

Default value: 1





Figure 114: XPI Service: Messaging System - Property: messaging.sys-

tem.queueParallelism.maxReceivers

Figure 115: Maximum Concurrency for JDBC Receiver Communication

Channel

The Messaging System will allow only a given number of messages for each

receiver to be processed at the same time. Once the parameter is set for the

communication channel, , the Asynchronous Inbound queues will only allow the

processing of so many messages for a receiver at the same time.





Figure 116: Runtime Behavior - Start Situation

Figure 117: Runtime Behavior - No further Processing of Message for

Communication Channel A





Link between the two parameters:

• One parameter affects the whole messaging system

• The other parameter affects only the communication channels

• Setting a greater value for a communication channel than for the messaging

system does not make any sense

Direct Connections

SAP NetWeaver PI 7.1 supports the development and configuration of scenarios

which will not go through the middleware at runtime. They are configured to

skip PI processing when there is no added value leading to reduced resource

consumption.

The “Direct Connection” is a concept to describe connections that will bypassPI at runtime, omitting several resource-intensive steps. This can be used for

particular scenarios to increase performance of message procesing.

Figure 118: Direct Connection Concept

It is configured in the Integration directory, and this configuration is propagated tothe back-end systems automatically.

Direct Connections are supported in scenarios using SAP NetWeaver Application

Servers with Web services, without mapping, static routing and one receiver.

All the modeling, development, and configuration activities will be also carried

out in PI.

The monitoring functionality will be based on the forthcoming SAP NetWeaver

Administrator and the sources of information are the interacting back-end systems.





An implementation scenario for Direct Connections could be feasible if the

following applies:

• Web services

• No mapping

• Static routing

• Only one receiver

Even if this does not seem to be a middleware-related solution, it exploits all SAP

NetWeaver PI 7.1 capabilities at design time, configuration time and monitoring.

Once you have modeled and developed your scenario, you can realize it can be

a candidate for a direct connection. Create a “Direct Connection”object in the

Integration Directory. Specify the receiver communication channel, the sender and

receiver interfaces and the adapter-specific attributes.Upon activation, this information is sent to the sender and receiver Web services

configuration layers, and this will be used by the application program to instantiate

the consumer proxy on the client side.

Figure 119: Direct Connection Configuration in the Integration Directory





Lesson Summary

You should now be able to:• Know about features of SAP NetWeaver PI addressing high-volume

scenarios


team








Unit Summary BIT480




Unit 2 SOA Management – Web ServicesConfiguration & Services Registry

Unit Overview

This unit describes the concept of Web Services and how the related configurationcan be achieved using SAP NetWeaver PI 7.1. The configuration and usage of the

Services Registry is covered in this unit.

Unit Objectives


• Set up the Web Service Runtime environment

• Use important maintenance transactions

• Identify the configuration tools needed to configure your Web service

scenarios• Use the different configuration tools

• Configure the Services Registry

• Understand the concepts and the functionality provided with the Services

Registry

• Understand how to publish, search, and consume enterprise services using

the Service Registry

• Know how mass configuration of Web service can be executed

Unit Contents

Lesson: Setup Web Service Runtime ... .. .. ... .. .. .. .. ... ... .. .. .. ... .. .. ... 152Lesson: Configuration of Web Services . .. .. ... .. .. .. .. ... ... .. .. ... .. .. .. ..157

Lesson: Services Registry.. ... ... .... .... ... .... ... ... .... .... ... ... .... ... ... 169

Lesson: Mass Configuration.... ... .... .... ... .... ... ... ..... ... ... .... ... .... .188


http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-



Unit 2: SOA Management – Web Services Configuration & Services Registry BIT480

Lesson: Setup Web Service Runtime

Lesson Overview

Your business plans to use Web services and you need to set up

the Web Service Runtime environment in SAP NetWeaver PI 7.1.

This lesson describes the necessary configuration steps to set up

the Web Service Runtime in your SAP NetWeaver PI 7.1 system.

If your company does not require this functionality, you can skip this unit

completely and take the information for later usage.

Lesson Objectives




Business Example

Your business needs to call asynchronous Web Services and

requires PI functionality like routing and mapping, and therefore

requires the usage of the WS adapter including the WS-RM (Web

Services Reliable Messaging Protocol) on SAP NetWeaver PI 7.1.

WS-RM describes a protocol that allows SOAP messages to be delivered reliably

between distributed applications in the presence of software component, system,or network failures.

Introduction and Overview

To execute asynchronous Web services and use the newly available

WS adapter, specific settings are required on the relevant system.

In our case, the Integration Server client of the SAP NetWeaver

PI 7.1 system has to be prepared to support the WS adapter.

System components, such as AUTOABAP, RFC, Background RFC (bgRFC),

and Internet Communication Framework (ICF) are involved and need to be set

up for a working WS runtime.

The same configuration needs to be done in your back-end systems as of SAP

NetWeaver 7.0 SP14 and SAP NetWeaver 7.1, if these are to be enabled for Web

Service communication using the Web Service Runtime.

The configuration has to be executed manually, and as the configuration is

client-specific it must be performed in each productive client and in client 000

in addition. In order to execute the necessary configuration steps, you need

the appropriate user with administrator authorizations. In upcoming releases

(enhancement packages), it is planned to integrate the necessary configuration

steps into CTC (Central Technical Configuration) templates.




BIT480 Lesson: Setup Web Service Runtime

Programs for Technical Configuration

The following programs are required:

• Report SRT_ADMIN:

Report to setup technical configuration of the Web

Service Runtime in client.

• Report SRT_ADMIN_CHECK:

Using the report , you can check whether the Web

Service Runtime is configured correctly.

• Transaction SBGRFCCONF:

Configuration of bgRFC is done using this

transaction. To perform bgRFC configuration tasks, you need authorizations

from authorization object S_BGRFC.• Transaction SICF:

Use this transaction to maintain Internet Communication Framework (ICF)

Services. Once you have installed the Application Server all ICF services are

available in an inactive state for security reasons. After the installation you

have to decide which services must be activated for the applications you

want to use. The following authorizations objects are relevant:

S_ICF, S_ICF_ADM, and S_ICFREC.

• Function module SRT_TECHNICAL_SETUP_RESET:

This function module can be used to reset the technical settings.

1. Execute report SRT_ADMIN (using transaction SA38) in client 000 and ineach productive client of your system.

• Choose Perform Technical Setup and execute the report (F8).

• Pay close attention to the guidelines in SAP Note 1110741.

• Using the report SRT_ADMIN, you create a service destination for

communication through RFC and you perform the settings for the

bgRFC.

2. Create a supervisor destination for bgRFC processing using transaction

SBGRFCCONF.

• The supervisor destination reads the configuration settings for the

bgRFC scheduler and starts or stops the schedulers as required oneach application server.

• Having a supervisor destination is a prerequisite for maintaining and

monitoring the bgRFC queues. Create the supervisor destination only

once for each system.

3. Activate the services of the ICF necessary for communication between the

Web Service consumer and the Web Service provider.

• SAP provides appropriate ICF services for the standard functions of the

Web Service Runtime. Activate the services listed in Note 1124553.





4. Start background job BC_SAP_SOAP_RUNTIME_MANAGEMENT.

• Call transaction SM36, and choose Standard Jobs – Standard

Scheduling.

• You must schedule the job hourly.

5. Check the configuration using report SRT_ADMIN_CHECK.

Detailed information regarding each configuration step is part of the SAP Library –Configuring the Web Service Run at:http://help.sap.com/saphelp_nwpi71/help-

data/en/46/abbc05ba0c2a7fe10000000a1553f6/frameset.htm.

Additional information is provided in SAP Note 1043195 - Configuration of the

Web service runtime.

The following screen shot shows the result of check report SRT_ADMIN_CHECK

after configuration the Web Service Runtime for a SAP NetWeaver PI 7.1 system.In this example system five clients have been configured to use Web Services

(clients 000, 001, 111, 112, and 113).

Figure 120: Report SRT_ADMIN_CHECK

Transaction SBGRFCCONF is used to configure bgRFC-specific configurationsand settings. bgRFC does not work, if the supervisor destination is missing. The

supervisor destination is used for internal bgRFC execution and is called by the

configured service user in the linked RFC destination (can be checked using

transaction SM59).


http://help.sap.com/saphelp_nwpi71/helpdata/en/46/abbc05ba0c2a7fe10000000a1553f6/frameset.htm




BIT480 Lesson: Setup Web Service Runtime

Figure 121: Transaction SBGRFCCONF

The destination used, for example SUPERVISOR, can be created out of transaction

SBGRFCCONF directly, when called for the first time. The destination of type 'L'

- Logical Destination – and specifying the Logon_Security information will be

created and can be later on checked with transaction SM59.

Figure 122: Transaction SM59 – SUPERVISOR Destination

Supporting Transactions for Error Analysis

If you are using the SAP NetWeaver PI 7.1 Integration Directory object and a

adapter of type WS (WebService), it could happen that the configuration data is

not completely processed on the Integration Server (ABAP stack) after channel

activation in the directory. The transaction WSTASKCHECK can be used to

check for pending configuration requests.





Lesson Summary

You should now be able to:• Set up the Web Service Runtime environment


Related Information

• SAP Library:

– Configuring the Web Service Run-

time:http://help.sap.com/saphelp_nwpi71/help-

data/en/46/abbc05ba0c2a7fe10000000a1553f6/frameset.htm

– Troubleshooting in the Web Service Run-

time:http://help.sap.com/saphelp_nwpi71/help-data/en/46/4420e292b75e3fe10000000a11466f/frameset.htm

• SAP Notes: 1043195, 1108662, 1110741, 1124553, 1142596, 1149651,

1160961



http://help.sap.com/saphelp_nwpi71/helpdata/en/46/4420e292b75e3fe10000000a11466f/frameset.htm

http://help.sap.com/saphelp_nwpi71/helpdata/en/46/4420e292b75e3fe10000000a11466f/frameset.htm




BIT480 Lesson: Configuration of Web Services

Lesson: Configuration of Web Services

Lesson Overview

In the course of this lesson, an overview of the tools needed to configure Web

Services (providers) and Web Service clients (consumers) is provided. This targets

direct communications (point-to-point – P2P) as well as communications using the

Integration Server of the SAP NetWeaver Integration 7.1 as an integration broker.

Lesson Objectives



scenarios• Use the different configuration tools

Business Example

Your company plans to implement Web service-based scenarios with direct

communication or/and using the PI 7.1 Integration Server as a message broker.

Introduction to Web Service communication and WSReliable Messaging

The foundation for asynchronous communication is the Web Services ReliableMessaging (WS-RM) protocol standard, which ensures a reliable message

exchange between the back-ends.

Figure 123: Implementation of WS Adapter and WS-RM in SAP NetWeaver

PI 7.1

The WS-RM specification describes a protocol that allows messages to

be delivered reliably between distributed applications in the presence of

either software component, system or network failures, and this protocol is







Figure 125: “Sequence”: Definition and Exchange Protocol

WS-RM Implementation:

The SOAP adapter as of today supports already

synchronous and asynchronous Web Service messaging, however, with

proprietary means since there was no standard available before. The WS-RM

protocol is supported using an own adapter running on the Integration Engine

(implemented in ABAP) and not on the Central Adapter Engine (implemented in

Java). The XI 3.0 protocol is still supported, likewise the SOAP protocol forsynchronous and simple, non-modifiable, asynchronous scenarios.

WS-RM in SAP Netweaver PI 7.1 supports:

• Asynchronous messaging (EO, EOIO) based on open WS standard

• Native support through Integration Engine (without Central Adapter Engine)

The implementation of WS-RM offers an abstraction from the Technical

Sequences. The application works with a “Logical Sequence” (ID) and Web

Service Runtime maps this to WS-RM sequences. Thus, transactional behavior

is ensured, which means that on consumer side either all or none of collected

calls are sent to the provider and on the provider-side each call is executed in

a separate transaction.

• Logical Sequence = SOAP Sequence

• Technical Sequence = WS-RM Sequence





System Requirements for Web Services

In the following, SAP NetWeaver Application Server (AS) is used and we assume

that the Web services are provided on the ABAP stack only for older releases. As

of AS JAVA 7.1 Web services can also be provided.

We have to differentiate the following systems based on their available

functionality and roles:

1. AS ABAP 7.0 SP < 14

2. AS ABAP 7.0 SP >= 14

3. AS ABAP 7.1

4. AS JAVA 7.0

5. AS JAVA 7.1

6. Integration Server SAP Netweaver PI 7.1

In the following, we will explain the required tools for WS configuration and then

explain the configuration details for selected scenarios.

Web Service - Configuration Tools

In this part, we will introduce the tools to be used for configuration of Web service

scenarios. The tools will be introduced first with their relation to the used system

types and system releases.

Tools used for AS ABAP 7.0 SP < 14

This section will list the relevant transactions for back-end systems running onAS ABAP 7.0 with an SP older than SP14. The following graphic displays the

important building blocks of Web service configuration on the ABAP side.

Figure 126: Logical Port (Consumer) – Service Endpoint (Provider)





Tools for Service Provider Configuration on AS ABAP 7.0 SP < 14

Transactions Description

WSCONFIG This transaction is used to create the

service provider.

WSADMIN Using this transaction, the created

service provider can be displayed and

locally tested.

WSSPROFILE Using this transaction, document

security and security profiles are

created and activated.

Tools for Service Consumer Configuration on AS ABAP 7.0 SP < 14Transactions Description

SM59 Recommended:

Create a destination to be used.

LPCONFIG Using this transaction, a logical port is

created and configured.

Tools used for AS ABAP 7.0 SP >= 14 and AS ABAP 7.1

This section will list the relevant transactions for back-end systems running on AS

ABAP 7.0 with an SP of SP14 or newer including AS ABAP 7.1.If you use the SAP PI 7.1 direct connection configuration in the Integration

Directory the configuration of your AS ABAP 7.1 back-end can be transferred and

automatically generated in the AS ABAP 7.1 back-end systems. In this case the

transactions are only used for local configuration checks.

Tools for Service Provider Configuration on AS ABAP 7.0 SP >= 14and AS ABAP 7.1


SOAMANAGER Using this transaction, the service

provider is configured.

You need to create and configure a

service endpoint.





Tools for Service Consumer Configuration on AS ABAP 7.0 SP >=

14 and AS ABAP 7.1


SOAMANAGER Using this transaction, the service

consumer is configured.

You need to create and configure a

logical port.

Tools used for AS JAVA 7.0

This section will list the relevant configuration tools for back-end systems running

on AS JAVA 7.0 used as the service consumer only.

Tools for Service Consumer Configuration on AS JAVA 7.0

Configration Tools Description

Visual Administrator (VA) In the VA, you configure the logical

port by specifying the correct service

endpoint URL.

Tools used for AS JAVA 7.1

This section will list the relevant configuration tools for back-end systems running

on AS JAVA 7.1.

Tools for Service Provider Configuration on AS JAVA 7.1

Configuration Tools Description

SAP NetWeaver Administration /nwa

SOA Management → Business

Administration → Web Services

Administration

Configure individual web services.

Tools for Service Consumer Configuration on AS JAVA 7.1


SAP NetWeaver Administration /nwa

SOA Management →

Business

Administration → Web Services

Administration

Configure individual web service

consumers.

Tools used on Integration Server SAP NetWeaver PI 7.1





This section will list the relevant configuration tools on the Integration Server

SAP NetWeaver PI 7.1.

Tools for Integration Server Configuration on SAP NetWeaver PI 7.1


System Landscape Directory

/sld

Configure business systems and

technical system details

Integration Directory In the Integration Directory, the

communication components and the

logical routing is configured.

Outbound direction:

In the Integration Directory com-munication channels of adapter type

WS and receiver agreements.

Inbound direction:

In the Integration Directory com-

munication channels of adapter type

WS and sender agreements.

Direct Connection versus Integration ServerCommunication

Business systems either communicate with each other directly using Web Services

or using the Integration Server in between.

Figure 127: Direct Connection versus Integration Server Communication







For a full blown configuration scenario overview, including which tools to use

on which back-end release, please check out SND and the link provided under

Related Information at the end of this lesson.

Scenarios Using Direct Communications

Direct communication means that back-end systems communicate directly using

WS runtime. The back-end systems can either be ABAP-based or Java-based.

Configuring such scenarios involves the following tasks:

1. Configuring the receiver back-end system as WS provider.

2. Configuring the sender back-end system as WS consumer.

If an environment contains many point-to-point connections, the administration

and maintenance of connections can become quite cumbersome to maintain.This is where SAP NetWeaver 7.1 Process Integration (PI) comes into play. PI

provides a tool and the infrastructure to centrally design, configure, and maintain

point-to-point connections. With PI, message types and interfaces can be designed

in the Enterprise Services (ES) Repository, and connection configuration, and

communication channels can be carried out centrally in the Integration Directory

(ID). All the configuration objects are also propagated automatically to the

corresponding back-end business systems (running on AS ABAP 7.1).

Figure 129: Direct Connection – Configuration Concept










BIT480 Lesson: Services Registry

Lesson: Services Registry

Lesson Overview

In the course of this lesson, the participant will get hints on configuration and the

usage of the Services Registry shipped as an integrated part of SAP NetWeaver PI

7.1.

Lesson Objectives




Registry



Business Example

Your company wants to support an SOA-based infrastructure. You will need a

central services registry for configuration and lookup services. In your landscape,

the Services Registry is to be used for this. Therefore, you wish to learn more

about the Services Registry.

Concept and Interoperability

Why is a Services Registry needed in a service-oriented application architecture?

A registry is usually identified as one of the first requirements of SOA adoption.

In simple terms, a registry is a catalog or index that acts as the system of record for

the services within an SOA.

A services registry is not designed to store the services themselves. It rather

indicates their location by reference. Also, having a centralized catalog of services

is of importance from an organizational perspective because it enables the easy

discovery, reuse, and management of services. A robust registry is an important

component of any SOA governance solution.





Figure 131: Demand for a Services Registry

Another important issue is the interoperability of the registry with other

components of the SOA infrastructure. OASIS provides a platform-independent

standard for registry interoperability known as UDDI (Universal Description,

Discovery, and Integration). UDDI defines a Web services-based programming

interface that allows different consumer applications, tools, and run-time systems

to query the registry, discover services, and interact as required to provide

management and governance capabilities.

UDDI is the most commonly adopted standard and ensures the greatest degreeof compatibility with other products in the environment. The Enterprise Services

Repository contains the model metadata along with the interfaces, its operations

and global data types.

Services Providers implement the services using ESR metadata and then publish

these implemented services in the Services Registry. Consumer tools in turn

access the Services Registry to find the centrally published services with all the

required information to consume it.





Figure 132: Services Registry – Concept

To simplify the search, services are grouped and organized in taxonomies. This

Services Registry information is published in an open standard way complying

with the UDDI V3.0 requirements. The Services Registry can interoperate with

other UDDI registries like Systinet.

Figure 133: Interoperability Services Registry – UDDI V3.0 Server





Interoperability with the third party UDDI V2 server can be achieved as seen in

the following diagram. Typical scenario steps are:

• Install Services Registry

• Install third party Application Server with is built-in service registry

• Unplug SAP NetWeaver's UDDI Server & Plug-in the third party Service

Registry

• Pre-load tModels and perform API tests

• Publish enterprise services from SAP AS ABAP system on to the third party

UDDI server

• Consume the published services from a Web Dynpro application

The Services Registry has a large number of centralization-related benefits. It

enables governance or improves governance for the following, for example:Services management

Standardization

Classification

Definition of procedures

Other advantages are the possibility to centrally define and expose functionality

for configuration, documentation, creation of global taxonomies, and versioning

of Web services. In addition, the consumer is able to configure the Web service

dynamically at runtime, which provides additional flexibility in terms of

performance and service level agreements.

Figure 134: Services Registry in Detail





Figure 135: Services Registry

To access your SAP NetWeaver PI 7.1 Services Registry front-end application,

you have to access first your SAP AS Java server home page and select Services

Registry. The Services Registry will start in a separate window.







The Services Registry implements UDDI Version 3.0 APIs plus three sets of

proprietary interfaces in Java and ABAP:

Classification Services

Additional Services Registry APIs for Java and ABAP

Figure 138: Services Registry – Classification Service

The Classification Service

• Supports classification and browsing in the user interfaces.

• Provides the metadata on different classification systems.

• Provides the content of each classification system, including possible values.

• Supports the dynamic addition of values to a classification system.





The following lists the supported classifications in the Services Registry:

• Deployment unit

– Part of the enterprise service-oriented architecture metamodel .

– Contains a set of process components; for example, SP_HR.

• Process component

– Implements business processes and allows their functions to be used

as services.

– Contains one or more related business objects.

– Can be used in different integration scenarios; for example, HR

Compensation Management.

• Business object

– A set of entities with common characteristics and common behavior

representing well-defined business semantics.

– The set of entities is generally accepted in the business world – for

example, HR Salary Adjustment.

• Lifecycle status

– Informs customers of the development status of objects.

– Determines whether the customer can or cannot use a service and

whether restrictions apply.

• Service Operation

– Part of the Enterprise Service Architecture metamodel.

– Sets of messages related to a single service action.

• Service Interface

– Group of operations in the Enterprise Services Repository

• Software Component Version

– Smallest shipment unit for design objects in the Enterprise Services

Repository and for development objects in the relevant application

system.

– Part of the software catalog in the System Landscape Directory.

SAP offers a Services Registry containing various SAP Enterprise

Services including Cassification data. The Services Registry URL

is http://sr.esworkplace.sap.com/ . For more details and how to get a

test-user for more check out the SDN - Explore Enterprise Services area at

https://www.sdn.sap.com/ir j/sdn/explore-es.


http://sr.esworkplace.sap.com/

https://www.sdn.sap.com/irj/sdn/explore-es



http://sr.esworkplace.sap.com/




Services Registry Configuration

Before you can start using the Services Registry, you must first configure the

UDDI server and set destinations to the UDDI server and the classification service.

Also, Service Registry users have to be assigned to user roles.

Start the SAP NetWeaver Administrator (/nwa) and choose SOA

Management → Technical Configuration → Services Registry Configuration.

Click the icon Services Registry Configuration.

Figure 139: Services Registry – Configuration

Here, you can configure the following UDDI Server and Services Registry

settings under different tabs:

• Configure UDDI Server Settings:

Enables basic settings of the UDDI server.

• Configure Security Policy Properties:

Here, you can set security levels for publishing, replication, discovery,

inquiry, custody, subscription, and value set functions according to the UDDI

v3.0 specifications.

• Export Data from the UDDI Server:

You can export data from a specific UDDI server and also export data aboutthe classification service of the UDDI server. The exported data is in a ZIP

archive file and can be used for backing up the information or exchanging

data between two UDDI servers.

• Import Data in the UDDI Server:

Here, you can import data into the UDDI server. This data must be a ZIP file

that has been exported from an SAP NetWeaver UDDI Server.





To create the necessary destinations, go to the SAP NetWeaver Administrator and

choose SOA Management → Technical Configuration → Destination Template

Management.

Figure 140: Destination Template Management

• Create the destination to the UDDI Server:

– Destination Type: WSDL

– Destination Name: UDDI_DESTINATION

– URL: http://hostname:port/uddi/wsdl/uddi_v3_service.wsdl

The URL used as an example is valid for the SAP UDDI server. If you

are using a non-SAP UDDI server, the URL would be different.

– Authentication: HTTP AuthenticationSelect User ID/Password (Basic) and click Details.

Enter your user ID and the password. If this user is not an administrator,

assign the role UDDI_Admin.





Figure 141: UDDI Destination

• Create the destination to the classification service:

– Destination Type: WSDL

– Destination Name: CLASSIFICATION_DESTINATION

– URL: http://hostname:port/ClassificationService/CS?wsdl

– Authentication: HTTP Authentication

Select User ID/Password (Basic) and click Details.

Enter your user ID and the password. If this user is not an administrator,

assign the role UDDI_Admin.

• Assign user roles to Services Registry users:

– The following user roles are available for the Services Registry:

SERVICES_REGISTRY_READ_ONLY:

This user role allows using the search functions of the Services Registry.

SERVICES_REGISTRY_READ_WRITE:

This user role allows using all functions of the Services

Registry.





Figure 142: Classification Destination

Publishing Enterprise Services to Services Registry – ABAP Usage

To publish enterprise services to the Service Registry from within your SAP

AS ABAP applications, you will first have to set up the connection from your

back-end system to the Services Registry and then publish your developed

enterprise services.

1. Create an HTTP destination to the external Service Registry host using

transaction SM59.

Fill in the hostname, service no., path prefix /ESRegistryWS/BasicAuthCon-

fig?style=document and the logon security parameters.

2. Configure the related logical port using transaction LPCONFIG pointing to

the SM59 HTTP destination.

3. Call transaction WSPARAM to specify an entry for the connected Services

Registry by pointing to the previous created logical port.





Figure 143: Transactions LPCONFIG and SM59

To publish services, proceed as follows:

1. Call transaction WSPUBLISH.

2. Enter the name of the service definition.3. Choose the name of the registry where the service is to be published.

4. In the following subscreen, choose whether the service definition is to be

published with or without end-point information.

5. Choose Force Publication when a service definition is to be published even

if it has already been published.

6. Choose Restrictions if only services that belong to a particular category

are to be published. These categories can be defined in transaction

WSRESTRICT.





Figure 144: Transaction WSPUBLISH

After publishing, it is recommended to check the publication.

Log on to the Services Registry at http://<full qualified hostname>:<HTTP por>/ sr.

Enter your service name in the search area, choose the system and choose Go.

You can display the published services in the Services Registry and the details.

Figure 145: Check Registration in Services Registry – ABAP Usage





APPENDIX - Publishing Enterprise Services toServices Registry - JAVA Usage

To publish enterprise services to the Service Registry from within your SAP AS

JAVA applications, you have to set up the connection from your back-end system

to the Services Registry first and then and publish your developed enterprise

services. Execute the same configuration steps as explained before using the

SAP NetWeaver Administrator.

To publish services, proceed as follows:

1. Start SAP NetWeaver Administration (/nwa).

2. Choose SOA Management → Business Administration → Publication

Restrictions.

3. Click the Create button to create a publication restriction.4. Add a name and a description.

5. Click Next and choose Add Service Definition.

6. Select the service and choose Finish.

7. Verify that the Service appears in the list and that the status is set to Active.

Figure 146: Publishing JAVA Services

After the publishing, it is recommended to check the publication. Log on to

the Services Registry at http://<full qualified hostname>:<HTTP port>/ sr.

Enter your service name in the search area, choose the system and choose Go.

You can display the published services in the Services Registry and the details.





Figure 147: Check Registration in Services Registry – JAVA Usage

APPENDIX - Consuming Enterprise Services fromServices Registry

To discover Web services in the Services Registry from the SAP NetWeaver

Developer Studio, you have to configure the connection between the Developer

Studio and the Services Registry via Window → Preferences → Web services →

Services Registry. Enter the parameters for the UDDI Service and Classification

Service as shown below:

Figure 148: SAP NetWeaver Developer Studio – Configuration for Services

Registry access





The following steps describe how to use the information in a Dynamic Web

Project:

Choose File → New → Project. Choose Web → Dynamic Web Project. Enter a

project name, select the Add project to an EAR option and choose Finish.

1. Choose File→

Import →

Web services→

WSDL→

Next .

2. Select an output location to import the WSDL in one of the folders of the

project created before. Choose Services Registry as WSDL source. Press

Next .

In the dialog window, enter your username and password to log on to the

Services Registry. Choose Ok to go ahead. Enter the search expression in

the Find field. This triggers a lookup for all services. Click on the found

Service Definition in the upper table and then on the endpoint displayed in

the lower table as show below. Choose Finish to trigger the download of theWSDL file. The WSDL import has completed and you can see the file in

your Eclipse workspace now. Next, generate a deployable Web service client

out of the downloaded WSDL from SR. Add the necessary implementation

client code and deploy the ear file on to the server.

3. In the dialog window, enter your username and password to log on to the

Services Registry. Press Ok to go ahead.

4. Enter the search expression in the Find field. This triggers a lookup for all

services. Click on the found Service Definition in the upper table and then

on the endpoint which is displayed in the lower table as show below.

5. Choose Finish to trigger the download of the WSDL file. The WSDL importhas completed and you can see the file in your Eclipse workspace now.

6. Next, generate a deployable Web service client out of the downloaded

WSDL from the Services Registry. Add the necessary implementation client

code and deploy the ear file on to the server.

Figure 149: SAP NetWeaver Development Studio – Consuming Enterprise

Services from Services Registry





Summary

Figure 150: Services Registry – Connectivity Overview

• The Services Registry provides visibility in an SOA landscape, which

enables search and browsing of services by classification.

• The Services Registry offers interoperability options with third party

Registries.

• The Services Registry acts as a central system to find the available service,

the endpoints and manage the connections between consumer and provider

systems.

• The Services Registry can be used by both SAP and non SAP applications.

• Both ABAP and Java tools can be used to publish services to a service

registry.





Lesson Summary

You should now be able to:• Configure the Services Registry


Registry







Lesson: Mass Configuration

Lesson Overview

During this lesson the feature of mass configuration of Web Services is covered.

You would like to configure a set of Web services at one go with identical runtime

configuration settings. How the mass configuration can be done will be explained

in this lesson.

Lesson Objectives


• Know how mass configuration of Web service can be executed

Business Example

When you want to configure a set of Web services at one go, you have to

first group the relevant Web services which need to have identical runtime

configuration settings. Mass Configuration allows you to group Web services in

configuration scenarios and apply settings to one or more of those Web services by

assigning configuration profiles them.

Mass Configuration

Looking at the configuration of Web Services there are two aspects to be

considered. The provider side and the consumer side. The provider is offering

certain functionality in form of a web service that can be called by a consumer

described in a well defined way. The consumer in turn expects the functionality of

the web service to be offered in a certain way according to the description of the

web service. Both sides have to be configured appropriately. In an environment

of a larger scale there is a need for means to configure the mass of Web Services

efficiently.




BIT480 Lesson: Mass Configuration

Figure 151: Basic Web Service communication Use Cases

Here we look at the two aspects of Mass Configuration of Web Services (Provider)

and Web Service clients (Consumer).

Configuring Web Service providers







Configuring Web Service Consumers

When it comes two configuring Web Service consumers there

are two ways to do it as well, either one by one or in a bundle.

• Configure individual Web service clients

You apply configuration settings directly to every individual Web service

client. This approach is suitable when you want to configure a small number

of Web Services. You configure individual Java Web service clients in

the SAP NetWeaver Administrator from SOA Management → Business

Administration → Web Services Administration.

Hint: More information about the steps you need to complete to

configure an individual Web service:

Configuration of Individual Web Services and Web Service Clients

http://help.sap.com/saphelp_nwpi71/help-

data/en/46/8c19c6bba66160e10000000a1553f7/frameset.htm

• Configure several Web service clients running on the same consumer

system

This approach allows you to configure one or more Web service clients

which run on the same consumer system, for example System A, to consume

one or more Web Services which run on the same provider system, for

example System B. You can configure Web service physical destinations in

the SAP NetWeaver Administrator from SOA Management →

TechnicalConfiguration → Destination Template Management.

Hint: More information about the steps you need to complete to

configure an individual Web service:

Configuration of Several Web Service Clients

http://help.sap.com/saphelp_nwpi71/help-

data/en/46/8c19c6bba66160e10000000a1553f7/frameset.htm

Mass Configuration for Providers


http://help.sap.com/saphelp_nwpi71/helpdata/en/46/8c19c6bba66160e10000000a1553f7/frameset.htm







In the following diagram two roles and background tasks in the configuration

process flow have been identified:

1. Technical Administrator

The Technical Administrator knows what technical configuration settings or

policies need to be applied to the service definitions that are part of a business

scenario. He or she prepares the relevant runtime configuration settings in

one or more configuration profiles in advance. A configuration profile is a

set of policies that need to be applied to a set of service definitions to meet

the needs of a business scenario. You can think of configuration profiles

as a placeholder for the runtime settings that need to be applied to service

definitions. The Technical Administrator does not apply the configuration

settings directly to the service definitions.

2. Business Administrator

The Business Administrator decides which service definitions in a business

scenario to configure and expose for consumption with which runtime

settings.

The Business Administrator:

• Groups service definitions in one or more logical units called

configuration scenarios.

A configuration scenario is a logical group of service definitions. You

can think of a configuration scenario as a worklist containing the service

definitions necessary to complete part of or the whole business scenario.• Assigns the configuration profiles prepared by the Technical

Administrator to one or more service definitions grouped in a

configuration scenario.

By assigning a configuration profile to service definitions, the Business

Administrator triggers the configuration of the respective service definitions.

This means that the Business Administrator triggers the creation of a

service endpoint for every service definition to which he or she assigns a

configuration profile.

3. Profiles – Service Definition Assignments

When a configuration profile is assigned to a service definition, thesystem creates a service endpoint for this service definition. The Business

Administrator does not explicitly create the service endpoints of service

definitions. The actual creation of service endpoints is performed by a

background job which runs at a present interval (5 minutes).





Figure 152: Mass Configuration: Providers

In this example you have three service definitions which are necessary to complete

a leave request process flow in an HR scenario:

HR_LeaveRequest_Service_1



The scenario has the following requirements:

• Basic HTTP authentication level must be configured for all service

definitions.

• Web service reliable messaging must be configured only for

HR_LeaveRequest_Service_2, and HR_LeaveRequest_Service_3. As a

prerequisite, Web service reliable messaging (WSRM) was enabled for these

two service definitions at design time in the SAP NetWeaver Developer

Studio.





To meet these needs for the configuration of the service definitions:

1. The Technical Administrator creates a configuration profile

HR_LeaveRequest_Profile in which he or she configures the actual settings

for the authentication level and WSRM as required.

2. The Business Administrator groups all three service definitions in a

configuration scenario, called HR_LeaveRequest_Scenario.

3. The Business Administrator assigns HR_LeaveRequest_Profile to all three

service definitions in HR_LeaveRequest_Scenario. In this way he or she

triggers the actual configuration of the service definitions.

4. The next time the background job is executed, the system creates one service

endpoint for each of the three service definitions. The service endpoints

contain the relevant settings of the configuration profile.

As a result, all three service definitions are configured with the requiredauthentication level, and WSRM is configured only for two of them:

HR_LeaveRequest_Service_2, and HR_LeaveRequest_Service_3.

Configuration Scenarios and Configuration Profiles:

• A configuration scenario comprises a list of service definitions, to which you

can assign a configuration profile.

• The same service definition can be active within multiple configuration

scenarios.

• You can create multiple configuration scenarios for your systeminfrastructure.

• A configuration profile can be applied to one or more service definitions

in a configuration scenario.

• The same service can be applied to multiple configuration profiles.

The following requirements apply to

Mass Configuration:

• Provider services/proxies must already exist.

• Currently, only WS configuration is supported.• ABAP proxies must use transaction SOAMANAGER

• Java proxies must use /nwa

• Mass configuration is not available from /nwapi

• Supports both P2P and brokered communications





Mass Configuration Steps -

ABAP:

1. Create Configuration Profile:

• Call transaction SOAMANAGER .

• Select tab Technical Configuration.

• Select Profile Management .

• Select Create and specify your new profile name.

• Save your profile.

• Finally Activate your profile.

2. Create Configuration Scenario:• Call transaction SOAMANAGER .

• Select tab Business Administration.

• Select Mass Configuration.

• Select Create and specify your new configuration scenario.

Add Consumer Group (optipnal).

Add Provider Services.

• Save your profile.

• Finally Activate your configuration scenario.





Figure 153: Mass Configuration Steps – ABAP

Mass Configuration Steps - Java:

1. Create Configuration Profile:

• Call SAP NetWeaver Administrator /nwa .


• Select SOA Management .

• Select Technical Configuration.

• Select Profile Management .

• Create New Profile and specify your WS properties.

• Press Finish.

2. Create Configuration Scenario:


• Select SOA Management .

• Select Business Administration.

• Select Mass Configuration.

• Create and specify your scenario.

• Add Service Definition.

• Finally Assign your profile.

• Finish your scenario maintenance.





Figure 154: Mass Configuration Steps – Java





Lesson Summary

You should now be able to:• Know how mass configuration of Web service can be executed




BIT480 Unit Summary

Unit Summary

You should now be able to:




scenarios

• Use the different configuration tools



Registry


the Service Registry• Know how mass configuration of Web service can be executed




Unit Summary BIT480




Unit 3 SOA Management – Monitoring

Unit Overview

At the conclusion of this unit, you will have an overview over the Monitoring

features and functions of SAP NetWeaver PI. You will learn, which component

could be monitored with which adequate tool of various provided monitoring tools.

Unit Objectives


• Know about components of the SAP NetWeaver PI Monitoring Landscape

(CEN, Solution Manager, Wily Introscope, NWA, NWAPI)

• Get familiar on how to monitor Web Service communication

• Get along with SAP NetWeaver PI components (including local Integration

Engine in back-ends, Non-Central Adapter Engine) and their monitoring

tools

• Understand how SAP supports customer systems by remote connections

and Early Watch Alert.

• Explain CCMS and SAP PI Monitoring Template and Engine relevant

templates (J2EE Engine, DB, Filesystem, qRFC/tRFC, Network, SYSLOG,

Dumps, GW, ICM, WebServices etc.)

• Outline how to setup GRMG (heartbeat) monitoring

• Know details about PI monitoring tools RWB, NWAPI, and Solution

Manager

• Understand the Process Monitoring Infrastructure (PMI) functionality

• Be familiar with the list of reoccurring tasks for continuous availability (DBGrowth, Filesystem check, Index Rebuilds, etc.)

• Appreciate the differences of Alerting (CCMS – Alerting, Alert Framework)

and active monitoring (On Demand with RWB).

• Be aware of how to monitor ccBPM (transaction for BPE Monitoring)

• Configure the message based Alerting

• Know how on demand monitoring can be done with SAP NetWeaver PI

• Know how to detect bottleneck situations (Performance Monitor, SMD

Dashboards).




Unit 3: SOA Management – Monitoring BIT480

• Realize to avoid bottleneck situations > Performance By Design – Single

Processing of Messages versus Throughput Optimization

Unit Contents

Lesson: SAP NetWeaver PI Monitoring Landscape... .. .. .. .. .. .. .. .. .. .. .203Lesson: System & Component Monitoring ..................................228

Exercise 3: System & Component Monitoring Exercise. .. .. .. .. .. .. .. 255

Lesson: Monitoring Activities - On Demand or Alerting Based ...........259Exercise 4: Create and Define Alerting Rules .. .. .. .. .. .. .. .. .. .. .. .. .. 273

Lesson: Performance Monitoring .. .. .. ... .. .. .. .. ... .. .. ... .. ... .. .. .. .. ... ..279Exercise 5: Performance Monitoring Exercise.. .. .. .. .. .. .. .. .. .. .. .. .. 285


http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-







BIT480 Lesson: SAP NetWeaver PI Monitoring Landscape

Figure 156: CEN Architecture in Detail





To set up a SAP System as a Central Monitoring System, there are a few steps that

have to be performed in the system which should be used as the CEN System.

• Create the CSMREG User:

A communication user is necessary with restricted

authorizations in all ABAP systems of the system landscape for

communication between the CEN, and the monitored systems. (See Creating

the CSMREG User). The user is created in the following way, start

transaction RZ21, choose Technical Infrastructure → Configure Central

System → Create CSMREG User , and enter any password for this user.

• Activate Background Dispatching:

Some of the monitoring data of the monitoring architec-

ture is collected by using data collection methods, which are periodically

executed as jobs. A prerequisite that these methods are started correctly,

background dispatching must be activated in all of the ABAP systems of your system landscape (see Activating and Deactivating Method Execution).

To activate background dispatching, start transaction RZ21, and choose

Technical Infrastructure→

Local Method Execution→

Activate Background

Dispatching.

• Activate the Internet Communication Manager (ICM):

The Java and Web Components use the Generic Request and Message

Generator for availability monitoring. For that, the ICM has to be

configured and activated in all ABAP systems of your system landscape (see

Administration of the Internet Communication Manager).

• Activate Central System Dispatching:

Auto-reaction methods are part of the monitoring architec-

ture which are started automatically in the case of an alert. By default,

these methods are executed in the system in which the alert occurs. If

these methods have to be started in CEN, you have to activate central

system dispatching (see Activating and Deactivating Method Execution).

To activate central system dispatching, start transaction RZ21, and choose

Technical Infrastructure → Configure Central System → Activate Central

System Dispatching.

• Register Monitored Components with CEN:

To display monitored components in CEN, it is necessary to

register them in CEN (see Register SAP NetWeaver Components and Hosts

in CEN in the SAP library http://help.sap.com).

• Availability Monitoring with CCMSPING:

You can use the availability agent CCMSPING to monitor

the availability of ABAP and Java instances and systems. Install the agent

once on any host and it has to be registered with CEN.

The CEN system in your landscape could run on the SAP Solution Manager or

could be a separated installed system.

SAP Solution Manager


http://help.sap.com/

http://help.sap.com/




The SAP Solution Manager provides scenarios for all phases of the application

management life cycle including support for:

• Implementation of SAP solutions

• Upgrade of SAP solutions

• Change Request Management

• Service Desk

• Solution Monitoring

• Root Cause Analysis

Figure 157: SAP Solution Manager

In the following we would like to focus on the Solution Monitoring and Root

Cause Analysis functionality.





Figure 158: Solution Manager - Solution Monitoring and Root Cause Analysis

• The SAP Solution Manager provides all functionality to monitor and

administer the whole System landscape

• The Landscape information system is used for administration of all server

and system data.

A key requirement for efficient and safe support of IT solutions is the ability to

perform root cause analysis with speed and efficiency. Solution Manager provides

all functionality to centrally analyze and monitor a complete SAP NetWeaver

system landscape.

SAP Solution Manager Diagnostics provides the following functionality:

• Thread Dump Analysis:

Central triggering and scheduling of JVM based

thread dumps for a certain or all J2EE node(s), gathering and transfergenerated thread dumps and analysis of the thread dump data via appropriate

user interface

• Java Memory Management

• Workload Analysis and more





Figure 159: E2E Workload Overview

The screenshot above shows the E2E Workload Overview.

On the right hand side of the picture we can see the following KPIs which are

dedicated to PI:

• Average RFC response time in milliseconds

This is interesting as all the operations that are performed in

PI/XI are performed within RFC queues, i.e. the average RFC response timeis the average of all the XI operations on the ABAP side.

• Average HTTP response time in milliseconds

This is the time taken to receive the messages from Java to ABAP (sent via

HTTP).

• Average Latency of Async/Sync Messages in milliseconds

This indicates the time that the messages had to wait before getting processed.

It is the difference between the time when the entered the integration engine

and the time when the exited the integration engine (ABAP times only).

• Average number and average size of Async/Sync messages

This data is captured from the ABAP Stack.







The information displayed on this screen is provided by the SAP NetWeaver PI

environment via a Web Service. This Web Ssrvice provides information on all the

messages processed within the Adapter Engine (JAVA stack). This Web Serviceis invoked once per hour by the extractor framework of the Solution Manager.

The screen is split into 2 sections: Sender and receiver side.

From the SAP NetWeaver PI point of view, the sender side means the “outbound”

direction. The sender side is the adapter side that will receive the messages from

the external system (outbound message from the external system point of view). .

Figure 161: J2EE Mapping Requests of SAP NetWeaver PI

The information displayed on this screen comes from 2 different sources:

• Client View of Mapping Requests:

– Comes from SAP NetWeaver PI, via a Web Service

• Server view of Mapping Requests:

– Comes from Wily Introscope

– Can be viewed “live” in the section “SAP NetWeaver PI Mapping

Overview” from the home dashboard: “0. SAP Overview (Site Map)”

The difference is that the Server view provides the mapping program name. Incase of a graphical mapping, this name can be used directly in the Integration

Builder Tools to locate the mapping itself (just remove the leading and trailing ‘_’

character to perform a search).

The important KPIs are displayed:

• Number of executions

• Total time (in milliseconds)

• Min, max and average time (in milliseconds)





This helps to identify why a mapping is slow, or does it have

a high response time because it is heavily called (high number

of executions) or is it because of the mapping processing itself?If more information is needed then a Transaction Trace with Wily

Introscope will give further information on the runtime operations.

Wily Introscope

Wily Introscope is a system management tool to manage Java Application

performance. It allows you to monitor and manage your application performance

in live production environments. Wily Introscope is installed as part of SAP

Solution Manager to give SAP support better visibility into technical issues you

may experience. You will also get access to Wily Introscope so that you can

analyze performance problems on your own.

Figure 162: Wily Introscope Architecture

The Wily Introscope tool includes the following features:

• Central monitoring of multiple systems

• Dynamic instrumentation measurement points can be customized via

config-files, no code changes necessary (as opposed to JARM).

• Live and Historical Data Performance data of recent days can be viewed in

detail (current historical range is configured to 14 days).

• Powerful graphical tools for displaying / evaluating data

• Highly customizable

SAP provides customization (instrumentation and so-called management

modules) for SAP J2EE, SAP EP, SAP XI/PI, SAP CRM, and more to come

• Integration with SAP End to End Trace for scenario analysis





Wily Introscope requires the following components:

• Introscope Enterprise Manager (server component)

The Enterprise Manager is typically installed on the Solution

Manager host. Alternatively, you can install the Enterprise Manager on

a separate host. The memory and CPU requirements for the Enterprise

Manager depend on the number of Introscope Agents that you connect and

on the complexity of the monitored systems. More details on Enterprise

Manager Sizing and self-monitoring can be found in the FAQ attached toSAP Note 797147.

• Introscope Java Agent (on the managed systems)

The installation files have to be copied to each monitored host

once. For each Java server node you set Java VM parameters to activate theagent. After activation by restarting the Java VM, the agent runs within

the Java process of the monitored system. The setup of the Java agent is

typically done centrally via a setup UI in Solution Manager Diagnostics.

• Host-Level Introscope Agent (on the managed systems)

The so-called Introscope Host Agent is installed once per host. It runs as

part of the SMDAgent in the SMDAgent process to collect data on operating

system level, e.g., from saposcol, GC logs, ABAP instances, and TREX. The

Host Agent generates less load on the Enterprise Manager than a normal

agent. For this reason, it should not be included in the memory sizing

calculation above. The Host agent is configured automatically by the SMD

setup wizard for managed systems. In previous releases, the IntroscopeEnvironment Performance Agent (EPAgent) took the role of the host-level

agent. The EPAgent is now replaced by the host-level agent. The EPAgent is

no longer supported.

• Optionally, you can install the Introscope Workstation on the Enterprise

Manager host or any client PC and/or deploy Introscope WebView on the

SAP NetWeaver Web Application Server.

Using the Introscope Instrumentation for SAP NetWeaver PI:

• Adapter Framework

– Provide the size during runtime of the 4 different queues:

1) Synchronous-Outbound

2) Synchronous-Inbound

3) Asynchronous-Outbound

4) Asynchronous-Inbound

– Monitor all the DB transactions (commits):

Successful and Failed

– Monitor the XI message sizes.





Figure 163: Incoming Messages in the AFW Queues

• Mapping

– The Mapping overview dashboard shows the cumulated time for all the

mappings (for each server node). Expensive mappings immediately

stand out.

– For each Mapping on the detailed screen

the following information is provided:

1) Cumulated time in milliseconds

2) Average response time in milliseconds

3) Number of invocations





Figure 164: Mapping Information

• Adapter Module Processor

– This dashboard shows the cumulated time for all the module processors

(for each server node). The time consuming module processors

immediately stand out.

– For each Module Processor on the detailed

screen the following information is provided:

1) Cumulated time in milliseconds

2) Average response time in milliseconds

3) Number of invocations









Figure 167: Monitoring Architecture with NWA

Sequence Monitoring

The WS-RM procotol ensures that message exchange between a service provider

and a service consumer is completed without any fault. In this case messages are

combined into sequences. With the analysis tools of the sequence monitor, anyerrors that occur during transmission can be found and removed. The Sequence

Monitoring can be accessed via the NWA for PI or via SOAMANAGER by

choosing the Monitoring tab and then Sequence Monitoring. The Sequence

Monitor is used to monitor the sequence status and to end/restart sequences with

errors in emergency situations.





Figure 168: Access Sequence Monitoring via NWA for PI (/nwapi)

Figure 169: Sequence Monitoring - Error Analysis





Within sequence overview pane, sequences can be either rejected, closed, or

restarted

• Reject:

Sequence is closed and removed regardless of whether any item

has status In Process

• Close:

All pending messages will be first processed before sequence termination,

new messages won’t be accepted any more

• Restart:

Restart is possible for failed sequences only

Background RFC (bgRFC)

The bgRFC allows applications to record data that is received later by a called

application. When the data is received, it has to be ensured that the data was

transferred to the receiver either once only in any order (transactional) or once

only in the order of creation (queued). Due to the fact, that the processing of units

take places asynchronously, there is a monitor if queues are stopped if a certain

unit has been processed, which function modules have been registered, and which

queues a unit is in. The following monitor should only be used if the Web

Service sequences could not be corrected via theWeb Sequence Monitoring

tool explained before.

The tasks for bgRFC Monitoring could be to check for

• a queue, which might be stopped

• a unit, which might to be debugged

• a forgotten lock, which might to be released

The bgRFC Monitor on ABAP stack is started via transaction SBGRFCMON.

From here you can monitor bgRFC units of type Q (Queued) and type T

(Transactional).





Figure 170: bgRFC Monitor

The first selection of this transaction is to choose the client (inbound or outbound)

and restrict destination and queue name. Another option is to look at locked or

erroneous queues. If entries are available they will be listed with their current state.

• Green state: The units of this destinations will be processed by the scheduler.

• Yellow state: The destination is locked and the scheduler will not execute

any unit of this destination

• Red state: An error has occurred

By double click on a queue name the list on the right side appears with the first

units registered to the queue. The first units are those, that the system will execute

next. Below the queue, there are more details, for example the state of the queue

and the number of units that are executable. There are two buttons in the left side

of the screen. “Lock Destination”and “Delete Queue Lock”. With the first one,

the destination gets locked which keeps the scheduler from further processing of entries for this destination. This affects all units of this destination no matter if they

are type T or type Q units. The second button is for unlocking of a unit. Any unit

lock will become a queue lock if the unit has reached the first position in a queue.

Web Service Logging and Tracing

SAP PI 7.1 provides the new functionality to communicate via the Web Service

(WS-RM) protocol with other systems and applications.









Engine with URL http://<full qualified hostname>:<HTTP port>/ mdt.

In the Runtime Workbench, the Non-Central Adapter Engine appears in

the selection Non-Central Adapter Engines in the component monitoring.To choose this component for the Message Monitoring the usage is similar

to the Central Adapter Engine, because both Adapter Engines (Central and

Non-Central) are monitored from the SAP NetWeaver PI system centrally.

You just have to select the type of Adapter Engine you want to monitor from the

selection and the following selection screen is identical.

Figure 173: Message Monitoring of the Non-Central Adapter Engine

This screenshot shows the Message Monitoring of the SAP NetWeaver PI with

the functionality to filter the messages which should be displayed by the chosen

Adapter Engine only.





SAP Support via Remote Connections andEarlyWatchAlert (EWA)

SAP Support offers the customer the EWA Service. In cases of Problems the

access via Remote Connection to the System has to be established. For more

details how to setup the Remote Connections and the EWA, there are SAP Notes

available in the SAP Marketplace which contains the newest information.

• Setup the Remote Connections (SAP Note 91488)

• Set up the EWA Service (SAP Note 207223)

Early Watch Alert for NetWeaver PI offers the following:

• Proactive, automated service on weekly basis

• Running in Solution Manager

• Included in maintenance fee

• Detailed Service Report with Ratings

• Detects critical issues in performance and stability

• Should be set up for all production systems in your landscape

The value proposition is:

• Minimize the risk of downtime

• React to issues such as bottlenecks before they become critical

The objectives of the EWA are:

• Prevent bottlenecks

• Identify potential problems at an early stage

• Provide regular and automatic performance monitoring of SAP components

• Provide regular reports

The EWA covers the following Monitoring Areas;

• General component status

• System configuration

• Hardware

• Performance development

• Average response times

• Current workload

• Critical error messages and process interruptions





There are additional monitoring areas for SAP Netweaver XI/PI:

• Message volume

• Message processing performance

• Top 20 Messages

• Message-based workload distribution

• XML Errors

SAP and Customer are notified of critical problems via RED rated EWA reports.

• EWA provides overview of system status

– Basis for further analysis

– Ensures focused analysis

• SAP quickly addresses critical problems in customer system:

– Initial analysis may provide solution

– Further maintenance sessions allow focus on critical problem

– Service Planning ensures customer receives suitable service





Lesson Summary

You should now be able to:• Know about components of the SAP NetWeaver PI Monitoring Landscape





tools







Lesson: System & Component Monitoring

Lesson Overview

This lesson describes the details of the Computer Center Monitoring System

(CCMS) and SAP NetWeaver PI monitoring tools, including how to setup and use

CCMS for SAP NetWeaver PI specific monitoring tasks.

Lesson Objectives




Dumps, GW, ICM, WebServices etc.)• Outline how to setup GRMG (heartbeat) monitoring


Manager


• Be familiar with the list of reoccurring tasks for continuous availability (DB

Growth, Filesystem check, Index Rebuilds, etc.)

Business Example

A SAPNetWeaver PI system has recently been installed in the system landscape of

your company and messages are already processed. You want to know which tools

SAP provides for system and component monitoring, how to configure them and

how to use them for system monitoring.

CCMS Monitor Templates

An overview of all available CCMS Monitoring Sets is shown with transaction

RZ20. By default, there are several categories, but of course it is possible to

create own Monitoring Sets and fill them with specific monitoring Informations

from several categories, for example Database, J2EE, or qRFC information. The

Monitoring Set SAP CCMS Technical Expert Monitors includes a huge amount

of monitoring tree elements (MTEs) which are available in this system. Afterthe installation of SAP NetWeaver PI, the following CCMS Monitoring Sets are

available by default.




BIT480 Lesson: System & Component Monitoring

Figure 174: CCMS Templates Overview

In this lesson, the following CCMS templates are examined in more detail:

• J2EE Engine• Database

• Filesystems

• Process Integration

• Syslog

• Communications





J2EE Engine

Figure 175: SAP J2EE Monitor Templates - Engines

The monitor set SAP J2EE Monitor Templates provides the most importantmonitors for monitoring AS Java and about all monitored Java instances. As it

is displayed in the screenshot, this J2EE Template is available for J2EE 6.40 or

newer. The information covers, among others, the following topics:

• Status of the instance and its associated processes

• Threads and sessions of the Java instance

• Memory management of the Java instance (heap)





Database

Figure 176: SAP CCMS Monitor Templates - Database

This monitor is used to monitor the underlying database system. The monitorprovides, amongst other things, information and alerts for the following areas:

• Backing up and restoring data

• Database system check: consistency and profile

• Possible storage space problems

• Performance of the Database





Filesystem

Figure 177: SAP CCMS Monitor Templates - Filesystems

This monitor provides informations of the Operating System Monitor, which

provides all of the values collected by SAPOSCOL, the operating system collector.

This monitor is used to monitor filesystems of the host systems and application

servers and to check if there is still enough free disk space available. The values

are collected by the operating system collector SAPOSCOL. It is also possible

to monitor this data with the operating system monitor, which is assigned as the

analysis method for most of the nodes of this monitor.





Syslog

Figure 178: SAP CCMS Monitor Templates - Syslog

With the Syslog monitor, the system log for the various application servers of your

system are monitored. The messages in the system log are grouped into subtrees

linked by topic. The subtree in which an alert is reported depends on the category

of the message. You can set these categories using the message ID in transaction

SE92 (Maintain Syslog Message). Also the message text and the severity and

criticality of the alert could be set by using this transaction.





Communications

Figure 179: SAP CCMS Monitor Templates - Communications







Web Services Monitor

Figure 180: SAP Web Service Monitor Templates - Web Service Monitor

The Web Service Runtime monitor triggers an alert if problems occur during the

configuration of the Web service runtime, if there are runtime errors of different

error categories, and whenever there are performance bottlenecks after certain

threshold values have been exceeded.







After this, the following information are displayed in this monitoring set:

• All used clients (Integration Server and Integration Engine of Application

Systems)

• QRFC Queues

• Business Process Engine

• Java Components

• Message Failure

Generic Request and Message Generator: (GRMG)

The Generic Request and Message Generator (GRMG) is used for monitoring the

availability of technical components and entire business processes. GRMG is

qualified for technical and application monitoring, the following applications canbe monitored with the GRMG Monitoring:

• Customer Relationship Management

• SAP Process Integration

• Portal Infrastructure

• TREX

• SAP Business Intelligence

• Web AS Java

• Adobe Document Services

In this lesson, the focus is on using the GRMG for SAP NetWeaver PI spececificcomppnents. It is important for PI Java components, e.g. an Adapter Engine,

which should be monitored for heartbeat of this component in the CCMS monitor.

The heartbeat will be implemented based on the GRMG framework of CCMS.

All Java component which should be monitored have to be defined in a GRMG

scenario. This is done by writing a corresponding XML specification and

importing it with transaction GRMG. A template for such a CRMG customizing

file is provided with SAP Note 634771. Use this template and refer to this note

for more information.





Figure 182: GRMG Scenario Customizing

After the upload of the XML Template, it is necessary to start the GRMG scenarios.

As soon as they are running, they are visible in the GRMG monitoring set.





Figure 183: CCMS Technical Expert Monitors - GRMG Selfmonitoring

For Heartbeat Monitoring of Non-SAP application, a GRMG lite scemario can

be used. In this case, a HTTP call to the remote application or URL is done and

with the response of the call the heartbeat is evaluated.

SAP NetWeaver PI - Monitoring Tools

The monitoring of the different components of SAP Netweaver PI

is done with different tools. The reason for that are the different

components which are placed in different stacks. In the section above,

the CCMS Templates for Monitoring the ABAP stack and JAVA stack

were shown and in this chapter the specific PI monitoring is considered.

The following tools are available for SAP NetWeaver PI specific monitoring:

• Runtime Workbench (RWB)

• Solution Manager Diagnostics

• NetWeaver Administrator for PI (NWAPI)

Runtime Work-

bench

The Runtime Workbench is the collection of PI specific monitoring tools. It

is called via transaction SXMB_IFR and by choosing the Runtime Workbench

link. Alternative it can be started directly with the URL http;//<full qualified

hostname>:<HTTP port>/ rwb.





Figure 184: Tools Start Page

By choosing the Runtime Workbench a new screen appears in which the monitoring

tools for PI can be chosen.

Figure 185: Runtime Workbench







Figure 187: Message Monitoring

• End to End Monitoring:

It is used in the following cases:

– To monitor message each processing steps in a number of SAP

components (to be configured).

– To monitor the path of individual messages through these SAP

components, from start to end





Figure 188: End to End Monitoring

• Performance Monitoring:

The data comes from the Integration Server (IS) or

the Process Monitoring Infrastructure (PMI). In the Performance Monitoring,

the following data can be displayed:

– Display of the aggregated overview data on the performance of

message processing in a specific PI component.

– Display of the individual overview data on the performance of message

processing in a specific PI component. It displays the start and end of

successful message processing for each component.

– Display of the aggregated detail data on the performance of message

processing in a specific PI component. It uses a time stamp to record

the time of particular processing steps, depending on the component.

– Display of the individual detail data on the performance of message

processing in a specific PI component. It uses a time stamp to record

the time of particular processing steps, depending on the component.





Figure 189: Performance Monitoring

The Performance Monitoring is more in detail described in a separate upcoming

lesson.

• Index Administration:

With this feature, it is possible to search formessages which ware previously indexed. A requirement is the search and

classification engine TREX for indexing and searching documents. For

further details see upcoming lesson.

• Configuration:

You select and configure components for the following reasons:

– As a prerequisite for end-to-end monitoring.

– If you want to use the Process Monitoring Infrastructure (PMI) to

compile runtime data and display it in performance monitoring.

• Alert Configuration:You use the alert configuration to have the system

inform you of errors during message processing. You can receive the

alert by e-mail, fax, or SMS. In each case you will also find the alert

in your alert inbox.





Figure 190: Alert Configuration

• 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. You can also callthe alert inbox directly by calling transaction ALRTINBOX. You can

execute the following activities in your alert inbox:

– Confirm alerts and start a follow-up action: Confirmed alerts disappear

from the inbox. You can also confirm alerts by e-mail, fax, or SMS.

This also causes them to disappear from your alert inbox.

– Forward alerts to another user

– Refresh the alert display

– Subscribe or unsubscribe to the alert categories that you are permitted

to use, in order to receive or not receive the corresponding alerts

– Personalize alert delivery to meet your requirements. You can choosethe type of delivery you want to use and a representative.





Figure 191: Alert Inbox

• Cache Monitoring:

Cache monitoring displays objects that are currently in the runtime cache of

either of the following receivers (cache instances) of cache data:

– Integration Server (ABAP Cache)

– Adapter Engine (Central and Local)

– Mapping Runtime Cache (Adapter Engines)– Business Systems (with Web Service Communication)

In cache monitoring, different cache objects are monitored depending on the

cache instance concerned. Selection criteria are available for each cache

object; you can use these selection criteria to search for current objects in the

runtime cache. A table of hits is displayed. The content of this table varies

depending on the cache object you have selected. For most cache objects,

you can display details for individual hits from the hit list. To do this,

select the radio button in the first column of the relevant line. Regardless

of which cache object you select, you always have the option of calling a

Notification Table that displays information about runtime cache updates and

any problems that arose. A Status Table lets you display the status of the lastcache update for each cache instance.

NetWeaver Administrator for PI (NWAPI)





The NWA for PI is the entry point for monitoring an entire SAP NetWeaver PI

system landscape comprising ABAP and Java systems. It can be accessed from the

PI Tools Start Page or at: http://<full qualified hostname>:<HTTP port>/ nwapi.After the Login, it displays an overview of the PI domains in your SLD with

all the components involved.

Figure 192: NWAPI - PI Overview

The following are the main functionalities available in NWA for PI:

• Message Monitoring

• Performance Monitoring

• Cache Monitoring

• Alert Inbox/Rules

• End to End Monitoring

• Adapter Monitoring

• Communication Channel Monitoring (Adapter Engine)


• Web Service Logging and Tracing

Configuration of the NWA for PI usage

Before the NWA for PU can be used, some configuration steps are required.

In the NWA (/nwa) execute the command: Configuration Management →

Scenarios → Configuration Wizard

• Execute the template “NWA for Double Stack System”

or for a Java Only system execute the template “Configure NWA for Java

System”.

• Execute the template “NWA Add Managed System” to add the remote

system as a managed system for NWA.





Figure 193: NWA Configuration

To perform the NWA Configuration check current version of SAP Note 1160261.

PI Monitor – Mapping Runtime

Figure 194: Mapping Runtime

In the Status-Monitoring for the Mapping Runtime, the technical status is displayed.

Important Information in this monitor are:.

• Availability status of this component

• Availability status of the Exchange Profile







Figure 196: Integration Engine

This monitor shows all technical informations of the Integration Engine.

Important are the following status information:

• Is the SLD reachable?

• Does the Integration Engine knows the Business System?

• Are roles in SXMS_CONF_ITEMS and SLD consistent?

A Message Summary of the actual day is further displayed with which the statusof the processed and failed messages are provided. The next section on the screen

(Common Tasks) provides useful links to jump directly to the following tools:

• Message Monitoring

• Performance Monitoring

• Cache Monitoring

• Alert Inbox

• Web Services Logging and Tracing

• End to End Monitoring


Additional some related links are given, which are used for the daily work with

the PI administration.

Process Monitoring Infrastructure (PMI)





Process Monitoring allows to monitor the universal process, which comprises

multiple components. In this case, the different steps of process are important,

not the status of the components involved, as is the case for system monitoring.The Process Monitoring Infrastructure provides the features for monitoring and

analysis of technical process instances in a distributed system environment. With

this PMI Monitoring Data, technical processes on the Integration Server and the

Adapter Framework can be monitored. For the Performance Monitoring the PMI

provides the required Information Data. Currently, the Processing of XI message

can be monitored and in this context, IDocs and tRFC/qRFC as well. This enables

the possibility to monitor business processes. For example, if an order has been

created and is sent to another system through XI for processing, the following

technical process steps form the basis for this process: IDoc outbound, tRFC, XI

processing, tRFC, IDoc inbound and calling the corresponding application in

the other system. If these technical process steps were performed successfully,

then this part of the business process was also successful. PMI provides a

Web-based user interface for Process Monitoring that can also be integrated in

other applications and whose features include the following:

• Graphical display of the process flow

• Information of aggregated values, likeas average process duration, minimum

and maximum duration, for an overview of the performance

• Quick overview of the current status of processes and process steps, for

example which ones includes errors and such which are free of errors.

• Display of detailed information with a ’drill-down’ feature

• Ability to jump directly to further analysis tools and them for correctingerrors

To use the PMI Monitoring, there is some configuration necessary

• Enable PMI on the ABAP Stack:

In the configuration section with transaction

SXMB_ADM → Integration Engine Configuration select category

MONITOR and change the parameter PMI_MONITORINGto “1” to

enable the PMI functionality. Default value is already “1”. If you do not

want to use End-to-End Monitoring we recommend to deactivate PMI

with this parameter setting to “0.”

• Enable PMI on the JAVA Stack:

For this, HTTP destination pmistore is required,

which points to the URL http://<full qualified host-

name>:<HTTP-port> /sap/bc/spi_gate.

Also for collecting the PMI data, there are some background jobs on the ABAP

stack needed:






SAP_XMB_EX-

TRACT_PMI_DATA

SXMS_PMI_EX-

TRACT_PMI_DATA

Every 15 minutes

SAP_XMB_GET_PMI_DATASXMS_PF_GET_PMI-

DATA

Every 15 minutes

SAP_XMB_PERF_AG-

GREGATE

SXMS_PF_AGGRE-

GATE

Every hour

SAP_XMB_PERF_RE-

ORG

SXMS_PF_REORG Every hour

For more details check the SAP Library http://help.sap.com for PMI configuration

details.

The level of the monitoring detail (low, medium, high) can be set up in the

Runtime Workbench in the section “Configuration”


http://-/?-

http://-/?-








Exercise 3: System & Component

Monitoring ExerciseExercise Objectives


• Get familiar with the usage of CCMS and RWB for detecting Errors

Business Example

You are responsible for the PI System and Component Operations. One task is

the monitoring and you want to know which possibilities are available in SAP

PI to do this

Task:

Use the PI Monitoring Tools, CCMS und RWB to find errors in the Training

System

1. Logon to the Training System, navigate to the Transaction RZ20 and search

for errors

2. Logon to the Training System, navigate to the Runtime Workbench and

search for errors

3. Logon to the Training System, navigate to the Transaction RZ20and search

for errors.





Solution 3: System & Component

Monitoring ExerciseTask:

Use the PI Monitoring Tools, CCMS und RWB to find errors in the Training

System

1. Logon to the Training System, navigate to the Transaction RZ20 and search

for errors

a) Call Transaction RZ20 and choose the CCMS Monitor Set “SAP

CCMS Technical Expert Monitors”. Navigate to the section “All

Monitoring Contexts.”

b) Click on the MTE “Transactional RFC and Queued RFC”which Queues

are locked? What is the reason?

c) Choose the Inbound Queues and navigate to the Int. Server Outbound

Messages (XBQO).

d) Choose client 800 with a double click.

e) In the qRFC Monitor select the line with the error by double click

on the line.

f) The Error cause is “XI Error CO_TXT_Outbinding_ERROR.OUT-

BINDING”

g) For solving the problem go back to the TA SXMB_MONIclick on the

entry and press the button “Cancel Processing of Messages with errors”

Now the message is marked as “canceled manually”

h) Navigate to the Queue Monitor and take a look at the former locked

Queue. Now the entry is deleted and the Queue is active again

After that, the queue is active again.

i) For solving the Configuration Error see step 3 of this Exercise (Enter a

valid receiver).

Continued on next page





2. Logon to the Training System, navigate to the Runtime Workbench and

search for errors

a) Call Transaction SXMB_IFR and choose the RuntimeWorkbench.

Chosse the Message Monitoring and search for Errors. Navigate to the

section “All Monitoring Contexts”

b) Choose the Component Monitoring and select the Adapter Engine.

c) Select the Communication Channel Monitoring and go through the

adapter.

d) Interprete the error of the File-Receiver-Adapter.

e) Click on the link at the bottom and go trough the audit log. What is

the problem of the communication channel?

f) Navigate to the Integration Directory.

g) Choose the Communication Channel CC_File Sender.

h) Check the source directory of this File Adapter and enter a valid path.

3. Logon to the Training System, navigate to the Transaction RZ20and search

for errors.

a) Call Transaction RZ20and choose the CCMS Monitor Set “SAP CCMS

.Technical Expert Monitors” Navigate to the section “All Monitoring

Contexts.”

b) Click on the Monitoring Contex.t

“IEngine_FN7_800 Integration Server.”

c) Choose the Category RCVR_Determination.

d) Interprete the error Too_Many_RECEIVERS_CASE_BE.

e) Logon to the Integration Directory and choose the Receiver

Determination BIT_480_HTTP_SENDER_00. SI_Debitor_out_sync.

In the overview Configured Receivers, check, how many receivers

are set up.

f) Just let the first entry for the Configured Receivers in the list an clear

all the other entries.





Lesson Summary

You should now be able to:• Explain CCMS and SAP PI Monitoring Template and Engine relevant





Manager







BIT480 Lesson: Monitoring Activities - On Demand or Alerting Based

Lesson: Monitoring Activities - On Demand or Alerting

Based

Lesson Overview

This lesson gives you the understanding of active and reactive monitoring, how

to monitor the ccBPM processes and the knowledge of reoccurring tasks for

continuous availability.

Lesson Objectives


• Appreciate the differences of Alerting (CCMS – Alerting, Alert Framework)and active monitoring (On Demand with RWB).




Business Example

There are several kinds of monitoring methods for a SAP NetWeaver PI system.

You as the responsible administrator want to know the differences between on

demand and alert-based monitoring, how to monitor messages on the Integration

Engine and Adapter Engines, how to monitor Integration Processes on the BPEengine and how to ensure a continuous availability of your business processes.

Alerting Functionality with SAP NetWeaver PI

The SAP NetWeaver PI provides a rule-based alerting framework. For all kind of

errors, which occur during the message processing in the PI, a notification with an

alert could be established. So, that the responsible person, gets prompt informed,

when errors occur. For the different components of the PI, different kind of alerts

and even different type of alert categories can be implemented. As an example,

error during the mapping runtime in the Integration Engine and connecting errors

in the Adapter Framework should be forwarded to different persons.

• Create a Alert Category with Transaction ALRRTCATDEF.

• Administer the Values of the Alert Category and maintain the receiving users.

• Set up the Alert Rules Configuration in the Runtime Workbench of the PI.

• Configure SAP Connect for Forwarding the Alerts e.g. via E-mail if needed.

Creating Alert Categories





The first step in implementing the alerting is to create the container for the alert.

These containers are defined as Alert Categories in transaction ALRTCATDEF in

your ABAP. Alternatively they can be created in the RWB→

Alert Configuration.

After calling this transaction you will get the following screen:

Figure 197: Transaction ALRTCATDEF

Enter your alerting relevatn short and long text. You can use the container

variables, which are filled during runtime with the individual values retrieved

during runtime from the failing messages.

Here is a table of useful container variables for PI specific message alerting:

PI Specific Container Variables

Available Container Variables: Container Variable Meaning:

SXMS_MSG_GUID Message ID

SXMS_RULE_NAME Description of the alert rule

SXMS_ERROR_CAT Error category

SXMS_ERROR_CODE Error code

SXMS_FROM_PARTY Sender party

SXMS_FROM_SERVICE Sender service

SXMS_FROM_NAMESPACE Sender namespace

SXMS_FROM_INTERFACE Sender interface





SXMS_TO_PARTY Receiver party

SXMS_TO_SERVICE Receiver service

SXMS_TO_NAMESPACE Receiver namespace

SXMS_TO_INTERFACE Receiver interface

SXMS_TO_ADAPTER_TYPE Adapter type

SXMS_TO_ADAPTER_ERRTXT Error text from the Adapter Engine

XMS_AF_ERRPAR1 … 15 RNIF Adapter only - Name of error

parameters 1 to 15

SXMS_AF_ERRVAL1 … 15 RNIF Adapter only - Content error

parameters 1 to 15

You cannot use these container variables for alerts of the BPE.

You can add as well guidelines for optional subsequent activities.

Recipients of the Alert Categories

For the created Alert category, it is necessary to define the possible recipients

of the alerts.

Figure 198: User Assignment for Alert Categories

For the User Assignment, there are three options:

• Choosing a individual person as a recipient of an alert.

• Choosing a certain user role as a recipient of an alert. This is for groups of

people.

• The last option is to invite a group for subscription. This is a special version

of a alert. These people do not have any tasks in regards to the alert. They

are simply advised that something happened.

Note: Users that you define as receiving an E-mail need to have valid

E-mail address in the User-Management with transaction SU01

Define the Alert Rules in the Runtime Workbench





After the creation of the alert category and the user assignment, the next step is to

define the alert rules. To do this, enter the RWB and execute Alert Configuration.

A new screen appears which looks like the following:

Figure 199: Alert Rules Configuration

In the top section you can choose the rule you wish to edit or create a new rule.

Once you have chosen a rule to modify, you then need to define what the rule

actually monitors. Here you can see the rule categories and to which category

the rule belongs to.

When you have made your choices then the next step is to activate the rule so that

it is active and also the alert category.

Suppress follow-up messages implies, that a message is only sent once per error

type. With this option activated, you only get one alert fro the first message that

failed. This avoids a full mailbox, but will also limit the alert to exactly one alert.

Alert Inbox





Figure 200: Alert Inbox of the RWB

In this display, you can get an overview of which alerting rules are defined, active

and also the alert category.

It is also possible, to forward this Alerts to the CCMS monitoring segment. The

alerts will appear in the CCMS category SAP XI Central Monitoring and are

grouped by the alerting categories defined.







In addition to ordinary message persistence, there are three possible places to

which message payload data can be written. These are the trace files of the

mapping service, the JCo trace files (as the mapping service is called using JCoRFC), and the HTTP/S trace files (as PI messages are sent and received using

HTTP/S).

To display information about messages, the messages must first have been logged.

A message is logged when it is processed if:

• It is an asynchronous message (persisted implicitly) and Logging for the

underlying pipeline is activated (general logging of all pipeline steps or

logging of particular pipeline steps). The original message and any versions

then exist for each message. Versions of an original message only exist if

message processing was executed with activated logging, or the message was

implicitly persisted following a particular pipeline step.• If logging is activated at pipeline level, a new version of the message is

saved each time a pipeline service is called. If logging is activated at pipeline

service level, a new version of the message is saved following processing by

the pipeline service concerned. In this way, changes to messages by pipeline

services can be monitored. You can monitor all services or only the critical

services, depending on the logging configuration.

Figure 202: Integration Engine - Message Monitoring





To get a different look & feel of processed message, it is possible to select different

predefined views. These views contain different informations of the message

processing e.g. some columns are hidden in some views. To change the view,click on the right buttonChoose Layout... . Choose the layout to an more technical

or an more business oriented view.

Figure 203: Layout of the Integration Engine Message Monitor

In the column adapter, the technical description appears, which depends on the

type of the chosen adapter.

• WS is the new web service reliable messaging protocol

• IE is the used Integration Engine. For example for ABAP Proxies

• IDOC, for using the IDOC protocol

• PE when the message is sent to an Integration Process (Process Engine)





Figure 204: Icon Legend of the Integration Engine Monitoring

More details for a message can be displayed with a double click on the message.





Figure 205: Details of Message Monitoring

There are two levels of monitoring:

• Monitoring the message headers (including the trace header)• Monitoring the message payload (containing the actual application data)

Use authorization object S_XMB_MONI if you want to prevent message trace

headers or message payloads being visible in the PI monitoring tools. This

authorization object enables you to restrict access to messages containing a

specific party, component, or interface. Furthermore, you can allow access only to

message headers by granting activity 03 Display, or only to message payloads by

granting activity 29 Display saved data. If you want to restrict the authorizations

of a user by assigning an individual S_XMB_MONI authorization, copy the user’s

standard single user role containing the generic S_XMB_MONI authorization

to a customized user role, and adapt the authorization object S_XMB_MONI

correspondingly. This way you avoid modifications of the standard user roles.

Message Monitoring in the Runtime Workbench

Starting with SAP NetWeaver PI 7.1 and the new Advanced Adapter Engine

functionality of the Integrated Scenario messages do not need to show up on the

Integration Engine at all. How do you montior this messages in your system?

Here the RWB - Message Monitoring functionality is the only recommended

monitoring tool.





Integration Process Monitoring in the BusinessProcess Engine

For the Business Process Engine, additional monitoring tools are necessary. There

are many transaction codes you can use to monitor workflow executions. The

entry point for the monitoring workflow is transaction code SXMB_MONI_BPE.

Almost all monitoring transaction codes take you to the workflow log. The

workflow log enables you to see exactly what is happening in the workflow.

Figure 206: Monitoring of the Business Process Engine





Figure 207: Workflow log





In this lesson we will focus on the following monitoring transactions:

• Process Selection – SXWF_XI_SWI1

All the reports lead to the same workflow log. The primary difference is the

selection criteria used to get to the workflow log. By designating F as the type

of work item, you will look at the log for each workflow. This is normally

easier than looking at each step individually. You also may need to change

the date/time range to get the executions that interest you. You could also

change the Status field. You could look at only executions in COMPLETED

status, ERROR status, STARTED status, CANCELLED status.

• Processes for One Message Type – SXWF_XI_SWI14

All other monitoring transactions take you to the same workflow log. The

difference is how to search for a workflow execution. In this transactioncode, SXWF_XI_SWI14, you can search by a specific Interface Name or

Interface Namespace. Now you will receive the logs only for a particular

Interface Name or Interface Namespace.

• Processes for a Message – SXWF_XI_SWI6

In transaction code you can get the workflow log for a particular message

GUID. If you have a interface that executes thousands of times a day, here

you can get the log for an exact GUID. For example, you have the GUID

number for a particular message and you want to see all workflow executions

tied to that GUID.

• Diagnosis Processes with Errors – SXWF_XI_SWI2_DIAGIn this transaction code you receive all workflows with errors. You can

highlight any of them and select Restart Workflow. For each work item you

can double-click to research the error. If you choose to restart the workflow,

it starts from the point of the error. In the exercise for this lesson there is an

example of researching an error included.

• Continue Processes Following Errors – SXWF_XI_SXPR

This transaction code is another way to do a restart. Here you can restart

many in mass by selecting Restart immediately. You could use this

transaction code if every workflow failed for the last 2 minutes and you

want to restart all of them. You could also use this transaction code to look at workflows in error and restart particular ones.





Figure 208: Workflow from Message Log

If you are looking at the XML messages, you can see which ones are executed

workflows. The Queue ID column will list the workflow that was executed forthis message. You could take the Message ID for a particular workflow, call

transaction SXWF_XI_SWI6 (Processes for a Message) and find all specific

workflow executions for this Message ID (GUID). Another alternative to get

to this overview is to call transaction SXMB_MONI and click in the column

Inbound or Outbound on PE





Exercise 4: Create and Define Alerting

RulesExercise Objectives


• Verify that the required Services are activated

• Create Alerting Categories

• Define Alert Rules

• Raise Alerts and monitor them

Business ExampleYou are responsible for the Implementation of the Alerting Rules. So you want to

define new Alerting-Rules and test them.

Task:

Create a new Alerting Category, assign your User to that category, define a

Alerting Rule and test it.

1. Log on to the Integration Server (client 800) for your training system, call

the Integration Builder, and start the Enterprise Service Repository. Your

user is BIT480-## (where ## is your group number)

The course instructor will provide you with the training system details.

2. Create a new Alerting Category

3. Define Long and Shorttext for the Category and add your User as the

Recipient of the Alert.

4. Test your Alert Category with the Report RSALERTTEST and look after

the Alert.

5. Define the Alert Rule based on the Alert Category

6. Raise an Alert and take a look at the Alert





Solution 4: Create and Define Alerting

RulesTask:

Create a new Alerting Category, assign your User to that category, define a

Alerting Rule and test it.

1. Log on to the Integration Server (client 800) for your training system, call

the Integration Builder, and start the Enterprise Service Repository. Your

user is BIT480-## (where ## is your group number)

The course instructor will provide you with the training system details.

a) Log on to client 800 in your training system. Your user is BIT480-##.

2. Create a new Alerting Category

a) Call Transaction ALRTCATDEF.

Switch to the Edit Mode and choose in the top menu the Icon “Create

New Alert Category”, enter an name and Description for this Category

and save it.






3. Define Long and Shorttext for the Category and add your User as the

Recipient of the Alert.

a) In the Tab Short-Longtext type in the Message you want to see in the

Alert. In the Tab Container, you can choose the Variables which can

be used in Short and Long-Text. These Variables are filled during

runtime with real values.

To assign a user to the Alert-Category choose in the top menu the

button fixed Recipients. In the following screen enter your user.

Figure 209: Creating an Alerting Category

4. Test your Alert Category with the Report RSALERTTEST and look after

the Alert.

a) To test the Alert Category, use the Report with Transaction SE38

RSALERTTEST. In the following screen choose the name of yourCategory. The ID of the Alert is given as a response.

To ensure, that the Alert was sucessfull sent to the PI Alert Inbox,

navigate to the Runtime Workbench. Call Transaction SXMB_IFRand

in the screen click on the RuntimeWorkbench. In the following Screen

choose Alert Inbox on the right side of the top menu. Enter your User

name and take a look at the Alert.






5. Define the Alert Rule based on the Alert Category

a) Navigate in the Runtime Workbench to the section “Alert

Configuration”

The first step is to choose the Alert Category from the list at the bottom.

After that, enter a description and set the mark “Rule active”In the

middle of the screen you can set the conditions for your Values and

enter criteria in which the Alert should occur. For example choose

Integration Engine, the Error Category as Application and the Error

Code to Mapping*

To activate this Rule click on add rule. The new rule appears in the

list at the top of the screen

With this created rule, in all Mapping Errors, a Alert will be created.

Figure 210: Configuration of the Alerting-Rule






6. Raise an Alert and take a look at the Alert

a) Navigate to the RuntimeWorkbench. Choose Component Monitoring

and click on the Integration Engine. Choose the tabTest Message and

open the Test Message: Test_Alerting_00.

Enter your User, Password and click in sent Message

Navigate to the Alert Inbox search for the Alert and interpret the text of

the Alert.

Figure 211: Alert Inbox

b) Navigate to the Runtime Workbench again, if you want to correct the

error.

c) Delete in the Namespace of the Message Payload the “-”and send the

Message again.





Lesson Summary

You should now be able to:• Appreciate the differences of Alerting (CCMS – Alerting, Alert Framework)





Related Information

Important SAP Notes on Alerting in SAP NetWeaver PI:

• 913858: XI Alerting: Troubleshooting

• 932085: XI 'Message based Alerting' - additional information




BIT480 Lesson: Performance Monitoring

Lesson: Performance Monitoring

Lesson Overview

This lesson describes the procedure of the performance monitoring. How

bottlenecks situations can be found and how they could be avoided.

Lesson Objectives



Dashboards).



Business Example

On your PI System, the Messaging Processing takes anomalous long time. You

as the responsible SAP Administrator want to know, how to detect bottleneck

situations and how to avoid them.

Performance Monitoring

The PI Performance monitoring is used to display statistical data on the

performance of message processing. The data comes from the Integration Server(IS) or the Process Monitoring Infrastructure (PMI). The central performance

monitoring tool is the Runtime Workbench. There are several Data views for

the Performance Monitoring:

• Aggregated overview data for message processing

• Individual overview data for message processing

• Aggregated detailed data for message processing performance

• Individual detailed data for message processing performance

Some Configuration steps are prerequisite for the performance Monitoring: Two

jobs are required for data collected on the Integration Server:

Job Name Report Recommended Inteval

SAP_XMB_PERF_AG-

GREGATE

SXMS_PF_AGGRE-

GATE

Every hour

SAP_XMB_PERF_RE-

ORG

SXMS_PF_REORG Every hour





Some Parameters in the Integration Engine Configuration have to be set as well

• MEASUREMENT_LEVEL

• MEASUREMENT_PERSIST

• DAYS_TO_KEEP_DATA, subparameter MEASUREMENT_ITEMS

• DAYS_TO_KEEP_DATA, subparameter AGGREGATION_ITEMS

To analyze the Performance Data, the most informative view is the Detailed Data

Individually. With this section, for each processing step of the Integration Engine,

the performance Data e.g. for Mapping, can be seen and bottlenecks can be found.

It is also possible to download these Performance Data in to a CSV Format for

further analysis.

Figure 212: Performance Data Results

The Performance Monitoring can also be used in the NetWeaver Administratorfor PI, if this tool is used for the Central System Monitoring. The

informations are of course the same and the main advantage is, that the

performance monitoring can be used for all PI Systems in the Landscape.

In the Overview on the right side, the component has to be selected and for this

the performance data can be displayed





Figure 213: Performance Monitoring with the NetWeaver Administrator for PI

Avoiding Bottleneck Situations

PI System is sized to handle average message volume in project scope. As default

inbound and outbound queues are shared between all interfaces, the sending of

mass-data from one interface influences overall interface throughput.

Precaution Measurements:

• Avoid mass-data transfer during regular working hours. If possible schedule

the high volume scenarios after the working hours.

• For planned mass-data transfer, configure the interface before as low priority

interface, so that the volume of messages of this interface has only limited

influence on all other regular transferred interfaces.

• If processing of mass-data transfer interfaces can be delayed into low

processing times, use time-controlled processing feature of PI.

• Or, restrict parallel processing of mass-data transfer interface by configuring

interface dedicated inbound and outbound queues and setting parallelization

of processing in the Integration Server Administration beforehand.

• Check usage of TUNING EO_INBOUND_PARALLEL_SENDER to restrict

or increase parallel inbound processing of one dedicated sender system.

• Ensure that end-user cannot send thousands of data, which could be ensured

by checking transfer of more than 100 interface objects with explicit pop-up

to be confirmed by end-users.





Performance by Design

PI General reach methods

• Direct calls (formerly named “P2P Connections”): is and option to configure

back-end systems to contact themselves directly at runtime, skipping PI.

(This term makes sense from a PI centric point of view, since the back-end

systems make no distinction between a provider back-end or a Middleware

system). The benefits of this method are both an increase in speed and also

throughput, due to the simplified connection schema compared to a mediated

one, using the same adapter technology

• Message Packaging: It is a throughput increasing mechanism basically

based on message group processing inside each pipeline step,by grouping

together asynchronous messages in packages and then processing eachmessage package in one LUW. Semantically speaking, each package contains

individual, unrelated messages. Thus taking the benefits of loaded ABAP

program re-execution and massive database access. This groups can be

divided for Package Size for example. Message Packaging has several good

features and helps to increase the Message processing within PI. They are

saved to the database individually; no special package archiving function

is available. Messages can end up in various different packages while they

are being processed because a new package is created for each processing

step. How packages are created in the sender system and in the central

Integration Engine can be configured. Packages can be received and saved in

the receiver system. They are then processed as individual messages.

– One call is able to process several messages, this is basically the

principle of overhead reduction and leads to: A reduction in “context

switch” operations, that is, every time the system setups the execution

environment, it is reused instead of being discarded after message

processing. Commit executing is delayed until the last message is

processes, finally all the changes are committed at the same time

in one single call.

– From the application perspective there is no change at all, single the

messages keep on being as atomic as before at every level. t means,

there is no impact in any monitoring transaction. Furthermore, if a

message inside the package generates an application error, the packageis broken down into single messages and is executed in isolation.

• Advanced Adapter Engine: It is an evolution of the adapter engine that

supports integration engine capabilities like routing and mapping locally,

resulting in a simplified architecture

ccBPM specific enhancements





Due to the fact, that the ccBPM Processing takes longer processing time, there

are some additional possibilities to avoid performance problems which are highly

recommends.

• Packaging: Message Packages can be transferred to the BPE, extending the

message packaging features to the Integration Process arena.

• Parallel Processing: Allow specific Integration processes to be executed with

QoS EO, instead of EOIO, taking the benefit of parallel processing. The

benefit of the usage of Queues is now possible in ccBPM, too.

• Enhanced Transaction Handling: Allows design time optimization of

transaction handling, avoiding starting and ending one transaction for each

integration process step.

“Adapter Specific” enhancements

Other alternatives, to avoid performance problems are some Adapter specific

enhancements. That means, in some adapter, there are settings which leads to a

better performance during message processing. These alternatives are of course

recommended to consider.

• For the IDoc adapter:

– Packaging: The IDoc packaging functionality allows several IDocs

to be treated together on the outbound side. This functionality is

now replaced by the message packaging, what is basically the same

principle with a broader scope.

– No XML transformation: allows IDocs to be kept in original format

when it makes no sense to translate them to the internal PI format.

• For the File Adapter:

– File Splitting: It is a file content conversion utility that allow to split

one file into several PI messages based on a specific configuration.

– As mentioned before, always correct system configuration is a

prerequisite of any additional optimization option.









Exercise 5: Performance Monitoring

ExerciseExercise Objectives


• Use the Performance Monitoring and interpret the results

Business Example

In your company are several PI Scenarios running. You have the task to look at

the performance Monitoring and find bottlenecks

Task:

A Scenario is configured where a message is put from the file adapter and send

trough the PI. There are two options. One message processing with the Advanced

Adapter Engine and the Integration Engine and one is just with the Advanced

Adapter Engine only. For this two scenarios, the performance differences should

be determined.

1. Analyze the Performance Data for the Scenario with processing via the

Integration Engine using the Runtime Workbench and thePerformance

Monitoring functionality.

2. Compare the Performance Data from the first an the second run via theIntegration Engine. Are there differences? If so, in which step?

3. Analyze the Performance Data for the processing via AAE?

4. Take a look at the Messages in the Audit log and the timestamps on the

filesystem when this files were created.

5. Compare the processing time data from the two different runs. How large is

the difference and what is the reason?





Solution 5: Performance Monitoring

ExerciseTask:

A Scenario is configured where a message is put from the file adapter and send

trough the PI. There are two options. One message processing with the Advanced

Adapter Engine and the Integration Engine and one is just with the Advanced

Adapter Engine only. For this two scenarios, the performance differences should

be determined.

1. Analyze the Performance Data for the Scenario with processing via the

Integration Engine using the Runtime Workbench and thePerformance

Monitoring functionality.

a) Logon into the Runtime Workbench and navigate to Performance

Monitoring.

b) Enter the following data into the Filters: Sender - TXT2XML,

Receiver - TXT2XML, and fill in the missing interface information as

gathered from the overview monitoring transaction before. Start the

Performance Monitoring.

c) Write down the Performance data for the messaging processing.

2. Compare the Performance Data from the first an the second run via the

Integration Engine. Are there differences? If so, in which step?

a) Time Differences appear in the Mapping step. This is due to the

Changes of the Mapping in which a wait step is inserted on purpose.

3. Analyze the Performance Data for the processing via AAE?

a) Why are there no data in the Performance Monitoring?

b) Performance Monitoring comes out of the Integration Engine and this

is not available for scenarios with the AAE. The messages can only be

viewed in the Message Monitoring for the Adapter Engine.

4. Take a look at the Messages in the Audit log and the timestamps on the

filesystem when this files were created.

a) Choose the Message Mapping for the Component Adapter Engine.

Now the messages are available. Navigate to the tab Audit-Log to see

the detailed Information. Take the timestamp from the fist and the

last Message when it was written on the file system and calculate the

processing time of the processing

5. Compare the processing time data from the two different runs. How large is

the difference and what is the reason?





Lesson Summary

You should now be able to:• Know how to detect bottleneck situations (Performance Monitor, SMD

Dashboards).






Unit Summary BIT480

Unit Summary


• Know about components of the SAP NetWeaver PI Monitoring Landscape





tools








Manager




• Appreciate the differences of Alerting (CCMS – Alerting, Alert Framework)






Dashboards).






Unit 4 Error Handling and Resolution

Unit Overview

At the conclusion of this unit, you will have the understanding of how to deal with

errors. You will learn effective ways to detect and resolve erroneous messages.

Unit Objectives


• Be aware of detecting error situations.

• Get a Feeling about Queue handling with EO versus EOIO Processing

(SYSFAIL versus Message Failure - on Integration Engine and an the

Adapter Engine).

• Appreciate to use monitoring transaction SXMB_MONI and Runtime

Workbench - Audit Log features.

• Be familiar with the logging and tracing functionality of Web Services and

the sequence monitoring

• Be familiar with solving temporary errors

• Know how to solve permanent errors, due to incorrect customizing or due to

incorrect payload (Payload Editing)

• Know which options you have to process erroneous messages

Unit Contents

Lesson: Error Detection.. .... ... ... .... .... ... .... ... ... .... .... ... .... ... ... ..290

Exercise 6: Error Detection Exercise . .. ... .. .. ... .. ... .. .. .. .. ... ... .. ..307Lesson: Error Resolution .... ... ... .... .... ... .... ... ... .... .... ... .... ... ... ..313

Exercise 7: Error Resolution Exercise. .. ... .. ... .. ... .. .. .. .. ... ... .. .. .321


http://-/?-

http://-/?-

http://-/?-

http://-/?-



Unit 4: Error Handling and Resolution BIT480

Lesson: Error Detection

Lesson Overview

At the conclusion of this unit, you will be able to understand how to detect error

situations, identify the concerned component and how to deal with this errors.

Lesson Objectives





Adapter Engine).





Business Example

In your Monitoring Landscape, the monitoring is already implemented and several

scenarios are running. Some errors occurred and you want to know how to detect

these errors.

Error Detection

This section describes how to analyze the PI message flow and error situations




BIT480 Lesson: Error Detection

Figure 214: Message Flow inside PI

This graphic demonstrates a typical message flow of a message within an PI

system and the different components involved. As already mentioned a message

can enter and leave the PI system via the AFW (Adapter Engine). In between

the integration engine is used which implements the exchange logic. In some

scenarios it is necessary to apply a mapping step executed in the MappingRuntime or additional functionality using the Business Process Engine (BPE).

Only the Idoc and plain-http adapter do not use the AFW to enter the PI. A

typical scenario which involves all of the components displayed above would be

a SOAP-to-RFC communication between different systems. While a message is

being passed between the ABAP and Java stack several times. The connections

between the ABAP and Java stack are either established via http using the Internet

Communication Manager (ICM) or via JCo using the Gateway.





Figure 215: Message Flow inside the Advanced Adapter Engine

This slide demonstrates a typical message flow of a message within an the

Advance Adapter Engine of an PI system and the different components involved.

A typical scenario would be a File-to-File communication between two legacy

systems. The message enters and leaves the PI system via the AAE in this case.

The simple routing and the mapping step will be executed in the AAE – Java only.

The Integration Engine is not involved in this case.

The following graphic describes the message flow inside the Adapter Framework

and the Monitoring-Points

Monitoring along the message flow: Inbound

1. Adapter Engine Monitoring: RWB Component Monitoring => Adapter

Engine

Communication Channel Monitoring RWB => Component Monitoring =>

Adapter Engine => Communication Channel Monitoring

2. Messaging System Monitoring: RWB => Component Monitoring =>

Adapter Engine => Engine StatusTab: BacklogTab: Messaging Overview

(e.g. All Categories)

Wily Introscope (Messaging System Queue Dashboards)

3. Message Monitoring in the AE: RWB => Message Monitoring (Adapter Engine – From Database)- Audit Log of message





There are some general Rules for Error Handling

• If the error is based on incorrect configuration:

1. Resolve root cause

2. Restart failed messages after solving root cause

• If the error is based on incorrect data from sender system:

1. Resolve incorrect data in sender system

2. Manually cancel erroneous XI message in XI

3. Resent corrected original data from sender system

• If the root cause of the error cannot be determined quickly enough, or the

analysis needs additional involvement of other persons and message is

blocking the queue in XI. This is only valid for EOIO QoS when Queues are

blocked. For EO messages the message has to be marked as erroneous andthe next message should be normally processed.

1. Mark entry in queue and move entry into temporary storage

2. Resolve root cause asynchronously by specialist

3. Restore entry

Queue Monitor-

ing

The Message processing in the SAP Process Integration is done with the usage of

Queues. These Queues can be used on inbound and outbound side for bufferingthe incoming and outgoing Messages. For example if a high amount of messages

are sent to the PI, they are all stored in the inbound Queues and each message is

processed after the other in the integration engine as a Logical Unit of work.

(LUW). If a Message gets an error during the processing and could not be

processed further e.g. to a Database or JCO Error, the message is stopped and

the complete Queue gets locked. . The other messages which are in the same

Queues will be set to the status waiting. That means they are hanging in this

Queue and no processing is possible. As you can imagine, for efficient Message

Processing it is important to pay attention on the Queue Handling. For the case,

that a Queue gets locked, it is crucial to unlock this Queue immediately that the

message processing can be continued.





Hanging Messages in locked Queues can be in the following status:

• SYSFAIL: A serious error has occurred during execution of the LUW in this

queue. The execution has been stopped. By double-clicking the status, the

error text can be viewed. More information about this error, can be found in

its short dump (ST22), too. For this LUW no background jobs are scheduled

for a retry, and the queue is not processed any further. To solve the problem,

the relevant application, needs to be informed and corrected.

• STOP: For this status, a lock has been set explicitly (SMQ2 or programs) on

this queue or on a generic queue (such as BASIS_*) . The qRFC never locks

a queue during processing. Once, the relevant application is informed, this

queue can be unlocked using transaction SMQ2. In case of using the event

processing could the status STOP be a normal state.

• CPICERR: In this case, a network or communication has error occurred

during execution of the first LUW. By double-clicking the status, the error

text is displayed. More information about this error, can be found in the

syslog (SM21) and in the trace files dev_rd or dev_rfc*. Depending on

how the queue was registered (SMQR), a batch job might be scheduled for

retry. Status CPICERR can also occur in the following cases, event though

no communication errors have occurred: A qRFC application finds out that

a LUW cannot be processed due to a temporary error in the application. It

therefore calls the RESTART_OF_BACKGROUNDTASK function module

to prompt the qRFC Manager to cancel the execution of this LUW and to

repeat this LUW later in accordance with the settings in transaction SM59.

qRFC then simulates a communication error with the text "Command to

tRFC/qRFC: Execute LUW once again." If this error occurs regularly, therelevant application has to be informed and should be rechecked.

• ARETRY: The application diagnosed a temporary problem while processing

the LUW and has used a specific qRFC call to prompt the qRFC Manager to

schedule a background job for a retry, using the registration in SMQR.

• ANORETRY: The application diagnosed a serious error while processing the

LUW and has used a specific qRFC call to prompt the qRFC Manager to

stop processing this LUW. For solving this problem, the relevant application

should be informed.

To continue the Message Processing of a locked Queue, the following alternatives

can be done• Resolve the Error and execute the LUW again: This solution can be used e.g.

for communication errors. After repairing of a Rfc connection, the LUW can

be executed in the Queue with the commend“Execute LUW”

• Save the faulty LUW. this action is used, if the error is not simple to resolve.

By saving a LUW from the Queue, it will be taken out of the Queue and be

stored at another place. The other messages which are waiting behind this

faulty LUW can now be processed again. Please consider, that a LUW should

always put out of the Queue by “Saving the LUW” and not by deleting it.





Figure 216: Error Handling with Queues

To abstract LUW from the Queues, by saving them is not recommended and this

procedure should be handled with care.

Error Categories

The Message Processing in SAP Process Integration is done in different

Components. For example the Integration Engine and the Adapter Framework. As

you can imagine, errors can occur on these different components. The errors can

be devided in several Error categories, which will be described in the following.





Routing Errors:

• Logical routing does not find a receiver

– NO_RECEIVER_CASE_BE

– NO_RECEIVER_CASE_ASYNC

• Common Causes

– Discrepancies between the Configuration in Integration Directory and

the SOAP header of the incoming message. (Sender service, Sender

interface, Sender interface Namespace)

– Condition for content-based routing has not been met

• Solution

– Comparing sender service, interface Namespace, interface in SOAP

header with ones in SXI_CACHE

– Making necessary correction in the Integration Directory or in the

SOAP header for asynchronous messages and restart the message

Figure 217: Routing Errors - No Receiver

Call Transaction SXMB_MONI. Select the message (for example, by using a

date or time to limit your search). Double-click to select the XML message. The

system then displays the current status of the XML message. In the tree on the left,expend Receiver Identification -> SOAP Header -> Main. You can find sender

information under <SAP:Sender>Double-click the line Error Header from the

SOAP Header section. The system displays the cause of the error. Double-click

message content and condition (XPath expression or context object) . The message

payload can only be changed in the Messaging System of the Runtime Workbench.

Only asynchronous Message with Quality of Service Exactly Once/ Exactly once

in order can be restarted. For synchronous messages with Qualitiy of Service BE a

manual restart is not possible





Figure 218: SOAP Header View in SXMB_MONIDetail View

Check the routing configuration for your system using the sender information

and the payload by calling transaction SXI_CACHE to display the XI Directory

Cache. Make adjustments in the Integration Directory or in the message payload

if appropriateSynchronous messages with errors cannot be restarted in the SAP PI. In this

case, the sender has to deliever the message once more. For asynchronous

message, (EO, EOIO) the messages can be restarted manually, ore via Batch Job

“RSXMB_RESTART_MESSAGES”





Figure 219: SXI_CACHE Content

• Logical routing find more than one receivers for Synchronous Message

– TOO_MANY_RECEIVERS_CASE_BE

• Common causes

– Complex content-based routing rules– Two or more rules are evaluated as true during runtime

• Solution

– Making correction in Integration Directory

– Resend the message from the Sending Application

Call SXMB_MONI, select the message (for example, by using a date or time to

limit your search). Double-click to select the message. The system displays the

current status of that XML message. In the tree displayed on the left, under the

SOAP Header section, double-click the line Message Header (Main). For sender

information, choose <SAP:Sender> More than one <SAP:Receiver> exists. Check

the routing configuration for your system using the sender information and thepayload by calling transaction SXI_CACHE to display the XI Directory Cache

Adjust ID contents if necessary Note: this error may remain undetected during

configuration time, especially if complex content-based routing rules are involved

This information is as well visible in the Message Monitoring of the Runtime

Workbench





Mapping Errors

• Mapping not executed

– JCO_COMMUNICATION_FAILURE

– NO_MAPPINGPROGRAM_FOUND

• Common causes

– Incorrect RFC connections between Integration Engine and J2EE

mapping runtime

– Non-updated runtime cache of Integration Engine

• Solution

– For error JCO_COMMUNICATION_FAILURE:

Check RFC destination AI_RUNTIME_JCOSERVER in SM59

Check JCO destination AI_RUNTIME_<SID> in the NWA

– For error NO_MAPPINGPROGRAM_FOUND:

Check cache notification status of ESR and Integration Directory

Check cache update status of integration engine using SXI_CACHE

and perform cache update it this is necessary

In the Runtime Workbench choose the Message Monitoring. Navigate to

the details Display all versions of the XML message. Expand the SOAP

Header section for the last version of the XML message in the tree on the left.

Double-click to select the line Error Header from the SOAP Header section (if available). Analyze the cause of the error. If you do not find any error information,

compare the message contents of the inbound message with the last message

version. Use this information to check whether a mapping was executed and





whether the mapping was executed with errors. If no mapping was executed,

check whether the mapping service is functioning. If a mapping was executed with

errors, check the mapping configuration (XSLT,...).

• Mapping executed with errors

– EXCEPTION_DURING_EXECUTE

– Common causes

Interface mapping version is not correct

Mapping program version is not correct

Mapping program does not work correct

• Solution

Check cache notification status of ESR and Integration Directory

Check cache update status of integration engine using SXI_CACHE

Perform cache update if really necessary

Technical Routing Errors

• Technical routing not executed

– Message processing ends after technical routing

– OUTBOUND_BINDING_NOT_FOUND

• Common causes

The receiver agreement could not be found for the specific sender to the

receiver

• Solution

– Analyze the error in technical routing header in the SXMB_MONI or

RWB Message Monitoring

– Check the Configuration in the Integration Directory





Figure 220: SXMB_MONI - Technical Routing

Call Adapter Errors

• The XML message could not be sent to the target system.

– CLIENT_RECEIVE_FAILED• Processing stops once the target system has been called.

– HTTP_RESP_STATUS_CODE_NOT_OK

• Common causes

– Incorrect connection parameters to target system

– Target system is not reachable

Figure 221: Call Adapter Errors





To determine where an XML message was sent or where it should be sent to, go

to the function Exchange Infrastructure =>Monitoring =>Integration Engine –

Monitoring =>Monitor for Processed XML Messages (SXBM_MONI) . Searchfor the corresponding XML message.Select the XML message. In the display

function, expand the node “Technical Routing” in the tree structure shown on the

left. The tag <SAP:receiver> contains the information about the receiver service

and interface (as a result of the receiver determination and interface determination

pipeline steps, respectively). The tag <SAP:OutboundBinding> contains the

information about the receiver communication channel. This information can also

be displayed by clicking on the “OutboundBinding” node in the left frame. Check

whether the system is active and accessible using the connectivity parameters from

the outbound binding.

Monitoring of Messages in the Adapter Framework

As described before, the Messages with errors are displayed in the Message

Monitor of the Integration Engine. But there could be also the case, that the

messages are erroneous in the Sender or Receiver Adapter. To check this, the

Message Monitoring of the Adapter Framework is needed.

Figure 222: Message Monitoring of the Adapter Engine

To navigate to this Monitoring, open the Runtime Workbench and choose Message

monitoring and the Component “Adapter Engine” and as the Source “Database”

The selection could me constricted with additional filter criteria. Then in the

bottom part of the screen, an overview of the Messages which are processed on

the Adapter Framework appears. To see more details of the erroneous Message

mark the entry and click on details. The Audit Log of the Adapter appears and

shows more details of the error





Figure 223: Audit Log

The Audit log shows a detailed overview over the activities and status informations

of the adapter. The errors are displayed here in detail and the number of retries is

provided as well.

Web Service Communication

The communication with WS-RM between a consumer and a provider can be

done in two different way.

• Mediated: The communication is done using the SAP PI for broadcasting

the messages with the WebService protocol

• Direct Connection: The communication is directly without using the SAP PI





Figure 224: WS-RM Communication

The graphic shows the communication variants.

For monitoring and detection of errors there is also the difference, whether the

communication is done in a asynchronous or synchronous way.

• For mediated asynchronous message exchange, the errors are visible in the

PI Integration Engine Monitoring SXMB_MONI

the adapter type is WS in this case. For further error information, the SOAP

Header has do be analyzed and the message can be restarted again manually.

• For mediated synchronous message exchange, the errors are not visible in

the PI Integration Engine Monitoring by default. But with the parameter

“LOGGING_SYNC”in the configuration section of the Integration Engine

SXBM_ADMThe monitoring of synchronous messages in the Integration

Engine can be activated. The error can be analyzed in the SOAP Header of

the message, but a restart is due to the Best Effort Quality of Service not

possible. The sender has to resent the message.

• For direct communication between consumer and provider, there is only thepossibility to use the Web-Service Logging and Tracing due to the reason,

that the Integration Engine of the PI is not used in this case. For synchronous

messages, there is no way to restart the erroneous messages. The Sender has

to send it again. For asynchronous scenarios, the sequence can be terminated.

In ABAP back-end system you can user transaction SOAMANAGER to get

to the Web Sercices Logging & Tracing functionality. On JAVA back-end

systems it is part of the SOA Management workcenter of NWA.





Figure 225: Sequence Monitoring

Termination of the sequence









Exercise 6: Error Detection Exercise

Exercise Objectives


• Detect Errors of the PI Message Processing at different components and find

out the reason for the error

Business Example

In your company, there are problems with the processing of messages. You want

to know how to detect these errors

Task:Execute the Scenarios and detect where the errors occur and what is the cause

for these errors

1. Scenario 1: Log in to the Runtime Workbench and send the Messages via the

Test-Tool to the Integration Engine.(HTTP-2-File)

2. Navigate to the Message Monitoring and analyze the errors


Test-Tool to the Integration Engine.(HTTP-2-JDBC)

4. Navigate to the Message Monitoring and analyze the Errors


Test-Tool to the Integration Engine.(HTTP-2-RFC syncronous))

6. Navigate to the Message Monitoring and analyze the errors.


Test-Tool to the Integration Engine.(HTTP-2-File )






Solution 6: Error Detection Exercise

Task:

Execute the Scenarios and detect where the errors occur and what is the cause

for these errors


Test-Tool to the Integration Engine.(HTTP-2-File)

a) In the RuntimeWorkbench navigate to the Component Monitoring

b) Choose the Integration Server and click on the Tab TestMessage

c) Click on openMessage and choose the Message Error_Detec-

tion_File_##

d) Enter your name and Password and send the Message

Figure 226: Sending the Message to the Integration Engine

(HTTP-2-File)






2. Navigate to the Message Monitoring and analyze the errors

a) In the RuntimeWorkbench navigate to the Message Monitoring

b) Choose Integration Server and filter with the criteria you can see in the

Test-Message Screen of the Integration Engine

c) Start the Search and take a look at the errors. Watch the Audit Log of

the Adapter Engine. What could be the cause


Test-Tool to the Integration Engine.(HTTP-2-JDBC)



c) Click on openMessage and choose the Message Error_Detec-tion_JDBC_##



(HTTP-2-JDBC). Repeat the step one more with the same Payload

data, that in summary you send two equal Messages to the PI

System







a) In the RuntimeWorkbench navigate to the Message Monitoring



c) Start the Search and take a look at the errors navigate through the

Audit-Log and search for the error


Test-Tool to the Integration Engine.(HTTP-2-RFC syncronous))



c) Click on openMessage and choose the Message Error_Detec-tion_sync_##



(HTTP-2-RFC-sync)

6. Navigate to the Message Monitoring and analyze the errors.







Test-Tool to the Integration Engine.(HTTP-2-File )



c) Click on openMessage and choose the Message Error_Detection_2_##


a) In the Runtime Workbench navigate to the Message Monitoring



c) Interprete the Error





Lesson Summary

You should now be able to:• Be aware of detecting error situations.



Adapter Engine).








BIT480 Lesson: Error Resolution

Lesson: Error Resolution

Lesson Overview

This lesson describes how detected errors can be resolved.

Lesson Objectives






Business Example

In your PI System are already occurring different errors. You have detected the

errors and now you want to know, how this erroneous messages can be resolved.

Error Resolution

Figure 229: Erroneous Messages in the Message Monitor of the Integration

Engine





After you performed the actions which were explained in the Lesson: Error

Detection, now you want to resolve these errors. In the case, that there are

erroneous messages in your system and you found out what was the reason forthis, the next step is to clear the Integration Engine of this Messages.

This Screenshot shows erroneous Messages available in the Integration Engine.

To cancel a erroneous message, select the line and choose the Button “Canceling

of Messages with Errors”The Status Icon of the Messages changes to Canceled

Manually

Figure 230: Manually canceled Messages

The manually canceled Messages will be deleted from the Integration Engine,

when the Background Job for Deleting will run the next time. Of course if this

Message have to be archived due to audit reasons. This will done by the Archiving

Job before the Deletion Procedure. The Procedure of Archiving and Deletion of Messages is described more in Detail in Unit 5

The manual canceling of messages is possible in the Adapter Engine as well. Do

do this, Choose the Message Monitoring, search for erroneous messages and

press the “cancel”button. You will be asked to confirm whether you really want

to cancel this message

Payload Editing of Messages

If messages are stucking in the PI System, and you find out, that the cause of this

error is a invalid Payload, or not valid Header Values, it is possible to change this

attributes and restart the Messages again. This Payload Editor is available in theMessage Monitoring of the Runtime Workbench.

Payload editing should be handled with care for audit reasons. A better

solution is to fix the error at the sender side and send the message once more





Figure 231: Message Monitoring Overview

Run the Runtime Workbench and choose the Message Monitoring. Search for the

message. Choose the Message and click on the Button “Message Editor”

Figure 232: Message Editor

After Editing the correct Values for Header or Payload, the Message has to be

saved in the Payload Editor. After that, a new Version of this message occurs

in the Message Monitoring with the status “changed manually” In the column





Version, the new Version of this message is displayed. Now the Message is ready

to resent. To do that, select the Message and click on “Resent”The status of this

Message changes to successful.

After that, the Message appears in the Message Monitoring of the Integration

Engine (SXMB_MONI or Runtime Workbench) and has to be resent again.

Error Resolution of ccBPM

If an ccbpm process stops with an error, the deletion is not so eays then to normal

messages. For cleaning up the workflow, there are some tasks to do.

Figure 233: Display of Workflow Items

For the error resolution of integration processes the following steps have to be

done:

• Call the Business Process Engine Monitoring SXMB_MONI_BPE

• Select the entry Diagnosis Processes with errors and enter the values. The

next screen is an overview of workflows with errors

• Navigate to the list with technical details Goto => List with technical details

• In the following screen, choose Goto => Workitemto display the workitem

of the workflow

• To change the object, navigate to Edit => Changefrom the top menu





Figure 234: Change the Status of the Workflow

• to delete a workitem select Select logically delete Confirm this choice

• After the deletion procedure is finished, the number of entries from the list

has reduced





Figure 235: Deleting the Workitem

Web Service Communication

If errors have occurred during the Web-Service communication, there is adifference what could be done with this failures. For synchronous message

processing, there is no possibility to resolve the errors. The message has to be

resent from the sender.

For asynchronous messages, the sequence has to be terminated. After this manual

termination, a scheduled batch job will delete this sequence.

Monitoring sequences of Web Services messages Status of sequence processing

Status of processed messages Error analysis Events Administrating sequences

Terminate Restart Sequence Monitoring works automatically once WS Runtime

has been set up





Figure 236: Error Analysis

If a sequence has an erroneous status, it can be rejected, terminated or restarted.

• Reject: Sequence is closed and removed regardless of whether any item

has status In Process

• Close: All pending messages will be first processed before sequence

termination, new messages won’t be accepted any more. This terminationcan be done

• Restart: for failed sequences only









Exercise 7: Error Resolution Exercise

Exercise Objectives


• Able to resolve the error which you have detected in the last exercise

Business Example

You found some errors in scenarios of your company. now you want to resolve

this errors

Task:

Resolve the errors which were detected in the last exercise

1. Scenario 1: Resolve the cause of the Permission failure of the File-Adapter

2. Scenario 2: Resolve the JDBC Access Problem with the Database

3. Scenario 3: Resolve the Error with the multiple Receivers in the synchronous

scenario

4. Scenario 4: Resolve the Error with the Receiver not found and insert a

default Receiver





Solution 7: Error Resolution Exercise

Task:

Resolve the errors which were detected in the last exercise

1. Scenario 1: Resolve the cause of the Permission failure of the File-Adapter

a) Logon to the Integration Builder and choose the Configuration Scenario

Bit480_##

b) Navigate to the Communication channels and open the

CC_File_Receiver_2 of the Communication Component

BIT_480_File_RECEIVER_##

c) Change to the edit mode and verify, that the target directory is

/usr/sap/trans/tmp/group##

d) Save and activate the configuration.

e) Run the Scenario by sending the Test-Message from the Runtime

Workbench again and monitor the result

f) Navigate to your group Folder “/usr/sap/trans/tmp/group##”and search

if the message has been written on the filesystem

2. Scenario 2: Resolve the JDBC Access Problem with the Database

a) Logon to the Runtime Workbench and choose the Communication

Channel Monitoring

b) Choose your JDBC Receiver and take a look at the Error. The cause

is “Violation of PRIMARY KEY constraint 'PK_DEBITOR'. Cannot

insert duplicate key in object 'DEBITOR'.”

c) Navigate to the Runtime Workbench and in the Component Monitoring

choose the Integration Engine. Selct the Test-Message Tab and open

the Test Message Error_Detection_JDBC_##

d) Go to the Message Payload and Change the value of the tag “kunnr”to a

different value. Send the message again.

e) Open the Message Monitoring and search for Errors

f) Logon into the SQL Server Management Studio

g) Navigate to the Database TBIT480_## and choose the table Debitor

h) Verify, that your Message has been written into the Database






3. Scenario 3: Resolve the Error with the multiple Receivers in the synchronous

scenario

a) Logon to the Integration Directory and choose the Receiver

Determination BIT_480_HTTP_SENDER_## SI_Company.

b) In the overview Configured Receivers, there are two receivers listed.

Delete the second entry in the list, so that only one Receiver Test_BAPI

is available in the list

c) Save and activate the changes

d) Send the Test-Message Error_Detection_sync_00 again and monitor

the result

4. Scenario 4: Resolve the Error with the Receiver not found and insert a

default Receiver

a) Logon into the SXMB_Moni and search for the messages. The Error is

“”No receiver agreement found for , BIT_480_HTTP_SENDER_##, ,

BIT_480, http://bit480.com/xi/performance00, SI_Vendor_out“”

b) Navigate to the Integration Directory and choose the Receiver

Determination BIT_480_HTTP_SENDER_## | SI_Vendor_out

c) Take a look at the configured Receivers.

d) Change the settings “If no receiver is found, proceed as

follows”to “Select the following Receiver”and enter the Receiver

BIT_480_File_Receiver_##

e) Try the scenario again,





Lesson Summary

You should now be able to:• Be familiar with solving temporary errors







BIT480 Unit Summary

Unit Summary





Adapter Engine).












Unit Summary BIT480




Unit 5 Message and BPE Archiving & TREX

Integration

Unit Overview

During the course of this unit you will become familiar with the archivingmethods used for Messages and BPE in a SAP NetWeaver PI System.

You get acquainted with the TREX integration, that could help your business

departments by offering a payload content search.

Unit Objectives


• Describe the process of message archiving and deletion on the Integration

Engine of a SAP NetWeaver PI System.

• Describe the process of message archiving on the Adapter Engine of a SAPNetWeaver PI System.

• Describe archiving and deletion administration of Integration Processes in a

SAP NetWeaver PI System.

• Describe the usage of Index-Based Message Searching using TREX

Unit Contents

Lesson: Message Archiving & Deletion on Integration Server (ABAP) . .328Lesson: Message Archiving on Adapter Engine (JAVA) .. .. .. .. .. .. .. .. .. .342Lesson: Integration Process Administration (BPE).........................348

Lesson: TREX Integration ...... ... .... .... ... .... ... ... ..... ... ... .... ... .... .352


http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-



Unit 5: Message and BPE Archiving & TREX Integration BIT480

Lesson: Message Archiving & Deletion on Integration

Server (ABAP)

Lesson Overview

Lesson Objectives




Business Example

An SAP NetWeaver PI system has recently been installed in the system landscape

of your company. You want to know what periodical tasks for archiving messages

have to be set up on the Integration Engine to make sure that space is not used

unnecessarily.

Message Archiving on the Integration Server (ABAP)

Message processing data is persisted in tables of the PI database. A message in

a large sense contains the XML message itself but also history entries for the

processed message. These database tables are fast growing. To prevent thesetables from growing too much, several jobs are scheduled periodically.




BIT480 Lesson: Message Archiving & Delet ion on Integrat ion Server (ABA P)

Figure 237: Areas of Message Archiving in SAP Process Integration 7.10

This graphic, shows in which parts of the SAP Process Integration 7.1 Message

Archiving could be done

As the PI System receives and sends messages, there is usually one sending and

one receiving system. Because both sending and receiving system should have

message archiving an additional archiving run on the PI system itself may not be

needed. Therefore, most messages that pass through a XI system do not need tobe archived in the XI again, so you can immediately delete these messages in the

PI system without archiving.

Figure 238:

Consider that both sending and receiving systems are also able and should do their

own archiving of messages. Therefore an additional message archiving on PI

may not be required. A PI system processing a high volume of messages should

have a much shorter retention time, compared to a system with only a very low

message volume. Another aspect is that you might have specific reasons to retain





the information. The size of the database and its available disk space plays a large

role. In a high volume scenario you need to allocate a greater amount of disk space

for the storage of the processed messages.

There are a few special cases to keep in mind:

• If you are using the BPE then you should consider archiving, as messages

might be created in the BPE that do not originate in a true “sending” system.

In this case the PI system is the “originating” system.

• There might be legal reasons to have a archiving for certain types of

messages, for example you have to prove that this type of messages were

sent and received by the “other” party.

• If a message in the PI was modified, restarted or cancelled manually, you

may also need to activate the archiving for those particular messages.

Otherwise these messages will remain in your PI system forever.

Messages that have been modified, restarted or cancelled manually need

to be archived. In a Test and QA system, there are messages from tests.

Usually you can delete these from the system before doing the copy to the

next system. For example, this avoids problems with the database becoming

full with older messages. It also improves the performance of the PI

system. Deleting and archiving are client-specific procedures. Therefore,

you must schedule the archiving and delete jobs in all required clients.

The switch procedure for the deletion is a cross-client procedure and only needs to

be configured in one client of your PI system.





For the Deletion Procedure of Messages from the Integration Engine, there are

two options.

• Simple Deletion Procedure

The simple deletion procedure deletes all XML

message records from the database tables. This procedure is recommended

for smaller XML messages volumes on the Integration Engine. However, for

larger data volumes there is an adverse effect on system performance

during the deletion process itself. For this reason, the switch procedure is

recommended when processing large message volumes.

• Switch Procedure

To begin with, the original tables are the active tables. All XML messages

are saved in these tables. When the delete job is started, the table entries are

not physically deleted from the database tables as in the procedure above;

instead the Delete flag is set in the master entry. The monitoring transactionsthen do no longer display this XML message. When a specified fill level is

reached, the delete job recognizes that a reorganization (or table switch) is

required. The table copies that were inactive before now become active

tables. All new XML messages are written to the table copies. For all

existing XML messages, the system checks whether the Delete flag in the

master entry is set or not. If it is not set, all corresponding table entries from

the original tables are copied to the table copies. Once all the table entries

have been copied, the original tables in the database are deleted

and then recreated again immediately.

Figure 239: Deletion Switch Procedure

In the SXMB_ADM you have the option to set the triggering value. The fill level

is the maximum possible number of entries in the table SXMSPMAST after which

a TABLE SWITCH followed by a DROP TABLE occurs. You can set the fill

level using the configuration parameter DROP_MAX_TABLE_LOAD for the





DELETION category. The ‘Maximum Number of Table Entries’ is calculated

by a logarithm and displayed in the Persistence Layer Analysis of transaction

SXMB_ADMININ. Based on this value the actual fill level is calculated.

Figure 240: SXMB_ADMIN: Persistence Layer Analysis





Figure 241:

Example:

Lets assume the max number of entries for the SXMSPMAST is 1.000.000

entries, considered to be XI messages. A DROP_MAX_TABLE_LOAD value of

90% meaning 900.000 messages are stored in the system until the switch and

deletion is triggered. Example: Retention Period = 30 days Throughput = 10 000

messages / day first time for triggering a table switch will be after 90 days (as fill

level is reached). Any message of age 31 days and older will be marked for

deletion. Messages of age 0 – 30 days are kept, which means 60 days worth of

messages will be deleted. From that point on a “delta” growth of 60 days until the

next deletion occurs. This results in the following peak space usage considering

1Mb/entry:900.000 MB + 300.000 MB = 1,2 TB for copy and dropping procedure





Figure 242: Drop Table Procedure

There are a few things to consider:

• Do you have a legal obligation to retain messages?

• Does your business process require this?

• The deletion process is depending on two major variables

1. Retention period (days)2. Determines how long a message stays in the system

3. Determines how many messages have to be copied at each switch

4. The lower this is, the fewer messages have to be copied

5. Parameter DROP_MAX_TABLE_LOAD (percentage)

6. Determines when the switch procedure is initiated

7. The higher this value is, the more messages are gather in advance

• The benefit of the new procedure is that dropping a large table and only copy

a few messages is faster than selecting nearly all the entries from a table and

deleting them all within that one table.

What retention time does your business (process) require? set

DROP_MAX_TABLE_LOAD so: the ratio between messages to be copied

and the total number of messages is about 20% Calculation: ~ messages/day x

retention time Result: Number of messages needed to be copied at trigger of

DROP_MAX_TABLE_LOAD Example: Daily # of messages: 25.000 Retention

time: 5 days Max. # of table entries: 900.000 Messages to be copied during switch:

25.000 x 5 = 125.000 Total number of messages for the 20% ratio = 125.000 x 5 =

625.000 DROP_MAX_TABLE_LOAD = 625.000 / 900.000 = 70 [%]





Figure 243: Configure Delete Procedure

Defining Interfaces for Archiving and Retention Periods

• You define interfaces so that you can archive their XML messages. You can

also specify for how long XML messages are retained in the database before

they are deleted or archived, and how long history entries for deleted XML

messages are retained in the database.

• To periodically schedule jobs for archiving, in the Integration Engine menu,

choose Administration =>Schedule Archiving Jobs.

• As a Rule, if you are not certain if you may need messages later on,

archive them a.s.a.p.. This reduces the size of the database and increases

performance.





Figure 244: Configuration of the Interfaces for Archiving

To define interfaces for archiving, proceed as follows:

• In the Integration Engine menu, choose Define Interfaces for Archiving andRetention Periods and enter the required interfaces. The system differentiates

between sender and receiver interfaces at this point.

• You have the ability to select one or many interfaces to be archived.

Defining Interfaces for Deletion

• To delete an interface from the list, select the corresponding line and choose

Delete Interface from List. Save your changes.

• All changes made are automatically entered in a customizing request. The

system displays a corresponding dialog box, in which you must specify a

request to transport the changes. You have the ability to select one or manyinterfaces to be archived.

Define Retention Periods





Choose Retention Period on the Define Interfaces for Archiving screen

• The system navigates to the Define Retention Periods screen, where you can

enter in the corresponding fields the number of days that history entries

marked for deletion or XML messages marked for deletion or archiving

are to be retained in the database.

• If you want processed synchronous XML messages without errors to be

deleted immediately, enter 0. Save your changes.

Figure 245: Define Retention Periods





Figure 246: Parameters for the Deletion Configuration

In this table, the required Parameter are listed which are used to configure the

Message Archiving and Deletion on the Integration Engine.

Note: Asynchronous XML messages to be deleted are retained in the

database for 3 days. Asynchronous XML messages to be archived are

retained in the database for 2 days. XML messages that do not have the

status Processed Successfully remain in the database.

Archiving of XML messages

• Define the interfaces for the XML messages to be archived by choosing

Configuration → Administration → Schedule Archiving Jobs and Deletion

Jobs in the Integration Engine menu.

• Use the archiving object BC_XMB and use SAP_BC_XMB as the archiving

info-structure. If you want to read the archive, the archiving info-structure

must be activated.





Figure 247: Scheduling of Archiving and Deletion Jobs

To delete selected XML messages choose Configuration → Configure Delete Job

from the Integration Engine menu. Simple Deletion Procedure is set by default.

The XML messages are not automatically deleted from the database tables. To

delete them, you must schedule delete and/or archiving jobs. The delete andarchiving jobs are scheduled periodically using the SXMB_ADM. The default

procedure is to delete messages. If you want to archive messages, you must define

at least one interface to be archived. Switch Procedure is used by selecting the

Switch Procedure Activated check box. You can do this at any point. To delete

history entries, the following prerequisites must be fulfilled: XML messages that

belong to the history entries must already be archived or deleted because you

cannot delete history entries for XML messages that are still in the database. Note:

You can only deactivate the switch procedure when the original tables are active

and the counter for the number of deleted records in the original tables is at zero.

Scheduling Archiving Jobs

An archiving job is scheduled, which in turn schedules the jobs to write the

message to the archive and delete the archived messages. From the Integration

Engine → Administration menu, choose Schedule Archiving Jobs. The system

displays the screen Integration Engine: Archiving. Choose Schedule Archiving.

To display the scheduled job in the job overview, choose Job Overview. To use

the SAP archive administration options, choose Archive Management and then





enter the archiving object BC-XMB in the Object name field. Do not schedule

your write or delete jobs by using archive management, but use the Integration

Engine archiving functions.

Job Information Summary

The jobs are scheduled out of transaction

SXMB_ADM..


SAP_BC_XMB_ARCHIVE<client>RSXMB_ARCHIVE_PLANOnce a day

SAP_BC_XMB_DELETE_<client>RSXMB_DELETE_MES-

SAGES RSXMB_TA-

BLE_SWITCH

Once a day

SAP_BC_XMB_HIST_DELETE_<client>RSXMB_DELETE_HIS-TORY

Once a week





Lesson Summary

You should now be able to:• Describe the process of message archiving and deletion on the Integration






Lesson: Message Archiving on Adapter Engine (JAVA)

Lesson Overview

This Lesson explains message archiving on the Adapter Engine of a SAP

NetWeaver PI System.

Lesson Objectives


• Describe the process of message archiving on the Adapter Engine of a SAP


Business Example

An SAP NetWeaver PI system has recently been installed in the system landscape

of your company. You want to know what periodical tasks for archiving messages

have to be set up on the Adapter Engine to make sure that space is not used

unnecessarily.

Archiving of Messages in the Adapter Framework

During the processing in SAP PI, the messages are stored in the Integration Engine

and in the Adapter Framework. For that, it is also necessary to configure the

Archiving and Deletion of Messages in from the Adapter Framework

Asynchronous messages become persistent in the database and, after their

storage time has run, are deleted from it. This delete job starts during each

restart of the Messaging System and periodically after the time interval

defined under "persistMessageRemover.checkInterval" in the Netweaver

Administrator. The default is once a day. You can define the storage time with

the "persistDuration.default" property of the PI Adapter Service. The default is

30 days. If you expect a data throughput within this time that exceeds the size of

your database, reduce this value. Synchronous messages are deleted automatically

after 5 minutes from the Adapter Framework.By default, successful processed

asynchronous messages are deleted after 30 days. For this case no further action is

necessary. Optionally it is possible to archive messages in the Adapter Framework,

before the expiration time has expired if the retain the messages is needed




BIT480 Lesson: Message Archiving on Adapter Engine (JAVA)

Figure 248: Settings for the Adapter Framework in the Netweaver

Administrator

The following parameters are important for the Adapter Framework:

Inbound processing service properties: "xiadapter.inbound.*"

Property Name = [default] xiadapter.inbound.numberRetries.default = 3

xiadapter.inbound.persistDuration.default = 2592000000 [ms]

xiadapter.inbound.retryInterval.default = 300000 [ms]

xiadapter.inbound.timeout.default = 180000 [ms]

This time values are given in milliseconds [ms]. Converted to minutes [min],

180,000 [ms] = 3 [min], 300,000 [ms] = 5 [min], and 2592000000 [ms] corresponds

to 30 days. Only relevant for asynchronous message processing are the first threeproperties. The "numberRetries" defines how often an asynchronous message with

Quality Of Service (QoS) 'Exactly once' is to be started if the inbound processing

failed at the first attempt. The "retryInterval" specifies the waiting time interval

of the system between two retry attempts. The "persistDuration" configures how

long the message should be stored in the messaging system database. This time

value has to be higher than the product of the number of retries and the retry

interval. In order to recognize messages sent twice from the IS, this default value

should match the value in the IS (30 days by default).





Outbound processing service properties: "xiadapter.outbound.*"

Property Name = [default] xiadapter.outbound.numberRetries.default = 3

xiadapter.outbound.persistDuration.default = 2592000000 [ms]

xiadapter.outbound.retryInterval.default = 300000 [ms]

This time values are given in milliseconds [ms], where 300000 [ms] equals 5

[min], and 2592000000 [ms] equals 30 days. All three properties are only relevant

for asynchronous message processing. The "numberRetries" defines how often an

asynchronous message with Quality of Service (QoS) 'Exactly Once' should be sent

to the IS, if an error occurs during the first attempt. The "retryInterval" specifies

how much time should elapse between two send attempts. The "persistDuration"

configures how long the message will be stored in the messaging system database.

This time value has to be higher than the product of the number of retries and

the retry interval. The restrictions described above also apply to archiving and

deleting these messages. SAP internal service properties: xiadapter.isconfig.*

Important Parameters for the Messaging System

Figure 249: Parameters for the Messaging System





Synchronous messages are kept in the memory in the messaging system for

monitoring purposes. But these messages are not persistent in the database. To

prevent a memory overflow, by default, the payload is removed, independent of

whether the message was processed successfully or with errors. This behavior

can be changed with the "syncMessageRemover.removeBody" property. SAP

recommends, only to change this for test purposes, and never during productive

operation. Furthermore, only the last 1000 synchronous messages are kept in the

memory. This can be configured using the "syncMessageRemover.messageCount"

property. Messages which reach the system after that are deleted periodically

using a separate thread. This deletion interval can be set with the

"syncMessageRemover.checkInterval" property. The default is 60 minutes. In this

period of time, more than 1000 messages may be contained in the memory. If all

header fields of the synchronous message are set, 1000 messages can occupy up

to 5 MB of memory. With very high numbers of messages, it is recommended

to reduce the deletion interval. Asynchronous messages become persistent in

the database and, after their storage time has run out, they are deleted from it.

This delete job starts during each restart of the MS and periodically after the time

interval defined. By default the interval is once a day (1440 minutes). The deletion

interval for the new job type "DeleteJob". tThe storage time is configured with

the "persistDuration.default" property of the PI Adapter Service (see related note

below). The default is 30 days. If a data throughput is excepted within this time

that exceeds the size of the database, this value should be reduced.

Figure 250: Message Database reorganization





With this user interface, the retention time for messages to expired can be

configured, so that these messages can be immediately removed from the database

or archived before the Deletion. Messages which are received or sent by the "SAPXI Messaging" service and persistent in the message database, the system assigns

a time stamp how long the messages will be retained in the Database. These time

stamp can be modified with the retention time parameter. This parameter specifies

for how long the message is to be retained in the message database before it can

be archived or deleted from the message database. By default, messages are kept

for 30 days in the Database for reasons of monitoring and detection of duplicates.

If a high traffic volume is excepted, which will probably fill up the space in the

database during the retention time, the retention time should be decreased and

also it is important, that there is enough space in the database before sending the

first messages change in retention time only affects the new messages sent or

received database space.

Configure the Archiving Jobs

Figure 251: Scheduling of the Archiving and Deletion Jobs in the Runtime

Workbench

The Jobs for Archiving and Deletion for the Adapter Engine are configured in

the Runtime Workbench. In the section Background Processing this Jobs can be

scheduled. The status icon shows the status of the Job and there is also a log given.

In this log, details like time and archived or deleted Messages are displayed.





Lesson Summary

You should now be able to:• Describe the process of message archiving on the Adapter Engine of a SAP






Lesson: Integration Process Administration (BPE)

Lesson Overview

This Lesson explains administration of Integration Processes in a SAP NetWeaver

PI System.

Lesson Objectives




Business Example

In your company you have implemented several business scenarios using SAP

NetWeaver PI. Some of the scenarios make use of BPE (ccBPM). Unused

Integration Processes can be deleted on a regular basis to avoid unnecessary

consumption of DB space.

Business Process Engine Archiving/ Deletion of WorkItems

For each individual process step within the ccBPM, a separate work item is

created as in the Integration server for each message. The result of this is a verylarge quantity of work items can be generated very quickly in the system. Those

messages which are sent through the XI and are adjusted by the ccBPM can be

both synchronous and asynchronous origins. Asynchronous messages are already

persisted in the integration server and can be archived from there too. Synchronous

messages do not become persisted. Usually, it is not needed to store this data

The important question is, whether the work items can be deleted, or whether they

must also be archived. In most cases, it should suffice to archive the incoming

message. The archiving of outgoing asynchronous and synchronous messages

in usually done the sending system. If this should not be sufficient due to legal

specifications, the work items can also be archived. Therefore, not only the

incoming and outgoing message are available. Every change on the messagecan be reproduced

After Workflows have been processed, normally they are not any longer needed.

So, in the development and quality assurance environments this Workflows should

be archived. For production, this is should not be done. For more information see

SAP Note 49545 – Deleting unnecessary work items. Archiving work items is the

same process as normal archiving. The transaction code is SARA The archiving

object for workflow is WORKITEM.




BIT480 Lesson: Integration Process Administration (BPE)

To archive the work items, the WORKITEM archiving object in transaction SARA

is used. For more information, also refer to notes 621258 and 736955. To delete

work items using the ADK (Archive Development Kit), the first step is to createan archive file. The work items saved in this archive file can be deleted in the

ADK in a second step. The history for a work item and the step log for a workflow

are deleted automatically when you use the ADK.

Figure 252: Archiving Workitem Objects

For deleting work items the report RSWWWIDE is used to delete all work itemsincluding all attachments and dependent work items. Since the RSWWWIDE

report can also delete work items that do not have a final status, SAP recommends

that the selection includes after the "completed" work item status and also

according to the date and "F" work item type. Attention. Because if the report is

used incorrectly, in a worst case scenario, all work items are deleted in the system.

Therefore, always to run the report in test mode first is recommended





Figure 253: Deletion of Work Items




BIT480 Lesson: Integration Process Administration (BPE)

Lesson Summary

You should now be able to:• Describe archiving and deletion administration of Integration Processes in a






Lesson: TREX Integration

Lesson Overview

This lesson gives an overview of how to control and monitor the indexing for the

index-based message search for a SAP NetWeaver PI system

Lesson Objectives



Business Example

In your company you have a running SAP NetWeaver PI installation for message

exchange. Now you want to know more on how to make use of TREX in your

company's integration landscape as an index-based message search.

TREX Integration

The usage of TREX Message search index offers additional functionality of

searching for specific messages. In addition to static header attributes which

is possible with PI Standard Functionality, also the usage of adapter-specific

message attributes and data from the main payload of a message for the search is

possible. A requirement of this, of course is, that the messages were indexed first.

The index-based message search can be applied to one or all indexed components

of an integration landscape (domain):

• Integration Server

• Adapter Engines

• and even ABAP Business systems.

The available filter criteria depends on the selected data source and further on the

selected component. The criteria Search Method and Search Text are available

specifically for the Index data source; the Adapter-Specific Message Attributes

criterion is also available for this data source in the additional filter criteria section.

• All Messages from both the Integration Server and the Adapter Engine are

transferred to TREX for indexing

• Full Text Search on Payload

• Fast Results for Message Search

• Embedded in the Runtime Workbench

• Temporally delayed because Messages need to be synchronized with TREX




BIT480 Lesson: TREX Integration

Figure 254: TREXArchitecture

• Includes an indexing mechanism and a search engine.

• The focus is on processing mass data.

• Various different document types (such as doc, pdf, XML, or txt) and

languages are supported.

• Platform independent.

• TREX can be used by ABAP and Java applications

• In many cases payload information needs to be searched

• Use application key attributes to search for messages

• Enter e.g. “OrderID”to check whether an order was processed

• TREX is an efficient search engine, built to work on high data volumes

• Existing search mechanisms can be used

• Integration in Runtime Workbench

– Include monitoring of all ABAP and Java components within the

system landscape– Offer Index administration within RWB

– Integrate index-based search in regular message monitoring

• Use of TREX search engine

– TREX is part of SAP NetWeaver

– TREX is an already existing SAP search engine





The retention time of messages on index can be configured to be longer than the

deletion/archiving period. In this case you can search for messages that already

has been deleted/archived. But the messages are always read for indexing fromthe Database. There is no functionality to read the messages from archive to be

indexed.

For the usage of the TREX Message Search in the Runtime Workbench, the

following Configuration steps are required

• Configuration of the Integration Engine and Adapter Engine by setting up

the communication with the server and configuration of the indexing part.

• The Messages have to be indexed

• The search function has to be activated and applied.

• A user interface is necessary to search for messages using the TREX index.

In this case, the user Interface is integrated into Runtime Workbench

Figure 255: Integration of TREX in the Runtime Workbench

For informations, how to configure the TREX for PI please use the online help. In

the section SAP Process Integration -> Runtime -> Central Monitoring -> Index

Administration the required steps are defined.

For the upcoming Enhancement Packages for SAP Process Integration 7.10 is

planned to implement a Interface-specific field search without the TREX. This

feature will be realized in the ABAP Stack.





Figure 256: Message Monitoring of Iindexed Messages

The retention time of messages on index can be configured to be longer than the

deletion/archiving period. In this case you can search for messages that already

has been deleted/archived. But the messages are always read for indexing fromthe DB. There is no functionality to read the messages from archive to be indexed.

The Indexing- functionality is integrated in the Runtime Workbench and can be

started from that point.





Figure 257: Protocol of Index Administration

In the Administration Section of the Message Search, the protocol can be viewed

and errors can be analyzed.





Lesson Summary

You should now be able to:• Describe the usage of Index-Based Message Searching using TREX




Unit Summary BIT480

Unit Summary




• Describe the process of message archiving on the Adapter Engine of a SAP








Unit 6 Security Aspects

Unit Overview

At the conclusion of this unit, you will be able to understand the SAP

NetWeaver PI related security concept with the different areas like, User Security,

Tool-specific security considerations, and security possibilities on transport- andmessage level. You will get an overview on adapter type specific security aspects.

Unit Objectives


• Understand different Security areas (User Security, Network and Setup

Security - Trusted Systems, Message-based Security).

• Know how to configure SAML for PI 7.1

• Know the Adapter-specific Security options

• Appreciate the User Concept of PI

• Be aware of setting up PI Tools Security (ESR, Integration Directory)

Unit Contents

Lesson: Security Considerations .............................................360

Lesson: Adapter-Specific Security... ... .. .. .. ... .. .. .. ... .. .. .. .. .. ... .. ... .. 370Lesson: PI User and Tool Security ...........................................374


http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-



Unit 6: Security Aspects BIT480

Lesson: Security Considerations

Lesson Overview

At the conclusion of this unit, you will be able to understand the different Security

areas like: User-Security, Network- and Message-Level Security. How to use

and configure SAML for PI 7.1

Lesson Objectives





Business Example

In your PI Environment, a B2B Connection to a partner for Message Exchange

should be established. You as the responsible person for the security aspects want

to know, which the PI Systems offers and how to use them.

Why is security necessary and should be considered with Message Exchange:

• Protect Business Data

– XML messages and messages of other formats contain sensitive

business data

– communication line and persistence locations must be secured from

eavesdropping and unauthorized access

– ensure only authenticated and authorized invocation of messages

– especially true when communicating with business partners over the

open Internet

• Protect Infrastructure

– prevent system hacks

– various components of SAP PI require continuous communication

• protect authentication data (user ids and passwords)




BIT480 Lesson: Security Considerations

Figure 258: Secure Communication using SAP NetWeaver Process

Integration

Authentication and Authorization

These chapter is described more in detail in a the separate following session

Network and Transport Layer Security

• All PI runtime components support encryption of the HTTP data stream

using SSL

• Server or Mutual Authentication

– Certificate must be installed on the server component based on X.509

to enable HTTPs.

– HTTP server identifies itself with a certificate that is to be verified by

the client

– HTTP client identifies itself with a certificate that is to be verified

by the server

• Requires that SAP Cryptographic Library is installed on the AS (ABAP

and Java)

• Enabling SSL for ABAP and Java have different procedures

• SSL can also be configured for technical (internal) PI communication like

cache updates and repository access in the directory





The following steps have to be done to enable SSL for the ABAP Stack:

• Download and install the SAP Cryptographic Library

• Maintain Profile Parameters

– ssl/ssl_lib = full qualified path to sapcrypto.dll / libsapcrypto.so

– sec/libsapsecu = full qualified path to sapcrypto.dll / libsapcrypto.so

– ssf/ssfapi_lib = full qualified path to sapcrypto.dll / libsapcrypto.so

– ssf/name = SAPSECULIB

• Create the SSL Server Personal Security Environment (PSE)

– Generate a Certificate Signing Request (CSR) for that PSE and send it

to a Certification Authority (CA)

• Import the CA’s trusted root Certificate

• Import the Certificate request response into the SSL Server PSE

For more information, see help.sap.com/nw04 => SAP NetWeaver => Security

=> Network and Transport Layer Security => Using the Secure Sockets Layer

Protocol with the SAP Web AS ABAP

The following steps have to be done to enable SSL for the JAVAStack

• Download and Install the SAP Java Cryptographic Toolkit

• Create the Server’s Key Pair to use for SSL

– Generate a Certificate Signing Request (CSR) for that Key Pair andsend it to a Certification Authority (CA)

• Import the CA’s trusted root Certificate

• Import the Certificate request response

For more information, see help.sap.com/nw04 => SAP NetWeaver =>Security

=>Network and Transport Layer Security =>Configuring the Use of SSL on

the SAP J2EE Engine





Message Level Security

• Message level security is enabled through the use of digital signatures

and encryption in SAP Process Integration. With this security feature the

message payload is only visible, if the receiver of this message has the

certificate to decrypt this message.

• Digital signatures authenticate sending partner and ensure data integrity.

This is used, to guarantee, that a sent message can only me accepted from a

receiver which has the public key of this digital signature implemented.

• Adds security controls to communication level security that are required for

B2B communication

• Message level security for PI protocol and SOAP adapter is based on the

Web Services Security (WS-Security) standard

• RNIF 2.0 adapter employs the S/MIME standard• Encryption ensures that the message content is confidential

Security Assertions Markup Language (SAML)

Security Assertions Markup Language is a protocol for encoding security

related information (assertions) into XML and exchanging this information in a

request/response fashion. It provides standard based mechanisms to exchange

security information using SOAP, HTTP(s) and SAML is an OASIS standard.

SAML is an evolving standard for transferring authentication information between

security domains. SAP NW ABAP and SAP NW Java can act as a SAML

destination site in the SAML Browser/Artifact Profile for Web SSO SAP NW

Portal can act as a SAML source site in the SAML Browser/Artifact Profile forWeb SSO





Figure 259: Principal Propagation with PI 7.10

Principal Propagation

Principal propagation allows to securely pass the identity of a user from a sender

application to a receiver application. For the mediated scenario (via SAP PI)

using the new web service reliable messaging protocol for instance, this means

that the web service on the web service provider system runs under the same user

as the web service consumer application. So far, user credentials are statically

configured in destinations and channels. With Principal Propagation this can be

done dynamically, reducing maintenance effort and leading to more flexibility.

Furthermore, it's possible to verify the permissions of the original user within the

receiver application, and to audit the user in the receiver system. The following

adapters and protocols support Principal Propagation: XI, RFC, SOAP, and

WS-RM. Principal Propagation for XI, RFC, and SOAP is based on the SAP

assertion ticket. The WS-RM approach uses SAML assertions.

The Identity is described by a structured XML element (SAML tag

AuthenticationStatement) with following components Principal name SAML

issuer/attester User store (e.g. SAP system name, and SAP client).

The benefits of Principal Propagation are:

• Dynamic Configuration at the PI Receiver Channel

• Permissions of the receiver application are checked against the original user

• User can be audited in receiver system

User to be propagated must exist in the Integration Engine as a service user with

appropriate roles for message processing





Configuration of SAML for PI 7.

As a Prerequisite, the SSL Configuration has to be done. After that, for the SAML

Configuration the following steps are necessary

• Configuration of the Backend-Systems

– The trusted relationships between the involved Backend-Systems

have to be defined and in those Systems, there have some further

configuration steps to be executed.

• Configuration in the Integration Engine: For the case, that the principal

propagation should be used between two Systems using the Integration

Server, the following has to be done

– Enable Principal Propagation on Integration Engines:

Call Transaction SXMB_ADM and run Configure Principal

Configurationto activate the principal propagation on the Integration

Server. This will create a system user PIPPUSER with the role

SAP_XI_APPL_SERV_USER assigned to the same and a RFC

Destination SAXIPP<Client>.

– Configure a trust relationship between WS Consumer and WS Provider

Principal propagation is implemented using authentication via SAP

assertion tickets between the involved messaging components. Each

communication step along the way from the sender to the receiver

requires a separate authentication for each messaging component before

the message is executed. This implies that the message is executed

under the same user in all participating messaging components. Since

an SAP assertion ticket is consumed during authentication, a new

ticket is generated each time a message is forwarded to the next

messaging component. Wherever you want to use an SAP assertion

ticket for authentication between a sending and a receiving messaging

component, you have to configure a trust relationship between the

application servers first.

ABAP Client: maintain system PSE in TransactionSTRUST: Create

and export system-PSE

ABAP Server: TransactionSTRUSTSSO2: Import certificate into

system PSE’s certificate list Add certificate to ACL

– Configure trusted issuers

For all propagated users, a user mapping has to be maintained Use

multiple selection functionality for mass configuration User mapping

clarifies following questions: Do I trust the issuer of the assertion, and





hence the user that is the subject of the assertion? Which user should be

logged in? Optionally, maintain user mapping either directly in table

USREXTID, or via table view VUSREXTID

– Configure Sender / Receiver Agreement in Integration Directory

For the various protocols and adapters that support principal

propagation, you have to configure for which messages an SAP

assertion ticket is to be created for the application user.

ABAP Proxies Call transaction SXMB_ADMIN, and choose Configure

Principal Propagation. Choose Define Interfaces, and maintain

interface name, interface namespace, and user in appropriate table

Entries with an asterisk (*) are allowed in all fields. If you enter an

asterisk only, all interfaces, namespaces, or users are considered.

Java Proxies Maintain file PP_Validate.ini. It contains the interfaces

and users for which you want to activate principal propagation. You

can find this file in the directory \usr\sap\SID\SYS\global\xi. If

it does not exist, principal propagation is switched off by default.

Create or modify the file PP_Validate.ini as follows (one entry

per line): interface namespace, interface name, user. Entries with

an asterisk (*) are allowed in all fields. If you enter an asterisk

only, all interfaces, namespaces, or users are considered. (Set the

property com.sap.aii.proxy.xiruntime.principalPropagation=true in file

\usr\sap\SID\SYS\global\xi\jpf.properties)

The RFC sender programs use two different methods to obtain the

necessary information for issuing RFC calls: An RFC program uses

either an RFC destination (ABAP sender system) or a property file

according to the RFC library for external RFC client programs. For

each method, you should specify that an SAP logon ticket or an SAP

assertion ticket has to be created for the call. In an RFC destination of

type G or T, for example, there is an explicit checkbox specifying that

an SAP assertion (logon) ticket should be created.

The SOAP client itself must be able to issue SAP assertion tickets. If

the sender is an SAP program, an HTTP destination of type G can

be used. If the sender is a SOAP (receiver) adapter, simple principal

propagation can be usedConfigure Principal Propagation in the Integration Directory In the

Integration Directory, sender and receiver agreements can be configured

to propagate user identities, simply set the Principal Propagation flag.

– Maintain users to be propagated on all involved components

The users which are used for the principal propagation have to be

provided in all involved Systems, that the propagation works correctly.





Figure 260: Principal Propagation in SAP NetWeaver 7.1

• Principal Propagation on Message Level: This approach forwards the

identity data within the message itself.

• Advantage of a SAML assertion is that it is connected to the message by

a digital signature whereas the SAML assertion ticket would be loosely

attached to a message.

• The purpose of a SAML assertion is to transport principal data of a principal

identity in a secure way where the assertion is generated by a trusted system.

• Overall Mechanism:

– An application executing under user U calls a service where it is

determined upon configuration whether U’s principal data are to be

propagated to the IS. If this is the case, a SAML assertion is generated.

On message receipt, the IS first checks the SAML assertion. If the

assertion is not correct, it immediately rejects the message and sends

back an error to the sender system. Note that it is necessary here that

the IS has a trust relationship to the attester which has to be configured

in the IS. If the assertion is correct, the principal data of the SAML

assertion are extracted and the SAML assertion itself is discarded. Now

the IS must guarantee that the principal data are attached to the actual

message and that they are not compromised by any means.

– When sending a message to the final receiver the IS first determines

whether the U’s principal data are to be propagated to the receiver. If this is the case, the IS creates a new SAML assertion containing the

original principal data. Thus, the IS always implements the SAML

attester role. On message receipt, the web service consumer just acts in

the ordinary way as in the P2P case by checking the SAML assertion

and, if successful, impersonating the user assigned to U’s principal

data. In general this will be just the user with the same name as U.

• SAML assertions:





– A SAML assertion containing the subject name is created and signed

by a trusted attester system against which the sender system is able to

authenticate the subject. This assertion also contains a signature withrespect to the entire message proving the linkage of the assertion to the

message contents.

– SAML assertions are used in two flavors where either the sender

itself sends the SAML-enriched messages to the target system

(holder-of-key) or the attester forwards the message to the target system

. In the target system - similar to X.509 certificates- there has to be

established a trust relationship to the attester and a mapping of the

subject name to the actual user has to be available.

– Identity is described by a structured XML element (dedicated SAML

tag AuthenticationStatement) with components principal name, SAML

issuer / attester, and user store (e.g. this may be a SAP system nameand SAP client)

To get further informations about Process Integration Security aspects, there

is the “SAP Netweaver Process Integration Security Guide”available at the

SDN-Network





Lesson Summary

You should now be able to:• Understand different Security areas (User Security, Network and Setup







Lesson: Adapter-Specific Security

Lesson Overview

This lesson describes the individual adapter-specific options which are used to

configure the security at the adapter-level.

Lesson Objectives



Business Example

In your company, a secured Connection for message exchange with a Business

Partner should be implemented. You as the responsible Person want to know,

which Adapter offers which options for security configuration.

Adapter Specific Security

In the SAP Process Infrastructure there are several Security Settings for each

Adapter depending on the type and used technology. the following graphic shows

an overview which adapter supports Transport security and which Authentication

mechanism could be used.

Transport Level Security

Transport

protocol

Transport

security

Authentication

mechanism

XI protocol HTTP HTTPS (SSL) User/password,

client certificate,

SAP assertion

ticket

WS protocol HTTP HTTPS (SSL) User/password,

client certificate,

SAP assertion

ticket, X.509

authentication

token, SAML

assertionIDoc adapter RFC SNC User/password,

client certificate

RFC adapter RFC SNC User/password,

client certificate




BIT480 Lesson: Adapter-Specific Security

Plain HTTP

adapter

HTTP HTTPS (SSL) User/password,

client certificate

File/FTP adapter FTP FTPS (SSL/TLS) User/password,

client certificate

SOAP adapter HTTP HTTPS (SSL) User/password,

client certificate,

SAP assertion

ticket In Axis

mode also digest

and NTLM

Mail adapter IMAP4, POP3,

SMTP

HTTPS (SSL) User/password,

CRAM-MD5

Marketplaceadapter

HTTP HTTPS (SSL) User/password,client certificate

RNIF 2.0 adapter HTTP HTTPS (SSL) User/password,

client certificate

RNIF 1.1 adapter

CIDX adapter

HTTP HTTPS (SSL) User/password,

client certificate

Figure 261: Message Level Security





The Configuration of the Adapter-Security Settings is done in the Communication

Channel and in the Sender/Receiver Agreement

First of all, in the Communication Channel the Security Parameters with

the Security Profile have to be activated. After that, in the Sender/Receiver

Agreement, in the Adapter-Specific Attributes, the Security Parameters appear.

For example, the usage of Message Encryption and Digital Signature are Options

for the Sender Agreement. Of course, only the certificates can be chosen which

are already imported in the NetWeaver Administrator KeyStorage

Figure 262: Adapter Security Configuration




BIT480 Lesson: Adapter-Specific Security

Lesson Summary

You should now be able to:• Know the Adapter-specific Security options





Lesson: PI User and Tool Security

Lesson Overview

This lesson describes the user concept of the PI and how to set up the security for

the different PI Tools like SAPLogon and Integration Builder.

Lesson Objectives




Business Example

In your company, a user-concept should be created, to allow only the authorized

Persons access to the different PI Tools. You as the responsible Person want to

know, which user-roles and authorizations are available for the access to the PI

System. The user and roles information has been already provided in Unit 1 -

Lesson Administration of SAP NetWeaver PI Components.

Limit Authorization on PI Content Objects

By default, any PI content developer or configurator can modify any object in the

Integration Builder Design of Configuration. In distributed teams or in a sharedPI environment it might be necessary to limit authorization for a developer or a

group of developers to only one software component or objects within a software

component or to specific configuration objects. Therefore, specific roles can

be created in the Integration Builder Design and Configuration. Objects and

authorization on these objects can be added to these roles.

For all Objects in Design and Configuration Time, authorizations can be defined

and edited in the Integration Builder. This can be done either for all objects in the

Integration Directory, or for objects of a particular directory. When accessing an

object, the system first checks the authorizations for the directory in which the

object is located. If no authorizations are defined, the default setting takes effect.

The following steps are required to limit the Authorization on PI Objects in theIntegration Repository and Directory




BIT480 Lesson: PI User and Tool Security

• Create a new role in the Integration Builder Design

– Add Object Types of any Software Component and Namespace

• Create a new role in the Integration Builder Configuration

– Add Configuration Objects and Collaboration Agreements

• Enable usage of Integration Builder roles in Exchange Profile

– Set Integration Builder Repository Parameter

com.sap.aii.util.server.auth.activation to true

– Set Integration Builder Directory Parameter

com.sap.aii.util.server.auth.activation to true

• Assign users to the newly created Integration Builder roles

– Create dummy roles in Web AS ABAP, these roles are then available as

groups in Web AS Java

– Assign users to these roles

– Assign the Integration Builder roles to the above groups in Web AS Java

– Assign unrestricted roles to Super Users

Figure 263: PI Object Authorizations in the Design Time

Edit Default Settings for Authorizations

A default setting for authorizations can be defined. This default setting is

applied to all objects for which no explicit authorizations have been defined.

To edit the default setting for authorizations, choose Tools → Default Setting





for Authorizations in the Integration Builder main menu. The system calls the

authorization editor. Then edit the authorizations that you want to define as the

default setting.

Edit Authorizations for a Particular Object Selection

The first step is, to define the object selection for which the editing of the

authorizations should be dine. To do so, in the navigation area, position the cursor

on the directory for which you want to edit the authorizations. Then in the context

menu, choose Edit Authorizations. The system calls the authorization editor.

Finally edit the authorizations for the selected objects.

Figure 264: PI Object Authorizations in the Configuration Time

After the Creation of the Roles, they have to be assigned to the User in the ABAP

and JAVA Stack




BIT480 Lesson: PI User and Tool Security

Figure 265: Activate Authorization Check in Exchange Profile

The roles have to be assigned to the user in the ABAP and JAVA stack, which is

shown in the screenshots below.

Figure 266: Assign User to Integration Builder Roles





Lesson Summary

You should now be able to:• Appreciate the User Concept of PI





BIT480 Unit Summary

Unit Summary











Unit Summary BIT480




Unit 7 Software Logistics

Unit Overview

During the course of this unit you will become acquainted with software

logistics concepts and which tools are available in the SAP NetWeaver PI system

environment for transport management functionality.

Unit Objectives


• Know the difference between Support Packages (SP), Support Package

Stacks (SPS), patches (ABAP and Java) and Enhancement Packages).

• Be familiar with the procedure for SAP NetWeaver PI 7.1 to apply

enhancement packages, SP(S) and patches

• Outline the available transport mechanisms for SAP NetWeaver PI 7.1

objects.

• Know about best practices for Change Management and Transport setup

• Know where to find more detailed information

Unit Contents

Lesson: SPS and Patch Procedure .......................................... 382Lesson: Change Management for SAP NetWeaver PI ....................387


http://-/?-

http://-/?-

http://-/?-

http://-/?-



Unit 7: Software Logistics BIT480

Lesson: SPS and Patch Procedure

Lesson Overview

Explains SAP NetWeaver related delivery components like Support Package,

Support Package Stacks, Patches and Enhancement Packages.

Lesson Objectives






Business Example

In your company, there is a SAP NetWeaver PI 7.1 system installed and you are

responsible for keeping the system up to date from the Software Logistics side.

Now you want to know, how you implement patches and updates (SPs, EhPs) and

which best practises should be considered.

SPS and Patching Procedure

SAP provides regularly for the customers Support Packages and EnhancementPackages. The Support Packages include technical bug fixing. The Enhancement

Packages contain new functionality. The Implementation of the Enhancements

Packages, Support Packages and JAVA Patches is done with the Java Support

Package Manager (JSPM).




BIT480 Lesson: SPS and Patch Procedure

Figure 267: Shipment Strategy

The delivering of quality enhancements, program corrections, and updates for

SAP NetWeaver by SAP is done with Support Packages. Support Packages are

grouped in Support Package Stacks (SP Stacks), which can include Support

Packages for ABAP, Java and Kernel Patches. If a SP Stack is available on the

Service Marketplace, it contains the optimum combination of Support Package

and Patch levels for all NetWeaver components within one package. TheSupport Packages and Patches which are listed together in an SP Stack must be

implemented together. Round about, SAP provides a new SP Stack each quarter.

The Support Package Stacks are always available on SAP Service Marketplace

at http://service.sap.com/sp-stacks. At this place, also the informations about

the availability of SP Stacks are available and for further information there is a

Support Package Stack Guide for each Support Package Stack available. This

guide gives you detailed information about importing Support Package Stacks.

It is updated for each new SP Stack.


http://service.sap.com/sp-stacks

http://service.sap.com/sp-stacks




Figure 268: Enhancement Package Strategy

In order to strengthen SOA by evolution approach through a stable core and

continuous innovation, enhancement packages are being introduced for SAP

NetWeaver too. As known from the enhancement package strategy of SAP

Business Suite, SAP NetWeaver enhancement packages are used to provide new

innovative functionality and they

• have a minimum impact on existing functionality

• are optional• are easy to implement.

To enable the optional character of enhancement packages, each package is

separately maintained using support packages. Maintenance of SAP NetWeaver

enhancement packages follows maintenance of the SAP NetWeaver main release

(5-1-2 maintenance strategy). Applications always run on a defined SAP

NetWeaver release, which is either an SAP NetWeaver main release or an SAP

NetWeaver enhancement package (e.g. SAP Business Suite 7.0 will run on SAP

enhancement package 1 for SAP NetWeaver 7.0).

For ABAP the normal tools SPAM and SPAU are used. On the JAVA side theJava Support Package Manager (JSPM) is used to apply support packages on

deployed software components. Also SAP and third-party software components

can be deployed, to which you can then apply support packages and patches. In

addition, JSPM detects SAP software components that have been modified and

allows to apply support packages to them.




BIT480 Lesson: SPS and Patch Procedure

The JSPM is started in the following way:

• Logon to the system as <sid>adm

• Navigate to the directory /usr/sap/<SID>/DVEBMGS00/j2ee/JSPM

• Start the JSPM with go.bat for Windows or go.sh for Unix

Figure 269: Patching Procedure with the JSPM

Beside of SAP software your running environment consists of more parts to be

considered. Usually OS patches and DB patches have to be considered as well.

In general your IT organization should plan to evaluate and implement a most

recent SP(S) at least once a year. Implementing patches should be done by needs,

which means that they should be considered to be applied more frequently.





Lesson Summary

You should now be able to:• Know the difference between Support Packages (SP), Support Package







BIT480 Lesson: Change Management for SAP NetWeaver PI

Lesson: Change Management for SAP NetWeaver PI

Lesson Overview

This lesson describes the available transport options for the SAP NetWeaver PI

7.1 objects.

Lesson Objectives



objects.



Business Example

Your company wants to implement change management procedures for SAP

NetWeaver Process Integration system landscape.

Object Versioning in SAP NetWeaver PI 7.1

In general we have to distinguish between ESR (Development) and Integration

Directory (Configuration) objects in the PI environment.

ESR objects have one original repository, in other words an ESR from which an

object originates. Within an ESR you can differentiate between original objects

and copies by using an attribute of the corresponding software component version.

The objects in the ESR are created in the development system and should be

transported into the following QA and finally into the production system.

With Integration Directory transports you can transport configuration objects of

the Integration Directory from one system to another. At configuration time you

have the option of testing the configuration in a test directory. If the tests are

successful, you can then transport the configuration objects in the test directory to

the Integration Directory for the productive landscape.

Important to know is how the versioning differ between ESR and IntegrationDirectory objects.

ESR Transport is Versioned

• No new object versions are created during import.

• No manual post-processing is necessary after import.

• Import order into target system is not relevant.





Figure 270: Versioning - Enterprise Service Repository

Integration Directory Transport is not Versioned

• New object versions are created during import.

• Manual activation of imported objects is necessary.

• Import order is relevant.

Figure 271: Versioning - Integration Directory





Transport Mechanisms for PI Objects

SAP NetWeaver Process Integration 7.1 supports the following transport

mechanisms for PI Enterprise Service Repository content and Integration

Directory content:

• Transporting using the file system

• Transporting using the Change Management Service (CMS) - Java

Development Solution

• Transporting using the Change and Transport System (CTS) - ABAP

Development Solution

– Support of Loose Coupling until SAP NetWeaver PI 7.1 SP5

– Full support including Close Coupling as of SAP NetWeaver PI 7.1 SP6

Figure 272: File Transport

On the operation side a regular or on request transfer from the export directory

of the development system to the import directory on the QA and production

system has to be implemented.





Change Management Service (CMS)

is part of SAP NetWeaver Java Development Infrastructure (SAP NWDI)

• CMS is comparable to ABAP Change and Transport System (CTS)

• CMS and CTS are not integrated. This means there is no automatic

synchronization between the two.

• CMS is closely integrated with the Design Time Repository (DTR), the

Component Build Service (CBS), and the System Landscape Directory

(SLD)

• CMS is optimized for the transport of source code changes within NWDI

Figure 273: CMS Basics for SAP NetWeaver PI





Figure 274: Situation before Enhanced CTS – Various Transport Tools are

Used

The Change and Transport System (CTS) is a tool that helps you to organize

development projects in the ABAP Workbench and in Customizing, and then

transport the changes between the SAP Systems in your system landscape.

This section is meant to be an overview of how you can use the CTS to organize

your changes.

Note: See also http://help.sap.com/saphelp_nwpi71/help-

data/en/14/94fc3f8fc2c542e10000000a1550b0/frameset.htm

Figure 275: Enhanced CTS – One Transport Tool for Multiple Content Types

Transporting Non-ABAP Objects in Change and Transport System

The enhanced Change and Transport System (CTS+) enables you to transport

Java objects and SAP-related non-ABAP applications in your system landscape,

alongside ABAP objects. You can also administer non-ABAP systems in a CTS

transport domain in SAP NetWeaver Application Server ABAP.


http://help.sap.com/saphelp_nwpi71/helpdata/en/14/94fc3f8fc2c542e10000000a1550b0/frameset.htm

http://help.sap.com/saphelp_nwpi71/helpdata/en/14/94fc3f8fc2c542e10000000a1550b0/frameset.htm




You can use CTS+ to transport the following additional objects:

• Java-based and J2EE-based objects:

– Software Component Archives (SCAs)

– Enterprise Application Archives (EARs)

– Software Deployment Archives (SDAs)

• Objects from the SAP NetWeaver usage type SAP NetWeaver Portal (EP)

– Enterprise Portal Archives (EPAs)

– Enterprise Portal Applications (PARs)

– Knowledge Management objects (KM Content and KM Configurations)

• Non-ABAP objects from the SAP NetWeaver usage type PI (Process

Integration):

– Integration Builder objects (TPZs)

• System Landscape Directory content objects (products, software

components, technical systems, and business systems)

You can transport these objects together with ABAP objects in a single transport

request. When you run imports in Transport Management System (TMS), the

system performs the appropriate deployment step automatically.

Any exceptions or constraints to this information are documented in SAP Note

1003674.

The enhanced CTS functions are available when you import Support Package

Stack (SPS) 15 of SAP NetWeaver 7.0. You also require an SAP ApplicationServer Java with the same Support Package level.

We recommend that you configure a dual-stack system.

The enhanced functions are integrated into Change and Transport System.

The UIs of the associated applications have also been enhanced. To transport

non-ABAP objects in CTS, you require a TMS domain controller. We recommend

that you configure a dual-stack system as the domain controller.

The CTS Deploy Web service must be available on the SAP NetWeaver

Application Server of the dual-stack system. The deployment proxy must exist in

SAP NetWeaver Application Server ABAP.

You can also use the CTS Deploy Web service in the SAP NetWeaver Application

Server Java of a different SAP NetWeaver system. You only need the SAP

NetWeaver Application Server ABAP as the domain controller in this case.





In some scenarios, you need to perform some manual actions when you add

objects to transport requests. Some object types require you to perform manual

actions after the deployment as well.

• Developer View:

– Transports can be triggered without leaving the development tool

– Transports are executed automatically (schedulers, administrators,..)

• Administrator View:

– No need to install, know and use the development tools

– Transports can be managed and monitored by single, reliable and

sophisticated transport and monitoring tool CTS (used for ABAP

transports for many years)

– Low learning effort for SAP administrators

– Very flexible in design of landscapes

• Quality Manager View:

– Well-defined transport routes

– Monitoring of all transports

– Support for quality assurance processes like quality gates

• Support View:

– Less learning effort and smaller variety of bugs (compared to multiple

solutions)

• General View:

– Synchronization of different transport types (e.g. ABAP, Portal etc.)

– 100% compatible with the SAP Solution Manager - ChaRM (Change

Request Management)





Figure 276: CTS+ Landscape for Dual Stacks as Used for SAP NetWeaver PI

Limitations of CMS - The former

ESR transport system CMS does NOT allow to

• reuse any ABAP transport knowledge

• build transport routes with an arbitrary number of systems in one track

• define arbitrary system roles (DEV, CONS, PROD are predefined)

• define multiple direct successor systems for each system

• select arbitrary objects for transports in any system (limitation by assembly)

• synchronize transports between ESR and other content

Advantages of Enhanced CTS -

Enhanced CTS allows to

• use the ABAP change and transport system (CTS) for ESR transport

• build transport routes with an arbitrary number of systems

• define arbitrary system roles

• define multiple direct successor systems for each system

• select arbitrary objects for transports in any system → no assembly

• support synchronized transports between ESR and other content





Best Practise - SAP's Recommendation - What to use?

• File Transport should be completely avoided due to missing recording.

• CMS can still be used for companies with a very simple landscape (e.g.

DEV-CONS-PROD), with very little ABAP (transport) knowledge and no

SAP NetWeaver AS ABAP installation. CMS can stay in use if there is

no need for synchronization of different content types (e.g. ESR, ABAP,

Portal etc.).

• CTS is especially good for companies with plans for medium and more

complex landscapes, who have a funded ABAP transport knowledge, and

who run already an ABAP transports system.

SAP will no further develop CMS, instead new development will only go into

the CTS direction.





Lesson Summary

You should now be able to:• Outline the available transport mechanisms for SAP NetWeaver PI 7.1

objects.



Related Information

SND - Resources on CTS+: https://www.sdn.sap.com/ir j/sdn/cts?rid=/webcon-

tent/uuid/c0ce1dd8-c020-2b10-d080-a1cd3e985af1


https://www.sdn.sap.com/irj/sdn/cts?rid=/webcontent/uuid/c0ce1dd8-c020-2b10-d080-a1cd3e985af1

https://www.sdn.sap.com/irj/sdn/cts?rid=/webcontent/uuid/c0ce1dd8-c020-2b10-d080-a1cd3e985af1



BIT480 Unit Summary

Unit Summary







objects.






Course Summary BIT480

Course Summary


• Explain the architecture and the components of SAP NetWeaver PI 7.1

• Know how which necessary components to need to be set up for a monitoring

environment

• Know how to monitor the operational state of the system and how to monitor

the processing of messages and service interfaces

• Know how to pinpoint and resolve error situations within the system and

address system performance and message throughput issues

Documents

BIT480 - PI – Operations(Col74)