Как опубликовать несколько веб-сервисов 1С на одном веб-сервере Apache или IIS без конфликтов

← На главную

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

Часть 1. Публикация нескольких баз на веб-сервере Apache

Основная ошибка при публикации нескольких баз на Apache — использование одной и той же директории на диске или перезапись конфигурационного файла. Давайте разберем правильный алгоритм действий по шагам.

Шаг 1. Создание раздельных каталогов на диске

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

C:\inetpub\wwwroot\base_prod — для рабочей базы;
C:\inetpub\wwwroot\base_test — для тестовой базы.

Шаг 2. Публикация баз с уникальными именами (алиасами)

При публикации через конфигуратор 1С (Администрирование -> Публикация на веб-сервере) или через утилиту командной строки webinst обязательно указывайте разные имена публикаций и разные каталоги:

Для первой базы: Имя = base_prod, Каталог = C:\inetpub\wwwroot\base_prod
Для второй базы: Имя = base_test, Каталог = C:\inetpub\wwwroot\base_test

Шаг 3. Анализ конфигурационного файла httpd.conf

После публикации конфигуратор автоматически вносит изменения в файл конфигурации Apache httpd.conf. Проанализируем, как должна выглядеть правильная структура описания баз в этом файле. Для каждой базы должен быть создан свой блок Alias и соответствующие директивы доступа:


# Настройки для первой базы (Рабочая)
Alias "/base_prod" "C:/inetpub/wwwroot/base_prod/"
<Directory "C:/inetpub/wwwroot/base_prod/">
    AllowOverride None
    Options None
    Require all granted
    SetHandler 1c-application
    ManagedApplicationDescriptor "C:/inetpub/wwwroot/base_prod/default.vrd"
</Directory>

# Настройки для второй базы (Тестовая)
Alias "/base_test" "C:/inetpub/wwwroot/base_test/"
<Directory "C:/inetpub/wwwroot/base_test/">
    AllowOverride None
    Options None
    Require all granted
    SetHandler 1c-application
    ManagedApplicationDescriptor "C:/inetpub/wwwroot/base_test/default.vrd"
</Directory>

Обратите внимание: каждая директория ссылается на свой собственный файл дескриптора публикации default.vrd. Если пути настроены верно, веб-сервисы обеих баз будут успешно запущены и доступны по адресам:

http://имя_сервера/base_prod/ws/ИмяСервиса?wsdl
http://имя_сервера/base_test/ws/ИмяСервиса?wsdl

---

Часть 2. Публикация на веб-сервере IIS и решение проблемы конфликта пулов

При работе с IIS администраторы часто сталкиваются со специфической проблемой: если опубликовать две базы (например, рабочую и тестовую) с одинаковыми именами веб-сервисов и одинаковыми пространствами имен, то работать будет только та база, к которой обратились первой. Второй запрос вернет пустую страницу или ошибку соединения.

Выясним причину проблемы

По умолчанию IIS запускает все веб-приложения 1С в рамках одного общего пула приложений (обычно это DefaultAppPool), который использует один и тот же рабочий процесс w3wp.exe. Из-за этого библиотеки расширения 1С смешивают кэш веб-сервисов разных баз в оперативной памяти одного процесса.

Решение: Изоляция пулов приложений IIS

Для стабильной работы необходимо разнести приложения 1С по разным пулам. Выполним настройку по шагам:

Откройте Диспетчер служб IIS (IIS Manager).
В левом дереве выберите раздел Пулы приложений (Application Pools).
В панели действий нажмите Добавить пул приложений (Add Application Pool).
Создайте два пула с понятными именами, например: Pool_Base_Prod и Pool_Base_Test. Укажите версию .NET CLR (обычно "Без управляемого кода").
Перейдите в раздел Сайты (Sites) -> Default Web Site и найдите ваши опубликованные приложения 1С (base_prod и base_test).
Нажмите правой кнопкой мыши на приложение base_prod, выберите Управление приложением (Manage Application) -> Дополнительные параметры (Advanced Settings).
В поле Пул приложений (Application Pool) выберите только что созданный пул Pool_Base_Prod.
Повторите аналогичную операцию для приложения base_test, назначив ему пул Pool_Base_Test.

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

---

Часть 3. Сложные сценарии администрирования веб-сервисов

1. Работа с разными версиями платформы 1С на одном сервере

Если ваши базы работают на разных версиях платформы 1С (например, одна на 8.3.21, а другая на 8.3.23), возникает аппаратное ограничение веб-серверов. Один экземпляр веб-сервера (Apache или IIS) может загрузить в свою память только один модуль расширения веб-сервера (wsap24.dll для Apache или wsisapi.dll для IIS).

Как решить эту проблему на Apache:

Рекомендуется установить два независимых экземпляра службы Apache на одном физическом сервере. Например, первый Apache будет слушать стандартный порт 80 и использовать модуль расширения от платформы 8.3.21. Второй Apache настраивается на порт 8080 и загружает модуль платформы 8.3.23. В файле конфигурации каждого экземпляра прописывается путь к соответствующей библиотеке:


# Для первого экземпляра Apache (Платформа 8.3.21):
LoadModule _1cws_module "C:/Program Files/1cv8/8.3.21.1607/bin/wsap24.dll"

# Для второго экземпляра Apache (Платформа 8.3.23):
LoadModule _1cws_module "C:/Program Files/1cv8/8.3.23.1865/bin/wsap24.dll"

Как решить эту проблему на IIS:

В IIS данная задача решается через сопоставление обработчиков (Handler Mappings). Вы можете настроить привязку обработчика к конкретной библиотеке wsisapi.dll не на уровне всего сервера, а индивидуально для каждого приложения (базы) внутри своего пула. Это позволяет запускать приложения разных версий 1С в рамках одного IIS без установки дополнительных служб.

2. Обратная задача: одна база на двух разных веб-серверах

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

При такой схеме работы важно соблюдать три правила:

Единая точка подключения: Оба веб-сервера в файлах настроек публикации default.vrd должны быть жестко привязаны к одному и тому же кластеру серверов 1С и одной базе данных. Строка подключения ib должна быть идентичной: ib="Srvr="1c-cluster-main";Ref="production_db";"
Настройка липких сессий (Sticky Sessions): Если перед веб-серверами установлен балансировщик нагрузки (например, Nginx или HAProxy), его необходимо настроить так, чтобы запросы одного клиента в рамках одной сессии всегда отправлялись на один и тот же веб-сервер. В противном случае сеансы пользователей будут постоянно обрываться.
Синхронизация конфигураций: Любые изменения в составе веб-сервисов (добавление новых методов, изменение пространства имен) требуют одновременного обновления файлов default.vrd на всех веб-серверах.

Важное предупреждение безопасности: Публикация одной базы на нескольких веб-серверах абсолютно безопасна, так как веб-серверы выполняют роль лишь "транспортных узлов". Однако категорически запрещено подключать к одной СУБД (MS SQL, PostgreSQL) два разных независимых кластера серверов 1С одновременно. Это гарантированно приведет к разрушению структуры базы данных и потере информации из-за рассинхронизации системных кэшей и транзакционных блокировок.