PI Federation – An Overview

8/3/2019 PI Federation – An Overview

http://slidepdf.com/reader/full/pi-federation-an-overview 1/47

SAP NetWeaver

How-To Guide

PI Federation – An Overview

Applicable Releases:

SAP NetWeaver Process Integration 7.0

SAP NetWeaver Process Integration 7.1

(Including Enhancement Package 1)

Topic Area:

SOA Middleware

Capability:

Service Bus

Version 1.0

March 2010



© Copyright 2010 SAP AG. All rights reserved.

No part of this publication may be reproduced or

transmitted in any form or for any purpose without the

express permission of SAP AG. The information contained

herein may be changed without prior notice.Some software products marketed by SAP AG and its

distributors contain proprietary software components of

other software vendors.

Microsoft, Windows, Outlook, and PowerPoint are

registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, OS/2, Parallel

Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390,

OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP,

Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix,

i5/OS, POWER, POWER5, OpenPower and PowerPC are

trademarks or registered trademarks of IBM Corporation. Adobe, the Adobe logo, Acrobat, PostScript, and Reader

are either trademarks or registered trademarks of Adobe

Systems Incorporated in the United States and/or other

countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered

trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame,

WinFrame, VideoFrame, and MultiWin are trademarks or

registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks orregistered trademarks of W3C®, World Wide Web

Consortium, Massachusetts Institute of Technology.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems,

Inc., used under license for technology invented and

implemented by Netscape.

MaxDB is a trademark of MySQL AB, Sweden.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP

NetWeaver, 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 in several other countries all over the world.

All other product and service names mentioned are the

trademarks of their respective companies. Data contained

in this document serves informational purposes only.

National product specifications may vary.

These materials are subject to change without notice.

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 withrespect to the materials. The only warranties for SAP

Group products and services are those that are set forth in

the express warranty statements accompanying such

products and services, if any. Nothing herein should be

construed as constituting an additional warranty.

These materials are provided “as is” without a warranty of

any kind, either express or implied, including but not

limited to, the implied warranties of merchantability,

fitness for a particular purpose, or non-infringement.

SAP shall not be liable for damages of any kind including

without limitation direct, special, indirect, or consequential

damages that may result from the use of these materials.

SAP does not warrant the accuracy or completeness of the

information, text, graphics, links or other items contained

within these materials. SAP has no control over the

information that you may access through the use of hot

links contained in these materials and does not endorse

your use of third party web pages nor provide any warranty

whatsoever relating to third party web pages.

SAP NetWeaver “How -to” Guides are intended to simplify

the product implementation. While specific product

features and procedures typically are explained in a

practical business context, it is not implied that those

features and procedures are the only approach in solving a

specific business problem using SAP NetWeaver. Should

you wish to receive additional information, clarification or

support, please refer to SAP Consulting.

Any software coding and/or code lines / strings (“Code”)

included in this documentation are only examples and are

not intended to be used in a productive system

environment. The Code is only intended better explain and

visualize the syntax and phrasing rules of certain coding.

SAP does not warrant the correctness and completeness of

the Code given herein, and SAP shall not be liable forerrors or damages caused by the usage of the Code, except

if such damages were caused by SAP intentionally or

grossly negligent.

Disclaimer

Some components of this product are based on Java™. Any

code change in these components may cause unpredictable

and severe malfunctions and is therefore expressively

prohibited, as is any decompilation of these components.

Any Java™ Source Code delivered with this product is only

to be used by SAP’s Support Services and may not be

modified or altered in any way.



Document History

Document Version Description

1.00 First official release of this guide



Typographic Conventions

Type Style Description

Example Text Words or characters quoted

from the screen. These

include field names, screen

titles, pushbuttons labels,

menu names, menu paths,

and menu options.

Cross-references to other

documentation

Example text Emphasized words or

phrases in body text, graphic

titles, and table titles

Example text File and directory names and

their paths, messages,

names of variables and

parameters, source text, and

names of installation,

upgrade and database tools.

Example text User entry texts. These are

words or characters that you

enter in the system exactly as

they appear in the

documentation.

<Example

text>

Variable user entry. Angle

brackets indicate that you

replace these words and

characters with appropriate

entries to make entries in the

system.

EXAMPLE TEXT Keys on the keyboard, for

example, F2 or ENTER.

Icons

Icon Description

CautionNote or Important

Example

Recommendation or Tip



Table of Contents

1. Introduction ..................................................................................................................... 1 2.

Reference Material ........................................................................................................... 2

3. Background Information ................................................................................................. 3

3.1 PI Domain................................................................................................................. 3 3.2 Adapter Engine ......................................................................................................... 4

3.2.1 Central v De-Central ..................................................................................... 4 3.2.2 Local Processing .......................................................................................... 4

4. What is PI Federation? .................................................................................................... 5 4.1 Architectural Models ................................................................................................. 6 4.2 Architectural Progression .......................................................................................... 7

5. Central.............................................................................................................................. 8 5.1 Reasons ................................................................................................................... 9 5.2 Examples.................................................................................................................. 9 5.3 Assessment Summary ............................................................................................ 10 5.4 Recommendations .................................................................................................. 11

5.4.1 Governance ................................................................................................ 11 5.4.2 Software Logistics & Synchronization.......................................................... 12 5.4.3 Tools .......................................................................................................... 13

6. Distributed ..................................................................................................................... 14 6.1

Reasons ................................................................................................................. 15

6.2 Examples................................................................................................................ 15 6.3 Assessment Summary ............................................................................................ 16 6.4 Recommendations .................................................................................................. 17

6.4.1 Governance ................................................................................................ 17 6.4.2 Software Logistics & Synchronization.......................................................... 18 6.4.3 Tools .......................................................................................................... 19

7. Federated ....................................................................................................................... 20 7.1 Reasons ................................................................................................................. 21 7.2 Examples................................................................................................................ 21 7.3 Assessment Details ................................................................................................ 22 7.4 Recommendations .................................................................................................. 23

7.4.1 Governance ................................................................................................ 23 7.4.2 Software Logistics & Synchronization.......................................................... 24 7.4.3 Tools .......................................................................................................... 27 7.4.4 Business System Communication Strategy ................................................. 27

8. Recommendations......................................................................................................... 28 8.1 Architectural Model Selection .................................................................................. 28 8.2 Governance Model Selection .................................................................................. 29 8.3 Tools ...................................................................................................................... 30

8.3.1 CTS+ .......................................................................................................... 30



8.3.2 Directory API .............................................................................................. 30 8.3.3 Web Dispatcher .......................................................................................... 31

8.4 SLD Strategy .......................................................................................................... 31 8.5 Service Registry Strategy ........................................................................................ 32 8.6 Security Utilization .................................................................................................. 32 8.7 Justify any architectural variation ............................................................................ 32

9. SAP NetWeaver Composition Environment Considerations ....................................... 33 10. Summary ........................................................................................................................ 35 11. Appendix - Examples in Detail ...................................................................................... 36

11.1 Central.................................................................................................................... 36 11.2 Distributed .............................................................................................................. 36

11.2.1 Central PI Integration Server with De-Central adapter engines located

regionally .................................................................................................... 36 11.2.2 Central PI Integration Server with de-central adapter engines located near

business systems ....................................................................................... 36 11.2.3 Central PI Integration Server with Adapter Engines deployed with web

dispatching for upgrade purposes. .............................................................. 36 11.3 Federated ............................................................................................................... 37

11.3.1 Regional PI Integration Servers .................................................................. 37 11.3.2 Regional PI Integration Servers with De-Central Adapter Engines ............... 37 11.3.3 Central PI Integration Server with regional PI Integration Servers ................ 37 11.3.4 Central PI Integration Server with regional PI Integration Servers and De-

Central Adapter Engines ............................................................................. 37 11.3.5 Localized PI Integration Servers ................................................................. 38 11.3.6 Localized PI Integration Servers with De-Central Adapter Engines .............. 38 11.3.7 Central PI integration Server with redundant Integration Server to be used

in Switch Over scenarios ............................................................................ 38 12. Appendix - Assessment Criteria ................................................................................... 39

12.1 Administration ......................................................................................................... 39 12.2 Availability .............................................................................................................. 39 12.3 Monitoring............................................................................................................... 39 12.4 TCO ....................................................................................................................... 39 12.5 Internal Performance .............................................................................................. 39 12.6 Network Utilization .................................................................................................. 39 12.7 Common Business Process Delivery ....................................................................... 39 12.8 Globalization & Localization .................................................................................... 40



1. Introduction

SAP Process Integration is used in over three thousand organizations offering an enterprise-class,

service-oriented architecture middleware to perform application to application (A2A) and business to

business (B2B) integration whilst accelerating composite application development.

With so many organizations, variances in landscape architecture are evident and solutions must adapt

providing flexibility in such situations. SAP Process Integration offers a number of landscape

deployment solutions which can be categorized as central, distributed or federated. This document

introduces each architectural model and highlights the associated planning and implementation

considerations. The following sections are used to provide a structured approach to the topic:

Background Information

What is PI Federation?

Central Architectural Model

Distributed Architectural Model

Federated Architectural Model

Recommendations

This document has a clear scope of SAP PI architecture topology with specific reference to federation.

It does not aim to discuss scaling SAP PI with respect to performance or high availability and is not

intended to be a implementation guide rather a discussion on federation. These topics are covered in

other documents and should be referenced appropriately. The following table highlights the scope of

this docuement with reference to the general scaling concepts of SAP solutions.

Scaling Description Discussed?

Vertical Increasing hardware specification of servers. Memory etc

Additional Java server nodes

Additional ABAP dialogue instances

Horizontal Additional PI De-central Adapter Engines (Distribution)

Additional PI Instances (Federation)



2. Reference Material

The following links provide supplementary information which support the topics discussed in this

document. The NetWeaver Technology RIG has a number of how-to guides which provide step by

step guidance on popular topics. In addition we have also created a number of recorded sessionsknown as the “Know How” series which can be played at your convenience.

Reference Material

Type Topic Link

RIG

Know How

Series

All Sessions http://www.sdn.sap.com/irj/scn/ipnw-khnc

RIG

How To

Guides

All http://www.sdn.sap.com/irj/scn/howtoguides

PI 7.1 and

above

http://www.sdn.sap.com/irj/sdn/index?rid=/webcontent/uuid/b021f97d

-b09e-2b10-c296-f7fb1fb345c4

PI 7.0 http://www.sdn.sap.com/irj/sdn/index?rid=/webcontent/uuid/608725f0

-2a77-2910-c2b6-8ddddecc4b5e

XI 3.0 http://www.sdn.sap.com/irj/sdn/index?rid=/webcontent/uuid/dd0326a7

-0d01-0010-f690-b94802b06c8a

SAP

Online

Help

Advanced

Adapter

Engine

http://help.sap.com/saphelp_nwpi711/helpdata/en/ca/b977f1c781420

1954f20bb87ad7aab/frameset.htm

CTS+ http://help.sap.com/saphelp_nwpi711/helpdata/en/c0/18907d03b7c04ca9d07c7efeb5e1a9/frameset.htm

Central

Monitoring

http://help.sap.com/saphelp_nwpi711/helpdata/en/44/bc872fc60b700

6e10000000a155369/frameset.htm

Directory API http://help.sap.com/saphelp_nwpi711/helpdata/en/48/d127e1e1c607

83e10000000a42189d/frameset.htm

ESR http://help.sap.com/saphelp_nwpi711/helpdata/en/61/fec608bc27654

daadb20c1e6da7dd1/frameset.htm

Process

Integration

http://help.sap.com/saphelp_nwpi711/helpdata/en/e1/8e51341a0608

4de10000009b38f83b/frameset.htm PI Integration

Security

http://help.sap.com/saphelp_nwpi711/helpdata/en/fb/c2953fc405330e

e10000000a114084/frameset.htm

Service

Registry

http://help.sap.com/saphelp_nwpi711/helpdata/en/2e/8526937af346a

0bc446905ea964ceb/frameset.htm

SLD http://help.sap.com/saphelp_nwpi711/helpdata/en/48/b68474966552

95e10000000a42189b/frameset.htm

Web

Dispatcher

http://help.sap.com/saphelp_nwpi711/helpdata/en/48/8fe37933114e6

fe10000000a421937/frameset.htm

http://www.sdn.sap.com/irj/scn/ipnw-khnc


http://www.sdn.sap.com/irj/scn/howtoguides


http://www.sdn.sap.com/irj/sdn/index?rid=/webcontent/uuid/b021f97d-b09e-2b10-c296-f7fb1fb345c4



http://www.sdn.sap.com/irj/sdn/index?rid=/webcontent/uuid/608725f0-2a77-2910-c2b6-8ddddecc4b5e



http://www.sdn.sap.com/irj/sdn/index?rid=/webcontent/uuid/dd0326a7-0d01-0010-f690-b94802b06c8a



http://help.sap.com/saphelp_nwpi711/helpdata/en/ca/b977f1c7814201954f20bb87ad7aab/frameset.htm



http://help.sap.com/saphelp_nwpi711/helpdata/en/c0/18907d03b7c04ca9d07c7efeb5e1a9/frameset.htm



http://help.sap.com/saphelp_nwpi711/helpdata/en/44/bc872fc60b7006e10000000a155369/frameset.htm



http://help.sap.com/saphelp_nwpi711/helpdata/en/48/d127e1e1c60783e10000000a42189d/frameset.htm



http://help.sap.com/saphelp_nwpi711/helpdata/en/61/fec608bc27654daadb20c1e6da7dd1/frameset.htm



http://help.sap.com/saphelp_nwpi711/helpdata/en/e1/8e51341a06084de10000009b38f83b/frameset.htm



http://help.sap.com/saphelp_nwpi711/helpdata/en/fb/c2953fc405330ee10000000a114084/frameset.htm



http://help.sap.com/saphelp_nwpi711/helpdata/en/2e/8526937af346a0bc446905ea964ceb/frameset.htm



http://help.sap.com/saphelp_nwpi711/helpdata/en/48/b6847496655295e10000000a42189b/frameset.htm



http://help.sap.com/saphelp_nwpi711/helpdata/en/48/8fe37933114e6fe10000000a421937/frameset.htm

































3. Background Information

3.1 PI Domain

Before discussing PI federation and associated deployment architectures it is important to highlight thecomponents which form the building blocks of a PI installation. This is known as a PI domain and the

following diagram illustrates each component independent of distribution. A brief description is given

for each component describing relative function.

Type Description

Integration Server A collection of BPE, Integration Engine and Central Adapter Engine.

See below.

Business Process Engine Runtime execution for ccBPM processes.

Integration Engine Runtime execution of pipeline steps such as receiver determination

interface determination, etc.

Central Adapter Engine Mandatory installation of an adapter engine holding java specific

adapters relevant for connectivity. Remote installations of this are

known as De-Central Adapter Engines and are discussed in detail

along with the Advanced Adapter Engine capabilities.

Enterprise Service

Repository

Design time for SOA artifacts such as service interfaces, message

types, data types and operation mappings.

Integration Directory Configuration of integration scenarios defining collaboration profiles,

agreements and objects such as receiver determination, etc

Central Monitoring Monitors PI domain at runtime via Solution Manager.

System Landscape

Directory

Defines metadata information defining Landscape, Software Catalog

and Development objects.

Advanced Adapter Engine

Extended

New java only deployment options providing ESB capabilities as per

AAE without ccBPM and other ABAP capabilities.

Partner Connectivity Kit The PCK is an AS Java-based application that uses the Adapter

Framework enable PI messages to be sent to an Integration Server

Note - The Adapter Engine (Java SE) is supported for compatibility reasons only. It hosts only asubset of the adapter functionality and you should only use it if it is a precondition in your environment.



3.2 Adapter Engine

Although SAP PI architecture involves many components, key considerations involve the use of either

one or more Integration Servers and associated adapter engines. This section describes the

deployment modes of an adapter engine which is important when discussing central, de-central or

federated PI architectures. For more information please hyperlinks located in the section “Reference

Material”.

3.2.1 Central v De-Central

A central adapter engine is mandatory and is located within the integration server for SAP PI

versions 3.0 through to 7.11. The adapter engine resides on the java application server found in the

dual stack installation of SAP PI. Available in all releases.

A de-central adapter engine refers to the deployment of the adapter engine remotely relative to the

integration server and does not represents an increase in functionality. It is important to emphasize

when installing any central adapter engine and de-central adapter engine of the same release they will

both support the same features and capabilities. A typical use of a de-central adapter engine is to

within a demilitarized zone allowing tight protocol controls with messages flowing to and from theintegration server. Other use cases for a de-central adapter engine are geographical distance and

resulting network latency issues. Available from XI 3.0.

3.2.2 Local Processing

The term Advanced Adapter Engine is the PI 7.1 release name of the adapter engine and supports a

new capability allowing local processing of messages within the advanced adapter engine only.

Known as an “Integrated

Configuration”, messages configured

with this object no longer travel to the

Integration Server resulting in

significant performance gains. Use ofthe Integrated Scenario object is

restricted to adapters found on the

adapter engine only. The diagram

illustrates message flow in such a

scenario.



4. What is PI Federation?

SAP PI has a number of architectural deployment options which cater for various requirements of an

organization. We can classify these deployment options as central, distributed or federated. In a

standard installation a single SAP PI instance is deployed per landscape tier. This is known as acentral architectural model and is typical in most organizations.

Larger organizations may require a more distributed solution and this is where the concept of PI

federation is introduced. PI Federation describes the deployment of multiple SAP PI instances within

a single landscape tier such as production. The diagram below illustrates a federated architecture and

represents an organization with a global PI instance meeting high level requirements but also

additional regional PI hubs which provide local flexibility and autonomy.

Such architecture is highly complex, has significant total cost of ownership overheads and as a result

is not suitable for most organizations. We shall discuss this example and many others in subsequent

sections along with recommendations regarding how to identify a suitable architecture for your

organization. At this point it is important to understand the definition of PI Federation, multiple PI

instances in the same landscape tier. The illustration below depicts an organization with multiple PI

instances geographically dispersed per region and is an example of PI federation.

Global

ProductionQuality AssuranceDevelopment

Federation

APJ

Americas

Development Quality Assurance Production

EMEA

Global



4.1 Architectural Models

Both central and federated architectural models have already been introduced, however an

intermediate model known as “distributed” provides a compromise in complexity. The following table

defines the three high level architectural models in SAP PI deployment, followed by a real world

sample architectural progression. Advantages and disadvantages for each model will be discussed in

subsequent sections.

Central

A single integration server communicating with all business systems. Central

deployment of SAP PI is a favorable starting point for most organizations as it is

represents the smallest possible installation footprint and holds associated TCO

benefits. Deviation from this initial architecture requires careful justification due

to the increased complexity and associated impacts on business metrics such

as total cost of ownership.

Distributed

A single integration server with one or more de-central adapter engines

communicating with relevant business systems. It is often found in organizations

where performance or security reasons dictate a more complex solution

compared to centralization. This is a hybrid approach between central and

federated models giving the benefits around performance and security with the

benefits from centralized governance, maintenance and monitoring.

Federated

Two or more integration servers within a single landscape tier communicating

with relevant business systems. Use of additional de-central adapter engines

per integration server is also possible and adds a further level of complexity.

Due to the more complex architecture the federated model allows greater

flexibility however at the expense of a higher TCO. Such organizations are

usually larger in size and require a high degree of abstraction in their landscape.

Below are some customer driven reasons for federation:

Organization and divisional autonomy due to legal or operational

reasons.

Separation of A2A and B2B integration scenarios for security reasons.

Separation by process types such as transactional versus master data.

Business continuity such as downtime minimization

Quality of Service obligations

Billing requirements based on volume

Security issues around personal data

Prioritization of messages

Geography

Technical Abstraction from upgrades & downtime

In contrast to customer driven reasons for federation there are also some SAP

driven reasons such as isolation for upgrade path independency or decoupling

of business systems and portal UI bindings.



4.1.1 Architectural Progression

With the central, distributed and federated models introduced it is relevant to mention how

organizations decide on a possible deployment solution. Organizations may be installing PI for the

first time or have and existing landscape requiring possible consolidation. In either case an

organization will follow a similar architectural progression, the difference will be where they a starting

from and whether they are looking to consolidate or expand.

The following table highlights a typical progression where geographical or political reasons dictate an

architectural deviation away from central towards a more distributed and federated solution. Each

model type and subsequent examples will be discussed at length throughout this document followed

by a summary highlighting a general approach when considering PI federation. Not all variations are

listed in the table.

Political, geographical or performance influenced progression

Type Description

Central Central PI Integration Server supporting global requirements

Distributed Central PI Integration Server with de-central adaptor engines located regionally

Central PI Integration Server with de-central adaptor engines close to business

systems

Federated Shadow PI Integration Servers in production for business continuity in patching or

upgrade scenarios. (Not specifically in this progression)

Region PI Integration Servers

Regional PI Integration Servers with de-central adaptor engines close to business

systems

Global PI Integration Server with regional PI integration servers

Localized PI Integration Servers

Note Clustering is another possible addition to the above architectural models and

provides improved redundancy, load balancing, performance and availability. This will

not be discussed in this document due to the size of the topic and is best suited for other

supporting documents more readily available. Please see „Reference Material“ section

for hyperlinks to relevant documents.

Consolidation

Expansion



5. Central

Central deployment of SAP PI is a favorable starting point for most organizations as

it is represents the smallest possible installation footprint and holds associated TCO

benefits. This involves a central integration server and central adapter engine. Weshall use a global company as a reference to provide consistency across

architectural models and subsequent easy comparison.

The illustration above depicts the single variation of a central architectural model with every

business system communicating with a single integration server. Whilst organizations are not

all global in nature we shall reference this for consistency when analyzing other architectural

models. If your organization is smaller in scope and specific to a single country or location the

following advantages and disadvantages may not be as pronounced.

Assessment Summary

Advantages Disadvantages

TCO Network Load

Central Governance Local Autonomy Reduced

Reduced Monitoring Complexity Message travels to integration server every time

Common Business Process Delivery Downtime Dependency

Development Object Re-use Local processing not possible

Releases Supported: All



5.1 Reasons

The main reason for organizations deploying a central architectural model is simplicity and a high TCO

benefit. For most organizations this model is ideal and caters for central governance and a high re-

use of development objects. It should be considered a starting point for all organizations before

further distribution or federation is implemented. Global requirements can be met in this architectural

model by implementing appropriate security and role based policies for design-time objects. Further

information by component is given in the following sections.

5.2 ExamplesThe following example demonstrates a centralized deployment of PI.

Type Description

Central Central PI Integration Server supporting global requirements.

5.2.1 Central PI Integration Server supporting global

requirements

There is only one variation of the central architectural modeland offers the smallest installation footprint. In the diagramto the right we can see many business systems bound to asingle integration server. One integration server is foundper tier with messages forced to travel from each businesssystem. This deployment example is highly recommendedwhere feasable due to a low TCO impact. Please see theassessment summary information for more detail.



5.3 Assessment Summary

The following table gives explanations against specific criteria and aims to give a quick reference for

comparison. Criteria definitions can be found in the appendix.

Criteria Rating Description

Administration Effort Low The administrative overhead for a central deployment model is very

low due to the single instance all in one solution. Upgrades, patches

and software logistics are at their simplest and consistent with other

SAP solutions.

Availability Medium The availabili ty in a central deployment model although adequate

for smaller installations it may be restrictive for larger organizations.

Consider a global company with business systems geographically

