Кейс интеграции со СберМаркетом

Введение и контекст

Компания — российский дистрибьютор и ритейлер, работающий на рынке более 30 лет. Имеет развитое направление электронной торговли, в товарной матрице более 9 тыс. наименований. В разных городах России открыто более 100 фирменных магазинов.

Клиенты могут сделать заказ на сайте и забрать его из магазина либо заказать доставку курьером. Заказ будет собран в магазине либо на региональном складе в зависимости от выбранного срока доставки.

Объём в екоме колеблется от сотен до тысяч заказов в день — в дни распродаж и в высокий сезон объёмы возрастают кратно.

Цель проекта

Основная цель — подключить маркетплейс СберМаркет по модели Click&Collect и увеличить продажи на несколько сотен заказов в день. Комиссия выплачивается маркетплейсу за каждый заказ как доля от общей суммы заказа.

Комплектацию заказов решено делать в фирменных магазинах. Оплата заказа — при получении заказа на месте.

Click&Collect — это онлайн-заказ с самовывозом.

Вызовы и решения

Предстояло решить несколько задач:

• Интеграция товарных потоков данных: (а) товарная номенклатура, (б) остатки, (в) цены, (г) информация по работающим магазинам и (д) изображения для товарных карточек.
• Интеграция по заказам: (а) разработать эндпоинт для получения входящего вызова от СберМаркета с информацией о заказе и (б) разработать клиент для API СберМаркета, чтобы отправлять информацию о готовности заказа на стороне продавца.
• Магазины могут включаться и выключаться из проекта торговли через маркетплейс.
• Заказчик хочет управлять списком товаров, которые выгружаются для продажи на маркетплейсе. Существуют отдельные премиум-товары, которые заказчик хочет запретить к продаже через СберМаркет, но не запрещать всю категорию, в которую входят такие товары.
• Многие товары имеют неглубокий остаток в магазинах, что может стать проблемой, если клиенты маркетплейса попытаются купить то, чего уже нет в магазине.

Методология и стек

Основные системы контура электронной торговли написаны на PHP, сам интернет-магазин сделан на сильно доработанной версии Битрикс. Используется СУБД MySQL для Битрикс и нереляционная Couchbase для хранения торговых предложений. В качестве поискового индекса внедрена система Elasticsearch.

Номенклатура, характеристики товаров, остатки и цены поступают в контур e-commerce из мастер-систем компании:

• товарные остатки в «каменных» магазинах — из 1С Управление Торговлей;
• товарная номенклатура и цены — из MS Dynamics NAV.

На момент старта проекта (октябрь 2021) СберМаркет предлагал использовать технологию S3 для обмена данными по товарам в виде файловых выгрузок.

Описание и анализ

Проект длился 2 года до того момента, как я (Андрей Корниенко) возглавил группу системного анализа в октябре 2023 года. К этому моменту были реализованы:

• Интеграционные потоки через фиды XML, отправляемые в облако СберМаркета по протоколу S3 для обмена номенклатурой, ценами и остатками.
• Списки магазинов, которые участвуют в интеграции с маркетплейсом, реализовали «на ручнике» через менеджера, который получал выгрузку в формате MS Excel и передавал коллегам на стороне СберМаркета.
• Получение события о создании и отмене заказов СберМаркет→Ecom B2C реализовали через Sbermarket Orders API Partner's WebHooks API (1.0.0)
• Отправку событий в маркетплейс Ecom B2C→СберМаркет о готовности заказа к получению реализовали через Sbermarket Orders API Notifications (1.0.0)

Тестовые включения интеграции выявили проблемы с ограничением частоты обмена: неглубокие остатки товаров приводили к тому, что в магазинах товар мог закончится, а клиенты пытались оформить на них заказы в СберМаркете. Нефункциональные требования на стороне маркетплейса не были задокументированы, равно как и в проектной документации на «нашей» стороне.

В процессе тестирования выяснилось, что остатки и цены обрабатываются при выгрузке файлами на стороне маркетплейса не чаще, чем раз в 30 минут.

В августе 2023 представители СберМаркета предложили перейти на обмен остатками и ценами через Web API, что позволило бы передавать изменения чаще и снизить количество ошибок с заказами. Задачи были поставлены без должного проектирования и «на скорую руку», к декабрю 2023 доработки по API были сделаны.

В декабре 2023 стало известно о добавлении ограничений в API СберМаркета: в одном запросе не более 10 уникальных магазинов и не более 1000 товаров. Доделываем.

СберМаркет объявляет фиче-фриз в декабре и доработки API не были протестированы.

Наконец, в апреле 2024 получаем «добро» на включение обмена по Web API… и он не взлетает. Оказалось, что на стороне СберМаркета добавлены дополнительные ограничения по RPS — не более 10 запросов в секунду от партнёра.

В этом месте задача эскалирована на меня, потому что в текущей архитектуре систем на «нашей» стороне оказалось невозможно соблюсти все ограничения одновременно в рамках одного запроса:

• До 10 уникальных магазинов
• До 1000 товаров
• До 10 RPS

Бизнес-заказчики потребовали разъяснений, почему после 2 лет разработки интеграция внезапно потребовала ещё +2 месяца на доработку?!

Провели ретро-встречу, проанализировали предпосылки, которые привели к неприятной ситуации, обсудили существующую архитектуру, предложили новую. Слайдов при обсуждении было, конечно же больше, но показать их нельзя.

По отдельности ничего из описанных предпосылок не сыграло ключевой роли в провале генерального перехода на обмен по API. Однако все вместе эти предпосылки сломали процесс.

Результаты и выводы

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

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

Основной урок для команды: проектировать систему до того, как переходить к реализации. Привычка продуктового подхода «быстро сделать и проверить» в случае сложных интеграций малопригодна; да и понятие «быстро» весьма относительное — пока задача пробирается через бэклог, отпуска, фиче-фризы, бюджеты и прочее проходит много времени и пере-/до-делывать становится дорого и долго.

Очень банальный тезис о том, что обязательно надо сохранять артефакты процесса анализа и разработки, обсуждений, договорённостей, достигнутых на встречах, стыдно даже писать; на дворе лето просвещённого 2024 года, а грабли всё те же.