Поделиться через

Шаблоны интеграции данных для отраслевых облаков Microsoft Industry

Относится к:

  • Microsoft Cloud for Sustainability
  • Microsoft Cloud for Financial Services
  • Microsoft Cloud for Healthcare
  • Microsoft Cloud for Retail

Модели отраслевых данных служат основой для соответствующих отраслевых облаков Microsoft Industry Cloud. В зависимости от уровня зрелости базы данных может потребоваться интеграция решений с другими системами.

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

Необходимость в интеграции

Сторонние системы могут иметь отдельные процессы и даже другую бизнес-логику. Если сторонняя система использует ту же базовую общую модель данных Common Data Model (CMD) Industry Cloud, устраняется необходимость в передаче данных, синхронизации и программировании для преобразования данных.

Мы используем шаблоны интеграции данных в следующих сценариях:

  • Первичные или транзакционные данные, которые не являются центральной частью единого непрерывного процесса управления. Данные синхронизируются между процессом в одной системе и отраслевым облаком Microsoft Industry Cloud.
  • Данные передаются или обмениваются между системами, когда это необходимо для расчетов.
  • Данные передаются между системами, поэтому действия в одной системе отражаются в другой.
  • Обобщенные данные из системы с подробным уровнем данных передаются в систему с представлением данных более высокого уровня.

Как выбрать правильную схему интеграции

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

Фактор принятия решения Описание
Типы и форматы данных Какой тип и формат данных интегрируется?
Волатильность данных От низкой волатильности/медленно меняющихся данных до высокой волатильности/быстро меняющихся данных.
Объем данных От небольших объемов данных к большим объемам.
Доступность данных Когда вы хотите, чтобы данные были готовы, от источника до цели? Нужны ли вам эти данные в режиме реального времени или вам просто нужно собрать все данные в конце дня и отправить их запланированным пакетом в целевую систему?
Защита сервисов и регулирование количества запросов к ним Обеспечение стабильной доступности и производительности для всех путем применения ограничений. Эти ограничения не должны влиять на обычных пользователей, а только на клиентов, выполняющих чрезвычайные запросы. Следует использовать общий шаблон для онлайн-сервисов для предоставления кодов ошибок при выполнении слишком большого количества запросов.
Требуемый уровень преобразования данных Требование преобразовать или агрегировать исходные данные в целевые.
Триггеры и действия триггеров Какое действие запускает отправку данных из источника в цель? Какие конкретно действия требуется автоматизировать после поступления данных в целевую систему?
Обработка ошибок Мониторинг, который осуществляется для обнаружения любых проблем с интерфейсами.
Масштабируемость Управляйте ожидаемыми объемами транзакций в настоящем, краткосрочном и долгосрочном периоде.
Система записи Учитывая, какая система является системой записи или владельцем информации.
Направление потока данных Должна ли целевая система извлекать их или исходная система должна их принудительно отправлять?

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

Шаблоны интеграции

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

  • Интеграция в реальном времени/синхронная интеграция
  • Интеграция почти в реальном времени/асинхронная интеграция
  • Пакетная интеграция
  • Интеграция уровня представления

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

Интеграция в реальном времени/синхронная интеграция

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

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

Диаграмма, показывающая шаблон интеграции в реальном времени

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

Диаграмма, показывающая шаблон интеграции в реальном времени со службой ретрансляции

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

Технологический вариант Направление данных Цель Используется, когда
Веб-API Dataverse Извлечение/отправка данных из внешнего источника в Dataverse Реализация OData v4 для обеспечения операций CRUD с использованием стандартного набора интерфейсов, предоставляя интерфейс, открытый для широкой технологической аудитории. В основном для интеграции транзакционных приложений, когда требуются дискретные операции CRUD. Его также можно использовать для любой пользовательской интеграции, но он сопряжен со сложностями, связанными с регулированием количества запросов, параллелизмом и логикой повторных попыток, особенно при больших объемах данных.
API-интерфейсы, опубликованные отраслевыми облаками Microsoft Извлечение/отправка данных из внешнего источника в Dataverse Пользовательские API-интерфейсы, созданные отраслевыми облаками Microsoft для поддержки специальных операций, таких как доступ к данным о выбросах, связанных с использованием Azure. Конкретные операции, опубликованные отраслевыми облаками Microsoft. Расставьте приоритеты в использовании этих пользовательских API-интерфейсов, прежде чем создавать свои собственные API-интерфейсы.
Пользовательский API-интерфейс Dataverse Извлечение/отправка данных из внешнего источника в Dataverse Создание собственного API-интерфейса в Dataverse. Когда одну или несколько операций необходимо объединить в одну операцию или необходимо предоставить новый тип события-триггера.
Виртуальные таблицы Извлечение/отправка данных из Dataverse во внешний источник Подключайтесь к внешним источникам данных и рассматривайте их как собственные сущности Dataverse. Получение справочных данных и сценариев CRUD с небольшим объемом.
Соединители Двунаправленное Обеспечьте бесперебойный обмен данными между службами Microsoft и внешними системами, приложениями и источниками данных. Опубликованные соединители Microsoft предназначены для часто используемых интеграций, таких как соединение служб Microsoft друг с другом и со сторонними приложениями. Проверенные опубликованные соединители используются для специализированной интеграции со сторонними приложениями, обеспечивая совместимость и надежность. Пользовательские соединители можно использовать, когда соединители Microsoft или партнеров не отвечают бизнес-потребностям клиента.

Интеграция почти в реальном времени/асинхронная интеграция

Асинхронная интеграция рекомендуется в сценариях, где нет непосредственной необходимости в ответах в реальном времени в бизнес-процессе или действии. Обычно она используется, когда между приложениями и системами передается значительный объем сообщений. Шаблоны асинхронной интеграции гарантируют, что связь между системами не блокирует и не замедляет процессы, позволяя каждой системе работать независимо и асинхронно. Некоторые из наиболее распространенных способов реализации асинхронной интеграции — это очереди сообщений, публикация-подписка и пакетная интеграция. Вы можете использовать эти интеграции отдельно или вместе, в зависимости от требований. Их часто называют архитектурой, управляемой событиями (EDA).

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

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

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

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

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

Технологический вариант Управляемый событиями или публикация-подписка Цель Рекомендации Используется при
Power Automate И то и другое Потребности малокодовой автоматизации. Следуйте ограничениям Power Automate и каждого соединителя, например регулирование количества запросов. Используйте для триггерных потоков Dataverse или когда вы хотите запускать потоки Power Automate по расписанию.
Пользовательские соединители на основе Logic Apps Управляемый событиями Создание соединителей данных для решения, позволяющего получать данные от решений независимых поставщиков программного обеспечения. Должны пройти проверку конфиденциальности, безопасности и соответствия нормативным требованиям, прежде чем они будут выпущены в качестве рабочей версии. Использование сценариев интеграции независимых поставщиков программного обеспечения, в которых отсутствуют собственные соединители.
Logic Apps и служебная шина Azure Публикация-подписка Получение сообщений издателем в служебную шину, и приложения Logic Apps исользуют это сообщение для отправки приложениям-подписчикам. Учитывайте конфигурацию и ограничения выполнения Logic Apps. Используйте собственные триггеры соединителей Logic Apps и пользовательскую интеграцию со сценариями нескольких подписчиков.
Функции Azure, функция веб-приложений службы приложений Azure и служебная шина Azure Публикация-подписка Используйте очередь сообщений для реализации канала связи между приложением и экземплярами потребительской службы. Рассмотрим порядок сообщений и другие соображения по дизайну. Сценарии с большими объемами и нестабильностью, в которых интеграцию невозможно реализовать с помощью малокодовых вариантов (Power Automate или Logic Apps).
Конечная точка службы И то и другое Отправка контекстной информации в очередь, тему, веб-перехватчик или концентратор событий. Не подходит для длительных транзакций. Когда требования интеграции в основном удовлетворяются отправкой контекста Dataverse в целевую систему напрямую, а порядок сообщений не имеет решающего значения.

Пакетная интеграция

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

Технологический вариант Направление данных Цель Рекомендации Используется при
Azure Data Factory В обе стороны Создание потоков данных для преобразования данных, полученных от Dataverse, или перед приемом в Dataverse Ограничения службы фабрики данных Сценарий массового приема или экспорта данных со сложным многоэтапным преобразованием.
Power Automate Неприменимо Автоматизация рабочих процессов и задач для Microsoft Ограниченная масштабируемость и длительная обработка Используйте Power Automate, когда вам нужно автоматизировать повторяющиеся задачи, запускать действия на основе событий и интегрировать приложения без разработки большого объема кода.
Поток данных Power Query Из внешних систем в Dataverse Инструмент подготовки данных, который позволяет принимать, преобразовывать и загружать данные в среды Dataverse. Ограничения Базовые сценарии, в которых целью является Dataverse и существующие соединители не подходят, и другие заданные сценарии для Power BI.
Конвейеры Azure Synapse В обе стороны Создание конвейеров для преобразования данных, полученных из Dataverse или перед приемом в Dataverse Неприменимо Сценарии аналитики и хранения данных.
Azure Synapse Link for Dataverse Из Dataverse в Azure Synapse Analytics или Azure Data Lake Storage v2 (ADLS) Репликация данных Dataverse в Azure Synapse Analytics или ADLS v2, и позволяет запускать аналитику, бизнес-аналитику и сценарии машинного обучения и пользовательской отчетности для ваших данных. Таблицы, которые не поддерживаются. Аналитика данных и пользовательская отчетность. Также как промежуточный этап экспорта данных.
Приложения логики Azure Неприменимо Создавайте рабочие процессы с мощными возможностями интеграции. Сложные пакетные операции могут потребовать значительной настройки и оркестрации. Не оптимизирован для специализированных сценариев пакетной обработки. Приложения Azure Logic Apps подходят для организации бизнес-процессов и интеграции служб.
SQL Server Integration Services В обе стороны Использование стороннего соединителя для извлечения и отправки данных из/в Dataverse. Поскольку это не решение PaaS, необходимо оценить масштабирование, использование памяти, производительность и стоимость. Любые ограничения, когда инструменты облачного извлечения, преобразования и загрузки (ETL) могут оказаться неприемлемыми.

