Обработка для тестирование работающего внешнего веб-сервиса

Интерес к интернет-технологиям с каждым годом становится все больше и больше. Эта тенденция не обходит стороной и такие информационные системы как 1С. Для удаленного взаимодействия (через интернет) в 1С 8 предусмотрен ряд объектов, таких как HTTP соединение и веб-сервисы. Но традиционно не многие 1С-разработчики сильны в вопросе веб-технологий. А когда возникает потребность в более детальном их изучении, то многим знакома ситуация, когда не знаешь, с чего же начать. И информации в интернете вроде бы много, но как разобраться в этом разнообразии, как выделить главное?

В этой статье я постараюсь выделить это "главное", которое поможет сориентироваться и заложить основу для дальнейшего, более углубленного изучения современных интернет-технологий. Буквально тезисно пройдемся по основным направлениям, рассмотрим всем известные (кому-то понятные, кому-то нет) термины "PHP", "JavaScript", "AJAX" и др.

1. Интернет, сервер, браузер

С понятием интернета, думаю, знакомы все и все представляют, что это такое. Если говорить коротко, то интернет - это единая сеть, объединяющая множество компьютеров в единое информационное пространство, в котором каждый компьютер имеет свой уникальный адрес. С помощью этого адреса компьютеры находят друг друга и обмениваются информацией.

Компьютеры можно поделить на две категории: сервера и клиенты. Под сервером обыватели понимают некий центральный компьютер, стоящий в офисе и хранящий на своем жестком диске в сетевой папке рабочие файлы. Это грубое представление отчасти верное, но не полное.

Сервер - это еще и программное обеспечение, которое стоит на компьютере и которое позволяет обрабатывать запросы других компьютеров, находящихся далеко за пределами офиса, а также отвечать им. Такое взаимодействие происходит по определенным правилам, протоколам (например HTTP , самый распространенный протокол интернета, речь о котором пойдет ниже). Если вы раньше когда-либо слышали такие слова как IIS или Apache , то это как раз и есть то самое ПО сервера (как правило его называют веб-сервером), которое отвечает за обработку запросов и отправку ответов.

Клиент - это компьютер, инициирующий запрос серверу. Но не только компьютер, а также как и в случае с сервером еще и программное обеспечение. Самый яркий пример - это веб-браузер (Internet Explorer , FireFox , Chrome , Safari и др.). Давайте далее для простоты так и будем под клиентом понимать веб-браузер, хотя на самом деле это может быть любое приложение, устанавливающее соединение и взаимодействующее с сервером.

Теперь разберемся непосредственно с процессом взаимодействия клиента и сервера. Что запрашивает клиент у сервера? Для более правильной терминологии будем говорить, что клиент запрашивает ресурс . По сути любой ресурс - это файл, хранящийся на сервере, только в зависимости от типа файла ответ сервера может быть самый разный. Яркий пример простого запроса - это когда пользователь в адресной строке браузера набирает адрес ресурса и нажимает Enter (например www.yandex.ru). По этому адресу браузер отыскивает в интернете компьютер и отправляет его веб-серверу запрос на получение главного файла (имя файла писать не обязательно, обычно веб-сервер знает, какой файл по данному адресу является главным). Сервер принимает запрос, обрабатывает и отправляет браузеру обратно считанную из главного файла информацию (как правило это поток html, о котором речь пойдет ниже). Браузер принимает информацию, обрабатывает html-код и рисует в своем окне красивую страничку, которую видит пользователь.

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

2. HTTP и HTML

Как уже было сказано ранее, общение клиента и сервера происходит по определенным правилам (протоколам). Самым распространенным из которых является HTTP , что означает протокол передачи гипертекста. Он описывает структуру запроса клиента и ответа сервера. Ниже на рисунке хорошо видно, из чего состоит такая структура.

