Technical Articles
Cloud Integration – Configuring Scenario Using the XI Receiver Adapter
This blog describes how to use the new XI receiver adapter, which will be available for customers with the 10-June-2018 release. It describes the configuration options, size limits and monitoring of your scenario.
Configuring a Scenario Using the XI Receiver Adapter
Many customers run existing on-premise backend systems that can connect to an integration broker using the XI 3.0 protocol. 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 used to send out messages using the XI 3.0 protocol.
In this blog, I focus on the XI receiver adapter and will create a sample scenario for the XI receiver adapter. In this scenario an asynchronous request is sent to a backend using the XI 3.0 protocol. In blog Configure Scenario Using the XI Sender Adapter I will continue with the end-to-end scenario configuring the XI sender adapter to receive an asynchronous response.
To send a message via the XI 3.0 protocol in Cloud Integration you need to configure an integration flow with an XI receiver adapter and you need to configure the receiver backend to receive the message.
Configure the Receiver System to Receive the XI Message from Cloud Integration
The first step is to configure the receiver backend to receive a message via the XI 3.0 protocol. You need to check that the local integration engine is configured.
Configure Local Integration Engine
Configure the Lokal Integration Engine in the backend using transaction SXMB_ADM -> Integration Engine Configuration. Here the Role of the Business System defined should be Application System.
Construct XI Engine URL
Then you need to construct the URL under which the local integration engine of the application system can be called. This URL needs to contain the HTTPS port the system exposes. Check in transaction SMICM -> Goto -> Services. Using the host name and port of the HTTPS service construct the URL using the following pattern:
https://<host name>:<port>/sap/xi/engine?type=receiver&sap-client=<client>
Get Name of the Business System
To be able to configure the XI receiver channel you need to know the name of the business system of the applications system. The easiest way to find out this information is to use transaction SLDCHECK in the application backend. In section LCR_GET_OWN_BUSINESS_SYSTEM you find the id of the business system. Usually it has the pattern: <SID>_<client>.
Check Available Interfaces
Use transaction SPROXY to find out which XI services are available in the system. For our sample we use the services of the PI flight booking demo examples. Check for the Service Interface FlightBookingOrderRequest_In in namespace http://sap.com/xi/XI/Demo/Airline.
Check that the interface is active. This interface will process the request and send back an asynchronous response (interface FlightBookingOrderConfirmation_Out) to Cloud Integration. The configuration for the response processing is described in the blog Configure Scenario Using the XI Sender Adapter and can be done as soon as the request configuration is successfully finished.
If this interface is not available in your backend, you can also use another Inbound interface for the scenario.
Now we have all the details to configure the integration flow in the Cloud Integration tenant.
Configure the Integration Flow Sending the XI Message
First, we configure the integration flow in the Design section of the Web UI. Create an integration flow, connect the end message event with the receiver participant and select the XI adapter.
Configure the XI Receiver Channel
First, you configure the Connection Details in the Connection tab in the XI receiver channel.
- Configure the Address field with the XI Engine URL constructed in one of the last steps.
- Select the Proxy Type you want to use to connect to the backend. On-Premise indicates that in our sample scenario we use the cloud connector configured with the Location ID CC2 to connect to the on-premise backend. The configuration of the cloud connector will not be described here. If the cloud connector is required to connect to the backend refer to the SAP documentation for the cloud connector.
- Select the Authentication Type required, in this sample scenario we use Basic Authentication and so have to enter the Credential Name as well. Make sure that you deploy the credentials on the tenant before you deploy the integration flow.
In addition to the connection details, you need to define the XI-specific configuration:
- Define the XI Identifiers For Sender system. We define a name for the Sender Communication Component. This name is used in the backend to identify the sender of the message.
- Define the XI Identifiers For Receiver. We define the name for the Receiver Communication Component. Set the business system of the receiver backend here, use the name you retrieved in one of the last steps using the SLDCHECK.
- As Service Interface define the interface you want to call in the backend, for our scenario we use FlightBookingOrderRequest_In.
- As Service Interface Namespace define the namespace of the interface you want to call in the backend, for our scenario we use http://sap.com/xi/XI/Demo/Airline.
In the Delivery Assurance tab, you specify the Quality of Service and, in case of 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 Exactly 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 is 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.
We configure Exactly Once for our sample scenario as we want to send 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 for 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. This 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 for 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: If this option is selected, the message is encrypted in the JMS queue 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
ID Mapping in XI Receiver
With the 25-November-2018 update an additional dropdown is available to configure the mapping of the message IDs, which is important to reach real Exactly-Once (EO) handling.
If the XI Message ID Determination dropdown is already available in your channel, you may keep it with the default setting Generate for this scenario. But you could also configure it to map the order ID from the inbound message to the XI message ID. Configure this as described in the blog Configuring ID Mapping in XI receiver Adapter.
Dynamic Configuration in XI Receiver
Most fields in the XI Receiver adapter are supported for dynamic configuration. This means you can configure them from a header or property:
The following fields can be configured via header or property:
- Address
- Location ID
- Credential Name
- Private Key Alias
- Sender Communication Party
- Sender Communication Component
- Receiver Communication Party
- Receiver Communication Component
- Receiver Service Interface
- Receiver Service Interface Namespace
Note that you need at least version 1.6 of the XI Receiver channel. This is the version that is available with the 5th-August-2018 update.
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 one direct XI Receiver without splitter or sequential multicast; 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 Inbound Channel
Configure the integration flow with the inbound channel required by your scenario. For the sample scenario we use the SOAP adapter and trigger the message from SOAP UI. But you can use any other adapter supporting asynchronous requests as well.
- Define the Address the SOAP endpoint will expose.
- Select One-Way as Message Exchange Pattern because the scenario is an asynchronous one-way scenario.
- Select Robust as Processing Setting to receive errors back that may occur during message processing.
- Define the Authorization you want to use. As we want to connect using user and password, we use User Role with the default User Role ESBMessaging.send.
Deploy the Integration Flow
Now you can deploy the integration flow. Afterwards check that 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 SOAP UI you need to know the endpoint URL to be used. For this purpose, 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.
Sending a Message to the Cloud Integration Endpoint
Now you can run the scenario. Use the SOAP UI to send the call. You can use the following request payload:
<soapenv:Envelope xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/” xmlns:dis=”http://camel.apache.org/cxf/jaxws/dispatch”>
<soapenv:Header/>
<soapenv:Body>
<ns1:FlightBookingOrderRequest xmlns:ns1=’http://sap.com/xi/XI/Demo/Airline’>
<AgencyData>
<AgencyID>00000110</AgencyID>
<OrderNumber>00000001</OrderNumber>
<ItemNumber>01</ItemNumber>
<OrderType>Single</OrderType>
</AgencyData>
<FlightID>
<AirlineID>LH</AirlineID>
<ConnectionID>401</ConnectionID>
<FlightDate>2018-04-01</FlightDate>
</FlightID>
<ClassCode>Y</ClassCode>
<PassengerName>Max Muster</PassengerName>
<PassengerBirthdate>2000-12-31</PassengerBirthdate>
</ns1:FlightBookingOrderRequest>
</soapenv:Body>
</soapenv:Envelope>
After triggering the request from SoapUI, you can check the execution in Cloud Integration’s monitoring and in transaction SXMB_MONI in the backend. In Cloud Integration’s monitoring you will see that two messages were processed; one message for storing the message in the temporary storage and one for consuming it from there and further processing it. More details about the monitoring in Cloud Integration can be found below in the Monitoring section.
In transaction SXMB_MONI you should see two messages: the inbound request from Cloud Integration which should be processed successfully and an outbound request trying to send the response. But as we have not yet configured the response processing this message will probably have the status failed. The response processing will be configured in the blog Configure Scenario Using the XI Sender Adapter.
Monitoring
To check the processing in Cloud Integration detail, you can use the monitoring tools provided by Cloud Integration.
Message Monitoring
The message processing can be checked in detail in the section Monitor Message Processing. Select the message you sent and check the processing status. You should find two message processing logs, one for the inbound messaging that saves the message to the data store/JMS queue, and one for processing the message from the data store/JMS queue and sending it to the receiver system. Those two messages are correlated via the CorrelationID available in the textual representation of the message processing log.
With the 8th-July-2018 update of Cloud Integration, this Correlation ID is in addition shown in the Properties of a message processing log and you can also search for all messages having the same Correlation ID using the ID search field at the top of the monitor:
In the event of a failure when sending to the receiver system, the outbound message will go into status Retry. The message will then be retried as configured in the XI receiver channel. The detailed error information is available under the link Message Processing Log.
Data Store Monitor (For Messages Stored in Data Store)
The messages that are stored temporarily during processing can be seen 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 <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” during message processing if required and removed after the last message was removed from the 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 of 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)
The messages that are stored temporarily during processing can be seen 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.
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.
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 be deleted or are still required.
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 sender or receiver 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.
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 changed in productive scenarios. Make sure there are no messages 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.
- 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 version of the XI sender adapter (April 2021)
- Acknowledgements are not supported
- Fault Messages are not supported
- ExactlyOnceInOrder (EOIO) is not supported.
The blog will be updated regularly with the new features.
Hi Mandy
Thank you for sharing on this much awaited functionality.
I would like to ask about the JMS Queue naming - XI.<Integration Flow Name>.<Channel Name>.<Guid>
Can you explain further how <Guid> is derived - is it at per message level, per channel, or some other granularity? I would like to know because your other blog mentions that the maximum queue is 30, so this might mean that there is a limit on how many XI flows/channels/messages/etc are possible in a single CPI tenant.
I also noticed that the retry functionality (for Data Store) seems to go on forever irrespective whether Exponential Backoff is selected (with maximum retry interval set) or not. I had to manually remove the Data Store entries to stop the retries.
Regards
Eng Swee
Hello Eng Swee,
the Guid is auto-generated based on the combination of iFlow/participant and channel. This is definitely unique and cannot be re-used between flows. And yes, this goes into the count of queues, which is limited to 30 queues. (but in future additional JMS resources can be bought in addition).
The retry is always going on forever, this has nothing to do with the exponential backoff. The exponential backoff only restricts the max time interval between the retries. For an explicit modeling of max retries you need to use an exception sub-process and model this on your own. But this is currently not supported for the XI adapter, this will come in one of the next updates. The blog will be updated then.
BR,
Mandy
Hi Mandy
Thanks for the quick response and explanations!
So can I say that at the moment, we can only have roughly 30 integration flows with XI receiver channels?
If the retry goes on forever, that's gonna make the XI adapter pretty much useless for productive scenarios at the moment.
Hi,
Yes, this is true. With 30 receiver channels using JMS as temp storage you are at the limit.
The retry configuration option will be added shortly (in one of the next updates), we know that this is urgently required.
BR,
Mandy
Great. Thanks for the update and clarifications, Mandy. Appreciate them.
Oops.. sorry, one last question (for now) -
Does the 30 JMS queues limit holds true as well when running the CPI content on on-premise PO 7.5?
XI adapter is not released yet for IGW profile. And if it gets released the XI adapter will most probably be available with data store option only.
BR,
Mandy
is there any option for proxy structure creation like PI in HCI also?
Hello Priya,
there is currently no such possibility available in Cloud Integration.
Regards,
Mandy
Does the CPI XI Receiver adapter support Request-reply pattern for having synchronous response back from ABAP Proxy.
yes, if you select Best Effort in the XI receiver channel you are able to execute synchronous calls (as mentioned in the blog).
BR,
Mandy
We are having request reply is not supported for the adapter error.
Hi,
as clearly mentioned in the limitations section, XI adapter is currently neither allowed in Request-Reply, nor in Send step. It's planned, but not yet supported.
BR,
Mandy
It's now supported: see blog Usage of XI Adapter in Send and Request-reply Step.
Thanks Mandy for the update, I tested it and works now.
Hi Mandy,
Thanks for you blog. I am using the CPI XI adapter to call an ABAP Proxy on a SAP backend system. The message has been received by the backend system, but is not routed to the proxy, but rather to the integration server. The Pipeline it is classified as SENDER rather than RECEIVER.(if I compare with similar message, coming from a SAP PI system, calling the same ABAP Proxy)
In the logging I have found the following error:
Error while receiving by HTTP (error code: 200, error text: Error Parsing Response. No XI Response Received.)
Does this ring any bells?
Thanks,
Frank
Hi Frank,
looks like some configuration problem.
Is it a synchronous interface you are calling? Are you calling this with setting BE in Delivery Assurance Tab in XI channel?
BR,
Mandy
Hi Mandy,
Thanks for the quick response. No it is a asynchronous interface, Exactly Once has been configured.
Thanks,
Frank
Hi Frank,
it's hard to say via remote analysis. Could you maybe open a ticket on LOD-HCI-PI-RT?
Please attach the integration flow project and the mpl with log level Debug and the complete log from the backend (from sxmb_moni)
Best regards,
Mandy.
One more idea: what is the endpoint URL configured in the XI receiver channel? Does it have URL parameter type=receiver?
https://<host name>:<port>/sap/xi/engine?type=receiver&sap-client=<client>
An additional remark:
It's possible to get the following error message when trying to send a message from CPI to a SAP ECC backend using the XI receiver adapter:
org.apache.cxf.transport.http.HTTPException: HTTP response '403: Forbidden' when communicating with http://<host>:<port>/sap/xi/engine?type=receiver&sap-client=<client>
In that case you might need to check your access control table in your local SAP Cloud Connector settings. Check SAP note 2473005 and the SAP help page (section 'Limiting the Accessible Services for HTTP(S)') for further information.
Hi Mandy,
Thanks for your blog. I was just wondering if it is planned to support EOIO as well.
Cheers,
Tobias
This requirement is known, but it is currently not on the near or midterm masterplan. Only on the long-term planning
Best regards,
Mandy
Thanks Mandy
Hi,
Is it possible to filter communication on Cloud Connector limiting it only to specific Service Interface?
So far I see that we can only specify full path /sap/xi/ that allows to route communication via Cloud Connector to all ABAP Proxies on the backend.
BR,
Piotr
Hello,
no, this is not possible. Simply because the Cloud Connector is not aware of the XI protocol, it only knows the /sap/xi path. What exactly is the use case you want to achieve? Maybe you can do some specific handling in the Cloud Integration designer and model different channels?
BR,
Mandy
I don't want to expose all possible ABAP Proxies on the backend with this one simple entry.
As you mentioned I will implement this handling/filtering in the iFlow.
Thanks,
Piotr
Hello Mandy,
Thanks for the blog. Much awaited feature. My question is, how the JMS queues are linked to an XI receiver or sender channel? Is is it a static linkage? Or dynamic at runtime? Is it safe to assume that at any time a max of 30 XI receiver/sender channel message will be handled, rather than a tenant supports only 30 XI channels in its entirety?
Thanks,
VJ.
Hello,
a JMS channel for an XI EO sender or receiver channel is generated as soon as the integration flow gets deployed. As static queue name is generated for this specific queue. The queue name consists of the participant name, the channel name and an unique ID to make sure this queue is only bound exactly to this channel. This means there is no dynamic linkage, there is exactly one queue per XI EO sender or receiver channel. You may also check this in the queue monitor (also see the screen shot above in the blog).
Regarding you point about the number of channels: with the enterprise license you can use 30 queues as a initial limit. This means you can use 30 JMS queues in total, independently if those are queues generated from XI adapter, or AS2 adapter or JMS adapter - 30 in total. In future (probably starting January) there is an upsell option available to buy additional JMS resources and also to add JMS on top of a normal PI edition. As soon as this is available it will be mentioned in the blog about JMS limits and size restrictions.
But coming back to your question: If you have only XI channels with EO and do not use AS2 or JMS adapter integration flows in the tenant this means you can have a maximum of 30 XI EO channels, not more. And if you also use JMS or AS2 adapter in addition, which generate JMS queues, this reduces the number of XI EO channels. So, if you require more JMS queues you need to buy more of the limited JMS resources.
I hope this helped to clarify.
Best regards,
Mandy
Mandy Krimmel - Is there any road-map to bring equivalent back-end integration add-on for the building of proxies by eliminating the dependence on service interfaces of ESR component from PI/PO when SCPI is the standalone middle-ware in the integration landscape?
We are currently evaluating options for this, but it is not yet on the near-future road map to support this in Cloud Platform Integration. For the time being you need to use ESR.
Best regards,
Mandy
Hi Mandy Krimmel
Hope you're doing well right now. Just curious, if there are any updates in the road map to handle proxies from CPI by eliminating PO ESR for migration strategy. Also need to know if exists, any SAP recommendations for migrating PO proxies to CPI by reusing existing ABAP logic like below -
Thanks in advance.
Chandan
There are currently workstreams discussing about different options how to offer something like ESR in CPI, but there are no fixed timelines available.
Best regards,
Mandy
Hi, see my answer below in this blog.
Hi Mandy,
Could you please confirm that we need an instance of PI/PO connected to ECC/S4H to be able to create the Service Interface in the PI ESR and generate the Inbound Proxy in SPROXY after?
Thanks,
Hello Bruno,
this is correct. At the moment there is no option yet available in CPI to generate proxies for SPROXY. This is planned for the future, but there are no timelines available yet.
Regards,
Mandy
Hi Bruno,
As far as I know it should also be possible to create a Proxy form a WSDL. You would just have to create that one by yourself and then use it in SPROXY to generate the Service Provider or Service Consumer object.
I just tried this but get an error all the times (“Exception occurred in library handler”). But that’s another story. See some hints here: https://wiki.scn.sap.com/wiki/display/ABAPConn/Generation+of+Consumer+Proxy+fails
Philippe
Hi Mandy Krimmel
We have an existing ECC PROXY scenario through PI. Now the ECC is getting lifted and shifted to Employee Central Payroll(ECP), which needs to be connected through SAP CPI. we are planning to reuse the existing SPROXY details for the connection between CPI and ECP. Can you please guide me the steps to follow to lift-and-shift SPROXY.
Thanks,
Poushali Bhandari
Hello,
if you want to show interfaces from CPI in SPROXY as you are used to for PI/PO, this is not (yet) possible. CPI cannot be connected to SPROXY as CPI does not (yet) offer a central repository for interfaces like the ESR.
Does this answer your question?
BR,
Mandy
Hi Mandy,
Thanks for the very detailed blog.
I have followed this and able to send a successful message from CPI to ECC system.
Is there any way to cancel the retry message/delete it?
I have 2 messages which are in retry mode for 2 days and they are not required anymore.
Also, can we have generic XI Sender/Receiver channel in CPI like in PI/PO?
Regards,
Pavan
Hi Pavan,
to cancel a message simply delete it from Data Store/JMS Queue. In future the message will then get the status CANCELLED. At the moment the message stays in RETRY, even if the message is removed, but as said, this will change shortly.
Concerning generic XI Sender see following blog: https://blogs.sap.com/2018/12/04/cloud-integration-configuring-scenario-with-xi-sender-handling-multiple-interfaces/
Best regards,
Mandy
Thanks a lot, Mandy,
I have deleted the messages from the Data Store.
I will definitely try the generic XI Sender in CPI to handle multiple interfaces.
Best Regards,
Pavan
Hi Mandy,
I really appreciate all of your CPI blogs. They are very detailed and have been extremely helpful.
We have an ECC-PI environment, and are moving to an S/4-CPI environment, and would like to reuse some of the proxies we've created through PI. Is it possible to do this without the use of an SLD? Is there any option to determine a business system name without the use of an SLD?
Regards
Hello Dan,
the Business System Name is required by the local XI proxy runtime in the Business System. This name comes from SLD and is then stored in a SLD cache table. The XI runtime reads it from there when sending a message via the XI runtime.
Some applications have reports to directly fill this cache table, then the processing would work without SLD, but usually the local XI runtime requires the SLD for message processing.
Best regards,
Mandy
Hello,
The PI colleagues in the meantime provide a report to set the business system without SLD: https://launchpad.support.sap.com/#/notes/2924308
Best regards,
Mandy
Hi Mandy,
Is there any way to automatically delete the temporary DataStore messages created by an XI adapter. seems default retention is 90 days.
I tried to perform a delete operation by providing SenderComponent_Adapter as Datastore name in separate flow. But this din worked.
Regards
You are right, as this is a very specific data store it can neither be accessed by othe flows, nor messages can be deleted using another integration flow. You may delete the messages in the data store monitor.
BR,
Mandy
Hi Mandy,
Thanks for quick response!
We have 500+ messages in temporary datastore. I know we have this option to multi select mode and manually delete the messages in manage datastore.
Business requirement is to automatically delete the temp DS after every 5 mins, as we would do 3 retries in an interval of 1 min and post which these messages are no longer needed to be retained.
Is there any plan to get any updates in future to set the retain until property or way to access/perform any operation on the temp datastore or feature in the XI adapter.
Regards,
Priya
Hello Priya,
I take this as feature request, we will try to offer a configuration option in the XI adapter short-term (2-3 months), should not be too much effort 🙂
Best regards,
Mandy
Thanks for the consideration Mandy 🙂
Appreciate your help!!
Regards,
Priya
Hello Mandy,
I have followed your blog to configure the receiver proxy But I am getting below error in the monitor.
org.apache.cxf.interceptor.Fault: Could not send Message., cause: java.net.UnknownHostException:
Using cloud connector I am able to post a message in S4 but when I am using the internet then I am getting the above error.
I tried to check the connection using connectivity tests but getting UnknownHostException: error. I have imported the CPI certificate in Strust.
Looks like this system is not reachable from internet. Either the firewall needs to be opened or you have to stick to Cloud Connector.
BR,
Mandy
Hi @ Mandy Krimmel,
Thanks for the detailed article.
However, I have queries -->
BR,
Rashmi
Hello Rashmi,
1.XI adapter is used to call a receiver system via XI protocol. So, usually it will be an XI proxy. What else do you expect?
2.what do you mean by this?
3. You need to specify the identifiers as expected by the receiver system. There are no fix values.
4. The location ID is specified in the Cloud Connector when creating the connection to the subaccount: https://help.sap.com/viewer/cca91383641e40ffbe03bdc78f00f681/Cloud/en-US/db9170a7d97610148537d5a84bf79ba2.html#loiodb9170a7d97610148537d5a84bf79ba2__establish_cloud_conection
BR
Mandy
Hi Mandy Krimmel
I have followed all the steps provided in this blog. Message is in completed status and at the same, data store message is in waiting status. There is no message processed to backend system as well(not able to find in sxmb_moni). Kindly guide to solve this issue.
Thanks in advance!!!
Regards,
Sindhuja.
Hello,
as written in the blog there should be two messages in the monitoring, no only one. One for storing the message to the data store and one for reading it out and sending the message to the receiver.
Maybe the second is still in process?
BR
Mandy
Thanks Mandy for the response!!
We found that, in web dispatcher level, there were restriction of access handler, because of which, the message did not reach backend even though there is no failed message notification in CPI end and datastore data was in retry status. Now it has been handled at web dispatcher. And message processed successfully.
Regards,
Sindhuja.
Hello Mandy Krimmel , thanks for the very detailed blog and explanations. Do you know if it's possible to add the CPI message ID to be visible in SAP without needing to enhance the message or add an attachments?
Hello,
usually the Cloud Integration message ID is transferred in the XI Main SOAP Header, did you check this in the backend in the PI monitoring?
Best regards
Mandy
Hi Mandy,
as the end of support deadline for PO will be 2027 we are actually considering a strategy how we should migrate ABAP proxy interfaces to CPI / integration suite.
Thereby the question has been raised whether SAP's long-term plans aim to support XI adapter when PO doesn't exist anymore or not.
More precisely, in case of asynchronous (incl. exactly-once / retry) SAP ECC / S4 sender integration scenarios we would like to know if it is more sustainable to migrate them to CPI's SOAP sender adapter with SAP RM protocol (because also SAP RM adapter will support exactly-once from Q4/2022) or continue with XI sender adapter.
What is the communication setup between S/4 and integration suite using XI adapter without PO (ESR)?
Best Regards,
Tobias Miller
Hello Tobias,
mid- to long-term SAP will offer all options that are currently available in PO also in Cloud Integration. But this will need some more time. XI Adapter is already available, still not with full feature set as in PO, but will be extended step by step based on priority of the missing features.
Currently SAP works on enabling data types and message types from ESR in cloud integration as a first increment into the ESR topic. this will continue in the next months.
Best regards
Mandy
Hi Mandy,
thank you for your quick reply. Do I understand correctly that in the final stage cloud integration will have its own ESR or similar repository for maintenance of ABAP proxy interface design objects and an S/4 system will be able to connect to that repository in order to generate ABAP consumer stubs (like you generating it today when connecting from ECC/S/4 to PO via transaction SPROXY or SE80 -> ESR browser)?
Further more I would like to know which of the missing XI features / your listed limitations do you mean for which SAP already knows today to put on the roadmap? Especially a status update about the following currently not supported features would be helpful for us as a decision base for our migration strategy:
Best Regards,
Tobias Miller
Hello Tobias,
yes, we work on the extension of the Cloud Integration Suite to enable the ESR centric features in Cloud integration.
You rightly mention two of the missing XI features, that will have to be offered. Let me add acknowledgements and WS security.
Unfortunately I cannot commit on any specific timeline, we are constantly extending the Integration Suite, the big parts at the moment are the migration tooling and the on-premise runtime. Afterwards more capacity will go into missing features.
To increase the priority on missing features I would suggest to open requests for them in the influence program or vote if already existing. SAP will pick the missing features based on the pull.
Best regards
Mandy
Hi Mandy,
thanks a lot for your fast reply again. Your statements give us planning security that we know that the XI adapter will still play a relevant role after PO and its ESR will be decommissioned.
Best Regards,
Tobias Miller