Xml web службы разработанные и функционирующие под управлением операционной среды net framework

Обновлено: 06.07.2024

Обозреватель Internet Explorer является примером неуправляемого приложения, в котором располагается среда (в виде расширения типа MIME). Размещение среды в обозревателе Internet Explorer позволяет встраивать управляемые компоненты и элементы управления Windows Forms в документы HTML. Такое размещение среды делает возможным использование управляемого мобильного кода (схожего с элементами управления Microsoft ActiveX), предоставляя при этом расширенные возможности, характерные исключительно для управляемого кода, к примеру выполнение при частичном доверии или изолированное хранение файлов.

На рисунке ниже показаны связи между средой CLR, библиотекой классов, приложениями и всей системой в целом. Он также дает представление о том, как управляемый код работает в более крупной архитектуре.

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

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

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

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

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

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

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

Наконец, среда может располагаться на высокопроизводительных серверных приложениях, таких как SQL Server 2008 и службы IIS. Такая инфраструктура позволяет использовать при создании бизнес-логики управляемый код, сохраняя при этом высокий уровень производительности, характерный для передовых производственных серверов, поддерживающих размещение среды.

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

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

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

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

На рисунке ниже показана основная схема сети и работа управляемого кода в различных серверных средах. Сервер, к примеру IIS или SQL Server, выполняет стандартные операции, а за логику приложения отвечает управляемый код.

Управляемый код на стороне сервера

Веб-службы XML - это важный шаг вперед в области веб-технологий. Они представляют собой компоненты распределенных серверных приложений и напоминают обычные веб-узлы. В отличие от веб-приложений веб-службы XML не имеют пользовательского интерфейса и не предназначены для обозревателей, будь то Internet Explorer или Netscape Navigator. Веб-службы XML состоят из стандартных программных компонентов, созданных для использования в других приложениях: традиционных клиентских приложениях, веб-приложениях и даже в других веб-службах XML. Благодаря этому технология веб-служб XML значительно ускоряет разработку приложений и их развертывание в высокораспределенной среде Интернета.

И наконец, как и страницы веб-форм в управляемой среде, веб-службы XML работают с высокой скоростью - со скоростью приложений на машинном языке - и используют масштабируемую систему связей IIS.

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

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

Назовем сервисом (service) ресурс , реализующий бизнес-функцию и обладающий следующими свойствами:

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

Частным случаем сервиса является XML web -сервис.

XML Web-сервис - это особый тип web -приложения, который:

В отличие от традиционного web -приложения, у web -сервиса нет пользовательского интерфейса. Вместо этого у него есть программный интерфейс , то есть web -сервис предоставляет функции ( web -методы), которые могут быть вызваны удаленно (например, по сети Internet ). Web -сервис не предназначен для обслуживания конечных пользователей. Его задача - предоставление услуг другим приложениям, будь то web -приложения, приложения с графическим пользовательским интерфейсом или консольные приложения.

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

Место web-сервисов среди других технологий удаленного вызова

Существует немало протоколов и технологий удаленного вызова: Microsoft Distributed Component Object Model ( DCOM ), the Object Management Group 's Common Object Request Broker Architecture ( CORBA ), Sun 's Remote Method Invocation ( RMI ), . NET Remoting , XML Web Services.

Все эти компонентно-ориентированные технологии ( DCOM , CORBA и RMI ) долгие годы успешно применялись в Intranet-приложениях. Они обеспечивают надежную, масштабируемую архитектуру. Однако при использовании этих технологий в Internet возникают две серьезные проблемы. Во-первых, они плохо взаимодействуют между собой. Все технологии оперируют объектами, но существенно отличаются деталями: управлением жизненным циклом, поддержкой конструкторов и степенью поддержки наследования. Второй, более важный аспект состоит в том, что ориентация на RPC-взаимодействия приводит к построению сильносвязных систем на основе явных вызовов методов объектов.

В отличие от данных технологий, XML Web Services и . NET Remoting в полной мере реализуют объектно-ориентированный подход для web -программирования.

Есть много способов написания web -сервисов. Их можно разрабатывать вручную или с помощью SOAP -инструментов, предоставляемых Microsoft, IBM и др. Написание web -сервисов с помощью Microsoft. NET имеет два преимущества:

Создание

Используя фоновый код, классы web-сервиса можно вынести из asmx-файлов в отдельные файлы.

Web-сервисы позволяют вызывать свои методы асинхронно. Асинхронный вызов возвращает управление немедленно, независимо от того, сколько времени нужно web-сервису на обработку вызова. Асинхронные вызовы полезны в случае, если обработка вызова требует значительного времени. Приложение выполняет вызов, далее продолжает работать, не дожидаясь результата вызова, и позднее получает результаты асинхронного вызова. Получение результата происходит при повторном вызове web-метода в удобное приложению время либо с помощью подписки на уведомление об окончании обработки вызова web-сервисом (механизм делегатов).

Описание web-сервисов при помощи контрактов

Для того чтобы другие разработчики могли использовать AdditionService, им нужно знать, какие методы он предоставляет, какие протоколы поддерживает, сигнатуры методов и адрес web-сервиса (URL). Вся эта и другая информация может быть описана на языке WSDL (Web Service Description language).

Обнаружение web-сервисов

Каким образом другие разработчики узнают о существовании AdditionService?

Во-первых, с помощью DISCO (сокращение от слова discovery) - файлового механизма поиска локальных web-сервисов, то есть механизма получения списка доступных web-сервисов из DISCO-файлов, размещенных на web-серверах. Кроме того, DISCO-файлы содержат записи о расположении WSDL-контрактов имеющихся сервисов. DISCO-файл представляет собой XML-файл с записями.

А как же осуществляется поиск web-сервисов в глобальной сети? Для поиска web-сервисов в глобальной сети Microsoft, IBM и Ariba совместно разработали UDDI (Universal Description Discovery and Integration) - спецификацию построения распределенных баз данных, которая позволяет отыскивать web-сервисы. UDDI поддерживается сотнями компаний. UDDI-сайты сами являются web-сервисами. Каждый может опубликовать свой реестр на основе UDDI. Большинство разработчиков никогда не используют UDDI API напрямую. Вместо этого к реестрам UDDI обращаются инструментальные средства разработки. Они также генерируют классы-оболочки обнаруженных и выбранных web-сервисов.

Итоги

Дэн Валин (Dan Wahlin)

Настройка веб-служб

Создание веб-служб с поддержкой AJAX

В листинге 4 показан пример применения атрибута WebMethod к методу с именем Жеткустомерсбикаунтри ().

Листинг 4. Использование атрибута WebMethod в веб-службе

Метод Жеткустомерсбикаунтри () принимает параметр Country и возвращает массив объектов Customer. Значение страны, передаваемое в метод, пересылается классу бизнес-уровня, который, в свою очередь, вызывает класс уровня данных для получения данных из базы данных, заполнения свойств объекта Customer данными и возвращения массива.

Использование атрибута ScriptService

В листинге 5 показан пример применения атрибута ScriptService к классу веб-службы с именем Кустомерссервице.

Листинг 5. Использование атрибута ScriptService для включения веб-службы в AJAX

Атрибут ScriptService выступает в качестве маркера, который указывает, что его можно вызывать из кода скрипта AJAX. В действительности он не обрабатывает ни одну из задач сериализации или десериализации JSON, которые происходят в фоновом режиме. Скрипсандлерфактори (настроенный в web.config) и другие связанные классы выполняют большую часть обработки JSON.

Использование атрибута ScriptMethod

Свойство Усехттпжет можно использовать, когда веб-метод должен принимать запросы GET, а не запросы POST. Запросы отправляются с использованием URL-адреса с входными параметрами веб-метода, преобразованными в параметры строки запроса. Свойство Усехттпжет по умолчанию имеет значение false и должно быть установлено в только тогда, когда известно, что true операции являются надежными, а конфиденциальные данные не передаются в веб-службу. В листинге 6 показан пример использования атрибута ScriptMethod со свойством Усехттпжет.

Листинг 6. Использование атрибута ScriptMethod со свойством Усехттпжет.

Ниже показаны примеры заголовков, отправленных при вызове веб-метода Хттпжетечо, показанного в листинге 6:

В листинге 7 показан пример использования свойства ResponseFormat для указания того, что XML-данные должны возвращаться из веб метода.

Листинг 7. Использование атрибута ScriptMethod со свойством ResponseFormat.

Свойство ResponseFormat также можно использовать вместе со свойством Ксмлсериализестринг. Свойство Ксмлсериализестринг имеет значение по умолчанию false, что означает, что все возвращаемые типы, за исключением строк, возвращаемых из веб-метода, сериализуются как XML, если ResponseFormat свойство имеет значение ResponseFormat.Xml . Если параметр XmlSerializeString имеет значение true , все типы, возвращаемые из веб-метода, СЕРИАЛИЗУЮТСЯ как XML, включая типы String. Если свойство ResponseFormat имеет значение ResponseFormat.Json , свойство ксмлсериализестринг игнорируется.

В листинге 8 показан пример использования свойства Ксмлсериализестринг для принудительного сериализации строк в формате XML.

Листинг 8. Использование атрибута ScriptMethod со свойством Ксмлсериализестринг

Далее показано значение, возвращаемое при вызове веб-метода Жетксмлстринг, показанного в листинге 8:

Работа со сложными типами

В листинге 5 показан пример возврата сложного типа с именем Customer из веб-службы. Класс Customer определяет несколько различных простых типов внутренне, как свойства FirstName и LastName. Сложные типы, используемые в качестве входного параметра или возвращаемого типа в веб-методе с поддержкой AJAX, автоматически сериализуются в JSON перед отправкой на клиентскую часть. Однако вложенные сложные типы (определяемые внутри другого типа) не предоставляются клиенту в качестве отдельных объектов по умолчанию.

Листинг 9. Показанный здесь класс Кустомердетаилс содержит два вложенных составных типа.

Объекты Address и Gender, определенные в классе Кустомердетаилс, показанном в листинге 9, не будут автоматически доступны для использования на стороне клиента через JavaScript, так как они являются вложенными типами (Address является классом, а Gender — перечислением). В ситуациях, когда вложенный тип, используемый в веб-службе, должен быть доступен на стороне клиента, можно использовать атрибут Женератескрипттипе, упомянутый ранее (см. список 10). Этот атрибут можно добавить несколько раз в случаях, когда из службы возвращаются различные вложенные сложные типы. Его можно применить непосредственно к классу веб-службы или к конкретным веб-методам.

Список 10. Использование атрибута Женератескриптсервице для определения вложенных типов, которые должны быть доступны клиенту.

Создание прокси-серверов JavaScript

Добавление ссылки на Кустомерссервице. asmx через элемент управления ScriptManager вызывает динамическое создание прокси-сервера JavaScript и ссылки на страницу. Прокси-сервер внедряется с помощью < > тега script и динамически загружается путем вызова файла кустомерссервице. asmx и добавления переключателем/JS в конец. В следующем примере показано, как прокси-сервер JavaScript внедряется на страницу при отключении отладки в web.config.

Если отладка включена в web.config отладочная версия прокси-сервера JavaScript будет внедрена на страницу, как показано далее:

Использование прокси-серверов JavaScript

Пример использования прокси JavaScript для вызова веб-метода с именем Жеткустомерсбикаунтри () показан в листинге 13. Функция Жеткустомерсбикаунтри () вызывается, когда пользователь нажимает кнопку на странице.

