“Redelivery Delay Support Required” Error When Using Delayed Redelivery with Try-Me and SAP Integration Suite (CPI JMS Consumer)

Solace Event Broker
1

Hi Team,

I am working with SAP Integration Suite (Cloud Integration – CPI) as a JMS consumer and Solace PubSub+ Advanced Event Mesh (Cloud) as the broker.

I created a durable queue and configured the following settings.

Environment:

  • Broker: Solace PubSub+ (Advanced Event Mesh – Cloud)

  • Protocol: JMS

  • Queue Type: Durable, Exclusive

  • Consumer Type:

    • Try-Me (for testing)

    • SAP CPI IFlow using JMS adapter

  • DMQ: Disabled

  • Redelivery: Enabled

  • Delayed Redelivery: Enabled

Issue:

After enabling Delayed Redelivery on the queue, when I try to consume messages using:

  1. Try-Me

  2. SAP CPI IFlow (JMS Receiver Adapter)

I receive the following error:

“Redelivery delay support required”

Because of this error, the consumer is not able to process messages.

My Requirement:

  1. Messages should retry infinite times if processing fails.

  2. Messages should NOT move to DMQ (DMQ is disabled intentionally).

  3. If the consumer is OFF, messages should remain in the queue.

  4. When the consumer comes back online:

    • All pending messages should be processed

    • Failed messages should retry automatically

    • Retry should follow exponential backoff

Questions:

  1. Does enabling Delayed Redelivery require special support from the JMS client?

  2. Does SAP CPI JMS adapter support broker-side delayed redelivery?

  3. Is Try-Me tool compatible with delayed redelivery?

  4. If CPI does not support this feature, what is the recommended way to implement:

    • Infinite retry

    • No DMQ usage

    • Exponential backoff

  5. Should exponential retry be implemented at:

    • Broker level?

    • Or inside CPI (using Exception Subprocess + Timer)?

What I Tried:

  • Enabled redelivery

  • Disabled DMQ

  • Set max redelivery count

  • Enabled delayed redelivery

  • Tested via Try-Me

  • Tested via CPI IFlow JMS adapter

Still facing the same error.

Could someone please guide me on the correct approach to achieve this requirement with SAP Integration Suite and Solace AEM?

Thanks in advance.

image
image1579×850 74.5 KB

2

Hi there, I’m Solly AI, I generate responses to your questions using the power of the Solace Agent Mesh:

Please remember that AI technology can make mistakes so ensure that you read our Disclaimer.

AI Generated responses are a work in progress, your help in evaluating my response would be awesome! If my response makes sense, please mark it as a solution or give a :+1:. If my response doesn’t make sense for your topic, please react to it with a :shaking_face:.

Based on the documentation provided, I can explain how to implement delayed redelivery with exponential backoff for JMS messages in Solace Cloud when using SAP Integration Suite (CPI) as the consumer.

The delayed redelivery feature with exponential backoff is supported in Solace Event Broker (formerly called PubSub+ Event Broker) and can be configured on queues and topic endpoints. Here’s what you need to know:

  1. Feature Overview:

    • Delayed redelivery helps applications recover from temporary processing failures
    • It uses a timer and is triggered by client-initiated transaction rollbacks
    • Supports exponential backoff through a configurable multiplier
    • Configuration is done entirely on the event broker side

  2. Key Configuration Parameters:

    • Initial interval: First delay between delivery attempts (default 1000ms)
    • Maximum interval: Maximum delay between attempts (default 64000ms)
    • Multiplier: Factor for exponential backoff (default 2.00, range 1.00-5.00)

  3. Important Considerations:

    • This is a Controlled Availability (CA) feature that requires special enablement
    • Configuration must be done when no clients are connected to the queue
    • The feature works with local transactions
    • Not supported in C API, JavaScript API, or Node.js API

  4. Behavior:

    • When a transaction is rolled back, message delivery is suspended
    • The delay increases exponentially between retry attempts
    • The consumer flow is blocked during the delay period
    • Delivery resumes after the delay timer expires

For the specific configuration steps and detailed documentation, please refer to:

Note: Since this is a broker-side configuration, you cannot modify these settings through the API. The configuration must be done through the broker’s administration interface when the queue is not in use.