1с wsdl должен содержать элемент definitions по причине неверный формат

Обновлено: 07.07.2024

WSDL расшифровывается как язык описания веб-сервисов. Это стандартный формат для описания веб-службы. WSDL был разработан совместно Microsoft и IBM.

Особенности WSDL

Определения WSDL описывают, как получить доступ к веб-службе и какие операции она будет выполнять.

WSDL является неотъемлемой частью универсального описания, обнаружения и интеграции (UDDI), всемирного реестра предприятий на основе XML.

WSDL произносится как «wiz-тупой» и произносится как «WSD-L».

Определения WSDL описывают, как получить доступ к веб-службе и какие операции она будет выполнять.

WSDL произносится как «wiz-тупой» и произносится как «WSD-L».

Использование WSDL

WSDL часто используется в сочетании с SOAP и XML-схемой для предоставления веб-сервисов через Интернет. Клиентская программа, подключающаяся к веб-службе, может прочитать WSDL, чтобы определить, какие функции доступны на сервере. Все используемые специальные типы данных встраиваются в файл WSDL в форме XML-схемы. Затем клиент может использовать SOAP для фактического вызова одной из функций, перечисленных в WSDL.

История WSDL

WSDL 1.1 был представлен Ariba, IBM и Microsoft в виде заметки W3C для описания сервисов для W3C XML Activity по XML-протоколам в марте 2001 года.

WSDL 1.1 не был одобрен Консорциумом World Wide Web (W3C), однако он только что выпустил проект для версии 2.0, который будет рекомендацией (официальным стандартом), и, таким образом, одобрен W3C.

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

Три основных элемента WSDL, которые могут быть определены отдельно:

Документ WSDL имеет различные элементы, но они содержатся в этих трех основных элементах, которые можно разрабатывать как отдельные документы, а затем их можно объединять или повторно использовать для формирования полных файлов WSDL.

Элементы WSDL

Документ WSDL содержит следующие элементы:

В дополнение к этим основным элементам спецификация WSDL также определяет следующие служебные элементы:

Структура документа WSDL

Документ WSDL также может содержать другие элементы, такие как элементы расширения и элемент службы, которые позволяют группировать определения нескольких веб-служб в одном документе WSDL.

Продолжите анализировать пример документа WSDL.

Ниже приведен файл WSDL, предоставленный для демонстрации простой программы WSDL.

Предположим, что сервис предоставляет единственную общедоступную функцию, называемую sayHello . Эта функция ожидает один строковый параметр и возвращает приветствие одной строки. Например, если вы передаете параметр world, то сервисная функция sayHello возвращает приветствие «Hello, world!».

пример

Пример анализа

Элемент <definitions> должен быть корневым элементом всех документов WSDL. Он определяет название веб-службы.

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

является контейнером всех других элементов.

указывает, что этот документ называется HelloService .

определяет многочисленные пространства имен, которые используются в оставшейся части документа.

является контейнером всех других элементов.

указывает, что этот документ называется HelloService .

определяет многочисленные пространства имен, которые используются в оставшейся части документа.

Элемент types описывает все типы данных, используемые между клиентом и сервером.

WSDL не привязан исключительно к конкретной системе ввода.

WSDL использует спецификацию XML-схемы W3C в качестве выбора по умолчанию для определения типов данных.

Если служба использует только простые встроенные типы XML-схемы, такие как строки и целые числа, то элемент types не требуется.

WSDL позволяет определять типы в отдельных элементах, чтобы их можно было повторно использовать в нескольких веб-службах.

Элемент types описывает все типы данных, используемые между клиентом и сервером.

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

Далее для экономии веб-сервис будет именоваться просто сервис.

Риски использования веб-сервисов 1С

В платформе 1С81 появилась реализация веб-сервисов.

Но их использование чревато рисками:

Правила построения сервисов по продаже

