PI Federation - An Overview

SAP NetWeaver How-To Guide
PI Federation An Overview
Applicable Releases: SAP NetWeaver Process Integration 7.0 SAP NetWeaver Process Integration 7.1 (Including Enhancement Package 1)
Topic Area: SOA Middleware
Capability: Service Bus
Version 1.0 March 2010
Copyright 2010 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered 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 with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. 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 for errors 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 SAPs Support Services and may not be modified or altered in any way.
Document History
Document Version 1.00 Description First official release of this guide
Typographic Conventions
Type Style Example Text Description 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 File and directory names and their paths, messages, names of variables and parameters, source text, and names of installation, upgrade and database tools. User entry texts. These are words or characters that you enter in the system exactly as they appear in the documentation. Variable user entry. Angle brackets indicate that you replace these words and characters with appropriate entries to make entries in the system. Keys on the keyboard, for example, F2 or ENTER.
Icons
Icon Description Caution Note or Important Example Recommendation or Tip
Example text
Example text
<Example text>
EXAMPLE TEXT
Table of Contents
1. 2. 3. Introduction ..................................................................................................................... 1 Reference Material........................................................................................................... 2 Background Information ................................................................................................. 3 3.1 3.2 PI Domain................................................................................................................. 3 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 4.2 Architectural Models ................................................................................................. 6 Architectural Progression .......................................................................................... 7
5.
Central.............................................................................................................................. 8 5.1 5.2 5.3 5.4 Reasons ................................................................................................................... 9 Examples.................................................................................................................. 9 Assessment Summary ............................................................................................ 10 Recommendations .................................................................................................. 11 5.4.1 Governance ................................................................................................ 11 5.4.2 Software Logistics & Synchronization.......................................................... 12 5.4.3 Tools .......................................................................................................... 13
6.
Distributed ..................................................................................................................... 14 6.1 6.2 6.3 6.4 Reasons ................................................................................................................. 15 Examples................................................................................................................ 15 Assessment Summary ............................................................................................ 16 Recommendations .................................................................................................. 17 6.4.1 Governance ................................................................................................ 17 6.4.2 Software Logistics & Synchronization.......................................................... 18 6.4.3 Tools .......................................................................................................... 19
7.
Federated ....................................................................................................................... 20 7.1 7.2 7.3 7.4 Reasons ................................................................................................................. 21 Examples................................................................................................................ 21 Assessment Details ................................................................................................ 22 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 8.2 8.3 Architectural Model Selection .................................................................................. 28 Governance Model Selection .................................................................................. 29 Tools ...................................................................................................................... 30 8.3.1 CTS+ .......................................................................................................... 30
8.4 8.5 8.6 8.7 9. 10. 11.
8.3.2 Directory API .............................................................................................. 30 8.3.3 Web Dispatcher .......................................................................................... 31 SLD Strategy .......................................................................................................... 31 Service Registry Strategy ........................................................................................ 32 Security Utilization .................................................................................................. 32 Justify any architectural variation ............................................................................ 32
SAP NetWeaver Composition Environment Considerations ....................................... 33 Summary........................................................................................................................ 35 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 DeCentral Adapter Engines ............................................................................. 37 11.3.5 Localized PI Integration Servers ................................................................. 38 11.3.6 Localized PI Integration Servers with De-Central Adapter Engines .............. 38 11.3.7 Central PI integration Server with redundant Integration Server to be used in Switch Over scenarios ............................................................................ 38
12.
Appendix - Assessment Criteria ................................................................................... 39 12.1 Administration ......................................................................................................... 39 12.2 Availability .............................................................................................................. 39 12.3 Monitoring............................................................................................................... 39 12.4 TCO ....................................................................................................................... 39 12.5 Internal Performance .............................................................................................. 39 12.6 Network Utilization .................................................................................................. 39 12.7 Common Business Process Delivery ....................................................................... 39 12.8 Globalization & Localization .................................................................................... 40
1. Introduction
SAP Process Integration is used in over three thousand organizations offering an enterprise-class, service-oriented architecture middleware to perform application to application (A2A) and business to business (B2B) integration whilst accelerating composite application development. With so many organizations, variances in landscape architecture are evident and solutions must adapt providing flexibility in such situations. SAP Process Integration offers a number of landscape deployment solutions which can be categorized as central, distributed or federated. This document introduces each architectural model and highlights the associated planning and implementation considerations. The following sections are used to provide a structured approach to the topic: Background Information What is PI Federation? Central Architectural Model Distributed Architectural Model Federated Architectural Model Recommendations
This document has a clear scope of SAP PI architecture topology with specific reference to federation. It does not aim to discuss scaling SAP PI with respect to performance or high availability and is not intended to be a implementation guide rather a discussion on federation. These topics are covered in other documents and should be referenced appropriately. The following table highlights the scope of this docuement with reference to the general scaling concepts of SAP solutions.
Scaling Vertical
Description Increasing hardware specification of servers. Memory etc Additional Java server nodes Additional ABAP dialogue instances
Discussed?
Horizontal
Additional PI De-central Adapter Engines (Distribution) Additional PI Instances (Federation)
2. Reference Material
The following links provide supplementary information which support the topics discussed in this document. The NetWeaver Technology RIG has a number of how-to guides which provide step by step guidance on popular topics. In addition we have also created a number of recorded sessions known 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
All RIG How To Guides XI 3.0 Advanced Adapter Engine CTS+ Central Monitoring Directory API SAP Online Help Process Integration PI Integration Security Service Registry SLD Web Dispatcher ESR PI 7.1 and above PI 7.0
http://www.sdn.sap.com/irj/scn/howtoguides http://www.sdn.sap.com/irj/sdn/index?rid=/webcontent/uuid/b021f97d -b09e-2b10-c296-f7fb1fb345c4 http://www.sdn.sap.com/irj/sdn/index?rid=/webcontent/uuid/608725f0 -2a77-2910-c2b6-8ddddecc4b5e http://www.sdn.sap.com/irj/sdn/index?rid=/webcontent/uuid/dd0326a7 -0d01-0010-f690-b94802b06c8a http://help.sap.com/saphelp_nwpi711/helpdata/en/ca/b977f1c781420 1954f20bb87ad7aab/frameset.htm http://help.sap.com/saphelp_nwpi711/helpdata/en/c0/18907d03b7c04 ca9d07c7efeb5e1a9/frameset.htm http://help.sap.com/saphelp_nwpi711/helpdata/en/44/bc872fc60b700 6e10000000a155369/frameset.htm http://help.sap.com/saphelp_nwpi711/helpdata/en/48/d127e1e1c607 83e10000000a42189d/frameset.htm http://help.sap.com/saphelp_nwpi711/helpdata/en/61/fec608bc27654 daadb20c1e6da7dd1/frameset.htm http://help.sap.com/saphelp_nwpi711/helpdata/en/e1/8e51341a0608 4de10000009b38f83b/frameset.htm http://help.sap.com/saphelp_nwpi711/helpdata/en/fb/c2953fc405330e e10000000a114084/frameset.htm http://help.sap.com/saphelp_nwpi711/helpdata/en/2e/8526937af346a 0bc446905ea964ceb/frameset.htm http://help.sap.com/saphelp_nwpi711/helpdata/en/48/b68474966552 95e10000000a42189b/frameset.htm http://help.sap.com/saphelp_nwpi711/helpdata/en/48/8fe37933114e6 fe10000000a421937/frameset.htm
3. Background Information
3.1 PI Domain
Before discussing PI federation and associated deployment architectures it is important to highlight the components 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 Integration Server Business Process Engine Integration Engine Central Adapter Engine
Description A collection of BPE, Integration Engine and Central Adapter Engine. See below. Runtime execution for ccBPM processes. Runtime execution of pipeline steps such as receiver determination interface determination, etc. 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. Design time for SOA artifacts such as service interfaces, message types, data types and operation mappings. Configuration of integration scenarios defining collaboration profiles, agreements and objects such as receiver determination, etc Monitors PI domain at runtime via Solution Manager. Defines metadata information defining Landscape, Software Catalog and Development objects. New java only deployment options providing ESB capabilities as per AAE without ccBPM and other ABAP capabilities. The PCK is an AS Java-based application that uses the Adapter Framework enable PI messages to be sent to an Integration Server
Enterprise Service Repository Integration Directory Central Monitoring System Landscape Directory Advanced Adapter Engine Extended Partner Connectivity Kit
Note - The Adapter Engine (Java SE) is supported for compatibility reasons only. It hosts only a subset of the adapter functionality and you should only use it if it is a precondition in your environment.
3.2 Adapter Engine

