Delivered Is Not Done: Defining AWS Event Handoffs Between Odoo, MES, WMS, and TMS

What an event-driven handoff actually is

In Amazon EventBridge, an event is a JSON object sent to an event bus. Amazon's documentation describes an event, in the context of event-driven architecture, as often an indicator of a change in a resource or environment. For a manufacturer, that translates into business facts such as an order confirmed, a work order released, a quantity received, or a shipment tendered.

EventBridge's role is routing. An event bus is a router that receives events and delivers them to zero or more destinations, called targets. A rule receives incoming events and sends them as appropriate to targets for processing. Rules can match on an event pattern, and a single rule can send an event to up to five targets. The documentation also notes that an event bus can act as a broker between different workloads, services, or systems.

Amazon SQS plays a different role. It holds messages in a queue until a consumer processes them, and its documentation addresses what happens when processing fails or repeats, covered below.

This is the first definition a manufacturer should insist on: the transport layer moves and routes events. It does not know whether the receiving business process finished its work.

What each cross-system handoff needs to define

Before choosing a service, write down the following for every handoff between Odoo and a connected system such as an MES, WMS, or TMS. Which of these systems holds the authoritative record is a design decision for the manufacturer; it varies by environment and should not be assumed.

• The business event. Name it in operating terms, such as "sales order confirmed," not in terms of a database change.
• The authoritative record. Decide which system owns the facts the event describes, so a downstream copy never silently becomes the master.
• The event identifier. Every event needs a stable identifier that survives retries, so the same business fact can be recognized as the same fact.
• The producer and the consumer. Name both, and name the person or team accountable for each side.
• The acknowledgement. Define what the receiver confirms and when. This is where delivery and completion get confused, so it deserves its own paragraph.

An acknowledgement can mean at least three different things: the message arrived, the message was validated, or the business action was completed. A design that treats the first as the third will report success while work sits undone. Decide which acknowledgement the producing side waits for, and which one the business actually cares about.

Delivery, processing, retry, replay, and reconciliation are different things

AWS documentation is explicit that delivery mechanics produce duplicates and repeats, which is why these concepts must be kept apart.

Retry and duplicates. For Amazon SQS FIFO queues, the deduplication process is time-sensitive, and the producer must be aware of the queue's deduplication interval. Specifically, Amazon SQS enforces a 5-minute deduplication window, and a SendMessage request retried after that window is treated as a new message, potentially creating duplicates. On the consuming side, if a consumer fails to process a message before the visibility timeout expires, another consumer may receive and process it, leading to duplicate processing. The documentation suggests that the visibility timeout be adjusted to the application's processing time, and the ChangeMessageVisibility API can extend it while a message is still being processed.

The business consequence is direct. If a retried message can be processed twice, the receiving system must be able to recognize the event identifier it has already handled and avoid applying the same change again. That property is called idempotency. It is a requirement on the consuming system's logic, and a queue setting cannot supply it on its own. For each event, ask whether the receiving Odoo, MES, WMS, or TMS configuration can recognize a repeated event identifier.

Replay. EventBridge supports archiving events and replaying them later from the archive. The documentation describes archiving as useful for testing an application, hydrating a new service when it first comes online, and adding durability to event-driven applications. Replay is a recovery tool, and it raises its own question: if an event is replayed, will the consumer treat it as new work? Without idempotent handling, replay can repeat a business action.

Reconciliation. Neither retry nor replay tells you whether the two systems now agree. Reconciliation is a separate, scheduled comparison of the authoritative record against the downstream copy. It catches the cases where an event was delivered and acknowledged but the resulting state is still wrong. Assign it an owner and a cadence just as you would any other control.

Exceptions need a bounded home and an owner

Some messages will not process. The SQS documentation advises that if a message repeatedly fails to process, it should be routed to a dead-letter queue instead of being reprocessed indefinitely. A dead-letter queue keeps one stuck message from consuming effort forever, but on its own it is only a holding area.

The operating design around it is a management decision, not a queue feature:

• Decide who looks at the exception queue, how often, and how they are alerted.
• Decide what the possible recovery decisions are for a given failed event: correct the data and resubmit, cancel the business action, or escalate to the owner of the authoritative record.
• Bound the queue. An exception list that nobody works becomes a second, hidden backlog.
• Record which customer commitment, order, or shipment each stuck event touches, so an operations manager can judge urgency in business terms rather than technical ones.

Monitoring belongs in this design. AWS's own supply chain architecture examples show Amazon CloudWatch and AWS X-Ray providing monitoring and troubleshooting capabilities, and the same example uses Amazon EventBridge to orchestrate workflows between warehouse management systems. Treat these as examples of how the services are combined, not as a prescribed blueprint for a given plant.

Comparing synchronous, scheduled, and event-driven exchange

Event-driven exchange is one of several patterns, and the right choice differs by handoff rather than by company. The sources reviewed document the event-driven and scheduled mechanisms; they do not rank the three patterns, so the comparison below is a set of questions to answer for each handoff.

• Synchronous interface. The caller waits for an answer. Ask whether the requesting person or system genuinely needs an immediate result, and what happens to the caller when the other system is slow or down. EventBridge can also call external endpoints, since API destinations are HTTP endpoints that can be set as the target of a rule, enabling REST API calls between services, integrated SaaS applications, and applications outside of AWS.
• Scheduled exchange. Data moves at set intervals. This can be reasonable when the business does not need to act on a change immediately. One AWS reference architecture for factory visibility, for example, has ERP, MRP, and HR systems synchronizing to cloud storage nightly using AWS Glue while Amazon Kinesis Data Firehose streams manufacturing and procurement events in near real time. That example shows scheduled and streaming exchange coexisting in one design. EventBridge also supports schedules, though its documentation says scheduled rules are a legacy feature, and EventBridge Scheduler is recommended for invoking targets on a schedule.
• Event-driven exchange. Changes are published as they happen and routed to interested consumers. Ask how much ordering matters, since the documentation notes that deduplication behavior is tied to FIFO queues and that a mobile device sending messages whose order is important can create a duplicate when it retries after regaining connectivity. Ask also about volume, auditability of what was sent, and who will support it after go-live.

For each handoff, compare the three against ordering needs, acceptable delay, expected volume, the audit trail you need, and the support burden your team can carry. Different handoffs in the same company can reasonably land on different answers.

Where MES and shop-floor data fit

Production events deserve a boundary note. AWS guidance describes that traditionally, systems and applications within manufacturing either don't communicate or communicate rigidly based on hierarchy, and presents combining MES data with data from other systems as a way to gain broader operating visibility. For a business-systems integration, the relevant question is what information crosses into Odoo or other business applications, for example a job's status or a quantity completed. How machines are controlled is a specialist matter outside this discussion.

Limits to keep in view

The AWS documentation reviewed here describes service mechanics and reference architectures. It does not establish how any particular Odoo 19 deployment, MES, WMS, or TMS behaves, what acknowledgement each of those products can return, or how fast a given design will perform. Those facts need to be confirmed against the actual products and the manufacturer's own configuration. The AWS reference architectures also illustrate possible combinations of services; they are not evidence that a design suits a particular operation.

A validation sequence for executives

Use this sequence in design reviews before approving integration work. Each item is a question to answer, not a claim about your environment.

1. List the handoffs. For each, name the business event, producer, consumer, and the accountable person on each side.
2. Name the authoritative record for the data each event carries.
3. Define the acknowledgement. Separate "received," "validated," and "completed," and decide which one the business waits on.
4. Confirm event identity. Does every event carry a stable identifier, and can each consumer recognize one it has already handled?
5. Test duplicates on purpose. Ask what happens if the same event arrives twice, including after a retry beyond the queue's deduplication window and after a replay from an archive.
6. Define the exception path. Who owns the dead-letter queue, how are they alerted, what decisions are open to them, and how is the affected order or commitment identified?
7. Plan reconciliation. Decide who will compare the authoritative record with downstream copies, on what cadence, and who resolves any differences found.
8. Choose the pattern per handoff. Compare synchronous, scheduled, and event-driven options on ordering, delay, volume, audit, and support effort.
9. Confirm product facts. Verify against the actual Odoo, MES, WMS, and TMS versions in use what each can send, acknowledge, and de-duplicate.
10. Assign monitoring. Decide who watches delays and failures, and what "late" means in business terms.

A handoff that passes this list gives you something a delivery report cannot: a clear answer to who knows the work is done, and how they know.