При работе с системой 1С:Предприятие мы часто сталкиваемся с необходимостью отправки большого объема электронных писем различным контрагентам. Эта задача может осложняться, если перед отправкой каждого письма требуется выполнить ресурсоемкие операции, такие как формирование отчета (например, в формате Excel) и сохранение его. В некоторых случаях эти операции по соображениям безопасности или из-за архитектурных ограничений конфигурации могут выполняться только в толстом клиенте.
Одной из главных проблем при массовой рассылке через публичные почтовые сервисы, такие как Gmail, являются ограничения на скорость трафика или количество отправляемых сообщений с одного IP-адреса или учетной записи. В результате один поток отправки письма может занимать канал, например, максимум в 300 Кб/сек. Если попытаться отправить все письма последовательно, это займет неприемлемо много времени.
Возникает логичный вопрос: поможет ли запуск нескольких потоков отправки обойти эти ограничения и увеличить общую пропускную способность? Опытным путем было установлено, что это действительно так. Если запустить несколько фоновых заданий, каждое из которых отправляет отдельное письмо, то суммарное количество байт, передаваемое через сервер за единицу времени, кратно увеличивается. Это означает, что параллельная отправка является эффективным решением для ускорения процесса.
Наша задача заключается в том, чтобы разделить пул контрагентов для отправки между запущенными процессами (потоками) и эффективно управлять этими процессами, контролируя их выполнение и обрабатывая возможные ошибки. Рассмотрим, как это можно реализовать в 1С.
Одним из наиболее гибких и контролируемых подходов является создание и управление пулом фоновых заданий. Этот метод позволяет нам задать максимальное количество одновременно работающих потоков, эффективно распределить между ними задачи по отправке писем и отслеживать статус каждого из них. Мы будем запускать фоновые задания, помещая их в специальный массив для отслеживания, и при необходимости ожидать завершения самых старых заданий, чтобы освободить место для новых.
Рассмотрим подробный алгоритм реализации такого подхода с использованием объектов платформы 1С.
Определение максимального количества параллельных потоков:
Первым шагом нам необходимо определить, сколько фоновых заданий (потоков) мы хотим запускать одновременно. Это значение должно быть подобрано эмпирическим путем и зависит от нескольких факторов:
Предположим, на основе нашего анализа, мы выбрали 5 потоков как оптимальное количество:
КоличествоПотоковОтправкиПочты = 5;
Инициализация массива для отслеживания активных заданий:
Для того чтобы контролировать запущенные фоновые задания, нам понадобится массив, в котором мы будем хранить ссылки на объекты ФоновоеЗадание. Это позволит нам в любой момент проверить их статус и, при необходимости, дождаться завершения или обработать ошибки.
ОтправленныеПрайсы = Новый Массив;
Название ОтправленныеПрайсы здесь условно и может быть заменено на более общее, например, АктивныеЗаданияОтправкиПисем.
Функция для получения текущих активных фоновых заданий:
Чтобы принимать решения о запуске новых заданий или ожидании, нам нужно знать, сколько наших фоновых заданий уже активно. Создадим вспомогательную функцию, которая будет запрашивать у платформы список активных заданий по их наименованию.
Функция АктивныеФоновыеЗаданияОтправкаПрайса()
// Создаем структуру отбора, чтобы получить только наши задания.
// "Наименование" — это параметр, который мы задаем при запуске ФоновогоЗадания.
// "Состояние" — указываем, что нас интересуют только активно выполняющиеся задания.
Отбор = Новый Структура("Наименование, Состояние", "ОтправкаПрайса", СостояниеФоновогоЗадания.Активно);
// Используем метод платформы ФоновыеЗадания.ПолучитьФоновыеЗадания()
// который возвращает коллекцию объектов ФоновоеЗадание, соответствующих отбору.
ФоновыеЗаданияОтправкаПрайса = ФоновыеЗадания.ПолучитьФоновыеЗадания(Отбор);
Возврат ФоновыеЗаданияОтправкаПрайса;
КонецФункции
Здесь "ОтправкаПрайса" — это уникальное наименование, которое мы присваиваем всем фоновым заданиям, отвечающим за отправку писем. СостояниеФоновогоЗадания.Активно означает, что задание находится в процессе выполнения. Если мы хотим отслеживать также задания, которые находятся в очереди на выполнение, мы можем добавить в отбор СостояниеФоновогоЗадания.ВОчереди.
Основной цикл запуска фоновых заданий:
Теперь мы можем реализовать основной цикл, который будет перебирать список получателей, запускать для каждого из них фоновое задание и контролировать количество одновременно работающих потоков. Этот цикл будет взаимодействовать с вспомогательной функцией для получения активных заданий и процедурой для ожидания их завершения.
// Пусть СписокПолучателей - это коллекция объектов или структур,
// содержащих информацию о контрагентах и необходимые данные для письма.
Для Каждого Контрагент Из СписокПолучателей Цикл
// 1. Получаем текущее количество активных фоновых заданий, запущенных нами.
ТекущиеАктивныеЗадания = АктивныеФоновыеЗаданияОтправкаПрайса();
// 2. Проверяем, не превышен ли лимит параллельных потоков.
// Если количество активных заданий равно или больше установленного лимита,
// мы должны подождать, пока одно из заданий завершится и освободит слот.
Если ТекущиеАктивныеЗадания.Количество() >= КоличествоПотоковОтправкиПочты Тогда
// Вызываем процедуру ожидания, которая обработает завершившиеся задания
// и при необходимости принудительно подождет одно из них.
ОжидатьЗавершенияИОбработатьЗадания(ОтправленныеПрайсы, 1); // Передаем 1, чтобы гарантировать хотя бы один свободный слот
КонецЕсли;
// 3. Подготовка параметров для нового фонового задания.
// Метод, который будет выполняться в фоновом задании, должен быть экспортным методом
// общего модуля, работающего на сервере.
ИмяМетодаОтправки = "МойОбщийМодульНаСервере.ОтправитьПисьмоКонтрагенту";
// Собираем параметры, которые будут переданы в наш серверный метод.
// Это могут быть ссылки на объекты базы данных, строковые параметры, двоичные данные и т.д.
МассивПараметров = Новый Массив;
МассивПараметров.Добавить(Контрагент.Ссылка); // Например, ссылка на элемент справочника "Контрагенты"
// Допустим, отчет уже сформирован и сохранен во временное хранилище или как двоичные данные.
МассивПараметров.Добавить(Контрагент.ДанныеОтчетаДляОтправки);
// Важно: если формирование отчета и сохранение в Excel выполняются в толстом клиенте,
// то к моменту запуска фонового задания файл должен быть уже сформирован
// и либо сохранен в доступное для сервера хранилище (например, общий сетевой ресурс),
// либо его содержимое (как двоичные данные) должно быть передано через параметры.
// Ключ фонового задания позволяет однозначно идентифицировать его.
// Полезно для отслеживания или отмены.
КлючФоновогоЗадания = "ОтправкаПисьмаКонтрагенту_" + Контрагент.УникальныйИдентификатор;
// Описание фонового задания отображается в списке активных фоновых заданий в консоли.
ОписаниеФоновогоЗадания = "Отправка письма для контрагента: " + Контрагент.Наименование;
// 4. Запускаем новое фоновое задание, используя метод платформы ФоновыеЗадания.Выполнить().
// Он возвращает объект ФоновоеЗадание, который мы можем отслеживать.
ФонЗад = ФоновыеЗадания.Выполнить(ИмяМетодаОтправки, МассивПараметров, КлючФоновогоЗадания, ОписаниеФоновогоЗадания);
// 5. Добавляем запущенное задание в наш массив для дальнейшего отслеживания.
ОтправленныеПрайсы.Добавить(ФонЗад);
КонецЦикла;
// 6. После завершения основного цикла, нам необходимо дождаться завершения всех оставшихся
// фоновых заданий, которые были запущены, но еще не успели завершиться.
// Вызываем нашу процедуру ожидания, передавая 0 в качестве минимального количества свободных слотов,
// что означает "ждать, пока массив ОтправленныеПрайсы полностью не опустеет".
Сообщить("Основной цикл отправки завершен. Ожидаем завершения всех оставшихся фоновых заданий...");
ОжидатьЗавершенияИОбработатьЗадания(ОтправленныеПрайсы, 0);
Сообщить("Все фоновые задания по отправке писем завершены.");
Процедура ожидания завершения и обработки фоновых заданий:
Эта процедура является центральной частью нашей логики управления пулом. Она будет периодически проверять статус запущенных заданий, удалять завершенные из массива и, если необходимо, принудительно ожидать выполнения одного из них, чтобы освободить слот для нового задания.
Процедура ОжидатьЗавершенияИОбработатьЗадания(МассивЗаданий, МинимальноеКоличествоСвободныхСлотов = 1)
// Шаг 1: Проходим по массиву заданий в обратном порядке.
// Это важно для безопасного удаления элементов из массива без нарушения индексов
// при итерации.
Индекс = МассивЗаданий.ВГраница();
Пока Индекс >= 0 Цикл
ФонЗад = МассивЗаданий[Индекс];
// Получаем актуальное состояние фонового задания.
// Состояние задания может измениться в любой момент.
АктуальноеСостояние = ФонЗад.Состояние;
Если АктуальноеСостояние = СостояниеФоновогоЗадания.Завершено Тогда
// Задание успешно завершено.
// Мы логируем успех и можем выполнить дополнительные действия.
Сообщить("Успех: " + ФонЗад.Описание + ". Статус: " + Строка(АктуальноеСостояние) + ". Id: " + ФонЗад.УникальныйИдентификатор);
// Дополнительная логика:
// - Обновление статуса отправки в базе данных (например, в регистре сведений).
// - Удаление временных файлов, которые могли быть использованы в процессе отправки.
// - Оповещение пользователя об успешной отправке.
МассивЗаданий.Удалить(Индекс); // Удаляем успешно завершенное задание из массива.
ИначеЕсли АктуальноеСостояние = СостояниеФоновогоЗадания.ЗавершеноАварийно Тогда
// Задание завершено с ошибкой.
// Крайне важно обработать эту ситуацию.
Сообщить("Ошибка: " + ФонЗад.Описание + ". Статус: " + Строка(АктуальноеСостояние) + ". Описание ошибки: " + ФонЗад.ОписаниеОшибки + ". Id: " + ФонЗад.УникальныйИдентификатор, СтатусСообщения.Важное);
// Логика обработки ошибок и повторных попыток:
// - Запись подробностей ошибки в журнал или отдельный регистр сведений.
// - Помещение письма обратно в очередь на отправку, но с пометкой "повторная попытка"
// и возможностью отложить ее на некоторое время (например, через 15 минут).
// - Ограничение количества повторных попыток.
// - Отправка уведомления администратору системы о критической ошибке.
МассивЗаданий.Удалить(Индекс); // Удаляем задание из массива после обработки ошибки.
ИначеЕсли АктуальноеСостояние = СостояниеФоновогоЗадания.Активно Или АктуальноеСостояние = СостояниеФоновогоЗадания.Остановлено Тогда
// Задание еще активно или было остановлено (например, администратором).
// В данном случае мы просто пропускаем его, так как оно еще не завершилось.
КонецЕсли;
Индекс = Индекс - 1; // Переходим к предыдущему элементу массива.
КонецЦикла;
// Шаг 2: При необходимости, принудительно ожидаем завершения одного из активных заданий.
// Это условие выполняется, если после очистки массива от завершившихся заданий,
// количество активных заданий все еще превышает установленный лимит
// (или если мы ждем полного опустошения массива, если МинимальноеКоличествоСвободныхСлотов = 0).
Если МассивЗаданий.Количество() > (КоличествоПотоковОтправкиПочты - МинимальноеКоличествоСвободныхСлотов) Тогда
// Ищем первое активное задание в массиве, чтобы его подождать.
ПервоеЗаданиеДляОжидания = Неопределено;
Для Каждого ЗаданиеИзМассива Из МассивЗаданий Цикл
Если ЗаданиеИзМассива.Состояние = СостояниеФоновогоЗадания.Активно Тогда
ПервоеЗаданиеДляОжидания = ЗаданиеИзМассива;
Прервать; // Нашли первое активное, ждем именно его.
КонецЕсли;
КонецЦикла;
Если ПервоеЗаданиеДляОжидания <> Неопределено Тогда
Сообщить("Пул заданий заполнен. Ожидаем завершения задания: " + ПервоеЗаданиеДляОжидания.Описание + " (Идентификатор: " + ПервоеЗаданиеДляОжидания.УникальныйИдентификатор + ")", СтатусСообщения.Информация);
Попытка
// Метод ФоновоеЗадание.ОжидатьЗавершенияВыполнения() - блокирующая операция.
// Он приостанавливает выполнение текущего серверного вызова
// до тех пор, пока целевое фоновое задание не завершится.
ПервоеЗаданиеДляОжидания.ОжидатьЗавершенияВыполнения();
// После того как задание завершилось, его статус мог измениться.
// Мы рекурсивно вызываем эту же процедуру, чтобы повторно пройти по массиву
// и корректно обработать завершившееся задание (удалить его, обработать результат).
// Это гарантирует, что массив будет очищен, а слот - освобожден.
ОжидатьЗавершенияИОбработатьЗадания(МассивЗаданий, МинимальноеКоличествоСвободныхСлотов);
Исключение
// Если при ожидании произошла ошибка (например, задание было отменено извне),
// мы ее логируем, но продолжаем работу.
Сообщить("Ошибка при ожидании завершения фонового задания '" + ПервоеЗаданиеДляОжидания.Описание + "': " + ОписаниеОшибки(), СтатусСообщения.Важное);
КонецПопытки;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Использование метода ФоновоеЗадание.ОжидатьЗавершенияВыполнения() следует применять с осторожностью, поскольку он блокирует текущий поток выполнения. В нашем случае это оправдано, так как мы хотим сознательно управлять размером пула и не допускать запуска новых заданий до освобождения слота. В других сценариях, где блокировка нежелательна, можно использовать периодический опрос состояния заданий без принудительного ожидания.
Помимо прямого управления пулом фоновых заданий, существуют и другие стратегии для организации параллельной отправки писем. Выбор подхода зависит от конкретных требований к скорости, масштабируемости, сложности логики и имеющихся ресурсов.
Использование дочерних фоновых заданий:
Мы можем создать одно "мастер"-фоновое задание, которое будет выполнять итерацию по списку получателей и для каждого письма запускать отдельное дочернее фоновое задание. Этот подход упрощает логику контроля за статусом каждого конкретного письма, поскольку каждое дочернее задание отвечает только за свою отправку. Мастер-задание может периодически проверять состояние всех запущенных дочерних заданий. Главное преимущество — максимальная производительность за счет простоты запуска, но при этом сложнее строго ограничить количество одновременно активных потоков, так как платформа сама управляет очередью и запуском фоновых заданий.
Группировка контрагентов и регламентные задания:
Если массовая рассылка не требует мгновенной реакции и может быть распределена по времени (например, ночная рассылка или рассылка в течение дня с определенными интервалами), можно использовать механизм регламентных заданий. Суть в следующем:
Этот метод хорошо подходит для очень крупных рассылок, где важно не перегрузить систему за короткий период.
Бизнес-процессы для отслеживания:
Бизнес-процессы в 1С предоставляют мощный механизм для моделирования и отслеживания сложных задач. Мы можем создать бизнес-процесс для каждого письма, который будет содержать шаги формирования вложения, отправки письма и регистрации результата. Сами по себе бизнес-процессы не обеспечивают параллелизм — они лишь описывают последовательность или ветвление задач. Однако они предоставляют удобный способ визуализации, контроля и мониторинга состояния каждой отдельной отправки. Для фактического выполнения шагов бизнес-процесса потребуется написать исполнителя задач бизнес-процесса (например, регламентное задание), который будет запускать серверные методы или фоновые задания для отправки почты. Это добавляет гибкости в управлении и возможность приостанавливать/возобновлять отправку, но увеличивает общую сложность решения.
Система очередей сообщений через регистры сведений или документы:
Одним из наиболее масштабируемых и отказоустойчивых подходов является реализация собственной системы очередей сообщений. Принцип работы следующий:
"ОчередьОтправкиПисем" или специализированный РегистрСведений.Такой подход позволяет сгладить пиковые нагрузки, управлять приоритетами, легко реализовать механизм повторных попыток и более гибко контролировать количество одновременно обрабатываемых писем, выбирая их из очереди регламентным заданием.
Для создания надежной и производительной системы параллельной отправки писем необходимо учитывать ряд дополнительных факторов и применять методы оптимизации.
Формирование отчетов в Excel в толстом клиенте:
Если требование формировать отчет и сохранять его в Excel строго привязано к толстому клиенту (из-за ActiveX, COM-объектов или других специфических ограничений), то необходимо продумать механизм передачи готового файла на сервер для дальнейшей отправки. Возможные варианты:
В идеале, если есть возможность, следует перенести логику формирования отчета на сервер (например, с использованием COMОбъект("Excel.Application") на сервере, если это разрешено и настроено, или с помощью специализированных библиотек для работы с Excel).
Использование нескольких учетных записей отправителя:
Как уже упоминалось, многие почтовые провайдеры применяют ограничения на скорость и количество писем к конкретной учетной записи или IP-адресу. Использование нескольких учетных записей отправителя (например, sales@mycompany.com, info@mycompany.com, support@mycompany.com) может быть очень эффективным способом увеличения общей пропускной способности. В 1С можно настроить несколько учетных записей электронной почты (например, в справочнике "Учетные записи электронной почты"). При запуске фонового задания вы можете динамически выбирать, с какой учетной записи будет отправлено письмо, распределяя нагрузку между ними.
Подробное логирование:
Для любой системы массовой рассылки крайне важно вести подробный журнал всех операций. Логи должны содержать следующую информацию:
Эти данные могут быть записаны в ЖурналРегистрации 1С или, что предпочтительнее для анализа и отчетности, в отдельный РегистрСведений. Подробные логи помогут при отладке, анализе проблем с доставкой и подтверждении факта отправки писем.
Механизмы повторной отправки (Retry-логика):
Отправка писем — это операция, подверженная временным сбоям (например, недоступность почтового сервера, временные ошибки авторизации, превышение лимитов провайдера). Необходимо реализовать надежный механизм повторных попыток:
Это значительно повышает отказоустойчивость вашей системы рассылки.
Мониторинг ресурсов:
Параллельная отправка, особенно с формированием вложений, может значительно увеличить нагрузку на сервер 1С. Важно постоянно мониторить следующие ресурсы:
Используйте стандартные инструменты мониторинга операционной системы или специализированные системы для отслеживания производительности.
Оптимизация количества потоков:
Количество одновременно работающих фоновых заданий (КоличествоПотоковОтправкиПочты) — это критически важный параметр. Слишком большое число потоков может привести к "эффекту троттлинга", когда система тратит больше ресурсов на переключение контекста между задачами и управление ими, чем на саму полезную работу. Это может также вызвать перегрузку почтового сервера или СУБД. Слишком малое количество потоков не даст желаемого ускорения.
Найдите оптимальное значение путем нагрузочного тестирования и мониторинга производительности. Начните с небольшого числа (например, 2-3), постепенно увеличивайте и отслеживайте загрузку ресурсов и скорость отправки.
Внешние сервисы рассылки:
Для очень больших объемов рассылок (тысячи или сотни тысяч писем в день) или в ситуациях, когда публичные почтовые сервисы слишком сильно ограничивают, рассмотрите интеграцию с внешними сервисами транзакционной почты или массовых рассылок, такими как SendGrid, Mailgun, UniSender, Postmark и другие. Эти сервисы специализируются на быстрой и надежной доставке писем, имеют:
Интеграция с ними из 1С, как правило, не сложна и осуществляется путем выполнения HTTP-запросов к их API.
Настройка собственного SMTP-сервера:
В корпоративной среде иногда возможно использование собственного или корпоративного SMTP-сервера. Такие серверы могут быть настроены с менее жесткими ограничениями по сравнению с публичными почтовыми сервисами, что дает вам полный контроль над процессом отправки. Это может потребовать дополнительной настройки ИТ-инфраструктуры и администрирования почтового сервера, но обеспечивает максимальную гибкость и пропускную способность.
Использование асинхронных вызовов:
В платформе 1С:Предприятие фоновые задания являются основным инструментом для реализации асинхронных операций. Правильное их использование позволяет выполнять длительные операции, такие как отправка почты, в фоновом режиме, не блокируя основной сеанс пользователя. Это улучшает отзывчивость интерфейса и общее восприятие системы пользователями.
Согласование с ИТ-инфраструктурой:
При планировании и реализации системы массовой рассылки крайне важно тесно сотрудничать с вашим ИТ-отделом. Масштабирование отправки почты может затронуть сетевые политики, настройки фаерволов, нагрузку на корпоративный почтовый сервер и другие аспекты сетевой инфраструктуры. Согласование поможет избежать неожиданных проблем и обеспечить бесперебойную работу.
Параллельная отправка писем из 1С является абсолютно реализуемой и необходимой задачей для эффективной работы с большими объемами рассылок. Используя описанные подходы, такие как управление пулом фоновых заданий, архитектура очередей сообщений или группировка регламентных заданий, а также учитывая важные аспекты оптимизации, мониторинга и отказоустойчивости, вы сможете значительно увеличить скорость и надежность доставки ваших электронных сообщений. Выбор конкретного решения должен основываться на детальном анализе требований к производительности, объемов рассылки и специфики вашей инфраструктуры 1С.