Although SAP PI architecture involves many components, key considerations involve the use of either one or more Integration Servers and associated adapter engines. This section describes the deployment modes of an adapter engine which is important when discussing central, de-central or federated PI architectures. For more information please hyperlinks located in the section Reference Material.
3.2.1
Central v De-Central
A central adapter engine is mandatory and is located within the integration server for SAP PI versions 3.0 through to 7.11. The adapter engine resides on the java application server found in the dual stack installation of SAP PI. Available in all releases. A de-central adapter engine refers to the deployment of the adapter engine remotely relative to the integration server and does not represents an increase in functionality. It is important to emphasize when installing any central adapter engine and de-central adapter engine of the same release they will both support the same features and capabilities. A typical use of a de-central adapter engine is to within a demilitarized zone allowing tight protocol controls with messages flowing to and from the integration 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 of the Integrated Scenario object is restricted to adapters found on the adapter engine only. The diagram illustrates message flow in such a scenario.
4. What is PI Federation?
SAP PI has a number of architectural deployment options which cater for various requirements of an organization. We can classify these deployment options as central, distributed or federated. In a standard installation a single SAP PI instance is deployed per landscape tier. This is known as a central architectural model and is typical in most organizations.
Global
Development Quality Assurance Production
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
EMEA
Federation
APJ
Americas
Development
Quality Assurance
Production
4.1 Architectural Models

