ноябрь 2016

Том 31, Номер 11

Microsoft Bot Framework - Решение бизнес-задач с помощью Microsoft Bot Framework

Срикантан Санкаран

Продукты и технологии:

Microsoft Bot Framework, Microsoft Flow, Azure Blob Storage, Azure Search, Azure SQL Database

В статье рассматриваются:

  • приложение, использующее преимущества Microsoft Flow, Azure Search и Microsoft Bot Framework для решения бизнес-задач;
  • создание последовательности операций (flows) бизнес-процесса, используя Microsoft Flow для консолидации данных из разных специализированных бизнес-приложений (line-of-business, LOB);
  • настройка Azure Search для индексации консолидированных данных, чтобы их можно было запрашивать из бота.

Сегодня люди все делают в сети или на своих телефонах (покупают, продают, проводят банковские операции, изучают информацию по какой-то тематике), и, чтобы сохранить конкурентоспособность, предприятиям нужно постоянно развивать свои приложения для обеспечения максимального удобства клиентам, использующим их сервисы. Это включает поддержку различных возможностей самообслуживания с удобным доступом клиентов к своим данным в любое время и в любом месте, зачастую из социальных каналов, используя голосовую связь и обмен сообщениями. Это трудная задача из-за необходимости совместной работы множества разных приложений и потому, что большинство этих приложений никогда не было рассчитано на обработку ситуаций, с которыми мы сталкиваемся в настоящее время. Усилия, нацеленные на удовлетворение этих потребностей, скорее всего приведут к необходимости создавать целый ряд проектов для параллельной разработки с вовлечением значительных ресурсов. Однако Microsoft Bot Framework может облегчить эту задачу.

Microsoft Bot Framework предоставляет платформу для организаций, создающих приложения — боты, с которыми клиенты могут легко взаимодействовать речевым или текстовым вводом. Без каких-либо дополнительных усилий к этим ботам можно без проблем обращаться по множеству социальных каналов, таким как Skype, Slack, Facebook Messenger и др. Они могут предоставлять пользователям доступ ко всем их данным, консолидированным из разрозненных LOB-приложений, с помощью технологий вроде Azure Logic Apps или Microsoft Flow. Эти технологии поставляются с коннекторами для всех ключевых бизнес-приложений, имеющихся сегодня на рынке. Azure Search Service предоставляет мощный механизм Lucene, который можно применять для гибкого поиска данных — как структурированных, так и неструктурированных. Клиенты могут взаимодействовать с ботами, ведя с ними разговор на естественном языке, и Azure Language Understanding Intelligent Service (LUIS) способен интерпретировать эти разговоры для располагающихся далее в общем процессе приложений, чтобы они могли соответственно реагировать.

В этой и следующей статьях мы обсудим сценарий, иллюстрирующий трудные задачи, с которыми сталкиваются сегодня организации, и то, как они могут создать решение с применением Microsoft Bot Framework. При реализации решения, охватывающего этот сценарий, вам пригодятся следующие полезные ссылки:

  • «Indexing Documents in Azure Blob Storage with Azure Search» (bit.ly/2d4yr8s);
  • «Enable and Disable Change Tracking (SQL Server)» (bit.ly/2d226wt).

Создание решения

Бизнес-сценарий, который будет проходить фоном в этой статье, включает страховое агентство, предлагающее клиентам разные виды договоров страхования — автомобилей, домов, пассажиров и медицинского страхования. Клиенты могут регистрироваться в веб-приложении, используя свои удостоверения Microsoft, и передавать свои запросы на конкретные виды страхования. Рабочий процесс обеспечивает поддержку регистрации пользователя в Dynamics CRM Online, где собирается информация о профиле, а затем договор страхования сохраняется в Office 365 SharePoint. Внутренний рабочий процесс в организации со временем изменяет состояние запроса на заключение договора, что в конечном счете приводит к его одобрению и генерации документа с условиями договора (policy document), сохраняемого в Office 365. Эти операции выходят за рамки этой статьи, поскольку в ней мы сосредоточимся на сценариях интеграции данных от нижележащих приложений, запускаемых после получения информации системой, и на извещении клиента о последующих обновлениях состояния договора. Архитектура решения для этого сценария представлена на рис. 1.

