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

Cloud Integration – Configuring Explicit Retry in Exception Sub-Process for XI Adapter Scenarios

This blog describes how to configure explicit retries when using the new XI adapter, which will be available for customers with the 02-September-2018 release. It describes the configuration options in a sample scenario.

Configuring Explicit Retry in Exception Subprocess for a Scenario Using the XI Adapter with Exactly Once Option

Using the XI sender and receiver adapter in EO scenarios connecting backends using XI protocol is described in the following two blogs:

XI Receiver Adapter: Configuring Scenario Using the XI Receiver Adapter

XI Sender Adapter: Configuring Scenario Using the XI Sender Adapter

With the basic configuration described in the two blogs, messages in error are retried forever according to the configured retry interval defined in the XI adapter. But there may be scenarios where you want to stop the retries after a defined number of retries and process the message in an alternative way, for example send the message via mail to another receiver. Or you want to notify the tenant administrator after some retries and after some more retries, if the message was still not successful process it in an alternative way.

This is possible after the 02-September-2018 release using explicit retry configuration in an exception subprocess. We will re-use the sample scenario setup in the blog for the XI receiver adapter and extend it using explicit retry configuration. Note, that you have to use the newest version of XI sender and receiver adapter. This means, if you want to extend an existing scenario you have to remove and re-create the XI channel to get the most recent version.

To configure such a scenario we need to add a Local Integration Process with the retry configuration and an Exception Sub-Process that catches the exception and calls the Local Integration Process for the retry handling. The scenario cannot be configured directly in the Exception Sub-Process because there only one end event is allowed, but we need an error and an end event to distinguish between continuing the retry or ending the retry.

Configure Retry Handling in Local Integration Process

First add a Local Integration Process to the integration flow. In this process, you configure the specific retry handling. In this sample, we check the number of retries executed, and after 6 unsuccessful retries, we end the processing and trigger a mail to alert someone about the problem.

These are the steps: In the local integration process, configure a Router after the start event, add an Error End Event and configure the Router. We need to check the header that counts the numbers of retries. This header is different for the two temporary storage options: JMS and Data Store.

  • The header SAPJMSRetries is set by the JMS handler and can be used in case you configure the XI adapter with JMS Queue as temporary storage.
  • The header SAP_DataStoreRetries is set by the data store handler and can be used in case you configure the XI adapter with Data Store as temporary storage.

Configure the router as shown in the pictures. The header is used to decide if the message processing continues or if it ends and a mail is triggered. If message processing is to continue, an error is raised by the process so that the message stays in the JMS Queue or Data Store and goes into retry status.

Configuration for Data Store Option:

Configuration for JMS Queue Option:

Configure Exception Sub-Process to Call the Local Integration Process

Furthermore, you need to add an Exception Subprocess in the main process, and add a Local Process Call, where you select the configured Local Integration Process, within the exception subprocess. Add a Receiver for the mail to be sent. Connect the Message End Event of the exception subprocess to the receiver using a Mail receiver channel. In this channel, you configure the mail address the mail is to be sent to and the details to be sent.

The following picture shows the configuration when an XI receiver adapter is used, but the same configuration can be used with XI sender adapter.

With this configuration, the message will be removed from the JMS queue/data store after 5 unsuccessful retries, so that no further retries are executed. A mail is triggered to notify the appropriate person to take manual action.

If you use the explicit retry configuration, you are free to configure retries as required for your scenario. For example, you can notify someone after 3 retries but not stop the processing until 10 retries have been made, to allow enough time for manual actions. Or, you can send the message after 3 retries via an alternative receiver channel.

Re-Create the XI Receiver Channel

As already mentioned you need the most recent version of the XI adapter to support explicit retry configuration. So, if you are extending an existing scenario, remove and re-create the XI channel. Use the same configuration settings you have used before.

Save and deploy the integration flow.

Run the Scenario

Execute your scenario as described in the blog Configuring Scenario Using the XI Receiver Adapter. To test the error case you may just enter some invalid address in the XI receiver channel. Check that you receive the notification mail and that the message is removed from JMS queue/Data Store.

Assigned Tags

      15 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Alexander Aigner
      Alexander Aigner

      Hello Mandy,

      i am currently working on a scenario where we use EO XI via Send Step. I was able to test the approach above with a message end event as in your example. but when using a Send Step, this seems to not work as it looks like the exception subprocess is never triggered.

      Your sample:

      Here you can see that the error triggers the exception subprocess and the local error handling process. When using the Send Step, this does not work:

      The exception block is never called, thus the local error handling process is never called. This means that the Retry will run forever.

      I have not found any information for this. Is this something that is still not working or do i need to change something in my flow?

      Thanks, Alex

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

      Hello Alex,

      it looks like you found a bug in our generator. Could you please open a ticket on LOD-HCI-PI-CON-SOAP so that the development can fix this?

      Thank you,

      Mandy

      Author's profile photo Alexander Aigner
      Alexander Aigner

      Hello Mandy,

      thanks for the reply, i have opend a ticket with the information.

      BR, Alex

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

      Could you maybe share the ticket number?

      Thank you,

      Mandy

      Author's profile photo Alexander Aigner
      Alexander Aigner

      Hello Mandy,

      here you go: 300737 / 2022

      Best regards, Alex

      Author's profile photo Eniyan Thangaraja
      Eniyan Thangaraja

      Hello Mandy/ Alex,

      We are facing the exact same issue. Did you get any resolution?

       

      Best Regards,

      Eniyan.

      Author's profile photo Alexander Aigner
      Alexander Aigner

      Hello Eniyan,

      we received info on the ticket on 09.05 that the fix is available. Since we solved the request differently, i did not really check it before.

      I just ran my test scenario again and as you commented, it still does not enter the exception subprocess. I have sent an update about this to SAP in above ticket.

      Best regards,
      Alex

      UPDATE: Sorry, i noticed that it stated on 09.05 that the solution will probably be available with the next release. Seems this has not been fixed now

      UPDATE 2: I got this response from SAP

      the fix should be available after your next tenant update. I assume it will happen this weekend. Afterwards you have to redeploy your iFlow.

      Author's profile photo Eniyan Thangaraja
      Eniyan Thangaraja

      Hi Alex,

      Thanks for the response! Appreciate it.

      I will try testing next week then. I will keep you posted here.

       

      Regards,

      Eniyan.

      Author's profile photo J. Evertse
      J. Evertse

      Hi. Any progress on the send exception handling? Is there a sap note?

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

      the issue with the Send step was solved last year already. Do you still have issues with Send step?

      Best regards

      Mandy

      Author's profile photo J. Evertse
      J. Evertse

      Hi Mandy

      We tested it (runtime-profile sap po 7.50 sp23) by forcing a http404 but it created a seperate retry process. And did not go to the exception block in the flow where the send step was used to the XI .

      Regards

      John

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

      Hello John,

      do I get it right that you try to run this flow on a PO system, not in the Cloud tenant?

      maybe there was a miss in the patch for this profile. Could you please create a ticket on LOD-HCI-PI-CON-SOAP and attach the integration flow (download from design time) and the generated flow which you deploy on the PO system. The experts need to have a look at this.

      Thank you

      mandy

      Author's profile photo J. Evertse
      J. Evertse

      Yes that is correct.

      This will also apply to the upcoming Integration Cell.

      Oke will do thanks.

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

      could you share the ticket number here?

      Author's profile photo J Evertse
      J Evertse

      here it is: Case ID: 393924 / 2023