Как видим общение клиента и сервера фактически сводится к обмену самой обычной текстовой информацией, которую может прочитать человек (см. тело запроса и ответа). Первая строчка запроса - это непосредственно команда веб-серверу от браузера получить таким-то методом такой-то ресурс по такому-то протоколу. Основные методы получения ресурсов - это GET и POST . В теории GET-метод служит для чтения ресурса, а POST - для изменения данных ресурса, но технически у метода GET нет запрета на изменение. На запрос сервер отвечает браузеру кодом ответа (в нашем случае 200 означает, что ресурс найден и отдан, т.е. ОК). В заголовках содержится служебная информация. Набор заголовков определяется конкретными условиями общения клиента и сервера. В теле ответа содержится непосредственно данные, ради которых все взаимодействие и затевалось.

При общении пользователя с внешним миром через браузер тело ответа как правило содержит поток HTML-кода. HTML - это язык гипертекстовой разметки, который понимает браузер. Прочитав этот код браузер отрисует пользователю страничку на экране. Но, как можно догадаться, ничто не мешает в теле ответа передать другие данные, например xml или обычный текст. Так в принципе и поступают в ряде случаев, когда нужно организовать удаленное взаимодействие между системами, только в этом случае клиентом будет выступать не браузер, а непосредственно одна из удаленных систем.

3. PHP и MySQL

Теперь мы знаем, что ресурс - это конкретный файл, обратившись к которому по протоколу HTTP клиент получит в ответ от веб-сервера содержимое этого файла. Но с увеличением объема хранимой информации встает вопрос о правильной организации ее хранения. Очевидно, что хранить всю информацию в одном или нескольких больших файлах - не вариант. Также не вариант, когда информация разбита на множество очень мелких файлов. Вот тут сильно помогают базы данных. Одна из самых распространенных баз данных для хранения серверной информации - это MySQL . С ее помощью обеспечивается безопасное хранение, извлечение и администрирование информации.

А для того, чтобы веб-сервер мог извлекать из базы и правильно отдавать информацию клиенту существуют серверные языки программирования, ярким представителем которых является PHP . Конечно же, серверный язык может не только извлекать и отдавать - у него есть еще очень много полезных функций, но для простоты понимания будем считать именно так. Код PHP вставляется прямо в тело ресурса и когда веб-сервер читает содержимое ресурса, чтобы отдать его клиенту, этот код выполняется (извлекается информация из базы, производятся какие-то вычисления и т.п.). Результатом выполнения является динамически скомпонованный все тот же html-код, который и направляется клиенту.

4. JavaScript, AJAX и Web 2.0

Получив данные браузер отрисует их пользователю. Единожды отрисованная информация статична. Каждая новая порция информация требует обращения к серверу и перезагрузки страницы браузера. Для повышения интерактивности (выпадающие списки, плавающие формы и др.) без обращения к серверу придуман специальный клиентский язык, встроенный во все браузеры, JavaScript . Его используют для манипуляции полученными с сервера данными. В то время как PHP является серверным языком, JavaScript существует только на клиентской части. Исполняемые JavaScript конструкции называют сценариями. Они встраиваются в html-код и загружаются с ресурса на сервере, но исполняются на клиенте, т.е. после того, как данные получены и загружены браузером.

Помимо манипуляции данными JavaScript обладает такой замечательной функциональностью, как взаимодействие с сервером без перезагрузки страниц браузера. Подобная технология значительно сокращает объем передаваемых данных, ведь нет необходимости перезагружать страницу целиком - достаточно получить необходимые данные и разместить их в нужном месте страницы. Такая методика называется AJAX , что переводится как асинхронный JavaScript и XML . Слово "асинхронный" означает, что ответ сервера может приходить в фоновом режиме, т.е. послав запрос браузеру не нужно блокировать работу пользователя до получения ответа - он может продолжить работу, а когда придет ответ, браузер его увидит и обработает. На рисунке ниже схематично приведено сравнение двух моделей взаимодействия клиента с сервером: традиционной и с применением AJAX .

На этой схеме видно, что в отличие от традиционной модели, в модели AJAX веб-ресурс загружается один раз, а дальше по мере необходимости подгружаются только необходимые данные, обработка и вставка в html-код страницы которых производится уже на клиенте (в браузере).

