Почему HTTP-сервис 1С не обрабатывает первый POST-запрос и как это исправить?

При настройке интеграции 1С со сторонними сервисами (например, Calltouch, Bitrix24 или любыми другими системами через веб-хуки) разработчики часто сталкиваются с загадочным поведением: первый запрос после длительного простоя «пропадает», хотя в Журнале Регистрации видна успешная аутентификация пользователя. При этом последующие запросы, отправленные сразу за первым, отрабатывают корректно. Рассмотрим подробно, почему это происходит и как настроить стабильную работу HTTP-сервиса.

Анализ проблемы: почему «засыпает» сервис

Ситуация, описанная в теме, типична для работы пула соединений веб-сервера (Apache или IIS) и платформы 1С. Когда сторонний сервис отправляет POST-запрос, происходит следующее:

1. Веб-сервер принимает запрос и передает его модулю расширения 1С.
2. Если в пуле сеансов нет готового («живого») сеанса для указанного пользователя, 1С начинает процесс создания нового сеанса.
3. В этот момент выполняется инициализация: проверка лицензий и, что самое важное, исполнение кода в Модуле сеанса.
4. Если процесс инициализации занимает слишком много времени или в коде модуля сеанса происходит ошибка, вызывающая сторона (Calltouch) обрывает соединение по таймауту, не дождавшись ответа.

В итоге мы видим в Журнале Регистрации событие «Аутентификация», но до выполнения метода самого HTTP-сервиса дело не доходит. Рассмотрим по шагам, как локализовать и устранить эту проблему.

Шаг 1. Использование внешних инструментов диагностики

Часто сторонние сервисы выдают малоинформативные ошибки, такие как «Указанный адрес не отвечает». Чтобы понять, что именно возвращает 1С в момент «неудачного» запроса, необходимо воспользоваться инструментами типа Postman или curl. Разберем, как это помогает.

Отправив запрос через Postman, вы сможете увидеть реальный HTTP-статус (например, 500 Internal Server Error) и, что критически важно, тело ответа. В теле ответа 1С часто присылает подробное описание ошибки в формате HTML или JSON, где указано, в какой строке кода произошел сбой при инициализации сеанса.

Шаг 2. Проверка кода в Модуле сеанса

Разберем важный технический нюанс: при вызове HTTP-сервиса 1С не выполняет код модуля управляемого приложения (событие ПриНачалеРаботыСистемы), но всегда выполняет процедуру УстановкаПараметровСеанса в модуле сеанса.

Проанализируем типичную ошибку. Если в УстановкаПараметровСеанса написан код, предполагающий наличие интерактивного пользователя или открытых форм, он выдаст исключение при старте HTTP-сессии. Проверим наш код на наличие подобных конструкций:

Процедура УстановкаПараметровСеанса(ТребуемыеПараметры)
    
    // ОШИБКА: Попытка обращения к параметрам, доступным только в клиенте
    // Если ТекущийПользователь = Неопределено Тогда ...
    
    // Правильный подход: проверка типа соединения
    Инфо = ПолучитьСоединенияИнформационнойБазы();
    // Анализируем тип соединения, чтобы не выполнять лишний код для HTTP
    
КонецПроцедуры

Выясним причину задержки: если в этой процедуре выполняются тяжелые запросы к БД или инициализируются огромные массивы данных, время создания сеанса может превысить 5–10 секунд. Для веб-хука это критично. Рекомендуется максимально облегчить этот модуль для фоновых и HTTP-заданий.

Шаг 3. Тонкая настройка файла публикации (.vrd)

Параметры в файле default.vrd напрямую влияют на то, как часто 1С будет «гасить» сеансы. Рассмотрим настройки, которые помогут избежать частого пересоздания сессий:

1. sessionMaxAge: Этот параметр определяет время жизни сеанса в секундах после последнего обращения. Если установить его в 20 (как в примере автора), то через 20 секунд бездействия сеанс будет уничтожен. Увеличим его до sessionMaxAge="600" (10 минут) или более.
2. poolSize: Количество одновременно удерживаемых «горячих» сессий. Убедимся, что лимит достаточен для вашего трафика.
3. reuseSessions: Значение autouse позволяет платформе эффективно переиспользовать сеансы из пула.

Пример оптимизированной секции сервиса в .vrd:

<service name="calltouch"
         rootUrl="calltouch"
         enable="true"
         reuseSessions="autouse"
         sessionMaxAge="600"
         poolSize="5"
         poolTimeout="10"/>

Шаг 4. Режим отладки на сервере

Проанализируем влияние отладки. Если ваш сервер 1С запущен с ключом -debug, это может существенно замедлять запуск новых сессий. Платформа тратит время на поиск конфигуратора и регистрацию в менеджере отладки. Для рабочих баз, активно использующих HTTP-сервисы, режим отладки на постоянной основе включать не рекомендуется.

Шаг 5. Принудительный «прогрев» сервиса

Если специфика вашей конфигурации не позволяет сделать запуск сеанса мгновенным (например, из-за особенностей архитектуры), применим методику «прогрева». Рассмотрим вариант использования регламентного задания или внешнего скрипта (на стороне сервера), который раз в 5–7 минут отправляет простой GET-запрос к вашему HTTP-сервису.

Это позволит поддерживать хотя бы один сеанс в пуле всегда активным (статус «прогрет»), и когда придет реальный POST-запрос от Calltouch, 1С ответит на него мгновенно, не тратя время на авторизацию и запуск процедур модуля сеанса.

Резюме

Для стабильной обработки POST-запросов выполним следующие действия:

1. Проверим ответ сервиса через Postman, чтобы увидеть текст ошибки инициализации.
2. Оптимизируем процедуру УстановкаПараметровСеанса, исключив из нее тяжелые операции для HTTP-соединений.
3. Увеличим sessionMaxAge в файле публикации до 600 секунд и выше.
4. Отключим режим отладки на сервере, если он не требуется в данный момент.

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