Как я мучился с синхронизацией WooCommerce и Kika

Работал как то я с постоянным клиентом. Они продавали жевательный табак, стики и сопутствующую продукцию через интернет магазин на WooCommerce.

Проект к тому моменту был уже далеко не простым магазином на WordPress. Несколько языков, много товаров, свои доработки, платежи, доставка и внешние сервисы. В какой то момент понадобилось нормально связать магазин с системой Kika через интеграцию FHB, чтобы товары и заказы передавались автоматически.

На словах всё выглядело просто. Настроить синхронизацию, проверить один заказ и забыть. Но именно с этой интеграцией мы потом намучились больше всего.

Что нужно было получить

Покупатель оформляет заказ в WooCommerce. Заказ получает нужный статус. После этого данные должны автоматически попасть в Kika через FHB.

Для клиента это выглядит как одна функция. Заказ появился в магазине и должен появиться во внешней системе. Но внутри WordPress между этими двумя точками оказалось сразу несколько отдельных процессов.

WooCommerce → Action Scheduler → WP Cron → событие FHB → обработчик экспорта → Kika

И если ломается любой участок этой цепочки, со стороны кажется, что просто не работает Kika.

С чего начались проблемы

На сайте работал Action Scheduler. В списке фоновых заданий появлялась задача kika_export_order.

Логика была очевидной. Есть задача экспорта Kika, значит она должна взять заказ и отправить его дальше.

Но задача падала с сообщением no callbacks are registered.

Получалась довольно странная ситуация. Планировщик работает. Задача создаётся. WordPress пытается её выполнить. Но функции, которая должна обработать именно это событие, нет.

То есть автоматизация внешне существует, но выполнять сам экспорт фактически некому.

Почему такую проблему сложно заметить сразу

Когда полностью не работает cron, всё довольно понятно. Проверяешь запуск фоновых задач.

Когда внешний API отвечает ошибкой, идёшь смотреть запрос, авторизацию и ответ сервера.

Здесь же большая часть механизма выглядела исправной. В админке было запланированное действие. Оно запускалось. В логах появлялась запись.

Из за этого сначала кажется, что проблема находится уже где то дальше. В Kika, в товаре, в конкретном заказе или в статусе WooCommerce.

На деле пришлось разбираться, какой именно механизм экспорта предусмотрел сам FHB.

Пришлось идти в код FHB

Когда настройки в админке перестают давать ответы, я обычно открываю код плагина и смотрю, какие события и обработчики он регистрирует на самом деле.

Там и нашлась важная деталь. FHB использовал собственное событие wp_job_fhb_kika_export_order.

Именно к нему был подключён реальный обработчик экспорта заказов.

То есть нужная логика уже существовала. Не требовалось заново писать весь обмен с Kika и делать ещё одну интеграцию поверх готового плагина.

Проблема была в другом. Автоматизация обращалась не к той точке входа.

Это хороший пример того, почему при доработке WordPress не всегда нужно сразу писать новый код. Иногда плагин уже умеет всё необходимое, но его штатная цепочка запуска нарушена.

Потом пришлось разбираться с cron

Дальше выяснилось, что FHB умеет самостоятельно регистрировать периодическую задачу экспорта.

При сохранении настроек создавалось событие, которое должно было регулярно проверять подходящие заказы и передавать их дальше.

После этого проверка уже выглядела не как одна кнопка в WordPress, а как полноценная цепочка.

1. Системный cron запускает WordPress
2. WordPress обрабатывает фоновые события
3. Запускается событие FHB
4. FHB ищет подходящие заказы
5. Плагин формирует данные
6. Заказ отправляется в Kika

Само наличие WP Cron ещё не означает, что важные фоновые процессы выполняются стабильно. Для магазина с автоматической обработкой заказов я предпочитаю контролируемый запуск wp-cron.php с сервера.

Так синхронизация не зависит только от посещаемости сайта и случайного запуска фоновых задач.

Даже рабочий cron не означает, что заказ уйдёт

После cron появился следующий уровень проверки.