Если раньше ресурсы интернета рассматривались в основном как средство получения информации, то с развитием технологии AJAX появилась возможность интерактивного манипулирования ими, что выводит клиент-серверное взаимодействие на качественно новый уровень, понимаемый под термином Web 2.0 . Ресурсы, созданные на базе технологий Web 2.0 , отличает повышенная интерактивность. Фактически, такие ресурсы вполне могут заменить десктопные приложения. За примерами далеко ходить не надо. Интернет-сервис Google Docs предоставляет функциональность, схожую с основными приложениями пакета Microsoft Office с той лишь разницей, что никаких программ на компьютер устанавливать не нужно - вся работа осуществляется в окне браузера.

Говоря о JavaScript, стоит отметить тот факт, что в нем достаточно жестко реализуется политика безопасности - так называемая Same Origin Policy , суть которой сводится к простому правилу - действие JavaScript распространяется на данные, загруженные с одного домена (адреса) при прочих равных. Таким образом, например, если сценарий, загруженный с ресурса www.site1.com попытается напрямую из клиентской части обратиться к ресурсу www.site2.com, то получит запрет. Конечно существуют методики обхода такого ограничения. Скажу больше, современные версии JavaScript позволяют делать запросы на ресурсы на других адресах, но в этом случае запрос должен содержать специфические атрибуты (заголовки), а веб-сервер должен быть специальным образом настроен на прием таких запросов. Методика такой настройки называется CORS (cross-origin resource sharing) и у нее есть своя официальная спецификация. Однако не всегда есть возможность настроить веб-сервер под свои нужды, поэтому, если вы на практике столкнетесь, например, с потребностью получить данные по технологии AJAX с другого ресурса - проксируйте такие запросы через сервер, ведь серверная часть лишена подобных ограничений. Т.е. из клиентской части отправляете AJAX запрос своему веб-серверу, тот в свою очередь с помощью того же PHP перенаправляет запрос на нужный ресурс, получает данные и возвращает клиенту.

5. RPC, SOAP и веб-сервисы

От теоретических выкладок постепенно подошли к более практическим вопросам. RPC (remote procedure call) переводится как вызов удаленных процедур. Это класс технологий, позволяющих информационным системам удаленно взаимодействовать друг с другом. Таких технологий много и протоколы передачи данных они используют разные. Остановимся на рассмотрении SOAP (simple object access protocol), как более практичной с точки зрения 1с, т.к. именно на ней базируются веб-сервисы 1с (кстати говоря не только 1с).

Способом передачи (транспортом) данных по протоколу SOAP является, как правило, старый добрый HTTP, о котором говорилось выше. В тело HTTP-сообщения помещаются данные в виде XML-текста, сформированного по определенным правилам (спецификации протокола SOAP ). Тело запроса содержит XML-текст команды и параметры вызова метода в удаленной информационной системе, а тело ответа содержит XML-текст возвращаемых этим методом данных. По тем же правилам спецификации на стороне сервера или клиента XML-содержимое SOAP-сообщения интерпретируется в конкретные параметры или объекты. Возникает резонный вопрос, раз SOAP - это обмен при помощи XML, то зачем нужен именно специальным образом сформированный XML? Почему бы не передавать обычный XML с теми же данными? Все просто. При получении XML его придется разбирать (парсить) при помощи трехэтажного программного кода, так как заранее неизвестно, что это за XML и какая у него структура. Протокол же SOAP позволяет заранее определить структуру передаваемых данных а также опубликовать методы информационных систем, доступные для удаленных вызовов, что избавляет разработчиков от сложных процедур вызова методов и разбора данных.

