Модуль расширения веб-сервера 1С: что это и зачем он нужен

Модуль расширения веб-сервера 1С — это программный компонент, который устанавливается на веб-сервер (Apache или Microsoft IIS) и обеспечивает связь между браузером пользователя и информационной базой 1С. Без него веб-сервер не понимает, как обрабатывать запросы к опубликованной базе: он умеет отдавать статические страницы, но не знает протокола взаимодействия с платформой 1С:Предприятие.

Когда администратор публикует информационную базу на веб-сервере, платформа регистрирует в конфигурации веб-сервера обращение к этому модулю. Все запросы, поступающие по адресу публикации, модуль перенаправляет в кластер серверов 1С или напрямую в файловую базу, а ответы возвращает клиенту. Так пользователи получают доступ к базе через браузер или тонкий клиент по протоколу HTTP/HTTPS, не устанавливая полную платформу на каждое рабочее место.

Модуль поставляется вместе с платформой 1С:Предприятие как отдельный дистрибутивный компонент. Для Windows это библиотека wsap24.dll (для Apache) или компонент для IIS, для Linux — соответствующий модуль Apache. Его версия должна совпадать с версией платформы, иначе возможны сбои при обращении к базе.

Какую задачу решает модуль расширения

Веб-сервер сам по себе — универсальная программа, которая принимает HTTP-запросы и возвращает ответы. Он ничего не знает о структуре информационных баз 1С, о механизмах сеансов, о том, как вызывать серверные процедуры конфигурации. Модуль расширения добавляет веб-серверу эту «осведомлённость»: он загружается в процесс веб-сервера и перехватывает запросы, адресованные опубликованным базам.

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

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

Из чего состоит механизм публикации

При публикации базы на диске создаётся каталог, в котором размещается файл default.vrd — главный файл настроек публикации. В нём указывается имя публикации, строка подключения к базе, параметры веб-сервисов и HTTP-сервисов, настройки пула соединений. Веб-сервер настраивается так, чтобы запросы к этому виртуальному каталогу обрабатывал модуль расширения.

Публиковать базу можно двумя способами: из конфигуратора (меню «Администрирование — Публикация на веб-сервере») или утилитой командной строки webinst, которая входит в состав платформы. Второй способ удобен для автоматизации и для случаев, когда публикацию нужно выполнить на сервере без графического интерфейса.

Где находится модуль и как он устанавливается

Модуль устанавливается вместе с платформой, если при установке отметить соответствующий компонент — «Модули расширения веб-сервера». В Windows файлы модуля размещаются в каталоге установленной платформы, например в подкаталоге bin конкретной версии. Для Apache используется библиотека wsap24.dll, для IIS регистрируется обработчик ISAPI.

Важный момент: на компьютере с веб-сервером должна быть установлена платформа той же версии, что и версия, под которой работает база. Если кластер серверов обновили, а модуль на веб-сервере забыли обновить, при обращении к базе возникнут ошибки несовместимости версий. Это одна из самых частых причин сбоев после обновления платформы.

На Linux модуль устанавливается из пакетов дистрибутива платформы и подключается в конфигурации Apache директивой LoadModule. После изменения конфигурации веб-сервер необходимо перезапустить, иначе модуль не загрузится.

Как опубликовать базу: порядок действий

Стандартный путь для Windows и IIS выглядит так. Убедитесь, что установлены компоненты IIS, включая поддержку ISAPI-расширений, и компонент «Модули расширения веб-сервера» платформы 1С. Затем откройте конфигуратор под администратором, выберите «Администрирование — Публикация на веб-сервере», укажите имя публикации, веб-сервер и каталог, при необходимости отметьте публикацию веб-сервисов и HTTP-сервисов. После подтверждения платформа создаст каталог с default.vrd и зарегистрирует приложение в IIS.

Для Apache последовательность похожая, но веб-сервер должен быть настроен заранее: загружен модуль 1С, заданы права на каталог публикации. После публикации проверьте результат, открыв в браузере адрес вида http://имя_сервера/имя_публикации. Должна загрузиться страница входа веб-клиента или форма аутентификации.

1. 1
   Установите веб-сервер (IIS или Apache) и компонент «Модули расширения веб-сервера» платформы 1С
2. 2
   Откройте конфигуратор с правами администратора и выберите «Администрирование — Публикация на веб-сервере»
3. 3
   Укажите имя публикации, каталог и нужные сервисы (веб-клиент, веб-сервисы, HTTP-сервисы, OData)
4. 4
   Подтвердите публикацию и перезапустите веб-сервер, если он был настроен вручную
