Почему при вызове веб-сервиса 1С возникает ошибка HTTP и как ее исправить?

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

Разберем детально, почему возникает эта ошибка, как устроена аутентификация в объектах платформы 1С и как правильно вызывать веб-сервисы из программного кода.

Причина ошибки: разделение авторизации в WSОпределения и WSПрокси

Проанализируем механизм взаимодействия платформы с веб-сервисом. Обращение к SOAP-сервису состоит из двух независимых этапов:

1. Получение WSDL-описания: платформа отправляет HTTP GET запрос на получение схемы. Для этого создается объект WSОпределения, в конструктор которого передаются адрес схемы, имя пользователя и пароль. Если учетные данные верны, веб-сервер отдает XML-схему, и объект создается без ошибок.
2. Вызов конкретной операции (метода): платформа отправляет HTTP POST запрос (SOAP-конверт) на точку подключения через объект WSПрокси.

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

В результате, если в целевой базе используется авторизация 1С (по логину и паролю), а не аутентификация операционной системы, объект WSПрокси отправляет запрос без заголовка авторизации. Веб-сервер возвращает ответ HTTP 401 Unauthorized, а платформа генерирует общую ошибку вызова HTTP.

Разбор ошибочного кода

Посмотрим на пример кода, который приводит к сбою:

ЗащищенноеСоединение = Новый ЗащищенноеСоединениеOpenSSL;

// WSDL скачивается успешно, так как логин и пароль переданы в конструктор
Определение = Новый WSОпределения(МестоположениеWSDL, ИмяПользователя, ПарольПользователя,,, ЗащищенноеСоединение, Ложь);

// Прокси создается, но учетные данные пользователя базы в него НЕ попадают
Прокси = Новый WSПрокси(Определение, ПространствоИменСервиса, ИмяСервиса, ИмяТочкиПодключения,,, ЗащищенноеСоединение,, Ложь);

// На этой строке происходит исключение "Ошибка HTTP"
Результат = Прокси.ВыполнитьОперацию();

Корректная инициализация WSПрокси с авторизацией

Для исправления ошибки достаточно после создания объекта WSПрокси явно присвоить учетные данные его свойствам Пользователь и Пароль. Рассмотрим правильный вариант программного кода:

ЗащищенноеСоединение = Новый ЗащищенноеСоединениеOpenSSL;

// 1. Получаем WSDL-схему сервиса
Определение = Новый WSОпределения(
    МестоположениеWSDL, 
    ИмяПользователя, 
    ПарольПользователя, 
    , 
    , 
    ЗащищенноеСоединение, 
    Ложь
);

// 2. Инициализируем прокси сервиса
Прокси = Новый WSПрокси(
    Определение, 
    ПространствоИменСервиса, 
    ИмяСервиса, 
    ИмяТочкиПодключения, 
    , 
    , 
    ЗащищенноеСоединение, 
    , 
    Ложь
);

// 3. Явно передаем данные авторизации для выполнения операций
Прокси.Пользователь = ИмяПользователя;
Прокси.Пароль       = ПарольПользователя;

// 4. Вызываем целевую операцию сервиса
Результат = Прокси.execute();

После установки этих свойств каждый HTTP POST запрос с SOAP-пакетом будет содержать необходимый заголовок Authorization: Basic ..., веб-сервер успешно авторизует сеанс в 1С, и управление перейдет в модуль веб-сервиса.

Дополнительные факторы, вызывающие ошибки HTTP

Если после указания логина и пароля ошибка сохраняется, проанализируем сопутствующие настройки окружения и веб-сервера:

1. Регистр символов в Apache: В отличие от IIS, веб-сервер Apache чувствителен к регистру символов в URL. Проверьте атрибут alias в теге <point> файла default.vrd. Если там указано DM.1cws, адрес в строке подключения должен в точности повторять регистр (например, ws/DM.1cws?wsdl).
2. Права пользователя в конфигурации: Учетная запись 1С, под которой выполняется вызов, должна иметь роль с установленным правом Использование для вызываемого веб-сервиса. Без этого права платформа отклонит запрос до входа в метод.
3. Параметры файла default.vrd: Если в секции <ws> указан атрибут pointEnableCommon="false", доступны будут только те сервисы, для которых явно прописан тег <point enable="true" ... />.
4. Передача заголовков авторизации в Apache 2.4: Если веб-сервер работает за обратным прокси или с определенными модулями перенаправления, заголовок авторизации может отсекаться. Убедитесь, что в конфигурационном файле httpd.conf разрешена проброска заголовка авторизации: SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
5. Аутентификация в строке соединения default.vrd: Если сервис должен работать в открытом режиме без явной авторизации на клиенте, пользователя и пароль можно задать прямо в параметре ib файла default.vrd: usr=Имя;pwd=Пароль;.

Диагностика сбоев веб-сервисов

Выясним, как быстро локализовать источник сбоя, если вызов метода не срабатывает:

1. Проверка логов Apache: Откройте файлы access.log и error.log веб-сервера. Если в access.log фиксируется код 401 — проблема в учетных данных или заголовках авторизации; код 403 указывает на ограничения прав к каталогу публикации; код 500 свидетельствует о внутренней ошибке модуля расширения 1С или необработанном исключении в коде.
2. Журнал регистрации 1С: Перейдите в базу-источник сервиса и откройте Журнал регистрации. Отфильтруйте события по категории аутентификации и ошибок веб-сервисов, чтобы увидеть, под каким пользователем была попытка входа и по какой причине она отклонена.
3. Включение отладки: Для того чтобы отладчик 1С останавливался внутри модуля веб-сервиса, запустите процесс публикации с флагом отладки и проверьте, что предмет отладки на сервере активен.