Dependencies on Other Usage Types (Software Units)
SAP NetWeaver Process Integration (SAP PI) requires a dual-stack (ABAP+Java) .
The default installation variant for an SAP PI system is the all-in-one installation where all the central components - namely the central Integration Server, Integration Builder, and System Landscape Directory (SLD) - are installed on one host.
All ABAP components and all Java components of the SAP PI system run on the primary application server instance (central instance) of the ABAP application server. The ABAP stack and the Java stack of the dual-stack system can be secured as one unit. For scalability reasons, additional dual-stack (ABAP+Java) application server instances (dialog instances) can be added on different hosts.
Start with the all-in-one scenario and secure all components of the all-in-one installation by using switchover software. This means that you do not need to perform any additional actions concerning the communication between these components when a switchover is initiated.
Using the all-in-one scenario as your starting point reduces the post-installation tasks for enabling switchover to a reasonable number and it keeps the administration of the server cluster as simple as possible.
Main Building Blocks
The main building blocks of PI are the following (see also attached graphics "SAP Process Integration - Main Building Blocks.ppt"):
High Availability
SAP PI inherits the high availability of the dual-stack (ABAP+Java) .
Critical Components
PI Component or Service Number of Configurable Units System-Wide SPOF
ABAP stack: ABAP Enqueue Server ABAP Message Server NFS DBMS Java stack: Java Enqueue Server Java Message Server NFS DBMS |
1 ... n (*) |
X X X X
X X X X |
System Landscape Directory (SLD) | 1 ... m | |
Integration Repository | Running on the Java stack 1 for each ABAP+Java application server instance (*) |
|
Integration Directory | Running on the Java stack 1 for each ABAP+Java application server instance (*) |
|
Integration Server: Central Adapter Engine Integration Engine Business Process Engine |
1 for each ABAP+Java application server instance (*) Running on the Java stack Running on the ABAP stack Running on the ABAP stack |
(*) Critical components for high availability are inherited from the SAP dual-stack (ABAP+Java) system.
(**) J2EE Adapter Engine is available for backward compatibility only and should not be considered in a new SAP NetWeaver system. It is not described in this document.
Adapters
Adapters can play a crucial role in PI. Adapters are required in communication involving systems where PI middleware is not built in. It is important to note, however, that the scope of adapters as critical components is restricted to specific scenarios only. In general, one failing adapter does not affect the entire PI-based landscape, unlike an Integration Server failure.
For example, consider PI-based communication between two legacy SAP systems that are accessed by using the RFC adapter at runtime. In this case, the RFC adapter is a critical component for any mission-critical RFC communication scenario between those two systems. However, IDoc-based communication with the same application systems (using the IDoc adapter) is not affected by the runtime availability of the RFC adapter. A failing RFC adapter, of course, does not affect independent scenarios running across the Integration Server.
Critical Components
PI Adapter Number of Configurable Units System-Wide SPOF
Central Adapter Engine | 1 for each Integration Server | |
Adapter Engine (non-central) | 1 ... m (*) | |
J2EE Adapter Engine | 1 ... n | X |
Integration Server based Adapters (Idoc, plain HTTP) | Running on the ABAP stack 1 for each Integration Server (*) |
|
PI to PI (no Adapters) | Running on the ABAP stack 1 for each Intergartion Server (*) |
(*) High availability is inherited from the dual-stack (ABAP+Java) instances. For more information about critical components.
(**) J2EE Adapter Engine is available for backward compatibility only and should not be considered in a new SAP NetWeaver system. It is not described in this document.
Application Systems
When analyzing the high availability of the entire application landscape, it is helpful to view application systems as independent systems. The result is:
Even if PI is set up in a failure-resilient way with optimized availability, this has no impact whatsoever on how resilient to failures a sender or receiver system is. A mission-critical application scenario needs high availability along the complete communication path.
Application systems can be optimized in their availability by proper configuration and by implementing switchover software (similar to the Integration Server). For non-SAP systems, see the documentation of the specific product. For the case of other SAP usage types see the relevant sections in this document.
Scalability
SAP PI scales with the available SAP PI system instances.
Normal SAP PI message traffic enters the Integration Server using the HTTP protocol. However, if the IDoc adapter is used, message data enters the Integration Server using the standard RFC protocol. Load balancing is also available for the RFC protocol. The Java and the ABAP message server are used as the call dispatcher. RFC load balancing offers two major benefits for the PI system:
With RFC load balancing activated, the sudden failure of one dual-stack (ABAP+Java) application server instance does not affect the accessibility of the PI system by IDocs. RFC load balancing can also be used with the RFC adapter of an Adapter Engine. The adapter then registers several threads at the SAP Gateway of an RFC client system. The client system can then make use of load balancing by means of multiple SAP Gateway registration.
Capabilities
You can find more information about the capabilities provided by SAP NetWeaver Process Integration at http://www.sdn.sap.com/irj/sdn/nw-pi71 .