Skip to Content
Technical Articles
Author's profile photo Mandy Krimmel

Cloud Integration – Configuring Scenario with XI Sender handling Multiple Interfaces

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 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:

 

Assigned Tags

      16 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Anil Veepuri
      Anil Veepuri

      Hi Mandy,

      Is this the only way available to send multiple interfaces from a backend (Eg.ECC) to CPI? This seems to create a lot of dependency on a single iflow and may result in regression for each change in terms of adding a new message type.

      Regards,

      Anil Kumar VEEPURI

      Author's profile photo Mandy Krimmel
      Mandy Krimmel
      Blog Post Author

      You can also create single integration flows for each interface. But then you have to make sure in the sender system that the message is routed to the correct inbound URL.

      BR,

      Mandy

      Author's profile photo Philippe Addor
      Philippe Addor

      Hi,

      Why not creating one Iflow per outbound interface? What’s the disadvantage? Of course, on the backend a configuration has to be made for each interface individually. But that's manageable. 

      Philippe

      Author's profile photo Mandy Krimmel
      Mandy Krimmel
      Blog Post Author

      See above. This is possible as well, you have to make sure in the sender system that the correct inbound URL is called. This is to be configured in the sender systems outbound configuration.

      With this the configuration in Cloud Integration is more separated because different integration flows can be handled independently.

      Best regards,

      Mandy

      Author's profile photo Sanjeeb Sarkar
      Sanjeeb Sarkar

      Hi Mandy,

      Thank you for this blog.

      I have created a similar scenario XI sender to SOAP receiver scenario in CPI.

      In the XI adapter settings the QoS is BestEffort.

      Now when I am sending the payload from Postman to my XI_sender adapter ,

      Inbound processing in endpoint at /SendXIMessage failed with message "Fault:Quality Of Service not set in the message. This is not an XI message"

       

      Can you please let me know why this issue is coming? I have already set the QoS there.

      Author's profile photo Mandy Krimmel
      Mandy Krimmel
      Blog Post Author

      Hello,

      usually an XI sender system offers the qos setting in the xi message header. Please check that you provide all the required XI protocol details via postman, usually this is done by the XI runtime in the sender sysetem.

      BR

      Mandy

      Author's profile photo Sanjeeb Sarkar
      Sanjeeb Sarkar

      Hi Mandy,

      This is what the settings is for QoS , I feel like this is definitly not correct. 🙂

      Can you guide me a here a little bit?

      Author's profile photo Mandy Krimmel
      Mandy Krimmel
      Blog Post Author

      Hello,

      how does the XI message look like that you sent?

      BR

      Mandy

      Author's profile photo Sanjeeb Sarkar
      Sanjeeb Sarkar

      hi Mandy,

      Sorry, I misunderstood,

      Here is the xml payload that I am sending

      <?xml version="1.0"?>
      <soap:Envelope
      xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
      <soap:Header/>
      <soap:Body xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
      <ns0:ImportData
      xmlns:ns0="http://tempuri.org/">
      <ns0:Request>
      <ns1:WayBillGenerationRequest
      xmlns:ns1="http://schemas.datacontract.org/2004/07/SAPI.Entities.Data">
      <ns1:Consignee>
      <ns1:ConsigneeAddress1>House No 5 Handa Enclave, Behi</ns1:ConsigneeAddress1>

      </ns1:Consignee>
      <ns1:Services>

      </ns1:Services>
      <ns1:Shipper>

      </ns1:Shipper>
      </ns1:WayBillGenerationRequest>
      </ns0:Request>
      <ns0:Profile>
      <ns2:Api_type
      xmlns:ns2="http://schemas.datacontract.org/2004/07/SAPI.Entities.Admin">A
      </ns2:Api_type>
      <ns2:Area
      xmlns:ns2="http://schemas.datacontract.org/2004/07/SAPI.Entities.Admin">W
      </ns2:Area>
      <ns2:Customercode
      xmlns:ns2="http://schemas.datacontract.org/2004/07/SAPI.Entities.Admin">0
      </ns2:Customercode>
      <ns2:LicenceKey
      xmlns:ns2="http://schemas.datacontract.org/2004/07/SAPI.Entities.Admin">2
      </ns2:LicenceKey>
      <ns2:LoginID
      xmlns:ns2="http://schemas.datacontract.org/2004/07/SAPI.Entities.Admin">2
      </ns2:LoginID>
      <ns2:Version
      xmlns:ns2="http://schemas.datacontract.org/2004/07/SAPI.Entities.Admin">1.8
      </ns2:Version>
      </ns0:Profile>
      </ns0:ImportData>
      </soap:Body>
      </soap:Envelope>

      Author's profile photo Mandy Krimmel
      Mandy Krimmel
      Blog Post Author

      Hello,

      if you want to send to the XI sender adapter you need to send an XI message, no SOAP message.

      Let me give you an example:

      Sample Message:

      --uuid:d8748c0b-51ee-417d-a043-b243b8759122
      Content-Type: text/xml; charset=UTF-8
      Content-Transfer-Encoding: binary
      Content-ID: <root.message@cxf.apache.org>

      <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:xi="http://sap.com/xi/XI/Message/30" xmlns:xlink="http://www.w3.org/1999/xlink"><xi:Main soap:mustUnderstand="1" versionMajor="3" versionMinor="1"><xi:MessageClass>ApplicationMessage</xi:MessageClass><xi:ProcessingMode>synchronous</xi:ProcessingMode><xi:MessageId>a56b8515-51e5-4310-8c21-a6c6e4aa4678</xi:MessageId><xi:TimeSent>2021-12-10T07:51:19.084Z</xi:TimeSent><xi:Sender><xi:Party agency="http://sap.com/xi/XI" scheme="XIParty"></xi:Party><xi:Service>Sender Communication Component</xi:Service></xi:Sender><xi:Receiver><xi:Party agency="http://sap.com/xi/XI" scheme="XIParty"></xi:Party><xi:Service>Receiver Communication Component</xi:Service></xi:Receiver><xi:Interface namespace="Receiver Interface Namespace">Receiver Interface</xi:Interface></xi:Main><xi:ReliableMessaging ApplicationAckRequested="false" ApplicationErrorAckRequested="false" SystemAckRequested="false" SystemErrorAckRequested="false" soap:mustUnderstand="1"><xi:QualityOfService>BestEffort</xi:QualityOfService></xi:ReliableMessaging></soap:Header><soap:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:xi="http://sap.com/xi/XI/Message/30" xmlns:xlink="http://www.w3.org/1999/xlink"><xi:Manifest><xi:Payload xlink:href="cid:1fb74ea3-d938-44a0-8971-b1bee3531bd0-1@cxf.apache.org"><xi:Name>MainDocument</xi:Name><xi:Description>unspecified document</xi:Description><xi:Type>Application</xi:Type></xi:Payload></xi:Manifest></soap:Body></soap:Envelope>
      --uuid:d8748c0b-51ee-417d-a043-b243b8759122
      Content-Type: text/xml
      Content-Transfer-Encoding: binary
      Content-ID: <1fb74ea3-d938-44a0-8971-b1bee3531bd0-1@cxf.apache.org>

      <n0:BookingOrderRequest xmlns:n0="http://sap.com/xi/XI/Demo/Agency" xmlns:prx="urn:sap.com:proxy:ZJP:/1SAI/TAS08E2B636354DECFC54B6:700:2011/05/10"><AgencyID>00000001</AgencyID><OrderNumber>00000001</OrderNumber><FlightClass>S</FlightClass><FlightID><AirlineID>Str</AirlineID><ConnectionID>0001</ConnectionID><FlightDate>1999-01-24</FlightDate></FlightID><PassengerData><Surname>Str 7</Surname><FirstName>Str 8</FirstName><Birthdate>1999-01-24</Birthdate></PassengerData></n0:BookingOrderRequest>
      --uuid:d8748c0b-51ee-417d-a043-b243b8759122--

      And you need to specify the correct content type header, fot this message it would be:

      multipart/related; type="text/xml"; boundary="uuid:d8748c0b-51ee-417d-a043-b243b8759122"; start="<root.message@cxf.apache.org>"; start-info="text/xml"

      Best regards

      Mandy

       

      Author's profile photo Alisson dos Santos Alves
      Alisson dos Santos Alves
      Hi Mandy,
           My customer only has the CPI, how does the SLD work without having PI / PO?
      Author's profile photo Mandy Krimmel
      Mandy Krimmel
      Blog Post Author

      Hello,

      actually not CPI is dependent on the SLD. The problem is that the XI engine in the backend requires the SLD, not the Cloud Integration tenant. So, you may contact the PI/PO colleagues for their suggestion. You may open a ticket on BC-XI-IS-IEN.

      Best regards,

      Mandy

      Author's profile photo Alisson dos Santos Alves
      Alisson dos Santos Alves

      Thank you for you answer.

      I 'm going to try understand how to use XI Engine with CPI without being a migration.

       

       

       

      Author's profile photo Mandy Krimmel
      Mandy Krimmel
      Blog Post Author

      Hello

      you have to check the respective backend that want to communicate with XI protocol. For this the XI engine in the backend is required and there currently is a requirement for an SLD. And for options without SLD you may open a ticket on BC-XI-IS-IEN.

      Best regards

      Mandy

      Author's profile photo Alisson dos Santos Alves
      Alisson dos Santos Alves

      Hello Mandy!

      I managed to solve this problem.

      I wrote a short blog post about this and i hope to help. Thank you!

       

      https://blogs.sap.com/2022/01/11/cloud-integration-configuring-xi-adapter-in-a-customer-without-sld/

       

      Author's profile photo Mandy Krimmel
      Mandy Krimmel
      Blog Post Author

      Hello,

      just to make it clear, not CPI needs the SLD but the XI engine in the backend. And in your blog you describe how to use the XI engine without SLD by adding this specific table entry.

      Thank you for sharing,

      Mandy