Листинг 13. Вызов веб-службы с помощью прокси-сервера JavaScript.

Этот вызов ссылается на пространство имен Интерфацетраининг, класс Кустомерссервице и веб-метод Жеткустомерсбикаунтри, определенный в службе. Он передает значение страны, полученное из текстового поля, а также функцию обратного вызова с именем Онвсрекуесткомплете, которая должна вызываться при возвращении асинхронного вызова веб-службы. Онвсрекуесткомплете обрабатывает массив объектов Customer, возвращенных из службы, и преобразует их в таблицу, которая отображается на странице. Выходные данные, созданные при вызове, показаны на рис. 1.

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

Рис. 1. Привязка данных, полученных путем выполнения асинхронного вызова Ajax к веб-службе. (Щелкните, чтобы просмотреть изображение с полным размером)

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

Обработка ошибок

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

Листинг 14. Определение функции обратного вызова ошибок и отображение ошибок.

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

Выходные данные, создаваемые вызовом функций ошибок AJAX ASP.NET.

Обработка данных XML, возвращаемых веб-службой

Ранее было показано, как веб-метод может возвращать необработанные данные XML с помощью атрибута ScriptMethod вместе со свойством ResponseFormat. Если ResponseFormat имеет значение ResponseFormat.Xml, данные, возвращаемые веб-службой, сериализуются как XML, а не как JSON. Это может быть полезно, если XML-данные необходимо передать непосредственно клиенту для обработки с помощью JavaScript или XSLT. В настоящее время Internet Explorer 5 или более поздней версии предоставляет лучшую объектную модель на стороне клиента для анализа и фильтрации XML-данных из-за встроенной поддержки MSXML.

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

В листинге 15 показан пример вызова веб-метода с именем Жетрссфид (), который возвращает объект XmlElement. Жетрссфид () принимает один параметр, представляющий URL-адрес канала RSS для извлечения.

Листинг 15. Работа с XML-данными, возвращаемыми из веб-службы.

Обработка сложных типов

Сложные типы, принятые или возвращаемые веб-службой, автоматически предоставляются через прокси-сервер JavaScript. Однако вложенные сложные типы не доступны напрямую на стороне клиента, если только атрибут Женератескрипттипе не применен к службе, как обсуждалось ранее. Зачем использовать вложенный сложный тип на стороне клиента?

Вывод, создающий из вызова веб-службы, которая возвращает данные RSS.

Рис. 3. вывод, создающий из вызова веб-службы, которая ВОЗВРАЩАЕТ данные RSS. (Щелкните, чтобы просмотреть изображение с полным размером)

В листинге 16 показан пример кода на стороне клиента, который вызывает объект Address, определенный в пространстве имен модели, заполняет его обновленными данными и присваивает ему свойство Address объекта Кустомердетаилс. Затем объект Кустомердетаилс передается в веб-службу для обработки.

Листинг 16. Использование вложенных сложных типов

Создание и использование методов страницы

Листинг 17. Определение методов страницы.

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

Листинг 18. Вызов методов страницы с помощью объекта JavaScript Pagemethod.

Использование объекта Pagemethod очень похоже на использование прокси-объекта JavaScript. Сначала необходимо указать все данные параметров, которые должны быть переданы в метод страницы, а затем определить функцию обратного вызова, которая должна вызываться при возврате асинхронного вызова. Также можно указать обратный вызов сбоя (см. список 14 для примера ошибок обработки).

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

В случаях, когда необходимо использовать элемент управления только на определенной странице, можно ссылаться на него, добавив директиву Reference в верхнюю часть страницы, как показано ниже, а не обновлять web.config:

Использование элемента управления Аутокомплетикстендер.

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