dispersed in each country. As a result if the central integration

server is down for periodic maintenance then message processing

for each dependent country is suspended and hence availability isaffected.

Monitoring Complexity Low Monitoring is optimized in a central deployment model due to the

single instance. Adapters and associated component all belong to

the same PI domain and integration with SAP Solution Manager is

standard.

TCO Low TCO is minimized due to a single instance located centrally.

Development is efficient as all users are working off the same

design time environment and the cost of operations is relatively low.

Performance Internal Low Internal performance can be seen to be inefficient as every

message is being processed by the single instance. This maycreate a bottle neck for performance and a subsequent degradation

in processing time. Sizing a central deployment model is important

and may alleviate bottlenecks with additional dialogue processes

and java server nodes on the same Instance.

Network Efficiency Low Sending messages to the central integration server may be subject

to issues associated to network latency which is mentioned below.

Common Business Process

Delivery

High Due to a single instance deployment organizations can ensure

business processes or integration scenarios are deployed in

consistent manner. Object re-use is maximized and redundancies

are avoided.

Globalization & Localization Low Whilst global requirements are guaranteed, local integration

requirements may not be met. Local requirements may be deemed

more important than implementing a global solution however

thorough justification should be encouraged as the use of naming

conventions and authorizations may alleviate separation.



5.4 Recommendations

The following recommendations highlight the decision points or considerations from choosing a central

deployment model.

5.4.1 GovernanceGovernance can be defined by the policies, processes and procedures that support any IT landscape.

In the context of a PI solution and this document we shall define governance relative to change

management of design time objects in the Enterprise Service Repository and Integration Directory.

Who can change what and where it can be changed are of relevance in this criterion. In a federated

scenario with multiple ESR’s, a decision needs to be made where changes are allowed. Should they

be done in one central ESR only or should changes be permitted locally and then somehow replicated

with appropriate controls. A central governance model is highly recommended as a starting point in

federated scenarios. When this cannot be achieved a mixed mode should be adhered to. See below.

Central

Design time objects are created and changed in only one development system only and then

replicated consistently throughout the landscape as required. No changes are to be made or new

objects created in local PI instances.

This is the recommended approach in federated

scenarios when it can be applied practically. It may

require strict policy enforcement and a higher level

of collaboration but the benefits of object re-use and

one model for everyone is significant.

The implementation of ACL’s and user roles for design times objects creation and authoring is

recommended. Please see recommendations per

component in subsequent sections for more

information.

Governance in a central deployment model is simplified as there is only one development environment

for objects to be created or changed and hence central governance strategy is enforced.

Whilst a federated scenario may give you greater flexibility the central model is recommended

to guarantee high object re-use and consistency.

The use of roles, authorizations and appropriate naming conventions when creating,

changing, deleting and displaying design time objects can support global requirements and

cater to the needs of local divisions or businesses. Defining these constraints prior to an

implementation is imperative for success and possible future growth.



5.4.2 Software Logistics & Synchronization

In a central deployment model the transport and synchronization of objects is optimized due to a

single productive instance. As a result no synchronization is required with either the Enterprise

Service Repository or Integration Directory. The following table highlights the associated consideration

per component when dealing with software logistics and synchronization.

Component Considerations

ESR With one PI instance per tier, standard transport rules apply for moving development

objects inside the ESR. Please see the next section for sample configuration using

CTS+.

Integration Directory As per the ESR the single instance in each tier makes transporting of development

objects straight forward. The integration directory requires more consideration due to the

selective transport of objects and dependent configuration. An example of this is the

communication channel configuration which is tier specific. You do not transport a

communication channel of type file pointing to a development location into qualityassurance. These restrictions are standard PI transport considerations which are

dependent on your landscape and client topology. Specifically around the use of

business systems when leveraging older concepts such as transport groups which

transpose the name of a given system in a tier to another in the next tier.

Service Registry Service Registries are tier specific and the transporting of object from development,

quality assurance and production is not required. Publication is recommended per tier

post transport of the associated object in either the ESR or ID as end point configuration

and policy information is generated at this time.

SLD The system landscape directory content can be transported using CTS+ or historical

manual file export and import. As the SLD topology is independent of the PI landscape

you may have either one central SLD or a SLD per tier. The SLD is used in other

scenarios other than Integration or PI and hence the selected architectural SLD topology

will dictate the required synchronization or transport strategy.

Proxy Development Proxy development in the corresponding business systems should be transported in a

synchronized fashion along with ESR and Integration Directory content. This is a project

specific decision and is dependent on how an integration scenario needs to be promoted

throughout the landscape. Depending on how coupled your scenarios are with proxy

code this may not be required and could be done independently. Specific consideration

should be given to changes in Service Operation signatures to ensure each integrated

system proxy definition equals what has been defined in your ESR and resulting

Integration Scenario.



5.4.2.1 Sample ESR Transport Flow

The following diagram shows a sample transport flow of ESR design time objects in a three tiered

landscape of a central architectural model using a central governance model. This is standard across

SAP PI installations and is used to demonstrate variations evident in the federated architectural

model. The people located in the development layer indicate object authoring and modificaitons.

5.4.3 ToolsIn a federated scenario the following tools can be utilized to implement such an architectural model.

For more information please see the general “Recommendations” section in the next chapter for more

information on each of these tools. An associated “How-to” guide will be released demonstrating how

to utilize each toolset and can also be located in section “Reference Material”.

CTS+

Web Dispatcher

Directory API



6. Distributed

Distributed models are often found in organizations where performance or security

reasons dictate a more complex solution compared to centralization. This is a hybrid

approach between central and federated models giving the benefits aroundperformance and security whilst benefiting from centralized governance, maintenance

and monitoring. A distributed architectural model is defined by one PI integrations

server integrating with one or more de-centrally deployed adapter engines.

The illustration above depicts one example of distribution. Assessment information is relative

to distributed architectures in general and more variation specific details are described in

subsequent sections. The adapter engine icon represents either a full J2EE adapter engine

installation or the light weight alternative of a J2SE adapter engine.

Assessment Summary


Central Governance Increased TCO from central model

Common Business Process Delivery Design Time Autonomy Reduced

Development Object Re-use Additional Hardware Requirements

Performance Improvements due to local processing

Reliability due to local queuing capabilities




6.1 Reasons

Distributed models are often found in organizations where performance or security reasons dictate a

more complex solution compared to centralization. This is a hybrid approach between central and

federated models giving the benefits around performance, reliability and security whilst benefiting from

centralized governance, maintenance and monitoring. Local processing allows messages to stay

closer to the business systems of a given region or location and reduced network loads whilst

improving reliability to queue capabilities.

Organizations are able to deploy adapter engines closer to their business systems and improve the

performance of the integration scenarios relative to the central architectural model. This model is

highly recommended when the central model is not able to meet all requirements of a global

organization and offers a reasonable alternative to federation and associated complexities. Of these

reasons the technical implementation supports localization, business continuity and security

capabilities.

Localization

Local processing of messages reducing network load, improving

performance and reliability.

Business Continuity



Security

Placement within a De-Militarized Zone for external andinternal zone abstraction

6.2 ExamplesThe following examples demonstrate a distributed deployment of PI. Each has its own associated

advantages and disadvantages and more information can be found in the appendix.

Type Description

Localization

Central PI Integration Server with de-central adaptor engines located regionally.

Central PI Integration Server with de-central adaptor engines located near business systems.

Business

Continuity

Central PI integration Server with redundant Adapter Engines to be used in controlled switch

over scenarios when upgrading or patching.

Security Central PI Integration Server with an additional Adapter Engine in a De-Militarized Zone

(DMZ).




The following table gives explanations against specific criteria and aims to give a quick reference for

comparison. Definitions can be found in the appendix at the end of this document.


Administration Effort Medium The overhead in administration for a distributed deployment model

is still low however due to one or more de-central adapter/advanced

adapter engines co-ordination and release level synchronization is

required.

Availability Medium Availability in a distributed model has improvement when compared

