Как исправить ошибку «Сервис не найден» при создании WS-прокси в 1С?

← На главную

Интеграция различных информационных систем на платформе 1С:Предприятие 8 с помощью веб-сервисов (SOAP) — это классическое и надежное решение для настройки бесшовного обмена данными. Однако в процессе разработки программисты часто сталкиваются с неочевидными ошибками платформы при инициализации объектов подключения. Одна из самых распространенных проблем — ошибка «Сервис не найден» при вызове метода СоздатьWSПрокси.

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

Анатомия ошибки: почему платформа не видит веб-сервис?

Рассмотрим типовую ситуацию. Разработчик импортирует стороннюю WSDL-ссылку в ветку метаданных «Общие — WS-ссылки» своей конфигурации. Импорт проходит успешно, структура веб-сервиса, его операции и параметры отлично видны в дереве метаданных. Однако при попытке программно обратиться к этой ссылке и создать прокси-класс система выдает исключение:

{ОбщийМодуль.ВебСервисы.Модуль(3)}: Ошибка при вызове метода контекста (СоздатьWSПрокси): Сервис не найден

Выясним первопричину этой проблемы. Ошибка происходит из-за неверного понимания сигнатуры метода СоздатьWSПрокси. Давайте проанализируем синтаксис этого метода платформы:


Прокси = WSСсылки.ИмяWSСсылки.СоздатьWSПрокси(
    ПространствоИмен, 
    ИмяСервиса, 
    ИмяТочкиПодключения
);

Основные параметры метода:

ПространствоИмен (строка) — уникальный идентификатор (URI) пространства имен веб-сервиса. Разработчики часто ошибочно передают сюда физический URL-адрес публикации (например, http://server/base/ws/service.1cws?wsdl). Это ключевая ошибка! URL-адрес публикации и логическое пространство имен веб-сервиса — это совершенно разные вещи.
ИмяСервиса (строка) — имя самого веб-сервиса, как оно задано в конфигурации-источнике.
ИмяТочкиПодключения (строка) — имя порта/точки подключения (например, licenseSoap или имя_сервисаSoap).

Если в качестве первого параметра (Пространства имен) передается некорректная строка, платформа не сможет сопоставить ее со схемой WSDL и выбросит исключение «Сервис не найден».

Где найти правильное пространство имен (URI) веб-сервиса?

Разберем по шагам, как определить корректные параметры для успешного создания прокси-соединения:

Откройте конфигурацию базы-источника (той базы, которая предоставляет веб-сервис).
Перейдите в ветку метаданных Общие — Web-сервисы и выберите нужный объект.
Откройте палитру свойств этого веб-сервиса (клавиша F4).
Найдите свойство «URI пространства имен». Значение этого поля и есть то самое пространство имен, которое необходимо жестко указать в первом параметре метода создания прокси.

Обратите внимание: это значение может выглядеть как произвольная строка (например, просто license или http://www.company.ru/crm). Оно не обязано быть реально существующей ссылкой в интернете — это лишь уникальный текстовый идентификатор схемы данных.

Если у вас нет доступа к конфигуратору базы-источника, вы можете посмотреть это свойство прямо в базе-приемнике. Для этого разверните вашу импортированную WS-ссылку в дереве метаданных Конфигуратора, выделите сам веб-сервис внутри нее и посмотрите его свойства. В строке «URI пространства имен» будет указано точное значение.

Рассмотрим пример правильного кода инициализации статического прокси:


// Пример корректного создания прокси на основе статической WS-ссылки
ПространствоИмен  = "http://www.company.ru/license"; // Взято из свойств веб-сервиса
ИмяСервиса        = "license";
ИмяТочки          = "licenseSoap";

// Создаем прокси-объект
Прокси = WSСсылки.WSlicense.СоздатьWSПрокси(ПространствоИмен, ИмяСервиса, ИмяТочки);

// Задаем параметры авторизации (учетные данные пользователя базы-источника)
Прокси.Пользователь = "Администратор";
Прокси.Пароль       = "СекретныйПароль123";

// Теперь мы можем вызывать методы сервиса
Результат = Прокси.ПолучитьСтатусЛицензии();

Динамическое создание WS-прокси: лучший способ интеграции

Хотя использование статических WS-ссылок в дереве метаданных выглядит простым, на практике этот метод имеет серьезный недостаток. Схема веб-сервиса (структура методов, параметры, типы данных XDTO) «зашивается» в конфигурацию в момент импорта. Если разработчики удаленной базы изменят состав параметров веб-сервиса или даже просто обновят пространство имен, ваша интеграция мгновенно сломается. Для исправления ситуации придется открывать Конфигуратор, обновлять WS-ссылку вручную и выполнять обновление конфигурации базы данных.

Чтобы избежать этих проблем и сделать интеграцию гибкой, мы рекомендуем использовать динамическое создание WS-прокси через объект WSОпределения. В этом случае WSDL-описание схемы скачивается непосредственно в момент обращения к сервису.

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


// Адрес публикации веб-сервиса с суффиксом ?wsdl
АдресПубликации = "http://192.168.1.100/trade_base/ws/license.1cws?wsdl";
Логин           = "IntegrationUser";
Пароль          = "Pass123456";

Попытка
    // Шаг 1. Динамически загружаем описание схемы WSDL
    Определения = Новый WSОпределения(АдресПубликации, Логин, Пароль);
    
    // Шаг 2. Создаем WS-прокси, передавая объект определений
    // Пространство имен, имя сервиса и точку подключения берем из структуры описания
    ПространствоИмен  = "http://www.company.ru/license";
    ИмяСервиса        = "license";
    ИмяТочки          = "licenseSoap";
    
    Прокси = Новый WSПрокси(Определения, ПространствоИмен, ИмяСервиса, ИмяТочки);
    
    // Передаем авторизационные данные для выполнения самих операций
    Прокси.Пользователь = Логин;
    Прокси.Пароль       = Пароль;
    
    // Выполняем удаленный метод
    Результат = Прокси.ПроверитьПодключение();
    Сообщить("Успешное подключение: " + Результат);
    
Исключение
    Сообщить("Ошибка инициализации веб-сервиса: " + ОписаниеОшибки(), СтатусСообщения.Важное);
КонецПопытки

Особенности работы с веб-сервисами в современных версиях платформы (8.3.20+)

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

Использование механизмов БСП (Библиотека Стандартных Подсистем).
В современных типовых конфигурациях (таких как ERP, КА, УТ, ЗУП) разработчики практически никогда не используют низкоуровневые конструкторы платформы напрямую. Вместо этого применяется универсальный программный интерфейс БСП:
ОбщегоНазначения.СоздатьWSПрокси(Параметры)
Дело в том, что динамическая загрузка WSDL-описания при каждом обращении существенно замедляет работу системы (ведь серверу 1С приходится выполнять синхронный HTTP-запрос к удаленной базе, который может длиться до нескольких секунд). БСП решает эту проблему за счет кэширования схем в специальном регистре сведений КэшПрограммныхИнтерфейсов, а также автоматически применяет системные настройки прокси-серверов.
Требования к защищенному соединению (HTTPS/SSL).
Если удаленный веб-сервис опубликован по защищенному протоколу HTTPS (что является стандартом для промышленных систем), платформа 1С потребует явного указания параметров шифрования. В противном случае соединение будет заблокировано из соображений безопасности. Для работы по HTTPS в конструктор определений обязательно нужно передавать объект защищенного соединения:
```
ЗащищенноеСоединение = Новый ЗащищенноеСоединениеOpenSSL();
Определения = Новый WSОпределения(АдресHTTPS, Логин, Пароль, , , ЗащищенноеСоединение);
```
Авторизация и права доступа.
Убедитесь, что под учетной записью, которую вы используете для подключения к удаленной базе 1С, настроены соответствующие права доступа. Пользователю в базе-источнике обязательно должна быть назначена роль, содержащая право «Использование веб-сервисов» (или конкретные права на чтение и вызов созданного Web-сервиса). В противном случае платформа вернет ошибку авторизации HTTP 401 Unauthorized.

Резюме: SOAP или HTTP-сервисы?

Хотя веб-сервисы на протоколе SOAP (с использованием XML и XDTO) до сих пор активно поддерживаются и используются в экосистеме 1С, современным стандартом разработки становятся HTTP-сервисы (REST API).

HTTP-сервисы передают данные в легком формате JSON, не требуют сложного сопоставления пространств имен и генерации жестких схем WSDL, а также работают значительно быстрее за счет меньшего объема передаваемого служебного трафика. Если вы проектируете новую интеграционную схему между конфигурациями с нуля, рекомендуем сделать выбор в пользу HTTP-сервисов — это избавит вас от большинства проблем с несовместимостью пространств имен, кэшированием определений и долгим разбором тяжелых XML-пакетов. Для быстрой реализации такого решения можно использовать конструктор API для организации обмена в формате JSON.