Почему в 1С могут самопроизвольно отключаться расширения конфигурации при работе через веб-сервер?

← На главную

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

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

Анализ ситуации: симптомы и условия возникновения ошибки

Рассмотрим типовой сценарий, в котором проявляется данная проблема. Как правило, это рабочие места с высокой интенсивностью использования, например, кассовые зоны в магазинах («1С:Розница») или склады. Компьютеры не выключаются сутками, сеанс 1С открыт постоянно. База опубликована на веб-сервере IIS, используется тонкий клиент, а сама информационная база может быть как файловой, так и клиент-серверной.

Проблема проявляется следующим образом: отладчик показывает, что выполнение кода просто не заходит в процедуры, аннотированные как &Вместо, &Перед или &После. Основная конфигурация работает, но слой расширения становится «прозрачным». Это особенно критично для версий платформы ниже 8.3.14, где механизмы динамического подключения метаданных через HTTP-протокол еще не были достаточно отлажены.

Причина №1: Рециркуляция пула приложений IIS

Одной из главных причин «исчезновения» расширения является механизм работы веб-сервера IIS. По умолчанию в настройках пула приложений (Application Pool) включена периодическая рециркуляция (перезапуск рабочих процессов). Это происходит либо по расписанию (раз в 1740 минут), либо при достижении определенных лимитов памяти.

Разберем по шагам, что происходит в этот момент:

IIS завершает старый рабочий процесс w3wp.exe, в котором крутилось соединение с 1С.
Тонкий клиент 1С обнаруживает разрыв соединения и пытается его восстановить («прозрачное» восстановление сеанса).
На старых релизах платформы (например, 8.3.10) при таком быстром восстановлении сеанса через веб-сервер инициализация расширений может пройти некорректно. Основной контекст конфигурации подтягивается из кэша сервера, а компиляция модулей расширения игнорируется.

Для стабилизации ситуации проанализируем настройки IIS. Рекомендуется увеличить интервал рециркуляции или вовсе отключить его (установив значение 0), если база используется круглосуточно. Также стоит проверить параметр «Idle Time-out» (тайм-аут бездействия), который по умолчанию составляет 20 минут.

Причина №2: Особенности кэширования метаданных в тонком клиенте

Даже при работе через веб-сервер тонкий клиент активно использует локальный кэш на компьютере пользователя (папки %LocalAppData%\1C\1cv8). В этих папках хранятся скомпилированные образы расширений. При длительной работе без перезапуска программы может возникнуть ситуация, когда связь между идентификатором сеанса и локальным кэшем метаданных нарушается.

Поскольку расширение является «надстройкой» над основной конфигурацией, при возникновении любой ошибки доступа к файлам кэша расширения платформа может принять решение продолжить работу без него, чтобы не прерывать сеанс пользователя полностью. В результате мы видим работающую программу, но без функционала расширения.

Причина №3: Проблемы файла публикации default.vrd

Файл default.vrd управляет параметрами публикации базы на веб-сервере. Если в нем неверно настроено управление пулом соединений, это может приводить к преждевременному разрыву связи. Посмотрим на структуру секции point. Для повышения стабильности работы расширений можно попробовать явно указать параметры пула.

Пример структуры файла default.vrd с параметрами пула:


<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       base="/MyBase"
       ib="Srvr=MyServer;Ref=MyBase;">
    <pool size="10" timeout="600" />
</point>

Параметр pool size определяет количество удерживаемых соединений, а timeout — время их жизни в секундах. Правильная настройка пула позволяет избежать «дребезга» соединений, который часто становится причиной потери контекста расширения.

Как лечить: пошаговые рекомендации

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

Обновление платформы. Это наиболее радикальный и эффективный способ. Начиная с версий 8.3.14 и выше, работа с расширениями через HTTP была существенно переработана. Исправлены баги, связанные с потерей метаданных при восстановлении сессии.
Программный перезапуск сеанса. Если обновить платформу невозможно, внедрим в систему механизм принудительного завершения работы. Например, можно использовать обработчик ожидания, который в 3 часа ночи будет закрывать программу. Это гарантирует, что каждое утро кассир или оператор будет заходить в базу «с нуля», инициализируя все расширения.

Рассмотрим пример кода для принудительного закрытия системы:


Процедура ПриУстановкеПараметровСеанса(ТребуемыеПараметры)
    // Код проверки времени
    ТекущийЧас = Час(ТекущаяДата());
    Если ТекущийЧас = 3 Тогда 
        ЗавершитьРаботуСистемы(Ложь);
    КонецЕсли;
КонецПроцедуры

Настройка исключений антивируса. На сервере, где развернут IIS, антивирусное ПО может блокировать временные файлы расширений с расширениями .cmi и .cref. Проанализируем логи антивируса и добавим папку с базой (для файлового варианта) и временные папки системы в исключения.
Перенос кода в основную конфигурацию. Если стабильность критически важна, а расширение постоянно «отваливается», стоит рассмотреть совет опытных разработчиков: временно перенести критически важные изменения из расширения непосредственно в основную конфигурацию. Это лишит систему гибкости при обновлениях, но полностью устранит риск внезапного отключения функционала.
Использование толстого клиента. Если сетевая инфраструктура позволяет, попробуем подключиться к базе не через веб-сервер (HTTP), а напрямую через протокол TCP (если это серверный вариант) или через сетевой путь (если файловый). Как показывает практика, расширения работают гораздо стабильнее при прямом подключении к серверу 1С.

Резюме

Выясним причину окончательно: нестабильность расширений на веб-сервере в старых версиях 1С связана с некорректной обработкой восстановления HTTP-сессий. Система пытается сэкономить ресурсы и восстановить соединение без полной переинициализации метаданных, что приводит к потере слоя расширения.

Для исправления ситуации мы рекомендуем в первую очередь обновить платформу до актуального релиза. Если это невозможно — настройте параметры пула в IIS и обеспечьте регулярный перезапуск клиентских приложений (хотя бы раз в сутки). Это позволит избежать накопления ошибок в кэше и обеспечит бесперебойную работу расширений.