Guaranteed delivery in SAP Cloud Integration: JMS retries without endless loops

The problem

A receiver goes down for a few minutes and messages fail. Without a queue they are lost. With a queue but no retry limit, a single bad message can retry forever, filling monitors and hiding real incidents.

The pattern

• Receive the message and write it to a JMS queue immediately, then reply to the sender.
• A second iFlow consumes the queue through the JMS sender adapter and calls the receiver.
• Configure the JMS sender with a retry interval, exponential backoff and a maximum retry interval, so temporary outages recover automatically.
• Read the retry count and stop retrying after a limit you choose.

Reading the retry count

Cloud Integration sets the SAPJMSRetries header on messages consumed from a JMS queue. Store it as a property at the start of the consuming flow:

import com.sap.gateway.ip.core.customdev.util.Message

def Message processData(Message message) {
    def retries = (message.getHeaders().get("SAPJMSRetries") ?: "0") as Integer
    message.setProperty("retryCount", retries)
    return message
}

Add a Router right after it. When ${property.retryCount} > 5, route to an error branch that raises an alert, stores the message for reprocessing (for example in a data store or a separate error queue) and then ends successfully. Ending successfully removes the message from the retry cycle.

Things to get right

• Use an exception subprocess so failures return an error to the JMS adapter and trigger the retry.
• Make receivers idempotent, or pass a unique message ID, because a retry can arrive after a timeout that actually succeeded.
• Watch your JMS queue capacity and message size limits on your tenant.
• Consider the JMS sender’s dead-letter option for messages that repeatedly crash processing.

Result

Temporary outages heal themselves, permanent errors surface quickly as alerts with the original message kept safe, and your queues never fill with messages that will never succeed.