Почему возникает ошибка 400 при подключении к веб-сервису через WSОпределения в 1С и как ее исправить?

← На главную

При интеграции различных конфигураций 1С или внешних систем часто используется механизм Web-сервисов (SOAP). На этапе инициализации подключения разработчики нередко сталкиваются с ситуацией, когда попытка получить описание сервиса через конструктор WSОпределения завершается сбоем:

Ошибка при вызове конструктора (WSОпределения): При создании описания сервиса произошла ошибка. URL сервиса: http://127.0.0.1/.../DataExch.1cws?wsdl Код ответа сервера: 400

При этом при переходе по тому же самому адресу через обычный браузер WSDL-схема отображается корректно и без ошибок. Разберем по шагам, почему возникает такое поведение платформы и как настроить стабильное соединение.

Причина 1. Ограничение учебной версии платформы 1С

Проанализируем специфику работы платформы при локальной разработке. Если база опубликована на локальном веб-сервере (например, Apache или IIS) и используется учебная версия платформы, действует жесткое системное ограничение: запрещена одновременная работа нескольких сеансов с одной информационной базой.

Когда мы выполняем вызов веб-сервиса программно, происходят следующие события:

Открыт клиентский сеанс в режиме 1С:Предприятие или Конфигуратор.
Программа отправляет запрос к веб-серверу для получения схемы или выполнения операции.
Модуль веб-сервера 1С пытается запустить новый отдельный сеанс (веб-сеанс) для обработки входящего запроса.
Учебная платформа видит попытку открытия второго параллельного сеанса и блокирует его, возвращая веб-серверу внутреннюю ошибку, которая клиенту отдается в виде кода HTTP 400 или HTTP 500.

Способы решения:

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

Причина 2. Влияние системного прокси-сервера

По умолчанию конструктор WSОпределения обращается к сети с использованием системных настроек прокси операционной системы. Если в Windows включен корпоративный или сторонний прокси, запрос по локальному адресу 127.0.0.1 или localhost может перенаправляться во внешнюю сеть, что приводит к некорректному ответу и ошибке Код ответа сервера: 400.

Посмотрим на пример правильного отключения прокси-сервера через объект ИнтернетПрокси:


// Создаем объект прокси с параметром Ложь (не использовать системный прокси)
Прокси = Новый ИнтернетПрокси(Ложь);

URL = "http://127.0.0.1/Control/ws/DataExch.1cws?wsdl";
ИмяПользователя = "Администратор";
ПарольПользователя = "12345";
Таймаут = 30;

// Передаем объект Прокси в конструктор WSОпределения
ВС = Новый WSОпределения(URL, ИмяПользователя, ПарольПользователя, Прокси, Таймаут);

Причина 3. Настройки Apache и сброс заголовков авторизации

При использовании веб-сервера Apache модуль авторизации может автоматически обрезать заголовок Authorization, из-за чего данные пользователя 1С не достигают публикации. В результате веб-сервер не может авторизовать запрос к WSDL-схеме.

Выясним причину в конфигурации веб-сервера. Для корректной проброски авторизационных заголовков откройте файл конфигурации Apache (httpd.conf) и добавьте следующую директиву:

SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

Также проверьте файл публикации базы default.vrd. Убедитесь, что секция веб-сервисов активна:


<point name="Control"
        alias="Control"
        base="C:\Bases\Control"
        enable="default">
    <ws enable="true"/>
</point>

Причина 4. Права доступа к файловой базе данных

Если база данных файловая (1Cv8.1CD), служба веб-сервера (Apache или IIS) выполняет обращение к файлам базы от имени системного пользователя (например, SYSTEM, IUSR или пользователя службы). Если у этой учетной записи нет прав на запись и изменение каталога с базой, подключение к сервису будет падать с ошибкой.

Разберем требования к файловой базе:

Назначьте пользователю, от имени которого запущена служба веб-сервера, полные права на папку с базой данных 1С.
Убедитесь, что база не открыта в монопольном режиме (например, при реструктуризации таблиц или сравнении/объединении конфигураций).

Альтернативные способы работы с веб-сервисами

Если динамическое получение схемы через URL вызывает трудности или снижает производительность программы, рассмотрим альтернативные подходы:

Загрузка WSDL из локального файла:
Схему WSDL можно один раз открыть в браузере, сохранить как файл на локальный диск (например, DataExch.wsdl) и передать путь к файлу в конструктор:
```
ПутьКФайлу = "C:\WSDL\DataExch.wsdl";
ВС = Новый WSОпределения(ПутьКФайлу, "Логин", "Пароль");
```
Этот способ исключает зависимость от доступности веб-сервера при чтении структуры сервиса.
Использование статической WS-ссылки:
В дереве метаданных конфигурации перейдите в ветку Общие -> WS-ссылки и добавьте ссылку на сервис, импортировав WSDL-файл. В программном коде вызов будет выполняться значительно быстрее без динамического разбора схемы:
```
Прокси = WSСсылки.DataExch.СоздатьWSПрокси("DataExch", "DataExchSoap", "DataExchSoap");
Прокси.Пользователь = "Логин";
Прокси.Пароль = "Пароль";
Результат = Прокси.ВыполнитьОбмен();
```
Использование HTTP-сервисов (REST):
Если вы проектируете интеграцию с нуля, рекомендуется использовать объект метаданных HTTP-сервисы вместо SOAP. Они работают через HTTPСоединение и HTTPЗапрос, не требуют генерации сложных WSDL-схем и потребляют меньше системных ресурсов.