FHB не должен был экспортировать абсолютно любой заказ. Заказ сначала обязан соответствовать условиям интеграции.

В нашем случае важен был статус Processing. Также в логике присутствовала небольшая задержка перед экспортом.

Из за этого можно создать тестовый заказ, сразу открыть Kika и решить, что синхронизация снова сломалась. Хотя плагин ещё просто не должен был его отправлять.

Поэтому при диагностике важно смотреть не только на сам факт существования заказа, но и на его статус, время создания и условия, которые заложены в интеграцию.

Отдельно пришлось проверять товары

Заказы были только одной частью задачи. Перед нормальным экспортом нужно было убедиться, что товары уже синхронизированы и внешняя система понимает, какие позиции ей передаёт WooCommerce.

Если магазин отправляет заказ с товаром, которого Kika ещё не знает или который сопоставлен неправильно, дальше легко получить ошибку уже на другом участке цепочки.

Поэтому я разделяю такие задачи на два независимых процесса.

1. Сначала проверяется синхронизация товаров
2. Потом проверяется экспорт заказов

Это сильно упрощает диагностику. Если товары уже корректно сопоставлены, при проблемах с заказами не приходится одновременно проверять вообще всё.

Почему я не стал переписывать интеграцию с нуля

В таких ситуациях быстро появляется соблазн написать свой модуль.

Можно напрямую обращаться к API, создать собственный cron, хранить отметки об экспорте, добавить повторные попытки и свои логи.

Но это ещё один слой кода, который потом нужно обслуживать.

FHB уже умел работать с нужными данными, статусами, товарами и экспортом. Поэтому сначала было правильнее восстановить штатный механизм и понять, где именно он разорван.

Свой код имеет смысл писать там, где готового функционала действительно не хватает. А не просто потому, что существующая интеграция в первый момент выглядит сломанной.

Проблема была не просто в Kika

Фраза не работает синхронизация с Kika звучит просто, но технически почти ничего не объясняет.

Ошибка могла находиться в WooCommerce. В статусе заказа. В Action Scheduler. В WP Cron. В системном cron. В событии FHB. В обработчике. В сопоставлении товаров. И только потом уже непосредственно на стороне Kika.

Поэтому такие интеграции нужно проверять последовательно, а не менять настройки наугад.

Как я теперь проверяю подобные интеграции

Сначала сам заказ

Проверяю статус заказа, время создания и подходит ли он вообще под условия автоматического экспорта.

Потом товары

Смотрю, существуют ли нужные товары во внешней системе и правильно ли они сопоставлены.

Дальше фоновые задачи

Проверяю, создаются ли события, запускаются ли они и какие ошибки оставляют после выполнения.

Потом обработчик

Наличие события ещё не означает наличие работающей функции. Ошибка no callbacks are registered как раз отлично это показала.

После этого cron

Проверяю и WordPress, и системный запуск на сервере. Важный процесс не должен существовать только теоретически.

И только потом внешний API

Когда предыдущие участки подтверждены, уже есть смысл разбирать запросы, авторизацию, ответы сервера и данные, которые получает Kika.

Что в итоге

Для владельца магазина проблема выглядела очень просто. Заказ появился в WooCommerce, но дальше не синхронизировался.

Для разработчика за этим стояла целая цепочка фоновых событий и условий.

Именно поэтому интеграции интернет магазинов часто занимают больше времени, чем кажется по первоначальному описанию задачи.

Иногда нужно не написать сто строк нового PHP, а найти одно событие, которое запускается не тем способом, один callback, которого нет, или один статус, из за которого заказ вообще не попадает в обработку.

С Kika мы в итоге именно так и разобрались. Прошли всю цепочку, нашли реальные точки отказа и довели обмен до нормальной работы.

Если у вас уже есть магазин на WooCommerce и нужно настроить или починить интеграции, можно посмотреть мою страницу разработки и доработки WooCommerce. Я сначала разбираю существующую архитектуру и только потом решаю, что действительно нужно переписывать.