Technical Communication
The following types of technical communication are described:
● Communication with the technical configuration tools
● Communication with and between the integration tools
● Communication with and between the monitoring tools
The two technical configuration tools for maintaining the basic data of a process integration (PI) landscape are the exchange profile and the System Landscape Directory (SLD). Both tools must operate correctly to ensure a properly functioning PI landscape. All other tools communicate with these tools to obtain the technical configuration data of a given PI landscape.
● The exchange profile maintains the technical users, connection data, and configuration data of most PI components. Whenever a PI component communicates with another PI component, the exchange profile is accessed to obtain communication data.
● The SLD maintains a PI system landscape on a more abstract level. Nevertheless, it is also accessed by many other PI components.
The exchange profile contains the most fundamental technical configuration data of a PI landscape stored in an ABAP database table on the Integration Server. Each Java-based component of a PI landscape has an exchange profile access client installed, where JCo RFC connection data for the central exchange profile is maintained. The connection data for the exchange profile is stored in the secure storage of the component. The user specified in the connection data should have the ABAP user role SAP_BC_AI_LANDSCAPE_DB_RFC on the Integration Server.
This JCo RFC connection is used by the PI components to read configuration data of the central exchange profile. This means that a kind of bootstrapping mechanism is used for accessing other PI components, because the connection data to the other components is read from the central exchange profile first.

The read access to the exchange profile is shared by all PI components installed on the same Application Server Java.
The exchange profile access client module is also used for interactive maintenance of the exchange profile. Therefore, write access is also included in the role SAP_BC_AI_LANDSCAPE_DB_RFC.
Components and Their Communication with the Exchange Profile
Component |
Communication with Exchange Profile on Integration Server (Read Access Only) |
SLD |
No access |
Java components (Enterprise Services Repository, Integration Directory, central Advanced Adapter Engine, non-central Advanced Adapter Engines, Java Proxy Runtime, Runtime Workbench) |
JCo RFC connection You configure access data for the JCo RFC connection in the exchange profile JSP Connect in the local AS Java. The purpose is to obtain access data (user, password, technical connection data) for other PI components. |
Adapter Engine (Java SE) |
No access, because the connection data is kept locally. |
ABAP proxy generation Integration Server |
RFC type T destination LCRSAPRFC For the ABAP proxy generation, the purpose is to obtain access data for the Enterprise Services Repository. For the Integration Server, the purpose is to obtain parameters for the mapping runtime and for the Integration Server runtime. |
ABAP proxy runtime |
No direct access |
CMS |
No access |
TREX |
No access |
The general mechanism for a PI component A that communicates with a PI component B by applying the exchange profile data works as follows: Component A uses the following exchange profile parameters to log on to component B:
● com.sap.aii.connect.<component B>.* as connection data
● com.sap.aii.<component_A>.serviceuser.* as the user
Therefore, the calling component A identifies itself with its technical user when calling component B.

More information:
Exchange
Profile Parameters
The SLD contains both configuration data of a PI landscape and information about the software components installed. Both PI tools and messaging components need to read certain information from the SLD and, in addition, support a self-registration feature, which PI components use to introduce themselves to the SLD.
Components and Their Communication with the SLD
Component |
Communication with the SLD (Read and Write Access) |
Exchange profile |
No access |
Java components (Enterprise Services Repository, Integration Directory, central Advanced Adapter Engine, non-central Advanced Adapter Engines, Java Proxy Runtime, Runtime Workbench) |
HTTP connection You configure access data for the HTTP connection in the exchange profile. The purpose is to obtain various system data from the SLD as well as a self-registration in the SLD (write access). |
Adapter Engine (Java SE) |
Self-registration in the SLD (write access). |
ABAP proxy generation |
No access |
Integration Server ABAP proxy runtime |
RFC type T destination SAPSLDAPI to the SLD Bridge on the AS Java. HTTP connection from the SLD Bridge to the SLD. Access data for the SLD is maintained with transaction SLDAPICUST. For the Integration Server, the purpose is to obtain access data for (Advanced) Adapter Engines and other Integration Servers. For the ABAP proxy runtime, the purpose is to obtain data of its own business system and of the Integration Server. |
TREX |
No access |

