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

Cloud Integration – Configuring Scenario Using the XI Sender Adapter

This blog describes how to use the new XI sender adapter, which will be available for customers with the 10-June-2018 release. It describes the configuration options, size limits and monitoring options of your scenario.

Configuring a Scenario Using the XI Sender Adapter

Many customers run existing on-premise backend systems that can connect using the XI 3.0 protocol to an integration broker. In most cases the broker is an SAP NetWeaver PI (Process Integration) or PO (Process Orchestration) system. Now, with the new XI adapter, customers can also connect their on-premise backends to SAP Cloud Integration using the XI 3.0 protocol. Whereas the XI sender adapter can be used to receive messages via the XI 3.0 protocol, the XI receiver adapter can be use used to send out messages using the XI 3.0 protocol.

In this blog, I focus on the XI sender adapter and continue with the sample scenario started for the XI receiver adapter in blog Configuring Scenario Using the XI Receiver Adapter. In this scenario, we will now consume the asynchronous XI message from the backend system. To follow the whole scenario it’s easiest for you to start with the sample scenario using the XI receiver adapter and then continue with the XI sender scenario. But you can also consume the scenario for the XI sender adapter independently. In that case, you just configure the confirmation message and send it using transaction SPROXY.

To receive a message via XI 3.0 protocol in Cloud Integration, you need to configure an integration flow with an XI sender adapter and you need to configure the sender backend to send the message to the endpoint the XI sender adapter of the deployed integration flow exposes in Cloud Integration.

Configure the Integration Flow Receiving the XI Message

First, we configure the integration flow in the Web UI, Design section. Create an integration flow, connect the sender participant with the start message event and select the XI adapter.

Configure the XI Sender Channel

First, you choose the Connection tab in the XI sender channel. Configure a path in the Address field. This path will be generated into the endpoint URL, which is called from the sender system to trigger the integration flow execution.

In the Delivery Assurance tab, specify the Quality of Service and, in case of At Least Once and Exactly Once, the Retry configuration settings. Let’s check the options in more detail.

To define the Quality of Service, you have the following options: either At Least OnceExactly Once or Best Effort:

  • Best Effort is used for synchronous request-reply scenarios, that means, in case your sender system has a synchronous interface through which you like to send a message to Cloud Integration you use this option. If you select this option, you don’t need to configure any additional settings because the message request and the response are processed immediately in Cloud Integration. Therefore, no temporary storage of the message for later retry is involved.
  • Exactly Once and At Least Once are both used for asynchronous one-way scenarios, that means if your sender system has an asynchronous interface through which you like to send a message to Cloud Integration you need to use this option. If you configure this option the message is temporarily stored in the Cloud Integration tenant and, if an error occurs, the message is retried from there. The sender gets the successfully received status as soon as the message is persisted in the temporary storage. The difference is that
    • Exactly Once (with version 1.8 or higher of the XI sender adapter in January 2019 release) is ensuring that the XI sender adapter does not process the message if the same XI message ID was already received. It returns a duplicate message back to the sender, but does not process the message in Cloud Integration. This is implemented using an Idempotent Repository storing all the received XI message IDs.
      • Note, that this option can only be used with Data Store as temporary storage because also the Idempotent Repository is based on the database and Cloud Integration cannot support consistent update between JDBC and JMS resources.
      • Also be aware that the performance is not as good as with the At Least Once option because of the additional check against the Idempotent Repository.
      • You should use this option only if urgently required, usually the receiver system can detect and handle duplicates. In this case we suggest to use the At Least Once option.
    • Exactly Once (with version up to 1.7 of the XI sender adapter) processes the same XI message multiple times, if the sender sends it again. With this option the receiver should be able to handle duplicates. This option is equivalent to the At Least Once option available in the 1.8 version.
    • At Least Once (with version 1.8 or higher of the XI sender adapter in January 2019 release) processes the same XI message multiple times, if the sender sends it again. With this option the receiver should be able to handle duplicates. Note, that this option has better performance because no check against the Idempotent Repository has to be done.

We configure At Least Once for our sample scenario as we want to receive an asynchronous message. In this case the Temporary Storage needs to be defined. You can select to store the message temporarily either in the Data Store or in JMS Queues:

  • When Data Store is selected the message is persisted temporarily in the tenant’s database. The stored message can be monitored in the data store monitor.
  • If JMS Queue is selected the message is stored in a JMS queue on the connected JMS broker. Note, that the JMS Queue option is the recommended option because it is more performant but is only available if you have an Enterprise edition or Integration Suite for the tenant. (You can find more details in the in blog ‘How to activate Message Broker’.)

If Data Store is configured as Temporary Storage, the following additional settings need to be defined:

  • Retry Interval: Here you define after which time a retry shall be triggered if there was an error during message processing.
  • Exponential Backoff: If the flag is selected, which I would recommend, the retry interval is doubled after each unsuccessful retry.
  • Maximum Retry Interval: Here you enter the limit to avoid endless increase of the retry interval caused by the exponential backoff setting. This field is only available is Exponential Backoff is selected. The recommendation is to either keep the 60 minutes or even increase it if this is acceptable by the scenario.
  • Encrypt Message During Persistence: If this option is selected the message is encrypted in the data store during temporary storage. Note that this is recommended if the message contains sensitive data. However, the drawback is that this setting reduces the performance slightly.
  • Note that no configuration option is available for dead-letter queue handling. If the data store is used as temporary storage the out-of-memory handling is always active. Which means that after the 3rd retry caused by an out-of-memory a message is blocked and taken out of further processing.

