Интеграция систем с помощью SOAP-веб-сервисов в среде 1С — мощный и надежный инструмент. Тем не менее разработчики часто сталкиваются с неочевидными препятствиями. Одни из самых популярных вопросов: почему методы созданного веб-сервиса не подсказываются конфигуратором (отсутствует автокомплит в коде) и почему при вызове метода возникает трудночитаемая ошибка веб-сервера "HTTP Error 401.5 - Unauthorized"?
В этой статье мы подробно разберем природу обеих проблем, выясним причины их возникновения и рассмотрим пошаговые инструкции по их устранению.
При написании кода вызова веб-сервиса разработчики часто замечают, что после ввода точки после имени объекта WSПрокси конфигуратор не предлагает список доступных методов (операций), которые определены на стороне веб-сервиса. Более того, этих методов нет в описании типа WSПрокси в Синтаксис-помощнике.
Проанализируем, почему так происходит. Дело в том, что платформа 1С поддерживает два принципиально разных подхода к созданию прокси-классов веб-сервисов: динамический и статический.
Когда мы пишем следующий код:
WSОпределение = Новый WSОпределения(СтрокаПодключения, Пользователь, Пароль);
WSПрокси = Новый WSПрокси(WSОпределение, "http://www.sample-uri.org/WebServis", "WebServis", "WebServisSoap");
Платформа 1С считывает схему WSDL непосредственно во время выполнения кода (в runtime). Конфигуратор на этапе написания программного кода ничего не знает о структуре удаленного веб-сервиса, его методах и ожидаемых типах данных. Именно поэтому автодополнение (автокомплит) для объекта WSПрокси не работает. Платформа физически не может подсказать методы, пока реально не подключится к веб-сервису.
Если мы хотим, чтобы конфигуратор «видел» все методы, типы параметров и возвращаемые значения, нам необходимо импортировать описание веб-сервиса в саму конфигурацию 1С. Разберем, как это сделать:
Теперь мы можем инициализировать прокси-объект на основании метаданных конфигурации. Посмотрим на пример кода:
// Создание прокси на основании статической WS-ссылки
WSПрокси = WSСсылки.ИмяВашейСсылки.СоздатьWSПрокси("http://www.sample-uri.org/WebServis", "WebServis", "WebServisSoap");
// Теперь конфигуратор подсказывает метод CheckProcesses и его параметры!
Ответ = WSПрокси.CheckProcesses(ПараметрЗначение);
Полезный лайфхак: Что делать, если адрес веб-сервиса (endpoint) меняется динамически в зависимости от настроек системы (например, тестовый и рабочий контур)? Мы можем использовать преимущества статической ссылки для удобства написания кода, но при этом динамически переопределять адрес подключения в конструкторе:
АдресПодключения = "http://production-server/base/ws/WebServis";
WSПрокси = WSСсылки.ИмяВашейСсылки.СоздатьWSПрокси(
"http://www.sample-uri.org/WebServis",
"WebServis",
"WebServisSoap",
АдресПодключения
);
---
Рассмотрим частую ошибку начинающих разработчиков. Код инициализации выглядит правильно, учетные данные передаются в WSОпределения, но при вызове метода возникает ошибка авторизации:
WSОпределение = Новый WSОпределения(СтрокаПодключения, "ИмяПользователя", "Пароль123");
WSПрокси = Новый WSПрокси(WSОпределение, "http://www.sample-uri.org/WebServis", "WebServis", "WebServisSoap");
Ответ = WSПрокси.CheckProcesses(зн); // Ошибка: Пользователь не авторизован!
Выясним причину такого поведения платформы. Логин и пароль, переданные в конструктор Новый WSОпределения, используются платформой 1С исключительно для скачивания файла описания WSDL с веб-сервера. После того как WSDL-схема скачана, эти учетные данные уничтожаются. Создаваемый следом объект WSПрокси по умолчанию создается без авторизации.
Чтобы решить эту проблему, нам необходимо явно передать учетные данные самому объекту прокси. Сделать это можно двумя способами.
Этот способ наиболее нагляден и прост для чтения кода:
WSОпределение = Новый WSОпределения(СтрокаПодключения, "ИмяПользователя", "Пароль123");
WSПрокси = Новый WSПрокси(WSОпределение, "http://www.sample-uri.org/WebServis", "WebServis", "WebServisSoap");
// Явно заполняем свойства авторизации созданного прокси-объекта
WSПрокси.Пользователь = "ИмяПользователя";
WSПрокси.Пароль = "Пароль123";
Ответ = WSПрокси.CheckProcesses(зн);
Мы также можем передать имя пользователя и пароль непосредственно при инициализации объекта через параметры конструктора (они идут 8-м и 9-м параметрами):
WSПрокси = Новый WSПрокси(
WSОпределение,
"http://www.sample-uri.org/WebServis",
"WebServis",
"WebServisSoap",
, // Таймаут
, // Прокси
, // Защищенное соединение
"ИмяПользователя", // Пользователь
"Пароль123" // Пароль
);
---
Даже после того как мы прописали логин и пароль в свойствах WSПрокси, при обращении к веб-сервису, опубликованному на веб-сервере Microsoft IIS, может возникнуть ошибка:
HTTP Error 401.5 - Unauthorized. The URL you tried to reach has an ISAPI or CGI application installed that verifies user credentials before proceeding...
Давайте разберем внутреннюю архитектуру взаимодействия IIS и платформы 1С, чтобы понять, почему возникает этот сбой.
Когда мы публикуем базу 1С на IIS, запросы обрабатываются специальным модулем расширения веб-сервера 1С (это библиотека wsapisingle.dll). Ошибка 401.5 означает, что авторизация пользователя была отклонена именно этим внешним модулем (ISAPI-приложением).
В настройках IIS для виртуального каталога нашей базы 1С могут быть одновременно включены разные методы проверки подлинности (например, Anonymous Authentication, Basic Authentication, Windows Authentication).
Если в IIS выключена «Анонимная проверка подлинности» (Anonymous Authentication) и при этом включена «Обычная проверка подлинности» (Basic Authentication), то IIS перехватывает логин и пароль, которые мы передали из 1С через WSПрокси.Пользователь, и пытается сопоставить их с пользователями операционной системы Windows (или домена Active Directory). Поскольку наш пользователь WebServis существует только внутри базы данных 1С, а не в операционной системе, IIS блокирует запрос до того, как он будет передан модулю 1С, возвращая ошибку 401.5.
iisreset в командной строке от имени администратора).При такой настройке IIS без лишних проверок пропустит HTTP-запрос с авторизационными заголовками дальше к модулю 1С (wsapisingle.dll). Модуль 1С самостоятельно прочитает HTTP-заголовок Authorization, извлечет логин и пароль и успешно авторизует сессию под пользователем базы данных 1С.
---
Иногда возникают ситуации, когда внешняя система, вызывающая веб-сервис 1С, технически не может передавать авторизационные заголовки Basic-авторизации, либо мы хотим скрыть учетные данные от вызывающей стороны. В этом случае мы можем настроить автоматическую авторизацию непосредственно в файле публикации веб-сервиса — default.vrd.
Разберем, как прописать учетные данные в файле публикации:
C:\inetpub\wwwroot\ИмяБазы\).default.vrd с помощью любого текстового редактора.<point> и атрибут строки соединения ib.Usr (Имя пользователя) и Pwd (Пароль) прямо в строку подключения к базе данных.Пример модифицированной строки подключения в файле default.vrd для клиент-серверного варианта базы:
ib="Srvr=Server1C;Ref=TradeBase;Usr=WebServisUser;Pwd=StrongPassword123;"
Если база файловая, строка подключения будет выглядеть следующим образом:
ib="File="C:\1C_Bases\TradeBase";Usr=WebServisUser;Pwd=StrongPassword123;"
Важно: При использовании этого метода любые входящие анонимные запросы к данному веб-сервису будут автоматически выполняться под правами пользователя WebServisUser. Позаботьтесь о безопасности и предоставьте этой учетной записи в 1С минимально необходимые роли, ограничив доступ только к нужным веб-сервисам.
Мы подробно разобрали все тонкости настройки подключения к веб-сервисам в 1С. Применяя на практике эти подходы — от правильного распределения прав до корректной настройки IIS и использования статических WS-ссылок, вы сможете создавать стабильные и производительные интеграционные решения.