Both central and federated architectural models have already been introduced, however an intermediate model known as distributed provides a compromise in complexity. The following table defines the three high level architectural models in SAP PI deployment, followed by a real world sample architectural progression. Advantages and disadvantages for each model will be discussed in subsequent sections.
Central A single integration server communicating with all business systems. Central deployment of SAP PI is a favorable starting point for most organizations as it is represents the smallest possible installation footprint and holds associated TCO benefits. Deviation from this initial architecture requires careful justification due to the increased complexity and associated impacts on business metrics such as total cost of ownership.
Distributed A single integration server with one or more de-central adapter engines communicating with relevant business systems. It is often found in organizations where performance or security reasons dictate a more complex solution compared to centralization. This is a hybrid approach between central and federated models giving the benefits around performance and security with the benefits from centralized governance, maintenance and monitoring.
Federated Two or more integration servers within a single landscape tier communicating with relevant business systems. Use of additional de-central adapter engines per integration server is also possible and adds a further level of complexity. Due to the more complex architecture the federated model allows greater flexibility however at the expense of a higher TCO. Such organizations are usually larger in size and require a high degree of abstraction in their landscape. Below are some customer driven reasons for federation: Organization and divisional autonomy due to legal or operational reasons. Separation of A2A and B2B integration scenarios for security reasons. Separation by process types such as transactional versus master data. Business continuity such as downtime minimization Quality of Service obligations Billing requirements based on volume Security issues around personal data Prioritization of messages Geography Technical Abstraction from upgrades & downtime
In contrast to customer driven reasons for federation there are also some SAP driven reasons such as isolation for upgrade path independency or decoupling of business systems and portal UI bindings.
4.1.1
Architectural Progression
With the central, distributed and federated models introduced it is relevant to mention how organizations decide on a possible deployment solution. Organizations may be installing PI for the first time or have and existing landscape requiring possible consolidation. In either case an organization will follow a similar architectural progression, the difference will be where they a starting from and whether they are looking to consolidate or expand. The following table highlights a typical progression where geographical or political reasons dictate an architectural deviation away from central towards a more distributed and federated solution. Each model type and subsequent examples will be discussed at length throughout this document followed by a summary highlighting a general approach when considering PI federation. Not all variations are listed in the table. Political, geographical or performance influenced progression
Type Central Distributed Description
Expansion
Central PI Integration Server supporting global requirements 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
Consolidation
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.
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. We shall 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 TCO Central Governance Reduced Monitoring Complexity Common Business Process Delivery Development Object Re-use Releases Supported: All Disadvantages Network Load Local Autonomy Reduced Message travels to integration server every time Downtime Dependency Local processing not possible
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 reuse 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 Examples
The following example demonstrates a centralized deployment of PI.
Type Central Description 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 model and offers the smallest installation footprint. In the diagram to the right we can see many business systems bound to a single integration server. One integration server is found per tier with messages forced to travel from each business system. This deployment example is highly recommended where feasable due to a low TCO impact. Please see the assessment summary information for more detail.
5.3 Assessment Summary