If JMS Queue is configured as Temporary Storage the following additional settings need to be defined:

  • Retry Interval: Here you define after which time a retry shall be triggered if there was an error during message processing.
  • Exponential Backoff: If the flag is selected, which I would recommend, the retry interval is doubled after each unsuccessful retry.
  • Maximum Retry Interval: Here you enter the limit to avoid endless increase of the retry interval caused by the exponential backoff setting. This field is only available is Exponential Backoff is selected. The recommendation is to either keep the 60 minutes or even increase it if this is acceptable by the scenario.
  • Dead-Letter Queue: You should select this option to handle potential out-of-memory situations caused by large messages. If selected,  a message is blocked and taken out of further processing after the 3rd retry caused by an out-of-memory. More details about the dead letter queue handling can be found in blog How to configure Dead Letter Handling in JMS Adapter.
  • Encrypt Message During Persistence: You define if the message is to be encrypted in the data store during temporary storage. Note that this is recommended for sensitiv data but it reduces the performance slightly.

Starting with version 1.6 of the XI sender adapter, which is available with the 28-October-2018 version, you have the option to define size restrictions for inbound processing. In the Conditions tab adjust the default values for the Body Size, if required:

Configure Transaction Handling

You need to configure the correct transaction manager in the integration process for transactional end-to-end processing. Our process does only contain an XI Sender and no data store flow steps or JMS adapters; so we don’t need a specific transaction handler. Select the integration process and switch to the Processing tab. In Transaction Handling drop down select Not Required.

More details about the different transaction handling options and existing limitations are described in the blog ‘How to Configure Transaction Handling in Integration Flow’.

Configure the Outbound Channel

Configure the integration flow with the outbound channel required by your scenario. For the sample scenario we use the sftp adapter and send the message to a directory on the SFTP server. But you can use any other adapter as well.

Deploy the Integration Flow

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

Get the Endpoint URL to be called

To be able to call the integration flow from the sender system, you need to know the endpoint URL to be used. For this check the Endpoints tab in the Manage Integration Content monitor. There the URL is shown and can be copied to the clipboard using the Copy option.

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

The next step is to configure the sender backend to send the message to the Cloud Integration tenant. You need to configure the Integration Engine in the backend using transaction SXMB_ADM -> Integration Engine Configuration.

Configure Local Integration Engine 

If you did not already configure the local Integration Engine executing the XI Receiver blog you need to configure the Local Integration Engine in the backend using transaction SXMB_ADM -> Integration Engine Configuration. Here the Role of the Business System defined should be Application System.

Configure SLD

To send XI messages you need to make sure the SLD is configured correctly. Execute transaction SLDCHECK in the application backend to verify this.

Define RFC Destination with Integration Server URL

There are different options available to define the integration server URL to send messages to via XI 3.0 protocol, either define it for the whole backend system or interface-specific. You can find detailed information on this in the online help for the application system you are using.

To not interfere with any other scenarios in the backend, we will use the interface-specific configuration and define the XI endpoint URL to be called only for a specific interface.

Use transaction SM59 to create a new HTTP Connection to an external server. Define the target host and path prefix according to the endpoint URL you copied from the Endpoints tab. The path prefix is composed according to the following pattern: /cxf/<address field in XI sender adapter>.

In the Logon & Security tab, define SSL and the SSL Client Certificate to be used for the connection. If Basic Authentication is to be used, enter User and Password.

Test the connection using the Connection Test button. You should get an HTTP 500 with the response that an internal error occurred with reference to an MPL. This is because we did not send a payload along with the request. You should not get any SSL error or HTTP 40* errors, in this case you need to check the certificate setup and potentially the user-certificate mapping in the Cloud Integration tenant or the assignment of the role ESBMessaging.send in Cloud Platform role management for the login user. More details about setting up the inbound authentication can be found in the blog ‘How to Setup Secure HTTP Inbound Connection with Client Certificates’.

Define Sender/Receiver Definition

Use transaction SXMSIF to define a sender/receiver definition for the interface you want to use. Configure * for Service to make sure the configuration is valid for all sender and receiver services.

In the sample scenario we use the interface FlightBookingOrderConfirmation_Out from namespace http://sap.com/xi/XI/Demo/Airline from the PI Demo Examples as we want to send the confirmation after we got the flight booking configured in the scenario using the XI receiver adapter. But as already mentioned, you can also use any other interface available in your backend to try this out.

Activate Interface-Specific Endpoint

Use transaction SXMB_ADM -> Integration Engine Configuration –> Specific Configuration to define a new parameter with the following settings:

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

With this, the system will send XI proxy calls for the interface FlightBookingOrderConfirmation_Out to the Cloud Integration tenant.

Test Sending a Message to the Cloud Integration Endpoint

Now we can test the configuration. The easiest way to do this is using transaction SPROXY. In SPROXY select the Service Interface FlightBookingOrderConfirmation_Out in namespace http://sap.com/xi/XI/Demo/Airline. In the menu, choose Proxy -> Test. In the Test Service Consumer dialog leave the settings as they are and select Execute:

A screen with a sample test message is opened, press Execute and afterwards select 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.

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

Test the Whole E2E Scenario

