Постараюсь коротко и своими словами. SOAP сейчас весьма популярный протокол web API сервисов. То есть способ взаимодействия Вашей информационной системы через web с другими информационными системами.
В самом общем виде SOAP это протокол обмена структурированными XML сообщениями в произвольной распределенной вычислительной среде. Отсюда следует, что мы должны куда-то передать XML и получить назад также XML. Для передачи нам нужен транспорт. Или протокол передачи данных. Например SMTP, FTP, HTTP, HTTPS. Чаще всего HTTP, но это не принципиально.
Залогом успеха нашего обмена является способность правильно создать и передать XML запрос и правильно принять и разобрать XML ответ. Для того чтобы сделать все правильно нужно соблюдать (извиняюсь за тавтологию) правила. Эти правила описываются файлом специального формата: WSDL. WSDL — это язык описания правил использования web сервисов в том числе и сервиса SOAP.
Встроенный в 1С объект платформы WS-ссылка позволяет нам загрузить эти правила и на их основе использовать web сервис с максимальным удобством. Поставщик сервиса разрабатывает правила и размещает их по доступному для клиентов адресу. Естественно, что изменения в работе сервиса должны в случае необходимости сопровождаться внесением изменений в WSDL инструкцию. Но это не наша (клиента) забота. Для нас важны правила. Мы можем не иметь малейшего представления о том, как работает сервис, но точно знаем, что если обратимся к нему по правилам, то получим правильный ответ. Это сильно упрощает жизнь и разработку. Не знаю как Вам, а мне это нравится.
В общем-то объект WS-ссылки и создается и задается всего лишь ссылкой на WSDL правило:
После создания WS-ссылки и загрузки правил Вы можете просмотреть набор возможных методов и наборы их параметров с типизацией.
Вызвав одной универсальной функцией нужный метод (предварительно создав и передав нужную ему структуру параметров) SOAP сервиса Вы уже можете видеть результат в виде дерева. Описание ответных данных как правило содержится в документации поставщика, но это не обязательно. В любом случае в качестве ответа Вы получите некую структуру данных в виде XML файла, которая в общем виде может быть приведена к типу данных 1С "ДеревоЗначений". Вот это-то дерево и будет у Вас при любом вызове любого метода. Вызовите в этот момент отладчик для просмотра или выведите дерево результата на форму и разберитесь с каких ветвей снять заветные "плоды"-результаты. И все:)
Вот как просто можно вызвать и получить результаты разных методов в абсолютно разных сервисах (во втором примере метод без параметров):
Но как и в жизни в методы SOAP тоже можно обозначить как процедуры и функции. Процедуру мне посчастливилось увидеть всего один раз. Да и то, потому что публичный сервис с информацией о странах, который я использовал в качестве примера №1 перестал работать (на скрине он еще показан) и пришлось свочно искать ему замену. Что же делать с процедурой, ведь она не вернет нам ответ и не из чего будет создать дерево и, следовательно, неоткуда сорвать результат?
Но (опять же как часто бывает в жизни) с процедурой все стало даже проще. Она возвращает результат в свои же параметры. Как на скрине ниже:
Так как ПолучитьДеревоРезультатовДляSOAP задумывалась как функция то я ее заставил вернуть результат. В данном случае, не деревом, а структурой, содержащей выходные парметры метода. Какие из параметров выходные Вы всегда можете просмотреть в их свойствах. Хотя можно и не смотреть. Структура в результате будет содержать все выходные параметры метода. В нашем примере это "image" и "encoding". Получить результат из структуры оказывается еще проще. Если с дерева нужно "доставать", то в структуре все уже готово к употреблению.
В последний год мне довелось трижды связывать через web API свою конфигурацию с поставщиками услуг и информации, для получения данных или заказа услуг (например услуги доставки товара или рассылки СМС). В последний раз имея готовый код примера и обработку для 1С от поставщика я отказался от них и выбрал вариантом решения универсальный SOAP сервис. Просто потому, что так оказалось с наработанными ранее функциями проще.
Для данной публикации специально нашел парочку публичных SOAP ресурсов и слепил использующую их конфигурацию. 95% времени заняла работа с формами вызова и вывода данных. Зато в демке Вы можете видеть курс валют от ЦБ РФ на любую дату и краткий набор сведений о любой стране мира скриншот web страницы для произвольного url.
В общем кому лень или некогда разбираться с этим вот всем, а нужно сделать быстро и чтобы работало ссылка на скачивание демо конфигурации после публикации.
И пункт обязательной программы:) Тестировалось на релизе платформы 8.3.9.2309.
Спасибо за внимание и удачных всем разработок!
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Все здорово, но МЫЛО у 1с такое себе при взаимодействии с другими сервисами.
Зачастую удобнее и легче использовать http сервисы.
Они понятны любому разработчику, их легко разрабатывать и тестировать.
(1)
Из статьи:
Причем тут протокол передачи данных? Может вы имели ввиду REST?
Я бы не был столь категоричен… Легко разрабатывать и тестировать то, что хорошо продумано и задокументировано, к конкретной технологии — это почти не имеет отношения.
(2)
Добавлю, даже на порядок удобнее, порог вхождения практически нулевой у HTTP сервисов по отношению к SOAP.
Статья образовательная ценность имеет однозначно. Автору пожелание, напиши ещё про полностью программную работу с SOAP объектами, не всегда есть возможность конфигурацию допиливать.
(3)
Будьте последовательны в своем невежестве, если произносите HTTP сервисы (как в 1С), то не SOAP, а WEB сервисы. Но корректно (что бы не выглядеть идиотом): REST и SOAP.
(2)
Может я имел ввиду объект метаданных 1с, который да, реализует RESTful.
Буквально год назад КАТЕГОРИЧНО бросил использование Web сервисов после того, как оказалось, что при интеграции с яндексом они передают только один параметр (API проверки орфографии) и после беглого гуглинга оказалось, что в 1с оно работает нормально только с самой же 1с.
(5)
Я ничего не понял, кроме того, что были проблемы, и после рытья в гугл вы нашли оправдание, не продолжать работу. Что вы имели ввиду? Я с вами и вашими работами не знаком. Мысли читать не умею.
Всем привет. Ребята статью писал и готовил мучительно долго. Но перед отпуском решил закончить. Успел и уехал. Отвечу всем обязательно. Только когда вернусь:)
(6)
Ну попробуйте погуглить.
По первой же ссылке описание проблемы (не мой пост, если что):
Для того, чтоб веб сервисы работали как надо, надо чтоб на обеих сторонах были либо 1с’ки, либо чтоб была возможность правок обоих ресурсов.
И так, спрашивается, ради чего это все, если есть менее геморройные альтернативы?
У вас может и другой подход, но лично мой: «сделал API, работает как автомат калашникова прошибающий рельсу вдоль, можно и забыть про него», а для этого он должен быть ммаксимально простым. Мне будет лень переписывать API, когда в компании решат прикрутить корпоративный портал или мобильное приложение или скуд или замутить обмены с контрагентом.
HTTP сервисы (помним, да, что это метаданные 1с реализующие REST API?) это суть аналог flask’а. Там нечему ломаться и работать неправильно. API будет понятно и питонистам и яваскриптерам и пхп-инвалидам и даже вашим собратьям по разуму.
Работа была выполненна на отлично, как и всегда, но не средствами wsdl.
Если 1С никаких существенных изменений не вносила в этот механизм за последний год, то нужно с оглядкой подходить к подобным решениям.
ЗЫ: только прошу, без вот этого всего: «А НАМ И НЕ НАДО!!!», «ТОЛЬКО ВЫЙГРАЛИ!!!».
(8)
Чушь. Есть проблемы совместимости разных версий инструментов, но требования 1С — 1С или Java — Java, или WCF — WCF — нет.
Что такое: «правка общих ресурсов» — я даже не догадываюсь.
…
даже вашим собратьям по разуму.
Эээ…. Моим собратьям по разуму все равно что использовать: SOAP, CORBA, RMI и т.д., и т.п. Так что за себя рассказываете, я же за вас не рассказываю….
Я сервисы начал писать в 2007 году. И прикручивал их к 1С:7,7 еще. Проблемы были, но изучение вопроса помогало всегда их решать без смены технологии…
(10)
Вы тщательно это маскируете или я сильно не внимателен, а по вопросам веры — в церковь…
Я уже просил не говорить за меня.
Советуйте… Главное не с дулом у виска, оставьте им свободу выбора…
(4) Использую терминологию 1С.
(10) Фото просто угар.! :))))
Из отпуска вышел, но дискуссия увяла:) Так что если кому, что надо — пишите для возобновления. Как — то уже совсем не интересно задирать тему снова без повода.
(14) Добрый день!
Что за метод такой ПолучитьДеревоРезультатовДляSOAP?
(15) Ну вот такой метод, который позволяет просто отправить запрос и получить ответ в виде дерева значений для добавленного в конфигурацию Веб сервиса.
Когда я его написал и немного попользовался мне показалось хорошей идеей поделиться этим с сообществом. Впрочем, у Вас может быть иное мнение.
Вопросы возникли:
1. Если нужна авторизация? Где указывать пользователя и пароль?
2. {ОбщийМодуль.Служебный.Модуль(89)}: Ошибка при вызове метода контекста (Установить)
Данные.Установить(ТекСвойство,НужныйТип);
по причине:
Несоответствие типов XDTO:
Свойство является списковым
Выдает ошибку при попытке обращения к GetPartyByINN
Файл wsdl прикрепил.
(17) 1. Вопрос авторизации остается открытым. В основном авторизация в web сервисах происходит через один/несколько передаваемых параметров. apikey, как в примере с сервисом СкринURL какой-нибудь токен и т.п. Мне вот ни разу не пришлось авторизовываться для подключения к сервису, авторизация была только внутри самого сервиса. Но если Вам нужно именно авторизоваться для подключения — посмотрите в сторону параметра ИнтерентПрокси при вызове метода СоздатьWSПрокси для Вашей ws ссылки.
2. Подозреваю, что в списке со свойствами есть еще списки свойств. Рекурсивное вычерпывание параметров у меня не предусмотрено. Любопытный у Вас сервис, но, боюсь, что мой способ сделать все по простому здесь не заработает.