Как правильно обратиться к веб-сервису SAP из 1С и передать параметры через XDTO?

← На главную

Интеграция 1С с внешними системами через веб-сервисы, особенно если речь идет о таких сложных экосистемах, как SAP (через SAP PI/PO), часто вызывает затруднения у разработчиков. Основные сложности связаны с тем, что 1С требует строгого соблюдения типов данных и структуры WSDL-описания. В этой статье мы подробно разберем, как избежать ошибок Метод объекта не обнаружен и Несоответствие типов, а также научимся правильно формировать запросы к SAP.

Разберем причину ошибки «Метод объекта не обнаружен»

Когда мы создаем объект WSПрокси, 1С анализирует WSDL-файл и динамически создает методы у объекта прокси. Если при вызове метода, например Прокси.МХ1("9002"), возникает ошибка о его отсутствии, нам следует проанализировать три важных фактора:

Регистр имен: В 1С встроенный язык нечувствителен к регистру, но при обращении к методам веб-сервиса через точку регистр обязательно должен соответствовать тому, что написано в WSDL. Если в описании метод называется SI_DataLoad_Out, то вызов прокси.si_dataload_out() приведет к ошибке.
Выбор правильного порта: Один и тот же сервис SAP может иметь несколько портов (например, HTTP_Port и HTTPS_Port). Методы «привязаны» к конкретному порту. Если при создании прокси указан порт, в котором данная операция не описана, 1С его не увидит.
Структура WSDL: Часто разработчики пытаются вызвать метод Получить, полагая, что это универсальная команда. Однако у прокси нет предопределенных методов типа Получить или Отправить. Вызывать нужно именно то имя операции, которое определено в сервисе (например, MX1).

Варианты создания WS-прокси

Рассмотрим два способа подключения к сервису. Проанализируем их различия и выберем подходящий для вашей задачи.

Способ 1. Использование статической WS-ссылки

Этот метод удобен, если адрес сервиса не меняется. Вы добавляете WS-ссылку в дерево конфигурации и обращаетесь к ней следующим образом:


Прокси = WSСсылки.WSСсылкаSeverstal.СоздатьWSПрокси("http://namespace.url", "si_DataLoad_outb_syncService", "HTTPS_Port");
Прокси.Пользователь = "ЛогинSAP";
Прокси.Пароль = "ПарольSAP";

Способ 2. Динамическое создание через WSОпределения

Этот вариант более гибкий, так как позволяет загружать WSDL из файла или по URL прямо в коде, что критично при переходе между тестовым и продуктивным серверами SAP. Также здесь мы настраиваем защищенное соединение SSL.


// Настройка защищенного соединения
Защита = Новый ЗащищенноеСоединениеOpenSSL(
    Новый СертификатКлиентаWindows(СпособВыбораСертификатаWindows.Авто), 
    Новый СертификатыУдостоверяющихЦентровWindows()
);

// Загрузка определения сервиса
ПутьКWsdl = "C:/Wsdl/service_definition.wsdl";
Определение = Новый WSОпределения(ПутьКWsdl, Пользователь, Пароль, , , Защита);

// Создание прокси
// Важно: параметры (URIПространстваИмен, ИмяСервиса, ИмяПорта) должны строго совпадать с WSDL
Прокси = Новый WSПрокси(Определение, "http://sap.com/xi/XYZ", "si_DataLoad_outb_syncService", "HTTPS_Port", , , Защита);
Прокси.Пользователь = Пользователь;
Прокси.Пароль = Пароль;

Проблема «Несоответствие типов» и использование Фабрики XDTO

Выясним причину, почему простая передача строки Прокси.МХ1("9002") часто не работает. Веб-сервисы SAP ожидают не простое значение, а сложную структуру — XML-объект. Даже если параметр всего один, он должен быть обернут в тип, описанный в XDTO-пакете сервиса.

Посмотрим на алгоритм правильной подготовки параметра:

Определим тип параметра: Нам нужно найти в фабрике прокси тип объекта, который ожидает метод.
Создадим экземпляр объекта: Используем метод Создать() фабрики XDTO.
Заполним свойства: Установим значение конкретного поля внутри объекта.

Проанализируем пример кода для передачи параметра в метод MX1:


// 1. Получаем фабрику XDTO из нашего прокси
Фабрика = Прокси.ФабрикаXDTO;

// 2. Находим тип входного параметра. 
// Пространство имен (Namespace) берем из свойств WSDL или пакета XDTO
ТипПараметра = Фабрика.Тип("http://sap.com/xi/XYZ", "DT_MX1_Request");

// 3. Создаем объект XDTO на основе этого типа
ЗапросОбъект = Фабрика.Создать(ТипПараметра);

// 4. Заполняем данными. Поле "ID" должно соответствовать имени в схеме XDTO
ЗапросОбъект.ID = Формат(9002, "ЧГ=0"); 

// 5. Вызываем метод, передавая подготовленный объект
Попытка
    Результат = Прокси.MX1(ЗапросОбъект);
    // Обработка результата (Результат также будет объектом XDTO)
    Сообщить("Ответ получен успешно");
Исключение
    Сообщить("Ошибка при вызове сервиса: " + ОписаниеОшибки());
КонецПопытки;

Советы по отладке интеграции с SAP

Если вы все еще получаете ошибки, воспользуемся следующими рекомендациями:

1. Используйте SoapUI для проверки WSDL. Это «золотой стандарт» тестирования веб-сервисов. Загрузите ваш WSDL в SoapUI. Он автоматически создаст пример XML-запроса. Если запрос из SoapUI проходит, а из 1С нет — сравните структуру XML. Вы увидите, какие поля являются обязательными и в каком пространстве имен они должны находиться.

2. Проверьте пространство имен (Namespace). В коде 1С при создании прокси и типов XDTO часто допускают ошибки в URL пространства имен. Лишний слэш в конце или отсутствие http:// сделают типы несовместимыми.

3. Работа с заголовками. В некоторых случаях SAP требует специфические HTTP-заголовки (например, sap-client). Поскольку стандартный WSПрокси не всегда позволяет гибко управлять заголовками, иногда приходится формировать SOAP-сообщение вручную через HTTPСоединение и HTTPЗапрос, отправляя POST-запрос с XML-телом.

4. Очистка кэша. 1С кэширует определения веб-сервисов. Если вы изменили WSDL на стороне SAP, обязательно перезапустите сеанс 1С или обновите WS-ссылку в конфигураторе, иначе вы будете обращаться к «призраку» старого метода.

Таким образом, успех интеграции зависит от точности в именовании объектов, правильного выбора порта и грамотной работы с типами XDTO через ФабрикуXDTO. Следуя приведенным шагам, вы сможете корректно обмениваться данными с любой внешней системой, поддерживающей протокол SOAP.