Technical Communication

The following types of technical communication are described:

?     Communication with the technical configuration tools

?     Communication with and between the Integration Builder tools

?     Communication with and between the monitoring tools

Communication with the Technical Configuration 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 usually accessed to obtain communication data.

?     The SLD maintains a PI system landscape on a more abstract level. Nevertheless, it is also often accessed by many other PI components.

Exchange Profile

The exchange profile contains the most fundamental technical configuration data of a PI landscape (see Exchange Profile Parameters) stored in an ABAP database table on the Integration Server. Each J2EE-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 J2EE secure store 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 are read from the central exchange profile first.

The read access to the exchange profile is shared by all PI components installed on the same SAP NetWeaver 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

(Integration Repository, Integration Directory, central Adapter Engine, non-central Adapter Engines, Java Proxy Runtime, Runtime Workbench)

JCo RFC connection

Access data for the JCo RFC connection is configured in the exchange profile JSP Connect in the local J2EE engine.

The purpose is to obtain access data (user, password, technical connection data) for other PI components.

Plain J2SE Adapter Engine

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 Integration 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.

System Landscape Directory

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

(Integration Repository, Integration Directory, central Adapter Engine, non-central Adapter Engines, Java Proxy Runtime, Runtime Workbench)

HTTP connection

Access data for the HTTP connection is configured 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).

Plain J2SE Adapter Engine

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 J2EE server.

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 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 J2EE engine has an SLD Data Supplier service, which informs the SLD about the technical settings of the respective J2EE engine. This service is not XI-specific, but it must be activated to ensure the correct technical system data in the SLD.

Communication with and between the Integration Builder Tools

The Integration Builder tools are the Integration 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 Integration 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 Integration Repository to generate proxies directly in ABAP application systems. The interface data must be read from the Integration Repository.

Java proxies are generated locally in the Integration Repository as .jar files that can be further used to develop J2EE 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.

Internal Tool Communication

The Integration 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 Integration 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.

Cache Refresh of Messaging Components

The central messaging components (Integration Server and Adapter Engines) have to react according to the actual configuration in the Integration Directory and Integration 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, and a cache refresh mechanism that updates the runtime cache according to the changes made in the Integration Directory and Integration 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.*.

Communication for Monitoring

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

Adapter Engines

Integration Directory

Integration 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

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

Adapter Engines

Integration Directory

Integration Repository

SLD

RWB

Heartbeat (ping)

HTTP

Central monitoring server: PMI

Adapter Engines

Integration Server

Proxy runtimes

Collecting PMI records

HTTP, RFC

Integration Engine

TREX

Message indexing

RFC

Adapter Engine

TREX

Message indexing

HTTP(S)