Часто перед техническими специалистами встает задача опубликовать веб-сервис 1С на сервере, который находится в локальной сети, но на котором по тем или иным причинам (политика безопасности, ограничение лицензий, запрет руководства) нельзя устанавливать полную версию платформы 1С:Предприятие. Рассмотрим подробно, как решить эту задачу, какие минимальные компоненты потребуются и как правильно настроить веб-сервер для взаимодействия с базой данных 1С.
Для начала проанализируем, как работает связка «Веб-сервер — 1С». Когда внешний клиент обращается к веб-сервису, запрос принимает веб-сервер (например, Apache или IIS). Однако сам веб-сервер не знает, как обрабатывать специфические запросы к объектам 1С. Для этого ему нужен посредник — специальная динамическая библиотека (DLL), которая входит в состав платформы 1С. Эта библиотека называется «Модули расширения веб-сервера».
Важно понимать: для работы веб-сервиса нам не нужно устанавливать на стороннем сервере «Толстый клиент», «Тонкий клиент» или «Сервер 1С:Предприятия». Нам достаточно только модулей расширения. Выясним, как их развернуть и настроить.
Разберем самый надежный способ. Даже если руководство запрещает ставить «всю 1С», установка только модулей расширения веб-сервера обычно не вызывает возражений, так как это не устанавливает лишних исполняемых файлов или конфигураторов. Рассмотрим шаги по реализации:
bin) появятся необходимые файлы, такие как wsisapi.dll (для IIS) или wsap24.dll (для Apache).Проанализируем преимущества этого подхода: инсталлятор автоматически пропишет необходимые пути в системном реестре и подготовит зависимости. После этого публикацию можно выполнить удаленно через webinst или вручную.
Если запуск инсталлятора запрещен категорически, попробуем «переносной» вариант. Рассмотрим этот процесс по шагам:
Во-первых, подготовим рабочую среду. На компьютере, где 1С уже установлена, найдем каталог с версией платформы. Нам потребуются библиотеки модулей расширения. Для IIS это wsisapi.dll, для Apache 2.4 — wsap24.dll. Скопируем эти файлы на целевой сторонний веб-сервер в отдельную папку.
Во-вторых, создадим файл описания публикации — .vrd (Virtual Resource Descriptor). Это обычный XML-файл, который говорит веб-серверу, к какой базе 1С нужно подключаться. Пример структуры такого файла для серверной базы данных:
<?xml version="1.0" encoding="UTF-8"?>
<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="/MyWebService"
ib="Srvr="1CServerName";Ref="BaseName";">
<ws>
<point name="MyService"
alias="myservice.1cws"
enable="true"
reuseSessions="autouse"
sessionMaxAge="20"
mainLanguage="ru"/>
</ws>
</point>
В параметре ib мы указываем строку соединения с реальным сервером 1С. Таким образом, веб-сервер на «сторонней» машине будет выступать лишь шлюзом, перенаправляя запросы на основной сервер 1С в локальной сети.
Выясним, как упростить процесс настройки без запуска графического интерфейса конфигуратора. Для этого в платформе существует утилита командной строки webinst. Рассмотрим пример команды для публикации веб-сервиса на сервере Apache:
webinst -apache24 -ws -dir "C:\inetpub\wwwroot\my-service" -connstr "Srvr=1CServer;Ref=Base" -confPath "C:\Apache24\conf\httpd.conf"
Разберем параметры этой команды:
-ws — указывает, что мы публикуем именно веб-сервисы.-dir — каталог на диске стороннего сервера, где будет создан файл .vrd.-connstr — строка подключения к информационной базе.-confPath — путь к конфигурационному файлу вашего веб-сервера.Важный момент: утилита должна запускаться от имени администратора, так как она вносит изменения в настройки веб-сервера (например, добавляет LoadModule в Apache или создает приложение в IIS).
Проанализируем частую причину ошибок: «Ошибка доступа» или «Не удалось загрузить библиотеку». При публикации на стороннем сервере крайне важно правильно настроить права. Веб-сервер (процесс httpd.exe в Apache или w3wp.exe в IIS) запускается от имени конкретной учетной записи (например, IUSR или NetworkService).
Этой учетной записи необходимо предоставить полные права на:
.vrd.Кроме того, убедимся, что со стороннего сервера открыты необходимые порты (обычно 1540, 1541, 1560-1591) до основного сервера 1С, иначе библиотеки модулей расширения не смогут передать запрос к базе данных.
Если руководство запрещает размещать даже одну DLL-библиотеку 1С на целевом сервере, рассмотрим вариант с Reverse Proxy. Это наиболее «чистый» с точки зрения администрирования метод.
Суть метода заключается в следующем: мы публикуем веб-сервис стандартным способом на том сервере, где 1С уже установлена и разрешена. А на «стороннем» сервере настраиваем, например, Nginx. Посмотрим на пример конфигурации Nginx, который будет перенаправлять запросы:
server {
listen 80;
server_name external-server.com;
location /my-service/ {
proxy_pass http://internal-1c-server/my-base/ws/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
В этой схеме сторонний сервер вообще не знает о существовании 1С. Он просто получает HTTP-запрос и «проксирует» его внутреннему серверу. Это решает проблему отсутствия платформы и повышает безопасность, скрывая реальный адрес сервера 1С.
После того как публикация выполнена любым из вышеперечисленных способов, проверим работоспособность. Вызов веб-сервиса осуществляется по URL-адресу следующего вида:
http://[Имя_Стороннего_Сервера]/[Имя_Публикации]/ws/[Имя_Веб_Сервиса]?wsdl
Например: http://web-front.local/mybase/ws/ExchangeData?wsdl
Если в браузере открывается XML-описание сервиса (WSDL-файл), значит, публикация прошла успешно. Помните, что для вызова сервиса из программного кода (в 1С это объект WSОпределения) необходимо указывать логин и пароль пользователя 1С, у которого есть права на использование данного веб-сервиса.
Таким образом, мы выяснили, что установка полной платформы на сторонний сервер не требуется. Достаточно либо модулей расширения (DLL), либо настройки проксирования запросов, что позволяет гибко интегрировать 1С в существующую IT-инфраструктуру предприятия.