The following table gives explanations against specific criteria and aims to give a quick reference for comparison. Criteria definitions can be found in the appendix.
Criteria Administration Effort
Rating Low
Description 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. The availability 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 is affected. 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 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. Internal performance can be seen to be inefficient as every message is being processed by the single instance. This may create 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. Sending messages to the central integration server may be subject to issues associated to network latency which is mentioned below. 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. 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.
Availability
Medium
Monitoring Complexity
Low
TCO
Low
Performance Internal
Low
Network Efficiency
Low
Common Business Process Delivery
High
Globalization & Localization
Low
5.4 Recommendations
The following recommendations highlight the decision points or considerations from choosing a central deployment model.
5.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 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 ESRs, 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 ACLs and user roles for design times objects creation and authoring is recommended. Please see recommendations per component in subsequent sections for more information. Governance in a central deployment model is simplified as there is only one development environment for objects to be created or changed and hence central governance strategy is enforced. Whilst a federated scenario may give you greater flexibility the central model is recommended to guarantee high object re-use and consistency. The use of roles, authorizations and appropriate naming conventions when creating, changing, deleting and displaying design time objects can support global requirements and cater to the needs of local divisions or businesses. Defining these constraints prior to an implementation is imperative for success and possible future growth.
5.4.2
Software Logistics & Synchronization
In a central deployment model the transport and synchronization of objects is optimized due to a single productive instance. As a result no synchronization is required with either the Enterprise Service Repository or Integration Directory. The following table highlights the associated consideration per component when dealing with software logistics and synchronization.
Component ESR
Considerations 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+. 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 quality assurance. 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 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. 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 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.
Integration Directory
Service Registry
SLD
Proxy Development
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
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
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 around performance 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 Central Governance Common Business Process Delivery Development Object Re-use Performance Improvements due to local processing Reliability due to local queuing capabilities Releases Supported: All Disadvantages Increased TCO from central model Design Time Autonomy Reduced Additional Hardware Requirements
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 and internal zone abstraction
6.2 Examples
The 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 Localization
Description 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 Security
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).

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.
Rating Medium
Description 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 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 message queues enable temporary storage until the integrations server is operational. 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 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. Internal performance is improved due to the distribution of components 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. 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. 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. 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.
Availability
Medium
Medium
TCO
Medium
Medium
Network Efficiency
Medium
High
Medium
6.4 Recommendations
The following recommendations highlight the decision points or considerations from choosing a central deployment model.
6.4.1
Governance
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 ACLs 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.
6.4.2
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 ESR
Considerations With one PI instance per tier, standard transport rules apply for moving development objects inside the ESR via CTS+. 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 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 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. 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 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.
Service Registry
SLD
Proxy Development
6.4.2.1
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
Tools
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 federated architecture.
Assessment information is relative to federated architectures in general. Variation specific details are described in subsequent sections.
Assessment Summary Advantages Local Autonomy Flexibility Availability & Reliability Downtime Independence & Abstraction Disadvantages TCO Governance hard to enforce Administration & Operations Additional Hardware Requirements Multi Hop Scenarios may be introduced Releases Supported: All
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 Examples
The 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 Region PI Integration Servers Region PI Integration Servers with De-central Adapter Engines Central PI Integration Server with regional PI integration servers
Segmentation
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.

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.
Rating High
Description 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. Due the technical separation of PI instances this deployment model offers the highest availability rating. Service Level Agreements would need to be enforced to guarantee processing of messages from dependent regions or organizations. 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 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. 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 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. 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. 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.
Availability
Medium
High
TCO
High
High
Network Efficiency
High
Low
High
7.4 Recommendations
7.4.1 Governance
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 ACLs and user roles for design times objects creation and authoring is recommended. Please see recommendations per component in subsequent sections for more information.
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 onboarding or decommissioning segments.
Mixed
Changes to be made centrally and locally however with strict control mechanisms to ensure some object reuse is possible and redundancies are minimized. An example of such a mechanism is enforcing naming conventions or scenario specific object separation. E.g. Transactional relevant objects v master data. Demarcation of object ownership is recommended. A global PI hub may be responsible for master data and local regions handle transactional scenarios. Or possibly all SAP centric content is managed globally and local divisions or regions manage legacy system objects and scenarios. The aim of this mode is achieve some level of re-use and convention such that redundancies are avoided. This is demarcation is specific to each organization.
7.4.2
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 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. In situations 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. 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 quality assurance. These restrictions are standard PI transport considerations
ESR
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 that are 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. 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 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.
SLD
Proxy Development
7.4.2.1
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 are only two of many possibilities depending on your organizational requirements. It is only intended to demonstrate how you could synchronize ESR objects in a sample federated landscape and does not attempt to recommend CTS+ configuration. Please consult the appropriate expertise when defining your own transport strategy specific to PI and ESR. Central Governance Model
Local Governance Model
7.4.3
Tools
7.4.4
Business System Communication Strategy
In any architectural model, particularly federation a decision needs to be made regarding business system communication strategy. What PI integration servers can talk to what business systems? Should a hub to hub or a hub to system model be permitted? The following diagram illustrates the differences in approach. Hub to Hub This approach normalizes communications between regions or divisions such that each business system belongs to a specific PI integration Server. Any messages or scenarios requiring integration to a given business system must be processed via its nominated integration server. This allows consistent communication paths but requires additional configuration due to the additional hops from integration server to integration server. Consideration must be given to performance implications and possible demarcation options based on protocol. Use of integrated configuration in the advanced adapter engine bypasses such an approach. Hub to Business System This approach allows each integration server to communicate directly with each business system and hence the complexity of integration scenarios is increased. Managing such an approach requires a higher level of governance and may be restricted to certain protocols. For simplicity this diagram only illustrates one integration server communicating with each business system.
8. Recommendations
8.1 Architectural Model Selection
In 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 New
Description
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. 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.
Existing
Type Central Distributed
Description
Expansion
Central PI Integration Server supporting global requirements Central PI Integration Server with de-central adaptor engines located regionally Central PI Integration Server with de-central adaptor engines close to business systems 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 business systems Central PI Integration Server with regional PI integration servers Central PI Integration Server with regional PI Integration Servers and Adapter Engines
Consolidation
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.
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 ESRs 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 ACLs against design-time objects should be leveraged mitigate issues surrounding object ownership.
Local
Design time objects are created and changed in any development system. The ability to re-use objects and avoid redundancies is minimized due to local autonomy and resulting loss of control. This approach is not recommended due to lack of consistency in business process delivery.
Mixed
Design time objects are created and changed both centrally and locally. Strict control mechanisms ensure some object reuse whilst redundancies are minimized. An example of such a mechanism is enforcing naming conventions or scenario specific object separation. E.g. Transactional relevant objects v master data. This approach is recommended for federated scenarios where the central approach is not viable.
8.3 Tools
SAP PI federation is a complex undertaking and one that requires clear strategy and strict governance. Although there is no single tool to manage and administrate all components over every architectural model, the following tools provide measurable benefits in such scenarios.
Type CTS+ Directory API Web Dispatcher
Description Manages Transports in SAP Heterogeneous System Landscapes A programming interface found in the Integration Directory for dynamically changing configuration. A software application which forwards http communications dynamically to specific locations based on availability and configuration.
8.3.1
CTS+
The Enhanced Change and Transport System (CTS) helps you to organize development projects in ABAP Workbench and in Customizing, and then transport the changes between the SAP systems in your system landscape. As well as ABAP objects, you can also transport Java objects (J2EE, JEE) and SAP-specific non-ABAP technologies (such as Web Dynpro Java or SAP NetWeaver Portal) in your landscape. In SAP PI implementations there are a combination of ABAP and Java objects which need to be transported from development through to production. The following section highlights the possible utilization of CTS+ in the different architectural models discussed earlier.
8.3.2
Directory API
In addition to the Integration Builder you will also find a programming interface (Application Programming Interface (API)) with which you can access, edit, and activate objects in the Integration Directory. The programming interface is based on the fundamental configuration options that are possible in the Integration Directory. The programming interface consists of Web Services with which you can perform operations on configuration objects (for example, creating configuration objects or editing the attributes of configuration objects). The Web Services are fully implemented at the server and can be called by a valid client application. The use of the Directory API in the context of federated or distributed architectural models is important in switch over scenarios. You can utilize this API to perform a controlled switch in runtime processing
from a given integration server or adapter engine. This is done by changing the communication channel configuration of relevant integration scenarios such that a new adapter engine is referenced. This allows patching and various other downtime activities to be executed. Please see section Reference Material for more information.
8.3.3
Web Dispatcher
The SAP Web dispatcher installable software application located between the Web client (browser or soap enabled application) and your SAP system that is running the Web application. It forwards the incoming requests to the AS ABAP of the SAP system. The Web dispatcher is a load balancing solution that retrieves system administration and configuration from the message server. In the context of the architectural models referenced in this document a web dispatcher can be used to dynamically route messages to different integration servers and adapter engines. This is useful when combined with the Directory API as you can perform controlled switch over scenarios to support downtime and other related activities. Please see section Reference Material for more information.
8.4 SLD Strategy