Аутокомплетикстендер имеет несколько различных свойств, включая стандартные ИДЕНТИФИКАТОРы и свойства runat, найденные в серверных элементах управления. Кроме того, он позволяет определить, сколько символов имеет тип конечного пользователя, прежде чем веб-служба запрашивает данные. Свойство MinimumPrefixLength, показанное в листинге 19, вызывает вызов службы каждый раз при вводе символа в текстовое поле. Это значение следует устанавливать с осторожностью, поскольку каждый раз, когда пользователь вводит символ, который будет вызывать веб-служба для поиска значений, соответствующих символам в текстовом поле. Веб-служба для вызова, а также целевой веб-метод определяется с помощью свойств Сервицепас и Сервицемесод, соответственно. Наконец, свойство TargetControlID определяет, в какое текстовое поле следует привязать элемент управления Аутокомплетикстендер к.

Для вызова веб-службы необходимо применить атрибут ScriptService, как обсуждалось ранее, а целевой веб-метод должен принимать два параметра с именами Префикстекст и Count. Параметр Префикстекст представляет символы, введенные конечным пользователем, а параметр Count — количество возвращаемых элементов (значение по умолчанию — 10). В листинге 20 показан пример веб-метода, вызываемого элементом управления Аутокомплетикстендер, показанным выше в листинге 19. Веб-метод вызывает метод бизнес-уровня, который, в свою очередь, вызывает метод уровня данных, который обрабатывает фильтрацию данных и возвращает результаты сопоставления. Код для метода уровня данных показан в листинге 21.

Листинг 20. Фильтрация данных, отправляемых из элемента управления Аутокомплетикстендер.

Листинг 21. Фильтрация результатов на основе ввода конечных пользователей.

Веб-сервис — идентифицируемая уникальным веб-адресом (URL-адресом) программная система, которая обеспечивает взаимодействие между приложениями. Назначение веб-сервиса — настройка интеграции между Creatio и внешними приложениями и системами.

На основе пользовательской бизнес-логики Creatio сгенерирует и отправит запрос веб-сервису, получит ответ и предоставит необходимые данные. Эти данные можно использовать для создания или обновления записей в Creatio, а также для реализации пользовательской бизнес-логики или автоматизации.

Виды веб-сервисов в Creatio:

    Внешние REST и SOAP-сервисы, с которыми можно настроить интеграцию low-code инструментами. Подробнее читайте в блоке статей Веб-сервисы документации для пользователя.

Системные веб-сервисы.

Пользовательские веб-сервисы.

Виды аутентификации, которые поддерживаются веб-сервисами в Creatio, описаны в статье Аутентификация. Рекомендуемым способом аутентификации является аутентификация на основе открытого протокола авторизации OAuth 2.0, которая описана в статье Настроить авторизацию интегрированных приложений по протоколу OAuth 2.0.

  • odata — выполнение запросов от внешних приложений к серверу баз данных Creatio по протоколу OData 4. Описание использования протокола OData 4 в Creatio содержится в статье OData.
  • EntityDataService.svc — выполнение запросов от внешних приложений к серверу баз данных Creatio по протоколу OData 3. Описание использования протокола OData 3 в Creatio содержится в статье OData.
  • ProcessEngineService.svc — запуск бизнес-процессов Creatio из внешних приложений. Описание веб-сервиса содержится в статье Сервис запуска бизнес-процессов.

Примеры системных веб-сервисов с анонимной аутентификацией, предоставляемых Creatio:

  • AuthService.svc — выполнение запроса на аутентификацию в приложении Creatio. Описание веб-сервиса содержится в статье Аутентификация.

В этой статье рассмотрены пользовательские веб-сервисы. Системные веб-сервисы описаны в разделе Интеграция и внешний API.

Разработать пользовательский веб-сервис

    Создайте схему Исходный код ( Source code ). Для создания схемы воспользуйтесь статьей Разработка конфигурационных элементов.

Создайте класс сервиса.

Реализуйте методы класса, которые соответствуют конечным точкам веб-сервиса.

