При интеграции 1С с внешними системами через механизмы Web-сервисов программисты часто сталкиваются с ситуацией, когда сторонний сервис успешно проходит тесты в сторонних утилитах (например, в SoapUI), но при попытке добавить WS-ссылку в конфигурацию 1С возникает ошибка: «Неверный формат. по причине: SOAP операция не задана». Рассмотрим подробно, почему это происходит и как привести WSDL-описание сервиса к виду, который «поймет» платформа 1С.
Проблема кроется в алгоритмах парсинга WSDL-файла (Web Services Description Language), которые встроены в платформу 1С. В отличие от многих универсальных инструментов, 1С предъявляет строгие требования к полноте описания операций в секции binding. Ошибка «SOAP операция не задана» чаще всего означает, что парсер нашел определение операции в порту сервиса, но не смог найти для нее соответствующих инструкций по вызову в узле связывания (binding).
Выясним основные технические причины, которые приводят к такому поведению:
soapAction в секции wsdl:binding является обязательным для корректной маршрутизации запроса. Если разработчики внешнего сервиса оставили этот атрибут пустым или вовсе его не указали, 1С не сможет сопоставить абстрактную операцию с конкретным вызовом.WSDL указано использование SOAP 1.1, но используются пространства имен от SOAP 1.2, возникнет конфликт определений.WSDL импортирует типы данных через xsd:import, 1С может не получить доступ к этим файлам из-за проблем с авторизацией, сетевой доступностью или относительными путями.document/literal. Ошибки в описании rpc/encoded часто приводят к невозможности построить дерево операций.Проанализируем структуру WSDL-файла. Нам необходимо найти секцию wsdl:binding. Внутри каждой операции wsdl:operation должен присутствовать тег soap:operation. Разберем на примере, как это должно выглядеть в корректном варианте.
Посмотрим на пример правильной структуры:
<wsdl:binding name="MyServiceBinding" type="tns:MyServicePortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="GetNsiVersionById">
<soap:operation soapAction="http://example.com/GetNsiVersionById" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
Если в вашем файле строка soap:operation отсутствует или в ней нет soapAction, это и есть причина ошибки. Вам необходимо попросить разработчиков сервиса явно прописать этот атрибут. Если они не могут этого сделать, вы можете сохранить WSDL на локальный диск, вручную добавить пустые или фиктивные значения soapAction="" и попробовать создать WS-ссылку, указав путь к локальному файлу.
Проанализируем заголовки WSDL. В сообщении об ошибке в 1С часто фигурирует текст Soap11 или Soap12. Это указывает на то, какой именно биндинг вызвал проблему. Проверьте, что в файле правильно определены пространства имен для соответствующей версии:
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"Если сервис одновременно пытается использовать описание для обеих версий, но делает это некорректно, попробуйте оставить в локальной копии WSDL только одну версию биндинга, которая вам необходима.
Иногда создание WS-ссылки в конфигураторе через визуальный интерфейс блокируется из-за строгих проверок метаданных. Мы можем попытаться обойти это ограничение или получить более детальный текст ошибки, используя программный метод создания объектов 1С. Для этого воспользуемся объектом WSОпределения.
Рассмотрим пример кода для проверки доступности сервиса в режиме «1С:Предприятие»:
ПутьКWSDL = "http://myserver.com/service?wsdl";
ИмяПользователя = "admin";
Пароль = "password";
Попытка
// Пытаемся создать определение программно
Определение = Новый WSОпределения(ПутьКWSDL, ИмяПользователя, Пароль);
Сообщить("WSDL успешно прочитан, количество сервисов: " + Определение.Сервисы.Количество());
Исключение
// Если здесь возникнет ошибка, мы увидим детальное описание проблемы парсинга
Сообщить("Ошибка при чтении WSDL: " + ОписаниеОшибки());
КонецПопытки;
Если программный метод Новый WSОпределения отрабатывает без ошибок, а конфигуратор все равно выдает ошибку при создании ссылки, это может свидетельствовать о баге конкретного релиза платформы (как в случае с 8.3.13.1644). В такой ситуации рекомендуется использовать именно динамическое обращение к сервису без создания статической ссылки в дереве конфигурации.
Выясним, не связана ли проблема с внешними схемами. Часто 1С не может «проглотить» WSDL, потому что он ссылается на .xsd файлы, которые лежат по другому адресу или требуют отдельной авторизации. Рассмотрим алгоритм действий для локальной отладки:
WSDL в браузере или SoapUI.xsd:import и xsd:include.WSDL, изменив пути в schemaLocation на локальные (просто имена файлов в той же папке).Это позволит исключить сетевые проблемы и ошибки безопасности при загрузке определений типов.
Если вы работаете на старых релизах платформы (например, ветка 8.3.13 или 8.3.14), помните, что механизмы работы с XML и Web-сервисами в 1С постоянно совершенствуются. Если есть возможность, попробуйте загрузить проблемный WSDL в пустую базу на более свежем релизе (например, 8.3.22 или выше). Если там ошибка не воспроизводится, значит, вы столкнулись с внутренним ограничением парсера старой платформы.
Также стоит обратить внимание на атрибут transport в узле soap:binding. Он должен иметь строго определенное значение: transport="http://schemas.xmlsoap.org/soap/http". Любые отклонения или опечатки в этом URL приведут к тому, что 1С не опознает транспортный протокол и выдаст ошибку о незаданной операции.
Резюмируем: для исправления ошибки «SOAP операция не задана» необходимо обеспечить наличие атрибута soapAction для каждой операции, проверить соответствие пространств имен протоколам SOAP и убедиться в доступности всех импортируемых схем данных.