При переходе с версии 1С:ЗУП 2.5 на 3.1 многие системные администраторы и программисты сталкиваются с изменением логики работы почтовой подсистемы. Если раньше для каждого письма создавался отдельный документ Электронное письмо, то в новых редакциях, построенных на Библиотеке стандартных подсистем (БСП), механизм стал более скрытым от глаз пользователя. Рассмотрим подробнее, как устроена рассылка отчетов «изнутри», почему она может «зависать» на больших объемах данных и как это исправить.
В конфигурации 1С:ЗУП 3.1 механизмы Рассылка отчетов и Почтовый клиент (взаимодействия) — это абсолютно разные подсистемы. Рассмотрим причины, по которым вы не видите документов:
ИнтернетПочта напрямую. Письма формируются динамически в оперативной памяти сервера и передаются на SMTP-сервер без создания промежуточных объектов в базе данных.Если документов нет, проанализируем, как понять, ушло письмо или нет. Для этого в системе предусмотрены специальные механизмы логирования:
1. Регистр сведений «Состояния рассылок отчетов»
Это основной источник информации. Здесь фиксируется время последнего запуска, признак успешного завершения или наличие ошибок. Однако детального описания ошибки «по каждому сотруднику» здесь может не быть — регистр показывает статус всей рассылки целиком.
2. Журнал регистрации (ЖР)
При возникновении критических сбоев 1С записывает события в ЖР. Ищите записи по источнику Рассылка отчетов. Если рассылка «зависла», в журнале может не быть записей типа «Ошибка», так как процесс формально еще не завершен.
3. Мониторинг фоновых заданий
Поскольку рассылка выполняется в фоновом режиме, необходимо проверить список активных заданий в Консоли администрирования кластера или через типовую обработку Обслуживание -> Фоновые задания. Если задание «крутится» часами, значит, система попала в бесконечный цикл или столкнулась с сетевым ожиданием (тайм-аутом).
Выясним причину, по которой массовая рассылка (например, на 200+ получателей) может работать крайне медленно или обрываться без ошибок. Проанализируем ситуацию с двух сторон: программной логики 1С и настроек почтового сервера.
Типовой алгоритм в общем модуле РассылкаОтчетов работает по следующей схеме:
система сначала формирует все отчеты для всех получателей, сохраняет их в дерево значений в оперативной памяти, и только после этого начинает цикл отправки. Рассмотрим фрагмент кода, который является узким местом:
// Добавление дерева сформированных отчетов - табличных документов и файлов.
ДеревоОтчетов = СоздатьДеревоОтчетов;
// На этом этапе система может потреблять огромное количество памяти rphost,
// если получателей много, а отчеты «тяжелые».
Если у вас 500 сотрудников, система сформирует 500 индивидуальных расчетных листков. При большом объеме данных процесс rphost может достичь лимитов памяти, что приведет к деградации производительности или аварийному завершению фонового задания менеджером кластера (обычно через 30 минут по умолчанию).
Современные почтовые системы (например, Microsoft Exchange или корпоративные фильтры) имеют защиту от спама и «бомбардировки» письмами — Message Rate Limit. Если 1С пытается отправить 200 писем подряд в течение одной минуты, сервер может временно заблокировать соединение. При этом 1С не всегда корректно обрабатывает ошибку 421 4.4.2 Message submission rate exceeded, и фоновое задание просто уходит в бесконечное ожидание ответа от сервера.
Для решения проблемы «зависания» и обхода блокировок сервера разберем по шагам, какие изменения стоит внести в код (на примере доработки общего модуля РассылкаОтчетов):
Посмотрим на пример логики, которую успешно применили на практике:
// Пример логики для обхода блокировок Exchange
КоличествоВМинуту = 0;
Для Каждого Получатель Из СписокПолучателей Цикл
// Формируем и отправляем отчет конкретному лицу
ОтправитьПисьмо(Получатель);
КоличествоВМинуту = КоличествоВМинуту + 1;
// Если отправили 9 писем, делаем паузу, чтобы не злить сервер
Если КоличествоВМинуту >= 9 Тогда
ПриостановитьВыполнение(60); // Пауза 60 секунд
КоличествоВМинуту = 0;
КонецЕсли;
КонецЦикла;
Результат: Если типовой механизм мог «висеть» более 24 часов на 250 сотрудниках, то после оптимизации (отправка порциями по 30 человек и задержка 9 писем в минуту) время рассылки сокращается до 1.5–2 часов, при этом нагрузка на сервер 1С остается стабильно низкой.
Если вы не хотите вносить изменения в программный код, рассмотрим альтернативные варианты решения задачи:
Рассылки отчетов несколько элементов (например, по подразделениям: «Рассылка — Администрация», «Рассылка — Цех 1»). Настройте их запуск с интервалом в 30-40 минут..pdf генерируется платформой 8.3 значительно быстрее и занимает меньше места, чем .xlsx или .html. Это снижает нагрузку на память сервера 1С.Мы выяснили причину «невидимости» писем — это особенность архитектуры БСП. Основная проблема зависания кроется в неэффективности формирования всех отчетов разом и конфликтах с лимитами почтовых серверов. Используя предложенные методы оптимизации кода или административного деления рассылок, вы сможете обеспечить стабильную доставку расчетных листков даже в крупных организациях с численностью сотрудников более 1000 человек.