Concepts

PDF download from SAP Help Portal:

http://help.sap.com/saphelp_nw73ehp1/helpdata/en/cc/af121d92e1445483dcc57dd5f5ba8e/content.htm

Created on May 25, 2015

The documentation may have changed since you downloaded the PDF. You can always find the latest information on SAP Help Portal.

Note

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

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

Table of content

PUBLIC Page 1 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 Table of content
1 Concepts
1.1 Basics
1.1.1 Introduction
1.1.2 Key Capabilities
1.1.2.1 Connectivity
1.1.2.2 Mapping
1.1.2.3 Routing
1.1.3 Installation Options
1.1.4 Phases of an Integration Project
1.1.4.1 Design Time
1.1.4.1.1 Top-Down Design
1.1.4.2 Configuration Time
1.1.4.3 Runtime
1.1.4.3.1 Messages
1.1.5 Process Integration Landscapes
1.1.5.1 Using Local and Central Enterprise Services Repositories
1.1.5.2 Using Central and Non-Central Advanced Adapter Engines
1.1.5.3 Using Local and Central System Landscape Directories
1.2 Advanced Concepts
1.2.1 Using Predefined Integration Content
1.2.2 Interface Objects
1.2.3 Mapping Objects
1.2.3.1 Mapping Programs
1.2.3.2 Operation Mapping
1.2.3.3 Message Mappings (Overview)
1.2.3.4 User-Defined Functions and Function Libraries
1.2.4 Describing the System Landscape in the SLD
1.2.5 Separation of Business Systems and Technical Systems
1.2.6 Collaboration Profile
1.2.7 Content-Based Routing
1.2.8 B2B Configuration

PUBLIC Page 2 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 1 Concepts

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

Note
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.

1.1 Basics

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

Note
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
are oriented.
Process Integration Landscapes
Describes the different options how to design landscapes of PI components.

1.1.1 Introduction

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

Note
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 the
process 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 components
can run on different systems, can be hosted in different departments of a company, or can be implemented in completely different companies that have a
business relationship with each other. The application components exchange data with each other and thereby ensure that the value chain of the business
process 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 application
component, but rather on how the application components exchange data with each other. Process integration is all about choreographing the exchange of data
between application components.
Mediation
Technically, the business logic of different application components in an integration scenario is implemented on different systems. Let us assume that the
systems involved in an integration scenario communicate directly with each other. For example, if the application components run on different SAP systems, one
SAP system calls another using a remote function call. We call this kind of communication "point-to-point" or "direct communication" . However, an upgrade to one
part 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 case
of 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 all
integration-relevant information accessible at one central location. In contrast to the point-to-point scenario (where there is a "spaghetti-like" arrangement of
connections), 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:

PUBLIC Page 3 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 Figure 1: 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-based
integration. The messages contain the business data exchanged between the systems involved in a cross-component process. The message protocol of SAP
NetWeaver PI (which the runtime engine can process) is based on the W3C standard SOAP Messages with Attachments.
More information: Messages

1.1.2 Key Capabilities

Use
This section provides a summary of the key capabilities of SAP NetWeaver PI.
More information:
Connectivity
Mapping
Routing

1.1.2.1 Connectivity

Use
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 a
technical level and that are necessary to connect the system to the runtime engine of SAP NetWeaver PI are performed by adapters. SAP NetWeaver PI provides
a variety of adapters to connect applications that are based on completely different technical or application-specific protocols. The runtime engine transforms each
incoming 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 to
as: sender adapter). Depending on the characteristics of the receiver system, an adapter at the outbound side (a receiver adapter) then transforms the internal
message format into the format or protocol the receiver system can handle.

Note
Do not confuse connectivity with mapping: Connectivity implies transformations between the technical or industry-specific protocols of the connected
applications. A technical "protocol" can, for example, be a simple file format, or an IDoc format. An industry-specific protocol can be RosettaNet or EDI. In
contrast to that, mapping is the transformation of the business data in the payload of the message, which can, for example, include the transformation of one
data 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 by
partners.
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.