to a central deployment due to the ability for de-central or advanced

adapter engines to process or queue messages whilst the

integration server may not be operational. Local processing in the

advanced adapter engine is enabled via the new configuration

object called and integrated scenario. Asynchronous messagequeues enable temporary storage until the integrations server is

operational.

Monitoring Complexity Medium Monitoring in a distributed deployment model is still efficient due to

the central configuration using either local PI toolsets such as the

runtime workbench or solution manager.

TCO Medium TCO is higher than a central deployment model due to the

installation of additional de-central / advanced adapter engines. As

per the additional administrative overheads this correlates to a

higher TCO.

Performance Internal Medium Internal performance is improved due to the distribution ofcomponents and possible de-central message processing within an

advanced adapter engine. Even de-central adapter engines remove

overhead of protocol transformation being submitted in to the

integration server ABAP stack using the XI message format.

Network Efficiency Medium For advanced adapter engine scenario using the integrated

configuration objects network load is minimized due to local

processing. The protocol translation from legacy to SAP XI is done

locally and has a higher tolerance to errors given proximity to the

source of information.

Common Business Process

Delivery

High Even though de-central or advanced adapter engines may be

deployed there is still a high level of re-use due to the central design

time utilization of the ESR and Integration Directory.

Globalization & Localization Medium Whilst global requirements are guaranteed, local integration

business requirements may not be met. Local requirements may be

deemed more important than implementing a global solution

however thorough justification should be encouraged as the use of

naming conventions and authorizations may alleviate separation.

The benefit of local processing has an advantage to local

geographical requirements however the utilization of a central

design enforces governance.



6.4 Recommendations

The following recommendations highlight the decision points or considerations from choosing a central

deployment model.

6.4.1 GovernanceGovernance can be defined by the policies, processes and procedures that support any IT landscape.

In the context of a PI solution and this document we shall define governance relative to change

management of design time objects in the Enterprise Service Repository and Integration Directory.






Central

Design time objects are created and changed in only one development system only and thenreplicated consistently throughout the landscape as required. No changes are to be made or new







The implementation of ACL’s and user roles for

design times objects creation and authoring is


component in subsequent sections for more

information.

Governance in a central deployment model is simplified as there is only one development environment

for objects to be created or changed and hence central governance is enforced.

Whilst a federated scenario may give you greater flexibility the central model is

recommended where possible to guarantee high object re-use and object consistency.

The use of roles, authorizations and appropriate naming conventions when creating,

changing, deleting and displaying design time objects can allow a global solution which also

meets the needs of local divisions or businesses. Defining these constraints prior to an

implementation is imperative for success and possible future growth.




In a distributed deployment model the transport and synchronization of objects is optimized due to a

single productive instance. As a result no synchronization is required from either an Enterprise

Service Repository or Integration Directory perspective. This is the same as the central architectural

model with the exception of communication channel configurations in the Integration Directory pointing

to different adapter engines. The following table highlights the associated consideration per

component when dealing with software logistics and synchronization.


ESR With one PI instance per tier, standard transport rules apply for moving development

objects inside the ESR via CTS+.


objects straight forward. The integration directory requires more consideration due to the

selective transport of objects and dependent configuration. An example of this is the

communication channel configuration which is tier specific. You do not transport acommunication channel of type file pointing to a development location into quality

assurance. These restrictions are standard PI transport considerations which are

dependent on your landscape and client topology. As mentioned above, in distributed

scenarios special attention should be given to the communication channel configuration

such that the scenario points to the appropriate adapter engine, central or de-central.


quality assurance and production is not required. Publication is recommended per tier

post transport of the associated object in either the ESR or ID as end point configuration

and policy information is generated at this time.

SLD The system landscape directory content can be transported using CTS+ or historical

manual file export and import. As the SLD topology is independent of the PI landscape

you may have either one central SLD or a SLD per tier. The SLD is used in other

scenarios other than Integration or PI and hence the selected architectural SLD topology

will dictate the required synchronization or transport strategy.

Proxy Development Proxy development in the corresponding business systems should be transported in a

synchronized fashion along with ESR and Integration Directory content. This is a project

specific decision and is dependent on how an integration scenario needs to be promoted

throughout the landscape. Depending on how coupled your scenarios are with proxy

code this may not be required and could be done independently. Specific consideration

should be given to changes in Service Operation signatures to ensure each integrated

system proxy definition equals what has been defined in your ESR and resulting

Integration Scenario.




The following diagram shows a sample transport flow of ESR design time objects in a three tiered

landscape of a distributed architectural model using a central governance model. This is the same as

the central architectural model standard across SAP PI installations and is used to demonstrate

variations evident in the federated architectural model. The people located in the development layer

indicate object authoring and modificaitons.

6.4.3 ToolsIn a federated scenario the following tools can be utilized to implement such an architectural model.




CTS+

Web Dispatcher

Directory API



7. Federated

Due to the more complex architecture the federated model allows greater flexibility however

at the expense of a higher TCO. Such organizations are usually larger in size and require a

high degree of abstraction in their landscape. Below is one example of a federatedarchitecture.

Assessment information is relative to federated architectures in general. Variation specificdetails are described in subsequent sections.

Assessment Summary


Local Autonomy TCO

Flexibility Governance hard to enforce

Availability & Reliability Administration & Operations

Downtime Independence & Abstraction Additional Hardware Requirements

Multi Hop Scenarios may be introduced




7.1 Reasons

There can be many reasons for federation which are driven by either technical or business

requirements. Of these reasons the technical implementation supports segmentation or provides

business continuity capabilities.

Segmentation

Geographical

Organization and divisional autonomy due to legal or

operational reasons.

Separation of A2A and B2B integration scenarios for

security reasons.

Separation by process types such as transactional versus

master data.

Quality of Service obligations

Billing requirements based on volume

Prioritization of messages Security issues around personal data

Business Continuity



Also in contrast to customer driven reasons for federation there are also some SAP driven reasons.

These include isolation for upgrade path dependency and decoupling or dependencies such as

business systems and portal UI.

7.2 ExamplesThe following examples demonstrate a federated deployment of PI. Each has its own associated

advantages and disadvantages and more information can be found in the appendix.

Type Description

Segmentation

Region PI Integration Servers

Region PI Integration Servers with De-central Adapter Engines

Central PI Integration Server with regional PI integration servers

Central PI Integration Server with regional PI Integration Servers and De-Central Adapter

Engines


Localized PI Integration Servers with De-central Adapter Engines.

Business

Continuity

Central PI integration Server with redundant Integration Server to be used in controlled

switch over scenarios when upgrading or patching.




The following table gives more details against specific criteria and aims to give a quick reference for

further comparison. Definitions can be found in the appendix. Federation demonstrates a high level of

abstraction and performance benefits yet suffers from the additional levels of administration and

governance to maintain and operate such a complex environment.


Administration Effort High Maintaining multiple PI instances in a given tier adds complexity and

is difficult to achieve. If local organizations are in control of their

isolated PI instance then minimal global landscape governance is

achieved. This may be seen as an advantage as technical

abstraction may allow more freedom and resistance to downtimes

globally. However the effort to synchronize systems across a global

landscape would be seen as difficult.

Availability Medium Due the technical separation of PI instances this deployment modeloffers the highest availability rating. Service Level Agreements

would need to be enforced to guarantee processing of messages

from dependent regions or organizations.

Monitoring Complexity High Monitoring in a federated deployment model is very difficult when

aiming to manage the entire landscape. Solution Manager does

allow for multiple instances and domains and a strong global

monitoring strategy needs to be implemented. Federation usually

dictates a political separation of monitoring responsibilities so this

may not be an issue.

TCO High TCO is at its highest in a federated deployment model due to the

number of installations and subsequent impact on required support

before, during and after installation.

Performance Internal High Internal Performance is at its best in a federated deployment model

due to de-central processing of messages and business processes

in satellite integration servers. Configuring each scenario requires

additional effort as the each connection from integration server to

integration is specifically nominated.

