Часто при интеграции 1С с внешними системами посредством веб-сервисов (через WSПрокси) разработчики сталкиваются с досадной ошибкой: Неверный формат. Она возникает в момент вызова метода SendRequest. При этом объект XDTO может быть успешно сформирован и проверен, но сервер-получатель категорически отказывается принимать запрос.
Давайте разберемся, почему это происходит и как нам исправить ситуацию, чтобы обмен данными заработал корректно.
Основная причина заключается в особенностях формирования SOAP-сообщения платформой 1С. Когда мы используем WSПрокси, 1С автоматически «оборачивает» наши данные в XML-структуру для отправки по протоколу SOAP. Однако, многие сторонние серверы (написанные на Java, .NET или PHP) настроены очень строго.
Сервер ожидает вполне конкретную структуру soapenv:Envelope и soapenv:Body. В ряде случаев встроенный механизм WSПрокси в 1С пытается оптимизировать передачу данных, опуская или изменяя некоторые элементы SOAP-конверта, которые сторонний сервис считает строго обязательными. В итоге запрос приходит на сервер, но тот не может его распознать, возвращая нам ответ об ошибке формата.
Рассмотрим способы, которые позволят нам взять процесс формирования запроса под полный контроль.
Если автоматика 1С не справляется с требованиями вашего веб-сервиса, самым надежным способом будет формирование «сырого» XML-пакета вручную и отправка его через HTTPСоединение. Это гарантирует, что на сервер уйдет именно та структура, которую он ожидает.
Рассмотрим по шагам, как это реализовать:
HTTPЗапрос для передачи данных.Content-Type и SOAPAction).Пример структуры кода для ручного формирования запроса:
// Пример формирования структуры запроса
ТекстЗапроса = "
|<soapenv:Envelope xmlns:soapenv=""http://schemas.xmlsoap.org/soap/envelope/"" xmlns:web=""http://ваш.namespace.ru/"">
| <soapenv:Header/>
| <soapenv:Body>
| <web:ВашаОперация>
| <web:Параметр>Значение</web:Параметр>
| </web:ВашаОперация>
| </soapenv:Body>
|</soapenv:Envelope>";
// Отправка через HTTP
HTTP = Новый HTTPСоединение("адрес.сервера", 80);
Запрос = Новый HTTPЗапрос("/путь/к/сервису");
Запрос.УстановитьТелоИзСтроки(ТекстЗапроса);
Запрос.УстановитьЗаголовок("Content-Type", "text/xml; charset=utf-8");
Запрос.УстановитьЗаголовок("SOAPAction", "ИмяОперации");
Ответ = HTTP.ОтправитьДляОбработки(Запрос);
Чтобы понять, что именно не нравится серверу в нашем запросе, мы можем провести глубокую диагностику. Не стоит гадать — лучше увидеть своими глазами, что улетает из 1С.
1. Использование технологического журнала (ТЖ)
Настройте фильтр на события WS и установите уровень записи 4. В файлах журнала вы увидите реальный XML-пакет, который платформа отправляет на сервер. Сравните его с примером из документации веб-сервиса: часто можно сразу заметить лишние теги или неверные пространства имен.
2. Использование снифферов трафика
Если сервис работает через HTTP (или если вы можете перехватить трафик), используйте инструменты типа Fiddler. Это позволит увидеть структуру запроса в «живом» виде. Проанализировав порядок элементов и наличие обязательных оберток, вы сможете внести корректировки в алгоритм формирования XML в 1С.
Если вы все же предпочитаете использовать ФабрикаXDTO, убедитесь, что при чтении XML вы используете правильные ПараметрыЧтенияXML. Иногда проблема кроется в том, что 1С неверно сопоставляет типы или пространства имен элементов внутри объекта XDTO. Всегда проверяйте, чтобы для каждого элемента был задан URI пространства имен, соответствующий WSDL-описанию вашего веб-сервиса.
Подводя итог: если WSПрокси вызывает ошибку, не тратьте время на долгие попытки подстроить параметры вызова. Переход на ручное формирование XML через HTTPЗапрос — это стандартное и самое эффективное решение для работы со «строгими» веб-сервисами, гарантирующее предсказуемый результат.