PUBLIC Page 4 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 Figure 1: Connectivity Capabilities of SAP NetWeaver PI

1.1.2.2 Mapping

Use
In scenarios spanning different application systems, or even different organizations and enterprises, it is most likely that the structure of the data exchanged
between two process components differs on both sides of a connection due to business-related reasons. To enable a seamless exchange of data, the data
structures 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

Note
Mapping describes transformations at the level of the business data that is exchanged between process components. This can also include special formats
for particular business entities, for example, the format of a time field in a message. Transformations at the level of the technical transport protocol are handled
by 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 systems
connected to each other rather than process components. But keep in mind that mappings can already be defined at design time.

Figure 1: Simple Mapping Concatenating one Single Field of a Source Structure into 2 Target Structure Fields

PUBLIC Page 5 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 1.1.2.3 Routing

Use
Routing covers all rules that define the flow of messages between different systems at runtime. SAP NetWeaver PI supports in particular routing that depends on
the 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 message
field 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 specific
receiver 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:

Figure 1: Routing a Message to Three Different Receiver Systems

1.1.3 Installation Options

Use
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 are
technically based on the runtime engines. When you install SAP NetWeaver PI, you install one or more runtime engines on a host system. SAP NetWeaver PI
provides 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.

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 System Landscape Directory), as well as the
following runtime engines:
Integration Engine
Business Process Engine
Advanced Adapter Engine
More information: SAP NetWeaver PI Dual-Stack Installation

Advanced Adapter Engine Extended (AEX) Is technically based on AS Java only .

Provides tools for designing and configuring integration content (Enterprise Services
Repository, Integration Directory and System Landscape Directory), as well as the
Advanced Adapter Engine as runtime engine.

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

Note
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

PUBLIC Page 6 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 Note
You have also the option to combine the Process Integration capabilities of the AEX with SAP NetWeaver Business Process Management by installing
Process Orchestration .
For more information, see SAP NetWeaver Library at help.sap.com under SAP NetWeaver Library: Function-Oriented View Process Orchestration .

Caution
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 for
enhanced service orchestration as part of a dual-stack SAP NetWeaver installation. It is based on both Application Server Java and Application Server
ABAP. 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
to systems 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.

Figure 1: Connectivity Options of SAP NetWeaver - Dual-Stack and AEX

1.1.4 Phases of an Integration Project

Use
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,

PUBLIC Page 7 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 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 PI
is to de-couple the business semantics from the technical details of the concrete system landscape. Business semantics are, for example, the business flow of a
process and its separation into individual application components, as well as the structure of exchanged data. These aspects of a business process are merely
determined 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 of
a particular system landscape. We call the corresponding phase of an integration project the design time . In other words, at design time, you can specify an
integration 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 the
integration scenario is executed is referred to as runtime . You can consider one and the same integration scenario being deployed on completely different
system landscapes. For example, in one case there is a material management integration scenario that spans only a few systems within a midsize company,
whereas in another case the same integration scenario spans several hundreds of systems located in the different departments of a large enterprise. The same
scenario in this 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 an administrator.
The following figure illustrates the relationship of the design time and runtime view:

Figure 1: 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 sends
a 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 the
requestor 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

1.1.4.1 Design Time

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

PUBLIC Page 8 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 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
process integration 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 being
exchanged
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
receiver can 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. This type of transformation is called mapping . You specify the corresponding transformation rules in the ES Repository - in the form of mapping
objects.

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

Recommendation
It is recommended to design integration content using the top-down design approach.
More information: Top-Down Design

1.1.4.1.1 Top-Down Design

Use
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 process
components 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 a cross-component process - or how process Process models
components interact with each other You 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 (interface objects, mapping objects, and communication
channel templates).

Specifying how one process component (or application component) exchanges messages Interface objects
with another There are different interface object types available that describe these aspects - from the
communication mode of message exchange down to the detailed data structure of a
message.

