Как опубликовать сервис 1С на веб-сервере

Публикация сервиса 1С — это настройка связки «веб-сервер + расширение 1С», после которой информационная база и её веб-сервисы (HTTP-сервисы, стандартный интерфейс OData, веб-клиент) становятся доступны из браузера или из внешних систем по HTTP/HTTPS. Без публикации веб-сервисы, описанные в конфигурации, физически не принимают запросы: их обработчиком выступает модуль веб-сервера, который передаёт вызовы в платформу 1С.

Задача решается двумя путями: публикацией через диалог конфигуратора «Администрирование → Публикация на веб-сервере» либо ручным созданием файла описания публикации default.vrd и настройкой виртуального каталога. Первый способ быстрее и подходит для типовых сценариев, второй даёт полный контроль над параметрами и нужен при нестандартных требованиях — например, когда публиковать нужно только часть сервисов или база работает в кластере с несколькими рабочими серверами.

Ниже разобраны оба подхода на примере Windows с IIS и Linux/Windows с Apache, порядок проверки результата, типичные ошибки и ограничения, о которых нужно знать до начала работ.

Что подготовить перед публикацией

До открытия диалога публикации убедитесь, что на машине с веб-сервером установлен компонент платформы «Расширение веб-сервера» (модуль wsap для Apache или ISAPI-расширение для IIS). Он ставится тем же дистрибутивом платформы 1С — при установке нужно отметить соответствующий пункт. Разрядность модуля и веб-сервера должна совпадать: для 64-разрядного Apache берите 64-разрядный модуль расширения.

Для IIS потребуются включённые компоненты Windows: сама служба веб-сервера, ASP.NET/ISAPI-расширения и ISAPI-фильтры. Для Apache рекомендуется версия 2.4 — с ней работают актуальные версии платформы. Также проверьте, что учётная запись, под которой выполняется публикация, имеет права администратора на машине веб-сервера, иначе конфигуратор не сможет изменить настройки IIS или записать файлы в системные каталоги.

Определите заранее: имя публикации (латиницей, без пробелов — оно станет частью URL), каталог на диске, где будут лежать файлы публикации, и список того, что именно публикуется: тонкий/веб-клиент, веб-сервисы, HTTP-сервисы, стандартный интерфейс OData, WebDAV. Публикация лишнего увеличивает поверхность атаки и нагрузку.

Публикация через конфигуратор

Стандартный сценарий выглядит так. Откройте конфигуратор под пользователем с правами администратора информационной базы, перейдите в меню «Администрирование → Публикация на веб-сервере». В диалоге укажите имя публикации, тип веб-сервера (IIS или Apache), каталог публикации и отметьте нужные флажки: «Публиковать тонкий клиент и веб-клиент», «Публиковать Web-сервисы», «Публиковать HTTP-сервисы», «Публиковать стандартный интерфейс OData».

На закладках «Web-сервисы» и «HTTP-сервисы» можно выборочно отключить отдельные сервисы и изменить их псевдонимы. Псевдоним — это имя, под которым сервис виден в URL; если его не менять, используется имя из конфигурации. После нажатия «Опубликовать» конфигуратор создаст в указанном каталоге файл default.vrd и вспомогательные файлы, а для IIS — виртуальный каталог с настроенным обработчиком. Для Apache потребуется вручную перезапустить службу, чтобы она подхватила изменения конфигурации.

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

Ручная публикация через default.vrd

Файл default.vrd — это XML-описание публикации. Ручной вариант нужен, когда конфигуратор недоступен (публикация выполняется на отдельном сервере без установленного клиента), когда требуется публикация одного и того же сервиса под разными именами или когда настройки нужно версионировать и разворачивать скриптами.

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

<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://v8.1c.ru/8.3/virtual-resource-system"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
name="MyBase"
ib="Srvr=&quot;Server1C&quot;;Ref=&quot;MyBase&quot;;">
<ws name="Exchange" alias="exchange.1cws"/>
</point>

Для IIS виртуальный каталог создаётся в оснастке диспетчера служб IIS: указывается физический путь к каталогу с default.vrd, в сопоставлениях обработчиков регистрируется ISAPI-модуль платформы. Для Apache в httpd.conf добавляется загрузка модуля wsap24.so (или wsap24.dll) и блок Alias с обработчиком 1cws на каталог публикации.

LoadModule _1cws_module "C:/Program Files/1cv8/8.3.22.1750/bin/wsap24.dll"
Alias "/MyBase" "C:/inetpub/MyBase"
<Directory "C:/inetpub/MyBase">
    AllowOverride All
    Require all granted
    SetHandler 1cws-application
    ManagedApplicationDescriptor "C:/inetpub/MyBase/default.vrd"
</Directory>

Настройка IIS и Apache: различия

Конфигуратор умеет самостоятельно настраивать IIS: создаёт виртуальный каталог, назначает пул приложений и регистрирует обработчик. С Apache автоматика ограничивается записью фрагмента конфигурации — файл httpd.conf нужно править вручную, а службу перезапускать после каждого изменения. Поэтому на Windows для быстрой публикации чаще выбирают IIS, а Apache используют там, где веб-сервер уже работает на Linux или требуется кроссплатформенность.

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

Публикация веб-сервисов, HTTP-сервисов и OData

У каждого типа сервиса свой URL-шаблон. Веб-сервис (SOAP) доступен по адресу http://сервер/ИмяБазы/ws/ИмяСервиса, а его WSDL-описание — по тому же адресу с параметром ?wsdl. HTTP-сервисы отвечают по шаблону http://сервер/ИмяБазы/hs/КорневойURL/ШаблонURL, где корневой URL задаётся в свойствах HTTP-сервиса в конфигураторе. Стандартный интерфейс OData открывается по адресу http://сервер/ИмяБазы/odata/standard.odata.

Отдельный нюанс — аутентификация. По умолчанию веб-сервисы работают с аутентификацией 1С (имя и пароль пользователя информационной базы), которая передаётся через Basic-аутентификацию HTTP. Для анонимного доступа в default.vrd можно задать пользователя по умолчанию, но делать это стоит только для публичных справочных сервисов без доступа к чувствительным данным. Для OData права применяются как к обычному пользователю: интерфейс отдаст только те объекты, на чтение которых у пользователя есть права.

Типичные ошибки и их устранение

Большинство проблем публикации сводится к нескольким повторяющимся причинам. Ошибка 404 при корректном адресе обычно означает, что виртуальный каталог не создан или имя публикации в URL не совпадает с именем в настройках (регистр символов в IIS не важен, в Apache на Linux — важен). Ошибка 500 при обращении к любому ресурсу публикации чаще всего говорит о том, что модуль расширения не загрузился: несовпадение разрядности, отсутствие библиотек платформы или неверный путь к модулю в конфигурации.

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

Ограничения и безопасная эксплуатация

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

Для выхода в интернет минимальный набор защиты: HTTPS с действующим сертификатом, отдельный пользователь 1С с минимально необходимыми правами для каждой внешней системы, отключение неиспользуемых публикаций (веб-клиент, если нужен только обмен), ограничение доступа по IP на уровне веб-сервера или межсетевого экрана, где это возможно. Журналы веб-сервера и технологический журнал 1С позволяют отследить источник ошибок и подозрительные обращения.

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