Network Efficiency High Network performance is optimized in the federated deployment

model as physical distances can be minimized but also messages

are only sent to other locations or integration servers if required.

Common Business

Process Delivery

Low Due to one or more design times in a federated deployment model

the ability to enforce a high level of object re-use is minimized. This

can be achieved with strict policies which are mentioned in the

recommendations below but must be seen as a disadvantage when

considering the effort to maintain consistent use of objects.

Globalization &

Localization

High In a federated deployment model the ability to meet local

requirements are maximized however the global requirements may

not be met due to lack of governance.



7.4 Recommendations

7.4.1 Governance

Governance can be defined by the policies, processes and procedures that support any IT landscape.

In the context of a PI solution and this document we shall define governance relative to changemanagement of design time objects in the Enterprise Service Repository and Integration Directory.






Central

Design time objects are created and changed in only one development system only and then

replicated consistently throughout the landscape as required. No changes are to be made or new







The implementation of ACL’s and user roles for

design times objects creation and authoring is


component in subsequent sections for moreinformation.

Local

Design time objects are created and changed in any development system. Local PI instances are

responsible for their own development objects and not replicated. The ability to re-use objects and

avoid redundancies is minimized due to local autonomy and resulting loss of control.

At the very least you should implement naming

conventions per region or division such that if

consolidation can take place at a later stage it may

still be possible to converge in a controlled manner.

This mode guarantees isolation between each PI

instance which may be a business requirement

allowing complete autonomy and agility when on-

boarding or decommissioning segments.



Mixed

Changes to be made centrally and locally however with strict control mechanisms to ensure some

object reuse is possible and redundancies are minimized. An example of such a mechanism is

enforcing naming conventions or scenario specific object separation. E.g. Transactional relevant

objects v master data.

Demarcation of object ownership is recommended.

A global PI hub may be responsible for master data

and local regions handle transactional scenarios. Or

possibly all SAP centric content is managed globally

and local divisions or regions manage legacy system

objects and scenarios.

The aim of this mode is achieve some level of re-use

and convention such that redundancies are avoided.

This is demarcation is specific to each organization.


In a federated deployment model the transport and synchronization of objects is complex and requires

careful consideration per integration scenario. As discussed it all depends on whether integration

scenarios are local or global in nature. If the integration scenarios are local and are not multi-hop to

each integration server then at least the development objects are discrete in scope. If your integration

scenarios cross domains and require multi-hop integration with other integration servers then an

increase amount of synchronization is required when promoting scenarios within your landscape.

Please see the next section for information.Generally the level of federation and combination of governance models will determine how complex

you synchronization effort will be. The following table highlights the associated consideration per

component when dealing with software logistics and synchronization.


ESR With many ESRs in a single tier there may be a requirement to synchronsize all or

some objects dependent on your selected governance model. In a central model

where you are able to create and author objects centrally then you can replicate

everything down to other integration server ESRs and avoid complex requirements

around transport rules. Such a scenario is recommended where possible. Insituations where you have a local governance model then object will not need to be

synchronized in the ESR as they are autonomous and have no dependencies to

each other. For the mixed governance approach then careful consideration is

required to transport selected objects to selected Integration Servers. This is hard

to achieve and it would be advisable to replicate all objects simplifying transports

rules followed by the utilization of security to remove unwanted access or changes.


objects straight forward. The integration directory requires more consideration due

to the selective transport of objects and dependent configuration. An example of

this is the communication channel configuration which is tier specific. You do not

transport a communication channel of type file pointing to a development locationinto quality assurance. These restrictions are standard PI transport considerations



which are dependent on your landscape and client topology.

In federated scenarios the synchronization of Integration Directory scenarios is

dependent on the underlying ESR content being required for configuration.

Integration Directory scenarios tend to be configured locally at each integration

server instance as they are specific to the local business scenario. It is possible to

follow a central governance model however this is usually only for scenarios thatare being executed centrally.


quality assurance and production is not required. Publication is recommended per

tier post transport of the associated object in either the ESR or ID as end point

configuration and policy information is generated at this time.

SLD The system landscape directory content can be transported using CTS+ or

historical manual file export and import. As the SLD topology is independent of the

PI landscape you may have either one central SLD or a SLD per tier. The SLD is

used in other scenarios other than Integration or PI and hence the selected

architectural SLD topology will dictate the required synchronization or transport

strategy. Please see associated documents in section “Reference Material”. In

federated scenarios the SLD strategy still follows the same guidelines compared to

central or distributed models. Effectively each PI instance will require consistent

SLD content and system information across your landscape and there are standard

SLD capabilities to facilitate this.

Proxy Development Proxy development in the corresponding business systems should be transported in

a synchronized fashion along with ESR and Integration Directory content. This is a

project specific decision and is dependent on how an integration scenario needs to

be promoted throughout the landscape. Depending on how coupled your scenarios

are with proxy code this may not be required and could be done independently.

Specific consideration should be given to changes in Service Operation signatures

to ensure each integrated system proxy definition equals what has been defined in

your ESR and resulting Integration Scenario.




The following diagrams show a sample transport flow of ESR design time objects in a three tiered

landscape of a federated architectural model with global and regional PI instances. We shall

demonstrate how a central governance model may impact software logistics of the ESR followed by a

local governance model and relevant transport flow. The people illustrated below indicate object

authoring and are specific to a given integration server. The transportation paths in this examples areonly two of many possibilities depending on your organizational requirements. It is only intended to

demonstrate how you could synchronize ESR objects in a sample federated landscape and does not

attempt to recommend CTS+ configuration. Please consult the appropriate expertise when defining

your own transport strategy specific to PI and ESR.

Central Governance Model

Local Governance Model



7.4.3 Tools

In a federated scenario the following tools can be utilized to implement such an architectural model.




CTS+

Web Dispatcher

Directory API

7.4.4 Business System Communication Strategy

In any architectural model, particularly federation a decision needs to be made regarding business

system communication strategy. What PI integration servers can talk to what business systems?

Should a hub to hub or a hub to system model be permitted? The following diagram illustrates the

differences in approach.

Hub to Hub

This approach normalizes communications between

regions or divisions such that each business system

belongs to a specific PI integration Server. Any

messages or scenarios requiring integration to a given

business system must be processed via its nominated

integration server. This allows consistent

communication paths but requires additional

configuration due to the additional hops from

integration server to integration server. Consideration

must be given to performance implications and possible demarcation options based on protocol. Use

of integrated configuration in the advanced adapter engine bypasses such an approach.

Hub to Business System

This approach allows each integration server to

communicate directly with each business system and

hence the complexity of integration scenarios is

increased. Managing such an approach requires a

higher level of governance and may be restricted to

certain protocols. For simplicity this diagram only

illustrates one integration server communicating with

each business system.



8. Recommendations

8.1 Architectural Model SelectionIn any software implementation an organization can either have a new landscape

or one that is already in place. As a result this presents an opportunity for

consolidation or expansion. Where possible it is important consolidate and

leverage the least complex architecture to minimize TCO and meet the

requirements of your organization. Central and distributed deployment models

should be sufficient for most organizations with federation available to support the

most complex landscape if required.

Approach Description

New A landscape does not exist providing a unique opportunity to implement a clear

strategy and governance policy meeting the requirements of existing stakeholders

whilst positioned to scale when deemed appropriate.

Existing A landscape already exists requiring a degree consolidation and aggregation of

components. Strategy and governance policies must allow for transition yet be

aimed at the longer term architectural end state.

Type Description

Central Central PI Integration Server supporting global requirements

Distributed Central PI Integration Server with de-central adaptor engines located regionally

Central PI Integration Server with de-central adaptor engines close to businesssystems

Central PI Integration Server with separate DAE or AAE adaptors adaptor engines

with message dispatching

Central PI integration Server with redundant Adapter Engines to be used in

controlled switch over scenarios when upgrading or patching.

Central PI Integration Server with an additional Adapter Engine in a De-Militarized

Zone (DMZ).

