Интеграция сторонних систем с платформой 1С:Предприятие часто реализуется с использованием веб-сервисов SOAP. Основным инструментом для работы с такими сервисами в 1С является объект WSПрокси. Однако при его создании у разработчиков регулярно возникают трудности с заполнением параметров конструктора, особенно когда под рукой есть только ссылка на описание сервиса — WSDL-файл.
В этой статье мы подробно разберем, как устроен WSDL-файл «изнутри», научимся безошибочно определять параметры для создания WSПрокси как вручную (визуальным анализом XML), так и программным методом. Кроме того, мы проанализируем разницу между протоколами SOAP 1.1 и SOAP 1.2, а также рассмотрим лучшие практики оптимизации и обеспечения безопасности таких соединений в реальных проектах.
При попытке подключиться к веб-сервису разработчики обычно используют стандартный шаблон инициализации соединения. Типичный пример такого кода выглядит следующим образом:
Определение = Новый WSОпределения("https://speller.yandex.net/services/spellservice?WSDL", "User", "Pass");
Прокси = Новый WSПрокси(Определение, "http://ваш_URI_имен", "ТочкаВхода", "ТочкаВходаSoap");
Прокси.Пользователь = "User";
Прокси.Пароль = "Pass";
Ответ = Прокси.МойМетодВебСервиса("параметр1", "параметр2");
Если с первым параметром (объектом WSОпределения) все достаточно прозрачно, то последующие три параметра конструктора WSПрокси часто вызывают вопросы. Синтаксис-помощник 1С дает им следующие определения:
Для детального разбора мы возьмем реальный пример — популярный бесплатный сервис проверки орфографии «Яндекс.Спеллер», описание которого доступно по ссылке https://speller.yandex.net/services/spellservice?WSDL. Выясним, как сопоставить XML-структуру этого файла с параметрами платформы 1С. Для быстрого внедрения такой функциональности в интерфейс прикладного решения подойдёт готовая обработка для проверки орфографии в текстовых полях 1С через API Яндекс.Спеллера.
Самый простой и быстрый способ решить задачу в коде, не открывая сам WSDL-файл — использовать коллекцию Сервисы, которая создается внутри объекта WSОпределения после успешного скачивания и анализа XML-схемы. Платформа 1С самостоятельно разбирает структуру документа и предоставляет к ней объектный доступ.
Давайте разберем готовый шаблон кода, который позволяет инициализировать прокси-клиент в динамическом режиме:
// Шаг 1. Получаем WSDL-описание сервиса
АдресWSDL = "https://speller.yandex.net/services/spellservice?WSDL";
Определения = Новый WSОпределения(АдресWSDL);
// Шаг 2. Извлекаем описание первого доступного веб-сервиса
// В подавляющем большинстве WSDL-описаний содержится ровно один сервис
WSСервис = Определения.Сервисы[0];
// Шаг 3. Извлекаем параметры для создания WSПрокси
ПространствоИмен = WSСервис.URIПространстваИмен;
ИмяСервиса = WSСервис.Имя;
// Шаг 4. Берем первую доступную точку подключения (порт)
ИмяТочкиПодключения = WSСервис.ТочкиПодключения[0].Имя;
// Шаг 5. Конструируем WSПрокси на основе полученных метаданных
Прокси = Новый WSПрокси(Определения, ПространствоИмен, ИмяСервиса, ИмяТочкиПодключения);
Этот подход отлично работает в сценариях, когда API стороннего сервиса стабильно и мы можем позволить себе динамическое чтение структуры при каждом запуске сеанса. Однако для глубокого понимания технологии и отладки сложных интеграций крайне важно уметь читать исходный WSDL-файл «глазами».
WSDL-документ представляет собой обычный файл в формате XML. Если мы откроем его в браузере или текстовом редакторе, то легко сможем сопоставить структуру тегов с параметрами конструктора WSПрокси.
Выясним пошагово, где искать каждое значение в XML-структуре файла «Яндекс.Спеллер»:
Многие разработчики совершают ошибку, путая целевое пространство имен со служебными пространствами, объявленными в шапке XML-документа. Нам необходимо найти корневой тег документа <wsdl:definitions> (или просто <definitions>).
Внутри этого тега ищем атрибут targetNamespace. Его значение и является искомым URI пространства имен. Для Яндекс.Спеллера эта строка выглядит так: targetNamespace="http://speller.yandex.net/services/spellservice". Именно значение http://speller.yandex.net/services/spellservice мы должны передать вторым параметром.
Чтобы найти имя веб-сервиса, нам необходимо прокрутить XML-документ в самый конец. Именно там располагаются теги верхнего уровня, описывающие логические сервисы.
Ищем тег <wsdl:service>. Имя сервиса находится в атрибуте name данного тега. В нашем примере мы увидим: <wsdl:service name="SpellService">. Таким образом, третий параметр для WSПрокси равен строке "SpellService".
Точки подключения (или порты) описывают конкретные адреса и протоколы, по которым можно слать запросы к методам сервиса. Они объявляются строго внутри тега <wsdl:service>.
Внутри тега <wsdl:service name="SpellService"> мы увидим несколько дочерних тегов <wsdl:port>. Каждый из них имеет атрибут name. Например, мы можем обнаружить там порты с именами SpellServiceSoap и SpellServiceSoap12. Любое из этих имен подходит для передачи в качестве четвертого параметра конструктора.
Анализируя структуру WSDL-файла Яндекс.Спеллера, мы видим две разные точки подключения: SpellServiceSoap и SpellServiceSoap12. Разберемся, почему их две, в чем их фундаментальное различие и какую из них следует выбирать при разработке в 1С.
Разница между этими точками заключается в используемой версии протокола SOAP — SOAP 1.1 и SOAP 1.2 соответственно:
SpellServiceSoap):
Это классическая, исторически первая широко распространенная версия протокола. Она использует пространство имен XML-конверта http://schemas.xmlsoap.org/soap/envelope/. При отправке запроса по SOAP 1.1 веб-сервер обязательно требует наличия специального HTTP-заголовка SOAPAction, в котором указывается вызываемый метод. Если этот заголовок заблокирован прокси-сервером или не передан, запрос завершится ошибкой.
SpellServiceSoap12):
Более современная и гибкая спецификация (пространство имен конверта http://www.w3.org/2003/05/soap-envelope). В SOAP 1.2 заголовок SOAPAction больше не является обязательным. Вместо этого информация о вызываемом действии (action) передается непосредственно в HTTP-заголовке Content-Type в виде параметра (например, Content-Type: application/soap+xml; action="MyMethod"). Модель обработки ошибок и структура XML-ответа в SOAP 1.2 также более стандартизированы.
Что выбирать в 1С? Платформа 1С:Предприятие полностью поддерживает обе версии протокола. Если сторонний сервис современный и стабильно работает по стандарту SOAP 1.2, рекомендуется использовать именно его (то есть выбирать точку подключения с суффиксом Soap12 или индексом [1] в коллекции точек). Это обеспечивает лучшую совместимость со стандартами веб-разработки. Тем не менее, SOAP 1.1 остается крайне надежным решением, так как поддерживается абсолютно всеми унаследованными (legacy) системами.
Код, представленный в большинстве форумных обсуждений (включая динамическое создание Новый WSОпределения(URL)), содержит критическую архитектурную проблему, которая способна существенно замедлить работу вашей информационной базы 1С в продакшене.
Выясним, почему динамический подход может быть опасен:
Каждый раз, когда выполняется инструкция Новый WSОпределения(URL), платформа 1С совершает реальный сетевой HTTP-запрос к удаленному серверу для скачивания файла описания WSDL и всех связанных XSD-схем. Это приводит к следующим негативным последствиям:
Рассмотрим два надежных альтернативных решения этой проблемы:
Этот способ является наиболее производительным. Мы переносим задачу скачивания и разбора схемы на этап разработки:
https://speller.yandex.net/services/spellservice?WSDL). Платформа импортирует схему непосредственно в структуру конфигурации.Теперь инициализация прокси-клиента в коде будет происходить мгновенно, без каких-либо сетевых запросов к WSDL:
// Инициализация прокси на основе статической WS-ссылки из метаданных
ПространствоИмен = "http://speller.yandex.net/services/spellservice";
ИмяСервиса = "SpellService";
ИмяПорта = "SpellServiceSoap12";
Прокси = WSСсылки.ЯндексСпеллер.СоздатьWSПрокси(ПространствоИмен, ИмяСервиса, ИмяПорта);
// Прокси готов к работе за миллисекунды!
Единственным минусом данного подхода является необходимость обновлять конфигурацию 1С в случае, если разработчики внешнего сервиса изменят структуру API (например, добавят новые методы или изменят типы данных).
Если нам принципиально важно сохранить динамику интеграции (без жесткой привязки к метаданным конфигурации), следует использовать готовый механизм кэширования файлов WSDL, встроенный в БСП.
Функция ОбщегоНазначения.СоздатьWSПрокси() автоматически сохраняет скачанные файлы схем на локальный диск сервера 1С. При повторных вызовах платформа не обращается к сети, а мгновенно считывает схему из локального кэша:
// Пример использования функций БСП для безопасного и быстрого подключения
ПараметрыПодключения = Новый Структура;
ПараметрыПодключения.Вставить("WSDLАдрес", "https://speller.yandex.net/services/spellservice?WSDL");
ПараметрыПодключения.Вставить("ПространствоИмен", "http://speller.yandex.net/services/spellservice");
ПараметрыПодключения.Вставить("ИмяСервиса", "SpellService");
ПараметрыПодключения.Вставить("ИмяПорта", "SpellServiceSoap12");
ПараметрыПодключения.Вставить("Таймаут", 15); // Ограничиваем время ожидания
Прокси = ОбщегоНазначения.СоздатьWSПрокси(ПараметрыПодключения);
В реальной разработке просто создать объект WSПрокси недостаточно. Необходимо предусмотреть обработку нештатных ситуаций, защиту трафика и авторизацию.
1. Обязательная настройка таймаутов. По умолчанию время ожидания ответа от внешнего сервиса может быть неограниченным или слишком долгим. Если сторонний сервис зависнет, сессия пользователя 1С (или фоновое задание) также окажется заблокированной. Всегда явно ограничивайте время ожидания ответа:
// Задаем таймаут 20 секунд при создании прокси
Прокси = Новый WSПрокси(Определение, ПространствоИмен, ИмяСервиса, ИмяПорта, , 20);
// Либо через явное свойство объекта:
Прокси.Таймаут = 20;
2. Настройка защищенного соединения (HTTPS/SSL). Большинство современных публичных сервисов работают исключительно по протоколу HTTPS. Если удаленный сервер использует самоподписанный сертификат или сертификат, выданный нетиповым удостоверяющим центром, 1С выдаст ошибку проверки подлинности SSL. Чтобы этого избежать, передавайте в конструктор прокси настроенный объект защищенного соединения:
// Инициализируем защищенное соединение OpenSSL
ЗащищенноеСоединение = Новый ЗащищенноеСоединениеOpenSSL();
// Передаем его 7-м параметром в конструктор WSПрокси
Прокси = Новый WSПрокси(Определение, ПространствоИмен, ИмяСервиса, ИмяПорта, , 20, ЗащищенноеСоединение);
3. Разделение типов авторизации. Важно не путать авторизацию доступа к файлу WSDL и авторизацию для вызова бизнес-методов API:
Новый WSОпределения(URL, Пользователь, Пароль) используются веб-сервером (например, IIS, Nginx, Apache) только для того, чтобы разрешить скачивание физического файла схемы.Прокси.Пользователь и Прокси.Пароль используются для аутентификации каждого вашего запроса к бизнес-методам сервиса (обычно по протоколу HTTP Basic Auth). Убедитесь, что заполняете их корректно в зависимости от требований безопасности внешнего провайдера.Применяя данные правила и понимая внутреннее устройство стандартов SOAP и WSDL, вы сможете создавать быстрые, надежные и безопасные интеграционные механизмы в любых прикладных решениях на платформе 1С:Предприятие.