Show TOC

Configuration TimeLocate this document in the navigation structure

Use

Relationship Between Design Time and Configuration Time Entities

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 following figure illustrates the relationship between the entities defined at design time (above, the communication of two process components) and those relevant at configuration time (below, for an exemplary system landscape). The different colors of the systems indicate the different technical characteristics the systems may be based on:

Figure 1: Relationship of Design Time and Configuration Time Entities

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

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

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.

    More information: Collaboration Profile

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

    The figure above illustrates this by highlighting the possible communication paths for a message sent from system 1a to the runtime engine (in an interaction between process component 1 and process component 2).

Configuration of Message Exchange (in Detail)

The following figure illustrates in more detail what happens with an incoming message:

Figure 2: Phases of Message Processing

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.

    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

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 (or process 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.

The procedure and the relevant configuration objects needed to configure the message exchange depend on the chosen installation and connectivity option (that are summarized under Installation and Connectivity Options ).

More information:

Configuring Direct Communication

You can also configure direct communication between systems or applications without any runtime engine being involved. More information: Configuration Objects (Direct Communication)

Configuring Object Keys

Configuration objects are identified uniquely in the Integration Directory using object keys.

More information: Object Key in Configuration Objects

Transporting Integration Directory Objects

You can transport Integration Directory objects.

More information: Transporting Objects using CTS