The 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 SLDs 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 SLD communication? SAP PI Business Systems Web Dynpro development
8.5 Service Registry Strategy

The Services Registry is a registry for Web services. Located centrally within an SOA landscape, it contains entries for all services and service definitions in that landscape, with references to the services relevant WSDL metadata and to the locations of the callable service endpoints. The registered services are classified using semantic-rich classification systems to enable browsing of services by classification. Implementing a service registry is independent of SAP PI and hence we shall only highlight the main decision points of service registry topology. For more information please refer to the section Reference Material for links to supporting information. How many service registries are required? Central Registry One service registry representing internal services and one representing external services. One per division or region.
Where should they be located? Central services such as solution manager or PI. Independent java application server. Bound to the ESR. Recommended
8.6 Security Utilization

Although this has been covered to an extent within the governance section is it important to re-iterate the application of security in the context of PI and distributed architectures. It is common for organizations to specify they need federation due to security reasons. At runtime this is a typical use case but at design time new features within both the ESR and the Integration Directory now allow very strict controls. It is possible to force sets of users to create/display/modify objects at various levels of granularity and hence to roles can be created to realize such requirements. In our global example you can allow developers in the Europe to only access and change objects that they are assigned to and subsequently the same with users in APJ. The recommendation is to thoroughly investigate the application of security as a means to enable central governance and simplify your PI solution.
8.7 Justify any architectural variation