Клиенту выдается документ о продаже (чек) только в том случае, если транзакция по сервису прошла успешно. Иначе возможна ситуация, когда клиент получит чек и будет пребывать в уверенности, что получил услугу, а на самом деле это не так.

Использование внешних SOAP-сервисов

Веб-сервисы SOAP используют WSDL схемы и объекты XDTO для представления данных.

Загрузка WSDL

Для того, чтобы использовать внешний сервис, нужно загрузить его WSDL-схему.

Проверка валидности WSDL-схемы

Особенности загрузки WSDL в 1С

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

1С не любит слово «policies». Если WS-ссылка не загружается, нужно убрать все, что связано с этим словом в любом XML-редакторе.

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

Для тестирования работающего внешнего веб-сервиса используйте обработку «ТестПроизвольногоВебСервиса.epf» из пакета к этой статье.

Таким способом можно протестировать любой сервис, который имеет простые точки входа, содержащие параметры простых типов: число, дата, строка.

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

Стандартные средства отладки сервисов

Для отладки можно использовать программу SoapUI, который может передать произвольный запрос веб-сервису и получить от него ответ.

Использование 1С как сервиса

Правила разработки сервиса на базе 1С

Операция «Hello»

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

Например, можно использовать операцию Hello без параметров, которая просто возвращает булево значение Истина.

Публикация веб-сервиса

Задача публикации Web-сервисов сводится к размещению конфигурационных файлов *.1cws Web-сервисов в соответствующем каталоге веб-сервера с соответствующими настройками для веб сервера. Для того, чтобы выполнить публикацию Web-сервисов, следует выполнить команду меню «Администрирование | Публикация Web-сервисов».

В результате выполнения этой команды будет открыто окно публикации Web-сервисов.

Окно публикации Web-сервисов содержит путь к веб-серверу и два списка:

«Web-сервисы» – список Web-сервисов конфигурации;
«Публикация» – список Web-сервисов, опубликованных на указанном веб-сервере.

С помощью кнопки «Соединение…» следует указать веб-сервер, на котором требуется опубликовать Web-сервисы.

Окно выбора пути к веб-серверу позволяет указать путь двумя способами:

на закладке «Файлы» – этот способ используется в том случае, когда публикация выполняется на том же компьютере, на котором установлен веб-сервер. В качестве пути указывается локальный каталог, соответствующий интернет-странице, с которой будет выполняться вызов публикуемого Web-сервера;
на закладке «FTP сайт» – этот способ используется в том случае, когда требуется опубликовать Web-сервис на удаленном компьютере. Для выполнения публикации необходимо указать параметры FTP-соединения с удаленным компьютером и каталог, в котором будет опубликован Web-сервис.

Публикация выбранного Web-сервиса осуществляется с помощью кнопки «Опубликовать»

Для отмены публикации Web-сервиса используется кнопка «Удалить».

Для обновления списка опубликованных Web-сервисов используется кнопка «Обновить текущий список».

Публиковать можно в локальном каталоге или по FTP. Можно публиковать и на удаленный сервер по UNC-пути, если удаленный сервер входит в локальную сеть.

Авторизация к веб-сервису 1С

Для доступа к сервису нужно пройти аутентификацию.

Обычно веб-сервис работает под одним конкретным пользователем (чаще - специально созданным). Можно пользователя 1С "прикрепить" средствами Windows-аутентификации к пользователю Windows IUSR_ (для пользователя отключить авторизацию 1С). Как вариант, можно очистить список пользователей 1С, тогда авторизация не требуется.

Если требуется несколько пользователей, то можно создать несколько логинов для веб-сервера, к каждому из них привязать пользователя Windows и соответственно, прописать в 1С доступ к пользователям Windows.

В свойствах Пользователь и Пароль объекта WSПрокси используется не логин 1С, а логин пользователя веб-сервера.

Тестирование веб-сервиса 1С

Для тестирования 1С как веб-сервиса используйте обработку «ТестПроизвольногоВебСервиса.epf», как описано в разделе «Тестирование работающего внешнего веб-сервиса».

