Как настроить регламентное задание для отправки почты в 1С при ограничении доступа к серверу Exchange?

← На главную

В корпоративных информационных системах нередко возникает ситуация, когда почтовый сервер (например, Microsoft Exchange) настроен на прием исходящих сообщений по протоколу SMTP только с одного доверенного IP-адреса. При этом пользователи работают в распределенной среде или через клиент-серверную базу 1С, создавая документы электронных писем, которые должны автоматически отправляться во внешний мир.

Разберем, как устроена работа регламентных заданий в платформе 1С, выясним причину сетевых ограничений и рассмотрим несколько надежных вариантов решения этой задачи.

Особенности выполнения фоновых заданий в платформе 1С

Проанализируем поведение регламентных заданий в клиент-серверном варианте работы. В отличие от файлового режима, где для выполнения фоновых задач требуется отдельный сеанс пользователя, в клиент-серверной базе регламентные задания всегда выполняются на стороне кластера серверов 1С в рабочем процессе rphost. Это влечет за собой несколько важных моментов:

IP-адрес отправителя: сетевые пакеты к серверу Exchange пойдут именно с того физического сервера или виртуальной машины, где запущен процесс rphost, выполняющий конкретное фоновое задание. Если доступ разрешен для рабочей станции администратора, а сервер 1С находится на другом узле, регламентное задание завершится сетевой ошибкой таймаута или отказом в соединении.
Контекст учетной записи: задание запускается от имени системной службы кластера (обычно usr1cv8). Если на почтовом сервере используется NTLM или авторизация Windows, у службы должны быть соответствующие права.
Требования назначения функциональности: если в кластере серверов 1С несколько рабочих серверов, регламентное задание может запуститься на любом из них, если явно не заданы настройки назначения функциональности для сервиса фоновых заданий.

Вариант 1. Корректировка сетевых настроек и инфраструктуры

Прежде чем дорабатывать конфигурацию 1С, рассмотрим варианты на уровне системного администрирования. В большинстве случаев ограничение связано с параметрами Receive Connector в Microsoft Exchange, где настроен релей без аутентификации строго по диапазону доверенных IP-адресов.

Наиболее правильный подход — обратиться к системным администраторам почтового сервера и внести IP-адрес сервера 1С в список разрешенных узлов (параметр RemoteIPRanges коннектора получения), либо выделить сервисному пользователю 1С отдельную учетную запись с паролем для аутентификации по SMTP.

Если доступ к настройкам Exchange невозможен, на доверенном компьютере можно настроить локальный SMTP-relay (или перенаправление портов). В этом случае сервер 1С будет отправлять почту на разрешенный компьютер, а тот — пересылать сообщения в Exchange от своего доверенного имени.

Вариант 2. Реализация регламентного задания в конфигурации 1С

Если сервер 1С имеет прямой доступ к почтовому серверу, задача сводится к созданию регламентного задания. Рассмотрим типовые ошибки, которые часто допускают разработчики при написании подобного функционала, и напишем правильный код.

Посмотрим на пример кода с грубыми ошибками:


// Неоптимальный подход с ошибками:
Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |   ЭлектронноеПисьмо.Номер
    |ИЗ
    |   Документ.ЭлектронноеПисьмо КАК ЭлектронноеПисьмо
    |ГДЕ
    |   ЭлектронноеПисьмо.СтатусПисьма = ЗНАЧЕНИЕ(Перечисление.СтатусыПисем.Исходящее)";

Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
    док = Документы.ЭлектронноеПисьмо.НайтиПоНомеру(Выборка.Номер);
    док.ПолучитьОбъект().ОтправитьПисьмо();
КонецЦикла;

Проанализируем слабые места этого фрагмента:

Изменение типовых модулей: никогда не следует встраивать собственный код в типовые процедуры обновления или общие модули конфигурации. Необходимо создать отдельный нетиповой общий модуль (например, Кастом_ЭлектроннаяПочтаСервер) с признаками выполнения Сервер и Вызов сервера. Это позволит избежать потери изменений при обновлении типовой конфигурации.
Поиск по номеру: поиск документа по номеру внутри цикла порождает лишние запросы к базе данных, замедляет выполнение и может вернуть не тот документ при дублировании номеров в разных периодах. В запросе всегда нужно выбирать поле Ссылка.
Отсутствие обработки ошибок: если при отправке одного письма возникнет ошибка (например, некорректный адрес получателя или слишком большой файл вложения), всё регламентное задание прервется по аварии, а остальные письма в очереди останутся неотправленными. Вызов отправки обязательно должен оборачиваться в конструкцию Попытка ... Исключение.
Риск дублирования отправки: чтобы при длительной отправке повторный запуск регламентного задания не отправил те же сообщения дважды, статус документа необходимо менять на промежуточный (или фиксировать факт начала обработки).

Разберем правильный вариант реализации процедуры для регламентного задания:


Процедура ОтправитьИсходящуюПочту() Экспорт

    Если НЕ Константы.ИспользованиеВстроенногоПочтовогоКлиента.Получить() Тогда
        Возврат;
    КонецЕсли;

    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |   Письмо.Ссылка КАК Ссылка
        |ИЗ
        |   Документ.ЭлектронноеПисьмо КАК Письмо
        |ГДЕ
        |   Письмо.СтатусПисьма = ЗНАЧЕНИЕ(Перечисление.СтатусыПисем.Исходящее)
        |   И НЕ Письмо.ПометкаУдаления";

    Выборка = Запрос.Выполнить().Выбрать();

    Пока Выборка.Следующий() Цикл
        
        Попытка
            ОбъектПисьма = Выборка.Ссылка.ПолучитьОбъект();
            Если ОбъектПисьма <> Неопределено Тогда
                // Вызываем метод отправки документа
                ОбъектПисьма.ОтправитьПисьмо();
            КонецЕсли;
        Исключение
            // Записываем ошибку в журнал регистрации для дальнейшего анализа
            ЗаписьЖурналаРегистрации(
                "Отправка почты",
                УровеньЖурналаРегистрации.Ошибка,
                Метаданные.Документы.ЭлектронноеПисьмо,
                Выборка.Ссылка,
                ОписаниеОшибки()
            );
        КонецПопытки;

    КонецЦикла;

КонецПроцедуры

После создания процедуры в общем модуле добавим в ветку конфигурации РегламентныеЗадания новое задание, укажем в качестве метода вызова нашу процедуру и настроим необходимое расписание (например, каждые 5 минут).

Вариант 3. Использование внешней обработки на доверенной машине

Если изменить правила сетевого экрана или настройки Exchange невозможно, а сервер 1С не имеет доступа к почтовику, остается путь запуска сеанса с той машины, которой отправка разрешена:

Создаем внешнюю обработку (или обработку в составе конфигурации), модуль которой выбирает неотправленные документы и выполняет отправку.
В операционной системе разрешенного компьютера открываем стандартный Планировщик заданий Windows.
Создаем регламентную задачу с расписанием запуска исполняемого файла 1cv8.exe со специальными командными ключами: ENTERPRISE /S "Сервер1С\ИмяБазы" /N "ПочтовыйБот" /P "Пароль" /Execute "C:\Scripts\SendMail.epf".
При открытии обработки в обработчике ПриОткрытии инициируется процедура отправки, по завершении которой вызывается метод ЗавершитьРаботуСистемы(Ложь).

Такой подход позволяет обойти ограничения сетевой топологии без сложных манипуляций с портами и маршрутизацией.