How do retries work in SAP CPI, and when should I use JMS or Data Store?
Retries in SAP CPI work by persisting a message and processing it again after a failure. JMS queues give automatic, continuous retry with configurable intervals and exponential backoff, which suits high-volume asynchronous flows. Data Store gives controlled, scheduled reprocessing of held payloads. Either way, cap attempts, dead-letter the rest and make receivers idempotent.
Cloud Integration does not retry a failed message on its own unless the flow, or the sender, persists it. With a JMS queue between receipt and delivery, a failure returns the message to the queue and the JMS sender adapter retries it. Its settings control the retry interval, whether exponential backoff doubles the wait after each failure, and a maximum retry interval, which SAP defaults to 60 minutes.
| Need | Choose |
|---|---|
| Continuous asynchronous flow that must survive outages | JMS queue |
| Scheduled or manual reprocessing of held payloads | Data Store |
| Strict ordering | JMS with exclusive access, or sequence handling in the receiver |
| Synchronous request-reply | Neither: return an error to the caller |
Unlimited retry is an anti-pattern. Read the SAPJMSRetries header to stop after a sensible number of attempts, move the message to a dead-letter path, and alert on it. Because retried messages can be delivered more than once, the receiver must detect duplicates. See JMS vs Data Store for the decision table and the full retry guide for worked examples.
Related questions
See what Spanovix would fix in your landscape
Bring your hardest interfaces. In a short working session we show where the agents cut failures, manual work and risk for your teams.