Файл 1cws и является WSDL-описанием веб-сервиса 1С.

Использование сервисов в Рознице

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

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

Сервис может быть по-разному интегрирован в розничную программу, написанную на языке 1С (УТ, Розница и другие):

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

Организация служебных данных в 1С

Для хранения информации о транзакции в чеке необходимо создать дополнительную табличную часть «Сложные продажи» с реквизитами:

Номенклатура – привязка к номенклатуре чека.
Параметр - ссылка на справочник «Сложные продажи: Параметры».
Значение – значение параметра, составного типа. Строковое представление должно быть довольно длинным (1024 символа), чтобы помещался текст чека.

Справочник «Сложные продажи: Параметры» содержит перечень параметров транзакции.

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

Продавцу делается отдельная закладка (или печатная форма, чтобы не менять конфигурацию), в которой он может посмотреть табличку реквизитов транзакции для чека.

Использование обработок на языке 1С

Рассмотрим на примере условной услуги Paym для конфигурации «Розница».

Отдельный вопрос – как обеспечить завершенность транзакции. Т.е. если транзакция прошла в сервисе, как сделать, чтобы она не потерялась в 1С. Наиболее оптимальный путь – сверка реестров. Но это предмет отдельного рассмотрения.

Использование программ, интегрируемых с 1С

Часто в веб-сервисах используется XDTO. Приведем наиболее важные советы и рецепты по использованию XDTO в 1С.

XDTO в платформе 1С

XDTO-пакеты, описанные в ветке «XDTO-объекты» конфигурации, доступны для создания типов и объектов в глобальной фабрике Фабрика XDTO. Это не сразу становится очевидным.

Некоторые типы в схеме не имеют имени, чтобы их получить, надо пройтись по иерархии типов.

В примере был описан список System, содержавший структуры XDTO. Чтобы создать саму структуру, нужно было получить ее тип таки вот образом:

Частые проблемы с XDTO

Разные форматы XSD-схем

В некоторых форматах теги называются xs:, в некоторых xsd:, но 1С благополучно понимает оба формата. Однажды была ситуация, что XSD нормально без ошибок импортировалась в 1С, но не создавала ни одного пакета. Причина была в отсутствии атрибута targetNamespace у тега , соответственно 1С не знала, в какой пакет помещать схему, но ошибок не выдавала.

Сопровождение сервисов

Учитывая, что сервис – это совокупность двух систем – 1С и внешней, ошибки могут быть в обоих системах, что снижает общую надежность работы.

Для того, чтобы проще было разбираться в причинах отказов в работе сервисов, рекомендуется использовать комплекс мер.

Протоколирование запросов

Рекомендуется сохранять все запросы и ответы на них в каталог программы, файлы сохранять в папки вида ГГГГММДД по дням. Это очень способствует пониманию причин проблем.

anig99 wrote: Если у кого возникнет такая проблема, то на платформе 8.2.19.121 возникает ошибка
Определения = Новый WSОпределения("http://api.vetrf.ru/schema/platform/services/2.0-RC-last/ams-mercury-g2b.service_v2.0_pilot.wsdl");
по причине:
При создании описания сервиса произошла ошибка.
по причине:
Неправильный путь к файлу 'ApplicationManagementService_v1.1.wsdl'

На 8.3 такой ошибки нет. Попытаюсь решить. Если получится, то сообщу.

Для получения Фабрики нужно использовать такой код:

Не понятно как влияет, но ЗапросWeb = Новый HTTPЗапрос("platform/services/ApplicationManagementService"); использовал ЗапросWeb = Новый HTTPЗапрос("platform/services/2.0/ApplicationManagementService"); Вроде работает и так, и так.

nifor wrote: Коллеги добрый день . Подскажите у кого то посредством 1С получилось заполнить атрибуты id и for (api 2.0) ? При заполнении строковым типом ругается на неверный формат при отправке запроса .