Once an architectural model has been selected and implemented along with associated dependencies it is important not to deviate unless clearly justified. Impact on the organization and incumbent landscape can be significant. Governance benefits associated with the central and distributed models should not be underestimated.
9. SAP NetWeaver Composition Environment Considerations

Many organizations have either SAP PI or SAP NetWeaver Composition Environment implemented in their landscape. Introducing the other solution indirectly creates a federated design-time environment as the ESR is delivered with both solutions. In such cases, where you have SAP NetWeaver CE and SAP NetWeaver PI installations in your system landscape it is recommended to maintain design objects in one ES Repository delivered with SAP PI. To determine if one ESR repository can be used in such a use case depends primarily on the versions of SAP CE and SAP PI in your landscape. The diagram below illustrates such dependencies followed by a sample use case with appropriate explanations.
Example You organization has a SAP application based on SAP NetWeaver 7.0 such as SAP ERP and is also running SAP NetWeaver PI 7.0/ XI 3.0. You would like to use both SAP PI and SAP CE. Please see the next page for information on possible solution and approach. Solution A In the first variant shown above we can see a recommendation to upgrade and use the ESR and Service Registry of a new PI 7.1 instance. The following considerations must also be taken into account: Enterprise Services Repository with PI 7.1 used as a central repository in the landscape ES Repository with PI 7.1 manages both integration and service provisioning content centrally In case of upgrade from PI 7.0 to 7.1, content from existing ES Repositories on CE 7.1x can be migrated without any change Outlook: Support for using the latest ES Repository in the landscape across PI & CE
Solution B Or as an alternative without an actual upgrade of SAP PI you can install SAP CE and use the ESR and service registry of this installation whilst maintaining old legacy 3.0 and 7.0 design-time objects in the old Integration Repository etc. This is a federation of design-time components with the complication of different releases. The following consideration must also be taken into account: Integration content maintained in PI 7.0 as part of the Integration Repository Service provisioning content maintained as part of Enterprise Services Repository in CE 7.1x Content can be transported across the two repositories using LM Tools (CMS, CTS+) Content can migrated from the ES Repository with CE to PI 7.1 in case of upgrade One ABAP backend system can connect to only one repository currently
To summarize when you would like to use both SAP CE and SAP PI in your landscape it really depends on what versions of the solutions you are using. If you must maintain a XI 7.0/3.0 then you have sufficient differences in the ESR object meta model to warrant an additional ESR for the SAP CE installation. This is valid until you can migrate objects in an upgrade situation and consolidate repositories. For more information please section Reference Material.
10. Summary
This document has introduced the main architectural models in the context of federation and discussed the associated advantages and disadvantages for each. Whilst federation is supported using standard tools it is largely an exercise in planning, strategy and governance. Implementing federated scenarios should not be undertaken without appropriate consideration of the associated implications. Where possible it is important to start with a central architectural model and thoroughly justify any expansion. For organizations starting out with a federated architectural model due to an existing landscape, consolidation is recommended. Ultimately your organizational requirements will drive an appropriate solution and as outlined in this document SAP PI offers flexible deployment options.
11. Appendix - Examples in Detail

