Краткий ответ
Сначала зафиксируйте, какая система владеет каждым объектом, кто создаёт и изменяет запись, как связываются идентификаторы и что происходит при конфликте или недоступности одной стороны. Затем выберите способ доставки: синхронный вызов, очередь или регламентное задание. Интеграцию стоит считать управляемой, когда сбой можно обнаружить, связать с конкретной операцией, диагностировать и безопасно обработать повторно.
Применимость
Основные принципы статьи не привязаны к одной версии Odoo. SPL работал на Odoo 18 Community: поведение XML-RPC сверено с официальной документацией Odoo 18, а работа очереди — с документацией OCA queue_job 18.0. Пример Tridoks относится к Odoo 19 Enterprise.
Что определить до разработки
Это инженерный подход автора, а не встроенное правило Odoo. Он нужен, чтобы код интеграции не принимал неявные решения о данных.
- Источник истины (source of truth)
- Система, чьё значение считается исходным при расхождении.
- Направление обмена
- Односторонняя или двусторонняя передача и события, которые запускают обмен.
- Владелец данных (ownership)
- Граница ответственности: где объект создаётся, изменяется и закрывается.
- Сопоставление данных (mapping)
- Соответствие моделей, полей, единиц измерения, статусов и справочников.
- Внешний идентификатор (external reference)
- Устойчивая связь локальной записи с объектом во внешней системе.
- Правило разрешения конфликтов
- Порядок обработки параллельных изменений, устаревших событий и неполных данных.
Рекомендация автора
Описывайте контракт обмена таблицей до разработки. Если для объекта нельзя назвать владельца, направление и идентификатор, реализация почти неизбежно перенесёт этот выбор в код и усложнит разбор ошибок.
Синхронный и асинхронный обмен
Когда достаточно синхронного вызова
Синхронный вызов подходит, когда операция короткая, пользователь должен сразу получить результат, обе стороны доступны, а ошибка может быть показана и исправлена в том же сценарии. Пример — проверка небольшого справочника перед сохранением формы.
Когда полезна очередь
Асинхронная обработка помогает разделить пользовательскую операцию и внешний обмен, управлять нагрузкой и хранить состояние отдельных заданий. В OCA queue_job документированы независимые задания, приоритеты и настраиваемые интервалы retry. В SPL механизм на базе queue_job входил в контур обработки ошибок: сбои обнаруживались, а обмен восстанавливался повторной обработкой операций.
Очередь не делает операцию безопасной автоматически. Повторяемость зависит от бизнес-операции, внешнего идентификатора, проверки уже созданного результата и обработки частичного выполнения.
Очередь и интеграционный контур
Пример таблицы проектирования
| Сущность | Источник | Получатель | Идентификатор | Обработка ошибки |
|---|---|---|---|---|
| Заказ клиента | Витрина | Odoo | Внешний ID заказа | Проверить существование результата; ошибку отправить на разбор |
| Статус исполнения | Odoo | Витрина | Внешний ID заказа | Повторять после сетевой ошибки только при проверяемом результате |
| Снимок остатков | ERP/WMS | Система-получатель | Сопоставление товара и склада | Остановить пакет при несовпадении схемы; исправить сопоставление |
Это обобщённый пример и рекомендация автора, а не описание SPL или Tridoks.
Опыт проекта: контур SPL
Атрибуция
Этот опыт получен Владиславом Червяковым во время работы в kt.team. SPL не представлен как клиент текущей студии.
Контур включал два экземпляра Odoo 18 Community. Marketplace обслуживал клиентскую часть: заказы покупателей, товары и сайт. Vendor-система отвечала за исполнение заказов поставщиками. Для каждой стороны существовали отдельные модули Odoo, а асинхронный обмен работал через механизм на базе queue_job. В отдельных сценариях использовались REST, RPC и XML-RPC.
Двусторонний обмен охватывал заказы, закупки, отгрузки, остатки, сообщения и вложения. Материалы не позволяют восстановить полную матрицу владельцев и направлений для каждой сущности, поэтому ниже приведены только подтверждённые границы.
- примерно 100 заказов и закупок в день;
- примерно 200 отгрузок в день;
- примерно 500 сообщений и вложений в день.
Для основных синхронизируемых сущностей — заказов, закупок, отгрузок, остатков, сообщений и вложений — использовались внешние идентификаторы, связывающие соответствующие записи двух экземпляров Odoo. Это позволяло находить уже созданный объект при последующей синхронизации и снижать риск повторного создания записей, не означая формальной идемпотентности всего контура.
Полный публичный контекст и показатели проекта приведены в кейсе синхронизации двух Odoo для SPL.
Надёжность — это не отсутствие ошибок
Надёжный контур всё равно сталкивается с недоступностью сети, несовместимостью схемы, ошибками данных и изменениями API. Практически важнее, чтобы:
- проблема обнаруживалась, а не терялась;
- операцию можно было идентифицировать;
- ошибка содержала достаточно контекста для диагностики;
- существовал проверяемый путь восстановления;
- повтор не создавал неконтролируемые дубли или повторные бизнес-действия.
Рекомендация автора
Не называйте задание «безопасно повторяемым» только потому, что оно находится в очереди. Для повторной обработки нужен отдельный ответ: как обнаружить уже созданный объект, какой результат считать завершённым и что делать после частичного выполнения.
Практический разбор режимов сбоев продолжен в статье «Как восстанавливать интеграцию Odoo после сбоев».
Опыт проекта: границы Strapi, Odoo и Stripe
В продолжающемся проекте Tridoks внешняя витрина построена на Strapi, центральный ERP-контур — на Odoo 19 Enterprise, а платежи проходят через Stripe. В согласованном контуре витрина передаёт в Odoo клиента, адрес, sale.order, строки заказа и внешний идентификатор платежа. Odoo возвращает витрине статусы заказа и исполнения.
Пример показывает границы витрины, ERP и платёжной системы. Проект продолжается; актуальный статус опубликован в кейсе Tridoks.
Источники
- Odoo 18: External API — аутентификация XML-RPC и вызовы методов моделей.
- OCA queue_job 18.0 — задания, retry и требование проектировать повторяемость операций.
- Кейс SPL — основной публичный источник проектного контекста и объёмов.
- Кейс Tridoks — статус продолжающегося проекта и границы интеграции.
Нужно спроектировать интеграцию Odoo?
Опишите системы, объекты обмена и известные ограничения — определим вопросы для технического обследования.
Обсудить интеграцию