Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
mandy_krimmel
Product and Topic Expert
Product and Topic Expert
8,126
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:

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
former_member189418
Participant
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
philippeaddor
Active Participant
0 Kudos

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

mandy_krimmel
Product and Topic Expert
Product and Topic Expert
0 Kudos
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
mandy_krimmel
Product and Topic Expert
Product and Topic Expert
0 Kudos
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
0 Kudos
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.
mandy_krimmel
Product and Topic Expert
Product and Topic Expert
0 Kudos
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
0 Kudos
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?
mandy_krimmel
Product and Topic Expert
Product and Topic Expert
0 Kudos
Hello,

how does the XI message look like that you sent?

BR

Mandy
0 Kudos
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>

mandy_krimmel
Product and Topic Expert
Product and Topic Expert
0 Kudos
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

 
Hi Mandy,


     My customer only has the CPI, how does the SLD work without having PI / PO?

mandy_krimmel
Product and Topic Expert
Product and Topic Expert
0 Kudos
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
0 Kudos
Thank you for you answer.

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

 

 

 
mandy_krimmel
Product and Topic Expert
Product and Topic Expert
0 Kudos
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
0 Kudos
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/

 
mandy_krimmel
Product and Topic Expert
Product and Topic Expert
0 Kudos
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
VijayKonam
Active Contributor
0 Kudos
Making use of a Value Mapping Table available in CPI is a good alternative to define the router for each interface. You could maintain Sender Bus Sys, Sender Namespace and Sender Interface Name to lookup with constants receiver, receiver_url and fetch receiver URL (process direct adapter). Makes it simple.
mandy_krimmel
Product and Topic Expert
Product and Topic Expert
thank you for this suggestion!
das_sappo
Participant
0 Kudos

HI Mandy,

We are working on XI to HTTP synchronous scenario and not able to pass the Status (Success or Failure) back to SAP though the flow is successful in CPI. and the response is failing at SAP proxy with attached error. Please suggest how to resolve it.

XI Data

 

mandy_krimmel
Product and Topic Expert
Product and Topic Expert
0 Kudos
Hello,

this sounds like some part of the XI message got lost during processing. I would suggest to open a ticket on LOD-HCI-PI-CON-SOAP. The experts need to check this in detail.

Please attach the integration flow and the message processing logs. If the error is reproducible it would also be helpful  to trace the processing and provide the response payload in CPI that is send back.

Best regards

Mandy
sjaachi4567
Explorer
0 Kudos
Hi Mandy ,

I am also facing the same issue while triggering the message from SAP to CPI via sender proxy , failed with message "Fault:Quality Of Service not set in the message. This is not an XI message"

please suggest me to fix on this issue.

 

Regards,

Venkat
mandy_krimmel
Product and Topic Expert
Product and Topic Expert
0 Kudos
Hi,

I would suggest that you check that your message is really sent out via the integration engine from the sender system. Check in SXMB_MONI for the sent message and check on the status there.

Best regards

Mandy
sjaachi4567
Explorer
0 Kudos
Hi Mandy,

Thank you for your quick response.

I observed that messages are coming under srt_util but not sxmb_moni.

in SAP , failed with this error "payload consumption is not been announced (see note 11182825) " but in CPI we received the message and failed with this error "quality of service not set in the message, this is not an xi message".

we configured proxy structure in sproxy and abap code also done. soamanager configuration also completed and there given cpi endpoint , user credentials and created logical port and set to default port.

could you please suggest me to fix on this issue.

 

Thanks in advance.

Regards,

Venkat

 
mandy_krimmel
Product and Topic Expert
Product and Topic Expert
0 Kudos
Hello Venkat

This sounds as the message is not sent via the XI runtime, but via web service runtime. It is sent via the WS runtime and so comes as SOAP message to CPI.

You need to check the transaction SOAMANAGER and maybe consult your PI administrator on how to correctly configure the XI engine in the sender system.

Best regards

Mandy

 
ximadhu
Explorer
0 Kudos
Hi Mandy,

I have a requirement to migrate 100+ XI Proxy interfaces from SAP PI to SAP CPI. In this case if I create 100 iflows with 100 different endpoint URL's , I become clueless how to configure the same in-source SAP ECC system, Do we need to create 100 RFC destinations containing these endpoints ?

In case if I create a common XI sender It is difficult to handle the 100 + interfaces and routing to receivers based on interface names.

Could you suggest how to handle this?

BR,

Madhu sudhan
mandy_krimmel
Product and Topic Expert
Product and Topic Expert
Hello,

in general, there are the two options: a common XI sender adapter with routing based on interface names or separate flows with separate RFC destinations. Or something in between, e.g. have some XI sender adapter scenarios for a group of interfaces. Recommendations would be to have one or only small number of inbound flows and then distribute the messages via routing. This keeps the JMS resources lower and reduces the number of RFC connections to be maintained.

You should decide what would work best for you. If there are e.g. different integration developers migrating scenarios in parallel it would probably work better to have some XI inbound flows to distribute the work.

Best regards

Mandy
ximadhu
Explorer
0 Kudos
Thank you for the suggestion,
DS22
Discoverer
0 Kudos

Hi Mandy,

Understand that if there are more proxy interface migration to CPI, it is better to have single/a common XI adapter and distribute the work via process direct i believe. However, I would like to understand on how to work with 'Temporary Storage - JMS Queue' in the XI sender adapter.

Scenario: We have to send a payload from XI sender adapter to 2 receivers(JDBC Systems) via multicast. If the payload is successfully send to first receiver but failed to second receiver, then the message will be stored in JMS queue. So, once we fix the issue and we perform a retry, the same message will be sending to both receivers again.

Based on the above, it shows the message is sending again to the first receiver since the 'JMS queue' is configured in the XI sender adapter. So, could we know how to better handle this scenario so that only failed messages send to the intended receiver(e.g second receiver) ?

Additionally, i would think if we go for single XI/a common XI adapter approach and also process direct, we may have challenges to differentiate which messages in the JMS queue belongs to which interfaces since the queue name is referring to "adapter info +  the source iflow" e.g "XI.CPI_XI_IFLOW.XI.f330870e52993721aa23683823408bb8".

Daniel

mandy_krimmel
Product and Topic Expert
Product and Topic Expert
0 Kudos
Hi Daniel,

in case of multicast to several receivers, the recommendation would be to send the message to an outbound JMS queue per receiver (JMS receiver adapter ) and have one sending process for each receiver consuming from the queue and sending to the respective receiver system:

Sender -> XI(JMS) -> multicast -> JMS Receiver (Queue 1)

-> JMS Receiver (Queue 2)

JMS sender (Queue 1) -> Receiver 1

JMS sender (Queue 2) -> Receiver 2

With this you can ensure that the message is not received multiple times by one of the receivers in case the other was not reachable.

Best regards

Mandy
DS22
Discoverer
0 Kudos
Hi Mandy,

Thanks for the feedback. Earlier was thought that if we use the above design it will create 2 JMS messages(e.g 1 message in XI sender Queue and 1 message in JMS sender Queue) in case it fails to send out. After testing, this is not the case.

Daniel
mandy_krimmel
Product and Topic Expert
Product and Topic Expert
0 Kudos
The processing will remove the message from the XI sender queue once the message is successfully saved to the JMS queue and so the retry would only be triggered from the JMS sender queue.

Best regards

Mandy
rupertc
Explorer
0 Kudos
Hi Arvik,

Did you ever get a solution to this Part_boundry_not_Found issue in  XI Syncronous sender -> HTTP receiver scenario?
0 Kudos
Hi Mandy,

I have a scenario where I need to receive messages from backend(ecc) for multiple interfaces via xi sender adapter. I want send a response from the target system back to the backend(ecc) system. Can we use JMS queues in anyway to achive this? if not then how can we achive synchronous scenario with a generic iflow sending messages to multiple iflows.

 

 
mandy_krimmel
Product and Topic Expert
Product and Topic Expert
0 Kudos
Hello,

JMS queues are designed to do asynchronous decoupling and retry. They are not designed for response handling.

If you are using synchronous scenarios for your XI processing as well, you would anyway need a second integration flow for those synchronous scenarios. What I would suggest is to have two integration flows, one generic inbound flow for async scenarios (ALO or EO in the XI sender channel) and one integration flow for sync scenarios (BE in the XI sender channel).

Best regards

Mandy