Почему Web-сервис 1С открывает не ту информационную базу и как это исправить?

← На главную

Часто в процессе разработки и настройки обменов данными между конфигурациями (например, УПП и ЗУП) возникают ситуации, когда при обращении к опубликованному Web-сервису система отрабатывает запрос не в той информационной базе, на которую вы рассчитывали. Разберем по шагам, как выявить причину такого поведения и настроить работу сервисов корректно.

Шаг 1: Проверка файла публикации default.vrd

Первым делом необходимо проверить, куда именно «смотрит» виртуальная директория на сервере IIS. Файл default.vrd является связующим звеном между веб-сервером и информационной базой 1С. Располагается он в каталоге публикации, например, в C:\inetpub\wwwroot\zupbase_tst2\.

Откройте этот файл через любой текстовый редактор. В нем вы увидите структуру XML. Нас интересует атрибут ib. Пример корректной настройки для серверного варианта базы:


<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
        base="/zupbase_tst2"
        ib="Srvr="1C-doc83:2541";Ref="zupbase_tst2";">
</point>

Если в параметре ib указано имя или адрес базы, отличный от того, что вам нужен, значит, либо публикация настроена неверно, либо IIS подхватывает не тот файл, который вы редактируете.

Шаг 2: Диагностика сетевых настроек и параметров подключения

Если содержимое файла default.vrd выглядит правильно, обратим внимание на параметры вызова сервиса из кода 1С. В конфигурации 1С подключение осуществляется через объект WSОпределения. Проанализируйте строку инициализации:


Определение = Новый WSОпределения("http://10.2.15.131/zupbase_tst2/ru_RU/ws/UPP_Exchange?wsdl", ИмяПользователя, Пароль);

Важные моменты для проверки:

Соответствие IP-адреса и имени сервера: Убедитесь, что IP-адрес 10.2.15.131, указанный в коде, ведет именно на тот сервер, где опубликована нужная база.
Порты: Если IIS настроен на нестандартный порт (не 80), его необходимо указывать явно после IP-адреса через двоеточие.
Разрешение DNS: Проверьте, не перенаправляется ли имя сервера 1C-doc83 на другой IP через файл hosts или настройки DNS-сервера.

Шаг 3: Очистка кэша и перезапуск служб

Сервер IIS активно кэширует конфигурации приложений. Если вы внесли изменения в default.vrd, они могут не вступить в силу мгновенно. Рассмотрим способы принудительного обновления:

Для сброса кэша веб-сервера выполните следующие действия:

Откройте командную строку от имени администратора.
Введите команду iisreset и нажмите Enter. Это перезапустит все службы IIS, что заставит сервер перечитать конфигурационные файлы.
В качестве альтернативы можно зайти в «Диспетчер служб IIS», найти пул приложений, соответствующий вашей базе, и выполнить команду «Перезапуск».

Шаг 4: Проверка конфликтов публикаций

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

В диспетчере IIS посмотрите список «Сайты».
Перейдите в раздел «Виртуальные каталоги».
Убедитесь, что для имени zupbase_tst2 существует только одна публикация, и она ссылается на нужный физический путь на диске.
Если возникают сомнения, лучше удалить существующую публикацию через консоль 1С (панель администрирования web-сервисов) и выполнить новую публикацию с уникальным именем. Это исключит вероятность использования «старых» настроек из кэша.

Совет: Если проблема сохраняется, используйте логи IIS в папке C:\inetpub\logs\LogFiles. В них можно найти запись конкретного запроса и увидеть, по какому пути прошел запрос от клиента 1С. Это поможет понять, попадает ли пакет на нужный виртуальный каталог или перенаправляется на другой ресурс.

Следуя этим шагам, вы сможете локализовать причину подмены базы. В 90% случаев проблема кроется либо в кэшировании IIS, либо в расхождении параметров в default.vrd и реального пути к информационной базе в кластере 1С.