5. 5
   Откройте адрес публикации в браузере и убедитесь, что появляется окно входа в базу

Типичные ошибки и их причины

Самая распространённая проблема — ошибка загрузки модуля веб-сервером. Причины: несовпадение разрядности (64-разрядный веб-сервер и 32-разрядный модуль или наоборот), отсутствие прав у учётной записи пула приложений на каталог публикации и на каталог платформы, неверный путь к модулю в конфигурации.

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

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

Ограничения и когда модуль не нужен

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

Есть и ограничения самого механизма. Файловая база через веб-сервер подходит для небольшого числа одновременных пользователей: вся нагрузка ложится на процесс веб-сервера. Для десятков активных пользователей рекомендуется клиент-серверный вариант, где модуль лишь передаёт запросы в кластер. Кроме того, публикация открывает доступ к базе из сети, поэтому вопросы аутентификации и шифрования трафика нужно решать обязательно.

Варианты доступа к базе

Веб-клиент через модуль расширения

Подходит для удалённых пользователей без установки платформы; требует настройки веб-сервера и защиты канала

Тонкий клиент по HTTP

Даёт более отзывчивый интерфейс, но платформу на рабочее место установить придётся; публикация всё равно обязательна

Тонкий клиент напрямую к кластеру

Быстрее и проще внутри локальной сети, но не работает через веб-сервер и требует доступа к портам кластера

Безопасность публикации

Опубликованная база доступна по сетевому адресу, поэтому минимальный набор мер — включить HTTPS с действующим сертификатом и не публиковать базу в открытый интернет без необходимости. Если внешний доступ нужен, используйте VPN или обратный прокси с дополнительной аутентификацией.

В файле default.vrd не следует хранить пароли в открытом виде без необходимости; для подключения к кластеру лучше использовать учётную запись с минимально достаточными правами. Также ограничьте состав публикуемых сервисов: если HTTP-сервисы и OData не используются, не включайте их публикацию — каждый открытый интерфейс расширяет поверхность атаки.

Как проверить, что всё настроено правильно

Базовая проверка — открыть адрес публикации в браузере. Появление страницы входа означает, что модуль загружен, default.vrd прочитан, соединение с базой установлено. Если вместо этого отображается ошибка веб-сервера (500, 503, 404), смотрите журналы веб-сервера: они покажут, загрузился ли модуль и на каком этапе произошёл сбой.

Дополнительно стоит проверить работу под реальной учётной записью пользователя: войти в базу, открыть типовой документ или отчёт, убедиться, что сеанс не обрывается. Для веб-сервисов проверка — запрос wsdl-описания по адресу сервиса; для OData — запрос корневого адреса с метаданными.

Контрольные точки

Как проверить результат

Открытие адреса публикации в браузере

Норма

Загружается страница входа веб-клиента

Тревожный признак

Ошибка 500/503 или пустая страница — модуль не загружен или нет прав

Вход под учётной записью пользователя

Норма

База открывается, документы и отчёты работают

Тревожный признак

Ошибка соединения с кластером — проверяйте строку подключения в default.vrd

Журнал ошибок веб-сервера

Норма

Нет записей о сбое загрузки модуля

Тревожный признак

Ошибки загрузки wsap24 или ISAPI — проверяйте разрядность и версию платформы

Частые вопросы

Можно ли опубликовать базу без установки платформы на веб-сервер?

Нет. Модуль расширения — часть платформы, поэтому на компьютере с веб-сервером должна быть установлена платформа той же версии, как минимум с компонентом модулей расширения. Кластер серверов при этом может находиться на другой машине.

Чем отличается публикация для Apache и для IIS?

Принцип одинаков: веб-сервер загружает модуль и передаёт ему запросы к виртуальному каталогу. Разница в механизме подключения: для Apache модуль подключается директивой LoadModule в конфигурации, для IIS регистрируется как ISAPI-обработчик. Конфигуратор при публикации сам выполняет нужные настройки для выбранного типа сервера.

Почему после обновления платформы база перестала открываться через браузер?

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

Нужен ли отдельный веб-сервер для каждой базы?

Нет. Один веб-сервер с одним установленным модулем может обслуживать несколько публикаций — каждая база получает собственный виртуальный каталог и свой файл default.vrd. Ограничением служит только производительность сервера.

Безопасно ли публиковать файловую базу на веб-сервере?

Технически это работает, но подходит для небольшого числа пользователей: вся обработка выполняется в процессе веб-сервера. При росте нагрузки следует перевести базу в клиент-серверный вариант. В любом случае обязательны HTTPS и ограничение доступа к публикации.

Что такое default.vrd и можно ли редактировать его вручную?

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