Архитектура решения
Рис. 1. Архитектура решения

Dynamic CRM Online Dynamic CRM Online
Contacts Контакты
Microsoft Flow Microsoft Flow
Policy Request, Customer(Contacts) Запрос на заключение договора, Клиент (контакты)
Azure Storage Azure Storage
Azure SQL Database Azure SQL Database
Policy Documents Документы с условиями договора
Blobs Blobs
Azure Search Azure Search
Index Индекс
Office 365 / SharePoint Office 365 / SharePoint
Policy Requests, Documents Запросы на заключение договоров, документы
Microsoft Azure Microsoft Azure
Registered Consumers Зарегистрированные клиенты
Skype Skype
Microsoft Bot Framework Connector Service Microsoft Bot Framework — Connector Service
Bot App Приложение-бот
Azure Web App Azure Web App
LUIS LUIS
Cognitive Services Cognitive Services

Создание профиля контакта для клиента в Dynamics CRM Online, создание или обновление запроса на заключение договора в Office 365 или загрузка условий договора в Office 365 инициирует события в рабочих процессах бизнес-процесса, реализованного с применением Microsoft Flow. Через эти процессы структурированные данные синхронизируются и помещаются в таблицы Azure SQL Database, а неструктурированные данные, такие как условия договоров, реплицируются в Azure Blob Storage. Azure Search проходит по этим данным через регулярные интервалы и поддерживает их актуальность для запросов. Приложение-бот развертывается как Azure Web App, публикуемое через Microsoft Bot Framework Connector Service. Через Connector Service приложение-бот подключается к каналу Skype, к которому клиенты обращаются за получением состояния своих запросов о договорах страхования, для скачивания выданных условий договоров, планирования визитов с целью проверки и т. д. Клиенты входят под учетной записью Microsoft, где они регистрировались при обращении за договором страхования. Они могут использовать для взаимодействия с ботом либо обмен сообщениями в клиенте Skype, либо голосовые команды. Приложение-бот интегрируется с сервисом LUIS — одним из нескольких сервисов, доступных в Microsoft Cognitive Services, — для интерпретации клиентского ввода и выполнения запросов в Azure Search.

В этом контексте для создания решения нужно сделать следующее.

  1. Создать последовательности операций (flows) в бизнес-процессе с помощью Microsoft Flow для синхронизации и консолидации данных от различных LOB-приложений.
  2. Настроить Azure Search на индексацию консолидированных данных, чтобы их можно было запрашивать из бота.
  3. Сконфигурировать сервис LUIS, создать и обучить модель для интерпретации разговоров пользователей с ботами.
  4. Создание приложение-бот с помощью Microsoft Bot Framework и задействовать его из Skype.

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

Последовательность операций для синхронизации запросов на заключение договоров страхования

В этом примере запросы на заключение договоров сохраняются в пользовательском списке в Office 365. Процесс Microsoft Flow, связанный с этим списком, запускается, когда запрос на договор вставляется или обновляется в ходе процесса утверждения, и это приводит к вызову хранимой процедуры в Azure SQL Database. Для сценариев вставки и обновления создаются раздельные процессы Microsoft Flow.

На рис. 2 показано, как Microsoft Flow Designer позволяет выбирать событие-триггер в списке SharePoint в Office 365 при создании или обновлении элемента или файла.

События-триггеры в Microsoft Flow
Рис. 2. События-триггеры в Microsoft Flow

На рис. 3 показана последовательность операций (flow), которая запускается при вставке в этот список запроса на заключение договора страхования. Microsoft Flow Designer считывает метаданные хранимой процедуры и автоматически выводит форму на основе ее входных параметров. Поместив курсор в одно из полей ввода на форме, вы открываете карточку (правая часть рис. 3), где отображаются атрибуты из предыдущих операций; вы можете выбрать нужные вам атрибуты и сопоставить их с входными параметрами хранимой процедуры.

Последовательность операций синхронизации для запроса на договор страхования
Рис. 3. Последовательность операций синхронизации для запроса на договор страхования

Я создам дополнительную последовательность для синхронизации обновлений, чтобы обеспечить регулярное обновление состояния запроса на одобрение договора из Office 365 в целевой базе данных Azure SQL Database.

Заметьте, что каждый коннектор, применяемый в этом сценарии, требует соединения, которое сначала должно быть сконфигурировано, и учетной записи пользователя с достаточными правами для чтения данных из пользовательского списка в Office 365 SharePoint Site. Аналогично коннектор Azure SQL Database требует передачи удостоверений пользователя для аутентификации в базе данных.

Для теста созданной мной последовательности операций можно вставить какую-нибудь запись в список. Данные должны быть реплицированы в Azure SQL Database.

Последовательность операций синхронизации документов с условиями договоров

Как только запрос на заключение договора утверждается (по завершении серверного процесса, описание которого выходит за рамки этой статьи), генерируется документ с условиями договора и загружается в библиотеку документов в Office 365 SharePoint. Затем Microsoft Flow реплицирует этот документ в Azure Blob Storage. Для вставки нового документа в Azure Storage и замены исходного документа, если он обновляется в Office 365, создаются раздельные процессы Microsoft Flow. Документ содержит определенные ключевые слова вроде государственного номерного знака застрахованного автомобиля. Далее в этой статье я буду использовать Azure Search для выполнения полнотекстового поиска в документах по специфическим ключевым словам. На рис. 4 показана последовательность операций в Microsoft Flow, реализованная для синхронизации документов, которые впервые загружаются в Office 365.

Последовательность операций синхронизации для документов с условиями договоров
Рис. 4. Последовательность операций синхронизации для документов с условиями договоров

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

Синхронизация данных клиентских профилей

Когда клиент впервые регистрируется у поставщика страховых услуг, в Dynamics CRM Online создается контакт. Затем вызывается Microsoft Flow, который использует Dynamics CRM Online Connector для получения контакта и его вставки в Azure SQL Database. На рис. 5 показано, как может быть реализован этот процесс.

Поток данных о контактах
Рис. 5. Поток данных о контактах

Обратите внимание на то, что сначала нужно сконфигурировать соединение с Dynamics CRM Online, применяя удостоверения пользователя, в которых есть разрешение на подключение к организации и роль в системе безопасности, дающая права на доступ к данным. Более того, вы должны включить отслеживание изменений в таблице в Dynamics CRM Online, которая будет захватывать «события вставки», и в нашем случае такой таблицей является Contacts.

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

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

Выполнение последовательности операций
Рис. 6. Выполнение последовательности операций

Чтобы проверить эту последовательность операций, можно создать контакт через портал CRM Online. Данные контакта должны реплицироваться в Azure SQL Database.

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

Подготовка источников данных для поиска

Я реализовал процесс, чтобы консолидировать данные изо всех LOB-приложений, но, прежде чем использовать эти данные в Azure Search, нужно выполнить определенные операции.

Включение отслеживания изменений в Azure SQL Database Azure Search использует встроенный индексатор для Azure SQL Database, чтобы проходить по данным и формировать индекс. Отслеживание изменений нужно включить в базе данных и во всех таблицах, чтобы Azure Search не приходилось каждый раз перестраивать индекс:

ALTER DATABASE PolicyInfoDB SET CHANGE_TRACKING = ON
(CHANGE_RETENTION = 2 DAYS, AUTO_CLEANUP = ON);
ALTER TABLE CrmCustomerData ENABLE CHANGE_TRACKING
WITH (TRACK_COLUMNS_UPDATED = OFF);
ALTER TABLE PolicyRequests ENABLE CHANGE_TRACKING
WITH (TRACK_COLUMNS_UPDATED = OFF);

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

Настройка Azure Search на индексацию таблиц PolicyRequests и CrmCustomerData С помощью Azure Portal создайте сущность для своего поиска, затем выберите вариант импорта данных из Azure SQL Database. Мастер проведет вам по все процессу — от подключения к базе данных, создания источника данных для поиска, выборки данных для чтения метаданных и выборки атрибутов, которые необходимо использовать, до расписания обновления индекса. Индексы для каждой из таблиц настраиваются раздельно. На рис. 7 показана страница настройки индекса поиска для базы данных.

