Skip to Content
Technical Articles

SAP CPI – Retry Send Failed Asynchronous Messages Based On Time Interval

In this Blog let’s discuss how we can resend failed messages automatically 3 times with 5 minutes interval like in PI/PO and then generate an error or success alert emails

You can set iterations count like 3 times or 5 times and interval time of 5 minutes or 10 minutes accordingly your requirements

 

Part 1: The Main Integration Process

 

Example : Lets take a scenario IDOC to HTTP (asynchronous)

 

You can develop IDOC to HTTP iflow as you need as per the requirements however few changes needs to be done to the iflow to make sure we capture the required payload (After Map XML) which needs to be reprocessed by retry iflow

Our goal is to make sure we capture only successful After Map XML and reprocess only final payload to final URL

 

 

  • Set Below Properties in content modifier only after mapping step and externalize if needed as shown below

 

 

  • Set Routing Condition in exception sub process as shown below, this routing condition will act like start/stop feature to enable retry send failed messages option

 

 

  •  Process Call “Save AfterMap XML to DB Store  For Entry”
  • To make sure we are retrying to send only after map xml we are setting routing condition as shown below, default is to generate error email directly which is another process call in iflow

 

 

 

  • Script to set message GUID as header

 

  • Set AfterMap XML Body

 

 

  • Write DB Store using Header Message Guid, select overwrite existing message

 

Final Step Important which  be later used in the actual retry iflow is to externalize the final receiver URL with name ” Final_EndPoint_URL ”

 

Part 2: The Retry Custom Iflow

 

This iflow  reads the message from iflow 1 written message in database store for every 5 minutes as per timer and if the message is successfully delivered to final endpoint maintained in retry iflow itself it sends a success delivered email and if unable to deliver the message counter script will count the iterations and write it to a new DB store with name as counter and after 3 iterations it will delete all records from database store and send error alert email

you can download iflow from the google drive link below and upload to your CPI tenant

Make sure you configure the externalized parameters as needed for all adapters/channels

You can add as many receivers you wanted based on routing conditions

this is developed based in my requirements and you can enhance it accordingly your needs

You can set counter datastore values local or global

 

Ex: File to IDOC scenario and you have set receiver name as SAP and by default receiver name is SAP_IDOC as “IDOC” is added automatically based on adapter used, so based on this you can set receiver routing condition as “SAP_IDOC” so that all IDOC related messages are going to one receiver

Ex: IDOC to SOAP If you have 10 soap receiver Iflows you can still manage with one receiver as URL is automatically extracted based on message GUID of the original message from sap business hub (Integration content Configuration API) and set it to header “CamelDestinationOverrideUrl” which will over write your dummy URL you set in soap channel in retry iflow

Note: Original message details including Receiver are fetched automatically based on message guid from “message processing logs” of ODATA service (https://${header.TenantID}-tmn.hci.us3.hana.ondemand.com/api/v1/)

 

 

IFLOW Download Link

https://drive.google.com/open?id=1kMifQ1kboceqKGSaD6zDKBIUC2kq2x-2

 

 

 

Reference documents

https://blogs.sap.com/2016/05/11/exactly-once-in-sap-hana-cloud-integration/

https://blogs.sap.com/2016/11/02/dynamic-address-in-the-soap-receiver-adapter-of-hana-cloud-platform-integration-services/

https://blogs.sap.com/2016/12/28/sap-hcp-ishci-dynamically-configure-the-address-field-of-the-http-adapter/

 

 

 

 

1 Comment
You must be Logged on to comment or reply to a post.
  • Thank you for sharing this with the community! This will hopefully help clients work around the JMS queues / Enterprise License need. Did you see any inconsistency or issues with the Data Stores, for maybe high volume/frequency interfaces using this approach?