If you started with the flight booking scenario using the XI receiver adapter, you can now test the whole end-to-end scenario. Trigger the scenario by putting a file into the sftp folder and check the monitoring in your Cloud Integration tenant and in transaction SXMB_MONI in the backend.

In Cloud Integration monitoring you should find two message processing logs for the XI receiver integration flow sending the asynchronous request to the backend and one message processing log for the XI sender integration flow receiving the asynchronous response message:

In transaction SXMB_MONI there should be two XI messages; one for the request received and one for the response sent:

Monitoring

To check the processing in Cloud Integration 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. There is one message processing log for the whole processing, containing the inbound messaging that saves the message to the data store/JMS queue and the outbound processing from the data store/JMS queue and sending it to the receiver system.

In the event of a failure the message will go into status Retry. The message will then be retried as configured in the XI sender channel. The detailed error information is available under the link Message Processing Log.

Monitor XI Message ID in Idempotent Repository (For Scenarios using the Exactly Once Option)

For the monitoring of the already received message ID, which are persisted in the Idempotent Repository, an OData API is available. You may use it to find out if a specific XI message was already processed.

For example, you can use the Postman tool to call the OData API for the Idempotent Repository component.

Use the following URL to retrieve the source ID for an XI message ID:

https://<tmn-server>/api/v1/IdempotentRepositoryEntries?id=<xi-message ID>

example:

https://server/api/v1/IdempotentRepositoryEntries?id=00505615-0124-1ee8-b8ea-9aace1a9f929

The call returns 202 if the XI message ID was already processed or 404 if it is not contained in the Idempotent Repository. In case the entry exists in the Idempotent Repository, the Creation and Expiration Times are provided.

Data Store Monitor (For Messages Stored in Data Store)

You can find the messages that are stored temporarily during processing in the Data Stores tile in the Manage Stores section in the monitoring dashboard. During successful processing, the messages are removed immediately after the processing was completed. In case of an error, the messages are kept in the data store to trigger the retry from there.

The used data store name is auto-generated according to the following pattern: <participant name>_< XI channel name>. Below the data store name the <integration flow name>/XI is shown. In the monitor all messages are listed with a status. Two statuses exist:

  • Status Waiting means that the message waits for consumption.
  • Status Overdue indicates that the message was not consumed and processed in the due time, which is 2 days in case of the XI adapter.

In the monitor the Message ID is shown as a link. If you select the link the respective message processing log is opened in the message monitor.

Note that data stores that do not have messages persisted at the time the monitor is opened are not shown in the monitor. This is because data stores are created on the fly in message processing if required and removed after the last message was removed from data store.

Lock Monitor (For Messages Stored in Data Store)

In case the message was involved in several node outages, for example caused by an out-of-memory, the message gets locked in the Lock Monitor. Those messages are not retried any longer. Notice that you will probably not see any entry in this monitor during testing your sample scenario, as this entry will only be permanently available in case of a runtime node outage. So, see this section more as additional information.

The entry will be generated with the following parameters:

  • Component: XI
  • Source: XI_<integration flow name>.<participant name>_<channel name>
  • Entry ID: corresponds to the ID shown in data store monitor

You need to check if the message was the root cause if the error, maybe it is just too large to be processed. Then you need to ask the sender to send the data in smaller messages. Afterwards you can delete the message in the Data Store monitor and then also delete the lock in the Manage Locks monitor. If you are confident that the message did not cause the outage you can release the lock in the Manage Locks monitor by using the Release button.

Queue Monitor (For Messages Stored in JMS Queue)

You can find the messages that are stored temporarily during processing in the Message Queues tile in the Manage Stores section in the monitoring dashboard. During successful processing the messages are removed immediately after the processing was completed. In case of an error the messages are kept in the JMS queue to trigger the retry from there.

The used JMS queue name is auto-generated according to the following pattern: XI.<Integration Flow Name>.<Channel Name>.<Guid>. In the monitor all messages are listed with a status. Four statuses exist:

  • Status Waiting means that the message waits for consumption.
  • Status Failed indicates that the last processing or retry of the message ended with an error.
  • Status Blocked comes into play if dead-letter queue is configured in XI channel and if the message was involved in several node outages and so is taken out of processing. See dead-letter queue handling above.
  • Status Overdue indicates that the message was not consumed and processed in the due time, which is 2 days in case of the XI adapter.

You can see the number of retries that have already been executed and the time of the next retry. You can also trigger an immediate retry of the message or delete specific messages if you no longer want them to be processed.

Queue Deletion

If you do no longer need a specific queue(for example if you un-deploy the integration flow), you have to delete the queue manually in the Queue Monitor if the queue contains messages. The queue cannot be deleted automatically because this could cause data loss. Only the scenario owner knows if the messages can

To find unused queues in the monitor you may use the checks described in the blog ‘Checks in JMS Message Queue Monitor’.

JMS Resource and Size Limits

If you are using JMS for temporary storage you need to keep in mind that the connected JMS messaging instance, that is used has limited resources. The Enterprise or Messaging License sets a limit on the queues, storage and connections that you can use in the messaging instance. The limits are described in more detail in the blog ‘JMS Resource and Size Limits‘.

Important Considerations and Limitations

When using the XI adapter, there are some very important facts you need to be aware of:

Use JMS option if JMS is available in the tenant

To avoid additional load on the database and to have better performance you are strongly recommended to use the JMS option for temporary storage.