Именно по таким принципам работают SOAP веб-сервисы . Если коротко, то их суть заключается в следующем. В удаленной информационной среде разворачивается веб-сервис, который публикуется на веб-сервере. Это означает, что у веб-сервиса появляется собственный адрес и с этого момента его можно называть ресурсом. Внутри среды между ее методом (функцией, процедурой) настраивается связь с данным веб-сервисом. Если с клиента по протоколу HTTP послать запрос на этот адрес, то веб-сервер, приняв этот запрос, транслирует его непосредственно в информационную среду, переведя входные параметры в удобный для нее формат. В информационной среде срабатывает связанный с веб-сервисом метод, отрабатывает и возвращает результат обработки обратно веб-серверу, который в свою очередь возвращает его клиенту по тому же протоколу HTTP.

6. 1С: веб-сервисы и HTTPСоединение

Итак, мы рассмотрели основы технологий, на которых базируется удаленное взаимодействие между информационными системами (файловый обмен и обмен почтовыми сообщениями принципиально не рассматривались). Какие же из них используются в 1С?

Прежде всего надо отметить, что начиная с платформы 1С 8.1 появились SOAP веб-сервисы , которые в значительной степени повысили функциональность системы. Их, наряду с веб-расширением, вполне можно рассматривать в качестве основы для создания веб-интерфейсов к 1С. В этой связи есть интересная статья , в которой детально рассматривается применение технологии AJAX и веб-сервисов для построения веб-интерфейса для 1С. И пусть вас не смущает, что в платформе 8.2 появилась возможность работать с 1С из браузера и может показаться, что данная тематика неактуальна. Уверяю вас - это далеко не так. Управляемый интерфейс 8.2 очень сильно шаблонизирован и повлиять на него разработчик практически никак не может. Чтобы делать действительно красивые, функциональные и юзабилити-мощные интерфейсы придется пользоваться описанными технологиями.

Веб-сервисы также можно использовать для обмена между двумя базами. Можно обмениваться произвольными XML-сообщениями, что повышает безопасность такого взаимодействия, в отличие от применения обмена, основанного на выгрузке/загрузке файлов, когда файл по пути могут подменить. Так, например, можно осуществлять выгрузку проводок из зарплатной базы в бухгалтерскую, расходных накладных из торговой конфигурации в бухгалтерскую и т.п.

Если веб-сервисы - это надстройка к протоколу HTTP посредством протокола SOAP , то объект HTTPСоединение позволяет делать прямые запросы и получать ответ от веб-сервера напрямую по протоколу HTTP. Примером может служить выгрузка каталога товаров в интернет-магазин. При помощи HTTPСоединение отправляем POST-запрос с данными о товарах (например в виде XML , включенного в тело запроса) на известный нам адрес (это может быть определенная нами.php страничка). На стороне веб-сервера, на котором находится интернет-магазин, кодом PHP разбираем полученный XML и складываем данные о товарах в базу данных (MySQL например). Подобная техника отлично описана в статье - рекомендую к прочтению.

Здравствуйте, уважаемые программисты 1С! Представляю вашему вниманию, обсуждению и использованию Модуль для работы 1С с внешними веб-сервисами.


Кому это может пригодиться

1. Вы опытный программист, и в данный момент времени перед Вами стоит задача интегрировать 1С с внешними программами посредством вызова внешних веб-сервисов, и эта задача возникает у Вас периодически, каждый раз при этом Вы дублируете код - этот модуль придёт Вам на помощь, вызывайте любые операции любых веб-сервисов из кода в две строчки.

2. Вы только учитесь программировать или Вы опытный программист 1С, но у Вас абсолютно нет опыта работы с веб-сервисами и понятием XDTO в 1С - модуль поможет Вам в тестовом режиме использования понять на практике определенные нюансы работы с XDTO объектами в 1С , на примере с тестовыми внешними веб-сервисами (можете использовать в учебных целях общедоступный веб-сервис для работы с погодой GlobalWeather ).

Конечно же, практика в виде чтения чужого кода с отладчиком хороша и полезна, не заменит никакую документацию, но для начала, если Вы не знакомы с веб-сервисами, но хотите понять всю суть работы с внешними веб-сервисами из 1С и публикации веб-сервисов 1С для внешнего использования, для начала советую прочитать статью о веб-сервисах в целом на хабре или на wikipedia , реализации веб-сервисов в 1С на ИТС , затем серию публикаций автора под названием . По Вашему желанию можно поискать любую другую информацию на просторах интернета, всё зависит от Вашего настроя. Но давайте вернёмся к сути данной публикации.

