Odoo Shopware 6 Connector: Asynchronous synchronization for complex e-commerce systems
The question with an Odoo-Shopware integration is not whether the systems can exchange data. The question is how tightly they are coupled. A synchronous connection makes the availability of the checkout dependent on the ERP's response time. An asynchronous connection decouples the two.
This decision is made once, at the start of the project, and subsequently determines the operational behavior of the entire system. This article describes the asynchronous variant as a reference architecture: event flow, idempotence, error handling, project structure, testing, and deployment.
Why synchronous interfaces are problematic
A direct, blocking query of the ERP system with every customer action—such as a live inventory check at checkout—links the shop's availability to the availability and response time of a second system. If the ERP's response time increases even briefly, the checkout loading time immediately increases as well. If the ERP system fails temporarily, in the worst-case scenario, the entire checkout process comes to a standstill.
Another risk of synchronous architectures: Partial updates. If a multi-stage operation fails in the middle, parts of the data set may have already been written, while others may not have been processed – an inconsistent intermediate state that can go unnoticed without proper error handling.
These risks are not theoretical: Every JSON-2 call against Odoo runs in its own SQL transaction and is committed on success and discarded on failure – however, multiple calls are not automatically chained into a single transaction. Odoo to Shopware 6 Connector, which executes several related Odoo calls, must actively consider this property instead of incorrectly assuming an implicit overall transaction.
Event-Driven Architecture
The robust alternative is an event-driven, asynchronous architecture. When an order is received, the Shopware frontend writes it to a message queue in milliseconds and immediately completes the checkout successfully for the customer. A connector, acting as a consumer, processes the queue in the background and transmits the orders to Odoo via the JSON-2 API. If the transmission fails, the message remains in the queue and is processed again later using exponential backoff.
The basic data flow of the reference architecture:
Shopware 6 → RabbitMQ Message Queue → Connector (Consumer) → Odoo 19 (JSON-2 API) → PostgreSQLThis decoupling – referred to as "loose coupling" in the underlying architectural concept – means, specifically, that Odoo and Shopware know as little about each other as possible and communicate exclusively via standardized middleware. If one of the two systems fails temporarily, the other can continue operating for the decoupled processes; pending messages are buffered and processed later.
RabbitMQ and Symfony Messenger
In the described reference implementation, a RabbitMQ message queue assumes this intermediary role, connected via established patterns: Publisher Confirm (confirmation that a message has safely arrived in the queue), Retry Loops, Dead Letter Exchange, and Idempotent Consumer. The complete message flow follows the pattern Publisher → Exchange → Queue → Consumer → Retry Queue → Dead Letter Queue.
Will the Shopware to Odoo Connector Integrated directly into the Shopware frontend, it follows the established Symfony architecture with Symfony Messenger as a connection to the message queue – including dedicated directories for client, DTOs, mapper, message handler, services, repositories and exceptions.
Important for context: RabbitMQ is the specific message queue solution used in this reference architecture – the role of "message queue" is therefore not necessarily tied to this one product. The pattern (asynchronous decoupling via a queue) is what matters for the architectural decision, not the specific product choice.
Idempotency and data consistency
A connector that can process messages multiple times—for example, after a network error and a redelivery attempt—must be idempotent: The specific message can be processed repeatedly without creating duplicates or inconsistent states. Odoo achieves this using external IDs in conjunction with the load()-Method that updates an existing ID instead of creating a new one.
For non-idempotent write operations, an additional rule applies: Before an automatic retry, it must be checked whether the original request has already successfully modified the target system – simply “sending again” without this check can otherwise lead to duplicate orders or incorrect inventory postings.
The business keys between the systems are immutable, business-related identifiers such as the Shopware UUID or the article number (SKU) – never technical surrogate keys like internal database IDs. We explain the logic behind this in [link/section]. Data mapping during ERP migration.
Stock levels, orders and prices
Typical synchronization areas of an ongoing Odoo-Shopware integration:
- Stock: Changes in the ERP system are fed back to the frontend based on events, instead of Shopware repeatedly actively requesting updates.
- Prices: including customer-specific B2B prices and tiered discounts, maintained as price lists in the ERP system.
- Orders: Asynchronous transfer from the frontend to the ERP, with retry in case of temporary errors.
- Order status: Feedback on delivery and invoice status to the frontend for customer communication and returns processes.
This list describes typical integration areas – the specific scope of a project always depends on the actual business processes required, not on a general list.
Fault tolerance and monitoring
For production-ready connectors, there are strict basic rules: no silent errors, no suppressed exceptions, complete logging of every incident, an automatic retry strategy, and moving unprocessable messages to a dead letter queue instead of silent data loss.
Structured logging includes at least the following: timestamp, correlation ID, the affected entity, the relevant business key reference, HTTP status, runtime, and the current retry counter. All external API calls use defined timeouts and exponential backoff with jitter; HTTP 429 and server errors 500, 502, 503, and 504 are generally considered candidates for an automatic retry – provided the repeated operation is demonstrably idempotent.
During operation, an observability setup (such as Grafana, Prometheus, or Loki) monitors technical metrics like CPU and database utilization, as well as the message queue fill level, supplemented by business metrics such as the number of orders per hour. If API availability drops, the system automatically triggers an alert – instead of a failure only being noticed through customer complaints.
Reference architecture overview
The complete architecture of a production-ready connector:
Shopware 6
│
Event / Order / Stock Change
│
▼
RabbitMQ Message Queue
│
▼
Connector (consumer)
│
Odoo 19 JSON-2 API
│
▼
PostgreSQL (ERP database)This structure is intentionally modular: Each component (producer, queue, consumer, API client) can be tested, monitored, and replaced independently without affecting the other components. Configuration values such as API keys, URLs, timeouts, and access credentials are never versioned in the source code, but are provided exclusively via environment variables or a secret management system.
Project structure: Python or Symfony
For high-performance ETL and connector processes, a modular project structure is recommended, regardless of the chosen programming language. In Python-based migration tools, a division into separate modules for configuration, authentication, API client, retry logic, data mapping, and separate modules for each entity (products, customers, inventory, orders) has proven effective, supplemented by a dedicated logging module and a dedicated test suite.
If the connector is integrated directly into the Shopware frontend, it follows the established Symfony architecture: a dedicated Odoo namespace with separate directories for the API client, Data Transfer Objects (DTOs), mapper classes, messenger messages and their handlers, services, repositories, exceptions, and CLI commands. This separation allows individual components—such as the pure API client—to be tested independently and reused outside the connector if necessary.
Testing: The recommended test pyramid
A production-ready connector goes through a fixed test pyramid before each release: Unit Tests → Integration Tests → API Tests → Load Tests → Smoke Tests → Go-Live TestsUnit tests examine individual functions in isolation, integration tests the interaction of multiple components, API tests the actual communication with Odoo, Shopware, and PlentyONE, load tests the behavior under realistic order volumes, smoke tests the basic functionality after deployment, and go-live tests the complete end-to-end functionality immediately before production release. Each of these stages covers different classes of errors – if one is skipped, error detection tends to be delayed until live operation.
Deployment and CI/CD pipeline
The reference architecture relies on isolated, versioned, and immutable containers for the connector itself. An automated CI/CD pipeline ensures code quality and stability through a fixed sequence of stages: linting, static code analysis, unit tests, integration tests, Docker build, deployment to a staging environment, and only then deployment to the production environment. A failed step at any of these stages automatically stops the pipeline, instead of passing on faulty code unchecked.
Coding Standards
Professional development demands consistency across the entire project: Python components adhere to PEP 8, static typing, and automated formatting tools like Ruff and Black. PHP components in the Shopware frontend utilize PSR-12, PHPStan, Rector, and CS Fixer. SQL scripts for validation and reporting use explicit column specifications instead of wildcard selects. EXPLAIN ANALYZE For performance testing, clean transaction boundaries, and optimized indexes. Each reference implementation also includes a unique version number and documentation of the precisely tested Odoo, Shopware, and Python/PHP versions to ensure long-term consistency between the implementation and reference documentation.
The connector is the permanent connection after migration is complete. Our overview describes the process – from system analysis to cutover – of getting there. Migration from PlentyONE to Odoo.
Request a high-performance Odoo-Shopware integration
A robust, asynchronous integration architecture between your existing Shopware 6 frontend and Odoo 19 isn't something you can buy off the shelf – it has to fit your actual data flows, load profiles, and business processes. That's precisely what we develop as part of our service. free, non-binding e-commerce auditsFor an initial assessment of your system landscape Contact us directly.
✔ Free of charge ✔ No obligation ✔ Asynchronous architecture instead of blocking interfaces ✔ Response within 24 hours
Frequently asked questions about the Odoo-Shopware connector
Is RabbitMQ absolutely necessary for every Odoo-Shopware integration?
No. RabbitMQ is the specific message queue solution used in our reference architecture. Crucial to the architecture is the underlying pattern of asynchronous, event-based decoupling – which specific product fulfills this role depends on your existing infrastructure and preferences.
What happens if the message queue itself fails?
A production-ready queue architecture runs redundantly and is monitored via the same observability setup as the other system components. A brief outage would be detected immediately by automatic alerts before it affects the checkout process.
Can we gradually migrate an existing synchronous integration to this architecture?
Yes. The transition can usually be carried out entity by entity – for example, first for orders, then for inventory and prices – instead of replacing the entire integration in a single, risky step.
We fear that a new interface will make our checkout process less stable rather than more stable.
The exact opposite is the goal of this architecture: Consistent decoupling via a queue makes the checkout more independent of the ERP system – not more dependent.
Our development team is not familiar with RabbitMQ or Symfony Messenger.
This is not an obstacle to starting the project. We handle the architecture and implementation entirely in-house and deliver a documented, maintainable system – including monitoring – that remains understandable even without in-depth messaging expertise.
How do we ensure that the integration continues to run reliably even after the project is completed?
Through the described observability setup with automatic alerting and clear documentation of the architecture, which your internal team or a successor partner can also understand.
Christopher Einenkel
Christopher Einenkel is the strategic mind at HQ GmbH for advanced system integrations and complex API architectures. Whenever data synchronizations reach their limits or demanding enterprise systems such as Salesforce need to be connected to Shopify, he designs tailored, high-performance interface logic.
His track record includes the in-house development of proprietary enterprise solutions, including automated AI translation tools for product master data, seamless B2B procurement systems, as well as automated market evaluation and competitive monitoring solutions. In addition, he manages the technical implementation and API integration of digital software call center systems into existing CRM and ERP environments for our enterprise clients.
