SAP CPI JMS vs Data Store
Use JMS queues when an asynchronous flow must survive outages with automatic, continuous retry and exponential backoff.
Use JMS queues when an asynchronous flow must survive outages with automatic, continuous retry and exponential backoff. Use Data Store when you need to hold payloads for controlled, scheduled or manual reprocessing, or to look entries up later. Many robust designs combine them: JMS for reliable delivery, Data Store for parking and replay.
How do JMS and Data Store compare?
Quick answer: JMS is a message queue built for continuous, automatic redelivery; Data Store is a persistent store built for holding entries until a flow deliberately fetches them.
| Criterion | JMS queue | Data Store |
|---|---|---|
| Primary purpose | Reliable asynchronous delivery | Holding payloads for later processing or lookup |
| Retry model | Automatic, driven by the JMS sender adapter | Controlled: a scheduled or triggered flow reads entries |
| Backoff | Retry interval, exponential backoff, maximum interval (default 60 minutes) | You design the schedule |
| Ordering | Exclusive access available on the JMS sender | Not a queue; ordering is up to your design |
| Lifetime | Until consumed or dead-lettered | Expiration period, default 30 days, up to 180 |
| Visibility | Manage Message Queues monitor | Manage Data Stores monitor, alert on unfetched entries |
| Best fit | High-volume, near-real-time asynchronous flows | Batch reprocessing, parking, replay, correlation lookups |
When should I choose JMS?
Quick answer: choose JMS when the message must keep flowing to its target as soon as the target recovers, without anyone intervening.
- Asynchronous interfaces such as orders, invoices or master-data updates that must survive target outages.
- Flows where you want platform-managed retry with exponential backoff rather than custom scheduling.
- Scenarios that need ordered processing, using exclusive access on the JMS sender.
- Decoupling a fast inbound step from a slower outbound call.
JMS queues are a tenant resource, so name them consistently and share them only by design.
When should I choose Data Store?
Quick answer: choose Data Store when reprocessing should happen on your terms, on a schedule, after a fix, or after a business check.
- Permanent-error parking: hold a message that failed validation until the data is corrected, then replay it.
- Scheduled batch reprocessing, for example every hour outside peak load.
- Correlation and lookups, where a later flow needs an earlier payload by a key.
- Cases where an operator must decide whether a message is reprocessed at all.
Set the expiration period longer than your realistic recovery window, and use the retention threshold for alerting so forgotten entries are flagged.
Can I use JMS and Data Store together?
Quick answer: yes, and it is often the most robust design.
A common pattern sends every message through a JMS queue for automatic retry of transient errors. When the exception subprocess classifies an error as permanent, or SAPJMSRetries passes your limit, the flow writes the payload and its error context to a Data Store and ends with a clear failed status and an alert. After the cause is fixed, a reprocessing flow replays the parked entries. Transient problems heal themselves; permanent ones wait safely for a human.
What mistakes should I avoid?
- Retrying permanent errors: a mapping failure fails identically every time.
- Unlimited retry without backoff, which hammers a recovering target.
- Using either option for synchronous calls where a caller is waiting for an answer.
- Forgetting idempotency: both patterns can deliver a message more than once.
For full configuration detail, read SAP CPI retry: JMS vs Data Store.
Key takeaways
- JMS is the default for continuous asynchronous retry with backoff.
- Data Store suits held payloads and scheduled or manual reprocessing.
- Cap retries, dead-letter the rest and make every receiver idempotent.
Questions
Is JMS or Data Store better for retry in SAP CPI?
For continuous asynchronous delivery, JMS is usually better because the JMS sender adapter retries automatically with configurable backoff. Data Store is better when reprocessing should be scheduled, controlled or manual.
How long does a Data Store entry live?
Until its expiration period, which defaults to 30 days and can be set up to 180 days. You can also alert if an entry is not fetched within a retention threshold.
Does JMS retry forever?
Ordinary processing errors keep retrying under your retry settings unless you model a limit, typically by checking the SAPJMSRetries header and ending the message after a threshold.
Related reading
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.