- SAP Managed Tags:
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.
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.
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 allow the respective headers.
To allow 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 allow 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 allow 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 allow 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 allow the headers that are really required.
Now I can use the headers to configure my routing to different receivers.
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 new receiver. I simply use an SFTP adapter and store the message in a different directory.
Now I can deploy the integration flow. Afterwards, I check if the integration flow was started successfully in the Manage Integration Content monitor.
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.
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 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:
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:
Second parameter:
With this, the system can send XI proxy calls for the interfaces FlightBookingOrderConfirmation_Out and XiPatternInterface2_Out to the Cloud Integration tenant.
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.
To check the processing in Cloud Integration in detail, you can use the monitoring tools provided by Cloud Integration.
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:
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:
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 allow the respective headers.
Allow the Required Headers
To allow 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 allow 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 allow 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 allow 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 allow 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:
34 Comments