11.1 Central
As 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 allows distribution of message processing whilst leveraging central governance. Locating the adapter engines in each region is a first step in distribution removing the need for messages to be sent back to the central integration server over a less reliable protocol compared to XI message format. This scenario does not need to be regionally aligned and could represent 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 to each business system, instead of having a adapter engine per region. A notable increase in TCO is evident due to the increased hardware requirements supporting each adapter engine installation. An analysis on TCO v benefits should be done before deploying such a scenario. Note the representation of adapter en
11.2.3 Central PI Integration Server with Adapter Engines deployed with web dispatching for upgrade purposes.
This scenario utilizes the web dispatcher to enable a controlled switch over between adapter engines. This is only relevant for j2ee adapter engines and not j2se adapter engines. The use of the directory api is also available to provide a programmatic change of communication channels and associated adapter engine. This scenario is not driven by expansion or consolidation but the resulting distribution model is a product of this implementation.
11.3
11.3.1
Federated
Regional PI Integration Servers
This has been introduced earlier and demonstrates federation based on regions. The diagram illustrates three regions but this could be scaled differently to represent countries or other granularity. The more servers you introduce into the landscape tier the higher the TCO impact on your organization.
11.3.2 Regional PI Integration Servers with De-Central Adapter Engines

This scenario allow local processing via regional integration servers but also further distribution is evident with local decentral adapter engines located close to the business systems. This provides queue capabilities and protocol change very close to the business system at the expense of TCO and centralised maintenance. Central governance models are recommended. This is a more extreme case of federation and not recommended for most organizations.
11.3.3 Central PI Integration Server with regional PI Integration Servers

This scenario has a central integration server supporting specific global integration scenario such as master data only and allows the regional integration servers to support localized scenarios. E.g Transactional messages. This scenario has been noted in large global organizations however the TCO impact cannot be underestimated due to the number of integration servers involved.
11.3.4 Central PI Integration Server with regional PI Integration Servers and De-Central Adapter Engines
This scenario see an extension of the last with a fully federated global solution with additional de-central adapter engines deployed close to business systems. This is an extreme case of federation and poses serious overheads in administration and increased TCO. It is not a recommended solution for the majority of organizations and is depicted here to merely show what is possible not what is likely.
11.3.5
Localized PI Integration Servers
This scenario has local PI integration server installed close to the business systems. Again this is an extreme case of federation and offers little to no consolidation possibilities. Some organizations have chosen this use case when acquiring new business or divisions such that they can clearly decouple each asset which leads to some agility when selling. This is not common in most organizations and again is depicted here to demonstrate what is possible. Intra PI integration server communications have not been depicted due to the complex nature of possible integration points and would result in a confusing illustration.
11.3.6 Localized PI Integration Servers with De-Central Adapter Engines

This example is another extreme case of federation and really offers little in terms of benefit by abstraction. Given there are already local PI integration servers each with their own central adapter engine, another de-central adapter engine per local area is relatively redundant. This is not a recommended PI architectural deployment option and should be avoided. 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.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 fast controlled switch over scenarios. Whilst the previous example was switching between adapter engines either central or de-central, this example shows the same concept applied to complete PI integrations server instances. This enables a controlled phasing of runtime messages from one PI instance to another allowing peripheral downtime activities to be executed. This deployment option requires the combination of tools and correct execution sequence to be effective. Please see the Recommendations and Tools sections for more information. Additional how-to guides have been published on this concept providing thorough information on this topics.
12. Appendix - Assessment Criteria

The following criteria have been used to provide a clear comparison and reference for describing the relationship between each architectural deployment option.
12.1
Administration
Administration 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
Availability
Relates 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
Monitoring
With 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
TCO
Total 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
The ability to enforce a common business processes across the Process Integration landscape. This includes design-time object re-use and redundancy avoidance.
12.8
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.
www.sdn.sap.com/irj/sdn/howtoguides

PI Federation - An Overview

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PI Federation - An Overview

Uploaded by

Copyright:

Available Formats

SAP NetWeaver How-To Guide

Topic Area: SOA Middleware

Capability: Service Bus

Version 1.0 March 2010

8.4 8.5 8.6 8.7 9. 10. 11.

Additional PI De-central Adapter Engines (Distribution) Additional PI Instances (Federation)

Reference Material Type Topic Link

RIG Know How Series

3.2 Adapter Engine

4.1 Architectural Models

5.2.1 Central PI Integration Server supporting global requirements

5.3 Assessment Summary

Criteria Administration Effort

Common Business Process Delivery

Globalization & Localization

Software Logistics & Synchronization

Sample ESR Transport Flow

Business Continuity Security

6.3 Assessment Summary

Criteria Administration Effort

Common Business Process Delivery

Globalization & Localization

Software Logistics & Synchronization

Sample ESR Transport Flow

7.3 Assessment Summary

Criteria Administration Effort

Common Business Process Delivery

Globalization & Localization

Software Logistics & Synchronization

Sample ESR Transport Flow

Local Governance Model

Business System Communication Strategy

Type Central Distributed

8.2 Governance Model Selection

Type CTS+ Directory API Web Dispatcher

8.4 SLD Strategy

Where the SLD should be installed? Solution Manager, PI or other.

8.5 Service Registry Strategy

8.6 Security Utilization

8.7 Justify any architectural variation

9. SAP NetWeaver Composition Environment Considerations

11. Appendix - Examples in Detail

11.3.2 Regional PI Integration Servers with De-Central Adapter Engines

11.3.3 Central PI Integration Server with regional PI Integration Servers

Localized PI Integration Servers

11.3.6 Localized PI Integration Servers with De-Central Adapter Engines

12. Appendix - Assessment Criteria

Common Business Process Delivery

Globalization & Localization

You might also like