Show TOC

Setting up Scenarios Using Dual-Stack Message ProcessingLocate this document in the navigation structure

Use

When use an SAP NetWeaver PI dual-stack installation, you use an Integration Server as host for your runtime engines (Integration Engine and central Advanced Adapter Engine).

Note

The Integration Server also includes the Business Process Engine for scenarios including cross-component Business Process Management.

Depending on the adapter used at runtime, the communication might include the central Advanced Adapter Engine or only the Integration Engine.

More information: Connectivity Options Using SAP NetWeaver PI (under Integration Engine-Based Message Processing )

The following procedure applies for scenarios where message processing is performed by using both the Integration Engine (based on AS ABAP) and the Advanced Adapter Engine (based on AS Java).

Procedure

1. Design Integration Content

You define the software components for your development project in the System Landscape Directory (SLD). You design your integration content in the ES Repository.

In this section, we describe the general procedure when you follow the top-down design approach, which means that you start with a process model and based on the model specify all other integration content.

More information about the basic concepts: Design Time

Note

There is the option either to design the integration yourself from scratch or to use integration details already designed and delivered by SAP where you can modify this content according to your needs.

Both of these approaches normally come into play in real-life projects. A typical scenario would, for example, be that you use predefined content (and enhance it) to outline one part of the integration scenario, whereas another part has to be built completely from scratch. For the specific aspects that you have to consider when using predefined content shipped by SAP, see Using Predefined Integration Content .

  1. Define the software components you need for your developments.

    Note

    You need these entities in order to organize the ESR content (interfaces, mappings, for example) you define with the following steps.

    More information: Organizing and Managing Content in ESR

  2. Log in to the ES Repository and choose the usage profile Process Integration (SAP BASIS 7.30).

    More information: Usage Profile

  3. Define a process model.

    There are different modeling approaches available in the ES Repository. Decide to use either of the following approaches and follow the procedures described in one of the following sections:

    For an overview of the model types, see: Process Models .

  4. Define the necessary interface objects.

    Designing interface objects implies the following sub tasks:

    • Designing data types

    • Designing message types

    • Designing service interfaces and their operations

    There are other interface object types for special use cases, for example, context objects. For more information about the concepts behind these objects, see Interface Objects in the ES Repository .

    More information about the development procedure: Defining Interface Objects

  5. Define the necessary mapping objects.

    More information: Defining Mappings

  6. Activate your ESR objects.

2. Configure Integration Content

At configuration time you specify how messages have to be exchanged between the individual systems or applications of the existing system landscape - in accordance with the process model and additional integration content specified at design time.

More information about the basic concepts: Configuration Time

Key tools for this phase are the System Landscape Directory and the Integration Directory.

Recommendation

We recommend that you use a process model from the ES Repository as configuration template. Doing this, you can configure inbound processing, routing, mapping and outbound processing semi-automatically.

More information: Configuring Process Models

Defining Collaboration Profile

This task involves the definition of communication components, communication channels and (optional) communication parties.

More information: Defining Collaboration Profile

Configuring Inbound Message Processing

To specify the inbound processing, you define which (sender) communication channel (or sender adapter) is to be used to transform the incoming message into the message format that can be processes by the PI runtime. You do this by defining a sender agreement. In a sender agreement, you also can define security settings. Which security settings are supported, depends on the chosen adapter type.

To create a sender agreement, you first have to specify the following object key attributes: The sender component (to identify where the message comes from) and the outbound interface (to identify which message the sender agreement applies to).

More information: Defining Sender Agreements

Note

Sender agreements are not mandatory in all cases. You only have to define sender agreements when using special sender adapters that are configured explicitly at the inbound channel of the Integration Server (for example, sender File/FTP adapters). You also have to define a sender agreement when you want to apply specific security settings for the processing of the incoming message.

Note

You can make it easier for a business partner (sender) to call the Integration Server by publishing the sender agreement in the Services Registry. The business partner can then access the sender agreement in the form of a WSDL file in the Services Registry, before the firewall. The WSDL description contains all the relevant configuration data from the sender agreement as well as the assigned communication channel, which are required to call the Integration Server.

More information: Publishing Sender Agreements in the Services Registry

Configuring Routing and Mapping

The routing configuration is made up of the definition of receiver determinations and interface determinations. In receiver determinations you specify the receiver components of the message. In interface determinations you specify the receiver interfaces and mappings.

  1. Define the required receiver determinations.

    For each incoming message of a specific sender system (which is the key of the receiver determination), you define a receiver determination.

    More information: Defining Receiver Determinations

    Note

    When configuring a receiver determination, you also have the option to specify behavior at runtime if a receiver is not found. When you choose the option that the message processing is terminated with an error, you can correct the configuration and restart the message processing. More information: Displaying XML Message Versions

  2. Define the necessary interface determinations.

    You define an interface determination for a sender, an incoming message, and a specific receiver system.

    More information: Defining an Interface Determination

Configuring Outbound Message Processing

To specify the outbound processing, you define which (receiver) communication channel (or receiver adapter) is to be used for an outgoing message (targeted at a specific inbound interface of a specific receiver system). You do this by defining a receiver agreement. In a receiver agreement, you also can define security settings (depending on the chosen adapter type). When creating a receiver agreement, you have to specify a receiver component, a receiver (inbound) interface, and a sender component.

More information: Defining Receiver Agreements

Activating Configuration Objects

Activate the configuration objects so that your configuration settings become runtime-relevant.

More information: Change Lists