Конфигурирование Azure Search для индексации таблицы базы данных
Рис. 7. Конфигурирование Azure Search для индексации таблицы базы данных

Страница настройки Azure Search обнаруживает, включено ли отслеживание изменений в индексируемой таблице базы данных. Я задал ежечасную индексацию (Hourly); прочие варианты включают Once, Daily и Custom.

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

Колонка параметров Azure Search предоставляет обозреватель поиска (search explorer), который упрощает задание параметров поиска, просмотр результатов и проверку конфигурации.

Конфигурирование индекса Azure Search для документов с условиями договоров Настройка Azure Search на поиск и индексацию в Azure Storage Blobs очень похожа на только что описанную настройку базы данных, но должен заметить, что эта функциональность на данный момент все еще находится в состоянии предварительной версии.

Далее в этой статье я намерен задействовать Azure Search для запроса документов по дате их генерации и по ключевым словам вроде регистрационного номера автомобиля, хранящимся в документах. Azure Search поддерживает Apache Lucene Query Language, обеспечивающий расширенные возможности запросов.

Заметьте, что Blob Storage имеет свойство metadata_storage_last_modified, которое является полем даты-времени. Тип данных его эквивалента в Azure Search, используемого индексатором для поиска совпадения, — Edm.DateTimeOffset, но по нему вести поиск нельзя. Поскольку я хочу извлекать документы с условиями договоров по году их генерации, соответствующее поле должно поддерживать запросы (queryable field).

Чтобы решить эту проблему, я мог бы сменить тип данных в индексе на Edm.String, который поддерживает поисковые запросы. Однако, так как индексатор использует это поле в качестве флага, чтобы определять, изменился ли файл с момента последней операции индексации и следует ли снова индексировать его, смена типа данных не годится из-за риска нарушения работы этой функциональности.

Вместо этого можно добавить дополнительное поле в индекс для хранения того же значения, используя тип данных Edm.String. Но тогда я не смогу использовать Azure Portal для настройки индекса, поскольку он не разрешает изменение логики для сопоставления полей из Azure Storage с индексом.

Чтобы обойти эту проблему, я задействую бесплатную утилиту — клиент Postman (getpostman.com/apps) — для обращения к Azure Search Service REST API и для выполнения следующих задач.

  • Создание источника данных Это можно сделать либо на Azure Portal, либо с помощью REST API из клиента Postman.
  • Конфигурирование индекса Поскольку я вручную определяю поля в индексе, я могу использовать более понятные имена, чем предлагаемые в конфигурации Search по умолчанию. Поле filepath будет установлено в качестве поля ключа в индексе. Обратите внимание на два поля подстановки для даты последней модификации — одно на основе Edm.DateTimeOffset а другое на основе Edm.String:
{
  "name" : "policydocuments-index",
    "fields": [
      { "name": "filepath", "type": "Edm.String", "key": true,
        "searchable": true },
      { "name": "content", "type": "Edm.String", "searchable": true },
      { "name": "filesize", "type": "Edm.String", "searchable": true },
      { "name": "author", "type": "Edm.String", "searchable": true },
      { "name": "filename", "type": "Edm.String", "searchable": true },
      { "name": "lastmoddate", "type": "Edm.String", "searchable": true },
      { "name": "contenttype", "type": "Edm.String", "searchable": true },
      { "name": "modifieddate", "type": "Edm.DateTimeOffset",
        "searchable": false }
      ]
}
  • Создание индексатора и полей сопоставления (mapping fields) На этом этапе создается индексатор, определяется расписание индексации и сопоставляются поля в Azure Storage с определенными в индексе на предыдущем этапе:
{
  "name" : "policydocuments-indexer",
  "dataSourceName" : "policiesrepodatasource",
  "targetIndexName" : "policydocuments-index",
  "schedule" : { "interval" : "PT2H" },
    "fieldMappings" : [
           { "sourceFieldName" : "metadata_storage_name",
             "targetFieldName" : "filename" },
     { "sourceFieldName" : "metadata_storage_size",
       "targetFieldName" : "filesize" },
     { "sourceFieldName" : "metadata_author", "targetFieldName" : "author" },
     { "sourceFieldNambe" : "metadata_storage_last_modified",
       "targetFieldName" :
       "modifieddate" },
     { "sourceFieldName" : "metadata_storage_last_modified",
       "targetFieldName" :
       "lastmoddate" },
     { "sourceFieldName" : "metadata_content_type",
       "targetFieldName" : "contenttype" },
     { "sourceFieldName" : "metadata_storage_path",
       "targetFieldName" : "filepath" }
  ],
  "parameters" : { "base64EncodeKeys": true }
}

