Как настроить регламентное задание 1С для Telegram Bot API без Webhook?

Да, если не использовать Webhook, то в УНФ 3 создается регламентное задание, которое периодически обращается к Telegram Bot API методом getUpdates, получает новые сообщения и передает их в обработчик.

Но есть два разных варианта.

## Вариант 1. Обычный короткий опрос

Регламентное задание запускается, например, раз в 5 или 10 секунд:

Плюсы:

— проще понять и отладить;
— легко реализовать в небольшой обработке.

Минусы:

— постоянные обращения к Telegram;
— лишняя нагрузка на сервер 1С;
— возможны накладки при параллельном запуске;
— при интервале 1 минута бот может отвечать с задержкой до минуты;
— при файловой базе такой вариант особенно нежелателен.

Для рабочего бота я бы не рекомендовал запускать отдельное регламентное задание каждые 5 секунд.

## Вариант 2. Long polling

Это предпочтительный вариант, если Webhook организовать нельзя.

Регламентное задание запускается, например, раз в минуту, но внутри выполняет несколько последовательных запросов с параметром timeout.

Схема:

Примерный режим:

— регламентное задание: раз в 1 минуту;
— таймаут Telegram: 25 или 30 секунд;
— длительность одного запуска задания: не более 50 секунд;
— ключ задания: один и тот же, чтобы параллельные экземпляры не запускались;
— offset: хранится в регистре сведений и увеличивается после успешной обработки обновления.

При наличии сообщения Telegram обычно отвечает сразу, поэтому бот реагирует почти мгновенно. Если сообщений нет, Telegram удерживает HTTP-соединение до окончания таймаута.

## Рекомендуемый вариант для УНФ 3

Для серверной базы:

Важно, чтобы таймаут HTTP-соединения был больше, чем timeout, передаваемый Telegram. Например:

Иначе 1С может закрыть соединение раньше Telegram.

## Почему задание должно завершаться

Не стоит делать бесконечный цикл в регламентном задании:

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

Лучше ограничить время работы:

На практике нужно учитывать, что ТекущаяДата() имеет секундную точность, а длительность самого HTTP-запроса может быть до 30 секунд.

## Пример общей логики регламентного задания

Ниже приведен BSL-код общей схемы. Процедуры получения обновлений и записи состояния являются условными, их нужно реализовать в общем модуле.

Смысл параметров:

## Как правильно сохранять offset

У Telegram каждое обновление имеет update_id.

Например, пришли обновления:

После успешной обработки нужно записать:

При следующем запросе передается:

Тогда Telegram вернет только новые обновления.

Для хранения можно создать регистр сведений:

Измерение:

Ресурс:

Запись:

Лучше хранить offset отдельно для каждого бота, если в базе будет несколько ботов.

## Когда записывать offset

Надежный вариант:

1. получить обновление;
2. обработать сообщение;
3. если обработка завершилась успешно, записать update_id;
4. перейти к следующему сообщению.

Если сначала записать offset, а потом при обработке произойдет ошибка, сообщение будет потеряно.

Однако есть нюанс. Если обработка заказа успела создать документ, а ошибка произошла при записи offset, Telegram-сообщение может прийти повторно. Поэтому обработчик должен быть идемпотентным.

Например, каждое обработанное обновление можно записывать в регистр:

Измерение:

Перед обработкой проверять, не обрабатывалось ли оно ранее.

## Параметры регламентного задания

В конфигураторе для задания можно указать:

Ключ особенно важен. Он не позволит запустить несколько одинаковых обработчиков параллельно.

Если используется серверная база, можно поставить интервал запуска 1 минуту. Если требуется реакция быстрее, например для оформления заказов, можно использовать запуск каждые 30 секунд, но само задание все равно должно завершаться примерно за 20-25 секунд.

Пример:

Но для большинства внутренних задач УНФ достаточно:

Фактическая задержка будет обычно меньше секунды при наличии нового сообщения, а не равна одной минуте, потому что используется long polling.

## Для файловой базы

С файловой базой long polling внутри регламентного задания может быть неудобен:

— длительно работающее задание может мешать другим фоновым заданиям;
— возможны блокировки;
— обработка тяжелых отчетов и заказов будет конкурировать с другими операциями.

Для файловой базы лучше один из вариантов:

1. отдельная внешняя программа или сервис, который получает сообщения от Telegram;
2. Webhook через опубликованный HTTP-сервис;
3. отдельная серверная информационная база для Telegram-интеграции;
4. короткий опрос раз в 30-60 секунд, если требований к скорости нет.

## Webhook вместо регламентного задания

Если база опубликована через HTTPS, лучше использовать Webhook:

В этом случае Telegram сам отправляет POST-запрос при каждом событии. Регламентное задание для получения сообщений не нужно.

Для Webhook потребуются:

— опубликованный HTTP-сервис;
— доступный извне HTTPS-адрес;
— SSL-сертификат;
— настройка setWebhook;
— обработчик POST-запроса;
— защита URL или проверка секретного заголовка.

Для УНФ 3 я бы выбирал так:

| Условия | Вариант |
|—|—|
| Есть сервер 1С и нет возможности публиковать HTTP-сервис | Регламентное задание + long polling |
| Есть HTTPS-публикация базы | Webhook |
| Файловая база | Webhook или отдельный сервис |
| Требуется простой прототип | Регламентное задание раз в минуту |
| Нужна высокая надежность и много пользователей | Webhook + очередь обработки |

То есть для первого рабочего варианта в УНФ 3 можно создать регламентное задание с запуском раз в минуту. Внутри него выполнять long polling с timeout=30, обрабатывать полученные сообщения и завершать работу примерно через 45 секунд. Это даст почти мгновенную реакцию и не потребует опроса Telegram каждые 5 секунд.