Start of Content Area

Background documentation Configuration Time  Locate the document in its SAP Library structure

At configuration time you configure the cross-system processes for an existing system landscape. The configuration describes how the Integration Server is to process inbound messages and to which receiver or receivers messages must be sent. Various engines are involved in message processing on the Integration Server: The Integration Engine is the central runtime component; the Adapter Engine is the runtime component for adapter communication; the Business Process Engine is the runtime component for the execution of integration processes on the Integration Server. The Integration Server provides the following different services:

      The Adapter Engine and the Integration Engine both have inbound and outbound processing. For example, when a message is received, a check is performed to determine whether the sender is authorized to send to the Integration Server.

      The Integration Engine determines receivers in two steps:

       Logical receivers are determined by logical routing.

       Technical receiver information is defined by technical routing.

Note

In this way, the logical receiver is separated from the technical receiver, which simplifies the exchange of technical addresses (of an application server, for example) without affecting the logically defined superordinate collaborative process.

      Using the configuration, the Integration Engine determines whether a mapping needs to be executed. If a mapping does need to be executed, it determines it and calls the mapping program.

      The Business Process Engine executes optional integration processes. It communicates with the Integration Engine to execute mappings and to send and receive messages.

The following graphic provides an overview of the execution of these services on the Integration Server and shows the information that is required from the Integration Directory:

Note

To keep the graphic simple, only the most important services are shown. The graphic also only shows the logical process flow of message processing. For example, the directory data is not actually read directly from the Integration Directory, but from a cache.

Engine Configuration in the Integration Directory on the Integration Server

This graphic is explained in the accompanying text

Since different customers have different requirements in a process integration scenario, Integration Directory content is not shipped. It is the task of consultants and administrators to configure the data in the Integration Directory at the customer site. During configuration, you reference objects from design time in the ES Repository (Integration Directory services that are required here are underlined):

      Configuration scenarios group configuration objects together in the Integration Builder. You can also reuse the objects that you create for a particular scenario in other configuration scenarios. To generate configuration objects automatically for a scenario, you can use an Process Integration Scenario from the ES Repository as a template.

      To keep configuration open to as many different configuration scenarios as possible and to support reusability, define the type of communication and the communication parties involved in two steps:

       You define the technical options of senders and receivers, as well as how they are identified, in the collaboration profiles. A profile comprises the following information:

       In the B2B environment, senders or receivers are usually identified by numbers (for example, by using a DUNS number or an EAN number). In the Integration Directory, specify all the ways to identify a sender or receiver by using the Collaboration Party object. This means that later on in the configuration, you do not need to work with various different identifiers. Instead, you simply use the communication party you have created, since it contains all the ways of identifying a sender or receiver. This procedure is known as sender or receiver normalization.

       To describe on a logical level which address types communicate with each other, use communication components. A communication component could be a business system or an integration process, for example. You can assign multiple communication components to a communication party or can configure one communication component without a specific communication party.

       The service does not yet specify any technical details regarding the message exchange. Depending on the type of service, you reference interfaces and one or more communication channels. The latter defines how you can address a communication party technically, for example, which adapters are required.

This means that you can call all technical options and ‘public’ sender and receiver interfaces in a collaboration profile.

       In collaboration agreements, you define the options described in the collaboration profile that are to be valid at runtime for a selection of senders and receivers. For this purpose you select, for instance, for technical routing the communication channel, which is to be active for a group of interfaces (for example, a channel that is intended for all IDoc messages). Collaboration agreements control inbound and outbound processing.

      Logical routing works with communication components and is determined by using routing rules:

       Receiver determinations determine the communication component to which the message is to be sent. You can also define conditions that must be fulfilled for the message to be forwarded.

       An interface determination that you use to assign a sender interface to a receiver interface.

      The interface determination determines which sender interface belongs to which receiver interface. If a mapping is to be executed for this interface pair, you can select it from the ES Repository and assign it to the interface determination. You load the actual mapping program from the Integration Repository before runtime and save it on the Integration Server.

Together, the collaboration agreements and the receiver and interface determinations determine the receiver of a message, and whether a mapping needs to be executed.

Communication Parties and the System Landscape Directory

The System Landscape Directory (SLD) describes a system landscape. A system landscape comprises the following different types of system:

      Business systems, which name the logical receiver independently of technical properties. For example, a business system might be a client of an SAP system.

      Technical systems with which the hardware of the system is specified in more detail (server data, and so on).

Before a customer who uses SAP NetWeaver PI can begin configuration, they must first enter all the business systems and assigned technical systems in the SLD. Since the SLD just refers to the system customer’s system landscape, they do not need to enter any business partner systems in the SLD in a cross-company scenario.

The following table provides an overview of how you can use the communication party, service, and communication channel objects in the Integration Builder during configuration to identify the sender and receiver, and describe their technical possibilities.

Collaboration Profile Objects and Their Use

Object Type

Use

SLD Entry

Communication Party

Identifies a company entity, which can later be configured as a sender or receiver. B2B communication builds on the identifiers specified here. The communication party is optional.

no

Communication Component of Type
Business Service

Communication component for cross-company message exchange. You can specify interfaces and communication channels for business services independently of a system.

no

Communication Component of Type
Integration Process Service

Communication component for exchanging messages with an integration process

no

Communication Component of Type
Business System Service

Communication component for exchanging messages with a business system. The business system, the corresponding technical system, and the assignment between the two must be entered in the SLD.

yes

Communication Channel

Defines the runtime component used to send and receive messages. The adapter type XI stands for proxy communication using the Integration Engine. All other adapter types stand for adapter communication using the Adapter Engine.

no

 

 

 

 

End of Content Area