Принцип работы данного модуля

Когда у меня встала задача интеграции 1С с внешними источниками, я сразу понял, что код нужно разделить на несколько уровней абстракции.

Общий модуль (1-ый уровень абстракции), который обслуживает определенный внешний веб-сервис, предоставляет такие функции как: получить структуру параметров определенной операции на данном веб-сервисе, выполнить определенную операцию на определенном веб-сервисе, который по мере необходимости обращается к 2-ому общему модулю (2-ой уровень абстракции), который уже на более низком уровне предоставляет все необходимые операции для работы с веб-сервисами.

Более подробно схематично:

От теории к практике

Как это работает в коде:

Платформа 8.3, управляемые формы.

Платформа 8.2, обычные формы.

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



Под капотом при выполнении метода:

Как видно по последнему скрину, имеется возможность указать имя реквизита, который идентифицирует успешное выполнение, также модуль имеет функционал для создания анонимных типов, причем на любом уровне вложенности. Есть возможность передавать реквизит булевого типа - "Отказ", в случае, если веб-сервис вызывается при записи объектной сущности.

Так как статья ориентирована на программистов, так или иначе умеющих читать код 1С и делать логические выводы, я не буду слишком сильно углубляться в обьяснение принципов работы данного модуля.

Файлы во вложении:

1. Тестовые конфигурации с интегрированными тестовыми внешними веб-сервисами:

1.1. на платформе 8.2, с режимом запуска обычное приложение.

1.2. на платформе 8.3, с режимом запуска управляемое приложение.

1.3 Соответствующие обработки на обычных и управляемых формах, для вызова и тестирования интегрированных веб-сервисов.

2. Текстовые файлы содержащие код технического общего модуля и шаблон обслуживающего веб-сервис общего модуля.

3. Текстовый файл, описывающий необходимые действия для интеграции данного модуля.