Интеграция уровня представления

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

  • Включение агрегитрования данных
  • Настройка пользовательского интерфейса
  • Повышенное удобство работы пользователей

И наоборот, она имеет присущие ограничения, в том числе:

  • Сложности в интеграции и сопровождении
  • Значительная взаимозависимость между интегрированными системами
  • Потенциальные последствия для производительности
  • Соображения относительно согласованности данных
Технологический вариант Цель Рекомендации Используется при
Собственные интеграции пользовательского интерфейса Использование карт Microsoft Bing, Microsoft Teams и других собственных интеграций пользовательского интерфейса. В большинстве случаев не настраивается. Определенные сценарии поддерживаются при интеграции встроенного пользовательского интерфейса.
Пользовательские страницы Внедрение приложений на основе холста в приложения на основе модели. Известные ограничения Предпочтительно использовать подход к интеграции с минимальным количеством кода и когда приложение на основе холста подходит для удобства использования.
Power Apps component framework (PCF) Пользовательский элемент управления многократного использования для отображения или взаимодействия с конечным пользователем, сохраняя при этом адаптивный дизайн. Ограничения Power Apps component framework. Предпочтительный метод, когда необходимо разработать настраиваемый пользовательский интерфейс в приложении на основе модели при отсутствии приложения на основе холста.
Плитки Power BI Отображение плитки Power BI в форме приложения на основе модели. Лицензирование Power BI, авторизация данных Power BI. Отображение плитки Power BI в приложении на основе модели
Панель мониторинга Power BI Embedded Отображение панели мониторинга Power BI Embedded в приложении на основе модели. Лицензирование Power BI, авторизация данных Power BI. Отображение аналитики, размещенной в Power BI.
Внедрение в виде HTML iFrame Внедрение другого системного пользовательского интерфейса в приложение на основе модели. Единый вход (SSO), конфигурация совместного использования ресурсов между источниками (CORS) и адаптивный дизайн. Сложные сценарии пользовательского интерфейса, когда сервис недоступен.
Пользовательский веб-ресурс Создание пользовательского макета пользовательского интерфейса в приложении на основе модели. Оцените специальные возможности и адаптивный дизайн пользовательского интерфейса. Сценарии, в которых другие интеграции пользовательского интерфейса невозможны.

Сводка по шаблонам интеграции данных

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

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

Шаблон интеграции Механизм Триггер Плюсы Минусы Используется при
В реальном времени или синхронная Обмен данными происходит синхронно, вызывая действия посредством двухточечной интеграции или с помощью ретрансляции. Действие пользователя или системное событие. Быстрый цикл передачи запрос и получения ответа. Значения и информация в реальном времени. Как правило, это не лучшая практика из-за риска зависания процессов и возникновения тесной интеграции. Риск волнового эффекта из-за временных ошибок. Чувствителен к задержке. Используйте, когда наличие информации в реальном времени критически важно.
Асинхронный Данные обмениваются или принимаются автоматически по периодическому графику или в виде постепенного потока с использованием шаблонов обмена сообщениями. Запланировано на определенный период или инициировано новым сообщением, опубликованным исходной системой. Слабая связь систем делает решение надежным. Балансировка нагрузки по времени и ресурсам. Это может быть очень близко к реальному времени. Своевременная обработка ошибок. Задержка реакции и отражения изменений в системах. Потребность в синхронизации данных практически в реальном времени для небольших или средних объемов данных.
Пакетная обработка Пакетная обработка — это практика сбора и транспортировки набора сообщений или записей в пакете для ограничения обмена сообщениями и накладных расходов. Запланированный или ручной триггер. Отлично подходит для использования со службами обмена сообщениями и другими шаблонами асинхронной интеграции. Меньше отдельных пакетов и меньше трафика сообщений. Свежесть данных ниже. Возможно влияние на нагрузку в принимающей системе, если бизнес-логика выполняется по прибытии сообщения. Сценарии с большими объемами или нестабильностью, когда возможен сбор и транспортировка набора сообщений или записей в пакетном режиме, сценарии репликации данных.
Уровень презентации Информация из одной системы легко интегрируется в пользовательский интерфейс другой системы. Неприменимо Устраняет сложность синхронизации данных, поскольку данные остаются в исходной системе. В некоторых отраслях это устраняет блокировки, связанные с местом расположения данных в соответствии с нормативными требованиями. Трудно использовать данные для расчетов и обработки, сложнее обеспечить единый вход, совместное использование ресурсов между источниками и согласование авторизации. Когда требование удовлетворяется путем непосредственного отображения исходной системы или пользовательского интерфейса без необходимости синхронизации данных между исходной и целевой системой.

Следующие шаги

Microsoft Cloud for Sustainability

Microsoft Cloud for Financial Services

Microsoft Cloud for Healthcare