При работе с современными конфигурациями 1С:Предприятие использование расширений стало стандартом де-факто. Однако при публикации базы на веб-сервере (IIS или Apache) системные администраторы часто сталкиваются с парадоксальной ситуацией: через обычный браузер (веб-клиент) база открывается и работает корректно, а при попытке подключения через тонкий клиент возникает критическая ошибка. В этой статье мы подробно разберем, почему это происходит, и проанализируем последовательность действий для восстановления работоспособности системы.
Первое, на что стоит обратить внимание — это разница в механизмах загрузки метаданных. Веб-клиент интерпретирует интерфейс постепенно, в то время как тонкий клиент при запуске пытается получить полную структуру конфигурации, включая все активные расширения. Если на этом этапе происходит сбой, запуск прерывается.
Рассмотрим первоочередные настройки в самой информационной базе. Часто проблема кроется в безопасном режиме или защите от опасных действий. Разберем по шагам, как проверить эти параметры:
Безопасный режим и флажок Защита от опасных действий.Важно понимать, что работа расширения в безопасном режиме накладывает ограничения на использование некоторых методов и функций (например, работу с файловой системой или внешними компонентами). Если код расширения обращается к таким ресурсам при запуске через тонкий клиент, сервер может разорвать соединение.
Одной из скрытых причин проблем с публикацией является наличие в системе сразу двух веб-серверов. Разберем ситуацию, когда в операционной системе установлены и Apache, и IIS (Internet Information Services). Часто возникает путаница: публикация выполняется для одного сервера, а по факту запросы обрабатываются другим или вовсе блокируются.
Выясним причину конфликта. Если в конфигураторе 1С при выполнении публикации выбран Apache, но соответствующая служба в Windows не запущена, а порт (обычно 80 или 443) занят службой IIS, тонкий клиент не сможет корректно инициализировать сессию. В этом случае мы рекомендуем придерживаться следующего алгоритма действий:
World Wide Web Publishing Service запущена.При использовании IIS критически важно, чтобы пул приложений имел права доступа к каталогу с платформой 1С. Разберем подробнее: пользователь, от имени которого работает IIS (например, IUSR или IIS AppPool\ИмяПула), должен обладать правами на «Чтение и выполнение» в папке C:\Program Files\1cv8\номер_версии\bin. Без этого компоненты расширения могут не загрузиться в поток данных HTTP.
Файл default.vrd — это связующее звено между веб-сервером и платформой 1С. Посмотрим на его структуру, особенно на секцию, отвечающую за расширения. Иногда автоматическая публикация не прописывает необходимые параметры, что приводит к ошибкам в тонком клиенте.
Проанализируем пример корректного блока расширений в файле default.vrd:
<extensions>
<extension name="MyExtension" active="true" />
<allExtensions buildStyles="true" />
</extensions>
Обратим внимание на параметр allExtensions="true" (или его наличие в новых версиях платформы). Если этот параметр установлен, сервер будет передавать тонкому клиенту все активные расширения. Если же в файле жестко прописаны имена расширений, которые были удалены или переименованы, тонкий клиент выдаст ошибку при попытке их сопоставления.
Если после перепубликации базы на сервере ошибка в тонком клиенте сохраняется, необходимо проанализировать состояние локального кэша пользователя. В отличие от браузера, который обновляет данные при нажатии Ctrl+F5, тонкий клиент хранит структуру конфигурации и расширений в локальных папках %AppData%\Local\1C и %AppData%\Roaming\1C.
Рассмотрим процесс очистки кэша для исправления проблем с расширениями:
Посмотрим на ситуацию с точки зрения версионности. Расширения крайне чувствительны к версии платформы. Если база была опубликована на версии 8.3.12, а расширение разработано или сконвертировано под 8.3.15, веб-сервер может некорректно передавать бинарные данные расширения. Всегда проверяйте, чтобы версия модуля расширения веб-сервера (например, isapi_1cws.dll для IIS или mod_wsap24.so для Apache) в точности соответствовала версии платформы, на которой работает сервер приложений или файловая база.
Иногда причиной сбоя расширений становятся сетевые экраны. Расширения увеличивают объем передаваемых метаданных. Выясним, как это влияет на стабильность соединения. Если в расширении содержатся объемные макеты или картинки, HTTP-пакеты становятся значительно тяжелее. Некоторые антивирусы или прокси-серверы могут расценивать такие специфические запросы 1С как подозрительные и обрывать их.
Для диагностики мы рекомендуем временно отключить сетевой экран на сервере и клиенте и проверить запуск. Если база запускается — необходимо добавить исключения для процессов 1cv8c.exe на клиенте и процессов веб-сервера на хосте.
Подводя итог, можно сказать, что решение проблемы чаще всего кроется в чистой перепубликации информационной базы на корректно настроенном веб-сервере (предпочтительно IIS для Windows-сред) с последующей очисткой локальных кэшей тонкого клиента. Тщательная проверка файла default.vrd и прав доступа к bin-директории платформы гарантирует стабильную передачу расширений конечному пользователю.