Формирую ProcessIncomingConsignmentOperation в версии 2,0.

При сохранении XML с помощью ФабрикиXDTO "перепрыгивают" реквизиты.
(ФабрикаXDTO создается по рекомендациям, выложенным здесь на форуме, та же схема с 1,4 отрабатывала без проблем)

И вот эти issueDate и issueNumber, относящиеся к vetCertificate, почему-то уезжают вниз, хотя должны идти следом за issueSeries.
В итоге пакет шлюзом не принимается, выдает отлуп "Format validation failed due to XML Schema rules: Элемент 'issueDate' не предусмотрен." - я так понимаю, что порядок элементов ему важен.
В SOAPui элементы на место поставишь - запрос проходит.

Грешил на релиз платформы, но на 8.3.8 , 8.3.9 , 8.3.10 результат одинаков.
1С, что-ли, не берет во внимание тег <xs:sequence> в XSD-схеме.

Подчеркивание впереди прицепите. Там базовый тип "NCName", а он должен содержать первым символом или букву или подчеркивание.

vvche wrote: Вот не пойму, в чем косяк.

Формирую ProcessIncomingConsignmentOperation в версии 2,0.

При сохранении XML с помощью ФабрикиXDTO "перепрыгивают" реквизиты.

Сам спросил, сам ответил

Определение = Новый WSОпределения("http://api.vetrf.ru/schema/platform/services/2.0-RC-last/ams-mercury-g2b.service_v2.0_pilot.wsdl");
ПодключениеОбмена = Новый WSПрокси(Определение,"http://api.vetrf.ru/schema/cdm/application/service","ApplicationManagementServiceBindingQSService","ApplicationManagementServiceBindingQSPort". Новый ЗащищенноеСоединениеOpenSSL( неопределено, неопределено ));
ПодключениеОбмена.Пользователь = "*************";
ПодключениеОбмена.Пароль = "************";
SubmitApplicationRequest = Фабрика.Создать(Фабрика.Тип("http://api.vetrf.ru/schema/cdm/application/ws-definitions", "submitApplicationRequest"));
Application = Фабрика.Создать(Фабрика.Тип("http://api.vetrf.ru/schema/cdm/application", "Application"));
ApplicationDataWrapper = Фабрика.Создать(Фабрика.Тип("http://api.vetrf.ru/schema/cdm/application", "ApplicationDataWrapper"));

modifyEnterpriseRequest = Фабрика.Создать(Фабрика.Тип("http://api.vetrf.ru/schema/cdm/mercury/g2b/applications/v2", "ModifyEnterpriseRequest"));;

ApplicationDataWrapper.Добавить(ФормаXML.Элемент,"http://api.vetrf.ru/schema/cdm/mercury/g2b/applications/v2", "ModifyEnterpriseRequest", modifyEnterpriseRequest);
Application.data = ApplicationDataWrapper;
Application.serviceId = "mercury-g2b.service:2.0";
Application.issuerId = "******************";
Application.issueDate = ТекущаяДата();

SubmitApplicationRequest.apiKey = "***********************";
SubmitApplicationRequest.application = Application;

Результат = ПодключениеОбмена.submitApplicationRequest(SubmitApplicationRequest.apiKey, SubmitApplicationRequest.application);

Вылезает такая ошибка:
Несоответствие типов XDTO:
Тип 'ModifyEnterpriseRequest' не найден
Тип принадлежит пакету, отсутствующему в фабрике типов XDTO

Автор: Арулази Десиасилан (Arulazi Dhesiaseelan)
Перевод: Intersoft Lab