Для методов добавьте атрибуты [OperationContract] и [WebInvoke] с необходимыми параметрами. Атрибут [OperationContract] описан в официальной документации Microsoft. Атрибут [WebInvoke] описан в официальной документации Microsoft.

Реализуйте дополнительные классы, экземпляры которых будут принимать или возвращать методы веб-сервиса (опционально). Выполняется при необходимости передачи данных сложных типов (экземпляры объектов, коллекции, массивы и т. д.).

Для класса добавьте атрибут [DataContract] , а для полей класса — атрибут [DataMember] . Атрибут [DataContract] описан в официальной документации Microsoft. Атрибут [DataMember] описан в официальной документации Microsoft.

Разработать пользовательский веб-сервис с анонимной аутентификацией

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

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

Зарегистрируйте пользовательский веб-сервис с анонимной аутентификацией:

Создайте файл с названием веб-сервиса и расширением *.svc. Добавьте в него запись.

Атрибут Service должен содержать полное имя класса веб-сервиса с указанием пространства имен.

WCF-директива @ServiceHost описана в официальной документации Microsoft.

<services> — элемент, который содержит перечень конфигураций всех веб-сервисов приложения (вложенные элементы <service> ).

name — атрибут, который содержит название типа (класса или интерфейса), реализующего контракт веб-сервиса.

<endpoint> — вложенный элемент, который содержит адрес, привязку и интерфейс, определяющий контракт веб-сервиса, указанного в атрибуте name элемента <service> .

Описание элементов конфигурирования веб-сервиса доступно в официальной документации Microsoft.

Настройте доступ к пользовательскому веб-сервису с анонимной аутентификацией для всех пользователей:

Добавьте элемент <location> , определяющий относительный путь и права доступа к веб-сервису.

В атрибут value ключа AllowedLocations элемента <appSettings> добавьте относительный путь к веб-сервису.

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

Настройте доступ к пользовательскому веб-сервису с анонимной аутентификацией для всех пользователей:

Пример изменений файла ..\Terrasoft.WebHost\appsettings.json
  1. Откройте конфигурационный файл ..\Terrasoft.WebHost\appsettings.json .
  2. Добавьте информацию о веб-сервисе в блок AnonymousRoutes файла.

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

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

Вызвать пользовательский веб-сервис

Пользовательский веб-сервис можно вызвать из браузера и из front-end части.

Вызвать пользовательский веб-сервис из браузера

    Для получения аутентификационных cookie используйте системный веб-сервис AuthService.svc .

Для вызова пользовательского веб-сервиса используйте строку запроса:

Вызвать из браузера пользовательский веб-сервис с анонимной аутентификацией

Вызвать пользовательский веб-сервис из front-end части

    В модуль страницы, из которой вызывается веб-сервис, в качестве зависимости подключите модуль ServiceHelper . Этот модуль предоставляет удобный интерфейс для выполнения запросов к серверу через провайдер запросов Terrasoft.AjaxProvider , реализованный в клиентском ядре.

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

Способы вызова пользовательского веб-сервиса:

    Вызовите метод callService(serviceName, serviceMethodName, callback, serviceData, scope) .

Вызовите метод callService(config) , где config — конфигурационный объект со свойствами:

serviceName — имя пользовательского веб-сервиса.

methodName — имя вызываемого метода пользовательского сервиса.

callback — функция обратного вызова, в которой выполняется обработка ответа от веб-сервиса.

data — объект с проинициализированными входящими параметрами для метода веб-сервиса.

scope — контекст выполнения запроса.

Важно. Модуль ServiceHelper работает только с POST -запросами. Поэтому к методам пользовательского веб-сервиса необходимо добавить атрибут [WebInvoke] с параметром Method = "POST" .

Этот способ позволяет покрывать код тестами и отображает явные зависимости класса. Подробнее об использовании фабрики классов можно узнать из статьи Принцип замещения классов.

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