Теперь я могу использовать обозреватель (explorer) в Azure Search на портале, чтобы удостовериться в индексации документов и корректном сопоставлении значений атрибутов.

Требования к программному обеспечению для реализации этого сценария

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

  • SQL Management Studio for SQL Server 2014 или более поздняя версия для создания и подключения к Azure SQL Database.
  • Подписка Dynamics CRM Online с учетной записью пользователя, позволяющей подключаться к организации, где будут создаваться контакты, и имеющей необходимые роли в системе безопасности для чтения таблицы контактов. Вы также должны включить отслеживание изменений в этой таблице, чтобы работал ее триггер «при создании».
  • Доступ к сайту SharePoint в Office 365 и учетная запись пользователя с соответствующими правами доступа к этому сайту.
  • Рабочая учетная запись (work account) для входа и создания бизнес-процессов, обеспечивающих синхронизацию данных с использованием Microsoft Flow. Начните с посещения сайта flow.microsoft.com.
  • Для использования сервиса LUIS зарегистрируйтесь по своей рабочей учетной записи (или учетной записи Microsoft) на luis.ai. В следующей статье я буду использовать этот сервис для моделирования разговоров, о которых упоминалось в этой статье.

Примечание На момент написания этой статьи Microsoft Flow находится в состоянии предварительной версии и пока не позволяет обрабатывать исключения, реализовать логику повторной попытки или манипулировать кодом, стоящим за последовательность операций процесса. Все процессы, представленные в этом сценарии, также можно создать, используя Azure Logic Apps, которые поддерживают не только все средства Microsoft Flow, но и дополнительные средства вроде обработки исключений, применения редактора кода для манипуляций над последовательностями операций и др.

Выполнение сценария

Выполнение этого сценария от начала до конца требует веб-приложения, которое позволяет клиентам регистрироваться со своими удостоверениями Microsoft и отправлять запрос на заключение договора страхования. Затем это приложение должно создавать контакт в Dynamics CRM Online, генерировать идентификатор контакта и использовать это значение в запросе на договор страхования, созданном в списке Office 365. Однако, поскольку реализация такого приложения выходит за рамки этой статьи, вам придется выполнять все этапы вручную и по отдельности.

Войдите в Dynamics CRM Online Portal и создайте контакт. Убедитесь, что вы получили такие сведения, как номер мобильного телефона и учетную запись Microsoft для клиента, поскольку они потребуются впоследствии при работе с ботом. В дальнейшем будет запускаться процесс Microsoft Flow, связанный с таблицей Contacts, вызываться хранимая процедура в Azure SQL Database, а затем в таблицу CrmCustomerdata вставляться запись о клиенте. Запишите себе значение Customer ID, хранящееся в этой таблице, — оно понадобится на следующем этапе.

Вручную создайте запрос на договор страхования в пользовательском списке SharePoint в Office 365. Убедитесь, что Customer ID, сгенерированный для этого клиента в Dynamics CRM Online, захвачен в запросе. На рис. 8 показан список в SharePoint, где захватывается запрос. Процесс Microsoft Flow, связанный с этим списком, будет запущен при сохранении записи или при ее последующем обновлении в процессе одобрения. Удостоверьтесь, что запрос на договор страхования реплицируется в таблицу PolicyRequests в Azure SQL Database.