Federated Region PI Integration Servers

Regional PI Integration Servers with de-central adaptor engines close to businesssystems

Central PI Integration Server with regional PI integration servers

Central PI Integration Server with regional PI Integration Servers and Adapter

Engines


Localized PI Integration Servers with one or more Adapter Engines.

Central PI integration Server with shadow Integration Server to be used in controlled

switch over scenarios when upgrading or patching.

Consolidation

Expansion



8.2 Governance Model Selection

Governance can be defined by the policies, processes and procedures that

support any IT landscape. In the context of a PI solution and this document we

shall define governance relative to change management of design time objects in

the Enterprise Service Repository and Integration Directory. Who can change

what and where it can be changed are of relevance in this criterion.

If you have multiple ESR’s in a federated scenario then a decision needs to be made where

changes can be made. Should they be done in one central ESR only or should changes be permitted

locally and then somehow replicated with appropriate controls. To summarize the following models

are evident in the context of PI and governance.

Central Design time objects are created and changed in only one

development system only and then replicated consistently

throughout the landscape as required. This approach is

recommended due to the high level of object re-use.

Utilizing security roles and ACL’s against design -timeobjects should be leveraged mitigate issues surrounding

object ownership.

Local Design time objects are created and changed in any

development system. The ability to re-use objects and

avoid redundancies is minimized due to local autonomy

and resulting loss of control. This approach is not

recommended due to lack of consistency in business

process delivery.

Mixed Design time objects are created and changed both centrally

and locally. Strict control mechanisms ensure some object

reuse whilst redundancies are minimized. An example of

such a mechanism is enforcing naming conventions or

scenario specific object separation. E.g. Transactional

relevant objects v master data. This approach is

recommended for federated scenarios where the central

approach is not viable.



8.3 Tools

SAP PI federation is a complex undertaking and one that requires clear strategy and strict

governance. Although there is no single tool to manage and administrate all components over every

architectural model, the following tools provide measurable benefits in such scenarios.

Type Description

CTS+ Manages Transports in SAP Heterogeneous System Landscapes

Directory API A programming interface found in the Integration Directory for dynamically

changing configuration.

Web Dispatcher A software application which forwards http communications dynamically to

specific locations based on availability and configuration.

8.3.1 CTS+The Enhanced Change and Transport System (CTS) helps you to organize development projects in

ABAP Workbench and in Customizing, and then transport the changes between the SAP systems in

your system landscape. As well as ABAP objects, you can also transport Java objects (J2EE, JEE)

and SAP-specific non-ABAP technologies (such as Web Dynpro Java or SAP NetWeaver Portal) in

your landscape. In SAP PI implementations there are a combination of ABAP and Java objects which

need to be transported from development through to production. The following section highlights the

possible utilization of CTS+ in the different architectural models discussed earlier.

8.3.2 Directory API

In addition to the Integration Builder you will also find a programming interface (Application

Programming Interface (API)) with which you can access, edit, and activate objects in the Integration

Directory. The programming interface is based on the fundamental configuration options that are

possible in the Integration Directory.

The programming interface consists of Web Services with which you can perform operations on

configuration objects (for example, creating configuration objects or editing the attributes of

configuration objects). The Web Services are fully implemented at the server and can be called by a

valid client application.

The use of the Directory API in the context of federated or distributed architectural models is important

in switch over scenarios. You can utilize this API to perform a controlled switch in runtime processing



from a given integration server or adapter engine. This is done by changing the communication

channel configuration of relevant integration scenarios such that a new adapter engine is referenced.

This allows patching and various other downtime activities to be executed. Please see section

“Reference Material” for more information.

8.3.3 Web Dispatcher The SAP Web dispatcher installable software application located between the Web client (browser or

soap enabled application) and your SAP system that is running the Web application. It forwards the

incoming requests to the AS ABAP of the SAP system. The Web dispatcher is a load balancing

solution that retrieves system administration and configuration from the message server.

In the context of the architectural models referenced in this document a web dispatcher can be used to

dynamically route messages to different integration servers and adapter engines. This is useful when

combined with the Directory API as you can perform controlled switch over scenarios to support

downtime and other related activities. Please see section “Reference Material” for more information.

8.4 SLD StrategyThe System Landscape Directory of SAP NetWeaver (SLD) serves as a central information repository

for your system landscape. A system landscape consists of a number of hardware and software

components that depend on each other with regard to installation, software updates, and demands on

interfaces. Information in the SLD is used by various SAP tools, such as SAP Solution Manager, SAP

NetWeaver Administrator and SAP PI.

When considering the deployment of an SLD in your landscape a number of considerations must be

taken into account. Whilst an SLD strategy is important to PI architecture it is also a consideration in

SAP environments generally and hence we shall only highlight the main decision points. Such

strategies are detailed at length in other documents which can be located in the section “Reference

Material”.

How many SLD’s are required?

Single SLD for the entire landscape

Non Production SLD (DEV/QA) and a

production SLD (PRD)

SLD per tier.

Where the SLD should be installed?

Solution Manager, PI or other.

What applications and systems require SLDcommunication?

SAP PI

Business Systems

Web Dynpro development



8.5 Service Registry Strategy

The Services Registry is a registry for Web services. Located centrally within an SOA landscape, it

contains entries for all services and service definitions in that landscape, with references to the

services’ relevant WSDL metadata and to the locations of the callable service endpoints. The

registered services are classified using semantic-rich classification systems to enable browsing of

services by classification.

Implementing a service registry is independent of SAP PI and hence we shall only highlight the main

decision points of service registry topology. For more information please refer to the section

“Reference Material for links to supporting information.

How many service registries are required?

Central Registry

One service registry representing internal

services and one representing external

services.

One per division or region.

Where should they be located?

Central services such as solution manager

or PI.

Independent java application server.

Bound to the ESR. Recommended

8.6 Security UtilizationAlthough this has been covered to an extent within the governance section is it important to re-iterate

the application of security in the context of PI and distributed architectures. It is common for

organizations to specify they need federation due to security reasons. At runtime this is a typical use

case but at design time new features within both the ESR and the Integration Directory now allow very

strict controls. It is possible to force sets of users to create/display/modify objects at various levels of

granularity and hence to roles can be created to realize such requirements. In our global example you

can allow developers in the Europe to only access and change objects that they are assigned to and

subsequently the same with users in APJ. The recommendation is to thoroughly investigate the

application of security as a means to enable central governance and simplify your PI solution.

8.7 Justify any architectural variation

Once an architectural model has been selected and implemented along with associated dependencies

it is important not to deviate unless clearly justified. Impact on the organization and incumbent

landscape can be significant. Governance benefits associated with the central and distributed models

should not be underestimated.



9. SAP NetWeaver Composition Environment

Considerations

Many organizations have either SAP PI or SAP NetWeaver Composition Environment implemented intheir landscape. Introducing the other solution indirectly creates a federated design-time environment

as the ESR is delivered with both solutions. In such cases, where you have SAP NetWeaver CE and

SAP NetWeaver PI installations in your system landscape it is recommended to maintain design

objects in one ES Repository delivered with SAP PI.

To determine if one ESR repository can be used in such a use case depends primarily on the versions

of SAP CE and SAP PI in your landscape. The diagram below illustrates such dependencies followed

by a sample use case with appropriate explanations.



Example

You organization has a SAP application based on SAP NetWeaver 7.0 such as SAP ERP and is also

running SAP NetWeaver PI 7.0/ XI 3.0. You would like to use both SAP PI and SAP CE. Please see

the next page for information on possible solution and approach.

Solution A

In the first variant shown above we can see a

recommendation to upgrade and use the ESR and

Service Registry of a new PI 7.1 instance. The

following considerations must also be taken into

account:

Enterprise Services Repository with PI 7.1 used as a central repository in the landscape

ES Repository with PI 7.1 manages both integration and service provisioning content centrally

In case of upgrade from PI 7.0 to 7.1, content from existing ES Repositories on CE 7.1x canbe migrated without any change

