При активной работе с маркировкой товаров (особенно в периоды высокой нагрузки, когда подходит срок обязательного ввода остатков или запускаются новые товарные группы) пользователи систем 1С:Розница, 1С:Управление торговлей и других типовых конфигураций часто сталкиваются с неприятным сбоем. При отправке заказа на эмиссию кодов маркировки в СУЗ (Станцию управления заказами) система возвращает ошибку с кодом состояния HTTP 400 или 429 и текстом следующего содержания:
{ "globalErrors": [ "Превышена допустимая интенсивность запросов API token: f78e0db2-e9ee-6e47-eb73-a2aae43adf70. Повторите через 3 428 секунд. " ], "success": false }
В этой статье мы подробно проанализируем, почему возникает данная проблема, как устроены механизмы защиты серверов «Честного Знака» (ЦРПТ) и какими способами можно оперативно восстановить работоспособность обмена, обойдя это ограничение.
Для того чтобы понять природу ошибки, рассмотрим архитектуру взаимодействия программных решений 1С и шлюзов ИС МП («Честный Знак»). При формировании заказа на эмиссию кодов маркировки в документе 1С может содержаться несколько десятков строк с различной номенклатурой (разные характеристики, размеры, бренды или разные коды GTIN).
В ранних версиях механизмов интеграции 1С отправляла запросы по каждой строке последовательно в цикле, не делая пауз между отправками HTTP-пакетов. Для информационной системы 1С это выглядело логично и быстро. Однако серверная часть СУЗ «Честного Знака» воспринимает такую лавинообразную отправку запросов от одного источника как потенциальную угрозу стабильности системы (флуд или DDoS-атаку).
Чтобы снизить критическую нагрузку на свои серверные мощности, оператор маркировки ЦРПТ ввел жесткие квоты на интенсивность входящих обращений к API. Согласно правилам безопасности:
API token.HTTP 400 или HTTP 429 с указанием оставшегося времени бана.Таким образом, когда мы отправляем большой заказ, первая строка успешно обрабатывается сервером СУЗ, а последующие запросы, отправленные в ту же миллисекунду, мгновенно вызывают блокировку токена на час. В результате работа склада и контура маркировки полностью парализуется.
Разберем три основных способа борьбы с этой проблемой: от оперативного программирования «на коленке» до официальных методик.
Самым правильным и долгосрочным решением является обновление вашей информационной базы 1С до актуального релиза. Фирма «1С» оперативно реагирует на изменения в API ИС МП.
В библиотеках интеграции с маркировочными системами, начиная с релизов конца февраля 2020 года, разработчики внедрили принудительное ограничение скорости отправки пакетов. Теперь программный код 1С самостоятельно выдерживает необходимую технологическую паузу перед вызовом каждого последующего HTTP-запроса к СУЗ, распределяя нагрузку равномерно.
Если у вас установлена типовая конфигурация, находящаяся на поддержке, обязательно выполните обновление до последней доступной версии. Это решит проблему раз и навсегда без вмешательства в программный код.
Если ваша конфигурация сильно кастомизирована, находится на нетиповом обслуживании или обновить ее в данный момент не представляется возможным, мы можем самостоятельно внести изменения в код обмена. Наша главная задача — заставить 1С «засыпать» на 1 секунду перед отправкой очередного запроса в цикле.
Для реализации этой логики необходимо найти в конфигураторе общий модуль, отвечающий за отправку HTTP-запросов к СУЗ (например, функции отправки пакетов в СУЗ в модулях интеграции ИС МП), и внедрить туда механизм ожидания.
Рассмотрим два варианта реализации такой паузы средствами встроенного языка 1С:
Вариант А. Использование стандартной функции БСП (Библиотеки Стандартных Подсистем):
Если в вашей конфигурации используется БСП (а она есть практически во всех современных базах), мы можем использовать готовую функцию засыпания потока. Это наиболее красивый и наименее ресурсоемкий способ для процессора.
// Выдерживаем паузу в 1 секунду перед отправкой запроса к СУЗ
ОбщегоНазначенияБТС.Пауза(1);
Вариант Б. Реализация паузы через холостой цикл (если БСП недоступна):
Если по какой-то причине БСП в системе отсутствует или функция заблокирована, мы можем использовать простой цикл ожидания. Проанализируем пример кода ниже:
// Фиксируем стартовое время
ТекВремя = ТекущаяДата();
// Организуем пустой цикл на 1 секунду
Пока ТекущаяДата() <= ТекВремя + 1 Цикл
// Ждем окончания секунды для предотвращения блокировки API токена СУЗ
КонецЦикла;
Этот нехитрый прием гарантирует, что между отправкой двух последовательных запросов пройдет не менее одной секунды, что полностью удовлетворяет требованиям шлюза «Честного Знака» и предохраняет токен от бана.
Если вы хотите решить проблему программным путем, но при этом ваша основная конфигурация должна оставаться на замке (без снятия с поддержки), лучшим выходом будет написание или установка готового расширения.
Мы можем перехватить процедуру отправки запроса СУЗ. Разберем по шагам, как это сделать:
&Перед или &Вместо.Если вам нужно срочно выпустить коды маркировки прямо сейчас, а токен заблокирован или программные изменения вносить некому, мы можем временно изменить бизнес-процесс работы и воспользоваться так называемым «Сценарием №3», рекомендованным методологами маркировки.
Суть данного метода заключается в переносе этапа эмиссии из 1С непосредственно на веб-портал «Честного Знака»:
GTIN обработается сервером без каких-либо ошибок лимитов API.Этот способ более трудоемок в плане ручного сопоставления номенклатуры, но он является отличной «спасательной шлюпкой» в моменты нестабильной работы API шлюзов или блокировок токенов.
Мы проанализировали причины сбоя интенсивности запросов API token и рассмотрели все варианты исправления ситуации. Для стабильной и бесперебойной работы торговой точки рекомендуем придерживаться следующих правил: