Publish once, consume many: pub/sub with Boomi Event Streams

A new order in the e-shop has to reach three places: the warehouse system, so the goods can be picked; the ERP, so the invoice can be issued; and the CRM, so sales can see what the customer bought. This article explains why the straightforward way of doing that becomes fragile, describes the publish/subscribe pattern that replaces it, and then builds it with Boomi Event Streams and Boomi Integration.

The problem with one process that calls everyone

The first version usually looks like this:

e-shop ──► integration process ──► warehouse ──► ERP (invoice) ──► CRM

It is easy to build and it works on day one. Then reality arrives:

• One slow system slows everything. If the CRM takes eight seconds to answer, every order takes eight seconds longer.
• One failure stops everything. If the ERP is in its nightly backup, the warehouse doesn’t get the order either, even though it is running fine.
• Partial success is hard to undo. The warehouse got the order, invoicing failed, the CRM was never called. Rerunning the whole process creates a duplicate pick.
• Every new consumer means changing the producer. Adding the loyalty programme means editing and retesting the one process everybody depends on.

The pattern: publish once, subscribe independently

With publish/subscribe, the integration that receives the order does one thing: it publishes an order.created event to a topic. Each interested system has its own subscription on that topic and its own consumer process.

                          ┌─► subscription: warehouse ──► warehouse process ──► WMS
e-shop ──► producer ──► topic: orders.created ──► subscription: invoicing ──► invoicing process ──► ERP
                          └─► subscription: crm ──► CRM process ──► CRM

Each subscription receives its own copy of every event and keeps its own position. If the CRM is down for an hour, its subscription builds up a backlog while the warehouse and invoicing carry on. When the CRM is back, its consumer catches up. Adding the loyalty programme later is a new subscription and a new process, with no change to the producer.

Two rules make this safe:

• Consumers must be idempotent. Delivery is at least once, so the invoicing process must recognise an order it has already invoiced.
• The event is a fact, not an instruction. order.created says what happened. Each consumer decides what it means for its own system.

Building it with Boomi Event Streams

Boomi Event Streams is the managed event broker in the Boomi platform, built on Apache Pulsar. You manage topics and subscriptions in the Event Streams service, and Boomi Integration processes produce and consume events through the Boomi Event Streams connector. The exact menu labels and operation options can change between releases, so use the steps below as a guide to the order of work and check the current documentation for field names.

Step 1: Design the event

Agree on the event format before building anything. Keep it small but self-sufficient, and include an event ID for idempotency:

{
  "eventId": "7f1c2e9a-4b1d-4c55-9a51-2d1f0b7c9e10",
  "type": "order.created",
  "version": 1,
  "occurredAt": "2026-10-23T09:14:02Z",
  "orderId": "58213",
  "customerId": "C-1042",
  "currency": "EUR",
  "total": 184.50,
  "shipTo": { "city": "Thessaloniki", "postalCode": "54625" },
  "lines": [
    { "sku": "OL-500", "description": "Olive oil 500 ml", "qty": 2, "unitPrice": 8.90 },
    { "sku": "HN-250", "description": "Thyme honey 250 g", "qty": 3, "unitPrice": 6.50 }
  ]
}

Create a JSON profile for it in Boomi. Producer and consumers will all use the same profile, which keeps the contract in one place.

Step 2: Create the topic and subscriptions

1. In Event Streams, choose the environment (for example test) and create a topic named orders.created.
2. Create one subscription per consuming system: warehouse, invoicing and crm. Name them after the consumer, not after the process, so they stay meaningful when processes are refactored.
3. Generate an access token for the environment with permission to produce and consume. You will use it in the connector’s connection. Treat it as a secret and store it only in the connection component.

Depending on your release, subscriptions may also be created automatically the first time a consumer connects with a new subscription name. Creating them explicitly is clearer and means events are retained for that subscription from the moment it exists.

Step 3: Build the producer process

1. Start the process where the order arrives. If the e-shop sends a webhook, use a Web Services Server listener; if you poll the e-shop’s API, use a scheduled process with the e-shop connector or the HTTP Client connector.
2. Use a Map shape to turn the e-shop’s order into your order.created profile. Generate the eventId here (or use a stable ID from the source, which makes duplicates from retries easier to detect).
3. Add a Connector shape with the Boomi Event Streams connector, a connection that uses your token, and an operation with the Produce action pointed at the orders.created topic.
4. If the order has a natural key, such as the order number, set it as the message key where the operation allows it. Events with the same key can then be kept in order for consumers that need it.

The producer is now finished, and it will not need to change when consumers are added.

Step 4: Build one consumer process per system

Each consumer is a separate process that starts with the Event Streams connector in listen mode:

1. Create a process whose Start shape uses the Boomi Event Streams connector with a listen (consume) operation on the orders.created topic and the subscription for that system, for example invoicing.
2. Check idempotency first. For invoicing, look up the web order number in the ERP (or in a small table of processed event IDs). If the order already exists, end the path without doing anything.
3. Map the event to what the target expects: a sales document in the ERP, a pick request in the warehouse system, an activity or order record in the CRM.
4. Call the target with its connector.
5. Wrap the target call in a Try/Catch shape so failures are handled deliberately. What to do with failures is the subject of our article on dead-letter topics.

Repeat for warehouse and crm. The three processes share the event profile and nothing else.

Step 5: Deploy and test

1. Deploy the producer and the three consumers to the runtime for the environment. Listener processes only receive events while they are deployed and their listeners are running.
2. Send one test order through the e-shop (or post the sample JSON to the producer).
3. In Event Streams, check the topic: one message in, and each subscription’s backlog going back to zero.
4. In Process Reporting, you should see one producer execution and three consumer executions.

Then test the interesting cases:

• Stop one consumer (for example, stop the CRM listener), send a few orders and watch the crm subscription’s backlog grow while warehouse and invoicing keep working. Restart it and watch it catch up.
• Send the same event twice and check that the ERP has one sales order, not two.

Before you go live

• One subscription per system, not per process version. If you rename a subscription, the new one starts empty and the old one keeps accumulating events nobody reads.
• Watch backlogs. A growing backlog on a subscription is the earliest sign a consumer is stuck. Alert on it.
• Separate environments. Use different Event Streams environments and tokens for test and production, so a test order never reaches the production warehouse.
• Version the event. Add fields freely; for breaking changes, publish a new version or topic and migrate consumers one at a time. A shared canonical model helps here (see A canonical data model in Boomi).
• Plan for poison messages before the first one arrives.

Summary

Publishing one order.created event and letting each system subscribe independently turns a fragile chain into a set of small processes that fail and recover on their own. In Boomi, Event Streams holds the topic and subscriptions, and each consumer is a normal integration process with its own connector logic. For the concepts behind this, including when events are not the right tool, see our guide Event-driven integration: what it is and when you need it.