Как известно, одним из направлений деятельности международного консорциума W3C является программа по разработке и продвижению технологий Web-сервисов (Web Services Activity), в рамках которой рабочая группа Web Services Description занимается определением языка описания Web-сервисов и возможных способов взаимодействия с сервисами. 26 марта 2004г. рабочая группа обнародовала черновой вариант спецификации WSDL 2.0. Это событие можно расценить как переломный момент в истории развития языка WSDL. В этой статье рассказывается о изменениях, которые были внесены в спецификацию WSDL 1.1, и о том, что было улучшено в новой версии языка WSDL.

Рабочие варианты спецификаций W3C WSDL 2.0

Web Services Description Requirements (Требования, предъявляемые к описанию Web-сервисов);
Web Services Description Usage Scenarios (Сценарии использования языка описаний Web-сервисов).

В редакторской версии приведенных выше документов содержится информация о ходе работ над этими спецификациями.

Отличия WSDL 2.0 от языка версии 1.1

Концептуальная модель WSDL 2.0

В конкретной части описания элементы binding задают транспорт и формат доставки для интерфейсов (элементов interface ). Элемент сервиса (элемента service ) endpoint связывает сетевой адрес в соответствие со связыванием (элементом binding ). Наконец, элемент service группирует конечные точки (элементы endpoint ), которые реализуют общий интерфейс (элемент interface ). На рисунке 1 изображена концептуальная модель компонентов WSDL.

Рис. 1. Концептуальная модель WSDL

Компоненты WSDL

Язык WSDL содержит ряд компонентов и их ассоциированных свойств, предназначенных для описания Web-сервисов. В следующих разделах статьи кратко рассматривается каждый из этих компонентов. Листинг 1. Скелет WSDL 2.0

definitions

Элемент definitions является корневым элементов любого документа WSDL. Он используется в качестве контейнера, в котором содержится вся необходимая информация о данной услуге и ее атрибутах. На рисунке 2 приведена схема элемента definitions . Атрибут targetNamespace этого элемента является обязательным атрибутом типа anyURI . Это пространство имен может напрямую или косвенно определять семантику WSDL. Кроме того у элемента definitions могут быть другие необязательные атрибуты, соответствующие различным пространствам имен, которые могут использоваться в документе WSDL.

Рис. 2. Схема элемента definitions

include

Элемент include предназначен для разделения описаний Web-сервиса на модули - различные компоненты описаний сервисов из одного и того же пространства имен могут находиться в другом документе WSDL, которой можно использовать в описаниях Web-сервисов. Атрибут location является обязательным, он задает нахождение этих документов WSDL. Фактическое значение пространства имен добавляемого документа WSDL должно соответствовать целевому пространству имен элемента definitions в документе WSDL, в который добавляется первый документ. На рисунке 3 приведена схема элемента include .

Рис. 3. Схема элемента include

import

По своему назначению элемент import очень похож на элемент include , с тем исключением, что импортированный документ WSDL может относиться к другому целевому пространству имен. Атрибут namespace этого элемента является обязательным, а атрибут location - необязательным. На рисунке 4 приведена схема элемента import .

Рис. 4. Схема элемента import

types

Рис. 5. Схема элемента types

interface

Рис. 6. Схема элемента interface

binding

Рис. 7. Схема элемента binding

service

Элемент service описывает набор элементов endpoint , которые указывают на одиночный сетевой адрес для элемента binding . Вся другая информация о протоколе сдержится в элементе binding . К элементу service можно обратиться по Qname . У этого элемента есть обязательные атрибуты name и interface . На рисунке 8 приведена схема элемента service .

Рис. 8. Схема элемента service

Описание сервиса, предназначенного для передачи информации о котировках акций, на WSDL 1.1 и WSDL 2.0

В этом разделе кратко рассмотрен простой сервис, предназначенный для передачи информации о котировках акций. В Листинге 2 представлены типы XML-схемы, которые используются в описании этого сервиса. Листинги 3 и 4 - описание интерфейса сервиса на WSDL 1.1 и WSDL 2.0, соответственно, листинги 5 и 6 - описание реализации сервиса на WSDL 1.1 и WSDL 2.0.

Заключение

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

Читайте также: