Коректна інтеграція WooCommerce з ERP (системами обліку на кшталт BAS, Odoo чи 1C) базується на відмові від прямого синхронного запису на користь асинхронної буферизації. Щоб уникнути помилок 504 Gateway Timeout, блокувань бази даних і продажу відсутніх товарів, обмін даними має спиратися на пакетні запити (batch endpoints), фонові черги виконання та ідемпотентність транзакцій під час зміни статусів замовлень.
Анатомія збою: чому прямий обмін даними «в лоб» ламає інтернет-магазин
Типовий сценарій більшості базових модулів або самописних скриптів виглядає так: облікова система відправляє поодинокі HTTP-запити до сайту на кожну зміну залишку, або інтернет-магазин у момент натискання кнопки «Оформити замовлення» намагається синхронно зв’язатися з API складської програми й дочекатися підтвердження.
Такий підхід стабільно працює лише на етапі тестування з десятком товарів. У робочому середовищі він призводить до ланцюгової реакції технічних збоїв:
- PHP max_execution_time та 504 Gateway Timeout: якщо ERP вивантажує файл або масив на кілька сотень SKU одночасно через один синхронний виклик, вебсервер Nginx/Apache розриває з’єднання через перевищення ліміту очікування відповіді від PHP-FPM. Як наслідок — залишки оновлюються лише частково.
- Блокування бази даних (Database Deadlocks): класична структура WooCommerce зберігає атрибути товару в таблиці
wp_postmeta. Масовий паралельний запис сотень рядків провокує конфлікти блокування рядків у підсистемі MySQL InnoDB Locking and Transaction Model. У моменти, коли скрипт оновлення блокує таблицю, звичайні користувачі сайту бачать «білий екран» або не можуть відкрити кошик. - Стан перегонів (Race Condition) та овербукінг: покупець додає останню одиницю товару в кошик і переходить до оплати. Одночасно з цим ERP ініціює списання цього ж залишку через офлайн-продаж. Якщо інтеграція не підтримує блокування на рівні бізнес-логіки та версійність транзакції, WooCommerce дозволяє сплатити замовлення. Результат — касовий розрив і повернення коштів розчарованому клієнту.
- Неузгодженість статусів замовлень: втрата з’єднання між серверами під час передачі фіскального чека чи зміни статусу «В обробці» на «Виконано» залишає замовлення у підвислому стані без механізму повторних спроб (retry logic).
Архітектурні рішення для стабільної синхронізації
Для побудови відмовостійкого каналу передачі даних необхідно розділити прийом інформації та її безпосередній запис у базу даних WordPress.
1. Перехід на пакетні ендпоінти (Batch Updates)
Надсилання окремого HTTP POST-запиту на кожне оновлення ціни для тисячі позицій створює гігантський overhead на TLS-handshake та завантаження ядра WordPress. Згідно з WooCommerce REST API Documentation, система нативно підтримує ендпоінт /wp-json/wc/v3/products/batch, який дозволяє створювати, оновлювати або видаляти до 100 товарів за один HTTP-запит. Це зменшує навантаження на мережевий стек та вебсервер у десятки разів.
2. Фонова обробка через черги (Action Scheduler та Redis)
Коли ERP передає великий масив даних, вебсервер повинен лише валідувати вхідний пакет, повернути швидку відповідь HTTP 202 Accepted і передати масив у чергу обробки. Для цього всередині WooCommerce використовується Action Scheduler — асинхронна черга завдань, яка дробно розбирає імпорт у фоні через системний cron сервера без загрози виходу за ліміти виконання скриптів.
Для великих проектів із частими змінами цін буферизацію доцільно виносити на рівень оперативної пам’яті за допомогою Redis, що повністю нівелює навантаження на MySQL під час пікових напливів запитів від облікової системи.
3. Впровадження High-Performance Order Storage (HPOS)
Історично кожне замовлення WooCommerce записувалося як окремий запис у таблицю wp_posts, а всі його параметри (клієнт, адреса, ціна, статус) множинно дублювалися у wp_postmeta. При високій частоті замовлень це викликало конкуренцію за ресурси з каталогом товарів. Механізм High-Performance Order Storage (HPOS) зберігає замовлення у виділених реляційних таблицях (wp_wc_orders), що ізолює операції запису замовлень від читання каталогу та кардинально знижує ймовірність блокувань транзакцій.
Діагностика та матриця рішень: підбір архітектури обміну
Масштаб та інтенсивність обміну даними визначають необхідний технічний стек. Нижче наведено матрицю, за якою визначаються вимоги до каналу синхронізації:
| Параметри магазину | Характер оновлень | Оптимальна технічна архітектура | Ризики неправильної реалізації |
|---|---|---|---|
| До 1 000 SKU, до 20 замовлень на добу | Зміна залишків 1–2 рази на добу | Стандартний REST API, пагінація запитів, базові вебхуки WooCommerce. | Мінімальні, допустимий прямий обмін за умови контролю timeout на стороні сервера. |
| 1 000–10 000 SKU, регулярні продажі | Постійні апдейти кожні 10–30 хвилин | Обов’язкове використання batch endpoints (/products/batch по 50–100 елементів), фонова обробка через Action Scheduler. | Переповнення буфера з’єднань, 504 Gateway Timeout, зависання черг через стандартний WP-Cron. |
| Понад 10 000 SKU або пікові продажі (>10 зам/хв) | Масові динамічні залишки, акції, сезонні сплески | Активація HPOS, винесення буфера в Redis, ізольований воркер на системному cron (CLI), черги з повторними спробами. | InnoDB deadlocks, падіння MySQL-сервера, розсинхронізація цін та овербукінг. |
Практичний погляд VORONOV Solutions
У рамках послуг із доопрацювання та інтеграцій інтернет-магазинів команда VORONOV Solutions регулярно стикається з наслідками некоректно побудованих зв’язок WooCommerce з ERP-системами (BAS, 1C, Odoo). Найпоширеніша проблема — застарілі сторонні коннектори, які намагаються писати дані безпосередньо в базу MySQL, оминаючи нативні хуки платформи. Це руйнує цілісність кешу та призводить до прихованих помилок.
Для нестандартних бізнес-процесів ми розробляємо кастомні плагіни та модулі з індивідуальною логікою на PHP: налаштовуємо асинхронні черги, впроваджуємо логування із системою сповіщень про збої та ізолюємо навантаження на рівні сервера. Для підтримки безперебійної роботи ми забезпечуємо щомісячний моніторинг стабільності критичних процесів магазину в рамках тарифу Commerce Care, що дозволяє виявляти помилки зв’язку до того, як вони вплинуть на клієнтів.
FAQ: часті запитання щодо інтеграції з ERP
Чому після масового вивантаження залишків з облікової системи сайт перестає відкриватися?
Причина полягає в блокуванні таблиць бази даних і вичерпанні пулу процесів PHP-FPM через масовий синхронний запис у таблицю wp_postmeta. Якщо скрипт інтеграції надсилає дані без обмеження швидкості та без пакетування, вебсервер перестає виділяти ресурси на обробку запитів звичайних відвідувачів сайту.
Як захиститися від продажу товару, якщо залишок змінився секунду тому в фізичному магазині?
Вирішенням є поєднання ідемпотентних ключів операцій та налаштування вебхуків високого пріоритету: при виникненні події списання на складі ERP повинна генерувати точковий швидкий вебхук до магазину на конкретний ID/SKU, який обробляється поза загальною чергою щоденного імпорту.
Чи можна увімкнути HPOS на вже працюючому магазині WooCommerce?
Так, але перехід вимагає попереднього технічного аудиту. Перед перемиканням бази на окремі таблиці замовлень необхідно перевірити сумісність усіх встановлених плагінів (особливо модулів оплати, доставки та аналітики) із новим API зберігання даних.
Плануєте запуск нового проекту, складну інтеграцію чи шукаєте надійну команду для технічної підтримки та прискорення існуючого сайту? Опишіть ваше завдання — у VORONOV Solutions ми проведемо технічний аудит і запропонуємо оптимальний формат співпраці (Fixed Price, пакет годин або Retainer).
Ukrainian 
English