Рассмотрим весьма распространенную ситуацию при интеграции 1С с интернет-магазином (например, на платформе 1С-Битрикс). Допустим, мы настроили авто-синхронизацию между 1С и сайтом каждые 30 минут. Но объем данных большой, и выгрузка может длиться час или даже больше. Возникает закономерный вопрос: не начнется ли новая синхронизация по расписанию, пока еще не закончилась старая? Проанализируем, как платформа 1С обрабатывает наложение расписаний, и разберем по шагам, как избежать ошибок при долгих обменах.
Сразу успокоим: платформа 1С имеет встроенные механизмы защиты от дублирования фоновых процессов. Согласно правилам работы платформы (и это даже вынесено в вопросы сертификации 1С:Профессионал), количество одновременно выполняющихся регламентных заданий может быть любым, но не будут выполняться два задания с одинаковым ключом и именем метода.
Это означает, что пока стартовавшее РегламентноеЗадание (РЗ) не завершит свою работу, новое задание с тем же самым ключом не будет запущено системой. Однако важно помнить: для того чтобы эта защита сработала, у регламентного задания обязательно должен быть заполнен уникальный ключ. Если ключ не задан, платформа может попытаться запустить параллельный поток.
Разберем ситуацию со сдвигом графика. Наша синхронизация настроена на старт каждые 30 минут. Первая выгрузка запустилась в 12:00, но из-за большого объема каталога обмен шел ровно 1 час и закончился в 13:00. По расписанию следующие старты должны были быть в 12:30 и в 13:00. Как поведет себя система?
Как только первое задание завершится в 13:00, платформа проверит расписание. Поскольку время следующего старта (12:30) уже прошло, следующее регламентное задание должно запуститься сразу же после окончания предыдущего. Однако, стоит учитывать настройки самого расписания регламентного задания, а именно параметры перезапуска при ошибке. Там можно указать, нужно ли повторять запуск или стоит "усохнуть" и дождаться следующего планового интервала.
В современных типовых конфигурациях (например, УТ, ERP, КА, УНФ) стандартный модуль обмена с сайтом уже содержит встроенную логическую защиту от двойного запуска. Посмотрим на этот механизм подробнее:
Но что если вмешается человеческий фактор? Выгрузка долго идет в фоне, пользователю кажется, что ничего не происходит, и он нажимает кнопку ручного обмена. Чтобы ручной сеанс не сломал фоновый, разработчики добавляют программную проверку активных фоновых заданий. Пример такой проверки может выглядеть так:
МассивЗаданий = ФоновыеЗадания.ПолучитьФоновыеЗадания(Новый Структура("Ключ, Состояние", КлючЗадания, СостояниеФоновогоЗадания.Активно));
Если МассивЗаданий.Количество() > 0 Тогда
ВызватьИсключение "Обмен с сайтом уже выполняется в фоновом режиме. Дождитесь его завершения.";
КонецЕсли;
Выясним причину, почему разработчики так тщательно блокируют параллельные выгрузки. Даже если бы 1С смогла обойти свои блокировки и запустить два обмена одновременно, это привело бы к критическим ошибкам на стороне сайта.
Протокол обмена CommerceML работает пошагово. На шаге инициализации сайт очищает временную директорию для файлов импорта. Если два процесса 1С начнут передавать данные одновременно, они будут перезаписывать и удалять XML-файлы друг друга на лету. В результате мы получим:
Проанализируем возможные аварийные ситуации. Если во время долгого обмена пропадет интернет или веб-сервер сайта временно ответит ошибкой 502 или 504, регламентное задание в 1С может зависнуть. В таком случае следующее задание не стартанет никогда, так как предыдущее формально все еще "выполняется".
Поэтому при настройке интеграции критически важно задавать ограничения времени выполнения (таймауты) сеанса и корректно настраивать параметры перезапуска при аварийном завершении. Это позволит системе принудительно "убить" зависший сеанс и начать всё с чистого листа.
Пытаться впихнуть выгрузку, которая длится час, в 30-минутный интервал — изначально плохая практика. Рассмотрим правильное архитектурное решение для высоконагруженных систем. Мы рекомендуем создавать два независимых узла обмена в 1С:
При таком подходе тяжелая выгрузка каталога и быстрая синхронизация текущих заказов не будут мешать друг другу, они будут использовать разные ключи регламентных заданий, и вопрос о наложении расписаний долгого обмена на короткий решится сам собой.