Boomi teams now have more messaging options than ever, and the platform has made its own preference clear: Atom Queues became a legacy feature in September 2025, Event Streams is the strategic service, and connectors for Azure Service Bus, MQTT and Kafka cover the brokers you already run. This guide helps you choose between them, plan a move away from Atom Queues without a big-bang migration, and configure the connectors for production.
What changed for Atom Queues
In the September 2025 release Boomi designated Atom Queues as a legacy feature. The details matter, because they are often misread:
- Atom Queues remain fully functional and supported for existing accounts.
- They no longer receive enhancements or optimizations, except critical security fixes.
- They are not available to new customers.
- They are not deprecated, there is no retirement date, and you are not required to convert existing processes to Event Streams.
At the same time Boomi added cloud attachment quotas so runtime cloud owners can govern Atom Queue usage, such as a commit batch limit and a message throttle rate. On Boomi-hosted public clouds, Atom Queue rate limiting has applied since 2024.
The practical conclusion: there is no emergency, but there is a direction. New designs should not start on Atom Queues, and existing ones should move when you touch them anyway.
Event Streams in short
Boomi Event Streams, announced in June 2023, is a message queuing and streaming service hosted and managed within the Boomi platform. The connector and service have matured considerably since:
- Acknowledgement control – an Acknowledgment operation (May 2025) and “Consume with Ack Later” container properties (July 2025) give you explicit control over when a message is considered processed.
- Concurrency – the maximum number of concurrent executions in Transacted Acknowledged mode is configurable through the container property
com.boomi.container.eventStreams.maxConcurrentExecutions. - Ordering – since September 2025 the connector enforces strict first-in-first-out processing with infinite retries and exponential backoff, so a failing message is not skipped.
- Operability – message management in the UI and a Backlog Size metric in the UI and the Event Streams Admin API.
- Platform events – since May 2026, Event Notifications can stream platform activity such as runtime and process status to Event Streams topics.
Strict FIFO with infinite retry has a consequence you must design for: a poison message blocks the messages behind it. Validate early, and route documents that can never succeed to an explicit exception topic instead of letting them retry forever.
Choosing a messaging option
| Option | Strength | Choose it when | Watch out for |
|---|---|---|---|
| Event Streams | Managed by Boomi, native connector, no extra infrastructure | Boomi-to-Boomi decoupling and event distribution inside your integration platform | Region availability and poison-message handling with strict FIFO |
| Atom Queues | Simple, local to the runtime | Only for existing processes you are not touching | Legacy status; no new investment |
| Azure Service Bus | Sessions, dead-lettering, scheduling, shared with Azure workloads | Boomi and Azure services exchange messages, or the broker is a shared enterprise asset | Entity design and identity per consumer |
| MQTT | Lightweight publish/subscribe for devices | IoT and OT data from sensors and gateways | Quality-of-service levels and broker security |
| Kafka | High-throughput event streaming and replay | Kafka is already the enterprise event backbone | Listener health and TLS configuration |
For Kafka specifically, see Boomi Kafka Connector 26.09.1: listener health, TLS and production readiness.
Moving off Atom Queues without a big bang
- Inventory every process that publishes to or listens on an Atom Queue, and record volumes and ordering assumptions.
- Classify each queue: simple work queue, publish/subscribe fan-out, or ordered stream. The classification decides the topic and subscription design in Event Streams.
- Dual-publish where possible: the producer publishes to both the Atom Queue and an Event Streams topic while a new consumer is tested. Boomi Marketplace has a recipe that demonstrates sending messages to both.
- Cut over consumers one at a time, compare counts, then stop publishing to the Atom Queue.
- Retire the Atom Queue listener and remove the queue configuration.
Make consumers idempotent before you start. During a dual-publish period duplicates are a feature, not a bug – see the idempotent receiver pattern.
Azure Service Bus: use the dynamic properties
The Microsoft Azure Service Bus connector version of May 2024 added five dynamic operation properties – CorrelationId, ReplyTo, To, ScheduledEnqueueTimeUtc and ReplyToSessionId – and made the existing operation properties dynamic as well. The former “Allow Entity Type Override” option is now “Allow Dynamic Entity Types”.
That enables patterns that used to require separate operations per destination:
- Request-reply with
ReplyTo,ReplyToSessionIdandCorrelationIdset per document – see request-reply and correlation IDs across platforms. - Scheduled delivery with
ScheduledEnqueueTimeUtcinstead of a polling process that waits. - Dynamic routing to a queue or topic chosen at runtime, which is useful for multi-tenant designs.
One upgrade note from that release: the Listen operation uses the domain name specified in the connection, and Boomi flagged that this may not be backwards compatible with previous domain names. Check listener connections after connector upgrades.
For ordering and parallelism on Service Bus, see message ordering with sessions and competing consumers.
MQTT: the new connector
In April 2024 Boomi released a new, generally available MQTT connector built on the Connector SDK, with functional parity with the legacy connector plus customer-requested enhancements. The legacy MQTT connector was deprecated at that point and retired on October 12, 2024. If an old process still references it, it is not running. For new MQTT designs, decide quality-of-service levels per topic explicitly and secure the broker connection with TLS and per-client credentials.
Production checklist for messaging in Boomi
- No new designs on Atom Queues; existing queues inventoried with an owner.
- Exception topic or dead-letter path for messages that can never succeed.
- Consumers idempotent, with a business key for duplicate detection.
- Concurrency and acknowledgement mode chosen per consumer, not left at defaults.
- Backlog size monitored and alerted per subscription.
- Connector versions and listener connections checked after each platform release.
0 Comments