iHerb + PochtaGlobal - автоматизация бизнес-процессов

Обзор

Связка iHerb → PochtaGlobal - типичный маршрут товарного бизнеса: заказ оформляется в американском магазине, попадает на склад мейлфорвардера в США, а тот отправляет посылку в Россию. iHerb - один из крупнейших магазинов товаров для здоровья: 30+ тысяч наименований от 1200 брендов. PochtaGlobal - сервис доставки из США, Европы и ОАЭ в Россию.

К нам обратился предприниматель с командой, который перепродаёт в России товары для здоровья и красоты из США. Между двумя этими системами у него сидел человек и целыми днями переносил данные руками. Бот на Browser Automation Studio закрыл весь этот участок: он собирает информацию о заказах на iHerb, оформляет покупки и посылки на PochtaGlobal, следит за трек-номерами PGB и отдаёт всё в Telegram-канал логов и в API учётной системы бизнеса.

Демо работы системы на YouTube

Проблема

Работа состояла из четырёх монотонных этапов, и все четыре росли линейно вместе с оборотом.

Сначала - заполнение покупок: большое количество товаров нужно было завести в кабинет мейлфорвардера, чтобы склад в США знал, что именно приедет и от кого. Затем - сборка посылок из этих покупок. Параллельно требовалось мониторить новые заказы iHerb и выписывать по ним трек-номера, а по каждому треку - заполнять форму на PochtaGlobal. И наконец - следить за статусами отправленных посылок PGB-XXX, потому что клиенту нужно отвечать, где его товар.

Цена ошибки здесь не абстрактная: опечатка в трек-номере или в имени получателя означает посылку, которую склад не может сопоставить с покупателем. А объём такой, что к вечеру внимание у оператора уже не то же, что утром.

Решение

Бот разбит на два независимых цикла с разной периодичностью, оба настраиваются в интерфейсе: обновление заказов - раз в 3600 секунд, обновление треков PGB - раз в 86400 секунд. Логины, пароли, ApiKey и данные Telegram-бота вводятся один раз в окне ресурсов при запуске и не лежат в теле скрипта.

Ключевое архитектурное решение - браузер нужен только для входа. Бот один раз авторизуется в кабинете iHerb и сохраняет куки, на PochtaGlobal сохраняет токен авторизации - а дальше всё оформление идёт чистыми HTTP-запросами, без Chromium вообще. Это меняет масштаб: создание покупки и посылки для любого количества трек-номеров занимает секунды вместо минут кликов по DOM, и ничего не ломается, когда на сайте меняют вёрстку.

Тело запроса собирается из данных заказа - внутренний ID заказа iHerb, полное имя получателя, склад отправления ("warehouse": "USA") - и проходит проверку длины: название покупки обрезается по лимиту поля в 50 символов, потому что длинные наименования товаров с iHerb в него не влезают. Это та деталь, которая находится не за столом, а на реальных данных.

Результат каждого шага уходит в два места: в Telegram-канал логов сообщением вида «Заказ 925152933 обновлен. Поставлен трек PGB-22212159 / Трек почты: CX400005202UZ» - и в API сервера бизнеса в формате JSON по ApiKey, откуда попадает в учётную систему.

Возможности

• Сбор информации о заказах на странице iHerb и мониторинг трек-номеров по расписанию
• Сохранение авторизации: куки для личного кабинета iHerb, токен для PochtaGlobal - без повторного логина каждый цикл
• Создание покупок и посылок на PochtaGlobal на HTTP-запросах, без браузера - для любого количества трек-номеров за проход
• Сборка JSON-payload из данных заказа со складом отправления и контролем лимита поля названия в 50 символов
• Отслеживание статусов отправленных посылок PGB-XXX и появления почтового трека (CX...UZ) с отдельным, более редким интервалом
• Логи в Telegram-канал с хештегом #новыйтрек: номер заказа, присвоенный трек PGB, почтовый трек или None, если он ещё не назначен
• Выгрузка данных в API сервера бизнеса в формате JSON по ApiKey - заказы, треки и статусы приходят в учётную систему без ручного переноса
• Настраиваемые интервалы обоих циклов: заказы (по умолчанию 3600 сек) и треки PGB (по умолчанию 86400 сек)
• Ввод учётных данных и ключей через окно ресурсов при запуске - ресурсы и входные данные в BAS

Процесс разработки

Первая версия делала всё через браузер - так проще начать, и так же проще упереться в потолок: на десятках трек-номеров прогон растягивается, а любая правка вёрстки на стороне сервиса ломает сценарий. Поэтому логика переехала на HTTP-клиент BAS, а браузер остался ровно на одной задаче - получить сессию. Куки и токен после этого живут отдельно от браузера, и остальной пайплайн к нему не привязан.

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

Отдельно стоит сказать про Трек почты: None в сообщениях. Это не недоделка, а честное состояние: почтовый трек присваивается позже трека PGB, и лог показывает ровно то, что известно на момент проверки, вместо того чтобы прятать пустое поле. Заказ вернётся в следующий цикл и допишет его, когда он появится - та же логика повторной проверки по расписанию, что и в остальных задачах такого рода.

Результаты

• Участок работы, занимавший человека целый день, идёт сам: от нового заказа iHerb до созданной посылки PGB и записи в учётной системе
• Оформление любого количества трек-номеров укладывается в один проход на HTTP-запросах вместо ручного заполнения формы по одному
• Опечатки в трек-номерах и именах получателей исчезли как класс - данные переносятся программно, а не глазами
• Владелец видит движение заказов в Telegram с телефона, без входа в два кабинета
• Учётная система получает данные по API в реальном времени, поэтому остатки и продажи не приходится сверять вручную
• Рост объёма заказов и расширение ассортимента не требуют переделки: добавляется нагрузка, а не логика

Выводы

Главный вывод этого проекта - браузер стоит держать только там, где без него нельзя. Авторизация действительно требует живой сессии; оформление форм - нет. Как только куки и токен сохранены, всё остальное становится обычным HTTP-клиентом: быстрее, устойчивее к правкам вёрстки и куда проще в отладке. Тот же приём потом переехал в более крупные системы автоматизации, вплоть до RPA Automation Panel.

Второй вывод - про интеграцию. Автоматизация, которая работает, но никуда не отдаёт результат, оставляет человека на месте: он всё равно открывает кабинет и переписывает цифры. Ценность здесь появилась в момент, когда бот начал писать в Telegram и в API учётной системы - то есть когда его работа стала видимой и попала в те же данные, по которым принимаются решения.