Using the Headers set by the XI Sender Adapter Requires to Allow the Required Headers

If you want to use the headers set by the XI Sender adapter in the integration flow configuration you need to add the required headers in the Allowed Header(s) field in the Runtime Configuration of the integration flow. For details check the blog Configuring Scenario with XI Sender handling Multiple Interfaces.

Changing Storage Between Data Store and JMS May Cause Data Loss:

As the adapter stores messages for retry in case of an error either in a JMS queue or in the Data Store, you need to keep in mind that changing this setting for an already running scenario may cause loss of data. This is because there can still be messages in the old storage, which will not be retried anymore after the storage changed. Those messages would stay in the data store or JMS queue until they are deleted (see field Retain Until in Data Store or Queue monitor).

Because of this, be very careful with such changes in productive scenarios. Make sure there are no message left in the ‘old’ storage before changing this setting.

Changing Participant or Channel Name May Cause Data Loss:

As the data store or JMS queue name for retry is generated based on the participant and channel name, a new data store or JMS queue would be generated if you change one of those names. As there can still be messages in the old storage, these messages will not be retried anymore after the storage changed. Those messages would stay in the data store or JMS queue until they are deleted (see field Retain Until in Data Store or Queue monitor).

Because of this be very careful with such changes in productive scenarios. Make sure there are no message left in the ‘old’ storage before changing participant or channel name. With the 30-September-2018 update you have the option to move all messages from one JMS queue to another, if required. This option would help you in case you urgently need to change the channel or participant name or if you have done it without knowing the constraint that a new queue would be generated.

To move messages from one JMS queue to another use the Message Queues monitor. In the single line actions for the ‘old’ queue select the Move action:

In the Move Messages dialog select the newly generated queue and choose Move. All messages of the old queue are now moved to the new one.

Note that there is currently no such move option for the data store. The blog will be updated as soon as this is available.

Wrong transaction handling configuration may cause inconsistent data and/or data loss:

The two storage options, JMS Queue and Data Store, require different transaction handlers. Because of this it is crucial that you define the correct transaction handler:

  • JMS Queue: If a JMS Queue is used for temporary storage in the XI receiver adapter and the XI adapter is used in a sequential multicast or splitter pattern you need to configure the Transaction Handling as Required for JMS.
  • Data Store: If the Data Store is used for temporary storage in the XI receiver adapter and the XI adapter is used in a sequential multicast or splitter pattern you need to configure the Transaction Handling as Required for JDBC.
  • For the XI sender adapter no transaction handler is required.
  • For the XI receiver adapter no transaction handler is required if the XI adapter is not used in a sequential multicast or in a split scenario.
  • As there is no distributed transaction support in Cloud Integration you cannot combine JMS and JDBC transactions. This means that you cannot ensure transactional behavior in scenarios using the XI receiver adapter with JMS storage in multicast scenarios together with flow steps that need a JDBC transaction handler, like for example Data Store or Write Variables.

More details about the transaction handling configuration and the constraints in configuration can be found in blog ‘How to configure Transaction Handling in Integration Flow‘.

The XI adapter currently has some limitations:

  • No explicit retry handling via Retry Header in Exception Sub-Process possible possible yet. -> Solved, see blog Configuring Explicit Retry in Exception Sub-Process for XI Adapter Scenarios.
  • MPL status stays in Retry even if the message is deleted from JMS queue or data store. Nevertheless in runtime no retry is executed anymore. -> solved, messages are now getting status Cancelled when the corresponding message is manually deleted in JMS or Data Store monitor. Note that the deletion of a message after the expiry date does not lead to Cancelled messages because the delete is directly done on the database/JMS broker.
  • XI receiver adapter is currently neither allowed in Request-Reply nor in Send step. -> Solved, see blog Usage of XI Adapter in Send and Request-reply Step.
  • Acknowledgements are not supported
  • Attachments are not supported -> solved with the latest versions of the XI sender and receiver adapter (February 2021)
  • Packaging is not supported -> solved with the latest versions of the XI sender adapter (April 2021)
  • Fault Messages are not supported
  • ExactlyOnceInOrder (EOIO) is not supported.

The blog will be updated regularly with the new features.

Assigned Tags

      57 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Manfred Lorenz
      Manfred Lorenz

      Hi Mandy,

      thanks a lot for this perfect blog. I'm sure many customers have been waiting for this feature. I have one question regarding the sytstem setup.

      Suppose a company has SAP PO and SAP CPI and only wants to set up the RFC connection to the CPI once in addition to the PO destination. I understand that i can decide which middleware should be used using sender/receiver definitions.

      But how do we have to specify the CPI endpoint in the RFC destination (is there one general URL for all CPI service interfaces like it is in PI /XISOAPAdapter/MessageServlet?ximessage=true) and how do we distinguish between the different serviceinterfcaces on the CPI side?

      Thanks for some more information on how to deal with connectivity setup using two middleware systems in a big interface landscape.

      Best Regards,

      Manfred

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

       

      Hi Manfred,

      no, there is no central inbound URL for the XI service in CPI. You can configure this as you like, you can have one central XI sender channel in one integration flow that would receive all XI inbound calls and then do routing to different processes/flows based on the payload received.

      Or you create different XI sender channels having different URL addresses and then use the interface specific configuration in the backend to call those different URLs.

      Best regards,

      Mandy

      Author's profile photo Robin Van Hoof
      Robin Van Hoof

      Hi Mandy,

      I'm currently looking into this as well and I'm trying to set up such an interface specific configuration in SXMB_ADM. I was hoping that by using a subparameter and checking the "Prefix" checkbox the subparameter name would be appended to the path prefix defined in the referenced RFC destination I configured in SM59, but it seems this doesn't work. My goal is to have one central connection to CPI in SM59 and dynamically determine the specific iFlow endpoint at runtime, based on the subparameter name in SXMB_ADM. Is such a configuration possible? I also posted this as a separate question to the wider community here (including screenshots): https://answers.sap.com/questions/13855273/sxmb-adm-subparameter-as-prefix.html

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

      Hi,

      I got the information from the PI colleagues that such a complete dynamic configuration is not possible.

      Please check note 2999875 - XI runtime: Receiver-specific IS_URL - SAP ONE Support Launchpad for the options available. But you need to create a dedicated RFC destination for all the different endpoints exposed in Cloud Integration. That's why the better option would be to have a central entry point in Cloud integration for all interfaces and route based on the interface, see Cloud Integration – Configuring Scenario with XI Sender handling Multiple Interfaces | SAP Blogs

      Best regards+

      mandy

      Author's profile photo Richard McArthur
      Richard McArthur

      So we seperate RFC destination maintained for every iflow receiver in HCI ?

      Is SAP putting anywork into alternative way of configuring connections ? G TYPE connections with the end point URL is much the same as standard SOAMANAGER and SOAP connections, Id love to use the XI adapter but Ill end up with 100 distinct RFC connections - now change the password for the service user (no certificates).

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

       

      Hello Richard,

      you mean XI sender adapter, right?

      As stated above you can configure your scenario in a way that you have only one XI sender channel. Then you have to configure the routing based on the payload/interface to further process the message. There are no plans at the moment to change this architecture in Cloud Integration.

      Best regards,

      Mandy

      Author's profile photo Richard McArthur
      Richard McArthur

      Thanks Mandy, I implemented a mini Router using XI adapter and Process direct, with some groovy to extract message type and route to the correct end point. I now have a single end point that dynamically routes to the correct integration flow with no other backend configuration.

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

       

      Great, thank you for the info.

      Author's profile photo Vijayashankar Konam
      Vijayashankar Konam

      Hello Richard,

      I am building the router on CPI for the same purpose. Could you please through some light on how you are dynamically generating the processdirect adapter target URL? I would like to use sender business system, interface and namespace just the way PI uses them in an ICO. However, I see that, those headers are not propagated into the iFlow exchange properties or as header. Any suggestion would be appreciated.

      VJ

      Author's profile photo Eng Swee Yeoh
      Eng Swee Yeoh

      Hi Mandy

       

      This XI 3.0 protocol support is a much needed functionality for many existing SAP customers that have invested heavily into SAP's previous de-facto middleware, PI/PRO.

       

      A key feature of this is the single entry point into the middleware for all different interfaces (as you can see from the other comments here). While we can implement a custom router to achieve this, it would be great if such capability be included out-of-the-box. This will prevent unnecessary custom development/configuration each time we need to include a new interface - imagine a company like ours needing to configure such a router for 100+ interfaces that we currently have on PI.

       

      If I'm not mistaken, the AS2 sender adapter has a similar capability, where there is only a single fixed endpoint URL.

       

      Appreciate it if you can bring this feedback/request back to the product development team for it to be included in the roadmap. This will greatly enhance the capabilities of CPI as well as help in its adoption into many company's landscape.

       

      Thanks and best regards,

      Eng Swee

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

       

      I will bring this request into our development planning, but cannot comment if it will make it to the roadmap.

      Best regards,

      Mandy

      Author's profile photo Eng Swee Yeoh
      Eng Swee Yeoh

      Thanks Mandy, every bit of assistance is much appreciated.

      Author's profile photo Tobias Miller
      Tobias Miller

      Hi Mandy,

      first I want to thank to your great article! I wait now already on new CPI reading material from you 🙂

      I want to know about the runtime behaviour of the retry logic in CPI message monitor regarding an IFlow with XI sender adapter in combination with QoS EO. So I built up a PoC XI-to-Mail-IFlow as you can see on the following picture:

      As I understand it (from your above "Data Store" section), the PoC IFlow should only retry the message processing two times until it changes the state from "retry" to "error".

      However, when I run a test (provoked error on receiver mail adapter) the retry mechanism repeats in an infinite loop even though the "maximum retry interval" parameter is set.
      It seems to me that this parameter doesn't work.

      Is the illustrated XI adapter of my PoC maybe incorrectly configured or could that be a bug?

      Best Regards,

      Toby

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

       

      Hello Tobias,

      as the parameter says this is only the maximum retry interval meaning the exponential backoff will not increase it further. But the retry will still continue. See also the description of the field and the tooltip.

      Taking your sample:

      • first retry after 1 minute
      • second retry after 2 minutes
      • third retry again after 2 minutes
      • and so on

      Meaning the 2 minutes is the maximum interval between two retries.

      If you set this to 60 minutes, the processing would look like this:

      • first retry after 1 minute
      • second retry after 2 minutes
      • third retry after 4 minutes
      • 4th retry after 8 minutes
      • 5th retry after 16 minutes
      • 6th retry after 32 minutes
      • 7th retry after 60 minutes
      • 8th retry after 60 minutes
      • and so on

      Currently there is no option to stop the retry after a specific number of retries (see also the limitations chapter about explicit retry configuration in exception sub-process). But I can already tell you now that this option will come with the September update in about 5 weeks. I will post a new blog about this feature shortly before it is available.

      Best regards,

      Mandy

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

      The explicit retry configuration will be available with the 2nd-September-2018 update, see blog Configuring Explicit Retry in Exception Sub-Process for XI Adapter Scenarios.

      BR,

      Mandy

      Author's profile photo Leonel Martinez
      Leonel Martinez

      Hello Mandy,

      Thanks for this blog.  I an new with HCI and I a little confuse with this.

      In a escenario SAP ECC->SAP PI/PO using a XI adapter, first in  SAP PI/PO we create the objects Data Type, Message Type an Service Interface and Then in SAP ECC in transacction SPROXY we generate the proxy object with the structure define in the message type.
      But in this scenario SAP ECC->SAP HCI using a XI adapter, where do you define the stucture and the service interface to generate in SPROXY transaction?

      Thanks,
      Regards,
      Leonel

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

       

      There is no ESR or similar tool to create interfaces and generate proxies available yet in Cloud integration. You still have to use the known ESR for this, you can than import the interfaces and mappings into Cloud Integration.

      Best regards,

      Mandy

       

      Author's profile photo Ricardo Israel Mata Viejo
      Ricardo Israel Mata Viejo

      Hi Mandy,

      Great blog, thank you so much, this really helps. I do have one question, hope you may help.

      There is the step to configure the SLD, but I dont have PO or SolMan on my landscape this is a single ECC system on HEC, I would like to leverage XI adapter, how can you configure the SLD?

      Any advise.

      Best regards,

      Ricardo

       

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

       

      Hello Ricardo,

      here you find more details about SLD and it's setup: https://support.sap.com/en/tools/software-logistics-tools/landscape-management-process/system-landscape-directory.html

      Best regards,

      Mandy

      Author's profile photo Ricardo Israel Mata Viejo
      Ricardo Israel Mata Viejo

      Thanks Mandy, but if I understand correctly I would need to install a SLD, correct?

      Currently this would be an impact on costs, basically, is there a way to do fix setup?  because there is no SLD in the landscape.

      Is there a scenario where this may work without an SLD? Cause at the moment I dont have either the component or the system to support it.

      Thank you.

      Best regards,

      Ricardo

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

       

      Hello,

      actually this would not be a fix in Cloud Integration side. 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 Ricardo Israel Mata Viejo
      Ricardo Israel Mata Viejo

      Thank you Mandy, I really appreciate your help.

      Best regards,

      Author's profile photo Ramanjaneya Reddy Sanivarapu
      Ramanjaneya Reddy Sanivarapu

       

      Hi Mandy,

       

      Appreciate your blog and it really helped in configuring many proxy scenarios and migrating the existing PI interfaces to CPI easily.

       

      But now we are facing a problem with "Proxy with attachments" , when ever there is a message with application attachment in the request ; we observe that in the data store the attachment is being lost and only the main payload is being stored. We need the Application attachment as well ( where we are converting attachment data to main payload in our scenario)

       

      Does the XI sender adapter supports Attachments? If yes, could you please  support us if we are missing anything!!

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

      Hello,

      The XI adapter currently does not support attachments (I added it now also to the limitations section), neither does the data store.

      Best regards,

      Mandy

      Author's profile photo Aswini Alapati
      Aswini Alapati

      Hi @Ramanj_reddy

      We recently migrated our On-Prem system to CPI and have few questions

      I see that you migrated you on-prem PI to CPI using the same procedure. so can you help me here:

      1. There will be no affect to the CPI flow which is using the existing proxy structures and Service interfaces
      2. How a customization(like adding a new field or changing the data type of existing field) can be performed to the proxies in ECC? I understand , in CPI we can easily edit the xsd. But how we can change the existing proxy structure in ECC.

      Many thanks in advance,

      Aswini.

       

       

      Author's profile photo Ramanjaneya Reddy Sanivarapu
      Ramanjaneya Reddy Sanivarapu

       

      Hi Mandy,

       

      Thank you for your quick response.

       

      One good news though , the XI message along with application attachments is working fine with JMS Queues though.

      We are testing multiple cases as well and will post if any issues.

       

      Thanks & Regards,

      Ramanji

      Author's profile photo Pradeep Kumar A
      Pradeep Kumar A

      Hello Mandy,

      Thanks for the great blog, as per your blog for me everything is working fine.

      But when i am send the response back to SAP, sender business component is going like AnonymousSOAPservice. I have added the Business component name like CPI_DEV in header. But while trigerring response SOAP Envelop is over writing my business component name from CPI_DEV to AnonymousSOAPservice.

      Can you suggest where i need to maintain the business component name in CPI, how to send back same name in Response to SAP.

      Below is Response SOAP Envelope

       

      Regards

      Pradeep Kumar. A

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

      Hello,

      this is currently a hard coded value. We have to make this configurable in the XI Sender adapter.

      Best regards,

      Mandy

      Author's profile photo Pradeep Kumar A
      Pradeep Kumar A

      Hello Mandy,

      Thanks for your replay.

      I am not able see the option where to maintain the Business component value in XI sender adapter. But I am maintaining in Content modifier header. When CPI sending the response to SAP ECC soap envelop is automatically overwriting  the existing header value to AnonymousSOAPservice.

      Regards,

      Pradeep Kumar. A

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

      Hello,

      please read my answer carefully. This is currently a hard coded value which cannot be overwritten, neither via header nor in the configuration. We (Cloud Integration) have to make this configurable. I will update the blog once this option is implemented.

      BR,

      Mandy

      Author's profile photo Sreenivasa V
      Sreenivasa V

      Hi Mandy,

       

      Can you please confirm is it possible to test the iflow(for exam: XI to Mail or XI to SOAP) from SOAPUI or Postman, using iflow endpoint. Rather than sproxy.

       

      If Yes please let me know.

       

      Thanks,

      Sreenivasa Veldanda.

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

      Hi,

      this is probably very difficult as you would have to build a valid XI message and not just send the payload message. Using SPROXY this is done automatically for you as a valid XI message is constructed before sending out the message. In the CPI trace you can see the real payload that is arriving before the XI sender adapter converts it to a Camel exchange in CPI, where the XI message payload is converted to the Camel message and the XI message headers are converted to Camel headers.

      Best regards,

      Mandy

      Author's profile photo Sreenivasa V
      Sreenivasa V

      Hi Mandy,

       

      Can you please confirm my doubt.  Generally cloud Connector is useful for Outbound from CPI.  In synchronous Sender proxy how the cloud connector will come into the picture.

       

      Please clarify My doubt.

       

      Thanks,

      Srinivas

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

      Hi,

      Cloud Connector is used for communication from CPI to a receiver backend, this is correct. I do not understand your remark about synchronous sender proxy. In XI sender adapter there is no Cloud Connector involved.

      If this does not answer your question please clarify your scenario in question in more detail.

      BR,

      Mandy

      Author's profile photo Amarnath Krishnamoorthy
      Amarnath Krishnamoorthy

      Hi Mandy ,

      How could i connect or which adapter i need to use for a Sender Proxy scenario via Cloud Connector to CPI ?

      Please confirm if Cloud connector can be used for a Synchronous Proxy scenario to connect with CPI ?

      Many thanks in advance for your answer .

      Author's profile photo Teun Hulten van
      Teun Hulten van

      Hi Mandy,

      Thanks for your blog.

      In our scenario we would like to trigger an application error, with a custom error message, in a SAP ABAP system with an XI Sender adapter in CPI.
      If we end the IFlow in CPI with an Error End, a system error is registered in /SXMB_MONI with the generic CPI error message. We would like to customise this.

      Our custom fault message is constructed in the exception sub process according to the Fault Message Type defined in the ABAP Proxy. We have set the CamelHttpResponseCode to 500 and have ended the flow with a Message End but no error is triggered in the SAP ABAP system. The fault message however is successfully received.

      Is it possible to trigger an (application) error with the XI Sender Adapter and return a custom fault message?

      Thanks.
      Best regards,

      Teun van Hulten

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

      Hello Teun,

      it is currently not possible in XI sender adapter to define custom error payload with error status to be sent back to sender system.

      This would be a new requirement to the XI adapter.

      BR,

      Mandy

       

      Author's profile photo Harsha Gaonkar
      Harsha Gaonkar

      Hi

      Is SLDCHECK is mandatory for S4 HANA to CPI connection?

      I do not have PI in my landscape. I want to connect S4 HANA to CPI and cloud connector is installed on S4 HANA.

      Thanks

      Harsha

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

      Hello Harsha,

      I'm not an expert in S4Hana, so not absolutely sure if SLDCHECK is required there. But I think so, yes. Important is that the backend system is defined as application system.

      Best regards,

      Mandy

      Author's profile photo Nitheesh Cherrikkal
      Nitheesh Cherrikkal

      Hi Mandy,

       

      Thanks for the amazing blog. I'm using a sender XI adapter in CPI to receive messages from S4 hana System. However messages are failing with the below error . I tried changing the Qos to EO and BE but same error with both .

      Inbound processing in endpoint at /S4/FreightOrder failed with message "NullPointerException:while trying to invoke the method com.sap.it.cxf.xi.message.QualityOfService.equals(java.lang.Object) of a null object returned from com.sap.it.cxf.xi.XIProperties.getQualityOfService()"

      Could you kindly help with this? Attaching the channel configuration herewith.

       

      Thanks,

      Nitheesh

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

      Hi,

      are you sending the message with EOIO? this is not allowed in the XI Sender adapter.

      Please check in the sender system to ensure you send it as EO only.

      Best regards

      Mandy

      Author's profile photo Aswini Alapati
      Aswini Alapati

      Hi @ Mandy Krimmel ,

      We followed the same blog to migrate our On-Prem PI system(7.11) to CPI using the existing proxy structures.

       

      Now we are going to decommission PI system. Can you provide some information on below two points:

       

      1. There will be no affect to the CPI flow which is using the existing proxy structures and Service interfaces
      2. How a customization(like adding a new field or changing the data type of existing field) can be performed to the proxies in ECC? I understand , in CPI we can easily edit the xsd. But how we can change the existing proxy structure in ECC.

      Thanks in advance,

      Aswini.

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

      Hello Aswini,

      CPI currently does not offer something like an ESR, so extending proxy structures is not yet available. But there are extensions planned on the roadmap for 2021.

      Currently the XSDs could be extended manually in CPI, but this will not be reflected in the ECC system and would have to be changed there as well.

      BR

      Mandy

       

      Author's profile photo Aswini Alapati
      Aswini Alapati

      Hi Mandy Krimmel ,

      Thanks for the response. Is there any SAP standard way how the existing proxies can be modified in ECC.

       

      Thank you very much in advance,

      Aswini.

       

      Author's profile photo Punith Oswal
      Punith Oswal

      Hello Mandy,

      Thanks for this detailed blog.

       

      I wanted to discuss one of the observations on XI adapter processing.

      I am using XI Sender Adapter to receive proxy messages from ECC system, My design is a  common XI sender adapter proxy and then via process direct the messages are disturbed to other respective flows based on Message Type in the payload.

       

      So I observed the message count is not matching up for XI Sender Adapter iFlow, for example if the load at ECC end has 500 messages, the XI Sender Adapter iFlow message count is 550, ideally the count should match right ? Please enlighten me if am missing something here.

       

      I am using Quality of service as "Exactly Once".

      My understanding is the count should match, number of messages from ECC = number of calls in XI Sender Adapter iFlow, but this is not the case.

       

      Your response is much awaited.

       

      Thanks,

      Punith O.

       

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

      This indeed sounds wrong. I would suggest you open a ticket on LOD-HCI-PI-CON-SOAP so that the experts have a look.

      Best regards

      Mandy

      Author's profile photo Peter Chezowitch
      Peter Chezowitch

      Thank you for this blog.

      Is it strategically recommended to continue to use XI/Proxy interfaces or what is the route we should go for new integrations? Is the monitoring still the same with sxmb_moni in an S4 system as it was with ECC? And if so, can we see the same details there with a CPI instead of a PI for sender and receiver scenarios?

      Also: Any news on the data type modelling tool for Cloud Integration?

      What is the current best practice to update proxies in SPROXY when we have no PI in the landscape anymore? Manually work on xsd/wsdl files and then upload them to SPROXY and CPI?

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

      Hello Peter,

      Cloud Integration is currently working on the data type modeling and it is planned to be available in 2022. Until then it is still necessary to either use the ESR for data type modeling or do manual changes on xsd/wsdl.

      the monitoring in the backend should be equal independent if CPI or PI is used for communication.

      Best regards

      Mandy

      Author's profile photo Rahul Yadav
      Rahul Yadav

      Hi Mandy,

       

      Thanks for writing amazing blog for the connectivity between SAP ECC/S4HANA. When I am triggering the data from SPROXY, I am not getting receiver system component name in SXMB_MONI. Is there any configuration required to populate that value in monitoring ?

      In your screenshot, I can see that CloudIntegration_TenantT2 will be receiver component during request and sender during response.

      May be, I am missing some configuration in S4HANA/ECC due to which component name is coming blank but message is successfully reaching SAP CPI.

       

      Rahul

       

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

      please check the scenario configuration for the whole E2E sceanrio: Cloud Integration – Configuring Scenario Using the XI Receiver Adapter | SAP Blogs

      There in the XI receiver channel the sender ID is configured.

      Best regards

      Mandy

      Author's profile photo Alexander Aigner
      Alexander Aigner

      Hello Rahul,

      for outbound messages (Proxy from SAP to Middleware) the Receiver is typically not known as the determination of the receiver happens in the Middleware (in your case the CPI). This behaviour is normal. For inbound (Middleware to SAP), the Middleware knows Sender and Receiver, thus you see it in this case also in the monitor (SXMB_MONI)

      Best regards,
      Alex

      Author's profile photo Rahul Yadav
      Rahul Yadav

      Thanks Alexander/Mandy,

      Got the concept. I was thinking that we can somehow populate the system name ( BS_CPI) as receiver component name so that by seeing the S4HANA monitoring, we can understand the logical recipient of the message. If it is regular behavior then I think we are good.

      I remember we can set sender component easily from Receiver XI adapter.

      Rahul

      Author's profile photo SUNIL Guddapathala
      SUNIL Guddapathala

      Hi Mandy,

      Thanks for this detailed  blogs.

      I am migrating proxy interface from PI to CPI. Is this possible to connect proxy interface both PI and CPI at at time with same ECC.

      If possible could you please suggest blogs.

       

      Regards,

      Sunil

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

      Hello Sunil

      with Interface-Specific Endpoint configurations you can configure this specific for dedicated interfaces. Connect one to PO and one to Cloud integration. With this you can step by step connect more and more scenarios to Cloud Integration.

      Hope this answered your question?

      Mandy

      Author's profile photo SUNIL Guddapathala
      SUNIL Guddapathala

      Hi Mandy,

      Thank you for your quick response.

      I have 5 proxy interface which needs to be migrate to CPI. Remaining proxy interface has to run as usual in PO.

      Let me check endpoint Configuration.

       

      Regards,

      Sunil

      Author's profile photo Bruno Hjort
      Bruno Hjort

      Hello Mandy,

      I have a little question about a behavior that I observed in the log monitor. I'm using the XI sender for receiving a standard message from SAP EWM and it is working fine, it receives and process the message successfully. But in the logs it is always marked as two runs, and the first one stays forever as "Processing". Is it normal?

       

       

       

      Best regards,

       

      Bruno

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

      Yes, this is as expected. This is the first run writing the message to the JMS queue, but as the overall status of the message processing is still waiting for the next step, the poll and further processing, the status stays in processing. then the poll happens which then gets a real status - completed or failed or retry.

      Best regards

      Mandy