PRINT FROM SAP HELP PORTALDocument:SAP NetWeaver Process Integration

File name:saphelp_nw73ehp1_en_ac_5eac92a34e45a2831ee59e9bce0f8d_frameset.pdf

URL:http://help.sap.com/saphelp_nw73ehp1/helpdata/en/ac/5eac92a34e45a2831ee59e9bce0f8d/frameset.htm

Date created:March 05, 2013

© 2012 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. Theinformation contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components ofother software vendors. Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, System ads,System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400,AS/400, S/390 Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes,BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity,Tivoli and Informix are trademarks or registered trademarks of IBM Corporation. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. Adobe, theAdobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Oracle is aregistered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame,WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks ofW3C ®, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of SunMicrosystems, Inc., used under license for technology invented and implemented by Netscape. SAP, R/3, xApps, xApp, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAPBusiness ByDesign, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany andin several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this documentserves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and itsaffiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions withrespect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products andservices, if any. Nothing herein should be construed as constituting an additional warranty.

PUBLIC© 2012 SAP AG. All rights reserved.

Page 1 of 130

SAP NetWeaver Process Integration

This documentation provides an entry point to the main procedures and key concepts that are relevant for those who work with SAP NetWeaver ProcessIntegration (SAP NetWeaver PI). It is targeted at development and integration experts who need to develop and configure integration scenarios. However, it alsoprovides an entry point to the documentation for administrators who want to operate and monitor integration scenarios.

The documentation provides an overview of the tasks and tools that come into play in integration projects.

The documentation is targeted at both beginners wanting to get involved in the topic, and experts already involved in real-life integration projects and who needall of the key information in one place to help them keep their orientation and not lose the central theme.

We recommend that beginners first read section Getting Started .

Structure of this Documentation

You can install SAP NetWeaver PI in different ways:

Dual-stack installation: Based on both AS ABAP and AS Java.

Advanced Adapter Engine Extended (AEX): Based on AS Java only.

More information: Installation Options

The concepts and procedures depend on the chosen installation option. Therefore, the structure of this documentation is geared to the installation options.

This documentation contains the following main sections:

Section Content Relevant forInstallationOption

Concepts Provides information on the concepts and capabilities of SAP NetWeaver PI.Sub section Basics is suitable for beginners to get a quick understanding of the basic capabilities andconcepts.Sub section Advanced Concepts provides information on sophisticated concepts.

Dual-Stackand AEX

Development andConfiguration Tasks (Dual-Stack)

Explains end-to-end how to set up integration scenarios. Provides an overview of the basic procedures andlinks to detailed task descriptions.Sub section Advanced Development Tasks (Dual-Stack) provides procedures and concepts aboutadvanced integration topics like mapping, routing, business-to-business integration, and cross-componentBusiness Process Management, for example.

Dual-Stack

Development andConfiguration Tasks (AEX)

Explains end-to-end how to set up integration scenarios. Provides an overview of the basic procedures andlinks to detailed task descriptions.Sub section Advanced Development Tasks (AEX) provides procedures and concepts about advancedintegration topics like mapping, routing and business-to-business integration, for example.

AEX

Special Development andConfiguration Tasks (Dual-Stack and AEX)

Contains special procedure descriptions valid for both installation options. Dual-Stackand AEX

Administrative Tasks Provides information for administrators who need to operate an SAP NetWeaver PI landscape and to monitorintegration scenarios at runtime.

Dual-Stackand AEX

If you want to get involved into the topic and set up your first running scenario, choose one of the available demo scenarios.

More information: Examples

Related Documentation

These are related information sources:

As a prerequisite to work with SAP NetWeaver PI, you need to install and configure the software.

To find the relevant installation guide, go to SAP Service Marketplace at http://service.sap.com/instguidesnw .

To find more information on the technical configuration, see Configuring Process Integration (PI) After Installation.

The SAP NetWeaver PI security guide explains the security features of SAP NetWeaver PI and recommends how to apply these features to protect data and tomaximize the confidentiality of data that passes through a PI landscape.

More information: SAP NetWeaver Process Integration Security Guide

Getting Started

This section gives guidance to beginners on how to get started with SAP NetWeaver PI.

Note

Recommendation

PUBLIC© 2012 SAP AG. All rights reserved.

Page 2 of 130

This section gives guidance to beginners on how to get started with SAP NetWeaver PI.

For those who are new to the topic, we recommend that you start your journey in the following way:

What You Would Like to Do Recommended Section

Get an overview of SAP NetWeaverPI and understand the basicconcepts.

BasicsIt will not take you longer than two hours to read through this section.

Understand the typical sequence ofsteps that an integration expert has towalk through.

Depending on the chosen installation option and use case, choose one of the following sections:Setting up Scenarios Using Dual-Stack Message Processing (for dual-stack installation option)Setting Up Scenarios Using Local AAE-Based Message Processing (for dual-stack installation option)Using Advanced Adapter Engine Extended Stand-Alone (for Advanced Adapter Engine Extended)Connecting Advanced Adapter Engine Extended to an Integration Server (for Advanced Adapter EngineExtended)

These sections walk you through the overall end-to-end procedure and contain links to detailed documentation related toeach step of the procedure. These sections are therefore also useful to an expert during an integration project to keepan overview of the whole situation

Understand how to operate andmonitor integration scenarios.

Administrative Tasks

Find out how to access the tools. Tool Access

Set up and run your first simplescenarios based on PI.

Examples

Concepts

This part of the documentation introduces the concepts and capabilities of SAP NetWeaver Process Integration (PI).

This section is relevant for both, the dual-Stack and the Advanced Adapter Engine Extended installation option.

Basics

Provides the basics in one place.

Is suitable for beginners to get a quick understanding of the basic capabilities and concepts.

Advanced Concepts

Covers advanced concepts like, for example, mapping and content-based routing.

Basics

This part of the documentation introduces the concepts and capabilities of SAP NetWeaver Process Integration (PI).

This section is relevant for both, the dual-Stack and the Advanced Adapter Engine Extended installation option.

Introduction

Key Capabilities

Installation Options

Describes the available installation options of SAP NetWeaver PI as well as the connectivity options that they support (for example, the supported adapters).

Phases of an Integration Project

Describes the phases design time, configuration time, and runtime . These phases constitute the main framework along which all concepts and procedures areoriented.

Process Integration Landscapes

Describes the different options how to design landscapes of PI components.

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 3 of 130

Introduction

Integration of Processes

SAP NetWeaver Process Integration (SAP NetWeaver PI) facilitates the integration of business processes that span different departments, organizations, orcompanies. Think of an application component being part of the value chain of a business application or a business process.

The term process component is also used to describe this entity.

If we assume that a business application ranges over different departments of one company, then an application component usually represents one part of theprocess that is performed in one department.

An integration scenario is used to model the process flow and the separation of a business application into its application components. Application componentscan run on different systems, can be hosted in different departments of a company, or can be implemented in completely different companies that have abusiness relationship with each other. The application components exchange data with each other and thereby ensure that the value chain of the businessprocess as a whole is maintained.

The focus of SAP NetWeaver PI is not on the “inner-life” of the individual application components, or how the business logic is implemented within an applicationcomponent, but rather on how the application components exchange data with each other. Process integration is all about choreographing the exchange of databetween application components.

Mediation

Technically, the business logic of different application components in an integration scenario is implemented on different systems. Let us assume that thesystems involved in an integration scenario communicate directly with each other. For example, if the application components run on different SAP systems, oneSAP system calls another using a remote function call. We call this kind of communication “point-to-point” or “direct communication”. However, an upgrade to onepart of the system landscape would, for example, entail that all individual connections that are affected also have to be adapted as part of the upgrade. In the caseof large system landscapes, this approach could easily get out of control since the number of connections grows to the square of the number of systems.

However, consider a situation where a central instance or “middleware” interconnects the systems. We call this type of communication “mediated communication”and refer to the middleware as the SAP NetWeaver PI runtime engine. With a central instance interconnecting the systems, you then have the option to have allintegration-relevant information accessible at one central location. In contrast to the point-to-point scenario (where there is a “spaghetti-like” arrangement ofconnections), in a mediated scenario the number and arrangement of connections remains manageable.

The following figure illustrates the difference between mediated and point-to-point communication:

Point-to-Point Communication (Left) Compared to Mediated Communication (Right)

Mediated communication is executed by exchanging XML messages. Accordingly, in the context of SAP NetWeaver PI we usually speak of message-basedintegration. The messages contain the business data exchanged between the systems involved in a cross-component process. The message protocol of SAPNetWeaver PI (which the runtime engine can process) is based on the W3C standard SOAP Messages with Attachments.

More information: Messages

Key Capabilities

This section provides a summary of the key capabilities of SAP NetWeaver PI.

More information:

Connectivity

Mapping

Routing

Connectivity

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 4 of 130

Overview

Connectivity is the capability to connect systems or applications that have different technical communication capabilities to each other using SAP NetWeaver PI.Examples for technical communication capabilities are the HTTP protocol or a remote function call (RFC). The transformations of messages that are required at atechnical level and that are necessary to connect the system to the runtime engine of SAP NetWeaver PI are performed by adapters. SAP NetWeaver PI providesa variety of adapters to connect applications that are based on completely different technical or application-specific protocols. The runtime engine transforms eachincoming message into an internal message format first before the message can be processed. This is done by an adapter at the inbound side (also referred toas: sender adapter). Depending on the characteristics of the receiver system, an adapter at the outbound side (a receiver adapter) then transforms the internalmessage format into the format or protocol the receiver system can handle.

Do not confuse connectivity with mapping: Connectivity implies transformations between the technical or industry-specific protocols of the connectedapplications. A technical “protocol” can, for example, be a simple file format, or an IDoc format. An industry-specific protocol can be RosettaNet or EDI. Incontrast to that, mapping is the transformation of the business data in the payload of the message, which can, for example, include the transformation of onedata field format ( YYYYMMDD ) to another ( YYYY-MM-DD ).

In particular, SAP NetWeaver PI provides connectivity to:

Technical protocols such as JDBC, JMS, HTTP, and many more

Industry-specific protocols, for example, RosettaNet or CIDX

SAP applications that send or expect their data with IDoc and RFC

To ensure greatest possible spectrum of connectivity options, SAP provides a large set of own-developed adapters, and also accepts adapters developed bypartners.

Additionally, customers can develop their own adapters with SAP NetWeaver PI in case they do not find the adapter to fit their needs.

The following figure illustrates the connectivity capabilities of SAP NetWeaver PI.

Connectivity Capabilities of SAP NetWeaver PI

Mapping

In scenarios spanning different application systems, or even different organizations and enterprises, it is most likely that the structure of the data exchangedbetween two process components differs on both sides of a connection due to business-related reasons. To enable a seamless exchange of data, the datastructures on both sides of a connection have to be transformed into each other.

Mapping determines the following aspects:

How structure nodes (or elements) in a source structure are assigned to structure nodes in a target structure

Which conversion rules apply for the transformation between source elements and target elements

Mapping describes transformations at the level of the business data that is exchanged between process components. This can also include special formatsfor particular business entities, for example, the format of a time field in a message. Transformations at the level of the technical transport protocol are handledby adapters (that form the connectivity capabilities of SAP NetWeaver PI).

The following figure illustrates a simple mapping step. Note that the figure illustrates what happens both at configuration time and at runtime, and shows systemsconnected to each other rather than process components. But keep in mind that mappings can already be defined at design time.

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 5 of 130

Simple Mapping Concatenating two Fields of a Source Structure into one Single Target Structure Field

Routing

Routing covers all rules that define the flow of messages between different systems at runtime. SAP NetWeaver PI supports in particular routing that depends onthe content of the exchanged message. For example, you can define a routing rule of the form that all messages with a specific value of one particular messagefield will be sent to a specific receiver system.

For example, the runtime engine of SAP NetWeaver PI detects messages where the customer number field has a specific value and forwards them to specificreceiver systems, which are intended to handle requests coming from the corresponding customer.

The following figure shows a scenario where a message is forwarded to three different receivers:

Routing a Message to Three Different Receiver Systems

Installation Options

When you run a scenario based on SAP NetWeaver PI, multiple systems or applications (shortly referred to as application system or business system)communicate with each other using an interconnected system that hosts one or more runtime engines. Connectivity and message processing capabilities aretechnically based on the runtime engines. When you install SAP NetWeaver PI, you install one or more runtime engines on a host system. SAP NetWeaver PIprovides different installation options, each of them offering different options for setting up the runtime engines.

Installation Options

Basically, you can install SAP NetWeaver PI in the following ways.

PUBLIC© 2012 SAP AG. All rights reserved.

Page 6 of 130

Installation Option Description

Dual-stack installation Is technically based on both AS ABAP and AS Java and comprises the complete functional range of SAP NetWeaver PI.Provides tools for designing and configuring integration content (Enterprise Services Repository, Integration Directory and SystemLandscape Directory), as well as the following runtime engines:

Integration EngineBusiness Process EngineAdvanced Adapter Engine

More information: SAP NetWeaver PI Dual-Stack Installation

Advanced AdapterEngine Extended(AEX)

Is technically based on AS Java only.Provides tools for designing and configuring integration content (Enterprise Services Repository, Integration Directory and SystemLandscape Directory), as well as the Advanced Adapter Engine as runtime engine.

However, when using this installation option, the functional range of these tools is slightly restricted as compared to an SAPNetWeaver PI installation.

In releases prior to SAP NetWeaver 7.3, an SAP NetWeaver PI installation was always based on both AS ABAP and AS Java(dual-stack). As of SAP NetWeaver 7.3, you have the option to choose an AS Java-only installation option, the AEX.

More information: Advanced Adapter Engine Extended

You have also the option to combine the Process Integration capabilities of the AEX with SAP NetWeaver Business Process Management by installingProcess Orchestration.

For more information, see SAP NetWeaver Library at help.sap.com under SAP NetWeaver Library: Function-Oriented View Process Orchestration .

Do not mistake cross-component Business Process Management (ccBPM) for Process Orchestration.

Process Orchestration is based on AS Java only, and modeling is performed using the Process Composer. In contrast to that, ccBPM contains functions forenhanced service orchestration as part of a dual-stack SAP NetWeaver installation. It is based on both Application Server Java and Application ServerABAP. Modeling in the context of ccBPM is performed using the Enterprise Services Repository (based on integration processes as design time objects).

Runtime Engines

Depending on the used installation option, SAP NetWeaver PI provides the following runtime engines:

Integration Engine (IE) (only for dual-stack installation option)

Based in Application Server ABAP and contains the following adapters: IDoc (IE), XI (connectivity to proxy runtime), HTTP (IE), as well as the connectivity tosystems or applications based on Web Services Reliable Messaging (WS channel).

Advanced Adapter Engine

Based on AS Java and provides the following adapters: RFC Adapter, SAP Business Connector Adapter, File/FTP Adapter, JDBC Adapter, JMS Adapter,SOAP Adapter, Marketplace Adapter, Mail Adapter, RNIF Adapter, CDIX Adapter, IDoc Adapter (AAE) (adapter type DOC_AAE ), HTTP Adapter (AAE)(adapter type HTTP_AAE ).

Business Process Engine (only for dual-stack installation option)

Based in AS ABAP and comes into play when you execute scenarios that contain integration processes (cross-component Business Process Management).

Connectivity Options

The following figure shows an overview of the available connectivity options for both dual-stack and AEX installation option.

Note

Note

Note

Caution

PUBLIC© 2012 SAP AG. All rights reserved.

Page 7 of 130

Connectivity Options of SAP NetWeaver — Dual-Stack and AEX

Phases of an Integration Project

Decoupling Business Semantics from Implementation Details

If we assume the different parts of a cross-system business application and their interactions are “hard-coded” on the individual systems that the process spans,then every change at the technical implementation level (such as changing a server address) entails a change to the whole business process. This is time-consuming, error prone, and does not scale for complex business processes and large system landscapes. Therefore, one basic principle of SAP NetWeaver PIis to de-couple the business semantics from the technical details of the concrete system landscape. Business semantics are, for example, the business flow of aprocess and its separation into individual application components, as well as the structure of exchanged data. These aspects of a business process are merelydetermined by business considerations rather than by details of the implementation or of the concrete system landscape.

Design Time, Configuration Time, and Runtime

Based on this de-coupling, it is possible to describe the integration-relevant aspects of a business process at an abstract level first – irrespective of the details ofa particular system landscape. We call the corresponding phase of an integration project the design time. In other words, at design time, you can specify anintegration scenario independent from any technical details that are implementation-relevant or system landscape-relevant.

In a later phase – at configuration time – the integration scenario will be configured such that it runs in a specific system landscape. The phase when theintegration scenario is executed is referred to as runtime. You can consider one and the same integration scenario being deployed on completely different systemlandscapes. For example, in one case there is a material management integration scenario that spans only a few systems within a midsize company, whereas inanother case the same integration scenario spans several hundreds of systems located in the different departments of a large enterprise. The same scenario inthis case involves the execution of the same business logic - just on a different scale. The scenario is finally executed at runtime and can be monitored by anadministrator.

The following figure illustrates the relationship of the design time and runtime view:

PUBLIC© 2012 SAP AG. All rights reserved.

Page 8 of 130

Comparison of Design Time and Runtime View

The upper part of the figure shows an interaction of two application components as modeled at design time. As an example, the left application component sendsa request to the right one. You can consider this interaction as one little part of an integration scenario.

At configuration time, this interaction is configured in a way that it runs in a specific system landscape.

The lower part of the figure shows the runtime view which results out of the configuration time activities.

The system landscape in general is composed of many business systems. For the request-response interaction outlined in the figure, the business logic of therequestor application component is deployed on (one or more) sender systems, and the business logic of the responding application component is deployed on(one or more) receiver systems. The communication of sender and receiver systems is mediated by the SAP NetWeaver PI runtime.

The three phases introduced here can be considered to be phases of an integration project.

More Information

Design Time

Configuration Time

Runtime

Design Time

At design time, an integration developer designs the integration-relevant aspects of a business process at an abstract level, independent from anyimplementation-relevant details.

The following aspects of a business process can already be specified at design time:

The process flow and its separation into individual process components (or application components)

The Enterprise Services Repository (ES Repository) allows you to outline the integration-relevant aspects of business processes, for example, using a processintegration scenario model type.

The interfaces that determine the data exchange between application components and the detailed structure of the data – of the messages – that is beingexchanged

The mapping or transformation of data structures on both sides of a connection

In a mediated communication step, the sender normally uses a data format and structure for sending out a message that is different to the one that the receivercan handle. The data structure and format used by the sender therefore has to be transformed into the structure and format that the receiver can handle. Thistype of transformation is called mapping. You specify the corresponding transformation rules in the ES Repository – in the form of mapping objects.

The design time-relevant aspects are specified and stored in the ES Repository. The corresponding content is referred to as integration content.

It is recommended to design integration content using the top-down design approach.

More information: Top-Down Design

Note

Recommendation

PUBLIC© 2012 SAP AG. All rights reserved.

Page 9 of 130

Top-Down Design

When you apply the top-down design approach, you first define the overall integration scenario at a high level, in particular, its separation into individual processcomponents and how these are connected with each other. This gives you a bird’s eye view of the integration. You do this in a model, as we will show below.Based on the model, you then specify the other relevant integration content objects like interfaces, data types, and mappings in more detail.

These are the main tasks when you design integration content top-down:

Design Task Design Objects

Modeling the integration-relevant aspects of across-component process – or how processcomponents interact with each other

Process modelsYou define a process model to start with (for example, a process integration scenario). Based on the model,you create the corresponding integration content that specifies the integration in more detail (interfaceobjects, mapping objects, and communication channel templates).

Specifying how one process component (orapplication component) exchanges messageswith another

Interface objectsThere are different interface object types available that describe these aspects – from the communicationmode of message exchange down to the detailed data structure of a message.

Specifying how data structures are transformedinto each other

Mapping objects

Pre-configuring connectivity/adapters Communication channel templatesYou use communication channel templates to specify those adapter settings for connectivity that are alreadyknown at design time.

After having finished the design tasks in the ES Repository, you need to generate proxies for the interface objects in the corresponding back-end systems Theinterface objects defined in the ES Repository are merely metadata that are independent from any programming language. Using proxy generation, you convertnon-language-specific interface descriptions into executable interfaces.

Configuration Time

At configuration time, an integration expert (for example, an integration consultant) configures the integration scenario specified at design time for a specific systemlandscape to enable the scenario to run in this system landscape.

The first configuration task is to identify the “players” of the game at runtime – the systems that actually communicate with each other – and relate them to thecorresponding process components.

At configuration time, the interaction of “abstract” application components is typically broken down into system-to-system interactions.

Based on this assignment, an integration expert specifies further details on how the messages are to be exchanged between the systems:

How the messages are routed by the runtime engine from a sender system to one or multiple receiver systems

How the individual systems (each may be based on different technical characteristics) can be connected to the runtime engine (connectivity and adapters)

Which security-relevant settings apply to the data exchange (for example, if messages are secured using digital signatures)

Configuration Settings in the Integration Directory

The relevant configuration settings in Integration Directory are structured in the following way:

Collaboration Profile

Defines those entities that interact with each other based on the exchange of XML messages.

These are typically systems or applications and are represented at configuration time by communication components. In addition to that, you define thecommunication capabilities of the components. These are represented by communication channels.

Optionally, you can also define communication parties as additional entities, typically suitable in business-to-business scenarios.

Configuration of Message Exchange

Specifies how messages are exchanged between communication components.

At configuration time individual system-to-system interactions are specified. As a configuration expert has to provide all the information necessary for the runtimeengine to handle the exchange of messages, it is most natural to “take up” the position of the runtime engine. This means, for each incoming message (whicharrives at the runtime engine), the configuration expert has to determine what should happen with this message - for example, which receiver systems it is tobe sent to, or how it is to be mapped.

Configuration of Message Exchange

The following figure illustrates what happens with an incoming message:

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 10 of 130

Processing of an Incoming Message

For an incoming message the following aspects have to be specified:

Inbound processing

Defines how the incoming message is to be transformed technically to the XML message format that the runtime engine (“PI runtime”) understands.

Inbound processing might also include additional security-relevant aspects, for example, how to handle the signature of the incoming message, or how todecrypt the incoming message, if these special security standards have been applied by the sender of the message.

Routing

Defines which receivers the incoming message is to be forwarded to.

The figure indicates the fact that in general multiple receivers can be configured for an incoming message.

The configuration of routing may also include routing conditions.

Mapping

Defines how the business data of the message is to be transformed with regard to a particular receiver (in contrast to the technical XML message format that ishandled during inbound processing).

For an incoming message sent to a particular receiver you select a predefined mapping from the ES Repository.

Outbound processing

Defines how a message should be transformed technically with regard to a specific receiver. Outbound processing again implies a technical transformationstep: A transformation from the XML message format that the runtime engine “speaks” to the protocol or standard that the receiver system can handle.

Outbound processing may also cover additional security-relevant aspects, for example, how to sign or encrypt an outgoing message in case these securitystandards are agreed on with the receiver.

Use of the Terms Outbound and Inbound

When used in the context of design time objects, the terms outbound/inbound refer to the “perspective” of the application component. When used in thecontext of configuration time objects, the terms outbound/inbound refer to the “perspective” of the runtime engine.

For example: An outbound service interface (a design time entity) is a service interface whereby a message is sent out from the application (where theinterface is implemented) to another application. In mediated scenarios, such a message is sent first to the runtime engine of SAP NetWeaver PI(interconnected between the two applications) and then sent from there to the other application. Therefore, a message sent by an outbound interface is theincoming (or inbound) message as seen from the perspective of the runtime engine. In other words: The incoming message (as used in the configuration timecontext) is then determined by an outbound interface implemented on a sender system.

The procedure and the relevant configuration objects needed to configure the message exchange depend on the chosen installation and connectivity option.

Configuration data maintained in Integration Directory is made available to the involved runtime engines by a cache refresh mechanism.

Based on these configuration settings, the message is processed at runtime by the involved runtime engines.

More Information

Installation Options

Runtime

Runtime

The business process is executed in the system landscape at runtime, which means that the process is executed and messages are exchanged between thesystems involved. In mediated scenarios, messages are processed by a central instance — or: runtime engine — that interconnects the systems.

This section provides detailed information on how a message is processed by the involved runtime engines.

At runtime, a message passes through the following steps:

01. Sender adapter processing

Based on the configuration of the sender adapter, the message is transformed technically to the XML message format the PI runtime can process (“XImessage format”). In case also additional security-related configuration settings apply, the message is handled accordingly.

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 11 of 130

02. Runtime engine pipeline processing

Processing of the message in the pipeline contains the following steps:

01. Inbound XML validation

Based on the configuration settings, the inbound message is checked with regard to validity of its XML schema.

02. Receiver determination

Based on the configuration setting (routing configuration) that is found in the runtime cache for the message, the receivers of the message and the routingconditions are evaluated. The receiver is written into the message header. In case multiple receivers are configured, for each receiver, a separate messageis created.

03. Mapping

Based on the configuration setting (mapping configuration) that is found in the runtime cache for the message, the assigned mapping program is performedand the content of the message transformed accordingly.

04. Interface determination

Based on the inbound interface configuration that is found for the message, the assigned inbound interface (at the receiver side) is evaluated.

More sophisticated scenarios can be configured where a message is sent to multiple inbound interfaces or where a large message is split into several“message chunks” which are then sent to different inbound interfaces. For sakes of simplicity we do not consider these cases here. .

05. Outbound XML validation

Based on the configuration settings, the outbound message (to be sent to the receiver) is checked with regard to validity of its XML schema.

03. Receiver adapter processing

Based on the configuration of the receiver adapter, the message is transformed technically from the “XI message format” to the format the receiver can process.In case also additional security-related configuration settings apply, the message is handled accordingly.

Messages

The message format used by the SAP NetWeaver PI runtime engines is based on XML. Since a message can also have binary attachments in addition to thebusiness data in XML, this documentation refers predominantly to messages in general and not specifically to XML messages.

XML Properties

XML (eXtensible Markup Language) allows the description of data in a form that is legible for people. An XML schema definition specifies which elements maybe used, which attributes have these elements, and what structure they have. More than one instance (a document that matches an XML schema definition) canexist for each schema. The following example of an instance illustrates that the elements in a schema are ordered hierarchically:

<PurchaseOrder no="1811">

<ShipToParty>

<Name>Brian Adams</Name>

<Address>200 S Wacker Drive Chicago IL 60606</Address>

</ShipToParty>

<Item> Bass Guitar No.14 </Item>

<Status>Confirmed</Status>

</PurchaseOrder>

These elements (for example, <Item> ) are also known as tags in HTML.

You can describe the structure of a schema by using an XML schema. As well as the description of the structure of an XML document (elements, attributes,hierarchy), this language allows you to define simple and complex data types. Note the following difference:

XML schema language provides a series of language constructs that you can use to describe an XML schema.

XML schema definition describes exactly one XML schema and is defined using the XML schema language.

More than one schema instance can exist for an XML schema. A schema instance is an XML document; its structure and values are defined using acorresponding XML schema definition. The process whereby the system checks whether an XML document matches a schema definition is called validation.

The terms XML instance or schema instance are often used instead of XML document. Whereas the term XML document is normally used to refer to adocument on a file system, the storage medium is less important in the other two terms.

The W3C recommendation for XML schema dated May 2, 2001 comprises three parts: HYPERLINK "http://www.w3.org/TR/xmlschema-0/", HYPERLINK

Note

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 12 of 130

"http://www.w3.org/TR/xmlschema-1/" und HYPERLINK "http://www.w3.org/TR/xmlschema-2/".

Message Protocol

The message protocol used by SAP NetWeaver PI is based on the W3C note SOAP Messages with Attachments. For more information, seewww.w3.org/TR/SOAP-attachments . The runtime engine of SAP NetWeaver PI expects a message that has the following structure:

Message Structure

The SOAP header of a message contains all the important information that the runtime engine of SAP NetWeaver PI requires to forward the message, while thePayload contains the actual business data (such as <PurchaseOrder> in the example above). You can also append an unlimited number of attachments tothe message before it is sent. Attachments typically comprise non-XML data, for example, pictures, text documents, or binary files.

The information in the message header must have the correct format for the message to be processed by the runtime engine of SAP NetWeaver PI. The payloadis not touched unless a mapping needs to be executed.

Discussion

Using XML technology has, among others, the following advantages:

XML is the standard exchange format in the Internet. Before this standard was created, there were practically no open exchange formats, which madecommunication in heterogeneous system landscapes very difficult.

Further standards and tools now exist that make working with XML even easier, examples being XML Schema, XSLT and XPath. XSLT (eXtensibleStylesheet Language for Transformations), for example, enables you to define mappings for messages with different structures. XPath expressions enableconditions to be evaluated depending on values in the payload . Evaluations of this type are required for receiver determination in logical routing.

As a standardized format, XML also enables you to connect to external systems. Once data from an external system has been converted to XML using anadapter, then it is a simple step to convert the data to other XML formats for other receivers.

Web Services Protocol

Aside from the message protocol, SAP NetWeaver PI supports the Web services protocol. A Web service is a modularized, executable unit. It can be called inheterogeneous system landscapes and is not restricted to a single host system. Based on the given input parameters, output is determined by the system. Thisis then passed back to the caller subsequently. SOAP, WSDL, UDDI, and WS-RM are the core standard for all Web service approaches.

Process Integration Landscapes

Central Versus Federated Landscape Design

SAP NetWeaver Process Integration landscapes can be designed in the following ways:

One single SAP NetWeaver PI instance (PI instance) is used as integration middleware for the complete system landscape.

Multiple PI instances are used in conjunction with each other. In this case, each PI instance covers either different kinds of scenarios or different parts of thesystem landscape.

This kind of landscape design is called federated PI. Federated landscapes are the medium of choice in situations where you need to strictly separate parts ofyour business according to different needs.

A globally-acting enterprise designs its PI landscape in such a way that a central PI instance (for example, a dual-stack PI installation) is used forbusiness-to-business processes that span several countries. In addition to this, local PI installations (for example, in that case, Advanced Adapter EngineExtended installations) are used to cover processes that run within individual countries.

As a second example, an enterprise can also separate landscapes for different organizational units.

Example

PUBLIC© 2012 SAP AG. All rights reserved.

Page 13 of 130

You can use both dual-stack PI instances and Advanced Adapter Engine Extended (AEX) instances (based on AS Java only) in a federated way.

You can also “mix” both installation options in a federated landscape design.

The following figure shows an example of a federated PI landscape with “mixed” usage of PI dual-stack installation and AEX installation.

Example of a Federated PI Landscape (one Dual-Stack PI Instance is Used Centrally and Multiple AEX Instances are Used Locally)

For each landscape design, you need to consider how to set up the individual PI components – namely, the Enterprise Services Repository, the AdvancedAdapter Engine, and the System Landscape Directory.

The following section provides an overview of the possible constellations of the PI components for different landscape design.

Using Different Landscapes for Development, Test and Productive Usage

Consider the following, additional dimension of landscape design: In general it is recommended to set up separate landscapes for development, test, andproductive usage.

In particular, it is recommended to design the landscapes in such a way that the test landscape is as similar to the productive landscape as possible. That way,it can be made sure that the most important productive scenarios can be anticipated and covered by the test cases.

More information:

Using Local and Central Enterprise Services Repositories

Using Central and Non-Central Advanced Adapter Engines

Using Local and Central System Landscape Directories

Using Local and Central Enterprise Services Repositories

In a federated landscape design, you can choose between the following constellations with regard to the Enterprise Services Repository (ES Repository):

Using a separate “local” ES Repository for each PI instance

In this setup, on each PI instance within the landscape, one ES Repository is hosted and directly connected to the “local” Integration Directory and runtimeengines (Advanced Adapter Engine, Integration Engine in case of dual-stack installation).

One disadvantage of this setup is that ESR content needs to be synchronized between different local ES Repositories and transport scenarios have to bescheduled accordingly.

Using one “central” ES Repository and connecting each local PI instance to the central ES Repository

In this setup, only one ES Repository is hosted on the central PI instance. The Integration Directory and the runtime engines (Advanced Adapter Engine,Integration Engine in case of dual-stack installation) of the local PI instance are directly connected to the central ES Repository.

The advantage of this option is that you can minimize total cost of ownership as the number of ES Repositories is minimized. You can minimize the need fortransport scenarios and administration tasks like user management.

The following figure illustrates for the dual-stack installation option how the most relevant PI components interact in a central ES Repository landscape design.

PUBLIC© 2012 SAP AG. All rights reserved.

Page 14 of 130

Constellation of PI Components when a Central ES Repository Is Used (for Dual-Stack Installation)

When you use a central ES Repository, the involved PI components communicate with each other in the following ways:

Integration Directory (local and central one) calls central ES Repository in order to access design objects for input helps.

This communication is needed in order to enable an Integration Directory user to open a (central) ES Repository object from the (local or central) IntegrationDirectory. In the following, examples for this kind of access are given:

Creating any configuration object (for example, integrated configuration) with a service interface as key element: select service interface from ES Repository(for example, to specify the receiver interface key field in an integrated configuration).

Editing integrated configuration: select operation mapping from ES Repository.

Creating communication component (type integration process): Select integration process from ES Repository.

Central ES Repository sends cache notification to the central Integration Directory after a design object in ES Repository has been activated or after an import.As indicated in figure above, the central Integration Directory then sends a cache notification to the relevant local Integration Directories (as necessary).

Local Integration Directories cannot be notified directly be the central ES Repository.

Central ES Repository calls central Integration Directory in order to access a list of communication channels in case mappings with mapping look-ups aretested.

In order to perform cache connectivity tests, the central ES Repository calls the central Integration Directory in order to obtain cache connectivity test data.Central Integration Directory calls the local Integration Directories to obtain the relevant test data (to be forwarded to the ES Repository).

It is mandatory to use a central System Landscape Directory (SLD) in case you configure your PI instance to use a central ES Repository. All PI systemssharing the same central ES Repository must be registered in the same (central) SLD.

Be careful when switching a PI landscape with a lot of existing content to central ES Repository usage. It is recommended to configure usage of central ESRepository once when the PI landscape is set up and not during productive usage. Note that switching to a central ES Repository can invalidate existingconfigurations in the Integration Directory (because ESR objects might be missing in the central ES Repository).

Using Central and Non-Central Advanced Adapter Engines

You can set up the Advanced Adapter Engine in the following ways, depending on the chosen installation option.

More information: Installation Options

Note

Caution

Recommendation

PUBLIC© 2012 SAP AG. All rights reserved.

Page 15 of 130

Dual-Stack PI Installation

In a dual-stack PI installation, you have the following options how to set up the Advanced Adapter Engine (AAE).

You can use the AAE as part of the Integration Server.

This option is called central Adapter Engine.

You can use the AAE stand-alone, next to the Integration Server.

That means, the AAE can be installed on a system with a different SAP system ID (SID) than the Integration Server and can be used as an independentintegration hub. However, note that you need an ES Repository and an Integration Directory as design and configuration tools in order to set up the scenarios.

This option is called non-central Advanced Adapter Engine.

The following figure illustrates the constellations of PI components in a non-central AAE setup for a PI dual-stack installation:

Using a Non-Central AAE within a Dual-Stack PI Installation

By default, the non-central AAE uses the user management of the Integration Server. In order to decouple the non-central AAE from the Integration Server alsowith regard to user management, you have also the option to configure a “local” user management on the host of the non-central AAE.

This setup enables you a more robust usage of the non-central AAE.

More information: User Management for Non-Central AAE (PI-AF)

Advanced Adapter Engine Extended (AEX) Installation

In an AEX installation, you also have the option of using an AAE non-centrally.

The design and configuration environment (ES Repository and Integration Directory) resides on the system of the central AAE. Both central and non-central AAEregister themselves at the same System Landscape Directory (SLD).

The following figure illustrates the constellations of PI components in a non-central AAE setup for an installation of the Advanced Adapter Engine Extended (AEX):

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 16 of 130

Using a Non-Central AAE Within an AEX

With regard to user management, the non-central AAE works completely autarkic because it uses a local User Management Engine.

More information: Advanced Adapter Engine Extended

Using Local and Central System Landscape Directories

The System Landscape Directory (SLD) is a key component in each PI landscape.

It stores information of software components, products and systems that needs to be accessed to during different phases of an integration project.

Role of the SLD in PI Landscapes

The SLD is used in PI landscapes in the following way.

At design time, the SLD needs to be accessed for the following purposes: It provides a software catalog that stores information of products and softwarecomponents. A software component is a shipment unit for design objects in the ES Repository, for example, integration scenarios or interface objects. When youcreate design objects in the ES Repository for productive usage, as a prerequisite you need to import an SLD-based software component into the ES Repository.

At configuration time and runtime, the SLD needs to be accessed for the following purposes: It stores information on business systems and technical systems. Abusiness system represents a logical system that is used as sender or receiver of messages in an integration scenario. A technical system represents thephysical system as identified by a server address and other attributes. When you configure an integration scenario for a specific system landscape using theIntegration Directory as configuration tool, you rely on the SLD data. At runtime, the correlation between business systems and assigned technical systems alsoneeds to be evaluated.

For performance reasons, relevant SLD data is hold in an SLD cache – to allow faster access from Integration Directory or runtime engines to SLD data. In order toallow SLD cache refresh, the availability of the SLD is critical.

SLD also contains the mapping of business system names as used in the development, test and productive landscapes. To evaluate this mapping, availabilityof the SLD is also critical when transporting Integration Directory content from a development to a test environment, for example.

To summarize, availability of the SLD is critical for the following activities:

Creation of products and software components (as basis for further design tasks in ES Repository)

Creation of business and technical systems (as basis for further configuration tasks in Integration Directory)

Cache refresh

(Re)start of PI components

Recommendations for SLD Landscapes

The general recommendation is to set up one (central) SLD for each productive PI landscape.

As availability of the SLD is critical for productive usage of PI, in a federated PI landscape you can set up additional (local) SLDs for each local PI instance.

In addition to that – depending on the individual requirements of your business – you can set up a separate SLD for each non-productive landscape likedevelopment or test landscape, for example.

In order to come to a final decision of your SLD landscape design, you need to trade the advantages of one single central SLD (low hardware requirements and lowoperation costs) off against the needs of high availability of SLD data.

More information: Planning Guide – System Landscape Directory available under http://www.sdn.sap.com/irj/sdn/nw-sld (How to Plan Your SLDSystem Landscape)

PUBLIC© 2012 SAP AG. All rights reserved.

Page 17 of 130

Advanced Concepts

This section covers advanced concepts like, for example, mapping and content-based routing.

The individual sub sections serve as background information and are linked to from the relevant procedures (for example, under Developing and ConfiguringIntegration Scenarios (Dual-Stack) and Developing and Configuring Integration Scenarios (AEX)).

This section is relevant for both, the dual-Stack and the Advanced Adapter Engine Extended installation option.

More information:

Advanced concepts related to design time:

Using Predefined Integration Content

Interface Objects

Mapping Objects

Advanced concepts related to configuration time:

Describing the System Landscape in the SLD

Separation of Business Systems and Technical Systems

Collaboration Profile

Content-Based Routing

B2B Configuration

Using Predefined Integration Content

You have the option to start an integration development project using integration content predefined by SAP. There is a lot of predefined content already availablethat can be reused and which helps customers to save time and effort in their integration development projects. Typically, customers do not use predefinedcontent 1:1 without adapting it to their needs. A typical use case is that customers use data types, service interfaces, and mappings provided by SAP and buildtheir own process model based on these entities, enriched by interfaces and mappings developed on their own. Another option is to use a predefined processmodel (and all underlying entities) where only one side of the communication is specified, and to specify the other part of the communication at the customer side.

The central location to browse for predefined integration content is the Enterprise Services Workplace (ES Workplace). You can access the ES Workplace in SAPCommunity Network at https://www.sdn.sap.com/irj/sdn/explore-es.

The term enterprise service is used to emphasize the fact that the ES Repository contains services that were designed according to SAP’s SOA designprinciples. Technically, this term summarizes interface objects. In this document, we intend to name these objects in particular, that is, as service interface,message type, or data type. Integration content published on the ES Workplace was designed based on integration scenario models and process componentsinteraction models. In addition to this content, SAP also provides integration content that was designed based on “classic” process integration scenarios.

Procedure

Before customers can use and enhance predefined content, they have to download it from SAP Service Marketplace and import it into the ES Repository installedin their landscape. The corresponding location on SAP Service Marketplace is the SAP Software Distribution Center at http://service.sap.com/swdc Support Packages and Patches Browse our Download Catalog SAP Content ESR Content (XI Content).

Customer modifications of predefined integration content must not be executed in an imported SAP software component: They must be performed in a separatesoftware component instead.

This avoids conflicts with subsequent SAP software updates since changes to an SAP software component will be immediately overwritten when SAPsoftware updates are imported.

Therefore, to be able to use predefined integration content provided by SAP, you have to create an own software component version for your developments.The new software component version has to include the SAP software component (that contains the predefined content) as the underlying software componentversion. To do this, define a “based-on” relationship between the new software component and the SAP software component.

More information: Underlying Software Component Version

When you use process integration content for SAP applications, make sure that there is an unambiguous (1:1) relationship between the correspondingsoftware component version in the ES Repository and the corresponding software component version in the SAP system. This is the same for the support

Note

Note

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 18 of 130

package. This means, the versions of both, software component version and support package number, need to be kept in sync in ES Repository and theSAP system. They have to be installed and maintained synchronously.

More information: Managing Enterprise Services Delivered by SAP

Interface Objects

Interface objects provide all details on how one process component exchanges data with another, for example, the mode of communication and the data structures.

The following table summarizes the interface object types:

ObjectType

Description

Serviceinterface

Defines a set of functions that is either provided by an application or used by an application; contains one or multiple operations. Each operationrefers to one or more message types.

Messagetype

Defines the root element of a message and refers to a data type.

Data type Defines a data structure.

Externaldefinition

Externally-defined data structure that is imported into the ES Repository.

Importedobject

RFC or IDoc interface that is imported into the ES Repository.

Contextobject

Design object that can be used as an abbreviated expression for an XPath expression to address a specific payload element. Context objectsare used in routing conditions.

Interface objects can reference each other in a specific way. The possible object references are shown in the following figure.

Object References Between Interface Objects

More information: Interface Objects in the ES Repository

Service Interfaces, Operations and Message Types

As interface objects also encapsulate each other (as illustrated in the figure above), a top-down design approach is also feasible, starting with the definition of aservice interface.

A service interface represents a set of functions that is either provided by an application (inbound service interface) or used by an application (outbound serviceinterface). You can consider the set of functions a service interface represents as a subset of the functions implemented by a process component. However, aservice interface in the ES Repository contains merely the metadata of a service, abstracted from any implementation details.

Service interfaces are based on Web Services Description Language (WSDL), an XML-based language for describing Web services and how to access them.However, when you create interface objects in the ES Repository, you do not need to be familiar with the syntax of WSDL because you can use the relevant editorto specify the interface attributes.

The Category service interface attribute determines whether the service interface is an outbound or an inbound service interface.

Only for dual-stack installation option: The Abstract category is only intended for communication with an integration process (cross-component BPM).

A service interface groups one or multiple operations. An operation represents the smallest, separately-callable function, described by a set of data types usedas input or output. You can specify the Communication Mode for each operation. This attribute determines if the communication defined by the operation issynchronous or asynchronous. In a synchronous communication step, a response is expected for each call or request message that is sent out. In anasynchronous communication step, a request message is sent out but no response is expected.

You assign one or multiple message types for each operation – depending on the communication mode.

A message type defines the root element of a message. You use a message to exchange data between systems. A message type refers to exactly one data typethat defines the structure of this data.

For a synchronous operation, you assign three message types: A request, a response, and a fault message type. A fault message type represents the message

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 19 of 130

that is expected in case an error occurs. For an asynchronous operation, you only assign one request message type. The following figure shows the role thedifferent interface objects play for the message exchange. The example shows an asynchronous message exchange where a request message is sent from theservice consumer to the service provider.

Asynchronous Message Exchange Between a Service Consumer and a Service Provider

The following figure shows a synchronous message exchange including a request and a response message being defined for the service interface operation:

Synchronous Message Exchange Between a Service Consumer and a Service Provider

In a lot of scenarios, the application forces that a specific communication sequence and transactional behavior is maintained during message exchange. With theattribute Interface Pattern you can design this behavior in the ES Repository. An interface pattern describes the type of communication that is to be executed onthe message when the interface is used. It determines what kind of operations can be defined for a service interface. The interface pattern that you select has animpact on the activities related to the programming of the business logic in the related back-end system (task of application developer).

For mediated communication using an integration broker, the interface patterns that fit most use cases are Stateless or Stateless (XI 3.0-compatible) .

The interface pattern Stateless (XI 3.0-compatible) is used by default for all interfaces migrated from earlier releases of SAP NetWeaver PI(namely, SAP NetWeaver PI 7.0 and SAP NetWeaver XI 3.0) to SAP NetWeaver PI 7.1 (called message interfaces in earlier releases). Additionally, thisinterface pattern is recommended for scenarios that use the common “technical adapters” such as the File/FTP, JDBC, JMS adapter. However, using thispattern limits the service interface to use only one operation.

The default pattern for developing new service interfaces is Stateless .

The interface pattern Tentative Update & Confirm/Compensate (TU &C/C) has been developed to improve the transactional behavior whenusing synchronous messages. The TU &C/C pattern ensures that - in cases of system or communication failure - one of more synchronous update calls inone transactional context are executed and ensure a consistent dataset on both sides of the communication.

More information: Service Interface

Data Types

A data type determines the data structure for a specific business entity, for example, an address. Data types are referenced by message types and thereforedefine the structure of a message.

As defined in the ES Repository, data types are based on XML Schema (also referred to as XSD). Data types can reference other data types which enables youto build up complex data types out of simpler ones. The basis for all data types are XSD types contained in XML schema and approved by W3C, (for example,xsd:string , xsd:decimal , xsd:integer ). These data types define the properties of an element at a technical level.

More information: Data Types in the Enterprise Services Repository

External Definitions

If you would like to reuse existing XML definitions as message definitions described in either WSDL or XSD, you can import these XML definitions into the ESRepository, rather than re-enter them manually using the data type editor. You then encapsulate the imported definition in the form of an external definition.

Context Objects

With a context objects, you can specify an XPATH expression that can be used to access a field in an XML message.

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 20 of 130

These expressions can then be used at configuration time to configure content-based routing and in integration processes (ccBPM)

More information:

Context Objects

Routing

Imported Objects

If you would like to reuse XML definitions of existing functions - RFCs or IDocs - so that you can call these functions using the Integration Server, you can importIDocs and RFCs into the ES Repository and make the interface signature known there.

Mapping Objects

In a mediated communication step of an integration scenario, the sender normally uses a data format and structure for sending out a message that is different to theone that the receiver can handle. The data structure and format used by the sender therefore has to be transformed into the structure and format that the receivercan handle. This type of transformation is called mapping. You specify the corresponding transformation rules in the ES Repository – in the form of mappingobjects.

From the runtime engine's perspective, the incoming message (sent from a sender) has to be transformed into an outbound message that is sent to a specificreceiver.

The term mapping describes transformations on the level of the business data that is exchanged between process components. This can include specialformats for particular business entities, such as the format of a time field in a message. Transformations on the level of the technical transport protocol arehandled by adapters (configured at configuration time).

Since mappings are determined by business needs and describe data transformations on a business level, they can be defined at design time. Therefore, mosttasks related to mapping are performed in the ES Repository. At configuration time, in the Integration Directory, you merely have to select the right mapping for aspecific communication step (or interaction).

Mapping Programs

A mapping is implemented by a mapping program.

More information: Mapping Programs

Overview of Mapping Objects

The following object types are available in the ES Repository for designing mappings:

ObjectType

Description

Operationmapping

Assigns a mapping program for a pair of service interface operations.An operation mapping encapsulates the mapping program that has to be executed at runtime.

Messagemapping

Mapping object created when you use the graphical mapping editor. A message mapping has to be referred to by an operation mapping.

Importedarchive

Encapsulates an externally developed Java or XSLT (Java) mapping program. An imported archive has to be referred to by an operation mapping.

Mappingtemplate

Contains parts of a message mapping that can be used as a copy template to create new message mappings. Mapping templates can refer toother mapping templates, thus enabling maximum reuse in mapping development.

Valuemappinggroup

A value mapping transforms values of message elements.A value mapping group is a configuration object (Integration Directory) that contains mappings between different representations of one and thesame object. Mapping programs (developed at design time) can refer to a value mapping table; however, since the actual values in manyscenarios are not known at design time, the value mapping table content is maintained in the Integration Directory (see also Value Mappings).

The following figure shows the most important object references between mapping objects (also including the object references to interface objects):

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 21 of 130

Object References Between Mapping Objects

Mapping Programs

A mapping is implemented by a mapping program. You use a mapping program to define:

How structure nodes (or elements) in the source structure are assigned to structure nodes in the target structure

Usually, elements with the same semantic meaning are assigned to each other. This part of the mapping is usually referred to as structure mapping.

How the source element is transformed into a value target element

SAP NetWeaver Process Integration supports the use of different kinds of mapping programs:

Message mapping

With a message mapping, you map one message type to another by using a graphical editor in the ES Repository. A mapping program is generated from thegraphical design.

Java program and XSLT (Java) program

These mapping programs are developed in Java and XSLT (eXtensible Stylesheet Language Transformations) respectively, and imported into the ESRepository as an archive.

XSLT (eXtensible Stylesheet Language Transformations) is a language that enables you to convert an XML document to another document. You candevelop mappings with XSLT and import them to the ES Repository.

ABAP program and XSLT (ABAP) program

These mapping programs are developed using the ABAP Workbench. At runtime, these programs are executed on the ABAP Engine of the Application Serveron which the Integration Server is running.

These kinds of mapping programs cannot be imported into the ES Repository and therefore are not shipped by SAP. They have to be developed in theSAP system at the customer’s site.

For usability reasons, it makes sense to design message mappings because you can use the graphical editor.

Operation Mapping

You use an operation mapping to relate an outbound service interface operation with an inbound service interface operation. You can also relate IDoc and RFCinterfaces with entities of the same type or with service interface operations. This is illustrated in the following figure:

Note

Note

Recommendation

PUBLIC© 2012 SAP AG. All rights reserved.

Page 22 of 130

Assigning Service Interface Operations with an Operation Mapping

You define the assignment of the operations related to each other in an operation mapping, whereas in a mapping program you define the detailed transformationrules for the transformation of a source structure (representing the message sent by the outbound operation) into a target structure (representing the messagereceived by the inbound operation).

The number of mapping programs or transformation rules you need to define for an operation mapping depends on the communication mode:

Synchronous communication

A synchronous operation (see section Defining Interface Objects) refers to a request, a response, and in some cases a fault message. Therefore, in generalyou have to define a mapping program for both request and response messages. If fault messages are used, you have to define an additional mappingprogram for the fault message.

Asynchronous communication

You only need one mapping program.

An operation mapping encapsulates the used mapping program (either defined graphically by a message mapping or contained in an imported archive).

Message Mappings (Overview)

In a message mapping, you assign a source and a target message type (according to the source and target operation of the operation mapping the messagemapping is assigned to). Using a graphical editor, you can define the mapping between the source and target message type.

Java source code is generated from the message mapping and compiled in a .jar file. At runtime, the .jar file is executed.

The graphical mapping editor is composed of three main areas (see Message Mappings (Detailed Information)). The left area shows the structure of thesource message assigned to the message mapping, the right area the structure of the target message. Below this is the data flow editor.

If you have created the message mapping based on an operation mapping, the source and target structures are already loaded according to the operationsyou have chosen in the operation mapping.

You use the graphical editor to do the following:

Design a structure mapping between the elements of the source and the target structure

Apply a function to transform the source and target fields into each other, if necessary

A simple assignment between source and target fields is generally not sufficient.

In the data flow editor, you define target field mappings. A target field mapping describes how one or more source fields are mapped to a target field.

A message mapping is constructed from individual target field mappings.

The following kinds of function can be used to specify target field mappings:

Standard functions

These functions are already available in the mapping editor. There are several kinds of standard function available in the mapping editor. For text mappings, forexample, these include simple calculations or Boolean operations, and date format conversions.

More information:

User-defined functions

You can define your own functions if standard functions do not fulfill your requirements.

More information: User-Defined Functions and Function Libraries

More information:

Data-Flow Editor

Note

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 23 of 130

Target Field Mappings

User-Defined Functions and Function Libraries

You can create your own user-defined function in Java source code. A user-defined function created in a message mapping or mapping template is stored in alocal function library belonging to the corresponding mapping object. To use a user-defined function in more than one message mapping or mapping template, youhave the option to create the user-defined functions in function libraries in the ES Repository.

A function library is created and maintained as a separate design object in the ES Repository.

A message mapping can only use function libraries that are defined in the same software component version as the message mapping, or in an underlyingversion.

More information:

User-Defined Functions

Function Libraries

Describing the System Landscape in the SLD

The SAP System Landscape Directory (SLD) is the central information provider in a system landscape.

The SLD contains two types of information relevant for SAP NetWeaver Process Integration:

Component information: Information about all available SAP products and components, including their versions. If there are any third-party products in thesystem landscape, they are also registered here

At design time of the integration objects, the component information is extracted from the SLD to define process integration scenarios.

For more information, see: Enterprise Services Repository

Landscape description: This contains all installed systems in a system landscape.

At configuration time, the landscape descriptions are needed to determine the system information of the business partners involved. It consists of businesssystems.

Business systems are logical systems that communicate with each other by sending and receiving messages. They can be SAP or third-party systems.

An SAP system has one or more clients that function independently of each other as logical units at runtime. Each of these clients represents a businesssystem in Process Integration.

A third-party system is also a logical unit that functions as a sender or receiver. Therefore, third-party systems are also business systems in this sense.

Business systems are based on technical systems. More information: Separation of Business Systems and Technical Systems

If you have more than one SLD instance, you must ensure that all content is synchronized. The SLD has export and import functions for this purpose.

For more information, see:

Planning Guide – System Landscape Directory

This guide is published in SAP Community Network at http://sdn.sap.com/irj/sdn/nw-sld . The Planning Guide contains recommendations on howto set up landscapes including the SLD and SAP NetWeaver Process Integration.

System Landscape Directory

Procedure

Configure Business Systems in the SLD

First, define and configure all business systems involved in the process in the SLD.

For more information, see: Configuring Business Systems in the SLD

Only once you have done so can you define the business systems as communication components in the Integration Directory and address them as the sendersand receivers of messages in later configuration steps.

You create communication components of type Business System for those systems that you are familiar with.

Note

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 24 of 130

Configure Groups and Transport Targets in the SLD

An Integration Server enables communication between business systems at runtime. It cannot execute business logic.

You can assign a group of business systems to an Integration Server. A business system group is a logical grouping of business systems that use an IntegrationServer to communicate with each other.

For more information, see: Configure Groups and Transport Targets in the SLD

Tasks for Changes in SLD

After you have made any changes in the SLD, always ensure that you clear the cache for SLD data in the Integration Directory. Only once you have done so canyou access up-to-date SLD content (for example, by using input help).

For more information, see: Delete SLD Data Cache

Example of Changes in the SLD

Change in the SLD Effect in Integration Directory

Create/delete a businesssystem

The input help for business systems (for example, when you define a business system component) is only updated once youclear the SLD cache.

Delete an Adapter Engine The input help for Adapter Engines in the communication channel is only updated once you clear the SLD cache.

In the following cases, ensuring that a change made in the SLD has also taken effect in the Integration Directory requires manual effort.

Changes in SLD and Additional Activities in the Integration Directory

Change in the SLD Effect in Integration Directory

Change a business system (registered as an SAP or non-SAP)systemFor more information, see: Technical System Landscape

For this change to take effect in the relevant business system service, you mustcompare the data with the SLD.For more information, see: Business System (Communication Component)

Change a business system (adapter-specific identifiers, forexample, the logical system)

For this change to take effect in the relevant business system service, you mustcompare the data with the SLD.For more information, see: Communication component

Separation of Business Systems and Technical Systems

Business systems represent “logical” systems, whereas technical system descriptions contain information about the technical details of a system. This isinformation such as the server address. When the message flow – that is, the routing – in a system landscape is defined (in the receiver determination), this isdone based on business systems, that is, at the level of the “logical” systems. This separation of the routing definition from the technical details has the advantagethat the configuration is independent from any changes to the technical details of the system landscape. If, for example, a server address is changed, this has noimpact on the routing configuration.

Nevertheless, at runtime a message needs to be forwarded to a “real” (physically) installed system. That means that the server address has to be known atruntime. Therefore, in addition to the “logical” receiver determination (as mentioned above), a “technical” receiver determination is performed at runtime. Thistechnical receiver determination is accomplished by a mapping of the business system to the underlying technical system. This dependency is already definedin the SLD since you always have to assign a technical system when creating a business system.

As an example, this mapping of a business system and technical system shows up in the configuration data in the Integration Directory in the attributes ofreceiver communication channels that usually contain the server name of the receiving system. The server name is part of the technical system descriptionthat is maintained in the SLD. On the other hand, the communication channel is assigned to a (receiver) communication component which is mapped directlyto a business system from the SLD.

Collaboration Profile

In a collaboration profile you can do the following:

Model the units that you want to address as the sender or receiver of a message

Define the available communication channels for the inbound and outbound processing of the messages

Addressing Senders and Receivers

You have the following options for addressing the sender or receiver of a message:

Communication party (party for short)

Example

PUBLIC© 2012 SAP AG. All rights reserved.

Page 25 of 130

Communication component (component for short)

The message protocol supports the addressing of senders and receivers on two levels: The first level corresponds to a company unit, the second to a technical orsemantic unit within a company unit or company. You represent the first addressing level with the Communication Party object, and the second by theCommunication Component object.

Depending on the scenario, you can define the sender and receiver of a message very flexibly with these objects. The options are listed in the following table.

Types of Addressing and Typical Usages

Addressing Typical Usages

Party with assignedcommunication components

You use this type of addressing when configuring collaborative processes in which whole companies communicate witheach other.You then use a communication party to represent each company. A communication component represents a business ortechnical entity within a company.In business-to-business processes (or cross-company processes) the companies involved usually provide a variety ofcommunication components for communicating with other companies.

Communication componentsindependent of a party

You use this type of addressing when configuring processes in which the system landscape is known to you. This isusually the case in application-to-application processes.The definition of communication parties is not mandatory. This enables you instead to specify the known communicationcomponents directly as either the sender or receiver of a message.

Note that it may sometimes be necessary to use communication parties when configuring internal company processes, for example in the case of IDoccommunication. If the IDoc partner is not of type logical system, you must map the IDoc partner to a communication party in the Integration Directory.

Communication Components

You define the systems involved in the process as communication components in the Integration Directory.

Create communication components of type Business System for those systems that you are familiar with (using the integration expert role). These are based onbusiness systems that are described in the System Landscape Directory.

The system landscape description in the SLD is based on the following entity types:

Business systems

Are defined for all systems that communicate with each other. Business systems are logical systems that play the role as senders or receivers ofmessages. Business systems can be SAP systems or third-party systems. Each business system has to be assigned to a technical system.

Technical systems

Are defined for all systems that are actually installed in your system landscape.

You can enter communication components of type Business Component (as representatives of the external system) for external systems of a business partner(business-to-business scenarios) that are not specified in greater detail. In addition to this, in business-to-business scenarios you can map the business partnersand partner companies as communication parties.

If an executable integration process is used, this is also addressed as a communication component.

Communication Channels and Adapter Configuration

You define the available technical communication options of a component in Communication Channels.

A sender communication channel contains the information that determines the inbound processing of a message that is sent by a sender component to the runtimeengine.

A receiver communication channel contains the related information for the outbound processing of a message that is sent by the runtime engine to a receivercomponent.

You can access the adapter configuration directly from the communication channel.

These technical communication capabilities are also called Connectivity and are realized in the various different Adapters.

More Information

Communication Party

Communication Component (for dual-stack installation option)

Communication Component (for Advanced Adapter Engine Extended)

Communication Channels

Separation of Business Systems and Technical Systems

Note

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 26 of 130

Content-Based Routing

In many business cases, it is necessary to define conditions with which the receivers of a message are determined during routing. For example, consider acondition in the following form: “If the value of a specific field in the message is x, then forward the message to receiver y.”

At configuration time, you can define conditions that depend on the content of the message. You can do this for both the determination of receiver communicationcomponents and inbound interfaces.

The following figure shows a simple example of content-based routing:

Basic Example for Content-Based Routing

The figure illustrates the following business case: Flight booking systems for different airlines are hosted on different systems. To ensure that the request for a flightavailability check is forwarded to the correct airline, the routing condition is formulated as airline-dependent. The airline ID (field AirlineID ) is contained in thepayload of the message. The routing condition is as follows: Send the message requesting the flight availability check to the airline Lufthansa if the fieldAirlineID in the message payload has the value LH (Lufthansa). If this field has the value AA (American Airlines), then forward the message to the airlineAmerican Airlines.

A routing condition generally has the following syntax:

<element in the message> <Operand> <value>

The element in the message is identified by an XML Path Language (XPath) expression. XPath is a language that allows you to address parts of XMLdocuments.

When you define a routing condition, you can use a condition editor. Using the condition editor, you do not need to worry about XPath syntax since you canconveniently identify a message element by clicking through the message structure displayed in the editor. Additionally, you can combine multiple conditions withlogical AND and OR operators.

B2B Configuration

Many integration scenarios are configured based on the assumption that the integration only involves business applications that span parts of one and the samecompany. In such cases, the system landscape typically is described in one System Landscape Directory. Typically, in such a situation the complete systemlandscape is known to the integration expert who performs the configuration tasks. The integration expert then typically puts a communication component on thesame level as a business system.

As soon as different companies share the same business process (in other words, in a B2B scenario), additional considerations come into play. Typically, in aB2B scenario, the configuration of the integration is a task that is distributed among integration experts from the involved companies or organizations. Eachintegration expert will only configure one “side” of the communication, and, in doing so, each expert knows only “his” part of the system landscape.

The next figure illustrates this fact schematically. It illustrates communication with an external business partner (business partner 2); in this case, the integrationexpert at business partner 1 does not know any details of the part of the system landscape hosted by business partner 2:

PUBLIC© 2012 SAP AG. All rights reserved.

Page 27 of 130

B2B Configuration

The integration expert at business partner 1 only knows the part of the system landscape that is hosted by business partner 1. The complementary part of thesystem landscape hosted by business partner 2 is typically not known to him or her, since companies and organizations do not usually expose internal systemnames or server addresses to external partners. This part of the system landscape is a “black box” to him.

For an integration expert working for business partner 2, the reverse is true (assuming for simplicity that only two business partners share the business process).

There are additional configuration concepts to handle these B2B-specific constraints (implemented as object types or object attributes in the Integration Directory).

Communication Party

Since B2B scenarios typically involve whole enterprises interacting with each other, you use a communication party to identify a company or an organization thattakes part in the business process. The communication party is an optional key field for receiver determinations, interface determinations, sender and receiveragreements. A party groups together those communication components that belong to the corresponding company or organization.

To accommodate the fact that B2B integration spans areas of responsibility that are separated from each other (as illustrated in the figure above), an additionalconcept is implemented: where you use an internal name to identify a company or a business partner during configuration, you have the option to map this internalname to a unique globally-recognized identifier that identifies the company unambiguously (for example, a D & B D-U-N-S number issued by the agency Dun &Bradstreet). In every communication with an external partner, the internal party name is then transformed to the globally-recognized identifier. Conversely, when amessage is received from an external business partner, the identifier can first be mapped to the internal party name during inbound processing.

Business Component

In external communications (B2B interactions), business system names cannot be used as addressing entities since they are not exposed externally. Therefore,communication components based on business systems in the SLD are not suitable. Instead, messages involved in a B2B interaction use a differentcommunication component type, called a business component. A business component merely represents an abstract entity for addressing the senders andreceivers of messages in B2B communications.

Masking Internal Details in Outbound Messages (Header Mapping)

A message sent out to a receiver system in a company-internal interaction carries the information of the sender (the name of the sender system) in the messageheader. In an external or B2B communication, the internal system names should be hidden and not show up in the message header when the message arrives atthe external business partner. To make sure that internal system names are masked in message headers, a header mapping can be applied. With a headermapping, you define a transformation from the internal (sender) system name to an externally exposed business component name. You configure the headermapping when you specify the outbound processing.

The following figure illustrates how header mapping works:

PUBLIC© 2012 SAP AG. All rights reserved.

Page 28 of 130

Masking Internal System Names in an Outbound Message Using Header Mapping

You have the following options to configure header mapping:

Dual-Stack installation: in a receiver agreement or in an integrated configuration object (Outbound Processing tab)

Advanced Adapter Engine Extended: in an integrated configuration object (Outbound Processing tab)

Routing Messages from an External Business Partner to an Internal System

If we consider the other direction of B2B message exchange, a message sent by an external business partner (2) cannot be addressed directly to a system of theinternal landscape hosted by business partner 1. Instead, the external business partner addresses the message to a virtual receiver by using a businesscomponent name to address the receiver of the message. This business component name is the name you (business partner 1) have communicated to theexternal business partner beforehand. To route the message from the external business partner to the right system in your (business partner 1) internal landscape(whose name the external business partner does not know), you use a receiver-dependent receiver determination.

A receiver-dependent receiver determination is illustrated in the following figure:

Receiver-Dependent Receiver Determination

The figure illustrates how a receiver-dependent receiver determination routes a message sent by the external business partner to the (externally exposed)business component BookService , to the internal system ABC .

You have the following options to configure a receiver-dependent receiver determination:

Dual-Stack installation: in a receiver determination or in an integrated configuration object

Advanced Adapter Engine Extended: in an integrated configuration object

More Information

Communication Party

Identifiers

Business Component (for dual-stack installation)

Business Component (for Advanced Adapter Engine Extended)

Development and Configuration Tasks (Dual-Stack)

PUBLIC© 2012 SAP AG. All rights reserved.

Page 29 of 130

This section describes the end-to-end procedure for setting up and running a scenario based on SAP NetWeaver PI, dual-stack installation option.

There are different installation options of SAP NetWeaver PI, each of them implying a slightly different approach.

More information: Installation Options

Procedure

According to the chosen use case, select either of the following sections:

Setting up Scenarios Using Dual-Stack Message Processing

Choose this section if you use the dual-stack installation option and like to process messages using both runtime engines, the Integration Engine and theAdvanced Adapter Engine (AAE).

Setting up Scenarios Using Local AAE-Based Message Processing

Choose this section if you use the dual-stack installation option and like to process messages using the AAE only (bypassing the Integration Engine).

The sections referred to above cover the basic end-to-end procedures. For more information on how to set up specific use cases like, for example, scenariosincluding cross-component Business Process Management, how to develop mappings, and B2B scenarios, see the corresponding section under AdvancedDevelopment Tasks (Dual-Stack).

The general procedure is structured according to the phases design time, configuration time and runtime.

More information: Phases of an Integration Project

Concepts

This part of the documentation introduces concepts and capabilities in particular relevant for the dual-stack installation option of SAP NetWeaver PI.

Section Content

SAP NetWeaver PI Dual-Stack Installation Provides an overview of the components and the architecture of a dual-stack SAP NetWeaver PI installation.

Cross-Component Business ProcessManagement

Provides a short introduction to the Cross-Component Business Process Management capability of a dual-stack PI installation.

Web Services Reliable Messaging Provides a short introduction to the Web Services Reliable Messaging capability of a dual-stack PIinstallation.

Process Models Provides an overview of the integration-specific model types available in the Enterprise Services Repositoryfor a dual-stack installation.

Configuration Objects (Dual-StackCommunication)

Provides an overview of the configuration objects relevant to set up dual-stack message processing.

Configuration Objects (DirectCommunication)

Provides an overview of the configuration objects relevant to set up direct communication.

Model-based Configuration Provides an overview of the model-based configuration option.

Message Processing at Runtime Provides a detailed description of how a message is processed by the involved runtime engines.

For concept information relevant for both, the dual-Stack and the Advanced Adapter Engine Extended installation option, see Concepts.

SAP NetWeaver PI Dual-Stack Installation

This section provides an overview of the different options for processing messages at runtime with an SAP NetWeaver PI dual-stack installation.

Connectivity Options

Note

Note

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 30 of 130

The following figure shows an overview of the connectivity options of a dual-stack SAP NetWeaver PI installation. Read the following sub sections for more details.

Connectivity Options of SAP NetWeaver PI (Dual-Stack) — Overview

Dual-Stack Message Processing

Using this connectivity option, both the Integration Engine (IE) and the Advanced Adapter Engine (AAE) are involved for message processing at runtime. In caseyou have configured integration processes, also the Business Process Engine is involved.

Adapters run either on the Integration Engine or the AAE. The following adapters run the Integration Engine: IDoc (IE), XI, HTTP (IE), WS (connectivity to systemsbased on Web Services Reliable Messaging). All other adapters run on the AAE. In which way the IE and AAE are used in particular, depends on the configuredadapters for inbound processing (connectivity to a sender system) and outbound processing (connectivity to a receiver system).

For example, in case a JDBC (sender) adapter is used for inbound processing, the AAE is involved in the communication to provide the required connectivityto the sender system.

The following figure illustrates this situation for the case where the AAE is connected upstream to the Integration Engine (providing the required connectivity atsender side):

Integration Engine-Based Communication Including the AAE at Sender Side

Local Message Processing Using the AAE

You can also process messages “locally” on the AAE without involving the IE. This option ensures a considerably higher performance. However, there are somerestrictions regarding the mediation capabilities compared to scenarios with full involvement of the Integration Server. For example, the “WS adapter” cannot beused. The following figure illustrates local message processing on the AAE:

Example

PUBLIC© 2012 SAP AG. All rights reserved.

Page 31 of 130

Local Message Processing on the AAE, Bypassing the Integration Engine

In the figure it is also illustrated that besides the fact that the IE is “bypassed” at runtime, the design and configuration time tools are still needed to set up thecommunication.

If at runtime dual-stack or local (AAE-only) message processing mode is used, depends on which configuration objects you have specified in Integration Directory.

In general, the following applies:

If you use sender agreements, receiver determinations, interface determinations and receiver agreements as configuration objects, messages are processed inthe dual-stack mode.

If you use an integrated configuration as configuration object, messages are processed in the AAE-only processing mode.

Which adapters are involved for inbound and outbound processing in particular, depends on the assigned communication channels.

Message Processing Using the Non-Central AAE

In addition to using the AAE as part of the Integration Server (the central Adapter Engine), there's also the option to use the AAE stand-alone, next to the IntegrationServer (non-central AAE). That means, the AAE can be installed on a system with a different SAP system ID (SID) than the Integration Server and be used as anindependent integration hub. However, note that you need an ES Repository and an Integration Directory as design and configuration tools in order to set up thescenarios.

The following figure shows the basic communication flow at runtime:

Message Processing Using the Non-Central AAE

As an additional option, you can use the Adapter Engine (Java SE). This option is only supported for compatibility reasons. It hosts only a subset of theadapter functionality and has fewer security and monitoring features.

More Information

Architecture (PI Dual-Stack) (for a detailed view of the components of a dual-stack SAP NetWeaver PI instance)

Configuration Time

Runtime

Message Processing at Runtime (for information on how message processing is performed in detail)

Architecture (SAP NetWeaver PI Dual-Stack)

The following figure shows the main components of an SAP NetWeaver PI dual-stack installation.

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 32 of 130

The main components for design and configuration time are the Enterprise Services Repository (ES Repository) and the Integration Directory. Using these tools, anintegration expert designs integration content (for example, interfaces and process integration scenarios) and specifies the configuration settings for messageexchange for a specific system landscape. The design and configuration tools are connected to the System Landscape Directory which contains, for example, thedescription of software components and systems. The ES Repository and the Integration Directory are technically based on AS Java.

The Integration Directory is connected to the ES Repository to allow access to specific design time objects (for example, mappings) also at configuration time.

More information:

Design Time

Configuration Time

When you install SAP NetWeaver PI (dual-stack installation option), you set up an “Integration Server”. The Integration Server hosts the following runtime engines:

Integration Engine (based on AS ABAP)

Business Process Engine (based on AS ABAP)

More information: Cross-Component Business Process Management

Advanced Adapter Engine (based on AS Java)

All SAP systems based on Application Server ABAP release 6.20 or higher contain a “local” Integration Engine, also when used as an application system.This local Integration Engine enables the system — when used as an application system — to connect to another system via an SAP NetWeaver PI runtimeengine. This kind of connectivity is also referred to as connectivity based on the proxy runtime. All other systems – either SAP or third-party – connect to theSAP NetWeaver PI runtime using adapters.

More information: Connectivity

To process messages, the involved runtime engines use information from the Integration Directory. This information is made available to the runtime engines usingruntime caches.

More information: Runtime Caches

More Information

Runtime

Cross-Component Business Process Management

Cross-component Business Process Management (ccBPM) contains functions for enhanced service orchestration that are based on integration processes. Anintegration process is composed of a specific flow of steps – including the sending and receiving of messages – during which the status of the process ispersisted on the Integration Server. In an integration process, you can define a specific level of process control. For example, you can specify how long anintegration process must wait for further messages to arrive, or you can group incoming messages and then send them in a particular order. You can also definecontrol structures, such as loops and process in branches that are independent of each other.

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 33 of 130

Using an Integration Process for a Message Split

Web Services Reliable Messaging

The Web Services Reliable Messaging (WSRM) specification issued by OASIS in 2005 describes a protocol that allows messages to be transferred reliablybetween nodes implementing this protocol in the presence of software component, system, or network failures.

A WSRM-enabled system guarantees a certain transactional behavior that ensures that a consistent data state is achieved after the interaction, even in the eventof failures as mentioned above.

You can find more information under the following internet address: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrm .

SAP NetWeaver Process Integration supports WSRM with the following enhancements:

Connectivity

It is possible to connect WSRM-enabled systems to the Integration Server and to configure certain security settings.

In addition to this, you can also configure the direct (point-to-point) connection between WSRM-enabled systems.

You can configure a communication channel with adapter type WS for this purpose in the Integration Directory.

Interface design

In the ES Repository, you can define certain interface patterns for service interfaces that help to implement WSRM-enabled applications. These are theinterface patterns Stateless and TU & C/C (Tentative Update and Compensate or Confirm).

For example, a TU & C/C scenario might be designed as follows: A service consumer sends his orders to a service provider. The provider processes theorders tentatively. Only after an order is confirmed on the consumer side is the order also persisted in the database on the provider side. In the event of anerror, the changes are rolled back. To implement such behavior, multiple operations have to be designed for the service interface and implemented later inthe related application systems

Process Models

The ES Repository supports process modeling with a variety of different model types. These are the model types that are most important for outlining theintegration-relevant aspects of collaborative processes:

Example

PUBLIC© 2012 SAP AG. All rights reserved.

Page 34 of 130

Model Type Description

Integration scenariomodel

This model type provides a high-level view on the integration.More information: Integration Scenario Model

Process componentsinteraction model

This model type allows you to specify the interaction between two process components in detail. Based on this model type, you canstart specifying interface objects, mappings and channel templates.More information: Process Components Interaction Model

Process integrationscenario

“Classic” process integration scenarios provide an alternative modeling approach. For each process integration scenario you candefine different Component Views for to outline different variants.

Note that only this model type is supported when setting up scenarios using the Advanced Adapter Engine Extended.You also need to use this model type when designing scenarios using cross-component Business Process Management.

More information: Process Integration Scenarios

Integration scenario models and process components interaction models on the one hand and process integration scenarios on the other hand represent twodifferent modeling approaches. From a tool perspective, these two modeling approaches are not integrated with each other. Therefore, you need to decide forone approach at the beginning of each integration project.

Configuration Objects (Dual-Stack Communication)

In this section you get a summary of the configuration tasks and objects required for dual-stack communication.

For an overview of the available communication and message processing options, we refer to the following sections:

Installation Options

Runtime

The figure below shows the phases of message processing for an incoming message. The configuration objects relevant in order to specify the different messageprocessing phases are also indicated in the figure.

Phases of Message Processing and Relevant Configuration Objects

For sakes of simplicity, communication parties (see below) are not considered in the figure.

The objects required to execute the current configuration tasks are listed in the following table.

Note

Note

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 35 of 130

Tasks and Relevant Objects

Tasks Relevant Objects

Defining a collaboration profileIn the collaboration profile you specify which components communicate with each other and what their technical communicationcapabilities are.

Communicationparty (party for short)CommunicationcomponentCommunicationchannel

Configuring inbound processingHere you enter for a specific sender/receiver pair which sender adapter (or channel) is to be used for the inbound processing of amessage. In addition, you can specify security settings.

Sender agreement

Defining routingIn routing specify which receiver messages are to be sent to.In a receiver determination you specify the receiver components (for example, business systems) for a message. You can configurethe forwarding of a message to the receiver depending on the application data in the message.In an interface determination you specify to which inbound interfaces of a receiver a message is to be forwarded. If necessary, youcan also specify here which mapping is to be executed.

ReceiverdeterminationInterfacedeterminationReceiver rule

Configuring outbound processingHere you enter for a specific sender/receiver pair which receiver adapter (or channel) is to be used for the outbound processing of amessage. In addition, you can specify security settings.

Receiver agreement

Configuration Objects (Direct Communication)

in this section you find a summary of the configuration objects that are required when you want to configure direct communication between a Web serviceconsumer and a web service provider without any runtime engine interconnected.

The objects required to execute the current configuration tasks are listed in the following table.

Tasks and Relevant Objects

Tasks Relevant Objects

Defining a collaboration profileIn the collaboration profile you specify which components communicate with each other and what their technicalcommunication capabilities are.

Communication party (partyfor short)Communication componentCommunication channel

Defining a direct connectionWith a direct connection you configure the direct communication between the sender (Web service consumer) and thereceiver (Web service provider).You assign the receiver channel of the receiver system to the direct connection.

This option is only provided for channels with adapter type WS.

Direct connection

When you activate the configuration objects, the configuration settings made in the Integration Directory are transported to the back-end system on which the Webservice consumer or Web service provider are installed.

Note that complete configuration of scenarios of this type is only supported at this time in the Integration Directory for back-end systems that are based on ASABAP 7.10.

Model-based Configuration

Using a process model from the ES Repository as configuration template is the best way to use synergies between design and configuration time activities. Thisallows a semi-automatic configuration which considerably reduces configuration time, costs, and effort. In this section we show how this works.

At design time (in a process model), you specify relations between application components. In a process integration scenario in particular you specify whichinterfaces, mappings, and possible communication channel templates determine the interaction between two application components in detail.

At configuration time, you map the interaction of application components to system-to-system-interactions. In the preceding sections, we explained how you do thismanually: You manually defined the routing and the other processing details for each incoming message.

However, assume that at configuration time you use a process integration scenario as configuration template and first assign the involved application components

Caution

Caution

PUBLIC© 2012 SAP AG. All rights reserved.

Page 36 of 130

to communication components (systems). Then you have all the information you need to derive all sender system/receiver system relations that are relevant for theinteraction between the application components. In other words, you know the object keys of all the relevant receiver determinations, interface determinations, andsender and receiver agreements as explained under Object Key in Configuration Objects.

In case, you configure message processing using the Advanced Adapter Engine only, you correspondingly get the object key of the relevant integratedconfiguration.

At this point, the model configurator comes into play: Based on assignments between application components and communication components (systems) for aspecific model, the relevant receiver determinations, interface determinations, and sender and receiver agreements (or the relevant integrated configuration) arecalculated and automatically generated. This means that the tool calculates the object key, and checks if there already is a configuration object with this exactkey. Depending on the result, it either creates the object or re-uses an existing one. All generated configuration objects are then grouped in a configurationscenario which is a grouping entity in the Integration Directory.

The following figure highlights how the design and configuration time entities are related to each other, how the model configurator comes into play, and how areceiver determination is generated out of the setting (as an example):

How the Model Configurator Evaluates a Receiver Determination for the Given Example

Using the model configurator saves you the trouble of manually creating all configuration objects. If you configure the integration for large system landscapes, it canquickly turn into a nightmare to manually find out all relevant configuration object keys.

After generating the objects, the configuration objects generated have to be further specified manually by adding those parts that cannot be automaticallydetermined, for example, routing conditions or specific security settings in sender and receiver agreements.

You can use the model configurator with the following model types as input:

Process components interaction model (or integration scenario as group of multiple process components interaction models)

Process integration scenario

Message Processing at Runtime

The business process is executed in the system landscape at runtime, which means that the process is executed and messages are exchanged between thesystems involved. In mediated scenarios, messages are processed by a central instance — or: runtime engine — that interconnects the systems.

As described under Installation Options, a dual-stack SAP NetWeaver PI instance provides the following runtime engines:

Integration Engine (IE)

Applications using the proxy runtime or Web services runtime send messages to the IE. Further-on, the IE enables connectivity to systems sending IDocs andvia the native HTTP interface (via the HTTP adapter).

The IE is based on SAP Application Server ABAP (AS ABAP).

Advanced Adapter Engine (AAE)

Enables connectivity to external systems via a variety of adapters.

The AAE is based in SAP Application Server Java (AS Java).

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 37 of 130

For sakes of simplicity, we do ignore the Business Process Engine (which also runs on AS ABAP) within this section as this runtime engine comes only intoplay in scenarios that use integration processes (cross-component Business Process Management).

The Advanced Adapter Engine Extended (AEX: Java-only installation option) provides only the Advanced Adapter Engine as runtime engine.

This section provides detailed information on how a message is processed by the involved runtime engines.

With a dual-stack installation of SAP NetWeaver PI, messages can be processed in different ways. On the one hand, both runtime engines can be involved.Correspondingly, in that case we talk about “dual-stack message processing”. In contrast to that, you can also configure scenarios that way that only one runtimeengine (either the AAE or the IE) is involved.

The following figure shows how the involved systems and runtime engines communicate with each other for a dual-stack message processing scenario (at left)and a single-stack message processing scenario (at right).

The figure shows two different message processing options in case the dual-stack installation option of SAP NetWeaver PI is used.

Dual-Stack (Left) and AAE-only (Right) Message Processing

For the dual-stack processing scenario, only the case is shown where the AAE is connected upstream to the Integration Engine (providing the requiredconnectivity at sender side). As single-stack message processing option, only the case is shown where the AAE is involved as runtime engine. In the following,additional possible cases are shown.

The following figure shows in more detail all possible ways a messages can pass through the runtime engines.

To make the process flow of each individual option more transparent, the individual cases are shown in separate figures in the subsequent sections.

Note

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 38 of 130

Overview of Message Processing Options

The kind of message processing that applies at runtime depends on the configuration settings in Integration Directory that match the incoming message.Configuration settings in Integration Directory are structured as configuration objects. In general, those configuration objects apply for processing of a specificmessage that have an object key that matches the address header of the message.

For more information on these concepts, see:Configuration Time.

The conditions that determine which message processing option applies at runtime, are indicated in the figure above as comments besides the correspondingbranch of the process flow. These conditions are explained in detail below.

Note that branches (where a decision is taken) are indicated as white rhombuses, whereas joints (where two message processing paths are merged) areindicated as grey rhombuses.

The inbound message contains information about the sender of the message and the service interface that specifies the message data structure. As soon asinbound message processing is started (by the sender adapter), the message header is evaluated.

There are the following cases:

A system sends a message to the IE.

In specific cases (for example, when an SAP system is connected to an SAP NetWeaver PI instance via the proxy runtime) a message is sent to the IE. In theruntime cache that sender agreement is searched for and evaluated that has an object key that matches the header of the incoming message.

Further message processing is specified by a set of Integration Directory configuration objects of the following type: receiver determination, interfacedetermination and receiver agreement.

After the pipeline processing steps like routing and mapping (that are specified by receiver and interface determinations), the matching receiver agreement isevaluated in order to execute outbound processing. Here, the following cases can occur:

An IE adapter (which means: an adapter that runs on the IE) is assigned to the receiver agreement.

In that case, outbound processing is continued on the IE and the message sent to the receiver system by the IE.

An AAE adapter is assigned to the receiver agreement.

In that case, the message is handed over to the AAE, where further outbound processing is executed.

A system sends a message to the AAE.

As an example, the sender system is connected to the SAP NetWeaver PI instance via the SOAP adapter.

In that case, the following situations can occur:

For the incoming message (and the applied sender adapter) a sender agreement is found in the runtime cache.

In that case, after inbound processing the message is forwarded to the IE where the further processing steps are performed.

This is one case of dual-stack message processing.

If during that processing sequence a receiver agreement applies with an AAE adapter assigned, the message is again handed over from the IE to theAAE and sent from there to the receiver system.

For the incoming message (and the applied sender adapter) an integrated configuration is found in the runtime cache.

Note

Example

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 39 of 130

Message processing is continued on the AAE.

This is the case of AAE-only message processing. Using the AEX installation option, only this path is possible.

Single-Stack Message Processing Options (Detail)

We explain in more detail the case when only the AAE is used at runtime. The following figure illustrates this case.

AAE-Only Message Processing

A message with a header that matches an integrated configuration passes through the following steps:

01. Sender adapter processing

02. Advanced Adapter Engine pipeline processing

03. Receiver adapter processing

For more information on the steps in detail, in particular on the steps within the messaging system, see Message Processing (Advanced Adapter Engine).

For sake of completeness, the following figure illustrates the case where only the IE is involved at runtime. This case applies when a sender agreement is foundfor the inbound message and an IE adapter is used for both inbound and outbound processing.

IE-Only Message Processing

Dual-Stack Message Processing (Detail)

The following figures illustrate the possible cases of dual-stack message processing.

We discuss in detail the first example.

Dual-Stack Message Processing (AAE Sender Adapter, IE Receiver Adapter)

According to the figure above, a messages passes through the following steps:

01. Sender adapter processing

Based on the configuration of the sender adapter, the message is transformed technically to the XML message format the PI runtime can process (“XImessage format”). In case also additional security-related configuration settings apply, the message is handled accordingly.

Because a sender agreement applies, the message is handed over to the IE, and further processing is executed there.

02. Integration Engine pipeline processing

Processing of the message in the IE pipeline contains the following steps:

01. Inbound XML validation

Based on the configuration settings, the inbound message is checked with regard to validity of its XML schema.

02. Receiver determination

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 40 of 130

Based on the receiver determination that is found for the message, the receivers of the message and the routing conditions are evaluated. The receiver iswritten into the message header. In case multiple receivers are configured, for each receiver, a separate message is created.

03. Mapping

Based on the interface determination that is found for the message, the assigned mapping program is performed and the content of the messagetransformed accordingly.

04. Interface determination

Based on the interface determination that is found for the message, the assigned inbound interface (at the receiver side) is evaluated.

More sophisticated scenarios can be configured where a message is sent to multiple inbound interfaces or where a large message is split into several“message chunks” which are then sent to different inbound interfaces. For sakes of simplicity we do not consider these cases here and instead of thatrefer to the corresponding section: Defining Message Splits.

05. Outbound XML validation

Based on the configuration settings, the outbound message (to be sent to the receiver) is checked with regard to validity of its XML schema.

03. Receiver adapter processing

In the example illustrated in the figure above, a receiver adapter is assigned for outbound processing that runs on the IE. Therefore, the message processing iscontinued on the IE. Based on the configuration of the receiver adapter (that is assigned to the receiver agreement), the message is transformed technicallyfrom the “XI message format” to the format the receiver can process. In case also additional security-related configuration settings apply, the message ishandled accordingly.

For the sake of completeness, the following figures illustrate the additional cases.

Dual-Stack Message Processing (IE Sender Adapter, AAE Receiver Adapter)

Dual-Stack Message Processing (AAE Sender Adapter, AAE Receiver Adapter)