Запрос на договор страхования в списке Office 365
Рис. 8. Запрос на договор страхования в списке Office 365

From dynamics CRM online Из Dynamics CRM Online

Затем создайте примеры PDF-документов и проверьте, что они содержат регистрационный номер автомобиля или идентификационные номера, которые будут использоваться при поиске документа. Загрузите эти документы в библиотеку SharePoint, связанную с процессом Microsoft Flow, для синхронизации документов. Убедитесь, что эти документы реплицируются по учетной записи хранилища Azure, сконфигурированного в последовательности операций (flow).

Вручную запустите индексатор, чтобы данные, синхронизированные на предыдущих этапах, были проиндексированы и доступны для поиска. Запустите Azure Search Explorer и запросите записи в каждой из таблиц и документы с условиями договоров, загруженные вами ранее, и проверьте, что они возвращаются в результатах поиска.

Обработка фрагментов речи на естественном языке в приложении-боте

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

  • What is the status of my insurance policy request? (Каково состояние моего запроса на договор страхования?)
  • Is my policy request # VehPol0101 approved? (Одобрен ли мой запрос на договор страхования за номером VehPol0101?)
  • Is there an update to my insurance policy request # VehPol0101? (Обновлен ли мой запрос на договор страхования за номером VehPol0101?)
  • Show me my policy document. (Покажи мне мой документ с условиями страхования.)
  • Get me the policy document. (Получи мой документ с условиями страхования.)
  • Get me last year’s policy document for Vehicle # KA 02A 8534. (Получи мой документ с условиями страхования за прошлый год для автомобиля с номером KA 02A 8534.)
  • Show me the policy document for vehicle # KA 02A 8534 issued in 2014. (Покажи мне документ с условиями страхования для автомобиля с номером KA 02A 8534 за 2014 год.)
  • Can you schedule a site inspection visit on Tuesday next week for vehicle # KA 02A 8534? (Можешь ли ты запланировать инспекционный визит на сайт во вторник на следующей неделе для автомобиля с номером KA 02A 8534?)

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

В следующей статье я создам приложение-бот с поддержкой естественного языка. Для этого я создам модель LUIS, которая будет регистрировать эти фрагменты речи (utterances) на естественном языке, обучу ее идентификации намерений пользователя в этих фрагментах речи и определю вспомогательные параметры или сущности, которые буду передавать в запросах к сервису Azure Search.

Артефакты, доступные для скачивания

Артефакты, использовавшиеся при реализации этого сценария, доступны для скачивания в репозитарии GitHub по ссылке bit.ly/2cOfANh:

  • скрипты для создания таблиц CrmCustomer и PolicyRequests в Azure SQL Database;
  • хранимые процедуры, использовавшиеся в предыдущих таблицах базы данных;
  • экранные снимки схемы списка Office 365, в котором хранятся запросы на договоры страхования, и библиотеки документов, куда загружаются документы с условиями договоров.

Я буду загружать другие артефакты, относящиеся к следующей статье, в то же место.

Заключение

Сегодня организации имеют дело с множеством приложений, которые должны работать совместно для решения задач бизнеса. Зачастую это трудная задача в том плане, что информация распределена по предприятию, что усложняет ее консолидацию и обеспечение доступа к ней со стороны клиентов. Microsoft Flow помогает консолидировать информацию всего предприятия, а Azure Search предоставляет гибкий механизм с богатой функциональностью запросов для обращения к данным. Это позволяет создать всего один интерфейс сервиса, который интегрирует всю информацию, ускоряя создание и развертывание клиентских приложений.

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


Срикантан Санкаран (Srikantan Sankaran) — технологический идеолог из группы DX в Бангалоре (Индия). Работает с многочисленными независимыми поставщиками решений (ISV) в Индии и помогает им проектировать архитектуру и развертывание решений в Microsoft Azure. С ним можно связаться по адресу sansri@microsoft.com.

Выражаю благодарность за рецензирование статьи экспертам Microsoft Сандипу Алуру (Sandeep Alur) и Полу Бауэру (Paul Bouwer).


Discuss this article in the MSDN Magazine forum