Как исправить ошибку Метод объекта не обнаружен при вызове метода Web-сервиса в 1С

← На главную

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

В данной статье мы подробно разберем причины этой ошибки, проанализируем правильность настройки пространств имен и рассмотрим альтернативный, более гибкий вариант интеграции через HTTP-сервисы.

Причины возникновения ошибки Метод объекта не обнаружен

Когда мы создаем объект WSПрокси и пытаемся вызвать метод (например, get_sheet(uid)), платформа 1С обращается к внутреннему описанию сервиса. Если платформа считает, что метода не существует, причины могут быть следующими:

Кэширование WSDL-определений: Платформа 1С сохраняет структуру сервиса в локальном кэше. Если вы добавили новый метод в Web-сервис и переопубликовали базу, клиентское приложение может все еще использовать старую структуру из кэша.
Несоответствие пространства имен (Namespace URI): Это самая частая причина. Если URI пространства имен в метаданных Web-сервиса указано некорректно или совпадает с другим существующим сервисом, 1С не сможет правильно сопоставить операции.
Регистрозависимость: Имена методов в SOAP чувствительны к регистру. Метод Get_Data и get_data — это разные методы.
Ошибки в параметрах WSПрокси: Неправильное указание имени точки подключения или порта при инициализации прокси-объекта.

Решение проблемы через настройку пространства имен

Разберем ситуацию, когда соединение с сервисом устанавливается успешно, но методы «не видны». Как показывает практика, ключевым моментом является поле Пространство имен URI в свойствах Web-сервиса. Рассмотрим правильный алгоритм настройки:

Во-первых, убедимся, что URI уникален. Рекомендуется использовать формат http://[адрес_сервера]/ws/[имя_сервиса]. Это позволяет платформе однозначно идентифицировать пакеты XDTO и операции, связанные именно с этим сервисом. После изменения URI необходимо обязательно выполнить перепубликацию на веб-сервере (Apache или IIS).

Проанализируем пример кода для подключения к Web-сервису с передачей учетных данных:


Функция ПолучитьДанныеС1СДокументооборот(uid)
    АдресДО = Константы.АдресВебСервиса1СДокументооборот.Получить(); // Например, "http://192.168.1.1/DO"
    АдресWDSL = АдресДО + "/ws/WSDOCMK.1cws?wsdl";
    
    ИмяПользователя = "Admin";
    ПарольПользователя = "Password123";
    
    Попытка
        // Создаем определение сервиса для получения структуры
        Определение = Новый WSОпределения(АдресWDSL, ИмяПользователя, ПарольПользователя);
        
        // Важно: параметры WSПрокси (Определение, URIПространстваИмен, ИмяСервиса, ИмяТочкиПодключения)
        // Если ИмяТочкиПодключения не указано, оно часто формируется как [ИмяСервиса]Soap
        WSПрокси = Новый WSПрокси(Определение, "http://www.yourdomain.ru/approval", "ApprovalService", "ApprovalServiceSoap");
        WSПрокси.Пользователь = ИмяПользователя;
        WSПрокси.Пароль = ПарольПользователя;
    Исключение
        Сообщить("Не удалось подключиться: " + ОписаниеОшибки());
        Возврат Неопределено;
    КонецПопытки;

    // Вызов метода, который ранее выдавал ошибку
    ДвоичныеДанные = WSПрокси.get_sheet(uid);
    Возврат ДвоичныеДанные;
КонецФункции

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

Диагностика с помощью SoapUI

Если ошибка сохраняется, необходимо проверить работоспособность самого сервиса независимо от кода 1С. Рассмотрим, как это сделать с помощью утилиты SoapUI:

Создайте новый SOAP-проект и вставьте ссылку на ваш WSDL (например, http://server/base/ws/myservice?wsdl).
Если база требует авторизации, в настройках запроса в SoapUI перейдите на вкладку Auth, выберите тип Preemptive и введите логин/пароль. Внимание: используйте латиницу для логинов при тестировании, чтобы исключить проблемы с кодировкой.
Найдите ваш метод в дереве проекта, введите входной параметр и запустите запрос.
Если SoapUI возвращает ответ (даже если это Base64 строка), значит, проблема на стороне вызывающего кода в 1С или в кэше метаданных. Если же SoapUI выдает Unexpected end of file, проверьте настройки веб-сервера и права доступа пользователя 1С.

Альтернатива: Использование HTTP-сервисов

Во многих случаях использование Web-сервисов (SOAP) является избыточным и сложным в настройке. Рассмотрим более современный и производительный вариант — HTTP-сервисы. Они работают быстрее, легче отлаживаются и не требуют строгого описания типов через XDTO-пакеты.

Посмотрим на пример реализации передачи двоичных данных (например, печатной формы в формате PDF) из одной базы в другую через HTTP.

Код на стороне базы-приемника (где создан HTTP-сервис):


Функция ПолучитьПечатнуюФорму(Запрос)
    // Извлекаем UID из параметров ресурса
    UIDДокумента = Запрос.ПараметрыПути.Получить("uid");
    
    // Формируем двоичные данные (например, из макета)
    // ПутьКФайлу = ... (логика формирования файла)
    ДД = Новый ДвоичныеДанные(ПутьКФайлу);
    
    Ответ = Новый HTTPСервисОтвет(200);
    Ответ.УстановитьТелоИзДвоичныхДанных(ДД);
    Ответ.Заголовки.Вставить("Content-Type", "application/octet-stream");
    
    Возврат Ответ;
КонецФункции

Код на стороне базы-инициатора (вызов сервиса):


&НаСервере
Функция ПолучитьФайлСДругойБазы(uid)
    АдресСервиса = "/BaseName/hs/Exchange/GetFile/" + uid;
    
    // Настройка соединения
    Соединение = Новый HTTPСоединение("192.168.5.200", , "User", "Pass");
    Запрос = Новый HTTPЗапрос(АдресСервиса);
    
    Попытка
        Ответ = Соединение.Получить(Запрос);
        Если Ответ.КодСостояния = 200 Тогда
            ДвоичныеДанные = Ответ.ПолучитьТелоКакДвоичныеДанные();
            Возврат ДвоичныеДанные;
        КонецЕсли;
    Исключение
        ЗаписьЖурналаРегистрации("Интеграция", УровеньЖурналаРегистрации.Ошибка, , , ОписаниеОшибки());
    КонецПопытки;
    
    Возврат Неопределено;
КонецФункции

Сравнение подходов

Проанализируем, какой метод лучше выбрать для вашей задачи:

Web-сервисы (SOAP):

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

HTTP-сервисы (REST-like):

Плюсы: Простота реализации, высокая скорость работы, легкость передачи бинарных данных, возможность тестирования через обычный браузер или Postman.
Минусы: Отсутствие автоматического описания структуры (нужно знать URL и формат ответа), необходимость ручной обработки заголовков.

Таким образом, если вы столкнулись с непреодолимыми трудностями при вызове метода WSПрокси, проверьте в первую очередь уникальность URI Пространства имен и попробуйте создать сервис заново с чистого листа. Если же задача позволяет, рассмотрите переход на HTTP-сервисы — это избавит вас от проблем с «невидимыми» методами и упростит поддержку кода.