Добрый день.
В связи с тем что 1с-программистов, работающих с веб-сервисами, нет, пришлось самому попробовать взяться за некую авантюру (с 1с, к сожалению, дел имел мало)
Дело в том, что у нас на предприятии есть информационная система(бд MSSQL),с поднятым на той стороне веб-сервисом, принимающим и отдающим штатную структуру, приказы по кадрам,список сотрудников и т.п.
Есть потребность эти данные из 1С туда перегружать.
[
Для начала хотел попробовать авторизоваться на сервере методом Login(String UserName, String Password) , потом получить штатную структуру GetStaffTree(AuthHeader authHeader) и перенести ее в форму 1С. Токен authHeader получается при авторизации
Сложность возникла после авторизации на сервисе

Описание метода Login


Host: ip

Content-Length: length
SOAPAction: "http://.../Login"




string
string


HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length




string



метод GetStaffTree:

POST /ImportStaff.asmx HTTP/1.1
Host: ip
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: "http://.../GetStaffTree"






string



HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length







int
string
string
string
short
string
string
string


int
string
string
string
short
string
string
string





В 1С авторизовался:

На форму выносил Поле, отображал там результат авторизации - успешно отображает токен.
далее использовал метод GetStaffTree

Результат - ошибка несоответствия типов:

Ошибка при вызове метода контекста (GetStaffTree)
Данные = Прокси.GetStaffTree(Авторизация);
по причине:
Несоответствие типов (параметр номер "1")


Судя по всему проблема в том, что токен получился строковый, а тип, который ждет метод GetSTaffTree, должен быть authHeader

Подскажите пожалуйста можно ли как-то выпутаться из этой ситуации и отобразить полученные данные в размещенной таблице на форме? Как корректно оперировать токеном?

Впервые слово веб-сервис я увидел в журнале Computerworld лет 7 назад. В голове отложилось, что эта технология позволяет одному ПК в сети предоставить в доступ какой либо сервис другим ПК.

Но что это такое я действительно понял только тогда, когда сам разработал веб сервисы для обмена между 1С и базой данных на MySQL.



По простому, технология веб-сервисов была создана для передачи сообщений от одного узла сети другому. Сообщения пересылаются в формате XML. Для пересылки сообщений 1с используется протокол SOAP. Но 1С использует не пересылку сообщений, а, основанную на пересылке, технологию вызова удаленных процедур. Так же платформа 1С позволяет вызывать операции сторонних веб-сервисов (ws-ссылки). Но мы в данных статьях не будет рассматривать ws-ссылки.


К примеру, где то имеется сервер с выходом в интернет, установленным сервером 1С: Предприятия, на котором опубликован веб-сервис с процедурой int plus2(a), которая прибавляет к "a" число 2 и возвращает результат.



На рисунке показано как один узел вызывает функцию plus2(). А другой узел возвращает ему результат в виде XML сообщения.

Но для того что бы воспользоваться веб-сервисом надо знать где его искать, какие есть у него функции, какие собственные типы вы определили. Для этого существует WSDL. WSDL (англ. Web Services Description Language) — язык описания веб-сервисов и доступа к ним, основанный на языке XML.


Одним из главных преимущств веб-сервисов является работа в гетерогенных(разнородных) средах. То есть воспользоваться функцией могут не только через 1с, но и используя любую другую среду разработки. Разработчик сайта на php в коде может обратиться к этому серверу по адресу, вызвать функцию и получить результат.


Вторым преимущество веб-сервисов является преобразование типов. Разработчику 1с совсем не надо думать как хранится, например, время в php, перед тем как его передать или принять как параметр. Нужно просто указать тип datetime и все преобразования сделает платформа.


Для передачи объектных данных базы 1с, например документа или справочника, существует перевод объектной модели в формат XML. Для этих целей служит XDTO. XDTO является механизмом объектного моделирования данных. Этот механизм позволяет описать ваши типы данных используя примитивные типы. Например документ с двумя реквизитами и одной табличной частью в XDTO описывается как ОбъектXDTO с тремя свойствами типа строка, одно из которых представлено в виде массива с набором других свойств. XDTO позволяет вам преобразовать объект не только для веб-сервиса, но и для записи, например, в xml файл. Скажу, что для каждого объекта уже есть своя модель XDTO и вам совсем не обязательно модель XDTO для каждого созданного вами документа, платформа делает структуру по умолчанию всегда.


Третий плюс в том что сам протокол SOAP чаще всего используется с протоколом HTTP, что помогает избежать многи проблем с маршртизацией, блокировками и прочим. Так же сообщения SOAP можно передавать и с многими другими протоколами, например можно передать в элеткронном письме.


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

Именно из за большого объема данных возникает второй недостаток - медленная скорость передачи данных.

Но тем не менее с каждым годом популярность веб сервисов растет, компания 1С уделяет им большое внимание и сейчас видно что 1С нацелена на развитие работы платформы 8.2 в сети интернет о чем свидетельствует выпуск БиблиотекиСтандартныхПодсистем с расширенными методами работы с веб сервисами и постоянное развитие веб-клиента.


Подведем итоги. Веб-сервисы в платформе 1с реализован в части удаленного вызова процедур. Для передачи сообщений 1с используется протокол SOAP. Чаще всего протокол SOAP используется совместно с протоколом HTTP, но может использовать и другие протоколы. Для описания структуры веб сервиса, составляющих его функций и типов данных используется язык WSDL. Для описания структур данных веб сервиса в 1с используется механизм XDTO. Для каждого типа метаданных (Документ ПриходнаяНакладная, Правочник Контрагенты и т.д.) в 1с хранится структура XDTO по умолчанию.

Постараюсь коротко и своими словами. SOAP сейчас весьма популярный протокол web API сервисов. То есть способ взаимодействия Вашей информационной системы через web с другими информационными системами.

В самом общем виде SOAP это протокол обмена структурированными XML сообщениями в произвольной распределенной вычислительной среде. Отсюда следует, что мы должны куда-то передать XML и получить назад также XML. Для передачи нам нужен транспорт. Или протокол передачи данных. Например SMTP, FTP, HTTP, HTTPS. Чаще всего HTTP, но это не принципиально.

Залогом успеха нашего обмена является способность правильно создать и передать XML запрос и правильно принять и разобрать XML ответ. Для того чтобы сделать все правильно нужно соблюдать (извиняюсь за тавтологию) правила. Эти правила описываются файлом специального формата: WSDL. WSDL - это язык описания правил использования web сервисов в том числе и сервиса SOAP.

Встроенный в 1С объект платформы WS-ссылка позволяет нам загрузить эти правила и на их основе использовать web сервис с максимальным удобством. Поставщик сервиса разрабатывает правила и размещает их по доступному для клиентов адресу. Естественно, что изменения в работе сервиса должны в случае необходимости сопровождаться внесением изменений в WSDL инструкцию. Но это не наша (клиента) забота. Для нас важны правила. Мы можем не иметь малейшего представления о том, как работает сервис, но точно знаем, что если обратимся к нему по правилам, то получим правильный ответ. Это сильно упрощает жизнь и разработку. Не знаю как Вам, а мне это нравится.

Вызвав одной универсальной функцией нужный метод (предварительно создав и передав нужную ему структуру параметров) SOAP сервиса Вы уже можете видеть результат в виде дерева. Описание ответных данных как правило содержится в документации поставщика, но это не обязательно. В любом случае в качестве ответа Вы получите некую структуру данных в виде XML файла, которая в общем виде может быть приведена к типу данных 1С "ДеревоЗначений". Вот это-то дерево и будет у Вас при любом вызове любого метода. Вызовите в этот момент отладчик для просмотра или выведите дерево результата на форму и разберитесь с каких ветвей снять заветные "плоды"-результаты. И все:)