Each AS Java has an SLD data supplier configuration, which informs the SLD about the technical settings of the respective AS Java. This function is not PI-specific, but it must be activated to ensure the correct technical system data in the SLD.
The integration tools are the Enterprise Services Repository, the Integration Directory, and the proxy generation tools. These tools enable applications to use PI services in the Integration Server.
You can use the Enterprise Services Repository to define application interfaces and mappings between such interfaces. It is used at design time when the application interfaces are defined.
You can use an interface defined in the Enterprise Services Repository to generate proxies directly in ABAP application systems. The interface data must be read from the Enterprise Services Repository.
Java proxies are generated in the SAP NetWeaver Developer Studio or locally (as .jar files) in the Enterprise Services Repository. They are used to develop Java applications that send or receive XI messages.
In the Integration Directory, the actual PI services of an Integration Server are defined. These are the routing of messages and the mapping of message contents.
The Enterprise Services Repository, the Integration Directory, and the ABAP proxy generation need to communicate for the exchange of data.

When the configurator of an interface determination wants to use the input help, the Integration Directory requires a list of all existing interfaces in the Enterprise Services Repository.
The communication is always executed by the bootstrapping mechanism described above and always uses HTTP connections. First, the exchange profile is read to obtain the connection data for the corresponding tool. For this purpose, the connection data for the target system is read, whereas to log on to the target system, the user of the source tool is read.
The central messaging components (Integration Server and Advanced Adapter Engines) have to react according to the actual configuration in the Integration Directory and Enterprise Services Repository, whenever changes are activated by these tools. For this purpose, the messaging components use a runtime cache, in which the actual configuration data is present. A cache refresh mechanism is used that updates the runtime cache according to the changes made in the Integration Directory and Enterprise Services Repository.
There are several variants of the cache refresh mechanism depending on the scope of the cache refresh (delta only or entire cache refresh) and on the triggering component (tool or messaging component). The bootstrapping mechanism described above is always used for the communication. There is one exception, however, if a direct HTTP connection is established from the Integration Server to the Integration Directory by using the SM59 type H destination INTEGRATION_DIRECTORY_HMI.
Following the conventions above, the user defining the Integration Server should be used as the logon user that is maintained in the exchange profile parameters com.sap.aii.integrationserver.serviceuser.*.
The central component for monitoring a PI landscape is the Runtime Workbench (RWB). It relies on various standard SAP monitoring tools such as the Computing Center Management System (CCMS), the Process Monitoring Infrastructure (PMI), and the Alert Framework. PI assumes that these standard monitoring services reside on one central monitoring server. This monitoring server may be the Integration Server, or it may be a dedicated server for monitoring functions. The RWB and the standard monitoring function require HTTP(S) and RFC(SNC) communication for monitoring functions such as:
● Heartbeat (ping) and self-test of components
● Message monitoring of selected PI components
● Message monitoring across a PI landscape (end-to-end monitoring)
● Performance monitoring
● Alerting
To collect monitoring data and to navigate across different monitoring UIs, the RWB needs to communicate with other PI components, with the SLD, and with the SAP base monitoring infrastructure.
The table below describes purposes as well as protocols of communications required for monitoring. It also lists the originator of a communication (client) and the responding component (server).
Communication Required for Monitoring Purposes
Client |
Server |
Purpose of Request |
Protocol |
RWB |
Advanced Adapter Engines Integration Directory Enterprise Services Repository SLD RWB |
Ping, self-test |
HTTP(S) |
RWB |
Integration Server |
Ping, self-test, reading of performance data |
RFC |
RWB |
Central monitoring server |
UI navigation |
HTTP(S) |
RWB |
Advanced Adapter Engines |
UI navigation |
HTTP(S) |
RWB |
Central monitoring server |
Configuring CCMS, PMI, Alert Framework |
RFC |
RWB |
SLD |
Reading the PI landscape |
HTTP(S) |
RWB |
TREX |
Message search |
HTTP(S) |
Central monitoring server: CCMS |
Advanced Adapter Engines Integration Directory Enterprise Services Repository SLD RWB |
Heartbeat (ping) |
HTTP |
Central monitoring server: PMI |
Advanced Adapter Engines Integration Server Proxy runtimes |
Collecting PMI records |
HTTP, RFC |
Integration Engine |
TREX |
Message indexing |
RFC |
Advanced Adapter Engine |
TREX |
Message indexing |
HTTP(S) |