More detailed information on the individual steps in a dual-stack message processing scenario: Saving Message Versions in the AAE (Dual-Stack MessageProcessin

Message Processing (Advanced Adapter Engine)

This section provides information on the individual steps a message passes through at runtime within the Advanced Adapter Engine (AAE).

This description applies for AAE-only message processing scenarios.

The following figure shows the processing steps.

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 41 of 130

AAE-Only Message Processing (Detailed Picture)

A messages passes through the following steps:

01. Sender adapter processing

Based on the configuration of the sender adapter, the message is transformed technically to the XML message format the AAE can process (“XI messageformat”). In case also additional security-related configuration settings apply, the message is handled accordingly (for example decrypted, in case thecorresponding security level is configured).

The message header matches an integrated configuration. Therefore, message processing is continued on the AAE.

02. Inbound XML validation

Based on the configuration settings, the inbound message is checked with regard to the validity of its XML schema.

03. Receiver determination

Based on the configuration settings in the integrated configuration (Receiver tab page), the receivers of the message and the routing conditions are evaluated.

In case the message should be forwarded to multiple receivers, for each receiver a separate message is created.

04. Interface determination

Based on the configuration settings in the integrated configuration (Receiver Interfaces tab page), the assigned inbound interfaces (at the receiver side) areevaluated.

More sophisticated scenarios can be configured where a message is sent to multiple inbound interfaces or where a large message is split into several“message chunks” which are then sent to different inbound interfaces. For sakes of simplicity we do not consider these cases here and instead of that referto the corresponding section: Defining Message Splits.

05. Mapping

Based on the configuration settings in the integrated configuration (Receiver Interfaces tab page), the assigned mapping program is performed and the contentof the message transformed accordingly.

06. Outbound XML validation

Based on the configuration settings, the outbound message (sent to the receiver) is checked with regard to validity of its XML schema.

07. Receiver adapter processing

Based on the configuration of the receiver adapter (that is assigned to the integrated configuration), the message is transformed technically from the “XImessage format” to the format the receiver can process. In case also additional security-related configuration settings apply, the message is handledaccordingly (for example encrypted, in case the corresponding security level is configured).

Note that for sake of simplicity, the figure above does not cover more sophisticated use cases like, for example, message split scenarios.

The following related section describes at which steps within the processing sequence, a message version can be saved for administrative purposes: SavingMessage Versions in the AAE (Local Message Processing)

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 42 of 130

Runtime Caches

Configuration data maintained in Integration Directory is replicated to the involved runtime engines by a cache refresh mechanism.

As configuration data also uses design data from the Enterprise Services Repository (ES Repository), cache refresh can also include data from the ESRepository. This applies to mapping programs used in configuration objects in particular.

This mechanism improves performance when operating integration scenarios because it minimizes the communication between the runtime engines, ESRepository, and Integration Directory involved. In addition to this, the caching mechanism makes sure that the runtime engines can continue their operation also ifthe connection to the ES Repository and the Integration Directory is interrupted temporarily.

Cache refresh is triggered automatically when an object in the ES Repository or in the Integration Directory is activated. In addition to this, the cache refresh canbe initiated manually.

The following figure shows the runtime caches in an SAP NetWeaver PI dual-stack installation.

In an Advanced Adapter Engine Extended (AEX) installation, the Integration Engine cache is missing. Besides that, the figure also applies for the AEX.

Runtime Caches (SAP NetWeaver PI Dual-Stack Installation)

The following runtime caches (also referred to as cache consumer) are used:

CPA cache

Is used by the Advanced Adapter Engine (AAE) in order to process messages at runtime in accordance to the configuration settings.

This cache contains, for example, all configuration data related to configuration of adapters of the AAE.

Mapping cache

Is used by the mapping runtime in order to execute mappings at runtime in accordance to the configuration in Integration Directory and the mapping programdefined in the ES Repository.

Integration Engine cache

Is used by the Integration Engine in order to process messages at runtime in accordance to the configuration settings.

This cache contains, for example, all configuration data for the adapters that run on the Integration Engine.

Business system cache (AS ABAP)

Is used in connected SAP systems based on Application Server ABAP.

This cache contains in particular configuration settings related to communication components.

It also contains configuration data maintained in communication channels with adapter type WS.

One configuration object can have multiple cache consumer.

Depending on the scenario, the configuration settings of a communication channel are replicated to the CPA cache and to a business system cache.

Note

Note

Example

PUBLIC© 2012 SAP AG. All rights reserved.

Page 43 of 130

Automatic Cache Refresh

Automatic cache refresh is initiated when a cache-relevant object in the ES Repository (for example, a mapping) is changed and activated. Then the ESRepository notification service (see figure above) sends cache notifications to the Integration Directory. Depending on the information sent with the notification, thenotification service of the Integration Directory evaluates the relevant cache consumer and sends an HTTP request to the cache targets. The cache consumer arethen provided with the relevant update.

Defining a Collaboration Profile

You initially specify the units that are to be addressed as the sender or receiver of messages in the communication profile. You define communication parties andcommunication components for this purpose. You define communication channels to establish the technical communication paths for the communication party andthe communication components. You configure the adapters for inbound and outbound processing in the communication channels.

More information: Collaboration Profile

Procedure

This task involves the definition of communication components, communication channels, and (optional) communication parties.

01. Optional: Define the necessary communication parties.

Using a communication party, you generally address a company within a business-to-business process.

More information: Defining Communication Parties

02. Define the necessary communication components and (optional) parties.

To define communication components based on a landscape description in the SLD, perform the following steps:

Logon to the SLD and define the necessary technical systems and business systems.

More information: Describing System Landscape in the SLD

Logon to the Integration Directory and create the necessary communication components based on the business systems in the SLD.

More information: Defining Business System as Communication Component

These communication components are called business system components because they are based on business systems defined in the SLD.

To define a communication component “from scratch” without defining the business systems in the SLD, logon to the Integration Directory and create abusiness component.

More information: Business Component

To define a communication component to address an integration process from the ES Repository, create an integration process component.

More information: Define Integration Process as Communication Component

03. To specify the technical communication capabilities of a communication component, you define a communication channel. You need a sender/receivercommunication channel to specify the adapter to connect to a sender/receiver component.

A communication channel provides the configuration interface for the adapter that is used to connect the communication component with the PI runtimeengine.

01. At first, you create a communication channel in the Integration Directory.

More information: Defining Communication Channels

02. You specify the adapter type.

03. You specify the configuration settings for the chosen adapter type.

More information: Configuring Adapters

Configuring Adapters

The different runtime engines of SAP NetWeaver PI provide a different set of adapters.

Procedure

You use communication channels in the Integration Directory to configure the adapters.

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 44 of 130

With the Adapter Type attribute, you specify the adapter to configure. The possible configuration settings depend on the chosen adapter type.

The links below guide you to detailed information on the configuration interface for each adapter type.

Configuring Adapters of the Integration Engine

Configuring the IDoc Adapter (IE)

Configuring the HTTP Adapter (IE)

Configuring the XI Adapter

Configuring the Communication Channel with Adapter Type WS

Configuring Adapters of the Advanced Adapter Engine

Configuring the RFC Adapter

Configuring the IDoc Adapter (AAE)

Configuring the SOAP Adapter

Configuring the HTTP Adapter (AAE)

Configuring the File/FTP Adapter

Configuring the JDBC Adapter

Configuring the JMS Adapter

Configuring the Mail Adapter

Configuring the Marketplace Adapter

Configuring the SAP BC Adapter

Configuring the CIDX Adapter

Configuring the RNIF Adapter

More Information

The following sections provide an overview of the supported settings for each adapter:

Adapters (Integration Engine)

Adapters (Advanced Adapter Engine)

Setting up Scenarios Using Dual-Stack Message Processing

When use an SAP NetWeaver PI dual-stack installation, you use an Integration Server as host for your runtime engines (Integration Engine and central AdvancedAdapter Engine).

The Integration Server also includes the Business Process Engine for scenarios including cross-component Business Process Management.

Depending on the adapter used at runtime, the communication might include the central Advanced Adapter Engine or only the Integration Engine.

More information: SAP NetWeaver PI Dual-Stack Installation (under Dual-Stack Message Processing)

The following procedure applies for scenarios where message processing is performed by using both the Integration Engine (based on AS ABAP) and theAdvanced Adapter Engine (based on AS Java).

Procedure

1. Design Integration Content

You define the software components for your development project in the System Landscape Directory (SLD). You design your integration content in the ESRepository.

In this section, we describe the general procedure when you follow the top-down design approach, which means that you start with a process model and based onthe model specify all other integration content.

More information about the basic concepts: Design Time

There is the option either to design the integration yourself from scratch or to use integration details already designed and delivered by SAP where you canmodify this content according to your needs.

Both of these approaches normally come into play in real-life projects. A typical scenario would, for example, be that you use predefined content (andenhance it) to outline one part of the integration scenario, whereas another part has to be built completely from scratch. For the specific aspects that you haveto consider when using predefined content shipped by SAP, see Using Predefined Integration Content.

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 45 of 130

01. Define the software components you need for your developments.

You need these entities in order to organize the ESR content (interfaces, mappings, for example) you define with the following steps.

More information: Organizing and Managing Content in ESR

02. Log in to the ES Repository and choose the usage profile Process Integration (SAP BASIS 7.30) .

More information: Usage Profile

03. Define a process model.

There are different modeling approaches available in the ES Repository. Decide to use either of the following approaches and follow the procedures describedin one of the following sections:

Defining Process Integration Scenarios

Defining Process Component Architecture Models

For an overview of the model types, see: Process Models.

04. Define the necessary interface objects.

Designing interface objects implies the following sub tasks:

Designing data types

Designing message types

Designing service interfaces and their operations

There are other interface object types for special use cases, for example, context objects. For more information about the concepts behind these objects, seeInterface Objects in the ES Repository.

More information about the development procedure: Defining Interface Objects

05. Define the necessary mapping objects.

More information: Defining Mappings

06. Activate your ESR objects.

2. Configure Integration Content

At configuration time you specify how messages have to be exchanged between the individual systems or applications of the existing system landscape – inaccordance with the process model and additional integration content specified at design time.

More information about the basic concepts: Configuration Time

Key tools for this phase are the System Landscape Directory and the Integration Directory.

We recommend that you use a process model from the ES Repository as configuration template. Doing this, you can configure inbound processing, routing,mapping and outbound processing semi-automatically.

More information:

Using the Process Model as a Configuration Template

Model-based Configuration

Defining Collaboration Profile

This task involves the definition of communication components, communication channels and (optional) communication parties.

More information: Defining Collaboration Profile

Configuring Inbound Message Processing

To specify the inbound processing, you define which (sender) communication channel (or sender adapter) is to be used to transform the incoming message intothe message format that can be processes by the PI runtime. You do this by defining a sender agreement. In a sender agreement, you also can define securitysettings. Which security settings are supported, depends on the chosen adapter type.

To create a sender agreement, you first have to specify the following object key attributes: The sender component (to identify where the message comes from) andthe outbound interface (to identify which message the sender agreement applies to).

More information: Defining Sender Agreements

Sender agreements are not mandatory in all cases. You only have to define sender agreements when using special sender adapters that are configuredexplicitly at the inbound channel of the Integration Server (for example, sender File/FTP adapters). You also have to define a sender agreement when youwant to apply specific security settings for the processing of the incoming message.

You can make it easier for a business partner (sender) to call the Integration Server by publishing the sender agreement in the Services Registry. Thebusiness partner can then access the sender agreement in the form of a WSDL file in the Services Registry, before the firewall. The WSDL descriptioncontains all the relevant configuration data from the sender agreement as well as the assigned communication channel, which are required to call the

Note

Recommendation

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 46 of 130

Integration Server.

More information: Publishing Sender Agreements in the Services Registry

Configuring Routing and Mapping

The routing configuration is made up of the definition of receiver determinations and interface determinations. In receiver determinations you specify the receivercomponents of the message. In interface determinations you specify the receiver interfaces and mappings.

01. Define the required receiver determinations.

For each incoming message of a specific sender system (which is the key of the receiver determination), you define a receiver determination.

More information: Defining Receiver Determinations

When configuring a receiver determination, you also have the option to specify behavior at runtime if a receiver is not found. When you choose the optionthat the message processing is terminated with an error, you can correct the configuration and restart the message processing. More information:Displaying XML Message Versions

02. Define the necessary interface determinations.

You define an interface determination for a sender, an incoming message, and a specific receiver system.

More information: Defining an Interface Determination

Configuring Outbound Message Processing

To specify the outbound processing, you define which (receiver) communication channel (or receiver adapter) is to be used for an outgoing message (targeted at aspecific inbound interface of a specific receiver system). You do this by defining a receiver agreement. In a receiver agreement, you also can define securitysettings (depending on the chosen adapter type). When creating a receiver agreement, you have to specify a receiver component, a receiver (inbound) interface,and a sender component.

More information: Defining Receiver Agreements

Activating Configuration Objects

Activate the configuration objects so that your configuration settings become runtime-relevant.

More information: Change Lists

Setting Up Scenarios Using Local AAE-Based MessageProcessing

When using an SAP NetWeaver PI dual-stack installation, you can set up scenarios in such a way that communication between the sender and receiver systemis performed locally by the central Advanced Adapter Engine (AAE) without involving the Integration Engine. Technically, at runtime only AS Java is involved.

Although the Integration Engine and Advanced Adapter Engine are installed on the same Integration Server, the Integration Engine is not involved in this type ofmessage processing. This means you can usually achieve a higher level of performance than if the Integration Engine were involved.

Note the following restrictions for design time, compared to a full installation of SAP NetWeaver PI:

You can only use process integration scenarios for process modeling.

You cannot use integration processes (ccBPM).

The following adapter types are not supported: IDoc (ABAP-based), XI, HTTP (ABAP-based), WS-RM.

More information: SAP NetWeaver PI Dual-Stack Installation (under Local Message Processing Using the AAE)

Procedure

1. Design Integration Content

You design the integration content in the same way as described under Setting up Scenarios Using Dual-Stack Message Processing (see section 1.Designing Integration Content).

2. Configure Integration Content

At configuration time you specify how messages have to be exchanged between the individual systems or applications of the existing system landscape – inaccordance with the process model and additional integration content specified at design time.

Note

Recommendation

Caution

PUBLIC© 2012 SAP AG. All rights reserved.

Page 47 of 130

More information about the basic concepts: Configuration Time

Key tools for this phase are the System Landscape Directory and the Integration Directory.

Note that for the configuration of AAE-based message processing you can only use process integration scenarios as configuration template.

Defining Collaboration Profile

This task involves the definition of communication components, communication channels and (optional) communication parties.

More information: Defining Collaboration Profile

For the communication channel, you can only use adapter types that run on the AAE.

More information: Configuring Adapters under Configuring Adapters of the Advanced Adapter Engine

Configuring Message Exchange

This task involves the configuration of the inbound processing, routing, mapping and outbound processing (phases of message processing).

01. Log on to the Integration Directory.

02. Create an integrated configuration and specify the corresponding attributes for each of the phases of message processing.

More information: Defining the Integrated Configuration

As far as you have defined a process integration scenario at design time, you can use the model configurator to specify the message exchange.

More information: Configuring Process Integration Scenarios

03. Activate the configuration objects.

Advanced Development Tasks (Dual-Stack)

This section provides information about special development tasks when using the dual-stack installation option of SAP NetWeaver PI.

Procedure

More information:

Developing and Configuring Mappings

Developing and Configuring Integration Processes

Applying Advanced Routing Techniques

Configuring B2B Integration

Encrypting Message Content on Database Level

Configuring Principal Propagation

Developing and Configuring Web Service Scenarios

Implementing and Generating Proxies in Application Systems

Developing a Java Adapter for SAP NetWeaver PI

Developing and Configuring Mappings

In a mediated communication step of an integration scenario, the sender normally uses a data format and structure for sending out a message that is different to theone that the receiver can handle. Therefore, the data structure and format used by the sender must be transformed into the structure and format that the receivercan handle. This type of transformation is called mapping. You specify the corresponding transformation rules in the ES Repository – in the form of mappingobjects.

More information: Mapping Objects

Caution

Caution

Recommendation

PUBLIC© 2012 SAP AG. All rights reserved.

Page 48 of 130

Procedure

Defining Mappings

These are the steps to define a mapping:

Tasks at Design Time

01. Implement the mapping using one of the available kinds of mapping programs.

For an overview of the supported types of mapping programs, see Mapping Programs

The ES Repository provides a graphical editor to design mappings intuitively. Mappings designed with the graphical editor are called message mappings.

More information:

Message Mappings (Overview)

Message Mappings (Detailed Information)

02. In the ES Repository, create an operation mapping for a pair of source and target interface operation.

More information:

Preconfiguring Mapping Programs with Operation Mappings

Operation Mapping

03. Assign the mapping program to the operation mapping.

04. Activate the mapping objects you have created.

Tasks at Configuration Time

To configure mapping, you need to select an operation mapping from the ES Repository for a specific communication step. You do this in the Integration Directoryin an interface determination or in integrated configuration object depending on the chosen connectivity option.

More information: Defining an Interface Determination

Defining the Integrated Configuration

To specify the mapping, choose the Receiver Interfaces tab.

Applying Advanced Mapping Techniques

More information: Applying Advanced Mapping Techniques

Processing Mappings at Runtime

The Process Integration runtime executes the mappings configured in the Integration Directory at runtime after receiver identification has taken place. If nomapping is required for a connection then the Process Integration runtime skips the mapping step.

Applying Advanced Mapping Techniques

There are several advanced mapping techniques you can use to design and configure mappings.

Some of these techniques combine design time and configuration time features in a way that enables mappings to be used dynamically (value mappings orparameterized mapping programs). You can find a detailed description of these techniques under Advanced Mapping Techniques.

In this section, you find an introduction to these techniques and a summary of the most important aspects.

Procedure

Designing and Configuring Multi-Mappings

Designing and Configuring Value Mappings

Designing and Configuring Parameterized Mapping Programs

Designing Mappings for Adapter-Specific Message Attributes

Designing and Configuring Mapping Lookups

Designing and Configuring Multi-Mappings

In standard mapping use cases, a single source message is transformed into a single target message. This kind of mapping is also referred to as a 1:1transformation.

A multi mapping allows you to override this restriction. In particular, a multi-mapping gives you the following options:

PUBLIC© 2012 SAP AG. All rights reserved.

Page 49 of 130

Designing a 1:n transformation for a message split

Designing 1:n, n:1, and n:m transformations to be used in integration processes (cross-component Business Process Management)

Procedure

Designing 1:n Transformations for Message Splits (Interface Determination)

You can use a 1:n multi-mapping to map a message to multiple different (and generally smaller) messages during logical routing (mapping-based messagesplit). To set up a message split scenario, you have to perform the following steps:

01. ES Repository: Create the necessary multi-mapping and assign it to an operation mapping.

More information: Developing Multi-Mappings for Message Splits

02. Integration Directory: Select the operation mapping in the corresponding configuration object.

For Integration-Engine-based communication, you do this assignment in an interface determination.

For local message exchange using the Advanced Adapter Engine or in case you use the Advanced Adapter Engine Extended, you do this assignment inan integrated configuration.

The inbound interface operations will be evaluated based on the multi-mapping.

More information: Defining an Interface Determination

For more information on this technique, read section Defining Message Splits.

Designing 1:n, n:1, and n:m Transformations to Be Used in Integration Processes

You can use a multi-mapping in a transformation step of an integration process.

This is the summary of steps:

01. ES Repository: Create the necessary multi-mapping and assign it to an operation mapping.

It is a prerequisite that the message schemas for the messages to be mapped exist in the ES Repository and that they are assigned to asynchronous,abstract service interfaces. You can only use this interface type in integration processes.

More information: Developing Multi-Mappings for Integration Processes

02. ES Repository: Create an integration process and enter the operation mapping in a transformation step in an integration process.

More information: Transformation Step

Designing and Configuring Value Mappings

If senders and receivers know the same objects under different names, value transformations are required.

For example, a customer is identified in a sender system by a customer number, whereas in a receiver system the customer is identified by a name.

There are several options for performing value mappings:

Using standard function FixValues

Using standard function Value mapping

Procedure

Using Standard Function FixValues

This is the easiest way to define a value mapping. In the target field mapping, you assign the standard function FixValues from the Conversions functiongroup. Using this function, you can define value pairs. However, the value mapping defined by such a pair can only be used in the corresponding messagemapping. Furthermore, this is a rather “static” option for defining a value mapping, since the value pairs have to be known at design time.

Using Value Mapping Tables from Configuration

A more flexible and “dynamic” way to define a value mapping is to use the standard function Value mapping (Conversions function group area). Using thisstandard function, you can refer to value pairs that are defined at a later point in time during configuration. To define the value pairs from configuration time, you usea value mapping group in the Integration Directory.

The advantages of this approach are that value mappings can be reused within different message mappings and values can be specified later at configurationtime.

In many cases, the names of objects are not known prior to configuration time.

Note

Example

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 50 of 130

To refer to the values (that are not already known at design time) in the message mapping, in the function Value mapping you use the key fields Agency andSchema.

If you refer to a value mapping table created manually in the Integration Directory, you have to select http://sap.com/xi/XI as Value MappingContext. The value mapping context identifies the source of the value pairs.

At configuration time, you define the actual values of the objects by creating value mapping groups. A value mapping group is a configuration object in theIntegration Directory and contains different representations of the same object. To enter the values that identify the objects in different frames of reference, you usethe key fields Agency and Schema.

Agency and scheme set a frame of reference within which an object can be uniquely identified. For more information, see Identifiers.

As an alternative to the manual creation and editing of value mapping groups, you can replicate value pairs from external data sources using a special interface.The interface objects are available as part of SAP predefined content in the software component SAP BASIS . For more information, see Value MappingReplication.

More information: Value Mapping

Designing and Configuring Parameterized Mapping Programs

You can add parameters to a mapping program (enabling you to transfer values to the mapping program) in the following ways:

At configuration time (in an interface determination in the Integration Directory)

This is another way to execute mappings dynamically, in the sense that the actual values are not known until configuration time (see also Defining andConfiguring Value Mappings).

At design time (using a transformation step in an integration process (ccBPM) in the ES Repository)

You can define parameterized mapping programs for message mappings, Java mappings, and XSLT mappings with Java enhancements.

Procedure

To set up a scenario with a parameterized mapping program for a message mapping, you have to perform the following steps:

01. Define the parameters at design time. To do this, you have to perform the following steps:

In the message mapping (on the Signature tab), define the parameters to be used in the target field mapping.

In the operation mapping (that references the message mapping), create parameters (by choosing Parameters) and connect them with those of themessage mapping (by choosing Binding).

You can set either Simple Type or Adapter as the Category for the parameter. The category Adapter is only relevant if you set up a mapping lookupscenario.

02. Values can be entered for the parameters from the following locations:

Integration Directory: in the interface determination which uses the operation mapping

ES Repository: in a transformation step of an integration process

More information: Parameterized Mapping Programs

Designing Mappings for Adapter-Specific Message Attributes

The message header of a message contains a header for adapter-specific message attributes that the sender adapter can use to write additional information to themessage header. This enables sender adapters to write information that is not known until runtime to the message.

Furthermore, developers have read and write-to access to adapter-specific attributes from within a mapping program.

XSLT programs (J2EE) and message mappings have mapping runtime constants that enable developers to access the same Java classes for adapter-specific-attribute mappings as in Java mapping programs. Mapping programs executed on the Integration Server support this kind of access. There is a separateinterface for ABAP mappings.

Note

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 51 of 130

Procedure

More information:

Java Mapping of Adapter-Specific Message Attributes

ABAP Mappings (see the interface documentation for the interface IF_MAPPING_DYNAMIC_CONF )

Designing and Configuring Mapping Lookups

Mapping lookups access values in a back-end system when the mapping program is executed (at runtime). By using a mapping lookup, a mapping programcan call functions from other application systems while a mapping program is being executed. The data transfer between mapping runtime and applicationsystems is accomplished by means of a lookup programming interface (API). The API provides methods for accessing application systems using the RFC,JDBC, and SOAP adapter.

Procedure

To set up a mapping lookup scenario, you have to perform a combination of activities at design and configuration time:

01. At design time (in the ES Repository), you define the mapping program.

You can define lookups for message mappings, Java mappings, and XSLT mappings with Java enhancements.

At design time, you have to perform the following steps:

01. Provide an import function parameter (of type Adapter )

02. Implement the call to the application system (using the import parameter)

More information:

Using the Lookup API in a Java Mapping Program

Using the Lookup API in an XSLT Program

Using the Lookup API in a Message Mapping

When setting up lookups using the JDBC or the RFC adapter with a message mapping, you can perform this step graphically.

More information:

Defining JDBC Lookups Graphically

Defining RFC Lookups Graphically

02. At configuration time (in the Integration Directory), you have to perform the following steps:

01. Configure the corresponding adapter in a (receiver) communication channel.

More information: Defining Communication Channels

02. Assign the corresponding operation mapping (that refers to the mapping program) in an interface determination.

You have to do this to ensure that the ID of the receiver channel is transferred to your mapping program at runtime.

More information: Defining an Interface Determination

More information: Adding Lookups to Mapping Programs

Using the Lookup API in a Java Mapping ProgramPrerequisites

Note the prerequisites for the adapter that you want to use for the lookup (see: Adding Lookups to Mapping Programs).

Procedure

1. Implement a Parameterized Java Mapping Program

01. To be able to execute the lookup, your Java mapping program requires an import parameter of type Adapter. Create a Java mapping (see steps 1 and 2 inParameterizing Java Mappings).

02. Using the lookup API and the import parameter, implement the call to the application system.

For JDBC adapter calls, use the specific lookup API for the JDBC adapter (see: Implementing Lookups Using DataBaseAccessor).

For calls with all other adapters, use the generic lookup API (see: Implementing Lookups Using SystemAccessor).

03. To be able to assign a receiver channel to this import parameter later, you must assign the import parameter to an operation mapping parameter by using a

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 52 of 130

binding (see steps 3-7 in Parameterized Java Mappings).

To execute or test the mapping program and the mapping lookup, perform the following steps in the Integration Directory:

2. Configure a Receiver Channel for Mapping Lookups

01. Create the receiver communication channel for the application system call in the Integration Directory.

More information: Defining Communication Channels

02. To transfer the ID of the receiver channel to your Java mapping program at runtime, create an interface determination and assign it to the operation mappingfrom step 3.

More information: Defining an Interface Determination

You can only execute the mapping lookup once you have performed these steps and have installed the runtime components of the Integration Server. Ifthis is not the case, the Java mapping program will terminate with an error message.

Result

You have implemented a lookup in your Java mapping program, and have configured it in the Integration Directory. You can now test the Java mapping programin the operation mapping (see: Test Environment for Operation Mappings).

Using the Lookup API in an XSLT ProgramPrerequisites

Note the prerequisites for the adapter that you want to use for the lookup.

More information: Adding Lookups to Mapping Programs

Procedure

To add a lookup to an XSLT program, you must parameterize it and use the lookup API. To access parameters and to use the mapping API, you must call Javamethods in the XSLT program. To minimize the number of Java methods that need to called, SAP recommends that you encapsulate the entire mapping lookup inone single Java method.

1. Implement a Parameterized XSLT Mapping Program

01. To be able to execute the lookup, your XSLT mapping program requires an import parameter for the adapter that is to be used. Create an XSLT mapping (seesteps 1 and 2 in Parameterizing XSLT Mappings). At runtime, the relevant operation mapping uses the import parameter to transfer the ID of an appropriatereceiver channel for the adapter (see steps 4-6).

02. Create a Java mapping program by implementing the look up. The method that you want to use to execute the lookup must have a parameter in order totransfer the ID of the receiver channel (see step 1) from the XSLT program. Furthermore, add additional parameters that are required for the lookup and fortransferring the result to the XSLT program, to the signature of the Java method.

More information: XSLT Mapping with Java Enhancement

03. Using the lookup API and the import parameter, implement the call to the application system within the Java method.

For JDBC adapter calls, use the specific lookup API for the JDBC adapter.

More information: Implementing Lookups Using DataBaseAccessor

For calls with all other adapters, use the generic lookup API.

More information: Implementing Lookups Using SystemAccessor

04. To be able to assign a receiver channel to this import parameter later, you must assign the import parameter to an operation mapping parameter by using abinding (see steps 3-7 in Parameterized XSLT Mappings).

To execute or test the mapping program and the mapping lookup, perform the following steps in the Integration Directory:

2. Configure a Receiver Channel for Mapping Lookups

01. Create the receiver channel for the application system call in the Integration Directory.

More information: Defining Communication Channels

02. To transfer the ID of the receiver channel to your XSLT mapping program at runtime, create an interface determination and assign it to the operation mappingfrom step 4.

More information: Defining an Interface Determination

You can only execute the mapping lookup once you have performed these steps and have installed the runtime components of the Integration Server. Ifthis is not the case, the XSLT mapping program will terminate with an error message.

Caution

Caution

PUBLIC© 2012 SAP AG. All rights reserved.

Page 53 of 130

Result

Using a Java enhancement, you have implemented a lookup in your XSLT mapping program, and have configured it in the Integration Directory. You can now testthe XSLT mapping program in the operation mapping (see: Test Environment for Operation Mappings).

Using the Lookup API in a Message Mapping

You can use the mapping lookup API in a used-defined function of a message mapping and then use the generic lookup API (class SystemAccessor ) or thespecial API for database calls ( DataBaseAccessor ). In the case of the latter, if the SELECT calls are only basic, it is sufficient to use the standard function todefine JDBC lookups graphically.

More information: Defining JDBC Lookups Graphically

Prerequisites

Note the prerequisites for the adapter that you want to use for the lookup.

More information: Adding Lookups to Mapping Programs

You have already created a message mapping and are in the mapping editor.

Procedure

1. Implement a Parameterized Message Mapping Program

01. To execute the lookup, your user-defined function requires an import function parameter of type Adapter, which is assigned to the message mappingparameter (see step 1-3 in Defining and Using Import Parameters).

02. Using the lookup API and the import parameter, implement the call to the application system

If the features of the standard function for graphical JDBC lookups (see above) are not sufficient for your application, use the specific lookup API for theJDBC adapter.

More information: Implementing Lookups Using DataBaseAccessor

For calls with all other adapters, use the generic lookup API

More information: Implementing Lookups Using SystemAccessor

03. If, later, you want to assign a receiver channel to the message mapping parameter that you assigned the import function parameter to in step 1, you mustassign this import parameter to an operation mapping parameter by using a binding (see step 4-8 in Defining and Using Import Parameters).

To execute or test the mapping program and the mapping lookup, perform the following steps in the Integration Directory:

2. Configure a Receiver Channel for Mapping Lookups

01. Create the receiver channel for the application system call in the Integration Directory.

More information: Defining Communication Channels

02. To transfer the ID of the receiver channel to your message mapping program at runtime, create an interface determination and assign it to the operationmapping from step 3.

More information: Defining an Interface Determination

You can only execute the mapping lookup once you have performed these steps and have installed the runtime components of the Integration Server. Ifthis is not the case, the message mapping program will terminate with an error message.

Result

You have implemented a lookup in a user-defined function of your message mapping program, and have configured it in the Integration Directory. You can nowtest the message mapping program in the operation mapping (see: Test Environment for Operation Mappings).

Defining JDBC Lookups Graphically

The data-flow editor in the mapping editor has the standard function JDBC lookup with which you can define a mapping-lookup using the JDBC adaptergraphically. You can formulate simple SELECT statements using the editor for this function.

Prerequisites

To be able to graphically model the lookup, you must know the table structure of the table that is to be accessed. To use the table structure in the mapping editor,

Caution

PUBLIC© 2012 SAP AG. All rights reserved.

Page 54 of 130

you must import it to the Enterprise Services Repository as an external definition (see step 2). To do this, the following conditions must be met:

The table must be defined in the database.

To access the table of the database, a JDBC adapter instance and the relevant database must be running.

Special Prerequisites for Databases

The mapping editor generates Java program code from the graphical definition of the mapping lookup. The SELECT statement that is generated contains the fieldsyou access using the default function in the graphical JDBC lookup. The fields are set in double quotation marks to avoid conflicts with SQL keywords.

In the mapping lookup, access an ORDER field that contains a request number. The SQL SELECT statement however contains an ORDER keyword to setthe order. To identify the field in the SELECT statement as identifier for a field it must be set in doubled quotation marks ( "ORDER" ). Otherwise the statementsyntax is incorrect.

The database that you want to access using the JDBC lookup must work with double quotation marks for accessing fields in the SQL syntax. This can beconfigured for the database in some cases: for example, if a JDBC lookup, which is described by the graphical standard function, only functions with a MySQLdatabase when the SQL mode ANSI or ANSI_QUOTES is set.

Procedure

1. Enable Access to the Database Table

01. In the Integration Directory, create the JDBC receiver channel for the call to the application system.

More information:

Defining Communication Channels

Configuring the Receiver JDBC Adapter

This receiver channel is initially only required for reading the table structure. The developer or consultant can create a different receiver channel later toaccess the same table in a different system (see also step 8 below).

02. Create an external definition in the Enterprise Repository and import the table structure for the lookup (see: Importing Table Structures from a Database).

2. Define a Parameterized Message Mapping Program

01. In the Enterprise Services Repository, create a message mapping with a source and target structure, or open an existing message mapping for editing.

02. In the mapping editor, switch to the Signature tab page. Create an import message mapping parameter of category Adapter (for example, MMP_JDBC ) andassign it the adapter metadata of the JDBC adapter. The adapter metadata of the JDBC adapter is shipped by using software component SAP BASIS.

03. In the mapping editor, navigate to the Definition tab page and then to the target-field mapping for which you want to define the JDBC lookup.

04. Drag the standard JDBC lookup function to the data-flow editor and define the SELECT statement in the function properties graphically:

01. Select the import message-mapping parameter for the JDBC adapter from the dropdown list box ( MMP_JDBC from step 4). The message mapping usesthis parameter later to transfer the ID of the receiver channel to the function which is to be used for the lookup (see steps 7 and 9).

02. Call input help and select the external definition from step 2.

03. Define the SELECT statement.

All available fields are displayed in the middle of the standard-function editor. The mapping editor creates an inbound or outbound parameter for thefunction for each field that you add to the right or left column.

Add all fields that you want to use to read a row in the database table to the column on the left. You must assign values to these fields later. To do so, inthe data-flow editor, assign them the source fields or result values of other functions. If you do not specify a unique key when you select the fields,multiple rows are read.

Add all the fields that you want to apply from the result of the SELECT statement and want to process further to the column on the right. If a SELECTstatement selects multiple rows, the function returns a result queue for each result parameter.

04. If you have selected the relevant checkbox in the function properties of the standard function, the mapping runtime inserts a context change after eachvalue in the result queue.

05. If, later, you want to assign a receiver channel to the message mapping parameter that you assigned the import function parameter to in step 1 (MMP_JDBC),you must assign this import parameter to an operation mapping parameter by using a binding (see step 4-8 in Defining and Using Import Parameters),for example IM_JDBC.

To execute or test the mapping program and the mapping lookup, perform the following steps in the Integration Directory:

3. Configure a Receiver Channel for Mapping Lookups

01. If you want to use a different JDBC receiver channel to the one in step 1, in the Integration Directory, create a new receiver channel for calling the applicationsystem.

More information:

Defining Communication Channels

Configuring the Receiver JDBC Adapter

02. To transfer the ID of the receiver channel to your message mapping program at runtime, create an interface determination and assign it the operation mappingfrom step 7. Then, in the interface determination, you can assign the receiver channel to the operation-mapping parameter (in the example IM_JDBC).

More information: Defining an Interface Determination

Example

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 55 of 130

You can only execute the mapping lookup once you have performed these steps and have installed the runtime components of the Integration Server. Ifthis is not the case, the message mapping program will terminate with an error message.

Result

You have defined a lookup in your message mapping by using the standard JDBC Lookup function, and have configured it in the Integration Directory. You cannow test the message mapping program in the operation mapping (see: Test Environment for Operation Mappings ).

Defining RFC Lookups Graphically

The data-flow editor in the mapping editor has the standard function RFC lookup with which you can define a mapping-lookup using the RFC adapter graphically.The function takes the request, response, and fault parts of an imported RFC into account.

Prerequisites

To be able to model the lookup graphically, the structure of the RFC must be known. To use this structure in the mapping editor, you must import the RFC to theEnterprise Services Repository (see step 2 below).

Procedure

Enable RFC Call and Import RFC for Mapping Editor

In the Integration Directory, create the RFC receiver channel for the call to the application system.

More information:

Defining Communication Channels

Configuring the Receiver RFC Adapter

This receiver channel is initially only required for testing the lookup. The developer or consultant can create a different receiver channel later to call the same RFCin a different system (see also step 8 below).

Import the RFC into the Enterprise Services Repository.

More information: Importing IDocs and RFCs

Define a Parameterized Message Mapping Program...

In the Enterprise Services Repository, create a message mapping with a source and target structure, or open an existing message mapping for editing.

In the mapping editor, switch to the Signature tab page. Create an import message-mapping parameter of category Adapter (for example, MMP_RFC ) and assignit the adapter metadata of the RFC adapter. The adapter metadata of the RFC adapter is shipped in software component SAP BASIS.

In the mapping editor, navigate to the Definition tab page and then to the target-field mapping for which you want to define the RFC lookup.

Drag the standard function RFC Lookup in function category Conversions to the data-flow editor and define the call graphically in the function properties:

Select the import message-mapping parameter for the RFC adapter from the dropdown list box ( MMP_RFC from step 4). The message mapping uses thisparameter later to transfer the ID of the receiver channel to the function which is to be used for the lookup (see steps 7 and 9).

Call input help and select the imported RFC from step 2.

To define the RFC call, in the function properties for standard function RFC Lookup, model the inbound and return parameters for the function, and model howthey are associated with the request and response parameters of the RFC. If you connect source fields or functions with the inbound parameters later, youimplicitly define a mapping between these source fields or functions and the parameters of the RFC request (left-hand side). At runtime, this mapping isprocessed in the same way as a target-field mapping. In the function properties, you then define which parameters of the RFC response can be assigned totarget fields or functions by using the return parameters in the dataflow editor (right-hand side).

Caution

PUBLIC© 2012 SAP AG. All rights reserved.

Page 56 of 130

Define the mapping as follows:

To use a parameter from the RFC request or the RFC response as the inbound or return parameter for the standard function RFC lookup, double-click theparameter in the structure. The parameter is then transferred to the table in the lower screen area. In the table you can also define the sequence of the inboundor return parameters.

Parameters in the RFC that are not scalar values are displayed in the dialog box in bold. Such parameters are, for example, table parameters in the RFC thatare mapped to elements with maxOccurs = unbounded . The same rules as for normal target-field mappings apply for the mapping to the parameters ofthe RFC request, or for the mapping from the parameters of the RFC response.

Instead of offering a parameter of the RFC request as the inbound parameter of the standard function RFC lookup, you can also enter a constant in the structure.

You can handle exceptions defined in the RFC as follows during the RFC lookup:

If you have selected the Use Exceptions checkbox in the function properties of the standard function, the mapping editor adds an additional parameter in red(the bottommost return parameter) to the standard function in the data-flow editor. If you do not assign a target field to this return parameter, ignore the RFCexceptions (the message mapping is not terminated at runtime). Otherwise the mapping runtime transfers the exception as an XML structure and it can thenbe evaluated in a user-defined function, for example. If there is no exception, the mapping runtime transfers an empty context.

If you have not selected the Use Exceptions checkbox, the mapping runtime terminates the message mapping if an exception occurs during the RFC lookup.

If, later, you want to assign a receiver channel to the message-mapping parameter that you assigned the import function parameter to in step 1 ( MMP_RFC ), youmust assign this import parameter to an operation-mapping parameter by using a binding (see step 4-8 in Defining and Using Import Parameters), forexample IM_RFC .

To execute or test the mapping program and the mapping lookup, perform the following steps in the Integration Directory:

Configure a Receiver Channel for Mapping Lookups

If you want to use a different RFC receiver channel to the one in step 1, create a new receiver channel for calling the application system in the IntegrationDirectory.

More information:

Defining Communication Channels

Configuring the Receiver RFC Adapter

To transfer the ID of the receiver channel to your message mapping program at runtime, create an interface determination and assign it the operation mappingfrom step 7. Then, in the interface determination, you can then assign the receiver channel to the operation-mapping parameter (in the example IM_RFC ).

More information: Defining an Interface Determination

Caution: You can only execute the mapping lookup once you have performed these steps and have installed the runtime components of the Integration Server. Ifthis is not the case, the message mapping program will terminate with an error message.

Result

You have defined a lookup in your message mapping by using the standard function RFC Lookup, and have configured it in the Integration Directory. You can nowtest the message mapping program in the operation mapping (more information: Test Environment for Operation Mappings ).

Developing and Configuring Integration Processes

In section Developing and Configuring Integration Scenarios we considered message exchange only for cases where messages are received andforwarded by SAP NetWeaver PI without any correlations between messages. Each interaction step is de-coupled from the others: the runtime engine processesan incoming message, forwards it to the configured receivers, and applies additional actions to the messages according to the configuration data. However, oncethe message has been sent, no status is held; the runtime engine “forgets” the message. With cross-component Business Process Management (ccBPM), themessage choreography capabilities of SAP NetWeaver Process Integration are extended so that a status is kept. This section provides the basic information onhow this works.

You can use ccBPM to define an integration process. An integration process is composed of a specific flow of steps (including the sending and receiving ofmessages), during which the status of the process is persisted on the Integration Server. In an integration process, you can define a specific level of processcontrol. For example, you can specify how long an integration process must wait for further messages to arrive, or you can group incoming messages and thensend them in a particular order. You can also define control structures, such as loops and processing branches that are independent of each other. You can defineconditions that control processing depending on the result of the condition. You can correlate messages with each other in order to ensure that messages thatbelong together are processed by the same integration process instance.

You cannot use integration processes in the following cases:

Scenarios that are based on an AEX installation

Scenarios using local message exchange on the Advanced Adapter Engine in a standard installation of SAP NetWeaver PI

Procedure

To set up a scenario including ccBPM, you have to perform the following tasks:

01. Design an integration process in the ES Repository

An integration process is specified as a separate object in the ES Repository using a graphical editor. To make sure that the integration process can send andreceive messages, you have to embed the integration process in an overall scenario or model. The model type has to be a process integration scenario.

Caution

PUBLIC© 2012 SAP AG. All rights reserved.

Page 57 of 130

In order to embed an integration process into an overall scenario or model, you cannot use an integration scenario model or a process componentsinteraction model as the overall process model. Instead, you have to use a “classical” process integration scenario.

More information: Designing Integration Processes

02. Configure the integration process in the Integration Directory

At configuration time, you treat the application component containing the integration process as a single communication component. Based on this assignment,you configure the process integration scenario using the model configurator.

More information: Configuring Integration Processes

03. Execute and monitor the integration process

Integration processes are executed using a separate runtime component, the Business Process Engine, which comes into play for the execution of integrationprocesses on the Integration Server.

To find more information about best practices and examples, check the following information sources:

Tutorial: Defining an Integration Process

Checklist: Making Correct Use of Integration Processes

Designing Integration Processes

You design an integration process in the ES Repository.

An integration process is specified as a separate object in the ES Repository using a graphical editor. To make sure that the integration process can send andreceive messages, you have to embed the integration process in an overall scenario or model.

Procedure

Specifying the Integration Process

Using a graphical process editor, you specify the “inner workings” of an integration process.

This procedure is documented in detail under Defining and Managing Integration Processes. In this section, we summarize the main aspects.

Specifying an integration process is composed of the following main tasks:

01. Specifying service interfaces

02. Using the graphical process editor

Specifying Service Interfaces

To enable the integration process to exchange messages with other application components, you need service interfaces. For service interfaces used inintegration processes, you have to select Abstract as the Category.

An abstract service interface is an interface that has no defined direction initially. Whereas outbound or inbound interfaces have an implemented interface in anapplication system as a counterpart, abstract service interfaces are only used by integration processes to send or receive messages. You can use the sameabstract service interface to receive or to send. You cannot generate a proxy for this interface type.

An integration process can only reference service interfaces from its own software component version.

More information: Process Signature

Using the Graphical Process Editor

These are the main elements of an integration process:

Container elements

You define the data the integration process has to process (its “variables”) as container elements. Container elements can have the following types:

Abstract interface

For messages (to be used in receive or send steps) described by corresponding abstract service interfaces.

Simple XSD Data Type

Caution

Note

Note

Caution

PUBLIC© 2012 SAP AG. All rights reserved.

Page 58 of 130

For process control elements, such as counters.

Receiver Used in a receiver determination step (see below).

The actual list of receivers is determined at runtime based on a receiver determination in the Integration Directory.

More information: Defining Process Data as Container Elements

Configurable parameters

You can define parameters whose values you can specify later, at configuration time. This gives you greater flexibility in handling the integration process.

More information: Defining Configurable Parameters

Process steps

You construct the integration process out of different process steps. You can use different step types. For example, you use a send step to send a message toanother integration process or to a business system. When specifying a process step, you choose the corresponding container elements. For example, whenyou define a receiver determination step, you need a container element of the type Receiver to assign to the step.

For detailed information, see Step Types. However, note the following:

Transformation steps are used to transform messages. Therefore, these steps refer to an operation mapping. You can use 1:n multi-mappings to split amessage into multiple messages, n:1 multi-mappings to bundle multiple messages into a single message, or 1:1 mappings for message transformations(see also Designing and Configuring Multi-Mappings).

In receive steps and send steps, you refer to the container elements for the corresponding abstract service interfaces.

In a receiver determination step, you refer to the corresponding Receiver container element.

In switch steps, fork steps, and loop steps, you can define conditions.

More information: Define a Condition

User decision steps enable users to make decisions that influence the processing of the integration process. The intended user receives a dialog work itemin the workflow inbox at runtime.

Message correlations

You use a correlation to join messages that belong together to the same process instance. In a correlation you define the message elements (for example, acustomer number) by which messages are to be correlated.

More information: Correlation: Defining Assignment of Msgs to Process Instances

Exception Handling

More information: Dealing with Exceptions

Deadline Monitoring

More information: Deadline Monitoring

Defining Sync/Async Communication

You can define a “sync/async bridge” to enable the communication between a synchronously calling business system and an asynchronously called businesssystem.

More information: Defining Sync/Async Communication

You define these elements using the graphical process editor.

More information: Process Editor

Embedding the Integration Process into a Process Integration Scenario

To enable the integration process to exchange messages with other (application) components, you have to embed the integration process into a processintegration scenario as the overall model. In a process integration scenario, you use application components to model the communication partners.

You use application components to represent the basic entities that exchange messages with each other. An application component represents an overallapplication area, such as SAP SCM. Those “process steps” that exchange messages with each other are modeled as actions within an application component.

For each integration process, you insert a separate application component. In the process integration scenario, you have to model the parts of the integrationprocess that are involved in message exchange interactions. You use actions to do this.

You find the detailed description of the concept as well as modeling guidelines under Defining Process Integration Scenarios.

Keep in mind that the application component defined for the integration process in the process integration scenario can be seen as the signature of theintegration process. It displays those parts of the integration process that interact with other application components using message exchange.

You can navigate from the corresponding application component to the integration process editor to display or further specify the “inner workings” of the integrationprocess.

Configuring Integration Processes

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 59 of 130

At configuration time, the integration process designed in the ES Repository acts as sender and receiver of messages and is, therefore, treated as a separatecommunication component. From a configuration time point of view, the integration process is nothing more than a “black box”.

Procedure

You configure an integration process in the Integration Directory.

To enable an integration process to be addressed as a sender or receiver of messages, you need to define a communication component of type integrationprocess (or integration process component). You basically create a communication component, specify a name, and assign the integration process from the ESRepository. If you have defined Configurable Parameters, you can specify them further here.

You do not assign a communication channel to an integration process component.

More information: Define Integration Process as Communication Component

The subsequent configuration of the message exchange including the integration process component is then performed using basically the same procedure asalready described under Developing and Configuring Integration Scenarios.

Applying Advanced Routing Techniques

This section provides information on how to apply special routing techniques like content-based or dynamic routing, for example.

The basics of routing have been described under Routing .

Procedure

More information:

Defining Content-Based Routing

Defining Dynamic Routing

Defining Message Splits

Defining Content-Based Routing

In many business cases, it is necessary to define conditions with which the receivers or inbound interfaces of a message are determined during routing. Forexample, consider a routing condition in the following form: “If the value of a specific field in the message is x, then forward the message to receiver y”.

At configuration time, you can define conditions that depend on the content of the message. You can do this for receiver determinations, receiver rules and interfacedeterminations.

More information: Content-Based Routing

Procedure

To configure content-based routing, you basically do the following:

When configuring content-based routing in a receiver determination or receiver rule, you define routing conditions for specific receivers or a sets of receivers.

When configuring content-based routing in an interface determination, you define routing conditions for specific sets of inbound interfaces.

Create one of the following objects in the Integration Directory:

Defining Receiver Determinations

Defining a Receiver Rule

Defining an Interface Determination

For local message exchange using the Advanced Adapter Engine or in case you use the Advanced Adapter Engine Extended, you configure content-basedrouting in an integrated configuration (Receiver tab page or Receiver Interfaces tab page).

More information: Defining the Integrated Configuration

When you define a routing condition, you basically specify the following attributes:

With the Left Operand, you specify the payload element of the incoming message upon which the routing to the specified receiver is to depend.

In the Right Operand, you enter a value for the payload element.

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 60 of 130

You choose a specific Operator to link both operands.

You have the following options to specify the payload element:

Using an XPath expression

Using this option, you can select the payload element intuitively from the structure of the incoming message (which is defined by the outbound interface in thekey of the receiver determination or interface determination).

You cannot specify expressions using XPath when you define conditions in receiver rules.

Using a context object

Using this option, you select a context object that has been defined for the outbound interface. A context object is a design object that can be used as anabbreviated expression for an XPath expression to address a specific payload element.

A context object has to be defined with the corresponding outbound interface in the ES Repository beforehand. So, if you already know at design time thepayload elements upon which the routing is likely to depend, you can define the corresponding context objects in the ES Repository at the correspondingservice interface.

More information: Creating Context Objects

Defining Extended Receiver Determinations

When using routing conditions or routing rules in receiver determinations, the receivers of a message are determined at runtime by evaluating the condition (whichdepends on the content of the message). However, the names of the receivers have already been defined at configuration time in the Integration Directory (dual-stack installation option: in the receiver determination object; Advanced Adapter Engine Extended (AEX): integrated configuration, Receiver tab).

When you configure routing that way (referred to as standard receiver determination), you have to specify the receiver names as part of the configurationprocedure in Integration Directory.

A more flexible way to configure routing is offered by the extended receiver determination.

In an extended receiver determination, you can specify a mapping program that takes over the task of finding out the actual receivers at runtime. You can designthe mapping program that way that the receivers of the message are read from a list that might be part of an external data source (mapping look-up approach).

This approach has the following advantages:

Storing receiver names in an external data source allows to update of the receiver list without the need of a cache refresh.

Storing receiver names outside the Integration Directory allows non-integration experts to maintain receivers.

Procedure

Extended receiver determination is supported for both kinds of message processing (dual-stack and the Advanced Adapter Engine message processing).

More information:

Defining Extended Receiver Determination (Dual-Stack) (dual-stack message processing)

This procedure is only relevant in case you have a dual-stack SAP NetWeaver PI installation and configure message processing using both stacks(Integration Engine and Advanced Adapter Engine).

Defining Extended Receiver Determination (Advanced Adapter Engine) (message processing using the Advanced Adapter Engine only)

This procedure is relevant in case you have a dual-stack SAP NetWeaver PI installation and configure message processing using the Advanced AdapterEngine only (bypassing the Integration Engine).

Defining Extended Receiver Determination (Dual-Stack)Procedure

01. Define a suitable mapping in the ES Repository.

More information: Mapping Messages to Each Other Using Mapping Objects

Note

Note

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 61 of 130

In particular, do the following:

Define an operation mapping and assign the abstract service interface ReceiverDetermination as the target interface. The service interfaceReceiverDetermination is in the Enterprise Services Repository in the software component SAP BASIS (namespacehttp://sap.com/xi/XI/System ).

Define the message mapping or mapping program that is to determine the receivers at runtime. Assign this message mapping or mapping program to theoperation mapping specified before.

The service interface uses the message type Receivers and the data type Receivers . The data type Receivers describes a list of receivers andhas the following structure:

The following instance of the data type Receivers contains two receivers. The first receiver comprises a party (element Party ) and communicationcomponent (element Service ) and is identified by a DUNS number; the second receiver comprises a communication component without a party.

01. <Receivers>02. <Receiver>03. <Party agency="016" scheme="DUNS"></Party>04. <Service>"MyService"</Service>05. </Receiver>06. <Receiver>07. <Party agency="http://sap.com/xi/XI" scheme="XIParty"></Party>08. <Service>"ABC_200"</Service>09. </Receiver>10. </Receivers>

You can specify party and communication component for each receiver.

02. Define an extended receiver determination in the Integration Directory

Enter the outbound interface of the operation mapping from above in the key of the receiver determination as the outbound interface. Assign this operationmapping to the receiver determination.

More information: Defining Extended Receiver Determination

03. Define the remaining configuration objects in Integration Directory (interface determination, sender and receiver agreements).

As you can use wildcards ( * ) to mask the keys of these configuration objects, you can leave out the names of the receivers.

Usage of wildcards therefore makes it possible to fully source out the determination of receivers to a mapping look-up executed at runtime. With otherwords, the names of the receivers don't need to be known already at configuration time.

More information on usage of wildcards: Defining Configuration Objects Generically/Specifically

If the mapping program returns an XML file with empty or missing <Service></Service> tag, the message is routed to the default receiver (that isconfigured in the receiver determination under If No Receiver Is Found, Proceed as Follows, option Select the Following Receiver:).

Defining Message Splits

You can set up scenarios where a message is split into several fragmented messages at runtime that are then sent to the same (or different) receiver systems.

These are the basic scenarios that you can configure using an interface determination from the Integration Directory:

Interface split

Mapping-based message split

Procedure

Defining an Interface Split

By default, in an interface determination you specify one or more inbound interfaces for a given receiver system. For each inbound interface, you might also like toassign a mapping since the inbound interfaces are most likely different from each other.

This is the basic procedure:

01. Define the service interfaces and operations in the ES Repository.

02. Optional: Define the necessary mappings in the ES Repository.

Note

Syntax

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 62 of 130

03. Define an interface determination in the Integration Directory (for Integration Engine-based communication) or an integrated configuration (for all scenarios wheremessages are processed by the Advanced Adapter Engine).

More information:

Defining an Interface Determination

Defining the Integrated Configuration

The figure below shows the behavior at runtime:

Interface Split

Defining a Mapping-Based Message Split

When you have a larger message (for example, one message containing a large number of line items) to be split into several smaller messages with eachmessage containing only a subset of line items of the large message, then you can do the following:

01. In the ES Repository, define a 1:n multi-mapping to specify the transformation of the large message into n smaller messages.

More information: Developing Multi-Mappings for Message Splits

02. In the Integration Directory, define an interface determination (for Integration Engine-based communication) or an integrated configuration (for all scenarios wheremessages are processed by the Advanced Adapter Engine) with the following properties:

The object key contains the source interface of the multi-mapping as outbound interface.

In the interface determination or integrated configuration, select the multi-mapping from the ES Repository (in the Operation Mapping field).

Note that in an interface determination you can select multi mappings for 1:n, n:1, or m:n transformations from the ES Repository. However, at runtimeonly 1:n transformations can be processed.

The target interfaces defined for the multi-mapping in the ES Repository are then calculated and displayed in the interface determination.

More information:

Defining an Interface Determination

Defining the Integrated Configuration

The figure below shows the behavior at runtime:

Mapping-Based Message Split

Using this option, you can only configure a message split where the split messages are sent to different inbound interfaces of the same receiver system.

The reason for this is as follows: During runtime, the receiver determination step is performed prior to the mapping step. At the time when the multi-mapping isperformed and the corresponding inbound interfaces are calculated (and the corresponding split messages are generated), there is no chance to do another“receiver split”. The resulting split messages can only be sent to the receiver system determined in the previous step.

Routing the Split Messages to Different Receiver Systems

To configure a message split where the split messages are routed to different receiver systems, you define the message split using several 1:1 mappings(instead of one 1:n mapping).

This is the procedure:

01. In the ES Repository, define the necessary 1:1 mappings for each of the intended split messages. Each mapping creates another subset of line items out ofthe large source message.

02. In the Integration Directory, do the following:

01. Configure the different receiver systems in a receiver determination.

More information: Defining Receiver Determinations

Note

Caution

PUBLIC© 2012 SAP AG. All rights reserved.

Page 63 of 130

02. For each configured receiver, define an interface determination or an integrated configuration. Assign the right 1:1 mapping and inbound interface.

More information:

Defining an Interface Determination

Defining the Integrated Configuration

The behavior at runtime is illustrated in the figure below:

Configuring a Message Split with Different Receiver Systems

Using Adapter-Specific Message Attributes in the MessageHeader

Some adapters support specific message attributes, which contain additional information about messages. This information is not located in the payload of themessage, but in additional message header fields.

Every adapter has a defined set of attributes, which are described for every adapter type as part of the configuration for each of the adapters. You can set theattributes in the sender adapter and use the attributes in the receiver adapter.

The length of the attribute value is defined by the XI message protocol. Values can be a maximum of 200 characters long. If, for example, you assign longervalues in the mapping or adapter modules then this can lead to processing errors at runtime or the values are shortened to 200 characters. This shortening canalso lead to a processing error. The processing error that occurs depends on the components that access the attributes.

In routing and mapping you can use the namespace and the technical name of attributes to access them.

The attribute namespace comprises the namespace in the Enterprise Services Repository in which the adapter metadata for the adapter is saved and the nameof the adapter metadata object.

The adapter namespaces for the adapters shipped by SAP therefore have the following format:

http://sap.com/xi/XI/System/<Adapter Metadata Object Name of Adapter>

The SAP adapter metadata objects are in namespace http://sap.com/xi/XI/System of software component SAP BASIS.

Procedure

01. In the sender adapter, select Set Adapter-Specific Message Attributes and select the attributes you want to use in the message header.

For more information, see the Adapter-Specific Message Attributes:

Configuring the Sender RFC Adapter

Configuring Sender Plain HTTP Adapter in Integration Directory

Configuring the Sender File Adapter

Configuring the Sender FTP Adapter

Configuring the Sender JMS Adapter

Configuring the Sender SOAP Adapter

Configuring the Sender Mail Adapter

PUBLIC© 2012 SAP AG. All rights reserved.

Page 64 of 130

Configuring the Sender RNIF 1.1 Adapter for Requests

Configuring the Sender RNIF 2.0 Adapter for Requests

Configuring the Sender CIDX Adapter

02. Use the set attributes in routing, mapping, or in the receiver adapter of the same type:

Specify an adapter-specific attribute as a context object when formulating a routing condition in the expression editor.

For more information, see Expression Editor

To evaluate the routing condition at runtime, the current value of the attribute is read from the message header.

In the mapping, you can use Java functions to get read and write access to attributes.

For more information, see Java Mapping of Adapter-Specific Message Attributes

Select the adapter-specific message attributes in the receiver adapter.

The attributes are read from a message and used instead of a static parameter from the adapter configuration.

For more information, see the Adapter-Specific Message Attributes:

Configuring the Receiver Plain HTTP Adapter in the Integration Directory

Configuring the Receiver File Adapter

Configuring the Receiver FTP Adapter

Configuring the Receiver JMS Adapter

Configuring the Receiver SOAP Adapter

Configuring the Receiver Mail Adapter

Configuring the Receiver RNIF 1.1 Adapter for Requests

Configuring the Receiver RNIF 2.0 Adapter for Requests

03. Message attributes are listed in the message header DynamicConfiguration in message monitoring.

More information about monitoring in the Integration Engine: Displaying XML Message Versions.

Security-Related TasksProcedure

Encrypting Message Content on Database Level

Configuring Principal Propagation

Enabling Virus-Scanning of Messages

Encrypting Message Content on Database Level

To increase data security, you have the option of encrypting the payload (and any attachments) of messages at the database level. This means that all messagesconfigured in this way are stored in the message database encrypted. Users that query the message database, for example using SQL, cannot read the contentof the payload.

Message payload and attachments is abbreviated to message content throughout this documentation.

You can use this feature if you run scenarios that involve the exchange of sensitive data and you want to prevent malicious users from accessing this data.

For more information on how this function is related to the Payment Card Industry – Data Security Standard (PCI-DSS), see: Using SAP NetWeaver PI inPCI-Compliant Scenarios.

The encryption of the message payload at the database level has the following characteristics:

It can be activated for specific service interfaces.

This means encryption can be activated for specific scenarios that include the exchange of sensitive business data.

It affects the complete payload of the message.

When you activate encryption for a service interface, the complete payload will always be stored encrypted.

Note that encryption of the message payload in the database does not affect how the message content is displayed in monitoring.

Encryption is supported for messages stored in both the Advanced Adapter Engine message database and in the Integration Engine message database.

Limitations

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 65 of 130

If you plan to use this feature, consider the limitations summarized under Encrypting Message Content on Database Level (Limitations).

Procedure

You can configure message payload encryption at the database level for the different kinds of message processing that are supported by the available installationoptions. In particular, these are the following options:

Dual-stack message processing

In scenarios of this kind both the Integration Engine and the Advanced Adapter Engine (AAE) are involved in message processing at runtime.

Scenarios of this kind are only possible with a dual-stack PI installation.

Message processing using AAE only

In scenarios of this kind only the Advanced Adapter Engine (AAE) is involved in message processing at runtime.

Scenarios of this kind can be implemented either as local message processing using a dual-stack implementation or when using the Advanced AdapterEngine Extended (AEX).

For more information on these options, see Installation Options.

The individual configuration procedure depends on the involved components. This is the general procedure.

There are two examples below.

01. Configuring service interfaces (applicable for dual-stack or AAE-only message processing)

Indicate the service interfaces in the Enterprise Services Repository for which message encryption should be activated.

More information: Configuring Service Interfaces for Encryption (ES Repository)

02. Configuring Advanced Adapter Engine (applicable for dual-stack or AAE-only message processing)

You need to configure message encryption in the AAE.

More information: Encrypting Message Content on Database Level (AAE)

03. Configuring central Integration Engine (applicable only for dual-stack message processing)

You need to configure message encryption in the central Integration Engine (IE) that is part of the Integration Server.

More information: Encrypting Message Content on Database Level (Central IE)

04. Configuring business systems with local Integration Engines (applicable for dual-stack or AAE-only message processing)

If the scenario involves business systems with a “local” Integration Engine, you need to perform additional configuration steps in the connected back-endsystems.

More information: Encrypting Message Content on Database Level (Local IE)

05. Configuring message processing in the Integration Directory (applicable for dual-stack or AAE-only message processing)

Proceed as described under Setting up Scenarios Using Dual-Stack Message Processing or Setting Up Scenarios Using Local AAE-BasedMessage Processing (in section 2. Configure Integration Content).

Also note the following:

Make sure that the relevant service interfaces specified as sensitive are assigned to the involved communication components. If you are using businesscomponents, you need to assign the relevant service interfaces manually.

Note these general recommendations on how to handle keys:

Be careful if you plan to delete keys. If you have deleted a key, a message (that has been stored encrypted) remains in the database but can no longer beopened. Do not rename keys during productive scenarios.

Configuration Tasks for Different System Landscapes

The configuration procedure and the involved configuration tools depend on the involved components at runtime. The following figure illustrates a possible setup ofcomponents when using dual-stack message processing.

Note

Note

Recommendation

PUBLIC© 2012 SAP AG. All rights reserved.

Page 66 of 130

Setup of Components when Using Dual-Stack Message Processing

In the illustrated setup an adapter of the AAE is used to connect the PI instance to a system that is not specified in more detail. The Integration Engine is used toconnect the PI instance to an SAP system (via the XI adapter).

To configure message encryption for this setup, you need to perform the following configuration tasks:

Configuring service interfaces for encryption (as described under Configuring Service Interfaces for Encryption)

Configuring the AAE (as described under Encrypting Message Content on Database Level (AAE))

Configuring the (“central”) Integration Engine hosted on the PI instance (as described under Encrypting Message Content on Database Level (Central IE))

Configuring the “local” Integration Engine in the connected SAP system (as described under Encrypting Message Content on Database Level (Local IE))

The following figure illustrates a possible setup of components when only the AAE is involved in message processing .

Setup of Components when Using AAE-Only Message Processing

In the illustrated setup, an SAP system is also connected to the PI instance based on the XI message protocol (configured in the SOAP adapter).

To configure message encryption for this setup, you need to perform the following configuration tasks:

Configuring service interfaces for encryption (as described under Configuring Service Interfaces for Encryption)

Configuring the AAE (as described under Encrypting Message Content on Database Level (AAE))

Configuring the “local” Integration Engine in the connected SAP system (as described under Encrypting Message Content on Database Level (Local IE))

Encrypting Message Content on Database Level (Limitations)

To increase data security, you have the option of encrypting the payload (and any attachments) of messages at the database level. This means that all messagesconfigured in this way are stored encrypted in the message database. Users that query the message database, for example using SQL, cannot read the contentof the payload.

PUBLIC© 2012 SAP AG. All rights reserved.

Page 67 of 130

of the payload.

Consider the following limitations if you plan to use this feature:

Parts of a message cannot be encrypted individually.

The complete payload of a message is always encrypted in the database.

Masking of individual fields (for example, Primary Account Number) is not supported.

Re-encryption of messages is not supported.

Administrators cannot re-encrypt messages that have already been stored. Re-encryption means: a message that has already been encrypted is decryptedand thereafter encrypted with a new key.

Furthermore, administrators cannot initiate automatic re-encryption of messages that have already been stored.

To overcome this limitation, administrators can manually redeliver affected messages or clean up the message database.

More information: Data Storage Security for the Advanced Adapter Engine, Data Storage Security for the Integration Engine

Applying message archiving can disable message encryption.

If an archiving solution is used that does not support encrypted data storage, this can lead to a situation in which configured message encryption at thedatabase level (as described in this section) is disabled. Administrators are recommended to evaluate the archive solution used in light of this limitation.

Scenarios using Business Process Management and cross-component Business Process Management are not fully supported.

Depending on the scenario, messages or message elements may be stored unencrypted in separate databases even if the message encryption is configuredaccording to the procedures in this section.

Encryption of logged synchronous messages is not supported in the Advanced Adapter Engine.

However, encryption of logged synchronous messages stored in the Integration Engine message store is supported.

Advanced (user-defined) message search on sensitive message elements is not supported.

If you define filters that include payload elements with sensitive data, be aware of the fact that these elements are stored unencrypted.

SAP NetWeaver Search and Classification (TREX) is not supported.

TREX stores messages unencrypted.

Message encryption at the database level is not fully supported for all SAP adapters and third-party adapters.

Adapters with their own message storage (for example, RNIF, CIDX adapter) do not support encrypted data storage if the message itself was not previouslyencrypted by the sender.

Only service interfaces can be marked as sensitive. Imported IDocs and RFCs cannot be marked as sensitive. Scenarios using those imported interfaces oneither sender or receiver side are currently not supported.

Configuring Principal Propagation

You can define that user identities are forwarded securely from a sender to a receiver by using an SAP NetWeaver Process Integration runtime engine (eitherIntegration Engine or Advanced Adapter Engine). You can define any number of communication routes between the sender and receiver. This is known asprincipal propagation.

User refers to a entity that can authenticate itself in a system when the security settings are configured appropriately and the necessary authorizations have beengranted. Note that the user name can be different in the sender and receiver systems. Principal propagation means that the identity of the user - and not their username - is forwarded.

Procedure

The procedure depends on the runtime engine used.

More information:

Configuring Principal Propagation Using the Integration Engine

Configuring Principal Propagation Using the Advanced Adapter Engine

Configuring Principal Propagation Using the Integration Engine

You can configure principal propagation using the Integration Engine (IE) interconnected between sender and receiver.

The following description always assumes that there is an Integration Engine located between the sender and the receiver.

Recommendation

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 68 of 130

You can configure principal propagation on the basis of the following authentication methods:

Authentication assertion ticket

This option is supported by the XI adapter.

Security Assertion Markup Language (SAML)

This option is supported by the Web service runtime (applications based on Web Service Reliable Messaging connected with the WS adapter).

Prerequisites

To enable the IE to support principal propagation, you need to perform technical configuration tasks.

More information: Configuring Principal Propagation (IE Technical Configuration)

Procedure

For more information, see:

Configuring Principal Propagation (Authentication Assertion Ticket)

Configuring Principal Propagation (SAML)

Configuring Principal Propagation (Authentication AssertionTicket)

You can configure principal propagation based on authentication assertion tickets.

Prerequisites

The sender and receiver adapters must be one of the following:

XI adapter

SOAP adapter

RFC adapter

Procedure

1. Configuring Back-End Systems Involved

First configure the involved back-end systems.

The basis of secure principal propagation is a trusted relationship between the involved back-end systems. You perform these steps separately in each back-end system.

2. Configuring in the Integration Directory

In the Integration Directory, specify between which entities principal propagation is to take place.

If you would like principal propagation to occur between a sender and a receiver using the Integration Server, perform the following steps:

01. Implement principal propagation from the sender to the Integration Server. In the corresponding sender agreement, on the Parameters tab page, underSettings for Principal Propagation select the Principal Propagation checkbox.

If this checkbox is selected, the signature of the sender ticket is verified and the corresponding user can log on to the Integration Server.

For more information, see: Defining Sender Agreements

02. Implement principal propagation from the Integration Server to the receiver. In the corresponding receiver agreement, on the Parameters tab page, underSettings for Principal Propagation select the Principal Propagation checkbox.

For more information, see: Defining Receiver Agreements

The checkbox is only displayed if you have assigned the sender or receiver agreement a communication channel with the appropriate adapter type (formore information, see Prerequisites).

Configuring Principal Propagation (SAML)

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 69 of 130

You can configure principal propagation based on Security Assertion Markup Language (SAML).

If you configure principal propagation based on SAML (version SAML 1.1), the user is authenticated based on a trust relationship. A password is requiredbecause the receiver system trusts the sender system using certificates and names.

Principal propagation based on the SAML 1.1 standard is supported for Web service runtime.

Prerequisites

For inbound and outbound processing on the Integration Server, use a communication channel to connect to the Web service runtime (default: Web ServicesReliable Messaging; communication channel: adapter type WS).

Procedure

1. Configuring Back-End Systems Involved

Define trust relationships between the back-end systems involved and execute the further configuration steps that are required in those back-end systems.

For more information, see: Configuring SSO with SAML Token Profiles

2. Configuring in the Integration Directory

In the Integration Directory use the following steps to specify between which entities principal propagation is to take place.

If you would like principal propagation to occur between a sender system and a receiver system using the Integration Server, perform the following steps:

01. Configure a business system each for the sender and receiver.

For more information, see: Configuring Business Systems

02. Implement principal propagation from the sender to the Integration Server.

Note that you must use a communication channel with adapter type WS for inbound message processing with the Integration Server.

Follow these steps.

01. Configure the sender channel.

Choose adapter type WS and the Sender radio button.

Implement the following authentication method to configure the channel (under Security Settings):

SAML 1.1 Sender Vouches Assertion (Message Authentication)

Implement further channel attributes.

For more information, see: Configuring the Communication Channel with Adapter Type WS

02. Create a sender agreement for the sender system and the outbound interface and assign the communication channel that you defined in the previous stepto the sender agreement.

For more information, see: Defining Sender Agreements

03. Activate the configuration objects.

03. Implement principal propagation from the Integration Server to the receiver.

Note that you must use a communication channel with adapter type WS for outbound message processing with the Integration Server.

Follow these steps.

01. Choose adapter type WS and the Receiver radio button.

Implement the following authentication method to configure the channel (under Security Settings):

SAML 1.1 Sender Vouches Assertion (Message Authentication)

Implement further channel attributes.

For more information, see: Configuring the Communication Channel with Adapter Type WS

02. Create a receiver agreement for the receiver system and the inbound interface and assign the communication channel that you defined in the previous stepto the receiver agreement.

For more information, see: Defining Receiver Agreements

03. Activate the configuration objects.

The procedure described assumes that you want to configure principal propagation for inbound and outbound channels of the Integration Server basedon SAML. You can also configure a scenario in which principal propagation is based on SAML for the inbound channel of the Integration Server and onauthentication assertion tickets for the outbound channel. In this case you must configure the outbound processing as described in PrincipalPropagation (Authentication Assertion Tickets) .

Caution

Caution

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 70 of 130

Enabling Virus-Scanning of Messages

The Virus Scan Interface that is part of SAP NetWeaver allows you to include external virus scanners in an SAP system and to scan files or documentsprocessed by SAP applications for viruses.

For more information, see SAP Library at http://help.sap.com under SAP NetWeaver Library: Function-Oriented View Security System Security Virus Scan Interface .

You can connect a Process Integration runtime engine (Integration Engine or Advanced Adapter Engine) to an external virus scanner using the Virus ScanInterface in order to activate virus scanning of both inbound and outbound messages.

By default, virus scanning of a message is limited to scanning attachments of the message for malicious data. Optionally, you can configure the ProcessIntegration runtime engines that way that the message payload in addition is scanned for malicious data.

Virus-scanning is supported by all adapters delivered by SAP. Note that, however, when you use WS protocol, virus scanning cannot be activated for directconnections.

Procedure

01. Configuring Virus Scan Interface

Configuration of the Virus Scan Interface is divided into tasks related to components based on Application Server ABAP and tasks related to componentsbased on Application Server Java.

For more information, see SAP Library at http://help.sap.com under SAP NetWeaver Library: Function-Oriented View Security SystemSecurity Virus Scan Interface Configuration of the Virus Scan Interface .

To configure Virus Scan Interface for Process Integration virus scanning, note the following:

The following transactions are available (AS ABAP): VSCANGROUP , VSCANPROFILE and VSCAN .

When configuring the Virus Scan Profile, select the scan profile: /SXMSF/PI_MESSAGING .

Make the following entries:

Profile Text: Process Integration Messaging

Use Reference: Select the Default Profile

Link: All steps successful

To configure the Virus Scan Profile (AS Java), logon to SAP NetWeaver Administrator and choose Configuraton Security Virus Scan Provider .

Select the scan profile: pi_Messaging .

Make the following entries:

Profile Description Process Integration Messaging

Reference Profile: Select the Default Profile

02. Global activation of virus scanning for the involved Process Integration runtime engines

Virus scanning can be configured for the Integration Engine (IE) or the Advanced Adapter Engine (AAE) or both. For more information, see: Virus-Scanning atRuntime.

The configuration settings specified for the runtime engines are referred to as global configuration settings, because they apply for all integration scenarios thatare executed on the basis of the chosen setup of business systems and runtime engines.

As default setting, virus scanning of inbound messages is proposed. However, you have the option to activate virus scanning for outbound messages inaddition.

Global virus scanning configuration for the IE

Follow the procedure described under Configuring Virus Scanning on the Integration Engine.

Global virus scanning configuration for the AAE

More information: Configuring Virus Scanning on the Advanced Adapter Engine.

03. Scenario-specific activation of virus scanning

You can specify for which messages as part of a specific scenario virus scanning should be applied. You perform this task by specifying the correspondingconfiguration object in Integration Directory. Which configuration objects need to be edited depends on the type of message processing.

For dual-stack message processing you can configure virus scanning of messages for specific scenarios that are covered by a sender or receiveragreement.

More information:

Defining Sender Agreements

Defining Receiver Agreements

For message processing using the Advanced Adapter Engine only, you can configure virus scanning of messages for specific scenarios that are coveredby an integrated configuration.

More information: Defining the Integrated Configuration

In each cases, you need to choose the favored option under Virus Scan.

You can choose between the following options:

Using global configuration

Select this value to choose the global configuration as specified for the Integration and/or the Advanced Adapter Engine.

Enabling virus scanning for the selected configuration object

PUBLIC© 2012 SAP AG. All rights reserved.

Page 71 of 130

Select this value to enable virus scanning for the messages specified by the configuration object.

Disabling virus scanning

Select this value to disable virus scanning for the messages specified by the configuration object.

Virus-Scanning at Runtime

SAP NetWeaver PI includes different runtime engines and therefore allows you to configure different types of message processing (either dual-stack or AdvancedAdapter Engine only) and connectivity options, as described under Runtime.

Furthermore, adapters run on either the Integration Engine (IE) or the Advanced Adapter Engine (AAE). Virus scanning on the other hand can be configured foreither inbound or outbound messages or both. For example, when you configure virus scanning for inbound messages, a virus scanning step has to be executedprior to pipeline processing within the involved runtime engine.

For which runtime engine virus scanning needs to be activated, therefore depends on the chosen message processing type and connectivity option.

The following figure shows where virus scanning step for both the IE and the AAE is located for all possible cases.

Localization of Virus Scanning Steps at Runtime

Note that branches (where a decision is taken) are indicated as white rhombuses, whereas joints (where two message processing paths are merged) areindicated as grey rhombuses.

The following applies for the location of the virus scan step:

Inbound virus scanning is always executed in that runtime engine where sender adapter processing is performed (before inbound XML validation step).

Outbound virus scanning in dual-stack scenarios is always executed on the IE (after the mapping step).

From the explanations above, the following rules can be derived for dual-stack message processing:

Inbound virus scanning has to be activated for that runtime engine on which sender adapter processing is executed.

Outbound virus scanning has to be activated for both runtime engines, independent of which runtime engine receiver adapter processing is executed.

For AAE-only message processing it is evident that virus scanning only needs to be activated for the AAE.

The following figure illustrates an example of dual-stack message processing with an AAE adapter used at both sender and receiver side and virus scanningconfigured for both inbound and outbound messages. Although sender and receiver adapter processing is executed on the AAE only, outbound virus scanning

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 72 of 130

has also to be activated for the IE.

Dual-Stack Message Processing with Virus Scanning

Configuring B2B Integration

Several companies or business partners are typically involved in a B2B process. Each of these bases their configuration of the B2B process on the informationavailable to them. For example, make business partner details known using your internal system landscape, not outwardly.

To keep things simple, the description below assumes a situation that involves one business process and two business partners. One of the business partnersinvolved uses SAP NetWeaver PI and performs the B2B configuration in the Integration Directory. The second business partner can also use SAP NetWeaver PIand perform a similar (mirror-image) configuration in their Integration Directory. However, they can also use a different integration tool.

This section describes the steps taken by one of the business partners in the Integration Directory.

Prerequisites

Ideally, you have mapped the B2B integration in the Enterprise Services Repository using a process model (process component interaction model or processintegration scenario). In the Integration Directory this enables you to automate much of the configuration of collaboration agreements and logical routing using themodel configurator. However, you must define the collaboration profile manually.

If there are no process models that you can use as the configuration template, you need to create all configuration objects manually.

Procedure

Configure Collaboration Profile

In this step you define the required communication parties, communication components, and communication channels.

To define the collaboration profile, perform the following steps:

01. In the Integration Directory, create a communication party for each business partner involved in the process.

02. Create a communication component of type Business System for each business system in your internal system landscape.

03. Create the required business components.

Business partners involved in B2B processes do not generally make the names of their internal business systems known externally, but instead maskthem by using business components.

Assign the business components that your business partner provided for external communication to the communication party that represents this externalbusiness partner.

Assign the business components that represent your own internal system landscape externally to the communication party that represents your owncompany.

04. Create the required communication channels.

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 73 of 130

You need one communication channel for each adapter involved. Depending on whether the adapter is a sender adapter or a receiver adapter, you create thecommunication channel for the relevant sender or receiver communication component as required.

Configure Communication Channels with Industry Standard Adapters

At least one of the involved business partners uses an industry standard adapter (such as the RNIF adapter) to connect to the message protocol supported by therespective industry standard.

In this step, you configure the involved industry standard adapter using the corresponding communication channels.

For information about the values you have to enter for the parameters of the communication channel, see the configuration guide for the respective industry-standard-specific SAP business package.

More information: Setting Up Integration Based on SAP Business Packages

Configure Sender and Receiver Agreements

In this step you configure the required sender and receiver agreements. In a sender and receiver agreement you assign the required communication channels tothe relevant sender/receiver pairs. You also specify the agreed security settings (if they are supported by the adapters used).

Perform the following steps:

01. Create a sender agreement for each sender/receiver pair that requires a sender adapter for inbound processing.

Note, however, that you do not always need to define a sender agreement.

More information: Defining Sender Agreements

02. Create a receiver agreement for each sender/receiver pair that requires a receiver adapter for outbound processing.

Define a header mapping for the receiver agreements that describe the communication with your external business partner. This ensures that the name of abusiness component (and not the name of a business system or an integration process component) is written in the header of the outbound message atruntime.

More information:

Defining Receiver Agreements

Define Header Mappings

03. Specify the required security settings in the relevant sender and receiver agreements.

Configure Logical Routing

In this step you define the logical routing.

In logical routing you define:

The required receiver determinations

In a B2B process, specify receiver-dependent receiver determinations for all messages that are to be sent from your business partner to the businesscomponents that you published. As the configured receivers, specify the business system components of your internal system landscape to which themessage is to be forwarded.

More information: Defining Receiver Determinations

The required interface determinations

More Information

B2B Configuration

Configuring B2B Scenarios Using the Model Configurator

Developing and Configuring Web Service Scenarios

SAP NetWeaver PI supports connectivity between the Web service provider and the Web service consumer.

The Web service provider and consumer can communicate based on one of the following patterns:

Mediated (or “Brokered”) Communication

Between Web service provider and consumer SAP NetWeaver PI is interconnected as integration middleware.

In this case, the mediation capabilities of SAP NetWeaver PI can be used for routing and mapping.

To configure this kind of communication, you can use communication channels with either adapter type SOAP or WS (for connectivity with applicationsbased on Web Services Reliable Messaging (WS-RM)).

Note that the SOAP adapter does not support WS-RM, but does provide proprietary means to deliver messages according to the Qualities of ServiceExactly One and Exactly Once in Order.

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 74 of 130

The adapter that you can use depends on the installation option. For example, if you have installed the Advanced Adapter Engine Extended then you canuse the communication channel with adapter type SOAP which runs on the Advanced Adapter Engine (but not adapter type WS).

Direct Communication

The Web service provider and consumer communicate with each other directly.

The following figure illustrates the two different communication types:

Integration Server-Based Communication (Top) and Direct Communication (Bottom)

Procedure

To develop and configure Web service scenarios, you generally adhere to the following procedure:

Mediated (or “Brokered”) Communication

Web Service Provider

When you set up and configure this part of the communication, the Integration Server (or Advanced Adapter Engine) can be viewed as Web service consumer.

01. Design the inbound service interface in the Enterprise Service Repository (ES Repository).

02. Configure the inbound service interface in the Integration Directory.

03. Create the Web service (inbound proxy).

04. Configure the Web service.

Web Service Consumer

When you set up and configure this part of the communication, the Integration Server (or Advanced Adapter Engine) can be viewed as Web service provider.

01. Design the outbound service in the Enterprise Service Repository.

02. Configure the outbound service interface in the Integration Directory.

03. Create a Web service-deployable proxy and a client application.

04. Configure the Web service consumer.

For information on how to perform the individual tasks (for example, service interface design) in detail, see the corresponding section under Developing andConfiguring Integration Scenarios for the corresponding installation option.

As an example for an end-to-end procedure for the cases the Web service provider and consumer are based on AS Java, see section below.

Direct Communication

More information: Setting Up Direct Communication

Mediated Communication Between Provider and Consumer (Based on AS Java)

The following sections provide specific information on how to develop and configure Web service consumers and providers based on Application Server Java inorder to communicate in the scenarios described above:

End-to-end procedure for developing and configuring Web service provider and consumer in order to communicate with an Integration Server:Web ServiceProviders and Consumers for Brokered Communication

End-to-end procedure for developing and configuring Web service provider and consumer if the interface pattern XI 3.0-Compatible is selected: Creating andConfiguring XI 3.0-Compatible Web Service Providers

More Information

Web Services Reliable Messaging

Setting Up Direct Communication

PUBLIC© 2012 SAP AG. All rights reserved.

Page 75 of 130

Procedure

To configure direct communication, you configure the relevant settings locally in the back-end systems of the Web service provider and Web service consumerthat are involved.

For systems based on AS ABAP, you generally use the SOA Manager.

You can access the SOA Manager by using the transaction code SOAMANAGER in the back-end system.

More information: Working with the SOA Manager

For systems based on AS Java, you generally use the SAP NetWeaver Administrator.

SAP NetWeaver Administrator is the administration tool for Java-based back-ends involved in integration scenarios.

You can access the SAP NetWeaver Administrator by entering the following data in a Web browser:

http://<host><port>/nwa

Here the following represents:

<host> the host where the Application Server Java is installed.

<port> the HTTP port of the Internet Communication Manager. It consists of 5<Java instance_number>00 . For example, if the instance number ofthe Java instance is 60 , the HTTP port is 56000 .

If the Web service provider and consumer are both based on AS ABAP 7.1 or a higher release, you can perform the configuration of the direct communicationcentrally in the Integration Directory, using a direct connection object (with an assigned sender channel of type WS).

You can use communication channels with adapter type WS only when you have chosen the SAP NetWeaver PI standard installation option. The reason isthat this connectivity option is only supported by the Integration Engine.

More information: Connectivity

The configuration settings are propagated into the back-end systems by a caching mechanism, therefore making local configuration unnecessary.

More information: Configuring Direct Communication

Creating and Configuring XI 3.0-Compatible Web ServiceProviders and Consumers for Brokered Communication

When you have created an XI 3.0-Compatible Service Interface (SI) in the Enterprise Services Repository (ESR), you can create and configure Web serviceproviders and consumers which use the Integration Server (IS) as a broker. The Java Web service providers and consumers communicate with the IS over an XI3.0 protocol by using the Java Proxy Runtime and the Web Service Runtime.

More Information about the Java Proxy runtime: Java Proxy Runtime

Procedure

Create and configure a synchronous or an asynchronous Web service provider (XI 3.0-compatible inbound proxy) for brokered communication.

Caution

PUBLIC© 2012 SAP AG. All rights reserved.

Page 76 of 130

In this case, the IS can be viewed as a service consumer.

More information: Creating and Configuring Web Service Providers

Create and configure a synchronous or an asynchronous Web service consumer (XI 3.0-compatible outbound proxy) for brokered communication.

In this case, the IS can be viewed as a service provider.

More information: Creating and Configuring Web Service Consumers

Creating and Configuring Web Service Providers

When you provide Web services using the Integration Server (IS) as a broker between the provider and the consumer side, the communication flow goes throughdifferent stages. To invoke a Web service method on the provider side, the IS sends a relevant message request to the service provider. Initially the request sentfrom the IS is an XI-specific message. However, the Java Proxy Runtime (JPR) transmits the message to the Web service runtime and the Web service runtimein turn converts the message to a SOAP message and thus makes it comprehensible to the Java Web service.

The figure below describes the different stages of the communication flow from the request of the IS to the provider side.

Each XI message that comes from the IS comprises payload, attachments, and specific XI data. The Java Web service runtime uses the payload to create therelevant SOAP message which invokes the business methods on the Web service. It also uses SAP-specific application program interfaces to retrieve theattachments, and to expose the specific XI data from the request (XI-specific message) to the provider.

Procedure

Create an inbound proxy. In this case, the IS can be viewed as a service consumer.

01. Create a synchronous or an asynchronous Java Web service provider (inbound proxy) for brokered communication.

Creating Web Service Providers for Brokered Communication

02. Extend the inbound proxy capabilities by using the application program interfaces for inbound proxy communication.

Application Program Interface for Inbound Proxy Communication

Creating Web Service Providers for Brokered Communication

When a Web service provider uses the Integration Server as a broker, the provider receives requests directly from the Integration Server. Then the providerprocesses these requests, and if necessary sends its response to the Integration Server. The Integration Server in turn delegates the response to thecorresponding service consumer.

You create synchronous or asynchronous Web service providers by using XI 3.0 Compatible service interface.

Procedure

PUBLIC© 2012 SAP AG. All rights reserved.

Page 77 of 130

01. Design the service interface in the Enterprise Service Repository.

In the Enterprise Service Builder, design an inbound service interface. The inbound service interface comprises interface pattern stateless, synchronous orasynchronous operations, message types, data types, and fault types.

More information:

Service Interface

Interface Pattern

Message Type

Fault Message Type

02. Create the Web service provider (inbound proxy).

In the SAP NetWeaver Developer Studio, proceed as follows:

01. Import the WSDL document from the ESR.

More information: Importing WSDL Documents in the SAP NetWeaver Developer Studio.

02. Create an outside-in Web service based on the WSDL document of the relevant inbound Service Interface modeled in the ESR. The Web serviceframework generates the skeleton of the implementation bean containing the Web service methods' declarations for the operations in the WSDL document.

More information about creating an outside-in Web service: Creating Outside-In Web Services.

03. Add the following XI related class level annotation in the source code of the Web service provider bean implementation: @XIEnabled()

If you import an XI-specific WSDL document from the ESR, the Web service framework adds the @XIEnabled()design time annotation automatically.However, if the WSDL document is not XI-specific, you can add the annotation manually and thus enable the inbound proxy for XI communication.When you add the @XIEnabled() design time annotation and deploy the inbound proxy, the server reports to the Web service runtime framework thatthis is an XI-specific proxy. Then, the runtime uses an XI-specific transport during the communication with the Integration Server. However, if theinbound proxy is not annotated with @XIEnabled() annotation, the server considers it a regular Java EE 5 proxy and the runtime uses SOAP transportas a communication mechanism.

04. Add the following transport specific class level annotation in the source code of the Web service bean implementation:

01. @TransportBindingRT(AltPath="{>service_interface_namespace<} >service_interface_local_name<")@TransportBindingRT(AltPath="{ns} name")

At a later stage, the system uses this value as a service endpoint URL to access the business logic in the inbound proxy.

More information about the @TransportBindingRT() annotation:

Configuring URLs for Web Service Endpoints

Configuring Web Services at Design Time

For Web services with asynchronous operations, add the following WS-RM related annotation in the source code:@RelMessagingNW05DTOperation(enableWSRM=true)

05. Provide an implementation of the business methods of the Web service.

06. Deploy the Web service on the application server.

For more information, see Building, Publishing and Removing Published Java EE Applications.

The Web service you deployed would not be listed in the WSIL resource provided by AS Java. For more information, see Accessing InformationProvided via WSIL.

Application Program Interface for Inbound Proxy Communication

You use the following SAP-specific interface pattern to examine the XI-specific data capsulated in the request XI message.

ProviderXIMessageContext

Extension interface name

com.sap.engine.services.webservices.espbase.server.additions.xi.ProviderXIMessageContext

Interface methods

Note

Syntax

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 78 of 130

01. //Returns an instance of ProviderXIMessageContext which is a singleton ProviderXIMessageContext getInstance(); //Returns property value mapped to the specified key Object getProperty(String key); // Determines the name of a communication party of a message received at the receiver String getSenderPartyName(); //Returns request XI message application acknowledgement listener name String getApplicationAckRequested(); //Returns request XI message system acknowledgement listener name String getSystemAckRequested(); //Returns request XI message application error acknowledgement listener name String getApplicationErrorAckRequested(); //Returns request XI message system error acknowledgement listener name String getSystemErrorAckRequested(); // Determines the service of a message received at the receiver String getSenderService(); //Returns request XI message queue id String getQueueId(); // Determines the service of a message received at the receiver QName getServiceInterfaceName(); //Identifies whether the XI request is asynchronous boolean isAsync();

Creating and Configuring Web Service Consumers

When you consume services using the Integration Server (IS) as a broker between the provider and the consumer side, the communication flow goes throughdifferent stages. To invoke a Web service method on the provider side, the consumer application has to send a relevant message request to the IS. Initially thisrequest is a SOAP message; however, the Web service runtime and the Java Proxy Runtime (JPR) convert this message to an XI-specific one and thus make itcomprehensible to the IS. Subsequently, the JPR sends this XI message to the IS, and then the server sends it in turn to the provider side. The role of the IS is toestablish proper communication with any service provider. For example, service providers can be Web services, JMS Providers, RFC calls, or others.

The figure below describes the different stages of the communication flow from the request of the consumer application to the IS.

Each XI message comprises SOAP XML payload (serialized content of the operation and its parameter values), attachments, and specific XI data. The runtimeuses SAP-specific application program interfaces to create the attachments and to configure the specific XI data.

Procedure

01. Create a Web service consumer (outbound proxy) for brokered communication. In this case, the IS can be viewed as a service provider.

More information:

Create a synchronous or an asynchronous Java Web service consumer for brokered communication.

Creating Web Service Consumers for Brokered Communication

Syntax

PUBLIC© 2012 SAP AG. All rights reserved.

Page 79 of 130

To enable XI 3.0 communication with the IS, extend the outbound proxy capabilities by using the application program interfaces for outbound proxycommunication.

Application Program Interfaces for Outbound Proxy Communication

02. Configure the outbound proxy.

More information:

Configure the synchronous or asynchronous Java Web service consumer for brokered communication.

Configuring Web Service Consumers for Brokered Communication

Creating Web Service Consumers for Brokered Communication

You create synchronous or asynchronous Web service consumers by using the XI 3.0-Compatible service interface.

Procedure

01. Design the service in the Enterprise Service Repository.

In the Enterprise Service Builder, design an outbound service interface. The outbound service interface comprises the interface pattern XI 3.0-compatible,synchronous or asynchronous operations, message types, data types, and fault types.

More information:

Service Interface

Interface Pattern

Message Type

Fault Message Type

02. Create a Web service deployable proxy and a client application. In the SAP NetWeaver Developer Studio, proceed as follows:

01. Import the WSDL document from the ESR.

More information: Importing WSDL Documents in the SAP NetWeaver Developer Studio.

02. Generate a deployable proxy based on the WSDL document of the relevant outbound Service Interface modeled in the ESR. More information: CreatingWeb Service Proxies.

03. Create a consumer application which uses the deployable proxy you generated.

In the client application, you specify the endpoint URL of the Web service port, a user name and a password to the PI Adapter Engine. Once you createthe consumer application, it uses the generated Web service proxy to send requests to the Web service runtime and the Java Proxy Runtime. You canalso insert XI specific application program interfaces (APIs) in the consumer application to enable XI specific outbound calls.

More information: Creating Web Service Client Applications, Application Program Interfaces for Outbound Proxy Communication

04. Deploy the Web service consumer. More information: Building, Publishing and Removing Published Java EE Applications.

Application Program Interfaces for Outbound ProxyCommunication

You use the following SAP-specific interface patterns to extend the control of the applications over the outbound proxy runtime. You useXIManagementInterfaceFactory, XIManagementInterface, and XIMessageContext to enable the Java WS outbound proxies for XI message communication. Youcan use the above APIs to enable XI communication via Java Proxy Runtime (JPR).

More information about JPR: Java Proxy Runtime.

XIManagementInterfaceFactory

Factory class name

com.sap.engine.services.webservices.espbase.client.api.XIManagementInterfaceFactory

Factory methods

01. //Creates an implementation of XIManagementInterface for the specified port. XIManagementInterface create(Object port);

XIManagementInterface

Syntax

PUBLIC© 2012 SAP AG. All rights reserved.

Page 80 of 130

This is an interface pattern which provides extended control over the XI management of the outbound proxies.

Extension interface name

com.sap.engine.services.webservices.espbase.client.api.XIManagementInterface

Factory class name

com.sap.engine.services.webservices.espbase.client.api.XIManagementInterfaceFactory

Interface methods

01. //Configures the type of the Java runtime transport: XI or SOAP void useXITransport(boolean useXICommunication); //Returns the type of the Java runtime transport, true identifies an XI transport boolean getUseXITransport(); //Returns request XI message context XIMessageContext getRequestXIMessageContext(); //Configures an implementation of interface ESPXIMessageProcessor. This implementation //represents the XI transport and is used by the Java runtime to communicate with //the IS in an XI manner (with XI messages). This method can be used for testing purposes. void setESPXIMessageProcessor(ESPXIMessageProcessor xiMessageProcessor); //Returns the implementation of the interface ESPXIMessageProcessor which is used by the Java //runtime for performing an XI communication ESPXIMessageProcessor getESPXIMessageProcessor();

XIMessageContext

This is an interface pattern which provides extended control over the XI messages.

Extension interface name

com.sap.engine.services.webservices.espbase.client.api.XIMessageContext

Factory class name

com.sap.engine.services.webservices.espbase.client.api.XIManagementInterfaceFactory

Interface methods

01. //Configures application acknowledgement listener name void setApplicationAckRequested(String ackListenerName);//Configures system acknowledgement listener name void setSystemAckRequested(String ackListenerName);//Configures application error acknowledgement listener name void setApplicationErrorAckRequested(String ackListenerName);//Configures system error acknowledgement listener name void setSystemErrorAckRequested(String ackListenerName);//Configures sender party name void setSenderPartyName(String senderPartyName);//Configures sender service name void setSenderService(String senderService);//Configures queue id void setQueueId(String queueId);//Adds a receiver void addReceiver(String receiverPartyName, String receiverPartyAgency,String hreceiverPartyScheme, String receiverService);//Removes all receivers void clearReceivers();

The table below explains the usage of the XIMessageContext methods.

Syntax

Syntax

PUBLIC© 2012 SAP AG. All rights reserved.

Page 81 of 130

Value Description

void setApplicationAckRequested(StringackListenerName);

This method requests positive application acknowledgment and verifies that the receiver processes the messagesuccessfully.The value of ackListenerName is the JNDI name of the acknowledgement listener bean.

void setSystemAckRequested(StringackListenerName);

This method requests positive system acknowledgement and verifies that the receiver is reached successfully.For provider proxies, this means that the implementing class for the provider proxy can be found and the methodfor inbound processing can be requested.The value of ackListenerName is the JNDI name of the acknowledgement listener bean.

voidsetApplicationErrorAckRequested(StringackListenerName);

This method requests negative application acknowledgment and indicates if an error occurred during messageprocessing at the receiver.The value of ackListenerName is the JNDI name of the acknowledgement listener bean.

void setSystemErrorAckRequested(StringackListenerName);

This method requests negative system acknowledgment and generates messaging runtime reports that an errorhas occurred during transfer or processing of the message on its way to the receiver. For example, an error in amapping program or a missing provider proxy in the receiver system could trigger this acknowledgment.The value of ackListenerName is the JNDI name of the acknowledgement listener bean.

void setQueueId(String queueId); This method enables you to assign a serialization context to multiple messages and to guarantee the quality ofservice exactly once in order.The string queueId is upper case-sensitive and can be maximum 16 characters long.All asynchronous messages with the same serialization context are received in the same order at the receiverside as they were entered in the outbound queue during the commit job of the sender side.

void addReceiver(StringreceiverPartyName, StringreceiverPartyAgency, StringreceiverPartyScheme, StringreceiverService);

This method adds a receiver to the set of all receivers in the consumer proxy. You must specify thecommunication party, the issuing agency, and the identification scheme in cross-company communication.

void clearReceivers(); This method deletes all specified receivers.

Configuring Web Service Consumers for BrokeredCommunication

After you create and deploy your outbound proxy on the application server, you enable it for communication by configuring a logical port to it. You provide theruntime configuration of the Web service consumers using the SAP NetWeaver Administrator.

Prerequisites

You have created and deployed the outbound proxy on your client system.

More information: Creating Web Service Consumers for Brokered Communication.

Procedure

01. Configure the Web service consumer. In the SAP NetWeaver Administrator, create a runtime configuration called logical port of the Web service consumer.

You can create a logical port based on a WSDL URL which determines the destination to which the Web service consumer sends its requests. In this case,the destination is the Integration Server. Therefore, you have to create the logical port based on the WSDL URL which you obtained from the IntegrationDirectory at a previous step. The logical port you create also contains the runtime configuration settings, such as user name and password, or WS-RMparameters which the Web service consumer uses.

More information about configuring the Web service consumer: Configuring Individual Web Service Clients.

More information about the underlying concepts for the configuration of Web service consumers in the SAP NetWeaver Administrator: Configuration ofIndividual Web Services and Web Service Clients.

02. Configure the Java Proxy Runtime (JPR).

Configure the isWSProxy property of the JPR.

More information: Using Java Proxy Runtime for Communication of Web Service Applications with PI

More information about the underlying concepts: Java Proxy Runtime.

Web Service Providers and Consumers for BrokeredCommunication

When you create a service interface (SI) in the Enterprise Services Repository, you can use it as a base to create applications for AS Java. These applications –Web service providers and Web service consumers – use the Integration Server (IS) as a broker as shown in the figure below.

PUBLIC© 2012 SAP AG. All rights reserved.

Page 82 of 130

The Web service providers and consumers can communicate with the IS over the Web service protocol by using the PI WS adapters. You can use this adapterboth for synchronous and asynchronous communication.

Prerequisites

The service interface is available in the Enterprise Services Repository.

Procedure

Use a synchronous or asynchronous Web service provider for brokered communication. In this case, the IS can be viewed as a service consumer. For moreinformation, see Web Service Providers for Brokered Communication.

Create and configure a synchronous or asynchronous Web service consumer for brokered communication. In this case, the IS can be viewed as a serviceprovider. For more information, see Web Service Consumers for Brokered Communication.

Web Service Providers for Brokered Communication

When a Web service provider uses the Integration Server (IS) as a broker, the provider receives requests from the IS. Then the provider processes theserequests, and if necessary sends its response to the IS. The IS in turn sends the response to the corresponding service consumer.

You can create synchronous and asynchronous Web service providers using adapter type PI WS .

Procedure

01. Design the service interface in the Enterprise Service Repository (ES Repository).

In the Enterprise Service Builder, design an inbound service interface. The inbound service interface comprises interface pattern stateless, operations,message types, data types, and fault types. For more information, see Service Interface, Interface Pattern, Message Type, and Fault Message Type.

02. Configure the service interface in the Integration Directory.

In the Integration Builder, create the following components to configure the service interface communication between the provider system and the IS:

Create a receiver communication component to define details about inbound processing and enable communication between the Web service provider andthe IS.

Create a receiver communication channel. In particular, you use a communication channel to define the type and configuration of the adapter used duringinbound processing. For more information, see Defining Communication Channels.

Create receiver determination and receiver agreement.

A receiver agreement contains a reference to a communication channel. You define a receiver agreement between a sender and a receiver for an inboundinterface. For more information, see Defining a Receiver Agreement and Defining Receiver Determinations.

Optionally, you can create a receiver party. For more information, see Defining Communication Parties.

03. Create the Web service (inbound proxy) in SAP NetWeaver Developer Studio:

01. Import the WSDL document from the ES Repository. For more information, see Importing WSDL Documents in the SAP NetWeaver DeveloperStudio.

02. Create an outside-in Web service based on the WSDL document of the relevant inbound Service Interface modeled in the ES Repository.

The Web service framework generates the skeleton of the implementation bean containing the Web service methods' declarations for the operations in theWSDL document. For more information about creating an outside-in Web service, see Creating Outside-In Web Services.

03. Provide an implementation of the business methods of the Web service.

04. Only for asynchronous Web services, add the following WS-RM-related annotation in the source code:@RelMessagingNW05DTOperation(enableWSRM=true)

05. Deploy the Web service on the application server. For more information, see Building, Publishing and Removing Published Java EE Applications.

04. Configure the Web service.

In the Integration Builder, configure the receiver communication channel you created in step 2 above. The receiver communication channel is a target URLthat points to the URL of the Web service.

For asynchronous Web services, you can construct the target URL using the following pattern: http://[Host]:[Port]/[Service_Access_Path]?wsdl&mode=ws_policy

In SAP NetWeaver Administrator, create a runtime configuration (called service endpoint ) of the Web service.

It contains the relevant runtime settings, such as authentication level, with which you want to provide the Web service.

PUBLIC© 2012 SAP AG. All rights reserved.

Page 83 of 130

For more information about configuring the Web service in the SAP NetWeaver Administrator, see Configuring Individual Web Services andConfiguration of Individual Web Services and Web Service Clients.

More Information

Integration Directory

Web Service Consumers for Brokered Communication

When a Web service consumer uses the Integration Server (IS) as a broker, the consumer sends its requests directly to the IS. The IS processes the requestsand sends them to the corresponding service provider.

You can create synchronous and asynchronous Web service consumers using adapter type PI WS.

Procedure

01. Design the service in the Enterprise Service Repository.

In the Enterprise Service Builder, design an outbound service interface. The outbound service interface comprises the interface pattern stateless, operations,message types, data types, and fault types. For more information, see Service Interface, Interface Pattern, Message Type, and Fault Message Type.

02. Configure the service interface in the Integration Directory.

In the Integration Builder, create the following components to configure the service interface communication between the consumer system and the IS:

Create a sender communication component to define details about outbound processing and enable communication between the Web service client and theIS.

Create a sender communication channel.

In particular, you can use a communication channel to define the type and configuration of the adapter used during outbound processing. For moreinformation, see Defining Communication Channels.

Create sender agreement and interface determination.

A sender agreement contains a reference to a communication channel. For more information, see Defining Sender Agreements and Defining anInterface Determination.

Optionally, you can create a sender party. For more information, see Defining Communication Parties.

03. Create a Web service deployable proxy and a client application in SAP NetWeaver Developer Studio:

01. Import the WSDL document from the Enterprise Service Repository. For more information, see Importing WSDL Documents in the SAP NetWeaverDeveloper Studio.

02. Generate a deployable proxy based on the WSDL document of the relevant outbound service interface modeled in the Enterprise Service Repository. Formore information, see Creating Web Service Proxies.

03. Create a client application that uses the deployable proxy you generated. Consider the following options:

When using synchronous communication, in the consumer application you should specify a URL to the Web service, a user name, and a password tothe PI Adapter Engine.

You can construct a URL to the Web service using the following pattern:http://[Adapterengine_Host]:[Port_Number]/XISOAPAdapter/MessageServlet?channel=[Sender_Party]:[Sender_Service]:[Sender_Channel]

For more information, see Configuring the Sender SOAP Adapter.

When using asynchronous communication, in the consumer application you specify username and password to the PI Adapter Engine.

For more information, see Creating Web Service Client Applications.

04. Deploy the Web service consumer on the application server. For more information, see Building, Publishing and Removing Published Java EEApplications.

04. Configure the Web service consumer.

01. In the Integration Builder, configure the sender communication channel you created in step 2 above.

The sender communication channel is a target URL that points to the URL of the Web service. You construct the target URL by using the following pattern:

When using synchronous communication, use http://[AdapterEngine_Host]:[Port_Number]/XISOAPAdapter/MessageServlet?channel=[Sender_Party]:[Sender_Service]:[Sender_Channel] .

When using asynchronous communication, use http://[Host]:[Port]/[Service_Access_Path]?wsdl&mode=ws_policy .

02. In SAP NetWeaver Administrator, create a runtime configuration (known as logical port) of the Web service consumer.

You can create a logical port based on a WSDL URL that determines the destination to which the Web service consumer sends its requests. In this case,the destination is the IS. Therefore, you have to create the logical port based on the WSDL URL that you obtained from the Integration Directory at a previousstep. The logical port you create also contains the runtime configuration settings, such as username and password, or WS-RM parameters, which the Webservice consumer uses.

For ore information about configuring Web service consumers, see Configuring Individual Web Service Clients and Configuration of IndividualWeb Services and Web Service Clients.

More Information

PUBLIC© 2012 SAP AG. All rights reserved.

Page 84 of 130

Integration Directory

Implementing and Generating Proxies in Application Systems

Proxies are non-language-specific interface descriptions in WSDL. The generation converts these descriptions into executable proxies in application systems.

Procedure

To generate proxies in an application system based on AS ABAP, use the ABAP proxy generation. Generation takes place in AS ABAP.

ABAP proxy runtime supports the WS and the XI protocol.

More information about XI runtime: XI-Specific ABAP Proxy Runtime Protocols

To generate proxies in an application system based on AS Java, use the Java proxy generation in SAP NetWeaver Developer Studio for new implementations.

More information: Creating and Configuring XI 3.0-Compatible Web Service Providers

You can still use the Java proxy generation in Integration Builder. However, it is no longer supported in subsequent releases.

More information: Java Proxy Objects (XI 3.0-Compatible)

More Information

Proxy Programming

Developing a Java Adapter for SAP NetWeaver PI

SAP NetWeaver PI installation delivers a sample adapter. You can use this adapter as a template for developing your own adapters. Find the tasks required tochange the sample adapter to your own adapter with a different adapter name and type, package name, deployment/JNDI name, trace and log file location, andconfiguration parameters. The step by step procedure shows you how you can use the com.sap.aii.adapter.sample.ra.rar adapter’s template to develop theYOURADAPTER adapter.

This description gives you an overview of the required tasks.

For more information about detailed instructions for adapter and module development, see: Developing Adapters and Modules

Procedure

01. Download the com.sap.aii.adapter.sample.ra.rar file.

02. Provide a different adapter name and type, package name, JNDI name, trace and log file locations, and the metadata describing the configuration parametersfor the sample_ra adapter’s Java program.

More information: Modifying the Java and Metadata Files

03. Change the configuration files used to build the RAR file.

More information: Modifying the Configuration Files for RAR

04. Include the Java code for the adapter.

05. Create the RAR file and deploy it to the AS Java.

More information: Creating and Deploying the Adapter

06. Test the adapter. For testing you need to create a communication component, sender and receiver communication channels, and an Integrated Configurationobject.

More information: Testing Your Adapter

Modifying the Java and Metadata Files

Provide a different adapter name and type, package name, JNDI name, trace and log file locations, and the metadata describing the configuration parameters forthe sample_ra adapter’s Java program.

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 85 of 130

Procedure

01. Download the com.sap.aii.adapter.sample.ra.rar file and extract the content of the com.sap.aii.adapter.sample.ra.jar file in to a temporary directory.

More information: Accessing JavaDoc and Source Text of the Example Adapter/Module

02. Change the file contents of all the files in com.sap.aii.adapter.sample.ra.jar. The files contain the package name/path of the sample_ra adapter. Changethem to your package/path names.

01. Change package name from com.sap.aii.af.sample.adapter.ra to com.test.YourAdapter.adapter.ra

02. Change package path for log and trace file locations from com/sap/aii/af/sample/adapter/ra to com/test/YourAdapter/adapter/ra

03. Change adapter guid from http://sap.com/xi/XI/sample/JCA to http://sap.com/xi/XI/YourAdapter/JCA

04. Change adapter namespace from http://sap.com/xi/XI/sample to http://sap.com/xi/XI/YourAdapter

03. Rename the file from SampleRA.xml to YourAdapterRA.xml

04. In SAP NetWeaver Developer Studio (NWDS), create the java project AdapterYOURADAPTER.

05. Create a package in the project com.test.YourAdapter.adapter.ra

01. Copy all file (except YourAdapterRA.xml) into project directory com/test/YourAdapter/adapter/ra

02. Copy YourAdapterRA.xml into root of project directory

06. In YourAdapterRa.xml (replace JNDI name) from deployedAdapters/sample_ra/shareable/sample_ra todeployedAdapters/YourAdapter_ra/shareable/YourAdapter_ra.

YourAdapterRa.xml contains the metadata for the adapter, for example configuration parameters such as file name and directory name.

07. Refresh the project in NWDS.

Modifying the Configuration Files for RAR

Change the configuration files used to build the RAR file.

Procedure

01. In NWDS, create project AdapterYOURADAPTER_RAR.

02. Extract and copy the META-INF directories to the appropriate project directories.

03. Use a text editor and change the contents of the files.

01. Change the namespace from com.sap.aii.af.sample.adapter.ra to com.test.YourAdapter.adapter.ra.

02. Change the adapter display file name references from sample_ra to YourAdapter_ra.

More information: Stand-Alone Deployment as RAR

04. Change the content of the ra.xml file. Change the adapter type from JCA to YOURADAPTERFile.

01. Change the adapter namespace from: http://sap.com/xi/XI/sample to http://sap.com/xi/XI/YourAdapter

02. Change the adapter display name from sample_ra to YourAdapterName_ra.

More information: Stand-Alone Deployment as RAR

05. Rename file from com.sap.aii.af.sample.adapter.ra-dd.xml to com.test.YourAdapter.adapter.ra-dd.xml.

Verify that the reference in SAP_MANIFEST.MF has also been changed from com.sap.aii.af.sample.adapter.ra-dd.xml tocom.test.YourAdapter.adapter.ra-dd.xml. (This should have already been done with step 3.1 above.)

More information: Stand-Alone Deployment as RAR

06. Refresh the projects in NWDS.

Creating and Deploying the Adapter

Create the RAR file and deploy it to the AS Java.

Procedure

01. Create a RAR file.

02. Deploy the RAR file.

03. Load the adapter metadata.

01. Load the metadata file, ra.xml, to the ES Repository.

PUBLIC© 2012 SAP AG. All rights reserved.

Page 86 of 130

In a browser, enter URL http://<host>:<port>/dir/start.

Enter the user ID and password when prompted.

02. In ES Repository create a software component version or open an existing software component version.

03. Under the software component version, create a namespace that corresponds to the ManagedConnectionFactory attribute namespace or the codednamespace of the adapter.

04. To load the metadata, call the context menu under Adapter Objects Adapter Metadata and select New.

05. In the Name field, enter the name of the adapter.

06. In the Namespace field, enter a unique, vendor-specific namespace that possibly contains a version number. The name and namespace together identifyan adapter type.

07. Locate the YourAdapterRA.xml

08. Choose Adapter Metadata Import XML Description .

04. Verify the adapter.

After deploying, loading and activating the adapter metadata, the adapter is available on AEX.

01. To verify the existence of the adapter, go to the AEX start page using URL http://<host>:<port>/start/index.jsp.

02. Click on Integration Builder.

Enter the User ID and password.

03. Create a communication channel and select your adapter in the Adapter Type field.

Testing Your Adapter

For testing, create a communication component, sender and receiver communication channels, and an Integrated Configuration object.

Procedure

01. To log on to Advanced Adapter Engine Extended, click on Integration Builder on start page.

Enter the User ID and password.

02. Create a Communication Component: AdapterService.

More information: Defining Communication Components

03. Create sender and receiver communication channels using your adapter.

More information: Defining Communication Channels

04. Create an Integrated Configuration object.

More information: Defining the Integrated Configuration

05. Send a test message.

Development and Configuration Tasks (AEX)

This section describes the end-to-end procedure for setting up and running a scenario based on SAP NetWeaver PI, Advanced Adapter Engine Extended (AEX)installation option.

There are different installation options of SAP NetWeaver PI, each of them implying a slightly different approach.

More information: Installation Options

Procedure

According to the chosen use case, select either of the following sections:

Using AEX Stand-Alone

Connecting AEX to an Integration Server

The sections referred to above cover the basic end-to-end procedures. For more information on how to set up specific use cases like, for example,sophisticated routing scenarios or B2B scenarios, see the corresponding section under Advanced Development Tasks (AEX).

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 87 of 130

The general procedure is structured according to the phases design time, configuration time and runtime.

More information: Phases of an Integration Project

Concepts

This part of the documentation introduces concepts and capabilities in particular relevant for the Advanced Adapter Engine Extended (AEX) installation option ofSAP NetWeaver PI.

Section Content

Advanced Adapter Engine Extended Provides an overview of the components and the architecture of an Advanced Adapter Engine Extendedinstallation.

Configuration Objects (Advanced AdapterEngine)

Provides an overview of the configuration objects relevant to set up message processing using theAdvanced Adapter Engine.

For concept information relevant for both, the dual-Stack and the Advanced Adapter Engine Extended installation option, see Concepts.

Advanced Adapter Engine Extended

Features

The installation option Advanced Adapter Engine Extended (AEX) provides the connectivity capabilities of the Advanced Adapter Engine (AAE) as well as thedesign and configuration tools (ES Repository and the Integration Directory) to set up scenarios based on the AAE.

For a detailed view of the components of the AEX, see Architecture (Advanced Adapter Engine Extended)

Capabilities

AEX supports the mediation capabilities of the AAE. In particular, you can use the following adapters:

RFC Adapter

SAP Business Connector Adapter

File/FTP Adapter

JDBC Adapter

JMS Adapter

SOAP Adapter

Marketplace Adapter

Mail Adapter

RNIF Adapter

CDIX Adapter

IDoc Adapter (AAE) (adapter type IDOC_AAE )

HTTP Adapter (AAE) (adapter type HTTP_AAE )

More information on the individual adapters: Adapter Configuration (AAE)

The RNIF and CIDX adapters, together with the corresponding business packages, allow you to set up business-to-business scenarios based on thecorresponding industry standard (RosettaNet or Chem eStandards respectively).

More information: Setting Up Integration Based on SAP Business Packages

Note that when you have installed the Advanced Adapter Engine Extended (AEX), integration processes cannot be used. Therefore, those scenarios of thebusiness package that use integration processes are not supported in this case.

Technically, the installation option AEX is based on AS Java.

Note

Note

Caution

PUBLIC© 2012 SAP AG. All rights reserved.

Page 88 of 130

Since AEX is based on AS Java alone, it is easier to install and maintain as it needs less memory and data storage. Therefore, AEX is a cost-saving optioncompared to a full installation of SAP NetWeaver PI.

Compared to a complete SAP NetWeaver PI installation, AEX has the following restrictions:

The connectivity options are restricted to the adapters of the AAE.

This means that you cannot use the following adapter types: IDoc (IE), XI, HTTP (IE), WS (connectivity with systems based on Web Services ReliableMessaging).

Although the XI adapter cannot be used with the AEX, you can configure connections based on the XI 3.0 message protocol using the SOAP adapter.

You cannot use integration processes (cross-component Business Process Management).

You can only use process integration scenarios as a modelling option in the ES Repository.

ABAP mapping is not available.

You cannot use the Runtime Workbench for monitoring purposes.

Connectivity Options

The following figure provides an overview of the connectivity options of the AEX. Read the following subsections for more details.

Connectivity Options of the AEX — Overview

Message Processing Using the Central AAE

As the standard connectivity option, you can use the Advanced Adapter Engine centrally, that means, installed on the same system ID (SID) where the designand configuration tools are also installed.

Using a Non-Central AAE as Part of an AEX Installation

You have the option to install a non-central Advanced Adapter Engine (non-central AAE) separately on a system with a different SAP SID than the central AAE. Atruntime, the non-central AAE works independently of the central one.

The design and configuration environment (ES Repository and Integration Directory) resides on the server of the central AAE. Both central and non-central AAEregister themselves at the same System Landscape Directory (SLD).

With regard to user management, the non-central AAE works completely autarkically, because it uses a local User Management Engine.

The following figure illustrates the setup.

Recommendation

Caution

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 89 of 130

Non-Central AAE as Part of an AEX Landscape

Note the following characteristics of the usage of a non-central AAE in an AEX installation:

You configure the non-central AAE using the Java Service Properties in SAP NetWeaver Administrator.

You cannot set up scenarios where an Integration Engine is involved in the communication.

Use Cases

You can use AEX in the following ways:

Using AEX standalone

Using AEX in combination with an additional SAP NetWeaver PI landscape

Using AEX Standalone

You can use AEX standalone as integration middleware. The basic communication options are illustrated in the following figure:

Using AEX Standalone

This use case is suitable in the following situations (examples):

Using AEX as “lightweight” and low-cost integration middleware

For scenarios that require only connectivity capabilities provided by the AAE and that do not contain any integration processes (cross-component BPM), youcan choose the installation option AEX, which is technically based only on the AS Java. In former releases, a standard installation of SAP NetWeaver PI(technically based on both AS Java and AS ABAP) was required for such scenarios.

Using AEX as a test environment

Since an AEX installation provides not only a runtime engine (Advanced Adapter Engine) but also the ES Repository and the Integration Directory, it supportsthe complete lifecycle of an integration project. Therefore, you have a complete and consistent toolset to set up, configure, and test integration scenarios in yourlandscape.

Note that AEX only provides a restricted functional range compared with an SAP NetWeaver PI complete installation. In particular, you cannot testintegration processes (ccBPM) with this setup.

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 90 of 130

Using AEX as a fail-over system

You can transport complete integration scenarios (integration content from the ES Repository) as well as the configuration content (Integration Directory) from aproductive landscape (for example based on an SAP NetWeaver PI standard installation) to a “fail-over landscape” based on AEX. Note that this transportoption is restricted to those Integration Directory objects that are supported by AEX, for example integrated configurations.

Using AEX in Combination with an Additional SAP NetWeaver PI Landscape

You can connect your AEX-based landscape to a landscape that is based on SAP NetWeaver PI. The basic communication options are illustrated in the followingfigure:

This use case is suitable in the following example situations:

Separating network zones

For example, you can set up a landscape based on an SAP NetWeaver PI standard installation for your security-critical scenarios. You can add an AEXinstallation in your demilitarized zone (DMZ) that is used for the external communication. Between the AEX in the DMZ and the “PI standard system”, you caneasily configure a change of transport protocol in order to provide maximum security.

Separating landscapes for different regions of an enterprise

For example, you can use landscapes based on AEX as a cost-saving integration solution for the regional business processes and a PI standard installation forthe central processes of an enterprise.

When you use AEX in combination with a landscape based on an SAP NetWeaver PI standard installation, you need to carefully consider all implications alsoin the case of federated PI landscapes. For example, the content of the individual ES Repositories (installed with the AEX on one hand and with the standardPI system on the other hand) is not aligned automatically, which means that suitable transport scenarios have to be planned.

Architecture (Advanced Adapter Engine Extended)

The following figure shows the main components of the AEX:

Caution

PUBLIC© 2012 SAP AG. All rights reserved.

Page 91 of 130

The main components for design and configuration time are the Enterprise Services Repository (ES Repository) and the Integration Directory.

The Integration Directory installed with AEX contains the same subset of configuration options as that which is necessary to configure the AAE-only messageprocessing option in a dual-stack PI installation, basically the integrated configuration.

Using these tools, an integration expert can design integration content (for example, interfaces and process integration scenarios) and specify the configurationsettings for message exchange for a specific system landscape. The design and configuration tools are connected to the System Landscape Directory whichcontains, for example, the description of software components and systems.

More information:

Design Time

Configuration Time

Based on the configuration settings from the Integration Directory, messages are exchanged between the connected business systems at runtime. AEX uses theAdvanced Adapter Engine as runtime engine.

To process messages, the AAE uses information from the Integration Directory. This information is made available to the AAE using a runtime cache.

More information: Runtime Caches

More Information

Runtime

Configuration Objects (Advanced Adapter Engine)

In this section you will find a summary of the tasks and configuration objects that are required when you want to configure communication using exclusively theAdvanced Adapter Engine as runtime engine.

This way of message processing is supported either when using the dual-stack SAP NetWeaver PI installation (and configuring “local” message processing viathe AAE), or when using the Advanced Adapter Engine Extended.

For an overview of the available communication and message processing options, we refer to the following sections:

Installation Options

Runtime

The figure below shows the phases of message processing for an incoming message. The configuration objects relevant in order to specify the different messageprocessing phases are also indicated in the figure.

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 92 of 130

Phases of Message Processing and Relevant Configuration Objects

For sakes of simplicity, communication parties (see below) are not considered in the figure.

The objects required to execute the current configuration tasks are listed in the following table.

Tasks and Relevant Configuration Objects

Tasks Relevant Objects

Defining a collaboration profileIn the collaboration profile you specify which components communicate with each other and what their technical communicationcapabilities are.

Communicationparty (party for short)CommunicationcomponentCommunicationchannel

Defining the integrated configurationIn the integrated configuration you specify the complete configuration of message processing using the Advanced Adapter Engine.Thereafter you only need one single object, whereas you need multiple configuration objects (sender agreement, receiverdetermination, interface determination, receiver agreement) for configuring communication with the Integration Server.

Integratedconfiguration

The table above lists the relevant configuration objects in Integration Directory. When you have installed the Advanced Adapter Engine Extended, you alsohave the option to configure the message flow graphically using Eclipse-based integration flows.

More information: Working with Integration Flows

Defining a Collaboration Profile

You initially specify the units that are to be addressed as the sender or receiver of messages in the communication profile. You define communication parties andcommunication components for this purpose. You define communication channels to establish the technical communication paths for the communication party andthe communication components. You configure the adapters for inbound and outbound processing in the communication channels.

More information: Collaboration Profile

Procedure

This task involves the definition of communication components, communication channels, and (optional) communication parties.

01. Optional: Define the necessary communication parties.

Using a communication party, you generally address a company within a business-to-business process.

More information: Defining Communication Parties

02. Define the necessary communication components and (optional) parties.

To define communication components based on a landscape description in the SLD, perform the following steps:

Logon to the SLD and define the necessary technical systems and business systems.

More information: Describing System Landscape in the SLD

Logon to the Integration Directory and create the necessary communication components based on the business systems in the SLD.

More information: Defining Business Systems as Communication Components

These communication components are called business system components because they are based on business systems defined in the SLD.

Note

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 93 of 130

To define a communication component “from scratch” without defining the business systems in the SLD, logon to the Integration Directory and create abusiness component.

More information: Business Component

03. To specify the technical communication capabilities of a communication component, you define a communication channel. You need a sender/receivercommunication channel to specify the adapter to connect to a sender/receiver component.

A communication channel provides the configuration interface for the adapter that is used to connect the communication component with the PI runtimeengine.

01. At first, you create a communication channel in the Integration Directory.

More information: Defining Communication Channels

02. You specify the adapter type.

03. You specify the configuration settings for the chosen adapter type.

More information: Configuring Adapters

Configuring Adapters

The Advanced Adapter Engine provides a set of different adapters.

Procedure

You use communication channels in the Integration Directory to configure the adapters.

With the Adapter Type attribute, you specify the adapter to configure. The possible configuration settings depend on the chosen adapter type.

The links below guide you to detailed information on the configuration interface for each adapter type.

Configuring the RFC Adapter

Configuring the IDoc Adapter (AAE)

Configuring the SOAP Adapter

Configuring the HTTP Adapter (AAE)

Configuring the File/FTP Adapter

Configuring the JDBC Adapter

Configuring the JMS Adapter

Configuring the Mail Adapter

Configuring the Marketplace Adapter

Configuring the SAP BC Adapter

Configuring the CIDX Adapter

Configuring the RNIF Adapter

More Information

Section Adapters (Advanced Adapter Engine) provides an overview of the supported settings for each adapter.

Using Advanced Adapter Engine Extended Stand-Alone

This is the basic communication flow when using Advanced Adapter Engine Extended (AEX) standalone:

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 94 of 130

Basic Communication Flow When Using AEX Stand-Alone

More information: Advanced Adapter Engine Extended

In this section, you will find information on how to set up this kind of communication.

Procedure

1. Design Integration Content

You define the software components for your development project in the System Landscape Directory (SLD). You design your integration content in the ESRepository.

In this section, we describe the general procedure when you follow the top-down design approach, which means that you start with a process model and based onthe model specify all other integration content.

More information about the basic concepts: Design Time

There is the option either to design the integration yourself from scratch or to use integration details already designed and delivered by SAP where you canmodify this content according to your needs. We will go into the aspects of both approaches in this chapter.

Both of these approaches normally come into play in real-life projects. A typical scenario would, for example, be that you use predefined content (andenhance it) to outline one part of the integration scenario, whereas another part has to be built completely from scratch. For the specific aspects that you haveto consider when using predefined content shipped by SAP, see Using Predefined Integration Content.

01. Define the software components you need for your developments.

You need these entities in order to organize the ESR content (for example, interfaces, mappings, and so on) you define with the following steps.

More information: Organizing and Managing Content in ESR

02. Log on to the ES Repository and choose the usage profile Advanced Adapter Engine Extended .

More information: Usage Profile

03. Define a process integration scenario for your overall process.

More information: Defining Process Integration Scenarios

04. Define the necessary interface objects.

More information: Defining Interface Objects

05. Define the necessary mapping objects.

More information: Defining Mappings

06. Activate your ESR objects.

2. Configure Integration Content

At configuration time you specify how messages have to be exchanged between the individual systems or applications of the existing system landscape – inaccordance with the process model and additional integration content specified at design time.

More information about the basic concepts: Configuration Time

Key tools for this phase are the System Landscape Directory and the Integration Directory and (optionally) the Eclipse-based PI Configuration Tool.

Using Integration Flows

You can configure integration content intuitively with the help of a graphical user interface which is part of the Eclipse-based Process Integration Tools (PI Tools).

Key object is the integration flow which provides a graphical description of the configuration of message exchange.

For each integration flow defined in Eclipse-based PI Tools, one integrated configuration and additional corresponding configuration objects (communicationchannels) are automatically created in Integration Directory.

In Integration Directory, the configuration objects that are automatically created based on an integration flow are stored in a separate folder. These configurationobjects cannot be changed in Integration Directory.

More information: Process Integration Tools (Eclipse-Based)

Using Integration Directory as User Interface

You can also configure integration content using the Integration Directory as user interface.

Compared to an SAP NetWeaver PI standard installation, the user interface of the Integration Directory for the AEX provides only access to the followingconfiguration object types:

Communication party

Communication component without party

Integration process components (communication components based on integration processes from the ES Repository) cannot be created.

Note

Note

Note

Caution

PUBLIC© 2012 SAP AG. All rights reserved.

Page 95 of 130

Integrated configuration

Configuration scenario

Value mapping group

We recommend that you use a process integration scenario from the ES Repository as configuration template. Doing this, you can configure inboundprocessing, routing, mapping and outbound processing semi-automatically.

More information: Configuring Process Integration Scenarios

01. Defining Collaboration Profile

This task involves the definition of communication components, communication channels and (optional) communication parties.

More information: Defining a Collaboration Profile

02. Configuring Message Exchange

This task involves the configuration of the inbound processing, routing, mapping and outbound processing (phases of message processing).

01. Logon to the Integration Directory.

02. Create an integrated configuration and specify the corresponding attributes for each of the phases of message processing.

More information: Defining the Integrated Configuration

03. Activate the configuration objects.

Connecting Advanced Adapter Engine Extended to anIntegration Server

There are certain use cases where it is suitable to connect an Advanced Adapter Engine Extended (AEX) with a landscape based on an SAP NetWeaver PI dual—stack installation.

More information: Advanced Adapter Engine Extended

The basic communication is illustrated in the following figure:

Connecting an AEX with SAP NetWeaver PI

The figure shows an example that uses AEX in both modes: In combination with another SAP NetWeaver PI system (communication path 1) and standalone(communication path 2).

Assume a situation that a global acting enterprise operates all communication to regional subsidiaries in standalone mode, whereas for all globalcommunications an additional landscape based on an SAP NetWeaver PI standard installation is interconnected (because the latter provides the completerange of mediation and security capabilities of SAP NetWeaver PI).

Procedure

The end-to-end procedure to set up and run a scenario depends on the details of the integration scenario, the system landscape the scenario is deployed on, aswell as on the particular choice of routing, connectivity and security settings.

You also have to take into consideration if the complete system landscape is owned by the same organization or if — as typically the case in business-to-business (B2B) scenarios — if different parts of the overall system landscape are owned and maintained by different business partners or organizations.

We show the basic steps to set up the following communication path: a sender system sends a message to the AEX. The message is then forwarded to theIntegration Server of an SAP NetWeaver PI landscape. The Integration Server processes the message and sends it to a receiver system. This communication isillustrated in the figure above (communication path 1). For sake of completeness, the figure also shows a communication path where a message is forwarded bythe AEX directly to the receiver. This communication (communication path 2 in figure above) is handled under Developing and Configuring Integration

Recommendation

Example

PUBLIC© 2012 SAP AG. All rights reserved.

Page 96 of 130

Scenarios (Using AEX Stand-Alone).

We can assume that in real-life scenarios both kinds of communication will be used in cooperation.

However, in this section we only show the basic steps to set up communication path 1. We assume that SAP NetWeaver PI and the AEX are installed on differenthosts.

Tasks on the Side of the AEX Installation

In general, you proceed as described under Developing and Configuring Integration Scenarios (Using AEX Stand-Alone). To set up the particular usecase covered in this section, take note of the following characteristics:

When you specify the message flow in the Integration Directory, you describe the message flow from the sender system to the Integration Server.

When you define the integrated configuration, you therefore need to specify the following basic settings:

To configure inbound processing (direction from the sender system to the AEX), you need to assign a sender adapter according to the protocol or standard thatis used by the sender.

To configure outbound processing (direction from the AEX to the Integration Server), you need to assign a receiver SOAP adapter. As Message Protocol,choose XI 3.0 .

Under Connection Parameters, enter the URL of the Integration Server.

To determine the URL of the Integration Server, you can do the following: configure inbound processing on the side of the SAP NetWeaver PI installation. Todo that, you define a sender agreement. Display the WSDL of the sender agreement. The WSDL contains the URL of the Integration Server. Note that incase AEX and SAP NetWeaver PI standard installation are hosted by different business partners (as the case in a B2B scenario), the URL has to becommunicated by other means (for example, email).

Tasks on the Side of the SAP NetWeaver PI Installation

In general, you proceed as described under Setting up Scenarios Using Dual-Stack Message Processing or Setting Up Scenarios Using Local AAE-Based Message Processing (depending on the chosen connectivity option). To set up the particular use case covered in this section, take note of the followingcharacteristics:

01. In the ES Repository you define the process integration scenario and the involved interface and mapping objects.

02. In the System Landscape Directory you describe the relevant part of the system landscape.

03. In the Integration Directory, you describe the message flow from the AEX to the receiver system.

Advanced Development Tasks (AEX)

This section provides information about advanced development tasks when using the Advanced Adapter Engine Extended (AEX).

Procedure

More information:

Developing and Configuring Mappings

Applying Advanced Routing Techniques

Encrypting Message Content on Database Level

Configuring Principal Propagation

Enabling Virus-Scanning of Messages

Configuring B2B Integration

Developing and Configuring Mappings

In a mediated communication step of an integration scenario, the sender normally uses a data format and structure for sending out a message that is different to theone that the receiver can handle. Therefore, the data structure and format used by the sender must be transformed into the structure and format that the receivercan handle. This type of transformation is called mapping. You specify the corresponding transformation rules in the ES Repository – in the form of mappingobjects.

More information: Mapping Objects

Note

Recommendation

PUBLIC© 2012 SAP AG. All rights reserved.

Page 97 of 130

Procedure

Defining Mappings

These are the steps to define a mapping:

Tasks at Design Time

01. Implement the mapping using one of the available kinds of mapping programs.

For an overview of the supported types of mapping programs, see Mapping Programs

The ES Repository provides a graphical editor to design mappings intuitively. Mappings designed with the graphical editor are called message mappings.

More information:

Message Mappings (Overview)

Message Mappings (Detailed Information)

02. In the ES Repository, create an operation mapping for a pair of source and target interface operation.

More information:

Preconfiguring Mapping Programs with Operation Mappings

Operation Mapping

03. Assign the mapping program to the operation mapping.

04. Activate the mapping objects you have created.

Tasks at Configuration Time

To configure mapping, you need to select an operation mapping from the ES Repository for a specific communication step. You do this in the Integration Directoryin an integrated configuration object.

To specify the mapping, choose the Receiver Interfaces tab.

More information: Defining the Integrated Configuration

Applying Advanced Mapping Techniques

More information: Applying Advanced Mapping Techniques

Processing Mappings at Runtime

The Advanced Adapter Engine executes the mappings configured in the Integration Directory at runtime after receiver identification has taken place. If no mappingis required for a connection then the Advanced Adapter Engine skips the mapping step.

Applying Advanced Mapping Techniques

There are several advanced mapping techniques you can use to design and configure mappings.

Some of these techniques combine design time and configuration time features in a way that enables mappings to be used dynamically (value mappings orparameterized mapping programs). In this section, you find an introduction to these techniques and a summary of the most important aspects.

Procedure

Designing and Configuring Multi-Mappings

Designing and Configuring Value Mappings

Designing and Configuring Parameterized Mapping Programs

Designing Mappings for Adapter-Specific Message Attributes

Designing and Configuring Mapping Lookups

Designing and Configuring Multi-Mappings

In standard mapping use cases, a single source message is transformed into a single target message. This kind of mapping is also referred to as a 1:1transformation.

A multi mapping allows you to override this restriction. In particular, a multi-mapping gives you the option to design a 1:n transformation for a message split.

Procedure

PUBLIC© 2012 SAP AG. All rights reserved.

Page 98 of 130

You can use a 1:n multi-mapping to map a message to multiple different (and generally smaller) messages during logical routing (mapping-based messagesplit). To set up a message split scenario, you have to perform the following steps:

01. ES Repository: Create the necessary multi-mapping and assign it to an operation mapping.

More information: Developing Multi-Mappings for Message Splits

02. Integration Directory: Select the operation mapping in the corresponding integrated configuration (Receiver Interfaces tab).

The inbound interface operations will be evaluated based on the multi-mapping.

More information: Defining the Integrated Configuration

For more information on this technique, read section Defining Message Splits.

Designing and Configuring Value Mappings

If senders and receivers know the same objects under different names, value transformations are required.

For example, a customer is identified in a sender system by a customer number, whereas in a receiver system the customer is identified by a name.

There are several options for performing value mappings:

Using standard function FixValues

Using standard function Value mapping

Procedure

Using Standard Function FixValues

This is the easiest way to define a value mapping. In the target field mapping, you assign the standard function FixValues from the Conversions functiongroup. Using this function, you can define value pairs. However, the value mapping defined by such a pair can only be used in the corresponding messagemapping. Furthermore, this is a rather “static” option for defining a value mapping, since the value pairs have to be known at design time.

Using Value Mapping Tables from Configuration

A more flexible and “dynamic” way to define a value mapping is to use the standard function Value mapping (Conversions function group area). Using thisstandard function, you can refer to value pairs that are defined at a later point in time during configuration. To define the value pairs from configuration time, you usea value mapping group in the Integration Directory.

The advantages of this approach are that value mappings can be reused within different message mappings and values can be specified later at configurationtime.

In many cases, the names of objects are not known prior to configuration time.

To refer to the values (that are not already known at design time) in the message mapping, in the function Value mapping you use the key fields Agency andSchema.

If you refer to a value mapping table created manually in the Integration Directory, you have to select http://sap.com/xi/XI as Value MappingContext. The value mapping context identifies the source of the value pairs.

At configuration time, you define the actual values of the objects by creating value mapping groups. A value mapping group is a configuration object in theIntegration Directory and contains different representations of the same object. To enter the values that identify the objects in different frames of reference, you usethe key fields Agency and Schema.

Agency and scheme set a frame of reference within which an object can be uniquely identified. For more information, see Identifiers.

As an alternative to the manual creation and editing of value mapping groups, you can replicate value pairs from external data sources using a special interface.The interface objects are available as part of SAP predefined content in the software component SAP BASIS . For more information, see Value MappingReplication.

More information: Value Mapping

Example

Note

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 99 of 130

Designing and Configuring Parameterized Mapping Programs

You can add parameters to a mapping program (enabling you to transfer values to the mapping program) at configuration time (in an integrated configuration in theIntegration Directory).

This is another way to execute mappings dynamically, in the sense that the actual values are not known until configuration time.

You can define parameterized mapping programs for message mappings, Java mappings, and XSLT mappings with Java enhancements.

Procedure

To set up a scenario with a parameterized mapping program for a message mapping, you have to perform the following steps:

01. Define the parameters at design time. To do this, you have to perform the following steps:

In the message mapping (on the Signature tab), define the parameters to be used in the target field mapping.

In the operation mapping (that references the message mapping), create parameters (by choosing Parameters) and connect them with those of themessage mapping (by choosing Binding).

You can set either Simple Type or Adapter as the Category for the parameter. The category Adapter is only relevant if you set up a mapping lookupscenario.

02. Values can be entered for the parameters in the Integration Directory (integrated configuration which uses the operation mapping).

More information: Parameterized Mapping Programs

Designing Mappings for Adapter-Specific Message Attributes

The message header of a message contains a header for adapter-specific message attributes that the sender adapter can use to write additional information to themessage header. This enables sender adapters to write information that is not known until runtime to the message.

Furthermore, developers have read and write-to access to adapter-specific attributes from within a mapping program.

XSLT programs (J2EE) and message mappings have mapping runtime constants that enable developers to access the same Java classes for adapter-specific-attribute mappings as in Java mapping programs. Mapping programs executed by SAP NetWeaver PI support this kind of access.

Procedure

More information:Java Mapping of Adapter-Specific Message Attributes

Designing and Configuring Mapping Lookups

Mapping lookups access values in a back-end system when the mapping program is executed (at runtime). By using a mapping lookup, a mapping programcan call functions from other application systems while a mapping program is being executed. The data transfer between mapping runtime and applicationsystems is accomplished by means of a lookup programming interface (API). The API provides methods for accessing application systems using the RFC,JDBC, and SOAP adapter.

Procedure

To set up a mapping lookup scenario, you have to perform a combination of activities at design and configuration time:

01. At design time (in the ES Repository), you define the mapping program.

You can define lookups for message mappings, Java mappings, and XSLT mappings with Java enhancements.

At design time, you have to perform the following steps:

01. Provide an import function parameter (of type Adapter )

02. Implement the call to the application system (using the import parameter)

More information:

Using the Lookup API in a Java Mapping Program

Using the Lookup API in an XSLT Program

Using the Lookup API in a Message Mapping

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 100 of 130

When setting up lookups using the JDBC or the RFC adapter with a message mapping, you can perform this step graphically.

More information:

Defining JDBC Lookups Graphically

Defining RFC Lookups Graphically

02. At configuration time (in the Integration Directory), you have to perform the following steps:

01. Configure the corresponding adapter in a (receiver) communication channel.

More information: Defining Communication Channels

02. Assign the corresponding operation mapping (that refers to the mapping program) in an integrated configuration.

You have to do this to ensure that the ID of the receiver channel is transferred to your mapping program at runtime.

More information: Defining the Integrated Configuration

More information: Adding Lookups to Mapping Programs

Using the Lookup API in a Java Mapping ProgramPrerequisites

Note the prerequisites for the adapter that you want to use for the lookup (see: Adding Lookups to Mapping Programs).

Procedure

1. Implement a Parameterized Java Mapping Program

01. To be able to execute the lookup, your Java mapping program requires an import parameter of type Adapter. Create a Java mapping (see steps 1 and 2 inParameterizing Java Mappings).

02. Using the lookup API and the import parameter, implement the call to the application system.

For JDBC adapter calls, use the specific lookup API for the JDBC adapter (see: Implementing Lookups Using DataBaseAccessor).

For calls with all other adapters, use the generic lookup API (see: Implementing Lookups Using SystemAccessor).

03. To be able to assign a receiver channel to this import parameter later, you must assign the import parameter to an operation mapping parameter by using abinding (see steps 3-7 in Parameterized Java Mappings).

To execute or test the mapping program and the mapping lookup, perform the following steps in the Integration Directory:

2. Configure a Receiver Channel for Mapping Lookups

01. Create the receiver communication channel for the application system call in the Integration Directory.

More information: Defining Communication Channels

02. To transfer the ID of the receiver channel to your Java mapping program at runtime, create an integrated configuration and assign to it the operation mappingfrom step 3.

More information: Defining the Integrated Configuration

Using the Lookup API in an XSLT ProgramPrerequisites

Note the prerequisites for the adapter that you want to use for the lookup.

More information: Adding Lookups to Mapping Programs

Procedure

To add a lookup to an XSLT program, you must parameterize it and use the lookup API. To access parameters and to use the mapping API, you must call Javamethods in the XSLT program. To minimize the number of Java methods that need to called, SAP recommends that you encapsulate the entire mapping lookup inone single Java method.

1. Implement a Parameterized XSLT Mapping Program

01. To be able to execute the lookup, your XSLT mapping program requires an import parameter for the adapter that is to be used. Create an XSLT mapping (seesteps 1 and 2 in Parameterizing XSLT Mappings). At runtime, the relevant operation mapping uses the import parameter to transfer the ID of an appropriatereceiver channel for the adapter (see steps 4-6).

02. Create a Java mapping program by implementing the look up. The method that you want to use to execute the lookup must have a parameter in order to

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 101 of 130

transfer the ID of the receiver channel (see step 1) from the XSLT program. Furthermore, add additional parameters that are required for the lookup and fortransferring the result to the XSLT program, to the signature of the Java method.

More information: XSLT Mapping with Java Enhancement

03. Using the lookup API and the import parameter, implement the call to the application system within the Java method.

For JDBC adapter calls, use the specific lookup API for the JDBC adapter.

More information: Implementing Lookups Using DataBaseAccessor

For calls with all other adapters, use the generic lookup API.

More information: Implementing Lookups Using SystemAccessor

04. To be able to assign a receiver channel to this import parameter later, you must assign the import parameter to an operation mapping parameter by using abinding (see steps 3-7 in Parameterized XSLT Mappings).

To execute or test the mapping program and the mapping lookup, perform the following steps in the Integration Directory:

2. Configure a Receiver Channel for Mapping Lookups

01. Create the receiver channel for the application system call in the Integration Directory.

More information: Defining Communication Channels

02. To transfer the ID of the receiver channel to your XSLT mapping program at runtime, create an integrated configuration and assign to it the operation mappingfrom step 4.

More information: Defining the Integrated Configuration

Using the Lookup API in a Message Mapping

You can use the mapping lookup API in a used-defined function of a message mapping and then use the generic lookup API (class SystemAccessor ) or thespecial API for database calls ( DataBaseAccessor ). In the case of the latter, if the SELECT calls are only basic, it is sufficient to use the standard function todefine JDBC lookups graphically.

More information: Defining JDBC Lookups Graphically

Prerequisites

Note the prerequisites for the adapter that you want to use for the lookup.

More information: Adding Lookups to Mapping Programs

You have already created a message mapping and are in the mapping editor.

Procedure

1. Implement a Parameterized Message Mapping Program

01. To execute the lookup, your user-defined function requires an import function parameter of type Adapter, which is assigned to the message mappingparameter (see step 1-3 in Defining and Using Import Parameters).

02. Using the lookup API and the import parameter, implement the call to the application system

If the features of the standard function for graphical JDBC lookups (see above) are not sufficient for your application, use the specific lookup API for theJDBC adapter.

More information: Implementing Lookups Using DataBaseAccessor

For calls with all other adapters, use the generic lookup API

More information: Implementing Lookups Using SystemAccessor

03. If, later, you want to assign a receiver channel to the message mapping parameter that you assigned the import function parameter to in step 1, you mustassign this import parameter to an operation mapping parameter by using a binding (see step 4-8 in Defining and Using Import Parameters).

To execute or test the mapping program and the mapping lookup, perform the following steps in the Integration Directory:

2. Configure a Receiver Channel for Mapping Lookups

01. Create the receiver channel for the application system call in the Integration Directory.

More information: Defining Communication Channels

02. To transfer the ID of the receiver channel to your message mapping program at runtime, create an integrated configuration and assign to it the operationmapping from step 3.

More information: Defining the Integrated Configuration

PUBLIC© 2012 SAP AG. All rights reserved.

Page 102 of 130

Defining JDBC Lookups Graphically

The data-flow editor in the mapping editor has the standard function JDBC lookup with which you can define a mapping-lookup using the JDBC adaptergraphically. You can formulate simple SELECT statements using the editor for this function.

Prerequisites

To be able to graphically model the lookup, you must know the table structure of the table that is to be accessed. To use the table structure in the mapping editor,you must import it to the Enterprise Services Repository as an external definition (see step 2). To do this, the following conditions must be met:

The table must be defined in the database.

To access the table of the database, a JDBC adapter instance and the relevant database must be running.

Special Prerequisites for Databases

The mapping editor generates Java program code from the graphical definition of the mapping lookup. The SELECT statement that is generated contains the fieldsyou access using the default function in the graphical JDBC lookup. The fields are set in double quotation marks to avoid conflicts with SQL keywords.

In the mapping lookup, access an ORDER field that contains a request number. The SQL SELECT statement however contains an ORDER keyword to setthe order. To identify the field in the SELECT statement as identifier for a field it must be set in doubled quotation marks ( "ORDER" ). Otherwise the statementsyntax is incorrect.

The database that you want to access using the JDBC lookup must work with double quotation marks for accessing fields in the SQL syntax. This can beconfigured for the database in some cases: for example, if a JDBC lookup, which is described by the graphical standard function, only functions with a MySQLdatabase when the SQL mode ANSI or ANSI_QUOTES is set.

Procedure

1. Enable Access to the Database Table

01. In the Integration Directory, create the JDBC receiver channel for the call to the application system.

More information:

Defining Communication Channels

Configuring the Receiver JDBC Adapter

This receiver channel is initially only required for reading the table structure. The developer or consultant can create a different receiver channel later toaccess the same table in a different system (see also step 8 below).

02. Create an external definition in the Enterprise Repository and import the table structure for the lookup (see: Importing Table Structures from a Database).

2. Define a Parameterized Message Mapping Program

01. In the Enterprise Services Repository, create a message mapping with a source and target structure, or open an existing message mapping for editing.

02. In the mapping editor, switch to the Signature tab page. Create an import message mapping parameter of category Adapter (for example, MMP_JDBC ) andassign it the adapter metadata of the JDBC adapter. The adapter metadata of the JDBC adapter is shipped by using software component SAP BASIS.

03. In the mapping editor, navigate to the Definition tab page and then to the target-field mapping for which you want to define the JDBC lookup.

04. Drag the standard JDBC lookup function to the data-flow editor and define the SELECT statement in the function properties graphically:

01. Select the import message-mapping parameter for the JDBC adapter from the dropdown list box ( MMP_JDBC from step 4). The message mapping usesthis parameter later to transfer the ID of the receiver channel to the function which is to be used for the lookup (see steps 7 and 9).

02. Call input help and select the external definition from step 2.

03. Define the SELECT statement.

All available fields are displayed in the middle of the standard-function editor. The mapping editor creates an inbound or outbound parameter for thefunction for each field that you add to the right or left column.

Add all fields that you want to use to read a row in the database table to the column on the left. You must assign values to these fields later. To do so, inthe data-flow editor, assign them the source fields or result values of other functions. If you do not specify a unique key when you select the fields,multiple rows are read.

Add all the fields that you want to apply from the result of the SELECT statement and want to process further to the column on the right. If a SELECTstatement selects multiple rows, the function returns a result queue for each result parameter.

04. If you have selected the relevant checkbox in the function properties of the standard function, the mapping runtime inserts a context change after eachvalue in the result queue.

05. If, later, you want to assign a receiver channel to the message mapping parameter that you assigned the import function parameter to in step 1 (MMP_JDBC),you must assign this import parameter to an operation mapping parameter by using a binding (see step 4-8 in Defining and Using Import Parameters),for example IM_JDBC.

To execute or test the mapping program and the mapping lookup, perform the following steps in the Integration Directory:

3. Configure a Receiver Channel for Mapping Lookups

Example

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 103 of 130

01. If you want to use a different JDBC receiver channel to the one in step 1, in the Integration Directory, create a new receiver channel for calling the applicationsystem.

More information:

Defining Communication Channels

Configuring the Receiver JDBC Adapter

02. To transfer the ID of the receiver channel to your message mapping program at runtime, create an integrated configuration and assign to it the operationmapping from step 7. Then, in the integrated configuration, you can assign the receiver channel to the operation-mapping parameter (in the exampleIM_JDBC).

More information: Defining the Integrated Configuration

Defining RFC Lookups Graphically

The data-flow editor in the mapping editor has the standard function RFC lookup with which you can define a mapping-lookup using the RFC adapter graphically.The function takes the request, response, and fault parts of an imported RFC into account.

Prerequisites

To be able to model the lookup graphically, the structure of the RFC must be known. To use this structure in the mapping editor, you must import the RFC to theEnterprise Services Repository (see step 2 below).

Procedure

Enable RFC Call and Import RFC for Mapping Editor

In the Integration Directory, create the RFC receiver channel for the call to the application system.

More information:

Defining Communication Channels

Configuring the Receiver RFC Adapter

This receiver channel is initially only required for testing the lookup. The developer or consultant can create a different receiver channel later to call the same RFCin a different system (see also step 8 below).

Import the RFC into the Enterprise Services Repository.

More information: Importing IDocs and RFCs

Define a Parameterized Message Mapping Program...

In the Enterprise Services Repository, create a message mapping with a source and target structure, or open an existing message mapping for editing.

In the mapping editor, switch to the Signature tab page. Create an import message-mapping parameter of category Adapter (for example, MMP_RFC ) and assignit the adapter metadata of the RFC adapter. The adapter metadata of the RFC adapter is shipped in software component SAP BASIS.

In the mapping editor, navigate to the Definition tab page and then to the target-field mapping for which you want to define the RFC lookup.

Drag the standard function RFC Lookup in function category Conversions to the data-flow editor and define the call graphically in the function properties:

Select the import message-mapping parameter for the RFC adapter from the dropdown list box ( MMP_RFC from step 4). The message mapping uses thisparameter later to transfer the ID of the receiver channel to the function which is to be used for the lookup (see steps 7 and 9).

Call input help and select the imported RFC from step 2.

To define the RFC call, in the function properties for standard function RFC Lookup, model the inbound and return parameters for the function, and model howthey are associated with the request and response parameters of the RFC. If you connect source fields or functions with the inbound parameters later, youimplicitly define a mapping between these source fields or functions and the parameters of the RFC request (left-hand side). At runtime, this mapping isprocessed in the same way as a target-field mapping. In the function properties, you then define which parameters of the RFC response can be assigned totarget fields or functions by using the return parameters in the dataflow editor (right-hand side).

PUBLIC© 2012 SAP AG. All rights reserved.

Page 104 of 130

Define the mapping as follows:

To use a parameter from the RFC request or the RFC response as the inbound or return parameter for the standard function RFC lookup, double-click theparameter in the structure. The parameter is then transferred to the table in the lower screen area. In the table you can also define the sequence of the inboundor return parameters.

Parameters in the RFC that are not scalar values are displayed in the dialog box in bold. Such parameters are, for example, table parameters in the RFC thatare mapped to elements with maxOccurs = unbounded . The same rules as for normal target-field mappings apply for the mapping to the parameters ofthe RFC request, or for the mapping from the parameters of the RFC response.

Instead of offering a parameter of the RFC request as the inbound parameter of the standard function RFC lookup, you can also enter a constant in the structure.

You can handle exceptions defined in the RFC as follows during the RFC lookup:

If you have selected the Use Exceptions checkbox in the function properties of the standard function, the mapping editor adds an additional parameter in red(the bottommost return parameter) to the standard function in the data-flow editor. If you do not assign a target field to this return parameter, ignore the RFCexceptions (the message mapping is not terminated at runtime). Otherwise the mapping runtime transfers the exception as an XML structure and it can thenbe evaluated in a user-defined function, for example. If there is no exception, the mapping runtime transfers an empty context.

If you have not selected the Use Exceptions checkbox, the mapping runtime terminates the message mapping if an exception occurs during the RFC lookup.

If, later, you want to assign a receiver channel to the message-mapping parameter that you assigned the import function parameter to in step 1 ( MMP_RFC ), youmust assign this import parameter to an operation-mapping parameter by using a binding (see step 4-8 in Defining and Using Import Parameters), forexample IM_RFC .

To execute or test the mapping program and the mapping lookup, perform the following steps in the Integration Directory:

Configure a Receiver Channel for Mapping Lookups

If you want to use a different RFC receiver channel to the one in step 1, create a new receiver channel for calling the application system in the IntegrationDirectory.

More information:

Defining Communication Channels

Configuring the Receiver RFC Adapter

To transfer the ID of the receiver channel to your message mapping program at runtime, create an integrated configuration and assign to it the operation mappingfrom step 7. Then, in the integrated configuration, you can then assign the receiver channel to the operation-mapping parameter (in the example IM_RFC ).

More information: Defining the Integrated Configuration

Caution: You can only execute the mapping lookup once you have performed these steps and have installed the runtime components of the Integration Server. Ifthis is not the case, the message mapping program will terminate with an error message.

Applying Advanced Routing Techniques

This section provides information on how to apply special routing techniques like content-based or dynamic routing, for example.

Procedure

More information:

Defining Content-Based Routing

Defining Extended Receiver Determination (Advanced Adapter Engine)

Defining Message Splits

More Information

Routing

PUBLIC© 2012 SAP AG. All rights reserved.

Page 105 of 130

Defining Content-Based Routing

In many business cases, it is necessary to define conditions with which the receivers or inbound interfaces of a message are determined during routing. Forexample, consider a routing condition in the following form: “If the value of a specific field in the message is x, then forward the message to receiver y”.

At configuration time, you can define conditions that depend on the content of the message. You can do this for receiver determinations, receiver rules and interfacedeterminations.

More information: Content-Based Routing

Procedure

To configure content-based routing, you basically do the following:

When configuring content-based routing in an integrated configuration, Receiver tab, you define routing conditions for specific receivers or a sets of receivers.

When configuring content-based routing in an integrated configuration, Receiver Interfaces tab, you define routing conditions for specific sets of inboundinterfaces.

Create an integrated configuration in the Integration Directory: Defining the Integrated Configuration

For local message exchange using the Advanced Adapter Engine or in case you use the Advanced Adapter Engine Extended, you configure content-basedrouting in an integrated configuration (Receiver tab page or Receiver Interfaces tab page).

More information: Defining the Integrated Configuration

When you define a routing condition, you basically specify the following attributes:

With the Left Operand, you specify the payload element of the incoming message upon which the routing to the specified receiver is to depend.

In the Right Operand, you enter a value for the payload element.

You choose a specific Operator to link both operands.

You have the following options to specify the payload element:

Using an XPath expression

Using this option, you can select the payload element intuitively from the structure of the incoming message (which is defined by the outbound interface in thekey of the integrated configuration).

Using a context object

Using this option, you select a context object that has been defined for the outbound interface. A context object is a design object that can be used as anabbreviated expression for an XPath expression to address a specific payload element.

A context object has to be defined with the corresponding outbound interface in the ES Repository beforehand. So, if you already know at design time thepayload elements upon which the routing is likely to depend, you can define the corresponding context objects in the ES Repository at the correspondingservice interface.

More information: Creating Context Objects

Defining Message Splits

You can set up scenarios where a message is split into several fragmented messages at runtime that are then sent to the same (or different) receiver systems.

These are the basic scenarios that you can configure in the Integration Directory:

Interface split

Mapping-based message split

Procedure

Defining an Interface Split

By default, in an integrated configuration you specify one or more inbound interfaces for a given receiver system. For each inbound interface, you might also like toassign a mapping since the inbound interfaces are most likely different from each other.

This is the basic procedure:

01. Define the service interfaces and operations in the ES Repository.

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 106 of 130

02. Optional: Define the necessary mappings in the ES Repository.

03. Define an integrated configuration.

More information:

Defining the Integrated Configuration

The figure below shows the behavior at runtime:

Interface Split

Defining a Mapping-Based Message Split

When you have a larger message (for example, one message containing a large number of line items) to be split into several smaller messages with eachmessage containing only a subset of line items of the large message, then you can do the following:

01. In the ES Repository, define a 1:n multi-mapping to specify the transformation of the large message into n smaller messages.

More information: Developing Multi-Mappings for Message Splits

02. In the Integration Directory, define an integrated configuration with the following properties:

The object key contains the source interface of the multi-mapping as outbound interface.

In the integrated configuration, select the multi-mapping from the ES Repository (in the Operation Mapping field).

Note that only 1:n transformations can be processed.

The target interfaces defined for the multi-mapping in the ES Repository are then calculated and displayed in the integrated configuration.

More information:

Defining the Integrated Configuration

The figure below shows the behavior at runtime:

Using this option, you can only configure a message split where the split messages are sent to different inbound interfaces of the same receiver system.

The reason for this is as follows: During runtime, the receiver determination step is performed prior to the mapping step. At the time when the multi-mapping isperformed and the corresponding inbound interfaces are calculated (and the corresponding split messages are generated), there is no chance to do another“receiver split”. The resulting split messages can only be sent to the receiver system determined in the previous step.

Routing the Split Messages to Different Receiver Systems

To configure a message split where the split messages are routed to different receiver systems, you define the message split using several 1:1 mappings(instead of one 1:n mapping).

This is the procedure:

01. In the ES Repository, define the necessary 1:1 mappings for each of the intended split messages. Each mapping creates another subset of line items out ofthe large source message.

02. In the Integration Directory, do the following:

01. Configure the different receiver systems in an integrated configuration.

02. For each configured receiver, define an integrated configuration. Assign the right 1:1 mapping and inbound interface.

More information:

Defining the Integrated Configuration

The behavior at runtime is illustrated in the figure below:

Note

Caution

PUBLIC© 2012 SAP AG. All rights reserved.

Page 107 of 130

Configuring a Message Split with Different Receiver Systems

Encrypting Message Content on Database Level

To increase data security, you have the option of encrypting the payload (and any attachments) of messages at the database level. This means that all messagesconfigured in this way are stored in the message database encrypted. Users that query the message database, for example using SQL, cannot read the contentof the payload.

Message payload and attachments is abbreviated to message content throughout this documentation.

You can use this feature if you run scenarios that involve the exchange of sensitive data and you want to prevent malicious users from accessing this data.

For more information on how this function is related to the Payment Card Industry – Data Security Standard (PCI-DSS), see: Using SAP NetWeaver PI inPCI-Compliant Scenarios.

The encryption of the message payload at the database level has the following characteristics:

It can be activated for specific service interfaces.

This means encryption can be activated for specific scenarios that include the exchange of sensitive business data.

It affects the complete payload of the message.

When you activate encryption for a service interface, the complete payload will always be stored encrypted.

Note that encryption of the message payload in the database does not affect how the message content is displayed in monitoring.

Encryption is supported for messages stored in the Advanced Adapter Engine message database.

Limitations

If you plan to use this feature, consider the limitations summarized under Encrypting Message Content on Database Level (Limitations).

Procedure

The individual configuration procedure depends on the involved components. This is the general procedure.

01. Configuring service interfaces

Indicate the service interfaces in the Enterprise Services Repository for which message encryption should be activated.

More information: Configuring Service Interfaces for Encryption (ES Repository)

02. Configuring Advanced Adapter Engine

You need to configure message encryption in the AAE.

More information: Encrypting Message Content on Database Level (AAE)

03. Configuring business systems with local Integration Engines (applicable for dual-stack or AAE-only message processing)

If the scenario involves business systems with a “local” Integration Engine, you need to perform additional configuration steps in the connected back-end

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 108 of 130

systems.

More information: Encrypting Message Content on Database Level (Local IE)

04. Configuring message processing in the Integration Directory

Proceed as described under Using Advanced Adapter Engine Extended Stand-Alone (in section 2. Configure Integration Content).

Also note the following:

Make sure that the relevant service interfaces specified as sensitive are assigned to the involved communication components. If you are using businesscomponents, you need to assign the relevant service interfaces manually.

Note these general recommendations on how to handle keys:

Be careful if you plan to delete keys. If you have deleted a key, a message (that has been stored encrypted) remains in the database but can no longer beopened. Do not rename keys during productive scenarios.

Configuration Tasks for Different System Landscapes

The configuration procedure and the involved configuration tools depend on the involved components at runtime.

The following figure illustrates a possible setup of components.

Setup of Components when Using AAE-Only Message Processing

In the illustrated setup, an SAP system is also connected to the PI instance based on the XI message protocol (configured in the SOAP adapter).

To configure message encryption for this setup, you need to perform the following configuration tasks:

Configuring service interfaces for encryption (as described under Configuring Service Interfaces for Encryption)

Configuring the AAE (as described under Encrypting Message Content on Database Level (AAE))

Configuring the “local” Integration Engine in the connected SAP system (as described under Encrypting Message Content on Database Level (Local IE))

Encrypting Message Content on Database Level (Limitations)

To increase data security, you have the option of encrypting the payload (and any attachments) of messages at the database level. This means that all messagesconfigured in this way are stored encrypted in the message database. Users that query the message database, for example using SQL, cannot read the contentof the payload.

Consider the following limitations if you plan to use this feature:

Parts of a message cannot be encrypted individually.

The complete payload of a message is always encrypted in the database.

Masking of individual fields (for example, Primary Account Number) is not supported.

Re-encryption of messages is not supported.

Administrators cannot re-encrypt messages that have already been stored. Re-encryption means: a message that has already been encrypted is decryptedand thereafter encrypted with a new key.

Note

Recommendation

PUBLIC© 2012 SAP AG. All rights reserved.

Page 109 of 130

Furthermore, administrators cannot initiate automatic re-encryption of messages that have already been stored.

To overcome this limitation, administrators can manually redeliver affected messages or clean up the message database.

More information: Data Storage Security for the Advanced Adapter Engine

Applying message archiving can disable message encryption.

If an archiving solution is used that does not support encrypted data storage, this can lead to a situation in which configured message encryption at thedatabase level (as described in this section) is disabled. Administrators are recommended to evaluate the archive solution used in light of this limitation.

Scenarios using Business Process Management are not fully supported.

Depending on the scenario, messages or message elements may be stored unencrypted in separate databases even if the message encryption is configuredaccording to the procedures in this section.

Encryption of logged synchronous messages is not supported in the Advanced Adapter Engine.

Advanced (user-defined) message search on sensitive message elements is not supported.

If you define filters that include payload elements with sensitive data, be aware of the fact that these elements are stored unencrypted.

SAP NetWeaver Search and Classification (TREX) is not supported.

TREX stores messages unencrypted.

Message encryption at the database level is not fully supported for all SAP adapters and third-party adapters.

Adapters with their own message storage (for example, RNIF, CIDX adapter) do not support encrypted data storage if the message itself was not previouslyencrypted by the sender.

Only service interfaces can be marked as sensitive. Imported IDocs and RFCs cannot be marked as sensitive. Scenarios using those imported interfaces oneither sender or receiver side are currently not supported.

Configuring Principal Propagation

You can define that user identities are forwarded securely from a sender to a receiver by using the Advanced Adapter Engine. You can define any number ofcommunication routes between the sender and receiver. This is known as principal propagation.

User refers to a entity that can authenticate itself in a system when the security settings are configured appropriately and the necessary authorizations have beengranted. Note that the user name can be different in the sender and receiver systems. Principal propagation means that the identity of the user - and not their username - is forwarded.

Procedure

More information: Configuring Principal Propagation Using the Advanced Adapter Engine

Enabling Virus-Scanning of Messages

The Virus Scan Interface that is part of SAP NetWeaver allows you to include external virus scanners in an SAP system and to scan files or documentsprocessed by SAP applications for viruses.

For more information, see SAP Library at http://help.sap.com under SAP NetWeaver Library: Function-Oriented View Security System Security Virus Scan Interface .

You can connect an Advanced Adapter Engine to an external virus scanner using the Virus Scan Interface in order to activate virus scanning of both inbound andoutbound messages.

By default, virus scanning of a message is limited to scanning attachments of the message for malicious data. Optionally, you can configure the AdvancedAdapter Engine that way that the message payload in addition is scanned for malicious data.

Virus-scanning is supported by all adapters delivered by SAP.

Procedure

01. Configuring Virus Scan Interface

Configuration of the Virus Scan Interface is implies tasks related to components based on Application Server Java.

To configure the Virus Scan Profile (AS Java), perform the following tasks:

01. Logon to SAP NetWeaver Administrator and choose Configuraton Security Virus Scan Provider .

02. Select the scan profile: pi_Messaging .

03. Make the following entries:

Recommendation

PUBLIC© 2012 SAP AG. All rights reserved.

Page 110 of 130

Profile Description Process Integration Messaging

Reference Profile: Select the Default Profile

For more information, see SAP Library at http://help.sap.com under SAP NetWeaver Library: Function-Oriented View Security SystemSecurity Virus Scan Interface Configuration of the Virus Scan Interface .

02. Global activation of virus scanning for the involved Advanced Adapter Engine

Virus scanning can be configured for the Advanced Adapter Engine (AAE).

The configuration settings specified for the Advanced Adapter Engine are referred to as global configuration settings, because they apply for all integrationscenarios that are executed on the basis of the chosen setup of business systems and runtime engines.

As default setting, virus scanning of inbound messages is proposed. However, you have the option to activate virus scanning for outbound messages inaddition.

More information: Configuring Virus Scanning on the Advanced Adapter Engine

03. Scenario-specific activation of virus scanning

You can specify for which messages as part of a specific scenario virus scanning should be applied. You perform this task by specifying the correspondingconfiguration object in Integration Directory.

For message processing using the Advanced Adapter Engine only, you can configure virus scanning of messages for specific scenarios that are covered byan integrated configuration.

More information: Defining the Integrated Configuration

Choose the favored option under Virus Scan.

You can choose between the following options:

Using global configuration

Select this value to choose the global configuration as specified for the Advanced Adapter Engine.

Enabling virus scanning for the selected configuration object

Select this value to enable virus scanning for the messages specified by the configuration object.

Disabling virus scanning

Select this value to disable virus scanning for the messages specified by the configuration object.

Configuring B2B Integration

Several companies or business partners are typically involved in a B2B process. Each of these bases their configuration of the B2B process on the informationavailable to them. For example, make business partner details known using your internal system landscape, not outwardly.

To keep things simple, the description below assumes a situation that involves one business process and two business partners. One of the business partnersinvolved uses SAP NetWeaver PI and performs the B2B configuration in the Integration Directory. The second business partner can also use SAP NetWeaver PIand perform a similar (mirror-image) configuration in their Integration Directory. However, they can also use a different integration tool.

This section describes the steps taken by one of the business partners in the Integration Directory.

Prerequisites

Ideally, you have mapped the B2B integration in the Enterprise Services Repository using a process integration scenario. In the Integration Directory this enablesyou to automate much of the configuration of configuration objects using the model configurator. However, you must define the collaboration profile manually.

If there are no process integration scenarios that you can use as the configuration template, you need to create all configuration objects manually.

Procedure

Configure Collaboration Profile

In this step you define the required communication parties, communication components, and communication channels.

To define the collaboration profile, perform the following steps:

01. In the Integration Directory, create a communication party for each business partner involved in the process.

02. Create a communication component of type Business System for each business system in your internal system landscape.

03. Create the required business components.

Business partners involved in B2B processes do not generally make the names of their internal business systems known externally, but instead maskthem by using business components.

Assign the business components that your business partner provided for external communication to the communication party that represents this externalbusiness partner.

Assign the business components that represent your own internal system landscape externally to the communication party that represents your owncompany.

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 111 of 130

04. Create the required communication channels.

You need one communication channel for each adapter involved. Depending on whether the adapter is a sender adapter or a receiver adapter, you create thecommunication channel for the relevant sender or receiver communication component as required.

Configure Communication Channels with Industry Standard Adapters

At least one of the involved business partners uses an industry standard adapter (such as the RNIF adapter) to connect to the message protocol supported by therespective industry standard.

In this step, you configure the involved industry standard adapter using the corresponding communication channels.

For information about the values you have to enter for the parameters of the communication channel, see the configuration guide for the respective industry-standard-specific SAP business package.

More information: Setting Up Integration Based on SAP Business Packages

Configure Integrated Configuration

In this step you configure the required integrated configuration. In an integrated configuration you assign the required communication channels to the relevantsender/receiver pairs. You also specify the agreed security settings (if they are supported by the adapters used).

Perform the following steps:

01. Create an integrated configuration for each sender/receiver pair that requires a sender adapter for inbound processing.

02. Define a header mapping for the integrated configurations that describe the communication with your external business partner. This ensures that the name ofa business component (and not the name of a business system or an integration process component) is written in the header of the outbound message atruntime.

More information:

Defining the Integrated Configuration

Defining Header Mappings

03. Specify the required security settings in the relevant integrated configurations.

Configure Logical Routing

In this step you define the logical routing.

In a B2B process, specify receiver-dependent integrated configurations for all messages that are to be sent from your business partner to the businesscomponents that you published. As the configured receivers, specify the business system components of your internal system landscape to which the messageis to be forwarded.

More Information

B2B Configuration

Configuring B2B Scenarios Using the Model Configurator

Special Development and Configuration Tasks (Dual-Stack andAEX)Procedure

More information:

Tasks Related to Message Encryption

Configuring Principal Propagation Using the Advanced Adapter Engine

Developing and Configuring B2B Scenarios

Defining Extended Receiver Determination (Advanced Adapter Engine)

Tasks Related to Message Encryption

In this section you find information related to message encryption on data base level relevant for both the dual-stack and AEX installation option.

Procedure

For the complete end-to-end description, check the corresponding chapter under Development and Configuration Tasks (Dual-Stack) AdvancedDevelopment Tasks (Dual-Stack) Security-Related Tasks , respectively Development and Configuration Tasks (AEX) Advanced Development Tasks(AEX) .

PUBLIC© 2012 SAP AG. All rights reserved.

Page 112 of 130

Configuring Service Interfaces for EncryptionProcedure

To activate message encryption at the database level for specific messages, you need to indicate the corresponding service interfaces in the ES Repository.

More information on the ES Repository: Managing Services in the Enterprise Services Repository

01. Log on to the ES Repository and open the service interface for which you want to activate message encryption.

More information on service interfaces: Creating a Service Interface

02. On the Definition tab, select Sensitive Data.

03. Save and activate the service interface.

We recommend that you specify sender and receiver interfaces as sensitive to ensure end-to-end encryption of a complete scenario.

If you configure message staging in such a way that a message version is stored after the mapping step, the receiver interface is also relevant for thismessage version.

To ensure that the message version after the mapping step is encrypted, you also need to specify the receiver interface as sensitive.

More information on staging:

Saving Message Versions in the AAE (Local Message Processing)

Saving Message Versions in the AAE (Dual-Stack Message Processing)

Activating encryption for a specific service interface might impair performance for those scenarios that involve processing of the corresponding message.

Encrypting Message Content on Database Level (Local IE)

This section describes all the configuration steps to be performed to enable message encryption at the database level in business systems with a localIntegration Engine.

All SAP systems based on Application Server ABAP release 6.20 or higher contain a local Integration Engine, also when used as an application system.This local Integration Engine enables the system (when used as an application system) to connect to another system via an SAP NetWeaver PI runtimeengine. This kind of connectivity is also referred to as connectivity based on the proxy runtime. All other systems – either SAP or third-party – connect to theSAP NetWeaver PI runtime using adapters.

Procedure

Configuration Tasks

Define the encryption keys and maintain the Personal Security Environment (PSE):

01. Call transaction SSFA.

02. Choose New Entries.

03. Select the SSF application PI Key1 DB Message Encryption.

This SSF application is predelivered.

04. For Encryption Algorithm, select the value TRIPLE-DES .

05. Save your changes.

SAP recommends not to change the name of the PSE file (field Private Address Book). In case you nevertheless like to change the name, consider thefact that the maximum name length is 25 characters. The reason for that is that the ENCRYPTION_KEY parameter value is restricted to this length.

Example

Caution

Note

Note

Caution

PUBLIC© 2012 SAP AG. All rights reserved.

Page 113 of 130

06. Repeat these steps for the SSF application PI Key 2 DB Message Encryption.

07. Call transaction STRUST.

08. Position the cursor on the entry SSF PI Key 1 DB Message Encryption.

09. In the context menu, choose Create.

10. For Algorithm, select the value RSA .

11. Repeat these steps for the entry SSF PI Key 2 DB Message Encryption.

12. Check if entries for all application servers are indicated as ok (green traffic light).

Note the following recommendations related to your activities using transaction STRUST:

Choose a suitable key length (recommendation: 2048 bytes).

As far as the requirements of the scenario allow, choose a suitably long validity period for the key. Otherwise take suitable measures to prepare yourbusiness processes and systems for key expiration.

Create backups of the keys by exporting them. Furthermore, be careful when deleting keys. There might still be messages stored in the database thatcannot be read without the key.

Finish encryption configuration on the Integration Engine and prepare to activate encryption for the sensitive service interface.

01. Call transaction SXMSIF.

02. Choose New Entry.

03. Enter an ID for the service interface (field Sender/Receiver ID).

04. Call the input help to select the sender service interface for which encryption should be activated (fields Interface Name and Interface Namespace).

You can select the service interfaces from the Enterprise Services Repository.

05. Under Component, enter * .

06. Note the value of Sender/Receiver ID for the following steps.

Depending on your scenario, you need to perform the same steps for the receiver service interface.

To finish Integration Engine configuration, perform the following steps:

01. Call transaction SXMB_ADM.

02. Choose Integration Engine Configuration.

03. As Category, choose Runtime .

04. Choose Configuration.

05. Create a new entry with the following settings:

In the Parameters column, select ENCRYPTION_KEY .

In the Current Value column, select the key that was defined previously using transaction STRUST.

Use the input help to make your selections.

06. Create another entry with the following settings:

In the Parameters column, select ENCRYPTION_ACTIVE .

In the Subparameter column, select the ID defined (for the service interface) previously using transaction SXMSIF.

In the Current Value column, enter 1 .

Checking Usage of Keys

You can find out for each key which messages are encrypted by this key.

If a key has been compromised, the administrator can find out if the key is still in use for message encryption.

To do this, perform the following steps:

01. Call transaction SXMB_CHK_ENCKEY.

You can alternatively call the Object Navigator (transaction SE80) and then start program RSXMB_CHECK_ENCKEY_USAGE .

02. You can display a list of messages encrypted either for a specific key or for all keys in use.

Configuring Principal Propagation Using the Advanced Adapter

Note

Example

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 114 of 130

Configuring Principal Propagation Using the Advanced AdapterEngine

You can configure principal propagation using the Advanced Adapter Engine (AAE) interconnected between sender and receiver.

The following description always assumes that there is an AAE located between the sender and the receiver.

This scenario can be implemented in one of the following cases:

You use the Advanced Adapter Engine Extended as installation option.

You use the dual-stack installation option of SAP NetWeaver PI and configure local message processing by the AAE.

You can configure principal propagation on the basis of authentication assertion tickets (as authentication method).

This option is supported by the SOAP and RFC adapter.

Procedure

Configuring principal propagation in general involves the following tasks:

Configuring involved back-end systems (for sender and receiver)

Configuring a trust relationship for involved components

Special configuration tasks for sender components

The following sections provide detailed information on these tasks.

One example set up is illustrated in the following figure.

Propagating Identities From a Sender to a Receiver With an AAE Interconnected

In this set up, a user context is propagated from a sender component to a receiver component with an AAE interconnected. Two communication paths have to beconfigured. On the first communication path (in the figure at left), the sender (acting as client) calls the AAE (acting as server). On the second communication path(in the figure at right), the AAE acts as client when calling the receiver (acting as server).

Configuring Back-End Systems Based on AS ABAP

For involved sender or receiver component that are based on AS ABAP, perform the steps as described under Enabling Principal Propagation for ABAPMessaging Components.

Configuring a Trust Relationship for Involved Components

The AAE supports principal propagation based on SAP assertion tickets. For all involved components, you have to perform configuration steps as described indetail under Configuring a Trust Relationship for SAP Assertion Tickets.

The configuration procedure depends on the underlying stack (AS ABAP or AS Java) and on whether the component acts as client or as server on a specificcommunication path. Therefore, refer to the corresponding sub chapter in the section linked to above.

For example, for the configuration of sender components based on AS Java, refer to sub section AS Java: Client Side (under Procedure). The same subsection applies for the configuration of the AAE in order to send messages to a receiver component (right hand communication path in figure above).

Sender-Specific Configuration Steps

For sending components (left hand side in figure above), the following configuration steps are necessary – depending on the used communication protocol.

More information: Configuring the Sender

Configuration Steps in the Integration Directory

In the Integration Directory, specify between which entities principal propagation is to take place.

Follow the sequence of tasks as described under: Setting Up Scenarios Using Local AAE-Based Message Processing (under 2. Configure IntegrationContent).

If you would like principal propagation to occur between a sender and a receiver using the AAE, consider the following additional aspects:

Configuration of sender and receiver communication channel.

Note

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 115 of 130

When you use a SOAP adapter (sender or receiver), as Message Protocol choose XI 3.0 .

In the involved SOAP receiver channel, you have the following options to configure connection parameters and authentication (tab General):

You can choose HTTP Destination as Addressing Type.

In that case, configure the relevant destination using SAP NetWeaver Administrator and ensure that this HTTP destination uses Authentication: AssertionTicket.

You can choose URL Address as Addressing Type.

In that case you have the following options:

Specify the target URL for an SAP receiver system and add the following string at the end of the URL (in field Target URL): &sap-client=<number of clientaddressed>.

For Authentication Mode, choose Anonymous Logon.

Specify the target URL for an SAP receiver system and skip the &sap-client=<number of client addressed> string at the end of the URL.

In that case, as Authentication Mode, choose Use logon data for SAP system and specify the client of the target system. Leave all other fields underAuthentication Data empty.

Implementing principal propagation from the sender to the AAE.

In the corresponding integrated configuration, on the Inbound Processing tab page select the Principal Propagation check box. If this check box is selected,the signature of the sender ticket is verified and the corresponding user can log on to the AAE.

The check box is only displayed if you have assigned the integrated configuration a sender communication channel with the appropriate adapter type.

Implementing principal propagation from the AAE to the receiver.

In the corresponding integrated configuration, select the Principal Propagation check box on the Outbound Processing tab page.

The check box is only displayed if you have assigned the integrated configuration a receiver communication channel with the appropriate adapter type.

It is recommended that you select both check boxes (on the Inbound Processing and on the Outbound Processing tab page) to ensure an end-to-endconfiguration of principal propagation.

In case that, for example, only the check box on the Inbound Processing tab page is selected, the user as configured in the receiver channel is used to callthe target system (instead of the intended user which is propagated from the sender to the AAE).

Developing and Configuring B2B Scenarios

When company-internal scenarios are developed and configured, typically all the details of a system landscape are known to the expert performing theconfiguration tasks. .

This is typically the case in small or midsize companies with a manageable size and structure of the system landscape.

However, in larger enterprises or in scenarios spanning different enterprises, this assumption can no longer be made. This section provides information about howbusiness-to-business (B2B) scenarios can be managed with SAP NetWeaver PI. In a B2B scenario, business partners (this can be whole enterprises which arein a business relationship with each other) communicate and exchange data with each other based on an IT infrastructure without knowing all details of the wholesystem landscape. In light of this fact, the concept behind the Integration Directory can be adapted to be used in a more flexible and generic way in order to caterfor just such cases.

More information: B2B Configuration

Procedure

More information on the procedure to set up B2B integration based on a process integration scenario: Configuring B2B Scenarios Using the ModelConfigurator

SAP provides industry-specific business packages to support the B2B integration of industry standards, such as RosettaNet for the high-tech industry.

More information on the general procedure to set up scenarios based on industry-specific business packages: Setting Up Integration Based on SAPBusiness Packages

Note

Note

Recommendation

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 116 of 130

Configuring B2B Scenarios Using the Model Configurator

The model configurator supports the configuration of business-to-business (B2B) processes.

For the purposes of this section, it is assumed that you are configuring a process integration scenario.

B2B Communication

In a B2B scenario, a minimum of two parties communicate with each other. The internal system landscapes of the parties are only made partially public or not atall. The parties communicate using business components.

When you design a process integration scenario, you can predefine B2B communication by classifying an application component as an External Party with B2BCommunication (a B2B component in short). All connections to and from a B2B component are known as B2B connections.

In the graphic below, B2B communication between two communication parties is shown schematically:

B2B Communication Between Two Parties

The integration expert configuring the process integration scenario for party A only has access to the details of party A’s internal system landscape. Therefore, hecan only define communication components for business systems from this part of the system landscape. He does not have access to details about the internalsystem landscape of party B. The situation is the opposite for an integration expert who configures the process integration scenario at party B.

Configuring B2B Scenarios

Below are the steps that need to be performed at party A to configure the B2B scenario.

When designing the process integration scenario that you are using as a configuration template, you must have predefined B2B communication as a B2Bcomponent by creating an application component.

You perform the following steps in the model configurator.

1. Assign Communication Components

When assigning the communication components for the application component of party A, do the following:

01. First assign the communication components for the internal systems (business systems) that are responsible for the processing of the messages (tab pageBusiness System Components for A2A)

02. Determine the business components to be used for B2B communication with external party B (tab page Business Components for B2B).

These business components are “visible” to party B.

03. Assign the communication components that were defined for the internal systems (business systems) system 1…n to the business component (at party A)(tab page for Business Components for B2B).

If any business components are missing, you can create them directly when assigning the components.

2. Configure B2B Connections

Senders and receivers are connected by joining together their respective business components when configuring the B2B connection.

The communication channels at the sender and receiver must be defined to define the technical details of message exchange. If, in the process integrationscenario used as the template for configuration, communication channel templates are assigned to a connection, they can be used to create new communicationchannels. You can reuse or copy existing communication channels.

3. Generate the Configuration Objects

The following B2B-specific settings are preconfigured when generating the configuration objects:

The corresponding configuration object (receiver agreement for dual-stack installation or integrated configuration for AEX) with sender party B also contains partyA’s business component as a virtual receiver in the key. The communication components that were defined for the internal systems (systems 1...n) are alsoentered as assigned receivers. At runtime, the messages sent from party B to party A's business component are also forwarded to the internal systems 1...nby means of receiver-dependent routing.

You must create the routing conditions for the assigned receiver manually after generation is complete.

Caution

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 117 of 130

A header mapping is predefined in the corresponding configuration object that defines the outbound processing for the message for party B as the receiver(receiver agreement for dual-stack installation or integrated configuration for AEX). The header mapping maps the communication components of the internalsystems 1...n to party A’s business component. Therefore, party A’s business component is entered as the sender in the header of the messages sent from theinternal systems 1…n to party B.

You can use the model configurator to configure both party-integrations (B2B connections) and connections between internal systems.

More Information

B2B Configuration

Configuring Process Integration Scenarios (for dual-stack installation)

Configuring Process Integration Scenarios (for Advanced Adapter Engine Extended)

Setting Up Integration Based on SAP Business Packages

To address B2B integration challenges for specific industry sectors, several standards have been developed for the exchange of business data in theseindustries.

SAP Business Packages for RosettaNet and CIDX

SAP provides industry-specific business packages to support the B2B integration of industry standards, such as RosettaNet for the high-tech industry.

The RosettaNet Implementation Framework (RNIF) standard, developed by the organization RosettaNet, defines processes, interfaces, and transport protocolsfor the exchange of business data in the high-tech industry (for example, in the electronics industry).

To facilitate the setup of B2B interactions with business partners compliant with an industry standard, SAP provides business packages containing both therelevant integration content in the ES Repository that allows the mapping to these standards, and the industry-specific adapters that enable an external standard tobe technically connected with the integration broker. SAP provides business packages for RosettaNet, Chemical Industry Data Exchange (CIDX), and Standardsfor Technology in Automotive Retail (STAR).

When you have installed the Advanced Adapter Engine Extended (AEX), integration processes cannot be used. Therefore, those scenarios of the businesspackage that use integration processes are not supported in that case.

Support of Electronic Data Interchange (EDI)

SAP NetWeaver Process Integration also supports the integration with United Nations/Electronic Data Interchange For Administration, Commerce, and Transport(UN/EDIFACT), the international standard for Electronic Data Interchange (EDI).

To ensure connectivity with systems based on this standard, you can use the SEEBURGER business packages for SAP NetWeaver PI. Over the past years,SEEBURGER has developed a large number of EDI adapters, including thousands of mappings and dozens of EDI communication protocols, for differentscenarios in various industries.

Structure of the Business Packages

SAP business packages are structured in the following way:

They contain:

Integration content that describes the industry standard interfaces

Integration content that describes the mappings of SAP standard interfaces to industry standard interfaces

For more information about structuring business packages and how the current industry standard is mapped as content in the Enterprise Services Repository,see Structure of Business Packages.

Adapter metadata for the industry standard adapter — you use the RNIF or CIDX adapter to connect to the message protocol supported by the relevant industrystandard (RNIF adapter to connect to RosettaNet Implementation Framework and CIDX to connect to Chem eStandards).

You can use the business packages provided by SAP to define your own processes based on these industry standards. Usually, the most important task is todevelop new mappings between your application and the interface of an industry standard.

Procedure

You set up the integration by following the following general procedure:

01. Install the SAP business package

Download the relevant SAP business package and import the corresponding industry-specific integration content to the ES Repository.

You can find the SAP business package in SAP Software Distribution Center at http://service.sap.com/swdc (SAP Service Marketplace login

Note

Note

Caution

PUBLIC© 2012 SAP AG. All rights reserved.

Page 118 of 130

required). Select the Downloads tab. In the navigation area, choose Support Packages and Patches Browse Our Download Catalog SAP Content .Choose ESR Content (XI Content). Note that the authorizations for downloading process integration content are generated automatically depending on yourlicenses. For example, look for the package XI CONTENT CIDX ERP for the integration content that describes the mappings of SAP standard interfaces toCIDX interfaces.

02. Define a new software component version in the System Landscape Directory for your development

This ensures that your developments are not overwritten by SAP updates later on.

This software component version must be based on the software component version that contains the business package.

See the explanations as provided under Using Predefined Integration Content.

03. Import the software component version to the Enterprise Services Repository

04. Define the content in the Enterprise Services Repository

In this phase, you build your integration content based on the predefined industry-specific integration content you have imported.

The integration design for RosettaNet and CIDX is based on process integration scenarios.

05. Configure the integration.

More information: Configuring B2B Integration

Structure of Business Packages

The business packages for RosettaNet and CIDX comprises the following software components:

Content of Business Packages

Software Component Name Content

Application-independent software component<Industry Standard ID>

CIDX

Describes the industry standard

Application-dependent software component<Industry Standard ID> <Application ID>

CIDX ERP

Describes the mapping of standard interfaces of an SAP application to industry standard interfaces.

Naming Conventions for Namespaces

Application-independent software component

Objects in this software component are dependent on the version of the industry standard. For this reason, the namespace contains the industry standardversion according to the following schema:

http://sap.com/xi/<Industry Standard Name>/<Industry Standard Version Identifier>

Application-dependent software component

Objects in this software component are dependent on the version of the industry standard and on the release of the application. For this reason, the namespacecontains the industry standard version and the application release according to the following schema:

http://sap.com/xi/<Industry Standard Name>/<Industry Standard Version Identifier>/<Application>/<ApplicationRelease>

For more information about the special versions of the relevant industry standard (RosettaNet/CIDX) in Process Integration Content, see:

Business Package for RosettaNet

Business Package for CIDX

Business Package for CIDX

Note

Example

Example

PUBLIC© 2012 SAP AG. All rights reserved.

Page 119 of 130

This business package supports Process Integration on the basis of the industry standard Chem eStandards, which is part of the Chemical Industry DataExchange (CIDX) organization.

Contents of the Software Component CIDX

Process Integration Content in this software component represents interfaces of Chem eStandards as they are defined in the documentation of the standard.

You can access this documentation at http://www.cidx.org .

The following table provides an overview of which object types (ES Repository) represent which parts of the industry standard. Furthermore, the namingconventions used are broken down into their different parts.

Object Type Description and Naming Convention

Process Integration Scenarios Describes the process independently of the application that is mapped with the industry standard.There is exactly one process integration scenario for each CIDX transaction in software component CIDX.Naming convention:<Transaction Name>

OrderCreate

Service Interface Describes the industry standard interface. The service interface references an external definition that describes theschema.Naming convention:<Transaction Name>

External definition Describes the data structure. The external definition contains the uploaded CIDX schema.Naming convention:<Name of the root element in the schema>

CustomerSpecificCatalogUpdate

Communication channeltemplate

Contains the technical details about inbound or outbound processing of the message using the CIDX adapter.Naming convention:<Role>_<Activity>_<Transaction Name>

Buyer_Send_ OrderCreate

Contents of Software Component CIDX ERP

ESR Content in this software component represents the mapping from SAP standard interfaces (ERP) to industry standard interfaces.

Object Type Description and Naming Convention

Process IntegrationScenarios

Describes the process depending on the application that is mapped with the industry standard, and depending on the role (Buyer orSeller).

There are two role-specific process integration scenarios for each CIDX transaction in software component CIDX ERP. The role refersto the application component that the application represents.

Naming convention:<Transaction Name>_<Role Name>

OrderCreate_Buyer

Operation mapping Describes the mapping between the source and target interfaceNaming convention:<Name of source interface>_<Name of target interface>

DesadvDelvry03_ShipNoticeIn this case, the source interface is the IDoc DESADV.DELVRY03 and the target interface is the industry standard interfaceShipNotice.

Message mapping Describes the mapping between the source and target messageThe same naming conventions apply as for operation mappings.

Mapping template Describes part of a mapping that can be used for defining a message mappingNaming convention:<Outbound Service Interface>_<IDoc Segment>_<Target Service Interface>_<CIDX-Segment>

Example

Example

Example

Note

Example

Example

PUBLIC© 2012 SAP AG. All rights reserved.

Page 120 of 130

More information:

Configuring the CIDX Adapter in the Integration Directory

Using Conventions for Communication Component Names

Business Package for RosettaNet

This business package supports Process Integration on the basis of the industry standard RosettaNet.

Contents of the Software Component ROSETTANET

ESR content (Process Integration content) in this software component represents RosettaNet partner interface processes (PIP). You can access the documentationfor this industry standard at http://www.rosettanet.org .

The following table provides an overview of which object types (ES Repository) represent which parts of the industry standard. Furthermore, the namingconventions used are broken down into their different parts.

Object Type Description and Naming Convention

ProcessIntegrationScenarios

Describes the process independently of the application that is mapped with the industry standard. The role of the application componentcorresponds to the role in the business operational view (see Business Operational View in the PIP specification).There is exactly one process integration scenario for each RosettaNet PIP in software component ROSETTANET.Naming convention:<PIP Name>

PIP0A1

Action Represents a business activity within a PIP.Naming convention:<Name of the Business Activity in the Business Flow Diagram>(see Business Operational View in the relevant PIP specification)

Distribute Notification of Failure

Service Interface Represents the business action in the business operational viewNaming convention:<Business Action Name>(see table Business Action –Business Document Mapping in the relevant PIP specification ® Column Maps To Business Document inBOV)

External definition Represents the structure of the exchanged dataNaming convention:<Name of root element in corresponding DTD file>You can download the DTD file together with the PIP specification from the RosettaNet Internet site.

Pip0A1FailureNotification

Communicationchannel template

Contains the technical details about inbound or outbound processing of the message using the RNIF adapter.Naming convention:<Role>_<Send/Receive>_<Name of the service interface>

Buyer_Receive_PurchaseOrderConfirmationAction

Contents of Software Component ROSETTANET ERP

ESR Content in this software component represents the mapping from SAP standard interfaces (ERP) to the industry standard RosettaNet.

Example

Example

Example

Example

PUBLIC© 2012 SAP AG. All rights reserved.

Page 121 of 130

Object Type Description and Naming Convention

Process IntegrationScenarios

Describes the process depending on the application that is mapped with the industry standard, and depending on the role (Buyer orSeller).

There are two role-specific process integration scenarios for each RosettaNet PIP in software component ROSETTANET. The rolerefers to the application component that the application represents.

Action See entry in table Contents of Software Component ROSETTANET.

Operation mapping Describes the mapping between the source and target interfaceNaming convention:<Name of source interface>_<Name of target interface>

OrdersOrders05_PurchaseOrderRequestAction

Message mapping Describes the mapping between the source and target messageThe same naming conventions apply as for operation mappings.

More information:

Configuring the RNIF Adapter

Service Interface Naming, RNIF 1.1

Service Interface Naming, RNIF 2.0

Defining Extended Receiver Determination (Advanced AdapterEngine)

When using routing conditions, the receivers of a message are determined at runtime by evaluating the condition (which depends on the content of the message).However, the names of the receivers have already been defined at configuration time in the Integration Directory (integrated configuration, Receiver tab).

When you configure routing that way (referred to as standard receiver determination), you have to specify the receiver names as part of the configurationprocedure in Integration Directory.

A more flexible way to configure routing is offered by the extended receiver determination.

In an extended receiver determination, you can specify a mapping program that takes over the task of finding out the actual receivers at runtime. You can designthe mapping program that way that the receivers of the message are read from a list that might be part of an external data source (mapping look-up approach).

This approach has the following advantages:

Storing receiver names in an external data source allows to update of the receiver list without the need of a cache refresh.

Storing receiver names outside the Integration Directory allows non-integration experts to maintain receivers.

This section applies to the use case when configuring message processing using the Advanced Adapter Engine only.

Procedure

01. Define a suitable mapping in the ES Repository.

More information: Mapping Messages to Each Other Using Mapping Objects

In particular, do the following:

Define an operation mapping and assign the abstract service interface ReceiverDetermination as the target interface. The service interfaceReceiverDetermination is in the Enterprise Services Repository in the software component SAP BASIS (namespacehttp://sap.com/xi/XI/System ).

Define the message mapping or mapping program that is to determine the receivers at runtime. Assign this message mapping or mapping program to theoperation mapping specified before.

The service interface uses the message type Receivers and the data type Receivers . The data type Receivers describes a list of receiversand has the following structure:

The following instance of the data type Receivers contains two receivers. The first receiver comprises a party (element Party ) and communicationcomponent (element Service ) and is identified by a DUNS number; the second receiver comprises a communication component without a party.

Note

Example

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 122 of 130

01. <Receivers>02. <Receiver>03. <Party agency="016" scheme="DUNS"></Party>04. <Service>"MyService"</Service>05. </Receiver>06. <Receiver>07. <Party agency="http://sap.com/xi/XI" scheme="XIParty"></Party>08. <Service>"ABC_200"</Service>09. </Receiver>10. </Receivers>

You can specify party and communication component for each receiver.

02. Define an integrated configuration in the Integration Directory

Enter the outbound interface of the operation mapping from above in the key of the receiver determination as the outbound interface. Assign this operationmapping to the receiver determination. Furthermore, define outbound processing (sender adapters) for all configured possible receivers.

More information on the steps to be performed in Integration Directory:

Defining the Integrated Configuration

Define Extended Receiver Determination

As for AEX no wildcards ( * ) can be used to mask the key of configuration objects, you need to specify the name of the potential receivers when definingthe integrated configuration.

If the mapping program returns an XML file with empty or missing <Service></Service> tag, the message is routed to the default receiver (that isconfigured in the integrated configuration, Receiver tab, under If No Receiver Is Found, Proceed as Follows, option Select the Following Receiver:).

Administrative Tasks

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

Procedure

Administering and Maintaining SAP NetWeaver PI

More information: Administering and Maintaining SAP NetWeaver Process Integration

Monitoring Integration Processes

SAP provides various tools for monitoring the Advanced Adapter Engine, the Integration Engine, and other components in SAP PI.

More information: Monitoring Integration Processes.

Saving Message Versions

You can store messages at runtime in the Advanced Adapter Engine (AAE) and the Integration Engine (IE) for administrative purposes.

More information: Saving Message Versions

Tasks Related to Software Logistics

Transporting Design and Configuration Objects

Process Integration landscapes in general consist of development systems, consolidation or test systems and production systems. Therefore, several ESRepositories and Integration Directories also come into play when you plan and maintain your system landscape and your processes end-to-end. Setting uptransport scenarios and transport paths is therefore a key task for administrators.

More information: Transporting ESR Content and Objects of Integration Directory

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

Syntax

Note

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 123 of 130

Change Management for Design and Configuration Objects

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

Object versions are treated in the same way in both the ES Repository and the Integration Directory.

More information:

Change Lists

(ES Repository)

Working with Change Lists (Integration Directory)

Administering Back-End Systems

To administer the back-end systems involved in an integration scenario as well as the AS ABAP or AS Java part of the Integration Server, you can use the SOAManager or SAP NetWeaver Administrator, respectively.

Using these tools, you can perform the following administrative tasks:

Monitoring services locally in the back-end system

Publishing services from the back-end system into the Services Registry (for more information: Services Registry)

SOA Manager is the administration tool for ABAP-based backends involved in integration scenarios.

You can access the SOA Manager by using the transaction code SOAMANAGER in the back-end system.

More information: Working with the SOA Manager

SAP NetWeaver Administrator is the administration tool for Java-based backends involved in integration scenarios.

You can access the SAP NetWeaver Administrator by entering the following data in a Web browser:

http://<host><port>/nwa

Here the following represents:

<host> the host where the Application Server Java is installed.

<port> the HTTP port of the Internet Communication Manager. It consists of 5<Java instance_number>00 . For example, if the instance number of theJava instance is 60 , the HTTP port is 56000 .

Monitoring Integration Processes

SAP provides various tools for monitoring the Advanced Adapter Engine, the Integration Engine, and other components in SAP NetWeaver Process Integration (PI).You can use SAP Solution Manager for central monitoring, as well as several other local monitors on Advanced Adapter Engine Extended (AEX) and dual-stacksystems.

Central Monitoring

When you have SAP Solution Manager in your landscape you can use it as a central tool for monitoring the integration processes. Within the PI Monitoringdashboard in the Technical Monitoring Work Center you can obtain an overview of all PI components in your landscape. If you find that certain processes ormessages on a particular component have to be reviewed more thoroughly, you can navigate to the corresponding local monitor on the system where thecomponent is running.

Accessing and Using Local Monitors

On each system in your PI domain you can use a local monitoring tool to monitor a PI component running on this system. Within a local monitor, you can obtaindetailed information about a specific process. Local monitors also allow you to control the process execution.

To access all local monitors in a quick and easy way use the configuration and monitoring home page: http://[host]:[port]/pimon

The monitoring frequency depends on the volume of messages processed. We recommend checking the various monitors at least once a day. It is also importantthat you frequently check the message queues to make sure that the overall message flow is working. If there are problems in a specific queue, no messages inthis queue are processed.

Local Monitoring on AEX Systems

The local monitors on an AEX system are available in SAP NetWeaver Administrator. They can be accessed at: http://[host]:[port]/nwa

Local Monitoring on Dual-Stack Systems

SAP provides the following local monitoring tools on dual-stack systems:

Identically to AEX systems, you can monitor the processes on the Advanced Adapter Engine and the Business Process Engine using the tools available inSAP NetWeaver Administrator.

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 124 of 130

These tools can be accessed at: http://[host]:[port]/nwa

You can monitor the processes on an Integration Engine using the tools available in transaction SXMB_MONI .

These tools can be accessed in SAP GUI, as well as with a browser using SAP GUI for HTML.

You can monitor the processes on an Integration Engine using the tools available in Runtime Workbench.

These tools can be accessed at: http://[host]:[port]/rwb

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

More Information

Monitoring the Advanced Adapter Engine

Monitoring the Integration Engine

Monitoring Integration Processes using NetWeaver Administrator

Saving Message Versions

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

Procedure

You have the following options to store messages at runtime:

Staging

Versions of asynchronous messages can be stored after specific steps at runtime. An administrator can then edit the message, for example, in order to correctfaulty data in the payload, and then restart and process the message again.

This function is only available for messages processed by the AAE.

Message logging

Versions of synchronous and asynchronous messages can be stored after specific steps at runtime to make them available for logging purposes at a laterpoint in time. Logged messages are only available in display mode and cannot be restarted any more.

Global Configuration of Staging

Find below more information on how to configure staging globally, that means, for all scenarios running in a PI landscape.

This function is available for asynchronous messages processed by the AAE.

Configuring Staging on the Advanced Adapter Engine

When you use the dual-stack implementation option of SAP NetWeaver PI, you can configure staging on the AAE for two different kinds of message processingscenarios:

Dual-stack message processing (including the IE)

In scenarios of this type, both AS ABAP and AS Java are involved for message processing at runtime.

This kind of message processing has been available in the very first releases of SAP NetWeaver PI. It is configured using the configuration objects receiverdetermination, interface determination, and sender/receiver agreement in Integration Directory.

More information: Saving Message Versions in the Advanced Adapter Engine (Dual-Stack Message Processing)

“Local” message processing on the AAE

This kind of message processing involves only the Advanced Adapter Engine at runtime, the ABAP stack is not involved at all.

Scenarios of this type are configured using the integrated configuration in Integration Directory.

This kind of staging is also the only available option in case you use the Advanced Adapter Engine Extended.

More information: Saving Message Versions in the Advanced Adapter Engine (Local Message Processing)

Global Configuration of Logging

Find below more information on how to configure this function globally, that means, for all scenarios running in a PI landscape.

This function is only supported for synchronous messages.

Configuring Logging on the Integration Engine

More information: Logging and Tracing (Integration Engine).

Configuring Logging on the Advanced Adapter Engine

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 125 of 130

You can log messages either in the pipeline of the Advanced Adapter Engine or within the processing of a chain of modules of an adapter.

Configuring Message Logging (Within AAE Pipeline)

Configuring Message Logging (Within Adapter Module Chain)

Scenario-Specific Configuration of Staging and Logging

You can configure staging and logging of messages for specific scenarios that are covered by an integrated configuration.

This option is only available for AAE-only message processing.

To perform scenario-specific configuration of staging and logging, open the corresponding integrated configuration in Integration Directory and choose tab AdvancedSettings.

Proceed as described under: Configuring Advanced Settings for Message Storage

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

Displaying Message Versions on the Integration Engine

You can display versions of messages processed by the IE. You can compare message versions in order to analyze what changes to the message were madeby the individual processing steps of the pipeline.

More information: Displaying Message Versions (Integration Engine).

Transporting ESR Content and Objects of Integration Directory Use

Objects in the Enterprise Services Repository (ES Repository) are referred to as design objects, while objects in the Integration Directory are referred to asconfiguration objects. The transport consists of an export from the source repository or source directory and an import to the target repository or target directory.These transports can be used as follows:

● To copy design objects from one ES Repository to another ES Repository. The software component version must be the same in the source and targetrepository in this case. In this way, you provide the design objects of the ES Repository using export files. Importing ESR Content briefly describeshow customers import this ESR content to their ES Repository.

● To copy configuration objects from one Integration Directory to another Integration Directory. In this way, you can copy a test configuration to a productivelandscape.

Prerequisites

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

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

Procedure

1. On the basis of your system landscape consider a transport landscape with which you set out between which systems ESR content or configuration objectsare to be transported.

2. Transport the ESR content.

More information: Transporting ESR Content

3. Transporting configuration object.

More information: Transporting Configuration Objects of the Integration Directory

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

Further Information

Process Integration Transports

PI Transports Using the Change Management Service (CMS)

Transporting Objects using CTS

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 126 of 130

Process Integration Transports General

When you develop your applications you must differentiate between two types of development objects:

● Design objects from the ES Repository and configuration objects from the Integration Directory.● Objects in the different application systems. These are Java and ABAP classes, client and server proxies generated using proxy generation, ABAP

programs, and other development objects that implement the actual application logic.

The functions for transporting design and configuration objects described in this section can only be used to transport ES Repository objects or Integration Directoryobjects. All objects that are developed in the application systems (proxy objects included) must be shipped using their infrastructure. In particular, you mustensure that the objects of your application from the ES Repository are shipped together with the objects of the application system.

More information:

● For more information about the organization and transport of ABAP development objects, see Change and Transport System – Overview (BC-CTS).

● For more information on the organization and transport of Java development projects, see Tasks

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

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

Transport Support for PI Transports

You can perform ESR content transports and Integration Directory Transports in the following ways:

● You manually export the contents as a file from the initial system and then import this file into the target system (file system-based transport).● Using the Change Management Service (CMS).

More information: PI Transports Using the Change Management Service (CMS)

PI Transports Using the Change Management Service (CMS) General

Use the following tools for PI transports using Change Management Services (CMS).

· Landscape Configurator - allows you to set up the transport landscape using XI tracks.· Enterprise Services Builder - to export ESR content of the development system or of the consolidation system (for emergency corrections) and to track

completed transports.· Integration Builder for Integration Directory transports - to export configuration contents of the development system or of the consolidation system (for short

notice changes) and to track completed transports· Transport Studio - to perform transports using CMS:

This section focuses on the basic steps and options for CMS transports. More detailed procedures are referenced at the relevant points.

Configuration of the Transport Landscape

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

PUBLIC© 2012 SAP AG. All rights reserved.

Page 127 of 130

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

PI Transports within a Transport Landscape

In CMS mode, you perform transports using the ES Builder (for design objects) or the Integration Builder (for configuration objects) and the CMS Transport Studio.The tools focus on the following transport areas:

Transport Functions in the ES Builder/Integration Builder and Transport Studio

ES Builder/Integration Builder

Determining the object set for transport

Status Display

Resolving conflicts in imports

Finding Transports

Transport Studio: Importing change requests to the target system(Development, Consolidation, Assembly)

Assembling software component versions (Assembly)

Quality assurance step (Approval)

We will assume that the software component version of the objects that are to be transported is released for transport using the CMS. SAP provides a softwarecomponent version for the entire content of the Integration Directory.

Transport Entities in ES Builder/Integration Builder

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

Change Lists

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

Transport Lists

To compile a list of objects independently of change lists, you use the transport wizard to create transport lists. To create a transport list, proceed as follows:

1. Choose Tools → Export Design Objects (Enterprise Services Builder) or Tools → Export Configuration Objects (Integration Builder).

2. Select the Transport Using CMS mode and determine the object set in the next step.

PUBLIC© 2012 SAP AG. All rights reserved.

Page 128 of 130

You can use change lists as a filter when determining the object set in the transport wizard. Objects lists compiled in this way nevertheless have all thenormal properties of a transport list.

Both the ES Builder and the Integration Builder display the transport list on the Change Lists tab page. This list is transferred directly to the CMS and has thestatus Waiting for export… until the process is complete. Object versions that are active at the time the transport list is compiled are transported in a transport list.

Interaction with the Transport Studio

Within an XI track you can transport objects from a development system (DEV) to a consolidation system (CONS) and then from the consolidation system (CONS)to a productive system (PROD). Both the ES Builder and the Integration Builder offer different options for defining the transport entities depending on the targetsystem:

Transport Units by XI Track and Transport Scenario

Type of XI Track Supported Transport Units(Depending on Transport Scenario)

From DEV to CONS From CONS to PROD

ES Repository Change and transport lists Usually:Software component versions (in the Transport Studio)

Change and transport lists (emergency corrections in the ES Builder)

IntegrationDirectory

Transport lists(objects of a party, service, or configurationscenario)

Usually: Change lists(after their import and manual release in the Integration Builder or further changes in theconsolidation system)You can also create new transport lists.

Complete copy(in the Transport Studio; for example, for an initial distribution of the entire directory content)

As shown in the table, the usual transport units and the necessary steps depend on the type of the XI track (Enterprise Services Repository or IntegrationDirectory) and the transport scenario.

In the CMS Transport Studio, there are a number of tab pages for each track, which you work through one after the other during a transport. The tab page on whichyour exported change or transport lists are shown depends on the Integration Builder or ES Builder you are working with (development, consolidation, or productivesystem). The following figure shows the process for the Integration Builder. The process is the same for the ES Builder.

You usually export transport requests from the development system, which appear in the import queue of the Transport Studio for the consolidation system. Youcontrol the rest of the transport from here. Exceptions:

· In the consolidation Integration Directory, change lists are usually generated when changes are imported. You must check and release these change lists inthe Integration Builder before you can transport them further with the Transport Studio.

· If you have to make emergency corrections in the ES Repository of the consolidation system, you export change or transport lists, which appear in theTransport Studio (as in the Directory case). You can then either reassemble the whole software component version (in the Assembly step) or create apackage containing just the changes for the productive system.

More information: Transporting Design Objects and Transporting Configuration Objects

The table below summarizes the transport procedures in the CMS. The sequence of the tab pages in the Transport Studio corresponds to the transport route withina track.

Development Status of the XI Track in the Transport Studio

Step Tab Page Use

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

0 Development This import queue contains checked-in archives and exports from other XI tracks connected to this track (more information: Connecting Tracks).

1 Consolidation Once a transport request has been exported in the development ES Builder/Integration Builder, this is where the change requestsappear for each software component version for import to the consolidation system (ES Repository or Integration Directory).

2 Assembly After import in the consolidation system, this is where you assemble transports of software component versions.

3 Approval This tab page displays assembled software component versions. You use this step for quality assurance, to decide which changes toimport to the productive system.

4 Production After approval, the transport is ready for import to the productive system. The corresponding tab page is only displayed if you haveentered a productive system in the corresponding track.

PUBLIC© 2012 SAP AG. All rights reserved.

Page 129 of 130

Transporting Configuration Scenarios

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

Procedure

01. To transport configuration scenarios, define groups of business systems in the System Landscape Directory in which the business systems that have beenpre-defined for different areas of use (for example, testing and production operation) are grouped together.

For more information, see: Tasks in the System Landscape Directory

02. To ensure configuration content can be imported and exported without any problems, in the System Landscape Directory, you must define (prior to import)which business systems correspond to each other in the various business system groups.

For more information, see: Configuring Groups and Transport Targets

03. You can now transport the configuration scenario.

Additional Information Transporting ESR Content and Objects of Integration Directory

PUBLIC© 2012 SAP AG. All rights reserved.

Page 130 of 130