Specifying how data structures are transformed into each other Mapping objects

Pre-configuring connectivity/adapters Communication channel templates

You use communication channel templates to specify those adapter settings for
connectivity that are already known 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 The
interface objects defined in the ES Repository are merely metadata that are independent from any programming language. Using proxy generation, you convert
non-language-specific interface descriptions into executable interfaces.

1.1.4.2 Configuration Time

Use
At configuration time, an integration expert (for example, an integration consultant) configures the integration scenario specified at design time for a specific system
landscape 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 the
corresponding process components.

Note
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.

PUBLIC Page 9 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 These are typically systems or applications and are represented at configuration time by communication components . In addition to that, you define the
communication 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
runtime engine 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 (which arrives at the runtime engine), the configuration expert has to determine what should happen with this message - for example, which
receiver systems it is to be sent to, or how it is to be mapped.
Configuration of Message Exchange
The following figure illustrates what happens with an incoming message:

Figure 1: 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 to
decrypt 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.

Note
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
is handled 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 transformation
step: 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 security
standards are agreed on with the receiver.

Note
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 the
context 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 the
interface 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 the
incoming (or inbound) message as seen from the perspective of the runtime engine. In other words: The incoming message (as used in the configuration time
context) 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

1.1.4.3 Runtime

Use
The business process is executed in the system landscape at runtime, which means that the process is executed and messages are exchanged between the

PUBLIC Page 10 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 systems 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:
1. 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 ( "XI
message format" ). In case also additional security-related configuration settings apply, the message is handled accordingly.
2. Runtime engine pipeline processing
Processing of the message in the pipeline contains the following steps:
1. Inbound XML validation
Based on the configuration settings, the inbound message is checked with regard to validity of its XML schema.
2. 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
routing conditions are evaluated. The receiver is written into the message header. In case multiple receivers are configured, for each receiver, a
separate message is created.
3. Mapping
Based on the configuration setting (mapping configuration) that is found in the runtime cache for the message, the assigned mapping program is
performed and the content of the message transformed accordingly.
4. Interface determination
Based on the inbound interface configuration that is found for the message, the assigned inbound interface (at the receiver side) is evaluated.

Note
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. .

5. 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.
3. 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.

1.1.4.3.1 Messages

Use
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 the
business 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 may
be used, which attributes have these elements, and what structure they have. More than one instance (a document that matches an XML schema definition) can
exist 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>

Note
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 a
corresponding XML schema definition. The process whereby the system checks whether an XML document matches a schema definition is called
validation .

Note
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
a document 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
"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, see
www.w3.org/TR/SOAP-attachments . The runtime engine of SAP NetWeaver PI expects a message that has the following structure:

PUBLIC Page 11 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 Figure 1: 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 the
Payload contains the actual business data (such as <PurchaseOrder> in the example above). You can also append an unlimited number of attachments to
the 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 payload
is 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 made
communication 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 (eXtensible
Stylesheet Language for Transformations), for example, enables you to define mappings for messages with different structures. XPath expressions enable
conditions 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 an
adapter, 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 in
heterogeneous system landscapes and is not restricted to a single host system. Based on the given input parameters, output is determined by the system. This
is then passed back to the caller subsequently. SOAP, WSDL, UDDI, and WS-RM are the core standard for all Web service approaches.

1.1.5 Process Integration Landscapes

Use
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 the
system 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 of your business according to different needs.

Example
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 for
business-to-business processes that span several countries. In addition to this, local PI installations (for example, in that case, Advanced Adapter
Engine Extended 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.

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.

PUBLIC Page 12 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 Figure 1: 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 Advanced
Adapter 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, and
productive 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

1.1.5.1 Using Local and Central Enterprise Services Repositories

Use
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 runtime
engines (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 be
scheduled 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 for
transport 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 Page 13 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 Figure 1: 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) Integration
Directory. 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).

Note
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 are
tested.
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).

