pi federation – an overview
TRANSCRIPT
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
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 2/47
© 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.
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 3/47
Document History
Document Version Description
1.00 First official release of this guide
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 4/47
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
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 5/47
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/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 6/47
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
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 7/47
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)
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 8/47
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
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 9/47
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.
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 10/47
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.
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 11/47
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
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 12/47
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.
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 13/47
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
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 14/47
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
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 15/47
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.
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 16/47
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.
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 17/47
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.
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 18/47
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.
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 19/47
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
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 20/47
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
Advantages Disadvantages
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
Releases Supported: All
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 21/47
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
Business continuity such as downtime minimization
Technical Abstraction from upgrades & downtime
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).
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 22/47
6.3 Assessment Summary
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.
Criteria Rating Description
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.
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 23/47
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.
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 thenreplicated 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 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.
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 24/47
6.4.2 Software Logistics & Synchronization
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.
Component Considerations
ESR With one PI instance per tier, standard transport rules apply for moving development
objects inside the ESR via 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 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.
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.
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 25/47
6.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 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.
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
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 26/47
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
Advantages Disadvantages
Local Autonomy TCO
Flexibility Governance hard to enforce
Availability & Reliability Administration & Operations
Downtime Independence & Abstraction Additional Hardware Requirements
Multi Hop Scenarios may be introduced
Releases Supported: All
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 27/47
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
Business continuity such as downtime minimization
Technical Abstraction from upgrades & downtime
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
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.
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 28/47
7.3 Assessment Summary
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.
Criteria Rating Description
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.
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 29/47
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.
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 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.
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 30/47
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.
7.4.2 Software Logistics & Synchronization
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.
Component Considerations
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.
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 locationinto quality assurance. These restrictions are standard PI transport considerations
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 31/47
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.
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. 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.
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 32/47
7.4.2.1 Sample ESR Transport Flow
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
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 33/47
7.4.3 Tools
In 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
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/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 34/47
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
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/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 35/47
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/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 36/47
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
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 37/47
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/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 38/47
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.
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 39/47
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.
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 40/47
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”.
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 41/47
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.
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 42/47
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.
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 43/47
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.
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 44/47
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.
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 45/47
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.
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 46/47
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.
8/3/2019 PI Federation – An Overview
http://slidepdf.com/reader/full/pi-federation-an-overview 47/47