Outlook: Support for using the latest ES Repository in the landscape across PI & CE

Solution B

Or as an alternative without an actual upgrade of

SAP PI you can install SAP CE and use the ESR

and service registry of this installation whilst

maintaining old legacy 3.0 and 7.0 design-time

objects in the old Integration Repository etc. This is

a federation of design-time components with the

complication of different releases. The following consideration must also be taken into account:

Integration content maintained in PI 7.0 as part of the Integration Repository

Service provisioning content maintained as part of Enterprise Services Repository in CE 7.1x

Content can be transported across the two repositories using LM Tools (CMS, CTS+)

Content can migrated from the ES Repository with CE to PI 7.1 in case of upgrade

One ABAP backend system can connect to only one repository currently

To summarize when you would like to use both SAP CE and SAP PI in your landscape it really

depends on what versions of the solutions you are using. If you must maintain a XI 7.0/3.0 then you

have sufficient differences in the ESR object meta model to warrant an additional ESR for the SAP CE

installation. This is valid until you can migrate objects in an upgrade situation and consolidate

repositories. For more information please section “Reference Material”.



10. Summary

This document has introduced the main architectural models in the context of federation and

discussed the associated advantages and disadvantages for each. Whilst federation is supported

using standard tools it is largely an exercise in planning, strategy and governance. Implementingfederated scenarios should not be undertaken without appropriate consideration of the associated

implications. Where possible it is important to start with a central architectural model and thoroughly

justify any expansion. For organizations starting out with a federated architectural model due to an

existing landscape, consolidation is recommended. Ultimately your organizational requirements will

drive an appropriate solution and as outlined in this document SAP PI offers flexible deployment

options.



11. Appendix - Examples in Detail

11.1 CentralAs there is only one example of this architectural model it can be found in the original section of the

document and not repeated here.

11.2 Distributed

11.2.1 Central PI Integration Server with De-Central

adapter engines located regionally

The use of de-central adapter engines regionally allowsdistribution of message processing whilst leveraging centralgovernance. Locating the adapter engines in each region is

a first step in distribution removing the need for messages tobe sent back to the central integration server over a lessreliable protocol compared to XI message format. Thisscenario does not need to be regionally aligned and couldrepresent countries, states or cities etc.

11.2.2 Central PI Integration Server with de-central adapter

engines located near business systems

This scenario further distributes adapter engine closer toeach business system, instead of having a adapter engineper region. A notable increase in TCO is evident due to theincreased hardware requirements supporting each adapterengine installation. An analysis on TCO v benefits shouldbe done before deploying such a scenario. Note therepresentation of adapter en

11.2.3 Central PI Integration Server with Adapter Enginesdeployed with web dispatching for upgrade purposes.

This scenario utilizes the web dispatcher to enable acontrolled switch over between adapter engines. This isonly relevant for j2ee adapter engines and not j2se adapterengines. The use of the directory api is also available toprovide a programmatic change of communication channelsand associated adapter engine. This scenario is not drivenby expansion or consolidation but the resulting distributionmodel is a product of this implementation.



11.3 Federated

11.3.1 Regional PI Integration Servers

This has been introduced earlier and demonstratesfederation based on regions. The diagram illustrates threeregions but this could be scaled differently to representcountries or other granularity. The more servers youintroduce into the landscape tier the higher the TCO impacton your organization.

11.3.2 Regional PI Integration Servers with De-Central

Adapter Engines

This scenario allow local processing via regional integrationservers but also further distribution is evident with local de-central adapter engines located close to the businesssystems. This provides queue capabilities and protocolchange very close to the business system at the expense ofTCO and centralised maintenance. Central governancemodels are recommended. This is a more extreme case offederation and not recommended for most organizations.

11.3.3 Central PI Integration Server with regional PIIntegration Servers

This scenario has a central integration server supporting

specific global integration scenario such as master data only

and allows the regional integration servers to support

localized scenarios. E.g Transactional messages. This

scenario has been noted in large global organizations

however the TCO impact cannot be underestimated due to

the number of integration servers involved.

11.3.4 Central PI Integration Server with regional PI

Integration Servers and De-Central Adapter Engines

This scenario see an extension of the last with a fully

federated global solution with additional de-central adapter

engines deployed close to business systems. This is an

extreme case of federation and poses serious overheads in

administration and increased TCO. It is not a

recommended solution for the majority of organizations and

is depicted here to merely show what is possible not what is

likely.



11.3.5 Localized PI Integration Servers

This scenario has local PI integration server installed close

to the business systems. Again this is an extreme case of

federation and offers little to no consolidation possibilities.

Some organizations have chosen this use case when

acquiring new business or divisions such that they can

clearly decouple each asset which leads to some agility

when selling. This is not common in most organizations

and again is depicted here to demonstrate what is possible.

Intra PI integration server communications have not been depicted due to the complex nature of

possible integration points and would result in a confusing illustration.

11.3.6 Localized PI Integration Servers with De-Central

Adapter Engines

This example is another extreme case of federation and

really offers little in terms of benefit by abstraction. Giventhere are already local PI integration servers each with theirown central adapter engine, another de-central adapterengine per local area is relatively redundant. This is not arecommended PI architectural deployment option andshould be avoided. Intra PI integration servercommunications have not been depicted due to thecomplex nature of possible integration points and wouldresult in a confusing illustration.

11.3.7 Central PI integration Server with redundant

Integration Server to be used in Switch Over scenarios

As described in the distributed architectural model there is a clear use case for providing fastcontrolled switch over scenarios. Whilst the previousexample was switching between adapter engines eithercentral or de-central, this example shows the same conceptapplied to complete PI integrations server instances. Thisenables a controlled phasing of runtime messages fromone PI instance to another allowing peripheral downtimeactivities to be executed. This deployment option requiresthe combination of tools and correct execution sequence tobe effective. Please see the “Recommendations” and“Tools” sections for more information. Additional how-to guides have been published on this conceptproviding thorough information on this topics.



12. Appendix - Assessment Criteria

The following criteria have been used to provide a clear comparison and reference for describing the

relationship between each architectural deployment option.

12.1 AdministrationAdministration defines how difficult the overall landscape is to operate and maintain with respect to

downtime and planned upgrades etc. The application of support packages, notes and hot fixes are

applicable in this criterion.

12.2 AvailabilityRelates to how available the Process Integration system for message processing. In distributed and

federated models availability is improved due to de-central message processing capability and

technical abstraction.

12.3 MonitoringWith SAP NetWeaver Process Integration, IT professionals can configure and monitor service-enabled

applications across the landscape. Using the integrated capabilities of SAP Solution Manager and

SAP NetWeaver, IT administrators can monitor the availability and performance of applications,

processes, and services; analyze the root-cause of problems; and undertake optimization measures.

This criterion defines the complexity and coverage of the monitoring solution in a given deployment

model.

12.4

TCOTotal Cost of Ownership defines just how much it costs to implement, operate and support a given IT

solution. This includes areas such as the technical infrastructure, software licensing, implementation

costs, support costs, upgrade and downtime costs etc. Whilst there are many models for calculating

TCO, this document aims to show relative TCO in each distinct architectural model, central, distributed

and federated.

12.5 Internal Performance

This criterion covers the internal performance of the SAP application software, database and operating

system when processing a message in SAP Process Integration. Other variables such as message

packaging and size of messages are assumed constant and this is an indicate measurement showing

relationship between each architectural model.

12.6 Network Utilization

Network looks at the impact or utilization on the physical communication network. The geographical

location of business systems, integration servers and adapter engines are taken into consideration.

Latency and reliability are also examples of such considerations.

12.7 Common Business Process Delivery

The ability to enforce a common business processes across the Process Integration landscape. This

includes design-time object re-use and redundancy avoidance.



12.8 Globalization & Localization

The ability to meet local and global requirements both technically and business related. As an

example a federated solution with local governance may add flexibility and abstraction whilst a

centralized governance model may not meet local requirements.



Documents

PI Federation – An Overview