Caution
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 systems
sharing the same central ES Repository must be registered in the same (central) SLD.

Recommendation
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 ES
Repository once when the PI landscape is set up and not during productive usage. Note that switching to a central ES Repository can invalidate existing
configurations in the Integration Directory (because ESR objects might be missing in the central ES Repository).

1.1.5.2 Using Central and Non-Central Advanced Adapter

PUBLIC Page 14 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 1.1.5.2 Using Central and Non-Central Advanced Adapter
Engines

Use
You can set up the Advanced Adapter Engine in the following ways, depending on the chosen installation option.
More information: Installation Options
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 independent
integration 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:

Figure 1: Using a Non-Central AAE within a Dual-Stack PI Installation

Note
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 also
with 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 AAE
register 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):

PUBLIC Page 15 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 Figure 2: 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

1.1.5.3 Using Local and Central System Landscape Directories

Use
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 software
components. A software component is a shipment unit for design objects in the ES Repository, for example, integration scenarios or interface objects. When you
create 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. A
business system represents a logical system that is used as sender or receiver of messages in an integration scenario. A technical system represents the
physical system as identified by a server address and other attributes. When you configure an integration scenario for a specific system landscape using the
Integration Directory as configuration tool, you rely on the SLD data. At runtime, the correlation between business systems and assigned technical systems also
needs 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 to
allow 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, availability
of 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 like
development 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 low
operation 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 SLD System
Landscape )

1.2 Advanced Concepts

PUBLIC Page 16 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 1.2 Advanced Concepts

Use
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 Configuring
Integration Scenarios (Dual-Stack) and Developing and Configuring Integration Scenarios (AEX) ).

Note
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

1.2.1 Using Predefined Integration Content

Use
You have the option to start an integration development project using integration content predefined by SAP. There is a lot of predefined content already available
that can be reused and which helps customers to save time and effort in their integration development projects. Typically, customers do not use predefined
content 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 build
their own process model based on these entities, enriched by interfaces and mappings developed on their own. Another option is to use a predefined process
model (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 SAP
Community Network at https://www.sdn.sap.com/irj/sdn/explore-es .

Note
The term enterprise service is used to emphasize the fact that the ES Repository contains services that were designed according to SAP's SOA design
principles. 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 components
interaction 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 installed
in 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 separate
software component instead.

Note
This avoids conflicts with subsequent SAP software updates since changes to an SAP software component will be immediately overwritten when SAP
software 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 component
version. To do this, define a "based-on" relationship between the new software component and the SAP software component.
More information: Underlying Software Component Version

Note
When you use process integration content for SAP applications, make sure that there is an unambiguous (1:1) relationship between the corresponding
software component version in the ES Repository and the corresponding software component version in the SAP system. This is the same for the support
package. This means, the versions of both, software component version and support package number, need to be kept in sync in ES Repository and the
SAP system. They have to be installed and maintained synchronously.

More information: Managing Enterprise Services Delivered by SAP

1.2.2 Interface Objects

PUBLIC Page 17 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 Use
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:

Object Type Description

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

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

Data type Defines a data structure.

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

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

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

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

Figure 1: 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 a
service 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 service
interface). You can consider the set of functions a service interface represents as a subset of the functions implemented by a process component. However, a
service 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 editor
to specify the interface attributes.
The Category service interface attribute determines whether the service interface is an outbound or an inbound service interface.

Note
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 used
as input or output. You can specify the Communication Mode for each operation. This attribute determines if the communication defined by the operation is
synchronous or asynchronous. In a synchronous communication step, a response is expected for each call or request message that is sent out. In an
asynchronous 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 type
that 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
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 the
different interface objects play for the message exchange. The example shows an asynchronous message exchange where a request message is sent from the
service consumer to the service provider.

PUBLIC Page 18 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 Figure 2: 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:

Figure 3: 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 the
attribute Interface Pattern you can design this behavior in the ES Repository. An interface pattern describes the type of communication that is to be executed on
the 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 an
impact on the activities related to the programming of the business logic in the related back-end system (task of application developer).

Note
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, this
interface pattern is recommended for scenarios that use the common "technical adapters" such as the File/FTP, JDBC, JMS adapter. However, using this
pattern 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 when using
synchronous messages. The TU &C/C pattern ensures that - in cases of system or communication failure - one of more synchronous update calls in one
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 therefore
define 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
you to 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.

PUBLIC Page 19 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 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 ES
Repository, 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.
These expressions can then be used at configuration time to configure content-based routing and in integration processes (ccBPM)
More information: Context Objects
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 import
IDocs and RFCs into the ES Repository and make the interface signature known there.

1.2.3 Mapping Objects

Use
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 the
one 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 receiver
can handle. This type of transformation is called mapping . You specify the corresponding transformation rules in the ES Repository - in the form of mapping
objects.
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 specific
receiver.

Note
The term mapping describes transformations on the level of the business data that is exchanged between process components. This can include special
formats for particular business entities, such as the format of a time field in a message. Transformations on the level of the technical transport protocol are
handled 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, most
tasks 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 a
specific 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:

Object Type Description

Operation mapping 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.

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

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

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

Value mapping group 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 the same object. Mapping
programs (developed at design time) can refer to a value mapping table; however, since
the actual values in many scenarios 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):

PUBLIC Page 20 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 Figure 1: Object References Between Mapping Objects

1.2.3.1 Mapping Programs

Use
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
the graphical 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 ES
Repository as an archive.

Note
XSLT (eXtensible Stylesheet Language Transformations) is a language that enables you to convert an XML document to another document. You can
develop 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
Server on which the Integration Server is running.

Note
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 the
SAP system at the customer's site.

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

1.2.3.2 Operation Mapping

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

PUBLIC Page 21 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 Figure 1: 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 transformation
rules for the transformation of a source structure (representing the message sent by the outbound operation) into a target structure (representing the message
received 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 general
you have to define a mapping program for both request and response messages. If fault messages are used, you have to define an additional mapping
program 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).

1.2.3.3 Message Mappings (Overview)

Use
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 message
mapping is assigned to). Using a graphical editor, you can define the mapping between the source and target message type.

Note
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 the source
message assigned to the message mapping, the right area the structure of the target message. Below this is the data flow editor.

Note
If you have created the message mapping based on an operation mapping, the source and target structures are already loaded according to the operations
you 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.

Note
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, for example, 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
Target Field Mappings

1.2.3.4 User-Defined Functions and Function Libraries

PUBLIC Page 22 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 Use
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 a
local function library belonging to the corresponding mapping object. To use a user-defined function in more than one message mapping or mapping template, you
have 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.

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

More information:
User-Defined Functions
Function Libraries

1.2.4 Describing the System Landscape in the SLD

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

Note
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
the system 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
business systems.
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
business system 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 how to 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 senders
and receivers of messages in later configuration steps.

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

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 Integration
Server 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 can
you access up-to-date SLD content (for example, by using input help).
For more information, see: Delete SLD Data Cache

Change in the SLD Effect in Integration Directory

PUBLIC Page 23 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 Create/delete a business system The input help for business systems (for example, when you define a business system
component) is only updated once you clear 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.

Change in the SLD Effect in Integration Directory

Change a business system (registered as an SAP or non-SAP) system For this change to take effect in the relevant business system service, you must
For more information, see: Technical System Landscape compare the data with the SLD .
For more information, see: Business System (Communication Component)

Change a business system (adapter-specific identifiers, for example, the logical system) For this change to take effect in the relevant business system service, you must
compare the data with the SLD .
For more information, see: Communication component

1.2.5 Separation of Business Systems and Technical Systems

