Show TOC

Background documentationConfiguration Time Locate this document in the navigation structure

 

At configuration time, an integration expert (for example, an integration consultant) configures the integration scenario specified at design time for a specific system landscape to enable the scenario to run in this system landscape.

The first configuration task is to identify the “players” of the game at runtime – the systems that actually communicate with each other – and relate them to the corresponding process components.

Note Note

At configuration time, the interaction of “abstract” application components is typically broken down into system-to-system interactions.

End of the note.

Based on this assignment, an integration expert specifies further details on how the messages are to be exchanged between the systems:

  • How the messages are routed by the runtime engine from a sender system to one or multiple receiver systems

  • How the individual systems (each may be based on different technical characteristics) can be connected to the runtime engine (connectivity and adapters)

  • Which security-relevant settings apply to the data exchange (for example, if messages are secured using digital signatures)

Configuration Settings in the Integration Directory

The relevant configuration settings in Integration Directory are structured in the following way:

  • Collaboration Profile

    Defines those entities that interact with each other based on the exchange of XML messages.

    These are typically systems or applications and are represented at configuration time by communication components. In addition to that, you define the communication capabilities of the components. These are represented by communication channels.

    Optionally, you can also define communication parties as additional entities, typically suitable in business-to-business scenarios.

  • Configuration of Message Exchange

    Specifies how messages are exchanged between communication components.

    At configuration time individual system-to-system interactions are specified. As a configuration expert has to provide all the information necessary for the runtime engine to handle the exchange of messages, it is most natural to “take up” the position of the runtime engine. This means, for each incoming message (which arrives at the runtime engine), the configuration expert has to determine what should happen with this message - for example, which receiver systems it is to be sent to, or how it is to be mapped.

Configuration of Message Exchange

The following figure illustrates what happens with an incoming message:

This graphic is explained in the accompanying text.

Processing of an Incoming Message

For an incoming message the following aspects have to be specified:

  • Inbound processing

    Defines how the incoming message is to be transformed technically to the XML message format that the runtime engine (“PI runtime”) understands.

    Inbound processing might also include additional security-relevant aspects, for example, how to handle the signature of the incoming message, or how to decrypt the incoming message, if these special security standards have been applied by the sender of the message.

  • Routing

    Defines which receivers the incoming message is to be forwarded to.

    Note Note

    The figure indicates the fact that in general multiple receivers can be configured for an incoming message.

    End of the note.

    The configuration of routing may also include routing conditions.

  • Mapping

    Defines how the business data of the message is to be transformed with regard to a particular receiver (in contrast to the technical XML message format that is handled during inbound processing).

    For an incoming message sent to a particular receiver you select a predefined mapping from the ES Repository.

  • Outbound processing

    Defines how a message should be transformed technically with regard to a specific receiver. Outbound processing again implies a technical transformation step: A transformation from the XML message format that the runtime engine “speaks” to the protocol or standard that the receiver system can handle.

    Outbound processing may also cover additional security-relevant aspects, for example, how to sign or encrypt an outgoing message in case these security standards are agreed on with the receiver.

Note Note

Use of the Terms Outbound and Inbound

When used in the context of design time objects, the terms outbound/inbound refer to the “perspective” of the application component. When used in the context of configuration time objects, the terms outbound/inbound refer to the “perspective” of the runtime engine.

For example: An outbound service interface (a design time entity) is a service interface whereby a message is sent out from the application (where the interface is implemented) to another application. In mediated scenarios, such a message is sent first to the runtime engine of SAP NetWeaver PI (interconnected between the two applications) and then sent from there to the other application. Therefore, a message sent by an outbound interface is the incoming (or inbound) message as seen from the perspective of the runtime engine. In other words: The incoming message (as used in the configuration time context) is then determined by an outbound interface implemented on a sender system.

End of the note.

The procedure and the relevant configuration objects needed to configure the message exchange depend on the chosen installation and connectivity option.

Configuration data maintained in Integration Directory is made available to the involved runtime engines by a cache refresh mechanism.

Based on these configuration settings, the message is processed at runtime by the involved runtime engines.

More Information