Вот как просто можно вызвать и получить результаты разных методов в абсолютно разных сервисах (во втором примере метод без параметров):

Но как и в жизни в методы SOAP тоже можно обозначить как процедуры и функции. Процедуру мне посчастливилось увидеть всего один раз. Да и то, потому что публичный сервис с информацией о странах, который я использовал в качестве примера №1 перестал работать (на скрине он еще показан) и пришлось свочно искать ему замену. Что же делать с процедурой, ведь она не вернет нам ответ и не из чего будет создать дерево и, следовательно, неоткуда сорвать результат?

Но (опять же как часто бывает в жизни) с процедурой все стало даже проще. Она возвращает результат в свои же параметры. Как на скрине ниже:

Так как ПолучитьДеревоРезультатовДляSOAP задумывалась как функция то я ее заставил вернуть результат. В данном случае, не деревом, а структурой, содержащей выходные парметры метода. Какие из параметров выходные Вы всегда можете просмотреть в их свойствах. Хотя можно и не смотреть. Структура в результате будет содержать все выходные параметры метода. В нашем примере это "image" и "encoding". Получить результат из структуры оказывается еще проще. Если с дерева нужно "доставать", то в структуре все уже готово к употреблению.

В последний год мне довелось трижды связывать через web API свою конфигурацию с поставщиками услуг и информации, для получения данных или заказа услуг (например услуги доставки товара или рассылки СМС). В последний раз имея готовый код примера и обработку для 1С от поставщика я отказался от них и выбрал вариантом решения универсальный SOAP сервис. Просто потому, что так оказалось с наработанными ранее функциями проще.

Для данной публикации специально нашел парочку публичных SOAP ресурсов и слепил использующую их конфигурацию. 95% времени заняла работа с формами вызова и вывода данных. Зато в демке Вы можете видеть курс валют от ЦБ РФ на любую дату и краткий набор сведений о любой стране мира скриншот web страницы для произвольного url.

В общем кому лень или некогда разбираться с этим вот всем, а нужно сделать быстро и чтобы работало ссылка на скачивание демо конфигурации после публикации.