Use
Business systems represent "logical" systems, whereas technical system descriptions contain information about the technical details of a system. This is
information such as the server address. When the message flow - that is, the routing - in a system landscape is defined (in the receiver determination), this is
done 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 advantage
that 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 no
impact 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 at
runtime. Therefore, in addition to the "logical" receiver determination (as mentioned above), a "technical" receiver determination is performed at runtime. This
technical receiver determination is accomplished by a mapping of the business system to the underlying technical system. This dependency is already defined
in the SLD since you always have to assign a technical system when creating a business system.

Example
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 of
receiver communication channels that usually contain the server name of the receiving system. The server name is part of the technical system description
that is maintained in the SLD. On the other hand, the communication channel is assigned to a (receiver) communication component which is mapped directly
to a business system from the SLD.

1.2.6 Collaboration Profile

Use
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)
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 or
semantic unit within a company unit or company. You represent the first addressing level with the Communication Party object, and the second by the
Communication 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.

Addressing Typical Usages

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

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

Note
Note that it may sometimes be necessary to use communication parties when configuring internal company processes, for example in the case of IDoc

PUBLIC Page 24 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 communication. 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 on
business systems that are described in the System Landscape Directory.

Note
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 of
messages. 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 partners
and 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 runtime
engine.
A receiver communication channel contains the related information for the outbound processing of a message that is sent by the runtime engine to a receiver
component.
You can access the adapter configuration directly from the communication channel.

Note
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

1.2.7 Content-Based Routing

Use
In many business cases, it is necessary to define conditions with which the receivers of a message are determined during routing. For example, consider a
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 both the determination of receiver communication
components and inbound interfaces.
The following figure shows a simple example of content-based routing:

Figure 1: 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 flight
availability check is forwarded to the correct airline, the routing condition is formulated as airline-dependent. The airline ID (field AirlineID) is contained in the

PUBLIC Page 25 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 payload of the message. The routing condition is as follows: Send the message requesting the flight availability check to the airline Lufthansa if the field
AirlineID in the message payload has the value LH (Lufthansa). If this field has the value AA (American Airlines), then forward the message to the airline
American 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 XML
documents.
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 can
conveniently identify a message element by clicking through the message structure displayed in the editor. Additionally, you can combine multiple conditions with
logical AND and OR operators.

1.2.8 B2B Configuration

Use
Many integration scenarios are configured based on the assumption that the integration only involves business applications that span parts of one and the same
company. In such cases, the system landscape typically is described in one System Landscape Directory. Typically, in such a situation the complete system
landscape is known to the integration expert who performs the configuration tasks. The integration expert then typically puts a communication component on the
same 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 a
B2B scenario, the configuration of the integration is a task that is distributed among integration experts from the involved companies or organizations. Each
integration 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 integration
expert at business partner 1 does not know any details of the part of the system landscape hosted by business partner 2:

Figure 1: 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 the
system landscape hosted by business partner 2 is typically not known to him or her, since companies and organizations do not usually expose internal system
names 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 that
takes part in the business process. The communication party is an optional key field for receiver determinations, interface determinations, sender and receiver
agreements. 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 additional
concept 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 internal

PUBLIC Page 26 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 name 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 a
message 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 different
communication component type, called a business component. A business component merely represents an abstract entity for addressing the senders and
receivers 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 message
header. 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 at
the external business partner. To make sure that internal system names are masked in message headers, a header mapping can be applied. With a header
mapping, you define a transformation from the internal (sender) system name to an externally exposed business component name. You configure the header
mapping when you specify the outbound processing.
The following figure illustrates how header mapping works:

Figure 2: 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 the
internal landscape hosted by business partner 1. Instead, the external business partner addresses the message to a virtual receiver by using a business
component name to address the receiver of the message. This business component name is the name you (business partner 1) have communicated to the
external 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:

PUBLIC Page 27 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.
 Figure 3: 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 Advanced Adapter Engine Extended)

PUBLIC Page 28 of 28
© 2014 SAP SE or an SAP affiliate company. All rights reserved.