Skip to Content

This blog describes how to configure a scenario where an XI sender adapter consumes messages for multiple interfaces and the routes them to different branches in the integration flow. This configuration option uses the headers set by the XI sender adapter.

Configuring Scenario with XI Sender Receiving Messages for Multiple Interfaces

The blog Configuring Scenario Using the XI Sender Adapter describes how to use the XI sender adapter in an EO scenario that receives messages from a sender backend using XI protocol. In general, the XI sender can receive all kind of XI messages for multiple interfaces and for multiple sender business systems and parties. Often there is a requirement to process messages for different interfaces or business systems differently. This can easily be achieved by using the headers the XI sender adapter sets for all these attributes received.

In this blog I describe how to extend the scenario described in the blog Configuring Scenario Using the XI Sender Adapter with the option to route the received messages to different branches depending on the interface. The straight forward integration flow configured in the linked blog looks like this:

We will extend it with a routing of the messages to different receiver systems based on the interface.

Configure the Integration Flow Receiving the XI Messages

Open the integration flow configured in the blog Configuring Scenario Using the XI Sender Adapter and change to edit mode. To make the integration flow aware of the headers the XI sender sets, we first need to whitelist the respective headers.

Whitelist the Required Headers

To whitelist the headers that you want to use for the routing configuration, you first need to know which headers are set by the XI sender adapter. This is documented in the following help chapter: Headers and Exchange Properties Provided by the Integration Framework. Here’s a short list for your reference:

SapInterfaceName
SapInterfaceNamespace
SapReceiverParty
SapReceiverService
SapSenderParty
SapSenderService

To whitelist them in your integration flow, open the Runtime Configuration tab for the integration flow and enter the headers you want to use in the integration flow in the field Allowed Header(s). The other headers are not passed to the integration flow and cannot be used.

For my scenario I only whitelist the headers SapInterfaceName and SapInterfaceNamespace because I want to configure a routing based on the interface. The single headers have to be separated by ‘|’.

Note that you can also set * in this field to whitelist all headers received from the sender system or set by the adapter, but this is not the recommended configuration option. For security reasons you should only whitelist the headers that are really required.

Now I can use the headers to configure my routing to different receivers.

Add Router to Different Receivers Based on the Interface

To configure the routing to different receivers, I add a Router step after the Start step and a second End event with an additional Receiver. To end messages for all other interfaces, I additionally add an Escalation End event and connect the router to the two new end events:

Route to First Receiver

I configure the route to the first receiver for the interface FlightBookingOrderConfirmation_Out and the namespace http://sap.com/xi/XI/Demo/Airline. For this, I define a Non-XML expression based on the two headers: ${header.SapInterfaceName} = ‘FlightBookingOrderConfirmation_Out’ and ${header.SapInterfaceNamespace} = ‘http://sap.com/xi/XI/Demo/Airline’

With this configuration, all messages received with the interface FlightBookingOrderConfirmation_Out are routed to Receiver1.

Route to Second Receiver

I configure the route to the second receiver for the interface XiPatternInterface2_Out and the namespace http://sap.com/xi/XI/System/Patterns. For this, I define a Non-XML expression based on the two headers: ${header.SapInterfaceName} = ‘XiPatternInterface2_Out’ and ${header.SapInterfaceNamespace} = ‘http://sap.com/xi/XI/System/Patterns’

With this configuration, all messages received with the interface XiPatternInterface2_Out are routed to Receiver2.

Route to Escalation End Event

To end messages for all other interfaces, I define the route to the Escalation End event as Default Route:

With this configuration, all messages received with an interface other than FlightBookingOrderConfirmation_Out  or XiPatternInterface2_Out are not processed by the integration flow.

Configure the Second Receiver

Configure the new receiver. I simply use an SFTP adapter and store the message in a different directory.

Deploy the Integration Flow

Now I can deploy the integration flow. Afterwards, I check if the integration flow was started successfully in the Manage Integration Content monitor.

Configure the Sender System to Send the XI Messages to Cloud Integration

As described in the blog Configuring Scenario Using the XI Sender Adapter, you need to configure the sender system to send XI messages to the Cloud Integration tenant.

Configure Integration Engine, SLD, and RFC Destination

Make sure you configure the Local Integration Engine, the SLD, and the RFC destination as described in the blog Configuring Scenario Using the XI Sender Adapter.

Define Sender/Receiver Definition

Define the Sender/Receiver Definition as described in the blog Configuring Scenario Using the XI Sender Adapter for two different interfaces, to be able to send different interfaces to the XI sender adapter. I use the following two interfaces for my scenario:

  • Interface FlightBookingOrderConfirmation_Out from namespace http://sap.com/xi/XI/Demo/Airline as Request
  • Interface XiPatternInterface2_Out from namespace http://sap.com/xi/XI/System/Patterns

Activate Interface-Specific Endpoint

Use transaction SXMB_ADM -> Integration Engine Configuration –> Specific Configuration to define two new parameters with the following settings as described in the blog Configuring Scenario Using the XI Sender Adapter for the two different interfaces:

First parameter:

  • Category: RUNTIME
  • Parameters: IS_URL
  • Subparameters: Select the Sender/Receiver ID defined in the last step for interface FlightBookingOrderConfirmation_Out
  • Current Value: dest://<name of the RFC destination you defined in SM59>

Second parameter:

  • Category: RUNTIME
  • Parameters: IS_URL
  • Subparameters: Select the Sender/Receiver ID defined in the last step for the second interface XiPatternInterface2_Out
  • Current Value: dest://<name of the RFC destination you defined in SM59>

With this, the system can send XI proxy calls for the interfaces FlightBookingOrderConfirmation_Out and XiPatternInterface2_Out to the Cloud Integration tenant.

Test the Scenario

The easiest way to test the scenario is to use transaction SPROXY to trigger the sending of XI messages for the different interfaces.

In the menu, choose Proxy -> Test. In the Test Service Consumer dialog leave the settings as they are and choose Execute:

A screen with a sample test message opens. Choose Execute and then Extras -> Trigger Commit Work. The request is sent to the Cloud Integration tenant. You can now monitor the processing as described in the next section.

Using this process, send XI messages for the two different interfaces.

Check in transaction SXMB_MONI that the message was sent successfully. Also, check in Cloud Integration monitoring that the two messages were processed. More details about monitoring in Cloud Integration can be found below in the Monitoring section.

Monitoring

To check the processing in Cloud Integration in detail, you can use the monitoring tools provided by Cloud Integration.

Message Monitoring

Message processing can be checked in detail in the section Monitor Message Processing. Select the message you sent and check the processing status.

If you send messages for the interfaces FlightBookingOrderConfirmation_Out and XiPatternInterface2_Out, the messages should be processed and sent to the different directories on the SFTP server.

If you send a message for a different interface, the message gets an Escalated status and is not processed to the SFTP adapter:

Trace the Message Processing

In addition to the message monitoring, you can trace the message processing to see the route the message took. Activate Log Level ‘Debug’ or Trace’ in the Integration Content monitor. After activating the log level, send a message and check the trace in the Message Monitor using the Debug or Trace link for the message.

In the Trace view you see which route was taken. For example, if a message for interface XiPatternInterface2_Out was sent, Route 2 is executed:

If a message is sent for an interface that is not configured, the process is executed to the Escalated End event:

 

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply