BASICS

PDF download from SAP Help Portal: http://help.sap.com/saphelp_nw74/helpdata/en/6a/d6aab71c5a441e89af1d8ebea87ecf/content.htm Created on February 07, 2014
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.

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

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

Page 1 of 18

TABLE OF CONTENT
1 Basics 1.1 Introduction 1.2 Key Capabilities 1.2.1 Connectivity 1.2.2 Mapping 1.2.3 Routing 1.3 Installation Options 1.4 Phases of an Integration Project 1.4.1 Design Time 1.4.1.1 Top-Down Design 1.4.2 Configuration Time 1.4.3 Runtime 1.4.3.1 Messages 1.5 Process Integration Landscapes 1.5.1 Using Local and Central Enterprise Services Repositories 1.5.2 Using Central and Non-Central Advanced Adapter Engines 1.5.3 Using Local and Central System Landscape Directories

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

Page 2 of 18

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 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 2013 SAP AG or an SAP affiliate company. All rights reserved.

Page 3 of 18

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 crosscomponent 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.2 Key Capabilities

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

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 2013 SAP AG or an SAP affiliate company. All rights reserved.

Page 4 of 18

Figure 1: Connectivity Capabilities of SAP NetWeaver PI

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 two Fields of a Source Structure into one Single Target Structure Field

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.

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

Page 5 of 18

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

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

Page 6 of 18

Installation Option Dual-stack installation

Description 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

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 Process Orchestration . SAP NetWeaver Library: Function-Oriented View

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

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

Page 7 of 18

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.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, 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 implementationrelevant 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:

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

Page 8 of 18

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

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

Page 9 of 18

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

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 Modeling the integration-relevant aspects of a cross-component process - or how process components interact with each other Design Objects Process models 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 with another Interface objects 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 Pre-configuring connectivity/adapters Mapping objects 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.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. 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

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

Page 10 of 18

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.

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

Page 11 of 18

More Information Installation Options Runtime

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

2.

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

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

Page 12 of 18

</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/xmlschema0/" , 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:

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

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

Page 13 of 18

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

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

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

Page 14 of 18

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.

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.

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

Page 15 of 18

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

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

Page 16 of 18

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):

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

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

Page 17 of 18

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 Your SLD System Landscape ) ( How to Plan

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

Page 18 of 18